Stablecoin Settlement Inside an Existing Treasury System

A group treasury pays suppliers and affiliates across borders through correspondent banking, where value dates are uncertain, intermediary deductions surface after the fact, and emerging-market corridors are the worst of both. The treasury management system where payments are raised, approved, released and reconciled has no view of anything that does not arrive as a bank statement. This pattern adds stablecoin settlement as another payment method inside that same system: the treasury raises and approves a payment as it already does, a licensed payment institution converts, screens and settles behind it, and balances reconcile back without a separate workflow.

It is possible now because one provider can hold both a PSD2 payment authorisation and a MiCA crypto-asset authorisation in the same jurisdiction, the combination the European Banking Authority pointed to on the overlap between payment services and crypto-asset services in e-money tokens. The corporate stays a client of that licensed provider and takes on no crypto-asset authorisation of its own. The first live corporate deployments were announced on 8 June 2026: Ledger runs automated supplier payments and Mantu runs cross-border intercompany settlement, both inside their Kyriba treasury system and executed by Fipto, a payment institution authorised by the ACPR and a CASP authorised by the AMF.

• Yes if you already run a TMS or treasury-capable ERP with multi-bank connectivity, you pay suppliers or affiliates across borders, and you have corridors where correspondent banking is slow or expensive.
• Not if you are a payment institution wanting to offer this to your clients - that is the same rail from the other side, and a different blueprint. Not if you have no treasury system to wire into. Not if the goal is yield on idle cash: MiCA prohibits paying interest on e-money tokens, and the honest destination for that demand is a fund unit, not a balance.

• DORA does not apply to an ordinary corporate treasury. It binds financial entities. Any provider or adviser implying a non-financial company owes DORA third-party obligations here is overstating - though if the payer is a bank, insurer or investment firm, the full regime does apply.
• The treasury-system layer has effectively one proven option. Only one treasury system was found with a named corporate running this in production. On any other system, expect to fund first-of-kind connector work and treat roadmap statements as roadmap.
• Supplier onboarding is the usual constraint, and it is slow. The corridor advantage depends on a beneficiary who can receive, which takes longer to arrange than the technical build.
• Accounting treatment is unsettled and jurisdictional, even for a balance held only in transit. That question belongs to the auditor and is worth raising early, well before year end.

• The company needs no licence. It is a client of a licensed payment institution executing its own payments, and it is not a provider of crypto-asset services to anyone. That keeps the work a treasury project, with no authorisation for the company to obtain.
• One provider holds both licences. Executing a payment is a payment service under PSD2; doing it in an e-money token also engages MiCA, and the workable answer in the market is one provider authorised on both sides in the same jurisdiction.
• The workflow stays in one system. The payment is raised under the existing approval matrix and segregation of duties, and it reconciles in the same ledger and the same report as every other method. No second tool, no parallel process, no new team.
• No keys, no wallet, no holding. The corporate never takes custody. The stablecoin serves only as a payment rail and never sits on the balance sheet as a holding, which keeps the accounting and disclosure question as small as it can be.