You're the Regulated Entity. Your Partner Initiated the Transaction. Now What?

Synapse collapsed. Cross River got a consent order. Evolve got an enforcement action. If you were paying attention to the BaaS space in 2024 and 2025, you watched the same story repeat: a regulated entity provided infrastructure to fintech partners, the partners moved fast, compliance gaps opened between what the partner was doing and what the bank was monitoring, and the regulator showed up at the bank's door. Not the partner's door. The bank's.

That pattern is about to repeat with stablecoins, and it will be worse.

SoFi just launched white-label stablecoin infrastructure. Their system enables banks, fintechs, and enterprise partners to leverage SoFi's regulatory, operational, and reserve framework to issue white-label stablecoins or integrate SoFiUSD into their settlement flows. Cross River provides stablecoin payments to 80+ fintech partners. BVNK just took Citi's investment and serves enterprise clients. Every one of these platforms faces the same structural problem: they hold the license, they carry the BSA obligations, but their partners initiate the transactions, onboard the end users, and control the customer relationships.

The compliance gap between "we provide the infrastructure" and "we're responsible for every transaction on it" is exactly where enforcement actions come from. And stablecoins amplify every dimension of that gap.

The liability asymmetry

Your partner gets the customer relationship and the revenue share. You get the examiner's letter.

This isn't new. Every BaaS bank has lived this tension. What's new is that stablecoins remove the safety nets. Traditional BaaS had clawback mechanisms. ACH returns. Wire recalls. Chargeback windows. If your partner's end user did something suspicious, you had time. You could pull the money back. You could freeze the account. You had a buffer between "something went wrong" and "the money is gone."

On stablecoin rails, that buffer is zero. A USDC transfer on Base confirms in two seconds. It's final. It's irreversible. When your partner's end user sends $50,000 USDC to a sanctioned wallet through your infrastructure, you cannot reverse it. There is no "recall" transaction. The USDC is at that address and nobody can move it except the private key holder.

The GENIUS Act requires all permitted payment stablecoin issuers to comply with US anti-money laundering and sanctions requirements, including implementing AML and sanctions programs and annually certifying compliance. That annual certification is yours. Your partner doesn't file it. Your partner doesn't sign it. If one of your partner's end users sent funds to a sanctioned address through your infrastructure, it's your certification that's at risk.

I keep coming back to the asymmetry. Your partner builds a great product on top of your rails. They grow fast. They onboard thousands of users. Revenue share checks start coming in. Then a FinCEN examiner asks about one transaction from one of those users, and you realize you have no idea what your partner's KYC process actually looks like, because you delegated it to them in the partnership agreement. That delegation doesn't hold up when the examiner is sitting in your conference room.

The multi-tenant monitoring problem

Here's an architectural problem that sounds simple and isn't.

Your BSA program needs to do two things that conflict with each other. First, it needs to monitor transactions across all partners in aggregate. Suspicious patterns don't respect tenant boundaries. If someone is structuring transfers across three of your partners, you need to see all three streams in a unified view to catch it. Second, when an examiner asks about a specific partner's activity, you need to produce a clean, isolated audit trail for just that partner's transactions. No data from other partners. No cross-contamination. Per-partner audit trails that protect each partner's confidentiality.

Aggregate monitoring requires unification. Per-partner audit trails require isolation. Most compliance systems are built for one or the other.

Someone on my team suggested "just add a partner_id column" last year. I wish it were that simple. The aggregate monitoring needs to join across partner_ids to detect cross-tenant patterns. The per-partner exports need to filter by partner_id and provably exclude everything else. You need index structures optimized for both queries. You need access controls that let your BSA team see the unified view while generating partner-specific exports that contain only that partner's data.

Then there's the timestamp problem. Different partners integrate at different times. Some send transactions in real time. Others batch. Some use webhooks, others poll. Your aggregate view needs to handle all of these ingestion patterns and produce a coherent timeline. When the examiner asks "what happened at 2:14 PM?" your answer needs to account for the fact that Partner B's transaction from 2:14 PM might not have arrived in your system until 2:17 PM.

The architecture for multi-tenant stablecoin compliance is genuinely hard. And most platforms are discovering this only after they've already onboarded their first few partners.

Velocity detection gap across tenants

This is the scenario the examiner will construct. I'm convinced of it.

A user holds wallets through three of your partners. Through Partner A, they send $3,200 USDC at 12:08 PM. Through Partner B, $3,100 at 1:41 PM. Through Partner C, $3,300 at 3:52 PM. Each individual transaction is below the $3,000 Travel Rule trigger. Each looks unremarkable in isolation. Your per-partner monitoring sees three separate, quiet activity streams.

In aggregate, that's $9,600 in transfers within four hours. The pattern is textbook structuring. The amounts are just below the reporting threshold. The timing is compressed. The destinations may or may not be related.

Your system never flagged it. Why? Because your tenants are siloed. Partner A's monitoring system has no visibility into Partner B's transactions. Your aggregate monitoring, if it exists, might not be connecting wallets across partners to the same underlying user.

This is the identity resolution problem buried inside the multi-tenant monitoring problem. It's not enough to aggregate transactions across partners. You need to know when the same person is operating through multiple partners. On traditional BaaS rails, you could sometimes catch this through SSN matching or email deduplication. On stablecoin rails, the "identity" is a wallet address, and a single user can trivially create a different wallet for each partner.

I don't have a clean solution for this. Nobody does, honestly. But I know the examiner will ask the question, because structuring detection across tenants is exactly the kind of vulnerability that enforcement actions are built around. If you're running a multi-tenant stablecoin platform, you should at minimum be logging the fact that your cross-tenant detection has known gaps, and documenting what you're doing to address them. The worst position is to not have thought about it at all.

The partner compliance certification problem

Here's the last piece, and in some ways it's the most uncomfortable.

Your partners have their own regulators. They need to demonstrate to those regulators that their stablecoin operations are compliant. But their compliance evidence lives in your systems. The transaction logs, the screening results, the alert dispositions, the audit trails. All of it is in your database.

When you produce a compliance report for Partner A, you're asking Partner A's regulator to trust you. To trust that the report is accurate. To trust that it's complete. To trust that you included all the relevant transactions and didn't omit anything embarrassing.

But you're the entity with a financial incentive in the partnership. If Partner A's compliance looks bad, it might jeopardize the partnership. At minimum, it creates an uncomfortable conversation. Your partner's regulator knows this. They know you have a motive to present the data favorably. "Trust us, we're compliant" is not sufficient when the entity saying "trust us" benefits from the relationship continuing.

What partners actually need are independently verifiable compliance artifacts. Records that the partner can validate without your involvement. Reports that contain enough cryptographic evidence that a third party can confirm the data is accurate and hasn't been selectively edited.

This is a hard technical problem. How do you produce a per-partner compliance export that is provably complete? Provably unmodified? Provably sourced from the actual transaction data and not a curated subset? Traditional audit approaches rely on the auditor having access to your full system. But in a multi-tenant model, giving Partner A's auditor access to your full system would expose Partner B's data.

The answer, I think, involves making each transaction's compliance evidence self-contained and independently verifiable at the time of creation. If the evidence is generated and committed when the transaction happens, rather than compiled after the fact, the partner and their regulator can verify it without depending on your cooperation. But very few platforms have built this capability.

The pattern we already know

The regulatory pattern from traditional BaaS is clear. The OCC issued consent orders against banks for failing to adequately supervise their fintech partners' BSA compliance. The FDIC did the same. In every case, the enforcement action landed on the regulated entity, not the partner. The regulated entity was expected to have controls. They were expected to monitor. They were expected to catch the problems their partners created.

The same pattern will apply to stablecoin infrastructure providers. Probably faster. Because stablecoin transactions are on-chain, and examiners can independently verify what happened. The transparency that makes blockchain attractive for settlement also makes compliance failures more visible. On traditional rails, the examiner sees what you show them. On stablecoin rails, the examiner can pull the on-chain data themselves and compare it to your records.

If you're providing stablecoin infrastructure to partners, the compliance architecture you need is fundamentally different from the compliance architecture you probably have. Multi-tenant monitoring with cross-tenant detection. Per-partner audit isolation with independently verifiable exports. Real-time screening with zero-latency alert generation. And an awareness that when something goes wrong on your partner's side, the letter is coming to your address.

The first stablecoin-specific BaaS consent order hasn't happened yet. But the conditions that produced the traditional BaaS enforcement actions, rapid partner growth, delegated compliance, insufficient monitoring, are all present in the stablecoin infrastructure space. The institutions that build the right architecture now will survive the first enforcement cycle. The ones that bolt stablecoin operations onto their existing compliance stack will be explaining to the examiner why their system didn't catch the $9,600 structured across three tenants.

Vinay Narayan is the founder of Legaci Labs. He holds a patent on tamper-evident digest chains for agent audit trails.