Bank API integration timeline for a stablecoin rail: the sandbox-to-production plan and who signs each gate

A realistic bank API integration timeline for a stablecoin settlement rail runs through five environments and six sign-off gates, and the gates matter more than the calendar. The phases are discovery and third party due diligence, sandbox connectivity, message and callback testing, key ceremony and security sign-off, user acceptance with a parallel run, and a controlled production pilot before general release. Each gate has a named signatory and an artefact that proves the phase was completed, and the plan is finished when the last gate is signed rather than when a date arrives. This article walks through each phase, the tests inside it, the artefacts it produces and who signs to leave it.

What has to be true before the sandbox is opened?

The first phase produces no code. It produces a scope document, a risk assessment and a vendor file. The scope document names which settlement flows are in the first release, for example pacs.008 received from the core banking system and paid out as a stablecoin transfer, or a stablecoin receipt off-ramped to a SWIFT payout, and which corridors, currencies and limits apply. Flows not named are out of scope, which keeps the test pack finite. The risk assessment is the new product assessment the bank already runs, extended with the digital asset specifics: custody model, chain and stablecoin acceptability, screening coverage and the regulatory position of the bank's supervisor as of the date of the assessment.

The vendor file follows the bank's third party risk management programme. In the United States, the interagency guidance on third party relationships issued in June 2023 sets the expectation that due diligence is proportionate to criticality, and a settlement rail is critical. The file holds the provider's regulatory registrations, independent assurance reports where they exist, information security questionnaire, financial standing and the contract with its service levels, data processing terms and exit provisions. Gate one is signed by the head of third party risk and the product owner, and it authorises the sandbox, nothing more.

What does the sandbox phase test?

Five environments are in play across the programme: the provider's sandbox, the bank's development environment, the bank's user acceptance environment, the provider's pre-production environment and production. The sandbox phase connects the first two. The work is credentials and plumbing: client certificates for mutual TLS, an OAuth client or API key held in the bank's secrets vault rather than in configuration files, IP allow-listing on both sides, a registered webhook endpoint with its signing secret, and agreed idempotency keys so that a retried request cannot create a second payment.

The tests in this phase are deliberately shallow: a health check, an authenticated call, a schema validation of a single pacs.008 inside a head.001 envelope, and a webhook received and verified. No value moves, and any wallet addresses used are test network addresses. The artefact is an integration design document showing data flows, trust boundaries and where secrets live. Gate two is an architecture review signed by the information security architect and the integration lead. It is the cheapest gate to fail and the most expensive to skip, because a design flaw found here costs a diagram and found in production costs an incident.

How are pacs.008 in and pacs.002 back actually tested?

Message testing runs in the bank's user acceptance environment against the provider's pre-production environment, and it is driven by a written test pack. Each case in the pack is a pacs.008 with a stated expected outcome, and the evidence for each case is the pair of messages plus the on chain transaction hash filed against the same UETR. The happy path is one case. The rest are the cases that will happen in production whether or not they were tested.

• Every mandatory element is exercised, including the debtor and creditor parties and accounts, the creditor agent, the interbank settlement amount and currency, the charge bearer and the UETR in the payment identification block.
• Every status the provider can return in a pacs.002 is provoked at least once, including accepted, accepted settlement in process, accepted settlement completed, pending and rejected with a reason code, and the bank's system is shown to handle each one.
• A pacs.004 return is triggered after settlement, and the return is shown to reference the original UETR and to post correctly to the bank's ledger.
• A duplicate UETR, a malformed envelope, an unsupported character set and an oversized remittance block are each submitted and rejected cleanly with a reason the operations team can read.
• A timeout and a retry are simulated so that the idempotency behaviour is proven, and a message received while the provider is unavailable is shown to queue rather than fail silently.
• Where MT103 is in scope, the mapping between MT103 fields and pacs.008 elements is tested in both directions, with truncation and character set differences recorded as known limitations.

The artefact is a test evidence pack: the pack itself, the message pairs, the hashes, the defects raised and their closure. Gate three is signed by the payments operations manager, who will live with the messages, and the quality assurance lead.

How are screening callbacks and holds tested?

Compliance testing is a separate phase because it has a separate signatory. The provider's screening runs at defined points, typically at onboarding of the client, at receipt of the instruction and before release of the on chain transfer, and each point can return a callback that holds, releases or rejects. The test pack provokes each outcome. A test client is onboarded through KYB with deliberately incomplete beneficial ownership to confirm the hold. A sanctions screening hit is triggered using the test entities that screening vendors publish for this purpose. A wallet screening hit is triggered against a test address flagged as high risk. A Travel Rule exchange is run with an IVMS101 payload for originator and beneficiary and the bank confirms it can store and retrieve it.

The most important case is the unhappy infrastructure case: the bank's callback endpoint is taken down and a payment that requires a compliance decision is submitted. The correct behaviour is that the payment holds until a decision is received. A rail that releases when it cannot reach the decision maker fails closed in name only. The compliance analysts also work the held items in the provider's compliance workbench, with a second analyst approving each release, so that four eyes control is proven rather than assumed. Gate four is signed by the BSA officer or chief compliance officer, and the artefact is the screening test evidence together with the written escalation procedure for hits in production.

The gate that gets skipped is never the message test. It is the one where somebody has to sign their own name under a control they did not build.

What happens at the key ceremony?

Two families of secrets are created before production: integration secrets and wallet keys. Integration secrets are the production client certificate, the API credential and the webhook signing secret, and they are generated inside the bank's vault with rotation dates recorded. Wallet keys are different in kind, because whoever controls them controls the money. Where the bank keeps custody of its operating wallet, the keys are generated in a scripted ceremony: a written script read aloud step by step, at least two witnesses, generation inside a hardware security module or a multi-party computation service so that no single person ever holds a complete key, a signing quorum defined for the operating wallet, sealed backups of recovery material stored in separate locations, and minutes signed by every participant.

The ceremony also fixes the operating controls that production will inherit: separation of the person who initiates a transfer from the person who approves it and from the system that signs it, a per transaction and daily spending limit on the operating wallet, and an allow-list of beneficiary addresses that can only be extended through the compliance process. The operating wallet is a till, funded for the day's expected payouts, not a vault. Alongside the ceremony, the penetration test of the integration is completed and its findings closed. Gate five is signed by the chief information security officer, and the artefacts are the ceremony minutes, the key inventory, the backup custody record and the penetration test closure report.

What do acceptance, parallel run and the pilot prove, and who signs go-live?

User acceptance testing puts business users, not engineers, in front of the system in the bank's acceptance environment. Operations staff process payments from the runbooks they will use in production, finance confirms the general ledger mapping, the suspense accounts and the end of day reconciliation of ledger to on chain balances, and the service desk rehearses the incident procedure. The parallel run then sends a sample of real instructions through the existing rail while shadowing them on the new rail, either on a test network or on the live network at nominal value, and reconciles the two outcomes for each UETR.

The production pilot follows with hard limits: a short list of named clients, low per transaction and daily caps, one or two corridors, daily reconciliation signed by finance, and a rehearsed rollback that reverts the routing to the legacy rail without touching the client's instruction format. Gate six is the go-live gate. It is signed by the head of payments as business owner, the chief compliance officer, the chief information security officer, the treasurer for liquidity and finality exposure, and the chief information officer for operational readiness, with internal audit attending as observer and the board or its risk committee notified. A post implementation review is scheduled at signing, and the limits are widened only after that review. That is the whole plan: six gates, six signatures, and a file behind each one.

Where StableNet fits

StableNet, built by SpendTheBits, is an API-first cross border settlement platform for banks, credit unions, licensed MSBs, exchange houses and remittance fintechs, and the plan above maps directly onto how it is integrated. The platform is ISO 20022 native: it accepts pacs.008 customer credit transfers inside head.001 envelopes, returns pacs.002 status reports and pacs.004 returns, carries pacs.009 for interbank legs, tracks every message end to end by UETR, and accepts and emits SWIFT MT103 where a bank is not yet on MX. Settlement completes in minutes in regulated stablecoins such as USDC and USDT on public blockchains, with on chain auditability, and the bank keeps custody of its operating wallet. KYB and KYC onboarding, KYT, sanctions and PEP screening, wallet screening, Travel Rule data in IVMS101 form and a compliance workbench with a tamper evident audit trail supply the callbacks and evidence each gate requires. SpendTheBits is a Bank of Canada registered payment service provider and a named finalist in the Swift Hackathon 2026 Technical Challenge.