Why Open Banking Teams Shouldn’t Trust the First Settlement Signal?

How ISO 20022 status tracking and in-flight limits help B2B platforms manage settlement exposure

A platform credited a merchant’s internal balance the moment the payer’s bank confirmed the debit. Two days later, the funds still hadn’t arrived on the merchant side. The balance was wrong, an order had already been released, and the operations team spent most of a week untangling the mismatch.

This is settlement risk in Open Banking — and if you’re running a B2B platform that processes account-to-account payments, it’s more common than many teams expect.

Open Banking Settles Differently from Cards

Open Banking moves money differently from card payments. In a card-based flow, authorisation and capture happen through a single processor, and the lifecycle is relatively predictable.

In Open Banking, the moment funds leave the payer’s account and the moment they arrive in the merchant’s account are separate events — reported through different status codes, often at different times, and sometimes through different intermediaries.

For B2B platforms that need to update internal balances, release orders, or trigger downstream workflows, this creates a practical question:

At what point in the payment flow is it safe to act?

Why Early Balance Updates Create Risk

If a platform updates a merchant’s internal balance when funds have left the payer’s bank but have not yet reached the merchant’s account, the platform is temporarily holding the position.

If those funds are delayed, rerouted, or fail to arrive, the platform has already updated records in a way that does not match reality.

In practice, this leads to reconciliation exceptions, delayed fulfilment, and sometimes having to cover the shortfall.

What ACSC and ACCC Actually Mean

These two ISO 20022 status codes are central to understanding settlement progression in Open Banking flows.

ACSC — AcceptedSettlementCompleted — indicates that debtor-side settlement has been completed. In practical terms, the payer-side payment movement has reached a completed settlement status. This is not the same as confirmation that the merchant has received the funds.

ACCC — AcceptedCreditSettlementCompleted — indicates that settlement has been completed on the merchant, or beneficiary, side. This is the point at which merchant-side settlement can be considered confirmed.

An important caveat: how these statuses are reported — and whether they are reported at all — depends on the payment rail, the banks involved, and the Open Banking provider’s implementation. Some banks may only report initiation. Others may report payer-side settlement, ACSC, but never send a separate ACCC signal.

The level of detail varies, and treating any single status as universally reliable across all implementations would be a mistake.

For reference, ISO 20022 maintains external code sets for payment status definitions here: ISO 20022 External Code Sets

A practical example of ACSC and ACCC status interpretation is also available here: Token.io — ISO 20022 Statuses

Mapping Internal Stages to ISO 20022 Statuses

The approach that proved effective: aligning internal operational stages directly with ISO 20022 payment statuses.

Payer-side settlement, ACSC, allows the platform to update internal records for monitoring. It is a useful signal that the payment has progressed, but it should still be treated as provisional from the merchant-side settlement perspective.

Merchant-side settlement, ACCC, where available, marks the point for final settlement confirmation and reconciliation.

With this mapping in place, operational teams gain clearer visibility into where each transaction actually stands. They can make decisions based on reported settlement status rather than assumptions.

Status Monitoring Across Payment Rails

Once status mapping is in place, it becomes possible to monitor the full lifecycle from initiation through to final settlement, flagging exceptions automatically.

This monitoring logic can be adapted to work across different payment rails, including schemes like Faster Payments and SEPA, though each rail has its own settlement timing, status granularity, and reporting conventions.

Cross-border transfers add another layer of variability. The key is building monitoring that accounts for these differences rather than assuming a uniform flow.

Automated exception detection is where the real operational value shows up.

Instead of a spreadsheet of pending transactions that someone reviews manually, each exception scenario triggers a specific workflow. Operations teams get alerts on the transactions that actually need attention.

How In-Flight Limits Reduce Financial Exposure

Beyond status monitoring, in-flight transaction limits provide a practical cap on exposure.

Count limits restrict the number of initiated but not yet settled transactions a payer can have open simultaneously. If a payer already has two transactions in progress, a third is held until one completes.

Amount limits cap the total value of in-flight transactions per payer. For example, a maximum exposure of $5,000 means any new transaction above that threshold waits until earlier payments settle on the merchant side.

These limits are tracked per payer using identifiers such as user ID, email address, account reference, or customer reference. This gives platforms clearer oversight of pending activity without blocking normal operations.

Handling Stale In-Flight Transactions

One pattern worth watching: a transaction that reaches payer-side settlement but never progresses to merchant-side settlement within the expected window.

This “stuck in the middle” state represents unresolved settlement exposure.

By combining in-flight limits with status-based monitoring, these cases surface automatically. If a transaction remains payer-settled but not merchant-settled for several days, it is flagged for review rather than sitting unnoticed in a queue.

What Changes When You Get This Right

The teams that build these controls do not just reduce the number of reconciliation exceptions. They change the operating model.

Settlement risk stops being something that surfaces retroactively through manual checks and starts being managed in real time, as payments move through the pipeline.

That shift matters most at scale.

A platform processing dozens of Open Banking transactions a day may be able to handle occasional mismatches manually. A platform processing thousands cannot afford to treat each one as a manual investigation.

Status-driven automation and in-flight limits turn settlement monitoring from a reactive cost centre into an operational capability that scales with volume.

For a detailed walkthrough of how this approach was applied in practice, including the specific operational outcomes, read the full case study here:

Reducing Settlement Risk with Open Banking Flows — Case Study