Open Banking Meets Crypto: Two Forces Together

Open banking and crypto are usually discussed separately, but together they describe a payment that starts in a regulated bank account and settles on a digital ledger. A customer could approve a payment in their banking app, the open banking interface could pass the instruction to a regulated payment firm, and that firm could convert the funds and settle them in a stablecoin to a supplier overseas. The customer sees one approval, while behind the scenes two systems, a bank ledger and a distributed ledger, must agree on the amount, the payee and the timing. The combination is attractive because each side fixes a weakness in the other. Open banking brings strong customer authentication, clear consent and a regulated account as the source of funds. Crypto brings instant settlement, weekend availability and lower cost for the cross border leg. A small business in London paying a 12,000 euro invoice to a supplier in Kenya could approve the payment on a Friday evening and see it settle the same night, instead of waiting for Monday and paying correspondent fees at each step. That is a real improvement for a business that lives on cash flow. The combined flow also creates new risks that neither world faces alone. The payment passes through more parties, including the bank, the third party provider, the crypto exchange or converter, and the wallet provider at the receiving end. If one party fails, the customer may not know where the money is. Custody is a key question. Who holds the stablecoins, who holds the private keys, and what happens if the wallet provider is hacked or goes out of business? A design must answer those questions in writing before the first live payment. Compliance must span both worlds as well. The bank checks the customer and the source of funds, the crypto firm screens the wallet address and the destination, and both must share enough information to satisfy anti money laundering rules without breaking data protection law. A sanctions hit on a wallet address must stop the payment, just as a sanctions hit on a bank account would. If the two screening systems use different lists or different matching rules, a risky payment can slip through the gap, so the firms must agree on a common standard. For architects, the combined model is a useful test of design discipline. The flow must have one clear owner, one reconciliation point and one customer view, even though several systems are involved. The product should show the customer the exchange rate, the fee, the settlement time and the refund route before they approve. A business analyst working on this design should map every handoff, name the party responsible for each one, and test the failure cases, including a failed conversion, a lost peg and a wallet that cannot be reached. Only then is the combination ready for real customers. Worked example with numbers: a small business in London pays a EUR 12,000 invoice to a supplier in Kenya, and the combined flow starts with the customer approving EUR 12,000 in the banking app, the open banking interface passing the instruction to a regulated payment firm, and the firm converting EUR 12,000 to a US dollar stablecoin at a rate of 1.08, giving USD 12,960, less a conversion fee of USD 25, so USD 12,935 reaches the supplier wallet. The supplier converts the stablecoin to Kenyan shillings at the local rate, and the whole payment settles in under an hour, while the traditional route would take two days and cost around EUR 40 in correspondent charges. The business saves time and money, but must accept the exchange rate risk during the hour the payment is in flight. Failure and recovery: the combined flow fails at its handoffs, and each handoff needs its own recovery. If the bank API is down, the payment never starts, and the customer must be told to try again or use a card. If the converter fails after the bank has debited the account, the funds sit in the converter account, and the payment firm must either complete the conversion or return the funds to the customer account, which takes a day. If the wallet address is wrong, the stablecoin goes to an address nobody controls, and it cannot be recalled. The recovery for each failure must be written down before launch, with a named owner and a time limit. For a business analyst, product owner or subject matter expert, the combined model requirement must map every handoff, name the party responsible for each step, and state the reconciliation point where the bank leg and the ledger leg are matched. The requirement must show the customer the exchange rate, the fee, the settlement time and the refund route before approval, because a customer who approves without seeing those facts cannot give informed consent. The design must have one clear owner, one reconciliation point and one customer view, even though several systems are involved, and the test pack must include a failure at each handoff. Source: PSD2; Bank for International Settlements; last reviewed 7 November 2026.