Payment release control

Check the evidence, the entitlement and the beneficiary before the money leaves

• Domain: Payments & Settlement
• Moment: Before the money moves
• Customer: A Gulf retail bank managing developer escrow

Check every release before the money leaves.

The situation

A retail bank in the Gulf holds escrow accounts for property developers. Buyer instalments go in. Money comes out only against certified construction progress, inside the limits set by the contract and the rules the account operates under.

Every release is a small credit decision made on a stack of documents: the engineer's certification, contractor invoices, the payment schedule, the budget, prior drawdowns, beneficiary account details.

The checking gets done, one claim at a time, against a payment cut-off. Then again for the auditor.

What breaks today

The pack is checked for presence only. A checklist confirms the certificate is attached. A person must still read it to confirm that the certified progress supports the claim.

Entitlement is recalculated by hand on every claim. Claimed amount against certified progress, the budget line, what is already released against it, the retention held back and any category cap. Simple arithmetic, against a cut-off.

Cumulative limits are invisible inside a single claim. A correct individual claim can still take a category over its project limit. The check needs the running total across all claims.

The same invoice arrives twice. Resubmitted a cycle later, reformatted, under a different reference, inside a larger claim. Per-claim review has no memory.

Beneficiary details change on a covering letter. A contractor's account number is amended between claims. Confirming the new account belongs to that contractor is a call under time pressure.

Cost categories are mapped by judgement. Whether a line is construction, marketing, land or management fee decides which limit it consumes, so totals depend on who processed the claim.

A rejection costs as much as an approval. A claim held for one missing document goes back, returns partly fixed, and consumes the review twice.

The reason for a decision lives in an email. Months later, the question is why the release was approved below the amount claimed. The answer sits in a thread.

What Manuel does

It sits in front of the release. It does not move money.

Intake and pack assembly. Manuel classifies every document arriving by email, portal or folder into one claim object: project, contractor, certified progress, invoice numbers, amounts, tax, beneficiary account, signatory. Each field links back to the page it came from.

Completeness against claim type and project stage. Manuel checks each required document is present, current and issued by a party the project record recognises, then names what is missing.

Entitlement calculation, shown. From certified progress, the payment schedule, the budget line, prior drawdowns and the retention rule, Manuel computes the releasable amount and shows the working. Any difference is attributed to the term that produced it.

Cap and cumulative checks on the running total. Every limit is evaluated on the total including this claim. A breach returns the limit, the position and the amount by which it exceeds.

Duplicate detection across the project's whole history. Invoice numbers, amounts, dates, contractors and document fingerprints are compared against every claim previously submitted on the project. Near matches surface with the earlier claim attached.

Beneficiary and account control. The named beneficiary is checked against the contract party and the project record. A changed account is an exception in its own right, whatever else is correct.

A verdict with reason codes. Every claim returns ready, hold or needs-review. Hold names the check that failed. Needs-review states the judgement required. An unknown result is never ready.

An evidence packet per claim. It shows the checks, values, rule version, and source document for each value.

What the customer gets

This control is proposed with a one-month test design. There is no measured result yet.

The officer receives completed arithmetic and named exceptions, leaving more time for judgement. Cumulative limit breaches and repeated invoices are checked across the full history.

What we measure in the proof, baselined first: claims per month, minutes per claim by type, the share held for a missing document, the rework rate, time from submission to decision, and any case last cycle where a duplicate or cap breach was caught after release.

What stays with your existing systems

Core banking stays in place with the escrow account, customer record, and payment rail. Manuel has no payment authority and initiates no transfer. It reads the claim, applies the checks, and returns a result with supporting records. An authorised officer makes the release in the existing system under your maker-checker process.

Deployment runs inside a private VPC, or through a runtime agent on-premise where systems cannot be reached from a cloud.

What a first scope looks like

One project, closed claims, read-only, files first. We run the control over claims your team has already decided and compare our verdict with the decision made. Where we disagree, we examine why, and those disagreements become the acceptance criteria.

The first test uses closed claims and has no connection to the live payment system.

Related: Settlement and fee integrity / Continuous audit / Residual exception diagnosis