Introducing Payouts

Stablecoins gave the industry a new settlement primitive: instant, global, 24/7 money movement with predictable fees. But anyone who has actually shipped a product knows the hard part starts the moment you need to leave the chain. Off-ramping is where stablecoin flows meet the real world: bank accounts, local rails, beneficiary verification, compliance gates, and corridor-specific quirks.

Today we’re announcing Dfns Payouts, a new capability that lets Dfns customers off-ramp stablecoins to local fiat through a single, normalized workflow while keeping Dfns as the control plane for authorization, signing, and auditability.

We’re starting with a first integration: Borderless. But the strategic point is bigger than any one provider. Payouts is designed to be provider- and rail-agnostic, so teams can integrate additional venues over time without rewriting their entire payout stack or re-architecting their security model. The market has plenty of vertically integrated offerings that bundle “one wallet + one payment provider” into a single stack. Payouts is intentionally the opposite: horizontal, marketplace-friendly, and built for optionality.

Why Payouts, why now

Stablecoins have matured into a credible settlement layer. What has not matured at the same pace is the infrastructure that converts them into local fiat at scale with real execution quality, governance, and resilience. Most teams entering stablecoin payouts still hard-code a single off-ramp provider and build their product around it. That works early. It becomes a structural constraint later. 

Dfns Payouts, powered by Borderless, changes that architecture. Borderless enables stablecoin-to-fiat payouts into bank accounts across more than 94 countries and 63 currencies through a network of 14+ licensed financial institutions. Instead of integrating corridor by corridor, customers gain access to an orchestration layer that can evaluate multiple payout paths for a given transaction. Dfns remains the wallet and control plane underneath, enforcing policy, approvals, limits, and secure execution.

The difference from vertically integrated models is deliberate. In stacks where wallet infrastructure is tightly coupled to a single payout provider, routing, pricing, and settlement are effectively bundled together. You inherit the provider’s economics and reliability profile. In the Dfns × Borderless model, routing and authorization are separated. Bridge, for example, can exist within the Borderless network as one payout provider. Today, each country maps to a single provider, but the Borderless team is working toward supporting multiple providers per country in the near future. As that capability rolls out, customers will be able to select the best route per transaction, while Dfns enforces whether that route is allowed to execute.

This separation delivers tangible benefits for fintechs and institutions operating at volume :

1. Price discovery improves. Borderless evaluates fees, FX spreads, and settlement paths across providers in real time. Transactions are routed to the most efficient available option rather than flowing through a single embedded vendor margin. Over meaningful payout volume, this directly improves unit economics across treasury flows, merchant settlement, remittance, and cross-border disbursement.
2. Best execution becomes defensible. Expectations around execution quality are increasingly applied to digital asset payments. With Dfns × Borderless, routing decisions are based on cost, speed, and reliability, and the data supporting those decisions is auditable. Crucially, Dfns policies can enforce routing constraints before any signature occurs. That creates a materially stronger posture with regulators, auditors, and internal risk teams: execution is not just fast; it is controlled, governed, and explainable.
3. Operational resilience is built into the structure. Borderless is not a payment rail; it is an orchestration layer. If one provider degrades in a corridor or goes offline, routing can shift. There is no hard dependency on Bridge or any single counterparty. For banks, enterprises, and public-sector deployments where uptime and redundancy are mandatory, this materially reduces concentration and operational risk.

All of this integrates cleanly into Dfns. Customers onboard directly with Borderless and connect their account to their Dfns organization via API key (i.e., ClientId + ClientSecret). Once the Borderless account is created and KYC is completed, beneficiaries and payment instructions can be managed programmatically via the Dfns APIs (support in the Dfns UI is coming soon). The payout lifecycle (i.e., quote, intent, settlement confirmation, status tracking) is modeled through provider-agnostic primitives with provider-specific adapters underneath. In v1, Payouts supports USDC, USDT, and EURC across EVM networks and Solana, with an architecture designed to make additional providers incremental rather than disruptive additions.

Stablecoins are no longer experimental infrastructure. Institutions now require pricing discipline, best-execution posture, resilience, and governance that can withstand scrutiny. Payouts exist because the market has reached the point where single-rail dependency is no longer sufficient. Payouts delivers programmable payout orchestration with institutional control preserved.

A unified payout lifecycle built for real-world flows

Quote normalization

The lifecycle starts with quotes. Dfns provides a Quote endpoint that acts as a normalization layer: customers request a quote in a mostly stable schema, Dfns maps it to the provider’s quote APIs, and returns a standardized list of quotes with consistent fee and net-receive information. This is intentionally a POST (not a GET) because some providers support executable quotes or require quote persistence, and the API needs to accommodate both. In Borderless’ case, an important nuance is that quotes are point-in-time references, not executable rate locks, there can be drift between quoting and settlement, and teams should treat that as market execution rather than limit-order execution. (This becomes even more important as we integrate providers with different quote semantics, including providers where quotes are executable.)

Payout intent creation

After quote selection, customers create a payout intent. This step is deliberately modeled as an intent because payout providers often require asynchronous steps before you can settle. For example, depending on corridor and institution, settlement instructions (including a deposit address) may arrive asynchronously via webhook after compliance checks, beneficiary validation, or internal approvals. In the Borderless flow, once an intent is created, Dfns moves into a waiting state until Borderless provides the final settlement instructions.

Provider-agnostic status model

This is where we introduce a consistent, Dfns-managed status model to abstract provider-specific state machines. The statuses are designed to reflect what the customer needs to do next and what the system is waiting on, not what any single provider happens to call the state. In v1 you’ll see a progression like:

• BeneficiaryDetailsRequired: payout intent created; waiting on provider to asynchronously provide deposit instructions
• DepositRequired: instructions are available; waiting for the on-chain deposit to be sent
• DepositProcessing: funds broadcast on-chain; waiting for confirmations and provider acknowledgement
• DisbursementPending: crypto delivered to provider; waiting for fiat remittance off-chain
• Completed / Failed

To avoid intents living forever, Payouts includes Time to Live (TTL) management: intents can expire if they remain in an awaiting state beyond the provider’s validity window, and Dfns can automatically close them as failed/expired based on that TTL.

Closed-loop settlement confirmation

Once settlement instructions are available, the actual on-chain move is executed through Dfns. This is the part that makes the integration materially safer and more operationally robust than “just send stablecoins to a deposit address and hope for the best.” Payouts provides an Action endpoint (with a Confirm action in v1, and a Cancel action to abort an intent). The Confirm action performs closed-loop verification before broadcasting anything: Dfns checks that the transfer parameters (asset, amount, destination deposit address, network) match what the provider expects for that payout. This is intentionally designed to eliminate the most common payout failures: manual copy/paste mistakes, sending to an expired deposit address, mismatched amount/asset, or settling before the provider is actually ready. After broadcast, Dfns tracks the resulting transfer and associates it back to the payout, including linking to the transaction hash when available.

Webhook-first, signed, and verifiable

Because this is an institutional flow, webhooks and integrity matter. Providers like Borderless (and others we plan to integrate) use signed webhooks for status updates and instruction delivery; Dfns validates these requests and then publishes its own normalized webhook events to customers:

• payout.status.updated
• payout.completed
• payout.failed

The design also assumes reality: webhook delivery can fail. Payouts therefore include mechanisms for reconciliation via status reads, and the provider/status indexing needed to backfill or recover if a provider is temporarily down or if events need to be replayed.

Routing and authorization should be separate systems

The easiest way to understand the Dfns/Borderless model is to separate routing from authorization. Borderless acts as a routing and best-execution layer across a network of payout providers: it compares paths, pricing, and availability and returns the best options for a given corridor, currency, and amount. Dfns sits underneath as the wallet, policy, and execution control layer: it determines whether a payout is allowed, enforces approvals and limits, and signs the on-chain settlement securely.

Borderless finds the best route. Dfns decides whether it’s allowed based on real time evaluation via the policy engine. That separation exists for a reason. Most teams entering stablecoin payouts hard-code a single provider early on. It’s fast, but it creates structural problems later: lock-in, weak price discovery, operational fragility, and a growing inability to evidence execution quality. When one provider controls pricing, routing, and settlement, there’s no real competition per transaction, no redundancy when a corridor degrades, and limited ability to demonstrate that you are consistently selecting competitive rates. Payouts are built to change the default: you don’t pick a provider upfront and live with it. You select the best route for each transaction while keeping the same wallet controls, the same policy posture, and the same audit story.

This is more than “1 wallet + 1 payout provider.”

The result is a payout capability that looks like a native part of Dfns rather than a one-off vendor integration. Customers get a consistent API and dashboard experience, normalized quotes, intent creation with idempotency support (externalId), asynchronous instruction handling, policy-gated execution, and an auditable state machine while remaining free to route across providers. 

And that’s the strategic shift we’re making with Payouts. We are not launching “a Borderless integration.” We are launching an orchestration-friendly payout layer where providers compete per transaction and Dfns remains the constant: the wallet infrastructure, the authorization boundary, and the execution control plane.

Borderless is the first provider we’re shipping with because it gives immediate global coverage and orchestration benefits. Over time, as we integrate additional networks (including ones with different quote semantics and different compliance requirements), the value of Payouts compounds: customers will be able to expand coverage, improve execution quality, add redundancy, and evolve their rails without rebuilding their security posture or rewriting their payout integration.

If you’re already using Dfns and you need stablecoin off-ramps, Payouts is live and ready to adopt after Borderless onboarding. If you’re building a stablecoin product and you don’t want your business logic welded to a single provider from day one, this is the model we think the market has been missing: programmable payout orchestration, with institutional-grade wallet controls at the core.

Note that payouts work seamlessly for both Dfns’ org-controlled (i.e. custodial) and user-controlled (i.e. non-custodial) wallets. Non custodial payouts can only be initiated by the wallet’s signer—not account administrators.

Dfns does not store end-user PII

A key design constraint is privacy and regulatory architecture. Dfns does not store KYC/KYB or end-user PII. Off-ramping requires identity verification and remittance details (beneficiary information, bank instructions, and often terms-of-service acceptance). In this integration, those flows live with Borderless and its participating institutions, and Borderless provides UI widgets to streamline them. What Dfns does at the moment of execution is a just-in-time spot check: when a payout is invoked, Dfns verifies with Borderless that the beneficiary/identity being referenced is valid and that the originating wallet address matches what Borderless expects for that identity. This preserves Dfns’ “custody/control plane” role without turning Dfns into a PII processor.

Get started with Dfns Payouts now

If you’re already a Dfns client:

1. You onboard with Borderless directly and connect it to your Dfns organization (API key model).
2. You can initiate payouts via API and (where relevant) via Dashboard experiences.
3. You receive normalized quotes, create payout intents, settle on-chain through Dfns, and track completion through webhooks and status endpoints.

If you’re evaluating stablecoin payouts and wallet infrastructure together, the key question is whether you want a single-rail dependency or a programmable orchestration layer where security and control remain independent of the payout venue.

• Request a demo: dfns.co‍
• Start integrating today: app.dfns.io