[Suit Up]

HOME / WIKI / themes / Bank connectivity layer
Wiki entry · themesUpdated 2026-04-30

Bank connectivity layer


Catch up on this theme →

The bank connectivity layer is the translation tier between stablecoin and tokenised-asset rails on one side and legacy bank core systems on the other. It is the layer most banks need but few want to build, because the stablecoin stack was developed almost entirely outside traditional banking by fintechs, non-bank payment companies, and crypto-native firms, with no expectation that bank cores would integrate. Architecturally, the layer exposes stablecoin and tokenised-money operations (issuance, settlement, custody, on-and-off ramp) as APIs to bank cores while abstracting the on-chain mechanics. The general ledger sees deposits and withdrawals; the connectivity layer handles chain-side execution. For a tokenisation operator, the connectivity layer is the unglamorous piece that determines whether a bank can offer stablecoin and tokenised-asset capabilities at all without a multi-year core-system transplant. The vendors that occupy the layer (Fireblocks, Zerohash, BVNK, Quant Network, parts of Anchorage) are commercially crowded but architecturally critical.

Why the layer exists as a distinct category

Banks built core systems for double-entry deposit accounting, message-bank rails (SWIFT, Fedwire, RTGS), and intraday position management against central-bank reserve accounts. None of these systems natively understand a stablecoin transfer, a tokenised-deposit hop between chains, or a smart-contract settlement instruction. The integration work is non-trivial: address management, gas economics, chain reorganisation handling, omnibus-versus-segregated wallet design, and reconciliation between an on-chain ledger that finalises in seconds and a bank ledger that posts on a daily cycle.

The choices for a bank that wants to offer the capability are three. Build the integration in-house, which requires multi-year platform investment and crypto-native engineering talent the bank does not typically retain. Buy a horizontal connectivity layer from a vendor that has already done the work and exposes an API surface tested across many bank counterparties. Or partner with a regulated infrastructure provider (Anchorage, Zerohash, BNY's digital-asset platform) that holds the relevant licences and presents the bank with a single integration point. Most banks landing on the capability are choosing some combination of the second and third routes.

What the connectivity vendors actually do

The functional surface is the same across the major vendors with differences in licensing perimeter and product depth. KYC and identity orchestration: presenting bank-grade customer onboarding into chain-resident wallets. Custody integration: linking the bank's deposit accounting to wallets the connectivity layer either custodies directly or co-custodies with a partner custodian. On-and-off ramp: converting between fiat held in the bank's deposit franchise and stablecoin or tokenised-money instruments held on chain, with the conversion either internal to the connectivity vendor or routed through a third-party liquidity provider. Settlement orchestration: handling the chain-side execution of payments, collateral movements, or tokenised-asset transfers under instructions from the bank-side core. Reconciliation: matching on-chain events back to bank-ledger entries with timing and finality semantics that the bank's risk and operations teams can sign off on.

The vendors that have accumulated the broadest licence stack are the ones with the deepest moat. Zerohash holds money-transmission licences across the US states, a New York BitLicense, and a US trust charter; Anchorage holds a federal OCC trust-bank charter and is the only crypto-native firm to have completed the transition from conditional to final approval; Fireblocks has institutional-custody and treasury-orchestration licensing in multiple jurisdictions but is less full-stack on the bank-customer-facing layer. The licence stack is what allows a bank to embed the connectivity vendor's surface under its own product without acquiring the regulated activity itself.

The expansion path

A connectivity vendor that stops at fiat-to-stablecoin conversion is at risk of commoditisation. The expansion path that several vendors are pursuing extends into adjacent layers: on-chain lending integration (so the bank can offer tokenised-deposit-collateralised credit through the same surface), tokenised-asset settlement (so the bank can sit on top of a tokenised-securities issuance through Securitize, Tokeny, or an in-house platform), and stablecoin orchestration for corporate clients (so the bank can offer multi-stablecoin treasury management, FX between stablecoin pairs, and cross-border settlement under one API). Each of these expansions adds margin and ties the bank-vendor relationship more deeply, at the cost of competing more directly with custodians and asset managers higher up the stack.

The structural question is whether the connectivity layer remains a distinct category or whether one of the adjacent layers absorbs it. Three possibilities. Custody platforms (Anchorage, BNY Digital Asset Custody, State Street Digital) extend their surface down into bank connectivity, in which case the licence-stack moat collapses into the custodian. Core-banking modernisation vendors (Mambu, Thought Machine, Finastra) absorb the integration work, in which case the connectivity layer becomes a feature of the core. Or the layer persists as an independent category because the stablecoin-and-chain-side operating discipline is materially different from either custody or core banking. The current evidence is that the layer is persisting as independent, but the consolidation pressure is real.

APAC angle

The bank-connectivity layer in APAC has a structurally different shape. DBS runs an in-house programme (DBS Token Services, the DDEx custody stack, the Partior interbank rail) that internalises most of the connectivity surface a US peer would buy from a vendor. Standard Chartered has a similar pattern through Zodia Custody and Zodia Markets. HSBC runs Orion as the tokenisation platform. The structural reason is that APAC bank tokenisation programmes started earlier in the institutional cycle, before a deep vendor market existed, and the banks that committed have built rather than bought.

For a Western connectivity vendor entering APAC, the addressable bank set is narrower because the largest banks already have in-house equivalents. The opportunity is in the second-tier banks, the Singapore and Hong Kong subsidiaries of European GSIBs, and the corporate-client embedded-finance use cases where the bank needs to extend a stablecoin or tokenised-money capability without standing up its own platform. The cross-border wholesale connectivity layer (the tier sitting between Partior, Project Agorá, and any future mBridge successor) is a separate question and is mostly being built by the multilaterals rather than by commercial vendors.

Open questions

  • Whether tokenised deposits at scale (a JPMorgan-style bank-money model deployed by a second GSIB) shrinks the addressable connectivity-vendor opportunity by allowing banks to issue native bank money on chain without translating between two ledgers. The translation problem partly disappears if the deposit liability lives on chain to begin with.
  • Whether OCC trust-charter holders (Circle, Ripple, BitGo, Fidelity Digital Assets) extend down into bank connectivity, competing with Zerohash and Fireblocks for the same integration mandates.
  • Whether regulators (OCC, FCA, MAS) eventually mandate specific stablecoin-connectivity standards that consolidate the layer around a small set of compliant vendors. The standards work has not landed yet.
  • The agentic-commerce posture: whether connectivity vendors explicitly support AI-agent-controlled wallets as embedded customers of the bank-fronted product, and the KYC architecture that would imply.

Related

Weekly briefing

Sunday evening Singapore time. Importance-3 items, one deep dive, what's worth watching next.