Thunes vs Tango AML vs StableNet: comparing cross-border payment infrastructure for MSBs

Thunes, Tango AML and StableNet are frequently placed on the same shortlist by money service businesses, but they occupy different layers of the cross-border stack. Thunes is a payout network: one integration that reaches bank accounts and mobile wallets across a wide set of markets. Tango AML is remittance and compliance software: the system of record an MSB uses to onboard customers, screen them and evidence its AML programme. StableNet is a settlement and compliance layer: it carries bank-standard payment messaging and settles the value itself on-chain, with compliance data attached to the transfer. Comparing them like-for-like produces a misleading table; comparing them by the problem each one removes is far more useful.

What does Thunes actually do?

Thunes operates what it calls a Direct Global Network. As of mid-2026 the company states that a single API connection gives its members reach into bank accounts, mobile wallets and, more recently, stablecoin wallets across roughly 140 countries and more than 90 currencies, supported by in-house treasury and compliance systems. Rather than routing through a multi-tiered chain of correspondent banks, Thunes contracts directly with licensed local partners in each market — which is why it can deliver into destinations such as mobile-money schemes that correspondent banking reaches slowly or not at all. It also offers a route for institutions on the SWIFT network to push payments into that network without building a new integration.

The value proposition is reach and simplicity. For a remittance business, a gig-economy platform or a payroll provider that needs to pay out in dozens of countries, replacing dozens of bilateral partner agreements with one commercial and technical relationship is a genuine reduction in complexity. The trade-off is structural rather than a criticism: an aggregated payout network is still, underneath, a network of funded local accounts. Someone has to hold liquidity in the destination market before the payout occurs, and the cost of that liquidity — plus the FX spread applied when converting into local currency — is embedded in the pricing whether or not it appears as a line item. You are outsourcing the correspondent problem rather than removing it.

What does Tango AML actually do?

Tango AML sits at a different layer entirely. It is money-transfer and regulatory-compliance software aimed at MSBs and money transfer operators, designed to keep an operator aligned with the rules of the supervisor that issued its licence. Its published feature set covers the operational core of a remittance business: customer onboarding and KYC, politically-exposed-person and sanctions screening, transaction monitoring and pattern detection, fraud controls, record-keeping, alerting and regulatory reporting, wrapped around a CRM for the customer relationship itself. The company also markets adjacent identity-verification products alongside the core platform.

For an MSB whose existential risk is an examination finding or the loss of a banking relationship, this is the layer that matters most. Regulators do not assess the elegance of your rail; they assess whether you can demonstrate risk-based onboarding, defensible screening, monitoring calibrated to your customer base, and complete records produced on demand. Software of this kind is how a small compliance team makes that demonstrable at scale. What it does not do — by design — is move money. Tango AML orchestrates and evidences the transfer; the transfer itself still executes over whatever settlement arrangement the MSB has, whether that is a correspondent bank, a payout aggregator or an on-chain rail.

Where does StableNet sit?

StableNet addresses the settlement layer and the compliance data that must travel with it. Payments enter over familiar bank messaging — SWIFT MT and ISO 20022 — so an existing payment-operations team is not asked to re-architect around a new format. Settlement then executes as a regulated stablecoin transfer, reaching finality in seconds rather than waiting on correspondent processing windows, with KYC, KYB, KYT, sanctions screening and Travel Rule originator and beneficiary data attached to the payment itself rather than reconciled afterwards. The design goal is that the message and the money arrive as a single verifiable event.

The economic consequence is the one treasury teams care about: because value moves on demand and settles continuously, the requirement to park pre-funded balances in every destination corridor shrinks. That is a different lever from the one an aggregator pulls. An aggregator compresses the number of relationships you manage; an on-chain settlement layer compresses the amount of working capital you must immobilise and the time your funds spend in transit. Institutions that route weekend and after-hours flows, or that operate in thinly-banked corridors where correspondent relationships have been withdrawn, tend to feel that difference first.

Ask a vendor which layer they own end to end and which layers they assume you already have. The gap between those two answers is your integration project.

How should an MSB compare them?

• Start from the binding constraint. If you cannot reach a market, that is a payout-network problem. If your last examination produced findings, that is a compliance-software problem. If your margin is being consumed by pre-funding, FX spread and days-in-transit, that is a settlement problem.
• Separate reach from economics. Counting countries and currencies tells you where you can pay; it tells you nothing about the liquidity you must hold to pay there, or the spread applied on conversion.
• Insist on end-to-end funds availability, not message speed. The number that matters is when the beneficiary can spend the money on a Saturday, not when an instruction was accepted.
• Ask how compliance data travels. A rail that carries Travel Rule and screening data with the payment removes reconciliation work that a rail without it pushes back onto your operations team.
• Map the overlap honestly. Some vendors bundle screening with payouts, others bundle payouts with software; the duplicated licence you are paying for twice is usually visible only once you draw the stack on a whiteboard.
• Test the exception path, not the happy path. Returns, repairs, sanctions hits and beneficiary-data errors are where cross-border operating cost actually accumulates.

It is worth being blunt about a common procurement error. Shortlists are usually assembled from vendors that appear together in search results, not from vendors that solve the same problem. That is how a payout network, a compliance platform and a settlement rail end up in the same evaluation matrix, scored against a single set of criteria that none of them was built to satisfy in full. The stronger approach is to decompose the requirement into reach, compliance operations and settlement, evaluate each layer against vendors that genuinely compete in it, and then examine the seams — because the seams between layers are where cost, latency and audit gaps live.

Do you have to choose only one?

Usually not, and the pretence that you must is the least useful part of vendor comparison. A mid-sized remittance operator might plausibly run compliance software as its system of record, settle high-volume corridors on an on-chain rail to release trapped liquidity, and retain an aggregator for long-tail destinations where local payout rails are the only practical last mile. What matters is that the layers interoperate: that the compliance system can evidence what the settlement layer did, and that the settlement layer does not require a parallel compliance process of its own.

The direction of travel is also worth noting. Payout networks have begun connecting stablecoin wallets alongside bank accounts and mobile money, which suggests the industry consensus is converging on on-chain value transfer as a normal component of cross-border infrastructure rather than an alternative to it. The differentiator over the next few years is unlikely to be whether a provider touches stablecoins at all, and far more likely to be whether compliance is native to the payment or bolted on beside it.

Where StableNet fits

StableNet is deliberately built at the settlement and compliance layer rather than as a payout directory or a standalone AML suite. Institutions connect over the messaging standards they already run, settle in seconds on regulated stablecoin rails, and get screening and Travel Rule data carried with each payment so that operations and compliance are looking at the same record. If your constraint is reach, an aggregator may be the right first purchase. If your constraint is the cost of holding liquidity in every corridor and the days your money spends invisible in transit, that is the problem StableNet was designed to remove.