Identity checks in a card program are a chain of contracts. The gap opens where the data stops moving up the chain.
A stablecoin card has two identity problems at once. The card side inherits the rules that govern any issued credential, which means a bank somewhere owns the anti-money-laundering program. The funding side comes from a blockchain, where the sender may be a wallet nobody has ever verified. Programs that handle both well tend to say little about it. Programs that handle one and assume the other are where supervisors are now looking.
The clearest description of how this breaks came in February, when Fintech Business Weekly traced cards advertised as requiring no identity checks back through the layers that issued them.
The corporate issuing gap
The mechanism is not a hack. It is a normal feature of commercial card programs used abnormally.
When a company is onboarded to a card program, the business is verified. After that, as the investigation into corporate issuing loopholes put it, “cards can be created for individual employees, contractors, and so forth, typically without any additional verification.” That is how expense cards work everywhere. It is also a straight path to an unverified card if the company doing the onboarding is a front for selling credentials.
The reporting traced those cards to BINs from several United States banks, including Sutton Bank, Fifth Third, Central Trust Bank, Regions, and Column, through program managers and intermediaries sitting in between. The banks were several steps removed from whoever ended up holding the card, which is the point and not the defense.
The author’s conclusion is the sentence every partnership team should read twice. “Responsibility for BSA/AML compliance is often passed down a chain of partners, with collection of necessary information typically resting with the user-facing entity. But, all too often, the data doesn’t flow back up to the regulated entity.”
Where the obligation actually sits
Strip away the branding and a card program has three layers with different obligations.
The issuing bank is the regulated entity. It holds the BIN, answers to a supervisor, and owns the anti-money-laundering program whether or not it ever meets a cardholder. The program manager operates the mechanics, sets policy in software, and holds the contract with the brand. The consumer-facing company, the wallet or app whose logo is on the card, collects the identity documents because it is the one with the user.
The obligation and the data therefore sit in different places by default, which is the structural problem. Federal regulators said as much in their July 2024 joint statement on bank arrangements with third parties: a bank’s use of third parties “does not diminish its responsibility to comply with all applicable laws and regulations,” and a bank that cannot reach the third party’s system of record may not be able to determine what it owes or who its customers are.
That guidance was written for deposit programs after a well-publicized failure. It reads like a specification for stablecoin card programs, where the system of record is split between a bank ledger and a blockchain.
Read more: Stablecoin corporate cards reach companies outside crypto • When a stablecoin card program fails, who gets the money back
What the funding leg adds
Card rules assume money arrives from an account. In these programs it arrives from an address.
That changes the exposure. In March, CoinDesk reported the Financial Action Task Force’s assessment that stablecoins made up 84% of $154 billion in illicit virtual asset volume during 2025, and that peer-to-peer transfers through unhosted wallets are a “key vulnerability” because they can happen without anti-money-laundering controls. Those FATF findings describe the exact flow a self-custodial card program relies on: tokens moving from a user’s own wallet into a spending arrangement.
Europe has already written rules for that leg. The Transfer of Funds Regulation has applied since December 30, 2024, with no minimum threshold, so every crypto transfer between regulated providers carries originator and beneficiary details. Under the EU travel rule, transfers to and from self-hosted wallets fall within scope when a provider is involved, and above 1,000 euros, the provider must obtain proof that its customer controls the wallet.
A program issuing in Europe has to solve this. A program issuing only in the United States has been able to treat it as a policy choice, and that is the asymmetry closing next.
What the new American rules cover, and what they leave out
Two proposals from this year matter here, and both are narrower than the headlines suggest.
In April, FinCEN and OFAC proposed a stand-alone Bank Secrecy Act framework for permitted payment stablecoin issuers. It requires the familiar program elements, risk-based controls, independent testing, a named compliance officer, training and customer due diligence, and it adds what Covington called the first explicit federal mandate for a private party to run an effective AML and sanctions program. Issuers would also need the technical ability to identify, block, freeze or reject secondary market transactions.
In June, FinCEN and the four banking agencies proposed a customer identification program for those same issuers: name, date of birth or formation, address and an identification number, risk-based verification, and records kept for five years after an account closes. Comments closed on August 21.
Now the part that matters for cards. Both proposals draw a line between the primary market, where someone mints or redeems directly with the issuer, and the secondary market, where tokens change hands between people. Only primary market participants are customers. Someone who buys tokens on an exchange, moves them to a wallet and funds a card has no identification relationship with the issuer at all.
So the rules being written for stablecoins do not identify the people spending them. They regulate the issuer’s front door. Everything downstream of that door still depends on the card program’s own controls.
Sanctions are the sharper edge
Money laundering controls get the attention, and sanctions exposure is the faster way to lose a licence.
The February reporting included a service that marketed cards to Iranian users as a way around restrictions on their domestic bank cards. A card program sitting on top of a token balance can look like an ordinary purchase at the terminal while the funding came from a jurisdiction the issuer is prohibited from serving, and the screening that catches it has to run in two places at once: against the cardholder and the merchant on the card side, and against the sending address on the token side.
The April proposal from FinCEN and OFAC pushes in the same direction by requiring issuers to hold the technical ability to identify, block, freeze, or reject transactions in the secondary market. A card program that cannot see where its funding came from is asking its bank to accept that exposure blind.
That makes the program the control point
Which brings the question back to the people running card programs, and to the banks sponsoring them.
If the issuer does not know the holder and the chain does not carry an identity, then the card program is the first place a real name attaches to the money. Every control that matters sits there: identity verification at onboarding, sanctions screening at authorization, monitoring of the funding addresses, and a record the bank can actually reach.
None of that is exotic. It is the standard bank program applied to a new funding source, and the work is in the plumbing, not the policy document.
Self-custody does not remove the identity question
One misunderstanding is worth clearing up, because it shows up in product decks.
A self-custodial card changes who holds the money. It does not change who has to be identified. The card is still issued under somebody’s licence, that licence carries the identity obligation, and the cardholder still signs up, submits documents, and gets screened. What self-custody removes is the custody risk, which is a different problem with a different owner.
The second misunderstanding runs the other way. Verifying the cardholder does not tell you anything about where the tokens came from. A user can pass every identity check and still fund the card from an address that has been receiving proceeds from somewhere else, which is why the funding leg needs its own controls rather than inheriting comfort from the onboarding file.
What sponsor banks are asking for now
Partnership teams report the diligence has tightened, and the questions have become specific. Six come up repeatedly.
Who performs identity verification, named entity by named entity, for every card type the program issues. What happens on corporate programs, where the answer must cover the individuals receiving cards and not only the company signing the contract. Whether identity records sit at the bank or only at the fintech, and how fast the bank can pull them. How the funding leg is screened, including blockchain analytics on the addresses sending tokens into the program. How sanctions screening runs at authorization rather than at onboarding only. And what the termination rights look like when a partner will not produce records on request.
A program that can answer those in writing is a program a compliance committee can approve. One that cannot is asking the bank to carry a risk it cannot see, which is the arrangement the 2024 guidance was written to stop.
The friction lands where the growth is
There is a real tension in all of this, and pretending otherwise helps nobody.
The markets where stablecoin cards are growing fastest are the ones where identity infrastructure is thinnest. Document coverage is patchy, address verification often means a utility bill that does not exist, and the customer a program most wants to serve is frequently the hardest one to verify against a database built for another country.
That is an argument for better verification methods, not for skipping them. Risk-based verification, which the American proposals explicitly allow, is designed for exactly this problem: documents where they exist, non-documentary methods where they do not, and a standard of forming a reasonable belief about who the customer is. The programs that solve verification in hard markets will end up with a moat, because the compliant path there is genuinely difficult to build.
The cost of getting it wrong is already visible
Supervisors have shown they will act on the licence rather than on a fine.
In March, the Bank of Lithuania revoked the electronic money licence of Paytend Europe, citing systematic failures in transaction monitoring, suspicious activity reporting and internal controls. The February reporting also noted that one of the American banks whose BINs appeared on no-KYC cards had received a consent order two years earlier over Bank Secrecy Act controls and third-party oversight, and that similar activity continued through its programs afterward.
The pattern in both cases is the same. The regulated entity was not the one selling the card, and it was still the one holding the consequence. For the sponsor banks deciding whether to enter this market, that is the fact that sets the price of admission, and it is a separate question from the capacity shortage that made the card enabler layer so concentrated in the first place.
Why the timing is tight
Visa has said it expects the number of stablecoin-linked card programs on its network to roughly double this year, from a base of more than 130 programs across more than 50 countries at the start of 2026. Every one of those programs needs a named owner for identity verification, a data path back to a regulated entity, and a screening design for the funding leg.
The supervisory calendar is moving in parallel. The OCC has said it wants final GENIUS Act rules by November, the stablecoin identification proposals are through their comment periods, and the law takes effect on January 18. Programs being designed now will launch into a rulebook that did not exist when they were scoped.
What would close the gap
Four things would do more than another framework.
Contractual clarity that names the entity responsible for verifying each cardholder, published in the program’s compliance summary rather than buried in a schedule. Identity records held at the regulated entity, not only at the user-facing brand, so the bank can produce them without asking permission. Screening of the funding addresses as a standard control, given what FATF says about where the risk concentrates. And enforcement that lands on a card program rather than an issuer, which has not happened yet in the United States and which would tell the market more than any proposal.
The technology here is not the hard part. Somebody has to know who is holding the card, and the industry has built an architecture in which that somebody is easy to leave undefined.