Copper.co API integration: where off-exchange settlement breaks
On paper, off-exchange settlement looks straightforward: the asset sits in custody, the trade is executed on an exchange, and the transfer is closed at the end of the day.
In a live environment, everything rests on statuses — Copper.co API integration is considered complete only when confirmation has arrived from two independent sources: the custody register and the exchange's trading environment.
It breaks at the junction. A status-change notification arrives before the exchange has recorded the execution on its side, and a response to a request does not arrive within the allotted time.
The client retries the call — and without duplicate protection, a second operation for the same trade appears in the register. Then comes a stuck reconciliation: some positions are marked as open on both sides, others as closed only at the custodian.
The cost of such desynchronization is measured not in seconds but in risks. Counterparty and instrument limits are calculated from a stale balance, collateral does not reconcile with actual positions, and end-of-day reporting requires manual explanations.
Worst of all, the discrepancy is not visible in current controls until the first unreconciled balance.
We start with a trade state map: which transitions the API exposes, where confirmation arrives asynchronously, and where it has to be polled.
Then — call retries that do not create duplicates, scheduled automatic reconciliation of registers, and discrepancy analysis before they reach reporting. Below, we break down how this is closed.
What custodial storage and off-exchange settlement provide
Assets remain in a custody account rather than on the exchange's balance sheet: the trade is executed, but funds do not leave the custody environment until off-exchange settlement occurs.
The venue sees only the resulting position; keys and signing policies are not transferred to its side. Therefore, compromise of a trading account does not grant access to the asset itself — access can be stolen, but not withdrawal.
The effect is measured in operational metrics. The share of operations without manual intervention exceeds 90%: deposits, allocation, and withdrawal follow rules, and a human gets involved only in non-template trades.
Transaction reconciliation stops being a weekly task — positions are matched automatically by trade identifiers, and discrepancies surface the same day, not in the reporting period.
Withdrawal limits are set by policy, not by operator habit: an address whitelist, daily thresholds, and a mandatory second signature for amounts above a defined level.
This eliminates a whole class of failures — an erroneous address, withdrawal to an unverified wallet, a one-time loss when a single key leaks.
A separate scenario is exchange unavailability. When trading halts or withdrawals are suspended, assets are not locked: settlements continue across other venues, and emergency withdrawal from the custodian is performed under a pre-agreed multi-signature procedure.
We build Copper.co integration around these scenarios: API connection, matching internal accounting with custody identifiers, and a test environment with emergency procedure drills. The output is an access and threshold matrix that shows who can sign what.
Custody connection modes and settlement options
The connection mode determines where assets physically reside at the moment of a trade and who is responsible for moving them.
Direct integration with Copper.co via API settles through segregated addresses: every movement is signed and appears in the statement, and reconciliation is based on an external ledger.
A shared asset pool scheme reduces transfer costs but requires internal accounting that must reconcile with the custodian.
| Option | When it fits | Settlement constraints |
|---|---|---|
| Direct custody connection | Segregated accounting and audit per client are required | Waiting for network confirmations; some assets are unavailable for instant withdrawal |
| Shared asset pool | Many small trades; reducing transfers matters | Discrepancy between internal balance and custody after a failure is resolved manually |
| ClearLoop | Trading on a venue without withdrawing funds from custody | Not all assets and venues are supported; there are volume limits and a session window |
| Exchange wallet | Prototype, small volumes | Assets are on the venue's balance sheet; rollback only under its rules |
ClearLoop removes the main risk: the asset does not leave the custody environment; the venue receives only collateral confirmation.
Settlement is limited by the list of supported assets and the trading session time — if the connection between custodian and exchange breaks, an order may fail to settle.
Settlement constraints are defined by three things: the asset set, the session window, and the volume limit. We check the compatibility of each pair before integration begins; otherwise, the trade will have to be handled in another mode.
Implementation procedure: from audit to handover
ClearLoop moves settlement from the exchange into the custody environment: assets remain in the Copper.co account, the trading venue receives only an allocated limit, and netting is closed at the end of the window.
The cost of an error here is higher than in a conventional integration: an incorrectly designed allocation releases more than needed, and the discrepancy surfaces during reconciliation.
That is why the work proceeds in stages, and each stage ends with a verifiable artifact rather than a verbal agreement.
- Settlement scheme audit. We analyze how funds currently move between the custodian, exchanges, and internal accounting: who initiates transfers, where transaction traces remain, and which limits are set manually.
- Flow diagram. We assemble a map: subaccounts, allocations for each venue, order routing, residual return, and points where a break between custodian and exchange states is possible.
- Integration design. We determine which calls run in real time and which run in batches, how retried requests are processed without duplicates, and what confirms the reconciliation result.
- Access setup. We separate trading and withdrawal rights across roles, enable two-step confirmation, and configure logging and alerts for every action with a limit.
- Testing on small volumes. We run the full cycle — allocation, trade, return, netting — on minimal amounts, reconciling every position on both sides. Errors at this stage are cheap; in production they are not.
- Handover and support. We provide regulations, configurations, rollback procedure, and a set of metrics: reconciliation discrepancy, allocation confirmation time, and the share of rejected calls.
Describe your current settlement scheme — we will come back with an estimate and a stage plan.
Configurations, diagrams, and regulations: what remains with you
After implementation, you are left not with 'platform access' but with a working set of artifacts: using them, the on-call shift resolves an incident without contacting us, and a new engineer joins the project in days rather than weeks.
Everything is stored in your repository, secret storage, and knowledge base — with versioning and revision history.
- Connection configurations — environment parameters, a list of variables, and rules for storing signing keys: only in secret storage, with scheduled rotation.
- Access matrix — who is authorized to initiate a settlement transfer, who confirms with a second key, who sees only balances; API key permissions are limited by an address list and a set of operations.
- Fund flow diagram — the asset's path from deposit to off-exchange settlement: where it is held in custody, when it changes holder, and which events record this.
- Reconciliation regulation — what is reconciled with extracts and how often, the acceptable discrepancy threshold, and the escalation procedure when it is exceeded.
- Integration documentation — request and response contracts, error codes, idempotent keys, and a retry strategy for each failure scenario.
- Instructions for the on-call shift — step-by-step actions for a timeout, a rejected request, a stuck settlement, and key revocation, indicating whom to escalate to.
- Rotation and revocation procedures — key rotation without downtime, access deactivation when an employee leaves, and a handover checklist for another team.
We hand over everything with a walkthrough: we show which artifact is used to check what during a failure, and we record the owners of each regulation on your side.
Case study: off-exchange settlement without stuck operations
The client is a trading company that held collateral across several venues and reconciled custody and exchange account balances every morning. Reconciliation was done manually from extracts: 4–6 hours of work, and discrepancies surfaced only after the session opened.
Every twentieth settlement cycle stalled: some positions could not be closed until the next day, and this ran into risk limits.
What changed: settlement was moved off-exchange via Copper.co ClearLoop — assets remain in custody, and trades are closed through mirrored accounts without transferring collateral to the venue.
The integration was built on the API: each order has its own identifier, a retried request goes out with the same key, so a connection break does not create a duplicate trade or double debit.
States are pulled by events, and a discrepancy is caught at the moment it appears, not during the morning reconciliation.
Metrics before and after
| Metric | Before | After |
|---|---|---|
| Settlement close | 4–6 hours | 12–20 minutes |
| Settlement failures | 1 cycle out of 20 | none over a quarter of observations |
| Custody and exchange account reconciliation | manually, once a day | automatically, per event |
The class of reconciliation failures disappeared entirely: a discrepancy no longer survives until morning, because the position in custody and in the exchange account reconciles in a single event stream.
A separate effect is the log: for each settlement, the order, account, and status are visible, so incident analysis or an audit request is closed in minutes rather than days.
The integration case study shows the main point: the value here is not in the API connection itself, but in how retries, events, and boundaries of responsibility between custodian and exchange are designed. Describe your venue and asset scheme — we will come back with an estimate and a work plan.
How does integration via custody differ from exchange settlement?
In exchange settlement, client funds sit in an exchange account: to execute a trade, the asset must be transferred to an exchange address and held there until withdrawal.
While funds are on the exchange, they are subject to its rules — a compliance check can suspend withdrawal, delisting of a pair forcibly closes a position, and a technical failure leaves capital locked with no external access.
Off-exchange settlement works differently — this mechanism, in particular, is implemented by Copper.co: assets remain in the custodian's segregated accounts, the exchange receives only the right to execute the trade, and delivery occurs via transfer between wallets under the custodian's control.
Keys to the custody are not transferred to the exchange, so the risk of funds being blocked on the exchange side disappears, and withdrawal limits no longer affect settlement.
The difference shows up in operations.
In the exchange scheme, every movement is a separate transaction with manual confirmation and balance reconciliation, whereas in the custody scheme the API triggers settlement on an event, notifications return delivery status, and balance discrepancies are visible immediately.
This reduces the volume of manual operations and removes the window in which capital is outside your control.
Technical concerns: access, limits, resilience
Access rights, limits, and failure behavior are checked before the first settlement trade goes through ClearLoop. Below are the things that usually surface during Copper.co connection and require an architectural decision, not a post-launch fix.
How are access rights separated?
We issue keys per role, not 'for the entire service': the trading environment gets only order placement and cancellation, the reporting environment gets read access to balances and trade history, and we never give withdrawal rights to automation at all.
Each key is tied to fixed addresses, and rotation occurs with an overlap window — changing a key does not bring down a running service and does not require stopping settlement.
Which operation limits should be built in in advance?
Limits come in layers: request rate on the custody provider side, size and order-count limits at the exchange, and ClearLoop settlement windows.
We set up a request queue with rate control and retries, and spread batch operations over time — a spike in activity does not turn into limit rejections at the moment positions are closed.
What happens if the exchange or custodian fails?
Assets remain in the custody account, not on the exchange's balance sheet, so venue unavailability does not mean loss of access to funds. Each operation is marked with its own identifier: a retried request after a connection break does not create a duplicate trade.
When the connection is restored, state reconciliation starts automatically — discrepancies in positions and balances are visible in the report rather than being determined manually from statements.
Let's discuss the task and come back with an estimate and plan
So that the integration estimate is based on facts rather than assumptions, let's start with a focused conversation. Describe the task: which operations should go through ClearLoop, which teams work with the platform, and which systems are already connected to asset accounting.
It is useful to prepare:
- a list of scenarios — what goes to off-exchange settlement and what remains in custody;
- a list of participating systems: trading environment, internal accounting, reporting, risk control;
- access and segregation-of-duties requirements — who can initiate which operations;
- operating mode constraints: trading windows, reconciliation regulations, maintenance windows;
- monitoring preferences: which events and at what level of detail need to be visible;
- contacts on the platform and internal team sides so that time is not lost on approvals.
This is enough to come back with a work plan: stages of connection and checks, the procedure for moving to production, the composition of documentation to be handed over, and points where confirmation is required on your side.
We will provide the estimate as a range by stage and separately note what affects it — without hidden assumptions or 'hanging' items.
Describe the task in a convenient form: a brief description, a flow diagram, or correspondence with the platform team. That will be enough to discuss the details and come back with an estimate and plan.