The B2B2B payments model: how a bank offers stablecoin-settled cross-border payments under its own brand

In a B2B2B payments model, a bank or credit union offers cross-border payments to its own business clients under its own brand, while a settlement provider moves value underneath in regulated stablecoins. The bank keeps the client relationship, the account, the KYB file and the price; the provider supplies the rail, the screening tooling and the ISO 20022 messaging, and never faces the client directly. Liability and compliance obligations split along the licence line: the bank answers to its client and its regulator, the provider answers to the bank under a service agreement. This article works through who owns what, how KYB and Travel Rule data flow, how the pricing stack is built and what the business client sees on screen.

Who owns the customer relationship in a B2B2B model?

The bank does, without qualification. The business client signs the bank's terms, holds a deposit account at the bank, logs into the bank's online banking or treasury portal and calls the bank's relationship manager when something goes wrong. The settlement provider is a vendor to the bank, disclosed in the bank's terms in the same way that a card processor or a wire bureau is disclosed, but it has no contract with the client and no authority to communicate with the client.

This has a practical consequence for the operating model. Every client-facing event, from a payment being held for review to a return arriving three days later, must reach the client through the bank's own channels. The provider's job is to emit a structured status event, for instance a pacs.002 status report carrying the UETR of the original instruction and a reason code, and the bank's job is to translate that into a notification the client understands. A bank that lets the provider's status page become the client's status page has quietly given away the relationship.

The credit union case is the same in shape. The member business signs the credit union's agreement, funds the payment from its share draft or business account, and receives the confirmation with the credit union's name on it. Where a credit union uses a corporate credit union or a sponsor bank for part of the fiat leg, that arrangement is also invisible to the member.

Who runs KYB, and what does the settlement provider see?

Know Your Business is performed by the bank under its own AML programme, whether that programme sits under the Bank Secrecy Act in the United States or under the Proceeds of Crime (Money Laundering) and Terrorist Financing Act administered by FINTRAC in Canada. The bank collects formation documents, beneficial ownership information, expected activity and the purpose of the cross-border payments, and it assigns the risk rating. None of that file is transferred to the provider. What the provider receives is a stable customer identifier issued by the bank, the customer's risk tier where the bank chooses to share it, and, on each payment, the originator and beneficiary data required for sanctions screening and the FATF Travel Rule.

The Travel Rule data deserves precision. FATF Recommendation 16 requires originator and beneficiary information to travel with the transfer, and for stablecoin legs that information is carried in IVMS101 form. The bank supplies the originator name, account or identifier and address; the beneficiary name and account; and the provider ensures the data is attached to the on-chain settlement and, where the counterparty is another regulated institution, exchanged with it. The bank's compliance team should be able to see exactly which fields left the bank, which is a data-flow diagram an examiner will ask to see.

• The bank performs KYB, beneficial ownership verification and risk rating, and keeps the file inside its own systems of record.
• The provider performs sanctions and PEP screening on each payment, wallet screening on the settlement addresses and KYT monitoring on the stablecoin leg, and returns the results to the bank.
• The bank makes the final decision on any hit: release, hold for enhanced review or reject, and records that decision in its own case management.
• The provider attaches Travel Rule data in IVMS101 form to each stablecoin transfer and retains the exchange records for the period the bank specifies.
• The bank files any suspicious activity or suspicious transaction report, because the reporting obligation belongs to the institution that holds the customer.

How do liability and compliance obligations split?

Liability follows the licence. The bank is liable to the client for the payment obligation: if a payment is late, misdirected or lost, the client's claim is against the bank under the account agreement and, in the United States, under Article 4A of the Uniform Commercial Code for wholesale funds transfers. The bank in turn holds the provider to a service agreement with defined service levels, an error-resolution procedure and an indemnity for losses caused by the provider's failure to follow the agreed controls.

Regulators treat the arrangement as a third-party relationship. In the United States, the 2023 Interagency Guidance on Third-Party Relationships applies, so the bank must show due diligence, contract review, ongoing monitoring and a documented exit plan for the provider. Under the Bank Service Company Act the provider's services to the bank can themselves be examined. In Canada, OSFI's third-party risk guideline places similar expectations on federally regulated institutions. The provider must therefore be prepared to give the bank its assurance reports, its incident history and its business continuity evidence, and the bank must keep a vendor file that an examiner can read without help.

Where the bank has no direct wallet relationship, the question of who holds the stablecoin during settlement needs an explicit answer in the agreement. The cleanest model is one in which the bank, or a custodian appointed by the bank, holds the settlement wallet and the provider only orchestrates transfers under the bank's policy. That keeps the bank in custody of client value at every step, which is the answer its regulator will want to hear.

The provider builds the road and paints the lines. The bank still drives, still holds the licence, and still answers for the passengers.

How is the service priced, and who keeps what?

The pricing stack has three layers. The provider charges the bank a wholesale price, typically a per-payment fee and a settlement or FX margin agreed in the service schedule. The bank sets a retail price to its client, usually a flat per-payment fee plus an FX margin over a reference rate, exactly as it prices a wire today. The bank keeps the difference. Because the stablecoin leg removes intermediary bank deductions, the bank can show the client a single all-in figure and a guaranteed beneficiary amount, which is a commercial advantage a correspondent chain rarely allows.

Two pricing decisions are worth making early. The first is whether the client pays for FX at the bank's rate or at a rate quoted by the provider at execution; the former keeps FX revenue at the bank, the latter simplifies operations. The second is how returns are charged. A pacs.004 return that comes back because the beneficiary account was closed carries a cost, and the bank should decide in advance whether that cost is absorbed, passed through or waived for the first occurrence.

What does the business client actually see?

The client sees a payment screen inside the bank's existing portal. It enters or selects a beneficiary, the amount and currency, and a purpose. It sees a quoted all-in cost, the amount the beneficiary will receive and an expected delivery time. After submission it sees a status timeline: received, screened, funded, settled, delivered. It receives a confirmation carrying a reference number, which is the UETR or a bank reference mapped to it, so that a query can be traced end to end. It never sees a wallet address, a chain name or a stablecoin ticker unless the bank chooses to expose them for its own reasons.

What the client also sees, if the bank has done the integration well, is faster confirmation of delivery than a wire provides, and fewer beneficiary short-payments. What it should not see is any change to its onboarding. The KYB file it already completed for the account covers the new service, with at most a supplementary questionnaire on expected cross-border activity and destination countries.

• A beneficiary form that captures the data the destination rail needs, such as an IBAN for SEPA or a routing number and account for ACH, rather than a generic free-text field.
• A quoted all-in price with the beneficiary amount fixed before the client confirms.
• A status timeline driven by structured messages, with a reason code translated into plain language when a payment is held or returned.
• A confirmation with a single reference number that the bank's operations team can trace through the provider's audit trail without asking the client for more.

What must be in the contract and the operating agreement?

The commercial contract and the operating agreement are different documents and both need attention. The commercial contract covers pricing, term, exclusivity if any, intellectual property in the client-facing interface and the branding rights. The operating agreement covers the controls: cut-off times per corridor, the screening lists in use and their update frequency, the escalation path for a hit, the service level for a pacs.002 status within a defined interval of submission, the return procedure using pacs.004, data retention periods, incident notification timelines and the exit plan, including how the bank retrieves its transaction history and Travel Rule records if the agreement ends.

A useful test before signing is to walk a single failed payment through both documents. A client sends a payment, sanctions screening produces a possible match, the bank places it on hold, the client asks what has happened, the match is cleared as false, the payment settles, and the beneficiary bank returns it because the account is closed. If every step in that sequence has a named owner, a message type and a timeline in the documents, the model is ready to launch. If any step has no owner, the client will find it first.

Where StableNet fits

StableNet, built by SpendTheBits, is a cross border B2B payment and settlement platform for banks, credit unions, licensed money service businesses, exchange houses and remittance fintechs, and B2B2B is one of its three commercial models: the institution offers the service to its own business clients under its own brand. Settlement runs in regulated stablecoins such as USDC and USDT on public blockchains, completing in minutes with on chain auditability, and customers keep custody, so client value stays with the institution throughout. The platform is ISO 20022 native, with pacs.008 credit transfers, pacs.002 status reports and pacs.004 returns tracked end to end by UETR, which gives the bank the structured events it needs for its own client notifications. Sanctions and PEP screening, wallet screening, KYT and Travel Rule data in IVMS101 form are built in, with a tamper evident audit trail for the vendor file. SpendTheBits is a Bank of Canada registered payment service provider and a named finalist in the Swift Hackathon 2026 Technical Challenge.