Selecting a Dollar Clearing Provider for Your Platform
Price and speed are the visible terms in a dollar clearing contract. For a platform holding money on behalf of thousands of clients, both sit downstream of four structural questions, and no spread or SLA repairs a wrong answer to any of them. Failed reconciliations, compliance gaps and a single point of failure under every client balance are structural outcomes, not service-level ones. An institution that earns from holding your clients’ money has a different interest in releasing it than one that earns from moving it.
The four questions a platform seeking to optimise it’s multi-currency clearing operation must ask four questions that run in dependency order:
- what the provider does with client money,
- whose name it sits in,
- how it reaches the beneficiary,
- and how your platform operates all three through one integration.
Does the provider lend against your clients’ funds?
Many clearing providers are, underneath, lending institutions. Client deposits sit on the provider’s balance sheet and are deployed into loans or investments. The model works until risk appetite changes or a credit event forces restrictions on access.
However, a non-lending, 100% reserve model holds client money in full and does not deploy it. The provider earns on services, not on the float. The funds are there because the architecture guarantees it, not because internal risk management happens to be working on any given day.
Lorum operates such a model: it is a correspondent institution for banks and fintechs, providing programmable access to global dollar clearing for platforms, named custody and treasury, on a non-lending, 100% reserve model.
Are accounts named, or pooled under your ledger?
The second question is whether each of your clients holds funds in an account registered in their own name, or whether every client’s money sits in a single omnibus account that only your internal ledger can divide.
Pooled accounts are simpler to open, and they move the entire burden of proof onto your records. When Synapse collapsed in April 2024, $265 million across 100,000 accounts was frozen because partner banks could not reconcile who owned what, and customer funds stayed inaccessible for months.
For a platform, the account structure is also the reconciliation primitive. Every payment received, every payout released and every currency conversion has to resolve to one identifiable client. Named accounts make that the resting state of the ledger rather than a matching exercise run after the fact, and the same structure is what protects the money: when a balance is held in the client’s own name, ownership never depends on your books being right.
Lorum provides named custody accounts as the default, each in the end client’s name with individual KYC and a direct contractual link between custodian and account holder. Accounts are opened through the API, which is what makes one account per client workable at platform scale rather than an onboarding queue. Segregation is architectural, not contractual.
Does the provider clear directly, or pass to a correspondent?
Dollar payments settle over Fedwire, CHIPS or ACH. SWIFT is not a settlement rail: it carries the instruction to whichever institution holds the account and performs the settlement.
The question is whether your provider clears into those systems through direct rail access, or passes the instruction to a correspondent that does. Each additional intermediary adds cost, latency, and a point at which the payment can be held for compliance screening you cannot see into. The same applies to currency execution: a conversion priced by an intermediary arrives as a rate you discover rather than a rate you agreed.
Lorum has direct access to local payment rails including Fedwire and ACH, clears in USD, EUR, GBP and AED, and converts at a firm institutional rate at the point of clearing. Because the movement and the conversion both settle into named accounts, each one resolves to a client at the moment it happens.
Does one API cover every currency your platform needs?
A platform clearing dollars through one provider, euros through another and sterling through a third runs three integrations, three onboarding processes and three reconciliation feeds. The sticker price on each can look competitive while the engineering and operations cost of maintaining all three sits outside the comparison.
Coverage is only half the question. The other half is whether one integration carries the whole operating cycle: opening an account for a new client, executing a conversion at a known rate, releasing a payout over a local rail, and returning a record that ties all three back to that client. An API that moves payments but cannot open accounts leaves the part that scales worst sitting in a queue.
With Lorum, a platform connects once. Accounts, conversion, payouts and reconciliation run through the same integration, and adding a market is a configuration change within it rather than a new banking relationship. No local entities, no bilateral banking relationship per jurisdiction.
Four answers eliminate more providers than a pricing comparison
The reserve question comes first because it is the only one of the four a provider cannot change later. Rails and currencies are additions to an existing integration. A lending model is the institution’s economics, and those are fixed. A provider whose revenue depends on holding client balances will always have a reason to release them a little later than your platform needs.
The account structure is the one that compounds, and the API is what makes it usable at volume. Together they decide whether your platform can prove, on any given day and for any given client, where the money is, what it converted at, and whose it is, without someone assembling the answer by hand.
