At a glance
A payment clearing API is a programmatic interface through which a platform opens accounts, receives funds, and sends payments on local payment rails such as Fedwire, ACH, SEPA, Faster Payments, and CHAPS, with one integration standing in for a direct relationship with each scheme. The API is the surface. What sits behind it decides whether a payment will settle when the platform says it will.
Key distinction: Two APIs can expose identical endpoints and deliver completely different outcomes, because clearing is a property of the institution operating the rails, not of the interface. Evaluating the API means evaluating the rail access, the account model, and the balance sheet underneath it.
This guide is for platforms choosing clearing infrastructure: fintechs and PSPs, payroll and EOR platforms, marketplaces, and trading platforms that need to move customer money across markets. It sets out what a clearing API does, the questions that separate direct access from a well-documented intermediary, and a checklist to run before signing.
What a payment clearing API does
A clearing API abstracts the schemes. Instead of joining Fedwire, CHAPS, or SEPA directly, each with its own membership criteria, message formats, and settlement accounts, a platform calls one set of endpoints and the provider carries the payment onto the right rail.
- Accounts. Endpoints to open accounts, in the platform's name or its customers' names, with local account details in each currency.
- Collections. Inbound funds arrive on those accounts and are surfaced as events with the originating rail, reference, and sender details.
- Payments. Outbound instructions are routed to the appropriate rail based on currency, amount, and urgency, and their status is reported until final settlement.
- Reporting. Statements, balances, and transaction data, ideally carrying the ISO 20022 fields that make reconciliation deterministic rather than heuristic.
Every provider describes roughly this surface. The differences are structural, and they show up in the five-layer stack of collect, hold, convert, clear, and pay out: which layers the provider actually operates, and which it resells.
The questions that decide settlement certainty
Rail access: direct or nested? Ask whether the provider has direct access to each rail it offers, or reaches it through further intermediaries. Nested access adds a balance sheet, a cut-off, and a counterparty to every payment. Ask for the list of rails with direct access by name: Fedwire, ACH, SEPA, SEPA Instant, Faster Payments, CHAPS, UAE IPP.
Account model: named or virtual? Ask whose name is on the account that holds customer funds. Virtual references on a pooled master account mean the customer exists in the provider's ledger and nowhere else. Named accounts mean the customer holds the account, with their own KYC and a direct contractual link to the custodian.
Finality: when is a payment actually settled? Ask how the API reports settlement, as distinct from acceptance or submission, and whether the status model is tied to the scheme's own finality. Settlement certainty is a known window, not a fast average.
Balance sheet: what happens to the funds between receipt and release? Ask whether the institution holding the funds lends against them. A lending balance sheet has a structural reason to release slowly; a non-lending, 100% reserve institution does not. This question is usually left out of API evaluations and it decides more than any endpoint.
Market expansion: what does adding a currency involve? Ask whether a new market is a configuration change inside the existing integration or a new banking relationship, a new entity, and a new contract. The answer reveals how much of the stack the provider owns.
Reconciliation data: can the ledger prove itself? Ask for end-to-end identifiers, ISO 20022 remittance fields, and statement endpoints that let a platform reconcile every movement to a customer without a manual matching step. Daily reconciliation is now a regulatory requirement for UK payment and e-money firms under the FCA's safeguarding regime, and the API either supports it or it does not.
Operations: is the API built for production? Idempotent payment creation, webhooks with retries and signatures, a sandbox that mirrors scheme behaviour including cut-offs and rejections, and published limits. These are table stakes, and their absence is a signal about the rest.
The evaluation checklist
| Question | What a good answer looks like | Red flag |
|---|---|---|
| Which rails do you access directly? | A named list of rails with direct access | "Through our banking partners" without names |
| Whose name is on the customer account? | The customer's, with individual KYC | A virtual reference on a master account |
| How do you report settlement? | Scheme-level finality with a known window per rail | "Completed" on submission |
| Do you lend against client funds? | No; 100% reserve, no rehypothecation | Yield sharing that depends on holding balances |
| What does a new market require? | A configuration change within the integration | A new contract and a new banking relationship |
| What reconciliation data do you expose? | End-to-end IDs and ISO 20022 fields on every movement | Free-text references and monthly statements |
| How is the API operated? | Idempotency, signed webhooks, a scheme-faithful sandbox | A sandbox that never rejects a payment |
What direct access looks like in practice
When the institution behind the API has direct access to the local rails and holds funds in named custody without lending, the evaluation questions collapse into one answer. Funds land on domestic rails in each market, sit in accounts the customer owns, and leave on domestic rails, all through a single integration. Adding a market is a configuration change, because the licensing and rail access already exist on the institution's side.
That is the model behind Lorum's multi-currency clearing: direct access to local rails globally, named custody accounts in each end customer's name, and treasury including wholesale FX, from one counterparty. The API is the way in. The institution is the reason the payment settles.
The infrastructure decision
A clearing API should be judged on what it cannot change: the rails it can reach, the name on the account, and the incentives of the balance sheet holding the money. Documentation quality matters, but a well-documented intermediary is still an intermediary. Infrastructure designed for clearing, not adapted from lending, is the property the checklist is really testing for.
Lorum is the correspondent institution for banks and fintechs. It provides programmable access to global clearing, named custody, and treasury, on a non-lending, 100% reserve model. For fintech and PSP platforms and digital platforms comparing clearing providers, the questions above are the evaluation, and the product pages set out how Lorum answers them.
Frequently asked questions
What is a payment clearing API?
A programmatic interface through which a platform opens accounts, receives funds, and sends payments on local payment rails such as Fedwire, ACH, SEPA, Faster Payments, and CHAPS, with one integration replacing direct relationships with each scheme.
How is a clearing API different from a payments API?
A payments API typically wraps card acceptance or a single provider's payout service. A clearing API gives access to the interbank rails themselves, with accounts, settlement status, and reconciliation data tied to the underlying schemes.
Which payment rails can be reached through a clearing API?
It depends on the institution behind it. Direct-access providers name the schemes: Fedwire and ACH in the US, SEPA and SEPA Instant in the euro area, Faster Payments and CHAPS in the UK, and UAE IPP in the Emirates, among others.
Does a platform need its own licence to use a clearing API?
The platform needs whatever authorisation its own activity requires, such as payment institution or e-money status. The clearing institution holds the scheme access and the licences to operate the rails and the custody accounts.
What matters most when comparing clearing APIs?
Three things the interface cannot change: whether rail access is direct, whether customer funds sit in named accounts, and whether the institution holding them lends against them. Everything else is documentation.
