Why an OTC settlement system falls apart on manual reconciliations
As soon as a trade leaves the exchange order book, settlement stops being a technical operation and turns into correspondence. The parties agree on the volume in a messenger, confirm it by email, and reconcile delivery manually against spreadsheets.
At that moment the OTC settlement system lives only in the operators' heads: neither party has a single source of truth about the trade's state.
Hence the divergence of ledgers. While one party records the asset as reserved for the trade, the other has not yet reflected the incoming credit, because every line goes through manual settlement reconciliation.
The discrepancy may be one transaction or a rounding difference — but that is exactly what leaves the trade hanging between delivery and payment, and no one can prove whose records are correct.
The price of such a scheme is the trade settlement time, measured in hours and days instead of minutes.
The wider the window between asset transfer and receipt of payment, the higher the risk of non-delivery of the asset: the counterparty recalls the transfer, the asset goes to the wrong place, and resolution turns into legal correspondence.
We examine how this is closed: what exactly is moved into software logic, how the "delivery versus payment" mechanism links both legs of settlement into a single indivisible operation, and why splitting keys between parties removes the question of trust in the counterparty.
What managed settlement delivers: speed, limits, failures
Managed settlement is when every OTC trade follows the same route: counterparty and limit checks, asset locking, delivery versus payment, multi-signature confirmation.
The effect of such settlement automation is visible not in presentations but in metrics taken before implementation and a month after.
Smart contracts run on the Ethereum network or in a closed perimeter — this is a choice driven by confidentiality and confirmation speed requirements, not by fashion. Below is a list of outcomes the client verifies on their own trade flow.
What to check in the impact report
- Settlement cycle time — instead of a manual chain of several days, you get hours: asset locking and delivery versus payment are executed in a single transaction rather than a series of approvals between counterparties.
- Counterparty limits — the check happens before the trade, not after it. An excess is rejected automatically rather than discovered at the reconciliation stage, when the assets are already in transit.
- Eliminated class of failures — data desynchronisation between the accounting system and the asset ledger no longer leads to "stuck" trades and manual investigations on both sides.
- Balance reconciliation — turns into a reconciliation of checksums across two ledgers rather than a read-through of statements: the discrepancy is found on your own side before the counterparty notices it.
- Share of trades without an operator — grows through standard structures; the team's time is freed up for non-standard ones, where a human still makes the decision.
Settlement options: from manual reconciliation to a trusted perimeter
The settlement scheme is determined not by the interface but by who holds the asset between trade confirmation and the final transfer.
With two or three counterparties, manual reconciliation of payment orders works, but every trade goes through correspondence, and a discrepancy in the payment details surfaces only after sending.
When there are dozens of trades, the bottleneck becomes the window between one party's transfer and the counter-delivery.
Five schemes occur in production — their limits of applicability are below.
| Scheme | When it fits | Where it hits a wall |
|---|---|---|
| Manual settlement via an intermediary | One-off trades, a narrow circle of counterparties | Manual reconciliation, no atomicity: one party transfers first |
| Conditional escrow with a third party | The parties do not trust each other, an arbiter is needed | The asset is locked, the third party is a point of failure and position disclosure |
| Multi-signature perimeter | A limited circle of participants, each with their own key | Thresholds and roles must be administered, losing a key blocks withdrawal |
| Settlement agent with netting of claims | Regular counter-flows, many trades | A trusted operator and full accounting of net positions are required |
| Hybrid settlement scheme | Accounting stays traditional, part of the assets are in the ledger | Two states must be reconciled, a discrepancy requires a rollback |
Moving from manual reconciliation to escrow and multi-signature removes the risk of a one-sided transfer but shifts the burden onto key and threshold administration.
A hybrid provides compatibility with current accounting if reconciliation and rollback are described in advance — otherwise a divergence between the two states costs more than a manual error.
Implementation stages: from trade audit to handover into operation
Implementing a settlement perimeter does not come "out of the box": trades have their own terms of recording, their own counterparties and their own confirmation procedure. First we analyse how you close trades now, and only then do we assemble the settlement scheme.
- Trade audit. We export the history for a period and tag it by type: where delivery versus payment applies, where there is partial execution, where settlement is still manual. The output is a register of scenarios with frequency and number of participants.
- Settlement scheme. We fix the moment when the asset is considered transferred and the payment is considered executed, how both legs of the trade are linked, and what to do in case of a discrepancy. The scheme becomes the reference for the code and the checks.
- Signer roles. We separate who initiates settlement, who confirms, who can cancel the operation; we set multi-signature thresholds by trade type rather than by a single rule.
- Perimeter assembly. We connect the settlement module to the accounting systems and the key store, and configure logging for every step.
- Testing on historical trades. We run closed trades through the new perimeter and compare them with the actual settlements. Failures are fed in separately: node unavailability, a signer's refusal, a resend.
- Handover into operation. We prepare documentation on the scheme and roles, train operators and the on-call shift, and fix the escalation and rollback procedure.
Handover package: procedures, keys, signature policies
Handover does not end at launch: a month later the client's team must be able to run settlements, change signature thresholds and investigate failures without our support.
That is why we document not a product description but working procedures — with roles, control points and a course of action for when something goes wrong.
- Settlement scheme — how the trade stages and asset locks are linked: DVP logic, finality points, conditions for transfer of title and actions in case of non-delivery.
- Signature policies and thresholds — key composition, the multi-signature scheme, the trigger threshold, signer roles and the rotation procedure without losing history.
- Settlement procedure — the order of operations on the trade date: who initiates, who confirms, which limits are checked before sending, where a discrepancy is escalated.
- Operation logs — which events are recorded, how they are matched against external statements and how long they remain available for investigation.
- Incident investigation procedure — failure classification, on-call roles, response times, criteria for halting settlement and restoring state from a backup.
- Operator instructions — checklists for routine actions: confirming a batch of trades, changing a threshold, suspending signature, escalation.
We agree the settlement scheme and signature policies with your risk and control roles and deliver them in your storage format. Two weeks after launch we review real operations: if a procedure is unviable, we fix it rather than adapting the team's work to it.
Case study: cut the settlement cycle and removed a class of failures
Before
The OTC desk closed large block trades via correspondence: terms were agreed in a messenger, confirmation went by email, and asset delivery and payment followed two independent branches.
A trade involved 6–8 manual steps: reconciling payment details, agreeing the rate, collecting the parties' signatures under the ISDA master agreement.
What we changed and what it became
The settlement cycle took from several hours to two days — the payment waited for the counterparty's confirmation, and the trader manually moved the terms from the correspondence into the register.
We assembled a settlement perimeter where terms are checked at the input, delivery versus payment is executed as a single trade, and both parties record the state in a shared log.
The treasury wallet was moved to multi-signature with role separation: the trader, risk control and treasury sign independently, and limits are set by policy.
Only order entry and the investigation of disputed cases remained manual — the share of operations without an operator grew to nine out of ten.
After launch the settlement cycle shrank from hours to minutes, and discrepancies during ledger reconciliation stopped occurring: reconciliation runs against a single source of state rather than two extracts.
The class of failures "the asset left, the payment did not arrive" is closed — both legs of the trade are recorded together, and a rollback is only possible in full.
How does delivery versus payment differ from escrow?
"Delivery versus payment" and conditional escrow solve the same task — preventing one party from giving up the asset without receiving the counter-value.
The difference lies in the design: in the first case both parts of the trade are executed in a linked manner, as a single operation; in the second, the asset is first locked with a third party and waits for the conditions to be met.
With linked execution, the contract checks both conditions in a single call and changes state atomically: either both delivery and payment go through, or nothing does.
The window in which one party has already given up and the other has not yet does not exist — settlement risk shrinks to a network failure rather than to counterparty bad faith.
Conditional escrow is built differently: the asset goes to a separate account and is frozen there until the stipulated events occur.
A time gap appears between locking and settlement, and with it the custodian's risk, the risk of a stuck asset and the question of who controls the keys. Usually this is a multi-signature scheme where execution is confirmed by an independent arbiter or by both parties.
Hence the different failure recovery schemes. With linked execution, a failure means the operation simply did not go through and the state has not changed — retrying it is enough.
In escrow the asset is already locked, so the return rules are written in advance: a timeout with automatic release of the lock, collecting additional signatures or resolution through an arbiter.
In OTC trade settlement, the choice is dictated by the nature of the assets. Linked execution works when both parts are recorded in the same environment and an atomic record is available for the operation.
Escrow helps when one leg lives outside it — in a register or with a settlement intermediary — and the time between locking and delivery must be used to verify the asset's origin and regulatory requirements.
Technical concerns: keys, failures, integration, liquidity
Five questions almost always come up before the first line of code — at the stage of designing the settlement logic. Below is how we answer them in the architecture, so that decisions do not have to be made at the moment of failure, when there is nothing left to change.
Who holds the signing keys and how is access restored?
The keys do not sit on the application server: signing is taken out to a hardware module, and access itself is split between several custodians under a threshold scheme — assembling the key requires a quorum of holders.
Losing one medium does not block settlement; recovery follows a pre-defined procedure with rotation.
What happens if the failure occurs on the counterparty's side?
The parties exchange step-by-step confirmations, so every trade is either carried through to the end in full or rolled back in full. A "debited but not credited" state does not arise, and the other party sees the exact status and is not left in uncertainty.
How does this fit with our accounting system?
We do not replace it. The settlement perimeter connects to the current accounting through an exchange layer where operations are reconciled by trade identifiers — the back office keeps working in its usual registers, and the blockchain part becomes a source of confirmed facts.
How is actual delivery confirmed?
Delivery confirmation is a separate event, not a side effect of debiting. Until a valid document is received from the receiving party, the asset is counted as in transit and the settlement part of the trade is not closed.
What happens to an incomplete trade?
It remains in an explicit intermediate status: either settlement is executed on the "delivery versus payment" principle, or both parties return to the initial state.
Incomplete and overdue trades are visible in a separate register indicating the step at which they stopped.
Let us discuss your settlement scheme and come back with an estimate
For the estimate of the settlement perimeter to rest on facts rather than general considerations, we need a set of source data on your scheme. We suggest discussing the task and assembling it together: we will clarify some points on a call, and you will send the rest afterwards.
- List of assets and settlement networks: which instruments, in what form they are recorded, where the keys are stored.
- Delivery versus payment scheme: the point at which both legs are recorded, who confirms, what happens in case of a discrepancy.
- Multi-sig roles and thresholds: the set of signers, the quorum, the procedure for key rotation and access recovery.
- Counterparties and limits: the circle of participants, the netting procedure, handling of partial execution.
- External systems the settlement perimeter exchanges data with: custodian, bank, accounting system, exchange formats.
- Reporting and audit requirements: which operation trails are needed, to whom and in what form they are provided.
- Constraints: access rights, the approval procedure, timelines, the handling regime for confidential data.
At the first meeting we will analyse where the scheme loses atomicity, how the confirmation thresholds are structured and what happens when the legs of a trade diverge.
After that we will come back with a staged work plan: the order of steps, dependencies on external systems, acceptance points and the scope of your involvement at each.