DEV Community: Tresori

What Peko and Kalp Just Validated About SME Infrastructure

Tresori — Wed, 17 Jun 2026 07:09:50 +0000

In Dubai on 14 June 2026, Peko and Kalp Digital Infastructure Corp signed a Memorandum of Understanding to embed Kalp’s full digital infrastructure stack beneath Peko’s all-in-one business platform. Peko runs the invoicing, payments, payroll, and operations for tens of thousands of small and medium enterprises across the UAE, Saudi Arabia, and India. The partnership will bring institutional-grade digital infrastructure — permissioned distributed ledger technology, programmable digital cash, a digital-asset wallet and key-management environment, tokenization, and agentic commerce — to those SMEs through the platform they already use.

Read as a news item, it is a notable partnership announcement.

Read as a structural signal, it is the most important MENA SME infrastructure deal of 2026 so far.

What Peko and Kalp just validated is a specific go-to-market model — institutional digital infrastructure delivered embedded and white-labelled beneath trusted SME platforms, rather than as a standalone consumer-facing product. The model has been the right answer in emerging markets for at least two years. Until now, it did not have its marquee MENA SME deal.

What does the Peko-Kalp partnership actually do?

Peko will integrate Kalp’s full digital infrastructure stack — permissioned distributed ledger, programmable cash rails, wallet and key-management infrastructure, agentic commerce, and tokenization — beneath its platform, delivering on-chain finance capabilities to SMEs and the institutional partners that distribute Peko across the UAE, Saudi Arabia, and India.

Peko will integrate Kalp Digital Infastructure Corp’s full digital stack beneath its platform. The capabilities will reach Peko’s direct SME customers and the institutional partners that distribute Peko on a white-label basis: banks, free zones, government entities, telcos, payment aggregators, and e-commerce providers across the UAE, Saudi Arabia, India, and other markets.

Peko is not a small fintech. Founded in 2022 and headquartered in Dubai, the platform offers more than 50 integrated services through a single interface — from invoicing and payments to payroll, corporate cards, company formation, corporate travel, and insurance. In December 2025, International Holding Company (IHC) acquired a majority stake to support continued growth. Peko is deployed both directly to SMEs and white-labelled to the banks and ecosystem enablers that serve those same SMEs.

Kalp Digital Infastructure Corp is an engineering company that builds the digital infrastructure beneath such platforms. Its stack includes a permissioned distributed ledger, programmable cash rails for smart and conditional payments, a digital-asset wallet and key-management environment, agentic commerce infrastructure for AI-agent-initiated transactions, tokenization and asset-lifecycle capabilities, and the APIs and SDKs that allow all of this to embed invisibly into third-party platforms.

The MoU establishes a phased rollout. The companies will first jointly evaluate integration architecture, security, and the commercial model — then introduce capabilities to Peko’s ecosystem progressively, scaling across the UAE, Saudi Arabia, India, and other markets, and extending to the institutional partners that already distribute Peko.

Key Takeaway: The Peko-Kalp MoU is a stack-level integration between an SME super-platform with 50+ services and cross-region distribution, and an on-chain finance infrastructure provider. The phased rollout starts with architecture and commercial evaluation before scaling to Peko’s full institutional partner network.

Why is the embedded model winning for SMEs?

SMEs do not want another standalone fintech app. They want their existing platforms — the ones they already trust to run their day-to-day operations — to be smarter. Embedded infrastructure delivers institutional-grade capability without forcing SMEs to navigate another vendor relationship, learn another product, or trust another brand. The platforms that already have SME distribution win when they upgrade what is underneath.

The Peko-Kalp model is not new in spirit. It is how Stripe acquired Bridge for $1.1 billion in 2024 and then rolled out stablecoin financial accounts across more than 100 countries — Stripe did not become a crypto company; it absorbed the stablecoin infrastructure beneath its existing payments product.

It is how Yellow Card, after processing over $3 billion in stablecoin transactions in 2024 across more than 20 African markets, shut down its retail business in October 2025 and pivoted entirely to selling stablecoin infrastructure to other businesses. The durable opportunity sits behind the brand, not in front of it.

**What is distinctive about Peko-Kalp is the structure: a stack-level **integration with a platform that already has cross-region SME distribution, sealed with a Memorandum of Understanding and a phased commercial roadmap. The deal makes the embedded model explicit for an SME context that has been historically underserved by both consumer-facing crypto products and traditional financial infrastructure.

The SME problem is specific. An SME running a manufacturing business in Sharjah, a trading company in Jeddah, or a software services firm in Bengaluru does not have the time, the team, or the inclination to evaluate a stablecoin payments product, a tokenization platform, an agentic commerce service, and a key-management environment as four separate vendor decisions. They have a platform. The platform either does what they need or it does not.

Peko’s bet, after this MoU, is that it will.

Key Takeaway: The embedded infrastructure model wins in SME markets because distribution already exists at the platform level. Standalone fintech products require SMEs to discover, evaluate, and trust a new vendor. Embedded on-chain finance requires none of that, the capability arrives through the platform the SME already uses.

What does the wallet and payment infrastructure layer actually do?

The wallet and payment layer is the part of the Kalp stack that turns the underlying distributed ledger into usable stablecoin payments — wallet creation, custody, key management, transaction routing across blockchain networks, and the policy controls that make institutional flows safe. This is the layer most SMEs touch first, because it is the one that handles the actual money movement. In the Kalp stack, this layer is powered by Tresori.

A permissioned distributed ledger and a tokenization engine are powerful primitives. But for an SME doing a cross-border supplier payment from Dubai to Mumbai, the primitive itself is invisible. What matters is whether the SME can:

Generate a wallet that securely holds dollar-pegged stablecoins like USDC or USDT.
Route a payment across the right blockchain network to optimize cost and settlement speed.
Comply with multi-jurisdictional rules — the UAE’s VARA framework, India’s regulatory regime, and KSA’s SAMA approach.
Settle payments in seconds, with recipients seeing local-currency value in their account.
That is the wallet and payment layer. Without it, the distributed ledger is theoretical. With it, the SME has a working infrastructure.

Tresori, the wallet and payment infrastructure piece of the Kalp stack, is built specifically for this layer. It abstracts the multi-chain complexity, handles MPC-secured institutional-grade custody, and provides the policy engine that lets banks, free zones, and other Peko white-label partners impose their own compliance rules on top — without rebuilding the underlying infrastructure. The architectural assumptions map to MENA and Indian flow patterns: corridor-by-corridor compliance, multi-chain routing across the networks where SME stablecoin volume lives, and the fast finality that cross-border B2B payments require.

This is what gets delivered to SMEs through Peko, embedded under whichever brand they already know.

What does this mean for the next wave of MENA and Indian SME infrastructure?

The Peko-Kalp model is portable. Any platform with SME distribution — banks, telcos, accounting software, e-commerce providers, free zones, government entities — can become a distribution channel for institutional-grade digital infrastructure simply by embedding the right stack. The next 18 months will see more deals of this shape. The companies that move first will define the category before competitors catch up.

Three implications worth watching.
First, the regulators. The UAE’s VARA, DFSA, FSRA, and CBUAE are now operationally clear on stablecoins and digital assets to a degree that was not true 24 months ago. Saudi Arabia’s SAMA has signaled increasing openness. India’s regulatory regime, while complex, has carved a workable path for B2B blockchain infrastructure even where retail crypto remains restricted. The regulators have done enough to make embedded SME infrastructure deployable. The remaining work is a builder question, not a regulatory one.

Second, institutional partners. Banks, free zones, and government entities that distribute Peko on a white-label basis now have access to the full Kalp stack through that same channel. A free zone authority can offer member SMEs programmable payments under its own brand. A bank can offer corporate tokenization services without building engineering. A government entity can deliver agentic commerce capabilities to its supplier ecosystem without picking a vendor for each component. The unit of distribution changes from “one bank, one fintech product” to “one platform, full stack.”

Third, the SMEs themselves. Historically, the companies that benefit most from this kind of infrastructure had to build technological awareness before they could decide to adopt it. With the embedded model, awareness becomes optional. SMEs get the capabilities through platforms they already trust — and the capabilities work the same regardless of whether the SME understands what is underneath.

The Peko-Kalp partnership is not the only deal of its kind that will be announced this year. It is the marquee one for MENA so far. The next will follow.

FAQs:

What is the Peko-Kalp partnership?

Peko, a UAE-based all-in-one business super-platform that serves small and medium enterprises across the UAE, Saudi Arabia, India, and other markets, signed an MoU with Kalp Digital Infastructure Corp on 14 June 2026. The MoU establishes a strategic collaboration to embed Kalp’s full digital infrastructure stack — permissioned distributed ledger technology, programmable cash rails, wallet and key-management infrastructure, agentic commerce capabilities, and tokenization — beneath Peko’s platform. The capabilities will reach Peko’s SME customers directly and the institutional partners that distribute Peko on a white-label basis: banks, free zones, government entities, telcos, payment aggregators, and e-commerce providers.

What infrastructure does Kalp provide?

Kalp Digital Infastructure Corp builds the digital infrastructure that sits beneath business and commerce platforms. The stack covers six components: a permissioned distributed ledger, programmable cash rails for conditional and automated payments, a digital-asset wallet and key-management environment, agentic commerce infrastructure for AI-agent-initiated transactions, tokenization and asset-lifecycle capabilities, and the APIs and SDKs that allow all of it to embed into third-party platforms. The model is white-label by design — Kalp’s technology surfaces under partner brands rather than as a standalone product.

Where does Tresori fit in the Kalp stack?

Tresori is the wallet and payment infrastructure layer of the Kalp stack. It handles institutional-grade custody, key management, multi-chain routing across blockchain networks, and the policy engine that lets enterprise partners impose their own compliance rules on top of the underlying infrastructure. In the Peko-Kalp partnership, Tresori is what makes the stablecoin and payment side of the integration work for SMEs — converting the underlying distributed ledger primitives into usable wallets and payments at the corridor, jurisdiction, and chain level that SME flows require.

What does this partnership mean for SMEs in MENA, KSA, and India?

SMEs across the UAE, Saudi Arabia, India, and other Peko markets will get access to institutional-grade digital infrastructure — programmable payments, tokenization, digital-asset wallets, and agentic commerce — through the Peko platform they already use, or through the bank, free zone, or government partner that distributes Peko on a white-label basis. SMEs will not need to evaluate a separate vendor for each capability. The infrastructure arrives embedded in the platform they already trust.

Why does this matter beyond just two companies?

The partnership validates a specific go-to-market model: institutional-grade digital infrastructure delivered embedded and white-labelled beneath SME-facing platforms, rather than as a standalone consumer-facing product. The same model has been winning across emerging markets — Stripe’s acquisition of Bridge, Yellow Card’s pivot to B2B infrastructure, Flutterwave’s blockchain selection. The Peko-Kalp deal is the first marquee MENA SME version of it. More deals of this shape will follow over the next 18 months as banks, free zones, governments, and other ecosystem enablers in the region recognize that distribution at SME scale is now available through the embedded stack rather than through standalone fintech products.

Africa’s Stablecoin Infrastructure Problem is Not Adoption — It’s Rails

Tresori — Tue, 02 Jun 2026 08:47:54 +0000

The story that has been told about stablecoins in Africa for the last three years is the story of a chart. It goes up and to the right. Sub-Saharan Africa received over $205 billion in on-chain crypto value between July 2024 and June 2025, a 52 percent year-on-year jump. Nigeria alone received $92.1 billion, nearly three times the total of second-place South Africa. Stablecoins now account for approximately 43 percent of Sub-Saharan Africa’s total crypto transaction volume. The numbers are real, and they are reported faithfully every quarter, and they have produced an industry-wide consensus that the African stablecoin opportunity is fundamentally a story about consumer adoption catching up to a product that finally works.

It is not.

The adoption is already here. The infrastructure underneath it is what isn’t. And the gap between the two — the gap between what users are doing on* stablecoin rails* and what the rails themselves can actually carry — is now the single most consequential bottleneck in African on-chain finance. Most strategic capital being deployed into the space is being deployed against the wrong problem.

Has stablecoin adoption in Africa happened yet?

Yes. Adoption has already happened, and the numbers say so without ambiguity. Sub-Saharan Africa took in over $205 billion in on-chain volume between July 2024 and June 2025, stablecoins are 43 percent of that volume, and the IMF estimates regional usage at 6.7 percent of GDP — one of the highest rates globally.

It is worth being precise about what the data is saying. The growth in African stablecoin volume between 2023 and 2025 is not a forecast. It is a record. In March 2025 alone, monthly on-chain volume in Sub-Saharan Africa reached nearly $25 billion, a clear outlier during a month when most other regions experienced declines. That spike was driven by a specific event — a naira devaluation in early 2025 that pushed Nigerian users into dollar-pegged assets at speed — but the structural story sits underneath the spike. Stablecoin behavior in the region is increasingly tied to high-value transactions linked to trade flows between Africa, the Middle East, and Asia.

That is not retail speculation. That is B2B settlement happening on rails that nobody designed for B2B settlement.

The global pattern around it is consistent. B2B stablecoin payments rose 733 percent year-over-year and now account for roughly 60 percent of global stablecoin payment volume. Monthly B2B stablecoin volume rose from under $100 million in early 2023 to over $6 billion by mid-2025. The IMF, in a 2025 Working Paper, estimated that stablecoin usage across Africa and the Middle East represented approximately 6.7 percent of total regional GDP in 2024 — one of the highest adoption rates globally.

When usage reaches 6.7 percent of GDP, the conversation about whether people will use the thing is over. The interesting question, the one strategic capital should be asking, is what is carrying that volume — and whether it can carry the next ten times of it.

What sits beneath the wallet layer in African stablecoin infrastructure?
A stack of custody, key management, policy, and compliance components that almost every African fintech has assembled internally because mid-market infrastructure for them has not existed. Consumer-facing companies sit on top of this layer. The layer itself is largely unbuilt as a market.

What is carrying African stablecoin volume today is a mix of consumer exchanges, on-and-off-ramp providers, and a handful of payment-layer fintechs that have stitched together correspondent relationships, custodial wallets, and bilateral integrations into something resembling rails. Companies like Yellow Card, Flutterwave, and Onafriq joined Circle’s new Payments Network in 2025 as design partners, bringing critical on-and-off-ramp infrastructure and access to over 500 million mobile wallets to the network. Flutterwave’s CEO told the World Economic Forum in early 2026 that the company is now building stablecoin rails on top of its existing fiat infrastructure, citing B2B payment costs as low as 0.5 percent on stablecoin rails compared with 1.5 percent on traditional ones.

This is real, and it works, and it is also not the bottom of the stack.
What sits beneath Yellow Card, Flutterwave, Onafriq, and the dozen smaller payment-layer companies operating in the region is a custody, key management, policy, and compliance layer that, in almost every case, has been assembled internally — by engineering teams who would much rather have been building product. The wallet is the visible part. The thing that signs the transaction, holds the key shards, applies the policy, screens the counterparty, records the audit trail, and survives the security review is the invisible part. And in Africa specifically, the invisible part is what has been holding the consumer-facing growth together with engineering effort that does not scale.

This is the layer that the industry has not built. It is also the layer that determines whether the next phase of growth happens at all.

Why is correspondent banking no longer a viable fallback for African payments?

Because the global banks that anchored it are leaving. Active correspondent banking relationships have declined 22 percent worldwide since 2011, and Barclays, Standard Chartered, Société Générale, and BNP Paribas have each exited major African corridors between 2022 and 2026.

The reason this matters now, and did not matter as urgently three years ago, is that the alternative — the correspondent banking system that Africa-to-the-world payments have run on for fifty years — is in a state of measurable retreat. The number of active correspondent banking relationships worldwide has declined by 22 percent since 2011, with the country-level declines ranging from 23 percent in advanced economies to 41 percent in small island developing states. The retreat from Africa in particular is documented and ongoing. Barclays completed its century-long African exit in 2022. Standard Chartered divested across Angola, Cameroon, Gambia, Sierra Leone, and Zimbabwe between 2022 and 2025, and confirmed a full exit from Botswana in early 2026. Société Générale divested its Moroccan and Algerian interests in 2024–2025, and BNP Paribas shut down its South African investment arm in 2024.

Press enter or click to view image in full size

This is the kind of cost that is easy to absorb because it has always been there, until suddenly it isn’t. The ECB has noted that average remittance costs to Sub-Saharan Africa remain at 7.7 percent, with the global Sustainable Development Goal target of 3 percent still far from being met. The CEPR has shown, using firm-level data, that when a firm’s main bank loses a correspondent relationship, the probability of exporting falls by 9.7 percentage points on average, and small firms see total exports decline by 42.7 percent.

What this means in practice is that for a growing portion of African

trade, the question is no longer whether stablecoin rails are better than correspondent banking. The question is whether they are available in the corridor at all. Where they are, businesses use them. Where they aren’t, businesses lose export volume.

What does “building the rails” mean in concrete terms?

It means owning six distinct layers — consumer interface, payment orchestration, custody, policy engine, compliance, and settlement network. In Africa, the top two layers have credible vendors. The middle three have almost none, which is the mid-market gap.

The term “rails” gets used loosely in this conversation, so it is worth being specific about what is on the list and who is responsible for each layer.

Press enter or click to view image in full size

Every African fintech serious about stablecoin volume has had to assemble the middle three layers — custody, policy, compliance — internally, because the existing options were built for a different market. Fireblocks was built for institutional desks in New York and London with four-month integration cycles and seven-figure annual contracts. Privy, now part of Stripe, was built for consumer-facing Web3 apps that did not need a policy engine or institutional-grade compliance. Both work for what they were built for. Neither was built for a Series B Nigerian fintech with a CFO watching the burn and a CISO with a SOC 2 audit on the calendar.

This is the mid-market gap, and in Africa it is not a gap in features — it is a gap in whether the rails exist at all for the companies trying to use them.

Why is most stablecoin capital going to the wrong layer of the stack?

Because consumer-facing companies are legible to fintech investors and infrastructure companies are not. Wallets and on-ramps pattern-match to mobile money. The custody-policy-compliance layer beneath them looks like enterprise sales, which is harder to underwrite — so it gets underfunded.

Join The Writer's Circle event

The fundraising data shows where the industry’s attention is. Most African stablecoin-adjacent capital in the last twenty-four months has flowed to consumer-facing on-and-off-ramps and to payment orchestrators sitting one layer above the rails. Both are valuable. Neither is the bottleneck.

The reason is partly that consumer-facing companies are legible to investors who came up in fintech and pattern-match stablecoins to mobile money. The chart on the slide is volume, and the volume is real, and the company telling the story is the one the user opens on their phone. Infrastructure companies — the ones building the layer below the layer everyone else is looking at — are harder to underwrite because their customers are other companies and their growth looks like enterprise sales rather than user acquisition.

This is the familiar pattern of infrastructure markets. The companies that get funded first are the ones building the visible parts. The companies that get funded next are the ones building the parts that turned out to be load-bearing. Stripe is now worth what it is worth not because it built a checkout button — many companies built a checkout button — but because it built the unglamorous layer beneath, the part where compliance, routing, fraud detection, and reconciliation happen.

Africa’s stablecoin infrastructure is currently in the first phase of that cycle. The checkout-button equivalents — the wallets, the on-ramps, the orchestrators — have been built and are growing. The Stripe-equivalent layer — the configurable, compliant, programmable rails that everything else depends on — has not.

What changes for African stablecoin builders in the next eighteen months?

Three forces converge: demand keeps growing, the GENIUS Act and MiCA harden compliance requirements, and Visa and Mastercard move stablecoins into core settlement. Fintechs whose rails are already production-grade survive the shift. Fintechs whose rails were assembled in a sprint will not.

Three things are now true at the same time, and the convergence is what makes this moment different from the moment a year ago.

First, the demand is real and growing. The 52 percent year-on-year growth in Sub-Saharan African on-chain volume is not driven by speculation; it is driven by Nigerian fintechs replacing correspondent banking, by Kenyan logistics companies paying trucking partners daily, by Ghanaian agricultural businesses receiving payment from European buyers on shipment confirmation. The use cases are mundane, which is exactly what makes them durable.

Second, the regulatory frame is solidifying. The GENIUS Act in the United States, MiCA in Europe, and the Virtual Asset Service Provider regimes now being implemented across Ghana, Nigeria, South Africa, and Kenya are converging on a model that treats stablecoins as regulated payment infrastructure rather than as crypto-adjacent assets. The GENIUS Act requires stablecoins to be fully backed by liquid assets and mandates regular public disclosures of reserves; in the UK and Hong Kong, issuers face increasingly strict transparency and audit requirements. This is good news for fintechs building on stablecoin rails — but only if the rails they build on can produce the audit trails, sanctions screening, and Travel Rule compliance the regulation demands. Most internally-assembled stacks cannot.

Third, the institutional players have stopped waiting. On March 3, 2026, Visa and Bridge announced an expansion of their stablecoin-linked card program to over 100 countries; SoFi and Mastercard partnered to allow the SoFiUSD stablecoin to be used for settlement across Mastercard’s global network. Yellow Card’s partnership with Mastercard, announced in 2026 and piloting across Ghana, Kenya, Nigeria, South Africa, and the UAE, is the African expression of the same shift. When Visa and Mastercard — networks that together process over $14 trillion annually — start integrating stablecoins into core settlement, the question for every other player in the system becomes whether their infrastructure can keep up.

The fintechs that win the next eighteen months in Africa will be the ones whose rails are already production-grade when the volume arrives. The ones whose rails were assembled in a sprint will spend the next eighteen months trying to refactor while shipping, and most of them will not make it.

What question should replace the adoption question?

What does the layer beneath the wallet need to look like to carry what the people are already doing? It is a more technical question, and a less marketable one, and it is the question whose answer will determine which African fintechs are still operating at scale in 2030.

The question that has driven African stablecoin strategy for three years is: how do we get more people to use stablecoins?

That question has been answered by the market. The people are using them.
The question that should drive the next three years is: what does the layer beneath the wallet need to look like to carry what the people are doing? It is a more technical question, and a less marketable one, and it is the question whose answer will determine which African fintechs are still operating at scale in 2030.

This is on-chain finance — the category Tresori is building infrastructure for — and the African opportunity inside it is no longer about persuading users to adopt the rails. It is about whether the rails will be built in time.

For founders and engineering leaders evaluating where to spend the next twelve months, the practical move is to look at the layer beneath the wallet you are building, and ask whether you assembled it because you wanted to or because nothing else was available. If the answer is the second one, the on-chain finance infrastructure layer is now the thing worth evaluating.

A sandbox is the cheapest way to see what production-grade rails actually look like before you commit. Try the Tresori sandbox →

FAQs:

Which African country leads stablecoin volume, and by how much?

Nigeria leads with $92.1 billion in on-chain value received between July 2024 and June 2025 — nearly three times South Africa’s total.

What are the dominant stablecoins used across African corridors?

USDT and USDC dominate, with USDT processing roughly $703 billion per month globally and USDC ranging up to $1.54 trillion monthly during the same period.

How much do African fintechs save on B2B payments using stablecoin rails?

Flutterwave’s CEO reports B2B payment costs as low as 0.5 percent on stablecoin rails compared with 1.5 percent on traditional fiat correspondent rails.

What compliance obligations do African stablecoin operators face under the GENIUS Act?

Full backing by liquid assets, regular public disclosure of reserves, Travel Rule compliance, sanctions screening, and audit trails produced at the infrastructure layer rather than bolted on later.

Is Tresori a competitor to Yellow Card or Flutterwave?

No. Tresori operates one layer beneath them — providing the custody, policy, and compliance infrastructure that payment-layer companies like Yellow Card and Flutterwave can build their consumer-facing products on top of.

How to Build a Stablecoin Policy Engine: Compliance as Code

Tresori — Thu, 28 May 2026 11:42:52 +0000

There is a moment in every stablecoin product build when the compliance team asks a question the engineering team cannot answer: “What happens if a transaction violates our AML policy at 2am on a Saturday?” If the answer is “someone reviews it on Monday,” the architecture is wrong. Not the policy — the architecture.

Compliance as code is the design principle that resolves this. Instead of policies that live in documents and get applied by humans after transactions settle, a stablecoin policy engine evaluates every transaction before execution and enforces the outcome deterministically — approve, deny, hold, or route to a step-up review. The policy engine becomes the decision authority between payment intent and transaction execution.

This is not an abstract architectural preference. Under the GENIUS Act, MiCA, and equivalent frameworks, regulated stablecoin issuers must maintain technical capabilities to block, freeze, and reject transactions that violate applicable law — on demand, without manual intervention. A policy document does not satisfy that requirement. A policy engine does.

What is a Stablecoin Policy Engine?

A stablecoin policy engine is a runtime decision layer that sits between a payment intent and transaction execution. It evaluates each transaction against a defined set of rules — spending limits, counterparty allowlists, approval requirements, jurisdiction constraints — and returns a deterministic outcome before any funds move.

The key word is before. A policy engine that runs after settlement is not a policy engine — it is an audit log. The compliance value comes from intercepting the transaction at the point where it can still be stopped, rerouted, or escalated.

Early stablecoin payment systems mirrored raw blockchain transfers: if you had funds and a destination, you could send. Production systems in 2026 are shifting toward constrained transfers — allowlists, limits, conditional settlement, and jurisdiction-aware routing. The policy engine is what makes that shift concrete.

The Four Core Controls

1. Spending limits
Spending limits are the most fundamental policy control. They define how much value can move in a given time window — per transaction, per day, per counterparty, per wallet.

class SpendingLimitPolicy:

def init(self, per_tx_limit, daily_limit, counterparty_limit):

self.per_tx_limit = per_tx_limit

self.daily_limit = daily_limit

self.counterparty_limit = counterparty_limit

def evaluate(self, tx: Transaction, state: WalletState) -> PolicyDecision:

if tx.amount > self.per_tx_limit:

return PolicyDecision.DENY(

reason=”exceeds_per_tx_limit”,

limit=self.per_tx_limit,

requested=tx.amount

)

if state.daily_volume + tx.amount > self.daily_limit:

return PolicyDecision.HOLD(

reason=”daily_limit_breach”,

requires=”step_up_approval”

)

if state.counterparty_volume[tx.to] + tx.amount > self.counterparty_limit:

return PolicyDecision.HOLD(

reason=”counterparty_limit_breach”,

requires=”manual_review”

)

return PolicyDecision.APPROVE()
The important design detail here: limits should be configurable per wallet, per product, and per jurisdiction — not hardcoded globally. A corporate treasury wallet and a consumer payroll wallet operate at different risk profiles. A single global limit is either too restrictive for one or too permissive for the other.

2. Counterparty allowlists

Counterparty allowlists define which wallet addresses or entity identifiers a wallet is permitted to transact with. In treasury payouts and B2B settlement, partner allowlists combined with screening are standard controls.

class CounterpartyPolicy:

def init(self, allowlist: set, blocklist: set, require_kyb: bool):

self.allowlist = allowlist

self.blocklist = blocklist

self.require_kyb = require_kyb

def evaluate(self, tx: Transaction, screening: ScreeningResult) -> PolicyDecision:

if tx.to in self.blocklist:

return PolicyDecision.DENY(reason=”blocklisted_counterparty”)

if screening.sanctions_hit:

return PolicyDecision.DENY(reason=”sanctions_screening_hit”)

if self.allowlist and tx.to not in self.allowlist:

return PolicyDecision.DENY(reason=”counterparty_not_allowlisted”)

if self.require_kyb and not screening.kyb_verified:

return PolicyDecision.HOLD(reason=”kyb_required”)

return PolicyDecision.APPROVE()

The blocklist and sanctions screening are non-negotiable. The allowlist is configurable by use case — treasury disbursements typically operate on closed allowlists, consumer payroll platforms on open lists with screening.

3. M-of-N approval requirements

M-of-N approvals require M out of N designated signatories to authorise a transaction before it executes. This is the governance control that matters most for high-value transfers, treasury operations, and any flow where separation of duties is required.

class MultiSigPolicy:

def init(self, threshold_amount: float, required_approvals: int,

total_approvers: int):

self.threshold = threshold_amount

self.m = required_approvals

self.n = total_approvers

def evaluate(self, tx: Transaction,

approvals: list[Approval]) -> PolicyDecision:

if tx.amount < self.threshold:

return PolicyDecision.APPROVE()

valid_approvals = [

a for a in approvals

if a.is_valid and a.approver in self.designated_approvers

]

if len(valid_approvals) >= self.m:

return PolicyDecision.APPROVE()

return PolicyDecision.HOLD(

reason=”insufficient_approvals”,

required=self.m,

received=len(valid_approvals),

pending=self.m — len(valid_approvals)

)

The threshold amount is the key configuration parameter. Transactions below threshold auto-approve. Transactions above threshold enter an approval workflow. The M-of-N parameters map directly to the separation of duties requirements that MiCA, the GENIUS Act, and institutional governance frameworks all require.

4. Time locks
Time locks prevent transaction execution before a specified time or after a deadline. They are used for settlement windows, payroll schedules, treasury rebalancing constraints, and regulatory holds.

class TimeLockPolicy:

Download the Medium app
def init(self, not_before: datetime, not_after: datetime = None,

settlement_window: tuple = None):

self.not_before = not_before

self.not_after = not_after

self.settlement_window = settlement_window

def evaluate(self, tx: Transaction,

current_time: datetime) -> PolicyDecision:

if current_time < self.not_before:

return PolicyDecision.HOLD(

reason=”time_lock_active”,

releases_at=self.not_before

)

if self.not_after and current_time > self.not_after:

return PolicyDecision.DENY(reason=”transaction_expired”)

if self.settlement_window:

window_start, window_end = self.settlement_window

if not (window_start <= current_time.hour < window_end):

return PolicyDecision.HOLD(

reason=”outside_settlement_window”,

next_window=window_start

)

return PolicyDecision.APPROVE()

Composing the Policy Engine
Individual controls are not policies — they are building blocks. A production stablecoin policy engine composes them into an evaluation chain where all controls must pass before a transaction proceeds.

class PolicyEngine:

def init(self, policies: list[Policy]):

self.policies = policies

def evaluate(self, tx: Transaction,

context: TransactionContext) -> PolicyDecision:

decisions = []

for policy in self.policies:

decision = policy.evaluate(tx, context)

decisions.append(decision)

if decision.outcome == Outcome.DENY:

self._log_decision(tx, decision, context)

return decision

if decision.outcome == Outcome.HOLD:

self._create_approval_workflow(tx, decision, context)

return decision

final = PolicyDecision.APPROVE()

self._log_decision(tx, final, context)

return final

def _log_decision(self, tx, decision, context):

AuditLog.record(

tx_id=tx.id,

outcome=decision.outcome,

reason=decision.reason,

policy_version=self.version,

timestamp=context.timestamp,

evaluator=context.service_identity

)

The audit log is not optional. Every decision must be reproducible, explainable, and exportable. Regulators examining your compliance programme will want to see not just what was approved but why — which policy version was active, which controls were evaluated, and which identity signed the decision. The _log_decision call on every outcome, including approvals, is what produces that evidence trail.

Jurisdiction-Aware Routing
A stablecoin policy engine in 2026 cannot operate on a single global policy. Different flows require separate policies: payouts vs customer withdrawals vs treasury movements. A transaction between a UAE sender and an Egyptian recipient operates under different jurisdiction constraints than one between Singapore and Indonesia. The policy engine needs to resolve which policy applies before evaluating it.

class JurisdictionRouter:

def resolve_policy(self, tx: Transaction,

context: TransactionContext) -> PolicyEngine:

jurisdiction_pair = (

context.sender_jurisdiction,

context.receiver_jurisdiction

)

return self.policy_registry.get(

jurisdiction_pair,

default=self.policy_registry.get(“global_default”)

)

This is the architecture that satisfies the programmable compliance requirement across VARA, MAS, CBN, and MiCA simultaneously — not a hardcoded global policy that tries to be everything, but a registry of configurable policies resolved at runtime based on transaction context.

The Difference Between Compliance as Code and Compliance as Documentation
A policy document says “transactions above $10,000 require senior approval.” A stablecoin policy engine enforces it. The document can be ignored, misinterpreted, or applied inconsistently at scale. The engine cannot.

The policy engine is the layer that translates business and compliance constraints into enforceable controls — automatically, at every transaction, without human intervention. That is the architectural shift that regulators are increasingly expecting — not better documentation, but better infrastructure.

Tresori’s policy engine implements this architecture natively: spending limits, M-of-N approvals, counterparty allowlists, time locks, and jurisdiction-aware routing all configurable through a single API, with immutable audit logs via Kap DLT capturing the full decision record for every transaction. The compliance programme that passes a regulatory review is not the one with the best policy documents — it is the one where the infrastructure enforces the policies automatically and the audit trail proves it.

FAQs

What is a stablecoin policy engine?

A stablecoin policy engine is a runtime decision layer that evaluates every transaction against configurable rules — spending limits, counterparty allowlists, M-of-N approval requirements, time locks — before execution. It returns a deterministic outcome: approve, deny, hold, or step-up. The compliance value comes from intercepting transactions before they settle, not reviewing them afterward.

What is compliance as code for stablecoins?

Compliance as code means encoding compliance rules as machine-enforceable policy that runs automatically at every transaction. Instead of policies that live in documents and get applied manually, a policy engine evaluates each payment intent in real time and enforces the outcome deterministically. This is the architecture required by the GENIUS Act, MiCA, and equivalent frameworks that mandate technical controls capable of blocking and freezing transactions on demand.

What are the core controls in a stablecoin policy engine?

The four core controls are spending limits (per-transaction and per-period caps), counterparty allowlists (permitted and blocked wallet addresses), M-of-N approval requirements (multi-party authorisation above a threshold amount), and time locks (settlement window constraints and transaction expiry). A production stablecoin policy engine composes all four into an evaluation chain that must pass before any transaction executes.

What is M-of-N approval and why does it matter?

M-of-N approval requires M out of N designated signatories to authorise a transaction before it executes. It is the governance control that satisfies separation of duties requirements under MiCA, the GENIUS Act, and institutional governance frameworks. For treasury operations, it prevents unilateral fund movement. For high-value transfers, it adds a human checkpoint that the policy engine enforces programmatically.

How does a policy engine handle jurisdiction-specific compliance?
A production stablecoin policy engine resolves which policy applies to a transaction based on sender and receiver jurisdiction before evaluating it. Different jurisdiction pairs — UAE to Egypt, Singapore to Indonesia — operate under different regulatory constraints. A policy registry maps jurisdiction pairs to configurable policy engines, so the correct controls are applied at runtime without requiring a monolithic global policy.

Why must every policy decision be logged?

Every policy decision — including approvals — must be reproducible, explainable, and exportable. Regulators examining a compliance programme need to see not just which transactions were blocked but why — which policy version was active, which controls were evaluated, which identity signed the decision. An immutable audit log on every outcome is what converts a policy engine from an operational control into a compliance artefact.

MiCA Stablecoin Compliance for Fintechs: Builder’s Checklist

Tresori — Tue, 26 May 2026 10:01:34 +0000

The Markets in Crypto-Assets Regulation is not a framework that arrives gently. Stablecoin rules for Asset-Referenced Tokens and E-Money Tokens became applicable on June 30, 2024. The main CASP authorisation regime applied from December 30, 2024. By July 1, 2026, the EU-wide transitional period ends — after which no entity may provide crypto-asset services in the EU without MiCA authorisation.

For fintechs building stablecoin compliance infrastructure in the EU, the question is not whether MiCA applies. It is whether the architecture underneath your product can satisfy what MiCA requires — and whether the gap between where you are and where you need to be can be closed before the deadlines compound.

This checklist is not a legal opinion. It is an infrastructure diagnostic. Each item maps a MiCA stablecoin requirement to the engineering or operational decision it demands.

Step 1: Determine Whether You Are an EMT or ART Issuer
The first MiCA stablecoin compliance decision — EMT or ART classification — determines every other compliance obligation that follows. Get it wrong and the entire architecture is built on the wrong foundation.

E-Money Tokens are stablecoins pegged 1:1 to a single fiat currency. USDC denominated in euros is an EMT. An EMT issuer must be an authorised credit institution or an electronic money institution — this is a licensing requirement, not a product decision. Asset-Referenced Tokens maintain stability by referencing multiple assets — currencies, commodities, or a basket. ARTs face stricter prudential requirements and, if deemed significant by the EBA, come under enhanced oversight.

Checklist:
Identify whether your stablecoin references a single fiat currency (EMT) or multiple assets (ART)
Confirm your entity holds the required authorisation — credit institution or EMI licence for EMTs
Assess whether your issuance volume triggers EBA significance thresholds
Publish a MiCA-compliant white paper before any public offer or admission to trading
Step 2: Build Reserve Architecture That Meets MiCA Standards
MiCA stablecoin requirements for reserves are not accounting rules. They are architecture requirements that determine how custody infrastructure must be built.

Issuers must maintain 1:1 liquid reserve assets, ensure full redeemability at par value, and implement adequate risk management frameworks. Reserve assets must be legally segregated, held with regulated custodians, and protected in the event of insolvency — meaning the reserves must be ring-fenced from the issuer’s corporate assets at the protocol level, not just on the balance sheet.

For builders, this is where wallet infrastructure matters. A custody architecture that commingles reserve assets with operational funds does not meet the MiCA standard. The segregation must be real, auditable, and documentable on demand.

Checklist:
Reserve assets held 1:1 against outstanding issuance in high-quality liquid assets
Reserves legally segregated from corporate assets — ring-fenced at the protocol level
Custody held with regulated, EU-supervised financial institutions
Liquidity policy documented — reserve assets must be convertible to fiat within one business day
Recovery and wind-down plan in place for significant token issuers
Step 3: Implement Daily Redemption Rights
MiCA requires stablecoin holders to be able to redeem at par value at any time. This is not a customer service commitment. It is a technical requirement with infrastructure implications.

Redemption at par value must be available to any holder, on demand, at no cost beyond direct operational costs. For fintechs, this means the redemption pathway — wallet to fiat — must be operational 24/7, not dependent on manual processing windows, and capable of handling volume spikes without delay.

Checklist:
Redemption pathway from stablecoin to fiat operational 24/7
Redemption processed at par value — no spread, no fee beyond direct costs
Redemption SLA documented and tested under stress conditions
Redemption rights clearly disclosed in token white paper and user-facing documentation
Step 4: Build AML/KYC Without Sacrificing Programmability
MiCA aligns with the EU’s full AML regime. For stablecoin builders, this means the Travel Rule applies, transaction monitoring is mandatory, and KYC is a prerequisite — not an afterthought.

MiCA aligns with the EU’s AML regime, requiring CASPs to share identifying information with counterparties during transfers — the Travel Rule. Customer identification, beneficial ownership verification, and transaction monitoring are all required. The architecture implication: compliance checks must be embedded in the transaction flow, not run as a separate post-settlement review.
The AML regime also introduces personal liability. Under MiCA, company executives and key personnel can be held personally responsible for violations — including bans from working in crypto-related roles. This is the clause that turns compliance from a legal team concern into a board-level concern.

Checklist:
KYC/AML programme implemented before first transaction — not at onboarding scale
Travel Rule data transmission operational for transfers above €1,000
Transaction monitoring system live — not manual, not batch
Sanctions screening embedded in transaction execution, not applied post-settlement
Suspicious transaction reporting process documented and tested
Beneficial ownership identification for institutional counterparties
Step 5: Prepare the CISO Package
MiCA authorisation requires documentation that most fintech security teams have never had to produce for a financial regulator. Preparing it in advance is the difference between a three-month approval and a nine-month one.

Over 70 CASP authorisations had been issued across the EU as of October 2025, with Germany and the Netherlands leading in licence issuance. The teams that moved fastest were the ones that arrived at their National Competent Authority with complete documentation packages — not the ones with the best technology.

What the NCA will ask for: governance framework, key management architecture documentation, incident response procedures, operational risk management policies, and evidence that reserve custody meets segregation standards. None of these are produced quickly. All of them need to exist before the application is submitted.

Checklist:
Governance framework documented — board oversight, compliance officer designated
Key management architecture documented — MPC sharding arrangement auditable
Incident response procedure — including notification timeline to NCA
Operational risk management policy — covering technology, third-party, and liquidity risk
Cybersecurity policy aligned with DORA requirements
Reserve custody documentation — segregation evidence, custodian agreements
The Infrastructure Implication
The checklist above has one consistent theme: MiCA stablecoin compliance is not satisfied by documentation alone. It requires custody architecture that segregates reserves at the protocol level, transaction flows that embed compliance before settlement, and key management systems that are auditable on demand.

This is the gap that catches most teams. The compliance policy is written. The legal review is complete. But the infrastructure underneath the product — the wallet layer, the custody model, the transaction pipeline — was not built to the standard the checklist requires.

Tresori’s compliance layer embeds KYC verification, AML screening, Travel Rule data transmission, and programmable transaction controls inside the payment flow. The CISO package — architecture documentation, pen-test results, compliance mappings, incident response procedures — is available before you submit your MiCA application, not months after. For teams working toward NCA authorisation, that timeline difference is the difference between a compliant product and a delayed one.

Conclusion
MiCA stablecoin requirements are detailed, sequential, and unforgiving about order of operations. The reserve architecture must exist before the white paper is published. The redemption pathway must be operational before the first token is issued. The AML programme must be live before the first transaction is processed.

By July 1, 2026, the transitional period ends across the EU. The teams that are ready are the ones that treated this checklist as an infrastructure brief, not a compliance exercise.

See how Tresori’s built-in MiCA stablecoin compliance layer maps to NCA requirements at tresori.xyz.

FAQs
What is MiCA stablecoin compliance?
MiCA stablecoin compliance refers to meeting the requirements of the EU’s Markets in Crypto-Assets Regulation for issuers of Asset-Referenced Tokens (ARTs) and E-Money Tokens (EMTs). Requirements include 1:1 reserve backing, segregated custody, daily redemption rights, AML/KYC programmes, Travel Rule compliance, and NCA authorisation.

What is the difference between an EMT and an ART under MiCA?
An E-Money Token is pegged 1:1 to a single fiat currency and must be issued by an authorised credit institution or EMI. An Asset-Referenced Token maintains stability by referencing multiple assets and faces stricter prudential requirements. The classification determines the authorisation pathway, reserve requirements, and oversight regime.

When did MiCA stablecoin rules take effect?
Stablecoin rules for ARTs and EMTs became applicable on June 30, 2024. The main CASP authorisation regime applied from December 30, 2024. The EU-wide transitional period ends July 1, 2026 — after which MiCA authorisation is required to operate across the EU.

What are the reserve requirements under MiCA?
MiCA requires stablecoin issuers to maintain 1:1 reserve assets in high-quality liquid instruments, legally segregated from corporate assets, held with regulated EU-supervised custodians, and redeemable within one business day. Monthly transparency reports demonstrating full reserve backing are mandatory.

Does MiCA require Travel Rule compliance for stablecoins?
Yes. MiCA aligns with the EU’s AML regime, requiring CASPs to share identifying information with counterparties during transfers above €1,000. Travel Rule data transmission must be embedded in the transaction flow — not processed as a post-settlement reporting step.

What documentation does MiCA require for NCA authorisation?
NCA applications require a governance framework, key management architecture documentation, incident response procedures, operational risk management policies, cybersecurity policies aligned with DORA, and reserve custody documentation demonstrating legal segregation. Teams that arrive with complete documentation packages move through the authorisation process significantly faster than those that prepare documentation during the review.

The Stablecoin Orchestration War: Who Will Control the Payment Stack?

Tresori — Tue, 12 May 2026 09:30:46 +0000

Every significant infrastructure market eventually produces the same dynamic. The rails get built. The asset layer matures. And then, quietly, the real battle begins — not over who issues the asset, but over who controls the layer that moves it. The internet had TCP/IP. Card payments had Visa and Mastercard’s switching networks. And stablecoin payments in 2026 are producing their own version of that fight, one that will determine which companies sit at the centre of the next decade of global money movement.

The prize is the stablecoin orchestration layer — the infrastructure that routes, settles, nets, and compliance-checks dollar flows across fifteen chains, multiple issuers, and dozens of jurisdictions. Whoever controls it controls the payment stack. And the race to own it is already underway.

Why the Stablecoin Orchestration Layer is the Real Prize

The stablecoin orchestration layer is the coordination infrastructure that sits between applications and the network of chains, bridges, and issuers that move stablecoin value. Whoever controls routing controls margin, compliance, and counterparty relationships across the entire flow.

Stablecoin issuance is a commodity play — USDC, USDT, and a growing roster of regulated alternatives are fungible at the asset level. Chain selection is a technical decision. But stablecoin orchestration — the layer that decides which chain to use, which bridge to cross, how to handle compliance, and how to net opposing flows — is a defensible position. It is sticky, technically complex, and increasingly the chokepoint through which all stablecoin payment volume flows.

Real-world stablecoin payment volume doubled in 2025 to $400 billion, with 60% estimated to be B2B flows, according to Bessemer Venture Partners. The teams that own the routing layer for that volume own the relationship with every business moving money through it. That is what this war is about.

The Players and What They are Trying to Own

Bridge (now Stripe)
Bridge was the first company to make stablecoin orchestration a standalone product category. Stripe acquired Bridge for $1.1 billion in February 2025, then acquired Privy — the embedded wallet infrastructure — in June 2025. The combined stack gives Stripe a stablecoin payment offering that spans issuance, orchestration, embedded wallets, and fiat on/off ramps, all within a single commercial relationship.

The strategic logic is clear. Stripe already processes significant share of global internet commerce. Adding stablecoin orchestration through Bridge, and wallet infrastructure through Privy, gives Stripe the ability to offer merchants and platforms a complete dollar-movement stack without leaving the Stripe ecosystem. The risk for fintechs evaluating Bridge is equally clear: vendor concentration. A stablecoin payment stack that depends entirely on Stripe is an infrastructure decision that is also a commercial dependency.

Ripple
Ripple is pursuing a different strategy — vertical integration through acquisition rather than developer adoption. In 2025, Ripple made four major acquisitions including Rail for $200 million and Palisade for custody, building toward what it describes as a one-stop stablecoin payment stack covering custody, treasury automation, virtual accounts, conversion, and settlement. Ripple Payments has processed more than $100 billion in total volume, with Rail adding another $10 billion annually.

Ripple’s RLUSD stablecoin has surpassed $1.5 billion in market cap and is being tested in Singapore’s MAS BLOOM sandbox for trade finance, where the MAS’s involvement signals that the RLUSD-on-XRPL stack is credible enough for regulated experimentation. Ripple is not building for developers. It is building for enterprises and financial institutions that want a single regulated counterparty for their entire stablecoin orchestration and payments operation.

Crossmint
Crossmint has positioned itself as the full-stack answer for teams that want stablecoin orchestration, wallets, compliance, and fiat ramps in a single API — without the ecosystem lock-in that comes with Bridge/Stripe or the enterprise-sales complexity of Ripple. Crossmint covers the entire stack: onramp, programmable wallets, compliance, offramp, and orchestration across 50+ chains. MoneyGram used Crossmint to launch stablecoin payments in sixty days. Western Union is among its enterprise adopters.

Crossmint joined the Solana Developer Platform as an official launch partner in March 2026, serving as the wallet and payments infrastructure layer within a platform that includes Mastercard and Worldpay among early enterprise adopters. Its positioning — full-stack, developer-accessible, multi-chain — targets the space between Bridge’s Stripe dependency and Ripple’s enterprise-only model.

Cybrid
Cybrid is the most quietly positioned player in this group. Founded in 2021 and having raised a $10 million Series A in October 2025, Cybrid’s stablecoin orchestration layer connects fiat rails and stablecoin infrastructure into a unified flow — ACH, wires, RTP, EFT, and stablecoin conversion through a single API, with embedded KYC/KYB/AML compliance and MPC custody. Its positioning is explicitly fiat-first: Cybrid is a vertically integrated platform that bundles payment orchestration, compliance, fiat on/off-ramps, and MSB licensing coverage. The argument is that most fintechs do not need a pure stablecoin payment stack — they need a payment stack that happens to include stablecoins.

What the Consolidation Tells You

The acquisition activity around stablecoin orchestration is not coincidental. Mastercard announced the acquisition of BVNK for up to $1.8 billion in March 2026. Stripe acquired Bridge for $1.1 billion. Ripple has invested nearly $4 billion in acquisitions across the stablecoin payment stack. The incumbents are not waiting to see how this develops. They are buying the layer.

The pattern is familiar from every prior infrastructure consolidation. The teams that win in card payments did not win by issuing better cards. They won by owning the switching network — the routing, the clearing, the settlement. Stablecoin orchestration is the switching network of the next era of global money movement. The acquisitions are the signal that the consolidation window is open and closing.

Where the Mid-Market Gap Still Exists

What none of these players fully address is the Series A-C fintech operating in MENA, Southeast Asia, or Africa that needs stablecoin orchestration with enterprise-grade compliance, sub-day deployment, and pricing that does not require a CFO conversation before the proof of concept begins. Bridge comes with Stripe lock-in. Ripple requires an enterprise sales process. Crossmint is the closest to this sweet spot but is still primarily developer-facing.

Tresori sits in this gap — stablecoin orchestration built on MPC-secured custody, with a routing engine that evaluates bridge options, gas costs, and liquidity depth per transaction, compliance embedded in the transaction flow, and 50+ chain support through a single API. The positioning is not better than the enterprise players. It is designed for a different buyer: the team that needs to be in production this sprint, not this quarter.

The Question Worth Asking

In every infrastructure war, the companies that win are not always the ones with the best technology. They are the ones that own the relationship with the builder at the moment the builder is making the decision. Bridge won that relationship for a generation of US fintechs before Stripe absorbed it. Ripple is winning it for enterprise financial institutions. The open question in 2026 is who wins it for the fastest-growing segment of the stablecoin payment stack market — the mid-market fintech building in the corridors where stablecoin orchestration is not a strategic bet but an operational necessity.

That question does not have a settled answer yet. Which means it still has one.

FAQs

What is the stablecoin orchestration war?

The stablecoin orchestration war refers to the competition among infrastructure companies — including Stripe/Bridge, Ripple, Crossmint, and Cybrid — to control the routing, settlement, and compliance layer of the stablecoin payment stack. Whoever owns this layer controls the margin and counterparty relationships across global stablecoin payments at scale.

Why does controlling the stablecoin payment stack matter?

The stablecoin orchestration layer is the chokepoint through which all stablecoin payment volume flows. It determines routing, cost, compliance, and settlement for every transaction. Controlling it means controlling the commercial relationship with every business moving money on stablecoin rails — the same structural position that made Visa and Mastercard’s switching networks so durable.

What is Stripe doing in stablecoin orchestration?

Stripe acquired Bridge for $1.1 billion in February 2025 and Privy in June 2025, combining stablecoin orchestration, wallet infrastructure, and fiat ramps into a single commercial stack. The risk for teams building on Bridge is Stripe ecosystem lock-in — the entire stablecoin payment stack becomes a dependency on a single vendor.

How is Ripple approaching the stablecoin payment stack?

Ripple is pursuing vertical integration through acquisitions — Rail, Palisade, GTreasury — to build a full-stack stablecoin orchestration and payments platform covering custody, treasury automation, virtual accounts, and settlement. Ripple Payments has processed over $100 billion in volume and is targeting enterprise financial institutions rather than developer teams.

Who serves the mid-market in stablecoin orchestration?

The mid-market gap — Series A-C fintechs needing enterprise-grade stablecoin orchestration with transparent pricing and sub-day deployment — is underserved by the major players. Bridge comes with Stripe lock-in. Ripple requires an enterprise sales process. Crossmint is the most accessible full-stack option. Tresori is positioned explicitly for this segment, with stablecoin orchestration across 50+ chains, MPC-secured custody, and compliance embedded in the transaction flow.

What does the acquisition activity tell us about where stablecoin infrastructure is heading?

Mastercard’s $1.8 billion acquisition of BVNK, Stripe’s $1.1 billion acquisition of Bridge, and Ripple’s $4 billion acquisition programme all point to the same conclusion: the stablecoin orchestration layer is consolidating. The teams making infrastructure decisions now are choosing which network they will be part of when that consolidation is complete.

Building On-Chain Finance Infrastructure With 12 Lines of Code

Tresori — Wed, 29 Apr 2026 08:01:32 +0000

There is a version of this story that starts with a whitepaper. KYC architecture diagrams. A six-month compliance review. A Fireblocks contract that costs three times what the deck said by year two.

That version is real. It has happened to a lot of teams. It is also not the only version anymore.

The version we’ll walk through starts differently — with an on-chain finance API for developers, a sandbox account, and the realisation that the infrastructure decisions that used to take quarters can now be made in an afternoon. Not because the compliance requirements went away, but because someone already built the layer that satisfies them.

Why has building compliant on-chain infrastructure taken months — until now?

Because the compliance and custody requirements of regulated finance are genuinely hard to build — and for a decade, building them was the only option. KYC linked to wallets, OFAC screening inside transactions, MPC key management with HSM backing. These are not features. They are architectural decisions. What changed is that they are now available as infrastructure you call, not infrastructure you build.

For the better part of a decade, building on-chain finance infrastructure meant one of two things. You either used a permissionless protocol — fast to integrate, impossible to make compliant — or you built the compliance and custody layer yourself, which meant hiring specialists, running a security audit, and explaining to your CFO why a six-month infrastructure project was a prerequisite for a payment feature.

The reason that trade-off persisted so long is that the compliance and custody requirements of regulated finance are genuinely hard. KYC needs to travel with every wallet, not live in a front-end. OFAC screening needs to run inside the transaction, not before it. MPC key management needs institutional-grade HSM backing, spending policy enforcement, and audit logging that survives a regulatory examination. These are not features you bolt on. They are architectural decisions that propagate through every subsequent choice.

What has changed is not the requirements. What has changed is that those requirements are now available as infrastructure — the same way SSL/TLS is available as infrastructure, and you do not have to understand the cryptography to serve HTTPS.

This is a walkthrough of that infrastructure, using Tresori’s on-chain finance API for developers. By the end of it, you will have provisioned a compliant MPC wallet, routed a stablecoin payment API, and verified Travel Rule compliance API. In 12 lines of code. The compliance and custody layer is handled. You just call it.

What changes when compliance is infrastructure rather than something you build?

Everything. When compliance is infrastructure, a wallet provisioning call is also a KYC-linking call, a key management call, and a policy enforcement call. You do not add compliance to a payment flow. You get a payment flow that was compliant before you wrote the first line.

A Tresori wallet is not a key pair you generate and store. It is a compliant MPC wallet — MPC key management fintech-backed, policy-enforced, linked to a verified entity in your system at the moment of creation. The KYC status your user completed at onboarding does not live in your database alone.

const wallet = await client.wallets.create({
entity_id: ‘usr_8f3kd92’,
chains: [‘solana’, ‘ethereum’],
policy: ‘standard_compliance’
});

Three things happen in that call that you did not have to write. The wallet is linked to usr_8f3kd92 in your entity registry. The MPC key management fintech shares are distributed across HSM-backed infrastructure, with no single point of compromise. The standard_compliance policy attaches OFAC screening blockchain and Travel Rule compliance API to every outbound transaction from this wallet — at the protocol level, not the application layer.

You get back addresses. Everything else is handled.
Key takeaway: KYC-linked wallet provisioning in on-chain finance is not a key management problem. It is an identity and compliance problem. An on-chain finance API for developers that solves all three in one pass is the architectural difference that matters.

Why is the contract short when the compliance requirements are not?
Because the compliance requirements moved into the infrastructure layer. The contract does not carry OFAC logic, Travel Rule packaging, or MPC key management — it calls an execution layer that does. Shorter code is not a shortcut. It is what happens when the hard work is done somewhere else.

const payment = await client.payments.send({
from_wallet: wallet.id,
to_address: ‘AhX9…recipientAddress’,
amount: ‘250.00’,
currency: ‘USDC’,
chain: ‘solana’,
memo: ‘Invoice #INV-2024–0391’
});
Before the transaction reaches the chain, Tresori runs OFAC screening blockchain against the destination address, packages Travel Rule compliance API originator data against the IVMS 101 standard, and routes the payment via stablecoin payment API to the optimal RPC endpoint. If the destination address matches a sanctions entry, the payment does not execute.

That is the architectural difference between compliance as a transaction-layer property and compliance as a wrapper around a permissionless protocol. In DeFi, a sanctions screen fails and the transaction executes anyway — the protocol has no mechanism to stop it. Here, the compliance logic is inside the execution layer.

Why should the chain be a parameter, not an architecture decision?

Because locking your architecture to a single chain means rebuilding every time the market moves. The chains that matter for on-chain finance infrastructure today — Solana, Base, Arbitrum, Stellar — are not the same ones that will matter in three years. The right infrastructure decision is one that makes chain selection a runtime choice, not a foundational commitment.

Stablecoin settlement infrastructure decisions are liquidity decisions, custody decisions, and — increasingly — jurisdiction decisions. Solana for settlement speed and USDC volume, Base and Arbitrum for permissioned blockchain payments with institutional tooling, Stellar for MENA and Southeast Asian remittance corridors.

Tresori routes across all of them from the same on-chain finance API for developers surface. The chain is a parameter, not an integration decision.

Why does Travel Rule compliance break when it lives in a front-end?

Because a front-end can be bypassed. The moment a user interacts with a permissionless contract directly — without going through your application layer — the Travel Rule check never runs. Compliance that depends on a user taking the right path is not compliance. It is a process that works until it doesn’t.

const compliance = await client.compliance.check({
payment_id: payment.id
});

The Travel Rule requirement — that originators and beneficiaries of transfers above a threshold be identified at the protocol level — is the one that trips most teams building regulated payment flows. The standard implementation puts the check in a front-end that calls a VASP directory before the user submits the transaction. That approach breaks under MiCA, breaks under any jurisdiction that requires the data at the protocol level rather than the application level, and is trivially bypassed by anyone who does not use your front-end.

Tresori’s Travel Rule implementation packages the originator and beneficiary data into the transaction at the point of execution. The compliance.check call returns the full compliance record — the data that exists in the audit trail, the data that satisfies a regulatory examination. You are not building a compliance report. You are reading one that was written when the transaction was created.

Key takeaway: Travel Rule compliance API that lives in a front-end is not compliance. It is a wrapper that breaks the moment someone bypasses the front-end. Compliance at the transaction layer does not break, because there is no front-end to bypass.

What is sitting behind those 12 lines?

Seven layers that used to take quarters to build: MPC key management, HSM-backed storage, spending policy enforcement, OFAC screening at execution, Travel Rule packaging, multi-chain routing, and SOC 2-compatible audit logging. None of it is in the 12 lines. All of it runs every time you call them.

Twelve lines of code. Three API calls. And what sits behind them is worth listing, because it is the list that used to take quarters to build: MPC wallet infrastructure with distributed key shares and HSM backing. OFAC screening running inside transaction execution. Travel Rule originator/beneficiary data packaged to IVMS 101 standard. Multi-chain routing logic across 50+ networks. SOC 2-compatible audit logging. Spending policy enforcement. KYC-to-wallet entity linking.

None of that is yours to maintain. None of it is yours to audit. None of it needs to be explained to a compliance officer who has never seen a blockchain address.

The question developers kept asking — “how do I add compliance to my on-chain payment flow?” — was always the wrong question. The right question is “how do I build a payment flow where compliance is already there?” The answer, it turns out, is twelve lines.

How do you know the sandbox is production-ready before you go live?

Because the sandbox runs the same infrastructure as production — same compliance checks, same custody layer, same Travel Rule implementation — on test funds. There is no stripped-down demo environment. What you build in the sandbox is what goes live. The only thing that changes is the key.

The sandbox is the fastest way to understand what the infrastructure layer can carry before committing to a production integration. Multi-chain routing, batch payment flows, webhook configuration for transaction status updates, and the full Travel Rule implementation are all available from day one.

FAQs

Can you really build on-chain finance infrastructure in 12 lines of code?

Yes. The compliance, custody, and Travel Rule logic is infrastructure — not something you write. You call it.

What does a 12-line on-chain finance smart contract look like?

Which Ethereum Layer 2 is best for regulated on-chain finance applications?

Base for teams on Coinbase’s stack. Arbitrum for ecosystem depth. Both have the USDC liquidity and institutional custody support regulated use cases require.

How does compliance integration work in such a small contract?

It doesn’t live in the contract at all. OFAC screening, Travel Rule, and KYC enforcement run in Tresori’s infrastructure layer before the transaction reaches the chain.

What security layers support this 12-line contract?

MPC with distributed key shares, HSM-backed storage, OFAC screening at execution, spending policy enforcement, and SOC 2 audit logging — all in the infrastructure layer, none of it yours to maintain.

How can developers test these contracts locally?

Tresori’s sandbox mirrors the full production API across 50+ chains using test funds. Same code, no changes required to go live.

Where can developers access Tresori SDK and smart contracts?

The SDK and full documentation are at tresori.xyz/developers. The sandbox — covering wallet provisioning, stablecoin settlement, and compliance across 50+ chains — is at tresori.xyz and provisions in under a day.

Why 2026 is the Year On-Chain Finance Goes Mainstream

Tresori — Tue, 14 Apr 2026 07:01:30 +0000

Introduction

The financial infrastructure underpinning global commerce has not fundamentally changed in decades. Cross-border payments still route through chains of correspondent banks, each maintaining their own ledger, each charging a fee — a model that hasn’t structurally changed since SWIFT was founded in 1973. Reconciliation still happens in batches, overnight, across siloed ledgers that never fully agree.

That is changing, not through a new app or a better interface, but through a structural shift in where financial logic lives. On-chain finance is moving from the periphery of institutional conversations to the center of infrastructure roadmaps. And 2026 is the year the enabling conditions have all arrived at once.

This is not a prediction. It is a pattern already visible in the data, in the regulatory calendars, and in the deployment decisions being made right now by fintech teams across MENA, Southeast Asia, and Africa.

For almost a decade, on-chain finance was too untested for traditional institutions to adopt, and too immature for serious infrastructure bets. In 2026, we’re witnessing a transition in settlement infrastructure, programmable money, and the quiet rewiring of how financial services work. Five structural forces are converging simultaneously — marking the moment on-chain finance crosses from experimental to default.

In this article, we cover:

Why has 2026 become the first year of real regulatory clarity for On-Chain Finance?
How Did Stablecoins Cross the Threshold From Crypto Experiment to Payment Infrastructure?
Why Do AI Agents Need On-Chain Payment Rails?
What Changed in Developer Tooling That Makes On-Chain Deployment Production-Ready?
What Does Inaction on On-Chain Finance Actually Cost in 2026?

For almost a decade, on-chain finance was too untested for traditional institutions to adopt, and too immature for serious infrastructure bets.

In 2026, we’re witnessing a transition in the settlement infrastructure, programmable money, and the quiet rewiring of how financial services work. Five structural forces are converging this year, marking the moment on-chain finance crosses from experimental to default.

Why has 2026 become the first year of real regulatory clarity for on-chain finance infrastructure?

In 2026, MiCA is fully enforced across all 27 EU member states and the OCC has granted digital asset bank charters in the US — making on-chain infrastructure providers regulated counterparties for the first time in institutional compliance frameworks.

For years, regulatory ambiguity was the biggest barrier to institutional adoption of on-chain infrastructure. Compliance teams couldn’t onboard on-chain vendors the same way they onboarded any other regulated financial counterparty — because those vendors weren’t regulated counterparties. That changed in 2026.

Key developments driving this shift:

The EU’s Markets in Crypto-Assets (MiCA) Regulation framework is fully in effect, providing a regulatory perimeter for digital assets across all 27 member states.
In the US, the OCC granted conditional approval for five national trust bank charters tied to digital assets in December 2025, including Circle, Fidelity Digital Assets, and Paxos — moving stablecoin and custody infrastructure inside the federal banking perimeter for the first time
Compliance teams can now work with on-chain vendors the same way they work with any regulated financial infrastructure provider the implication for financial institutions and fintechs is straight forward: on-chain infrastructure providers are becoming regulated counterparties. The legal and compliance question that blocked institutional adoption for years has a clear answer in 2026.

Key Takeaway:
Regulatory frameworks in the EU and US have formally brought on-chain infrastructure inside the institutional perimeter — removing the single biggest barrier to adoption.

How did stablecoins cross the threshold from crypto experiment to payment infrastructure?

Stablecoins now represent over $260 billion in circulating supply and are processing $226 billion annually in B2B payments — 60% of all real stablecoin payment activity, growing 733% year over year, according to McKinsey.

The numbers that define the shift:
USDT and USDC together represent over $260 billion in circulating supply as of March 2026, with USDT at approximately $186.7 billion and USDC at approximately $75–79 billion¹ 49% of institutions already use stablecoins for payments, with another 41% in piloting or planning stages²
According to McKinsey, B2B stablecoin payments account for approximately $226 billion annually, representing 60% of all real stablecoin payment activity and growing 733% year over year³
This figure represents just 0.01% of global B2B payment volumes³ — underscoring how much runway remains.

Stablecoins are now being used for B2B cross-border payments, corporate treasury management, supply chain settlement, and payroll for global teams. Major financial institutions have operationalized on-chain settlement for specific workflows — a shift from announcement to production that marks the relevant threshold.

For fintechs in high-growth corridors across Southeast Asia and MENA, where correspondent banking relationships are expensive, slow, and unreliable, stablecoin rails represent something more significant than efficiency gains. They represent a structural bypass of infrastructure that was never built for their volume or geography.

Key Takeaway:

With $260B+ in circulating supply and 733% YoY growth in B2B payment volume, stablecoins are no longer a crypto experiment — businesses are moving real money through them at scale, right now.

Why does the AI agent economy need on-chain payment rails?

AI agents operating autonomously booking compute, paying for API calls, settling contracts in real time require payment infrastructure with no human authorization loops, no minimum transaction fees, and no batch settlement windows. Only on-chain rails meet those requirements.

AI agents that can book compute, pay for API calls, hire other agents, and settle contracts in real time are becoming active economic participants. They need payment infrastructure that operates at machine speed:

No human authorization for every transaction
No 30-cent minimum fee that makes card networks structurally unworkable for high-frequency micropayments No batch settlement cycles that introduce latency into autonomous workflows Stablecoins on on-chain rails are the only payment infrastructure that meets these requirements.

Two production deployments already live in 2026:

Coinbase’s x402 protocol (backed by Cloudflare, AWS, Circle, and Stripe) embeds stablecoin micropayments directly into HTTP requests, allowing an AI agent to pay for a data feed or API call in the same interaction it makes the request Google’s agent payment protocol supports stablecoins as a settlement layer for autonomous agent transactions. The infrastructure category being built for AI agents is not separate from on-chain finance infrastructure. It is the same infrastructure — deployed for a new class of participant that traditional rails were never designed to accommodate.

Key Takeaway:

The AI agent economy has created a new class of payment requirements — continuous, high-frequency, low-value — that traditional rails cannot support and on-chain finance infrastructure was built to handle. This demand signal will only grow.

What changed in developer tooling that makes on-chain deployment production-ready?

Wallet as a Service platforms, the ERC-4337 account abstraction standard, and embedded finance APIs have reduced the on-chain integration timeline from months to under a day — removing the engineering barrier that previously required dedicated blockchain expertise.

Two years ago, integrating on-chain infrastructure required deep cryptographic expertise, custom smart contract development, and months of security review.

What has changed:
Wallet as a Service (WaaS) platforms abstract key management, custody, and multi-chain routing behind clean APIs
The ERC-4337 account abstraction standard eliminates gas fee management and seed phrase complexity from the user experience entirely
Embedded finance APIs allow any engineering team to integrate production-grade blockchain tools without dedicated blockchain expertise
A fintech engineering team can now deploy a production-grade on-chain payments stack complete with multi-chain support, gasless transactions, embedded wallets, and a compliance-ready policy engine using a modern API and SDK. The infrastructure layer that matters in 2026 is programmable by design, invisible to end users, autonomous in operation, and compliant by default. Those four properties — which required separate vendors and months of integration work two years ago — now arrive through a single interface.

The remaining constraint is not engineering. It is organizational: the time it takes an infrastructure team to realise that the decision they have been deferring no longer requires the build overhead they were deferring it for.

Key Takeaway: The integration timeline for on-chain infrastructure has collapsed from months to under a day. The technical barrier is gone — what remains is the organizational lag between a constraint disappearing and the teams who planned around it updating their assumptions.

What does inaction on on-chain finance actually cost in 2026?

The cost of not deploying on-chain finance infrastructure in 2026 is measurable: $15–50 per cross-border transaction versus under $0.10; T+1 settlement versus under 10 minutes; 4+ months to deploy versus under one day. Every quarter of inaction is a compounding competitive disadvantage.

On-chain finance is no longer a future-state consideration. It is an active deployment choice being made by real companies building real products.

What early movers are already doing:
Cross-border payment fintechs are replacing SWIFT rails with stablecoin transfers that settle in seconds at fractions of the cost.
Neobanks are launching stablecoin-denominated accounts offering yield and real-time transferability that no traditional bank account can match.
Corporate treasury platforms are automating cash management workflows that previously required manual oversight and overnight batch processing.
These deployments are particularly concentrated in MENA and Southeast Asian corridors, where the gap between the infrastructure teams actually need and the infrastructure legacy rails provide is widest — and where the early movers building on-chain finance rails are accumulating user trust and compliance frameworks before market consolidation closes the window.

Key Takeaway: The window for first-mover advantage in on-chain finance infrastructure is open, but it is not permanent. Early movers are locking in blockchain infrastructure partnerships and refining compliance frameworks now. Every quarter of delay is a quarter of compounding competitive disadvantage.

Conclusion
The five forces covered in this piece — regulatory clarity, stablecoin scale, AI agent demand, developer tooling, and the measurable cost of inaction — are not arriving sequentially. They are converging simultaneously in 2026, and that convergence is what makes this year structurally different from every year of “blockchain is almost ready” that preceded it.

On-chain finance is not the future of financial infrastructure. It is the present infrastructure layer being laid right now, corridor by corridor, workflow by workflow, by the teams that decided not to wait.

The question is no longer whether to adopt on-chain finance infrastructure. It is whether to build that capability in-house, piece by piece, over months — or to deploy through infrastructure that already handles key management, multi-chain routing, compliance policy, and wallet operations through a single API. Tresori is built for the latter: production-grade on-chain finance infrastructure that a fintech engineering team can deploy in under a day and that a CISO can review in under 48 hours. Learn more at tresori.xyz.

The institutions and fintechs that treat this as an observation will spend the coming years catching up to the ones that treated it as a decision.

FAQs

1. What is on-chain finance and why does it matter in 2026?

On-chain finance uses blockchain infrastructure to execute and settle financial transactions. Regulatory clarity, stablecoin maturity, and developer tooling have all converged, making 2026 the first year on-chain infrastructure is genuinely production-ready.

2. What is on-chain finance infrastructure and how is it different from traditional fintech?

On-chain finance infrastructure replaces batch-settlement, intermediary-dependent financial rails with programmable, 24/7, shared-state systems. Settlement happens in minutes rather than days; compliance is embedded in the transaction flow rather than applied post-settlement; and the entire stack is accessible through a developer API rather than requiring bespoke integration.

3. What does “programmable finance” mean for businesses?

Programmable finance means financial logic, including payment terms, spending limits, and approval workflows, is encoded in smart contracts and executed automatically when conditions are met.

4. What is MPC and why is it important for crypto wallets?

Multi-Party Computation (MPC) splits a private key into multiple shares held by separate parties, so the complete key never exists in one place. For wallets, this eliminates the single point of failure that makes traditional key management dangerous. Tresori uses MPC as the default security architecture across all wallet types.

5. Which blockchain networks matter for on-chain finance infrastructure in 2026?

The practical network set for enterprise on-chain finance includes Ethereum, Solana, Base, Polygon, BNB Chain, Avalanche, Arbitrum, Optimism, Tron, and Starknet — covering the major L1s and the high-throughput L2s where stablecoin payment volume is concentrated. Infrastructure that requires separate integrations per chain introduces deployment overhead that eliminates most of the speed advantage of on-chain rails.

6. How does Tresori help companies build crypto wallets at scale?

Tresori replaces the custom build of key management, signing, policy engine, gas management, and blockchain compliance tooling with a single API that can be integrated in hours.

Source:
¹ Tether Statistics 2026: Billion-Dollar Data Secrets • CoinLaw

² Global Insights: Stablecoin Payments & Infrastructure Trends | Fireblocks

³ Stablecoins in payments: What the raw transaction numbers miss | McKinsey