Crypto’s infrastructure problem is no longer limited to making transactions faster or cheaper. The harder task is determining whether a transaction should happen at all—and under which rules.
Three developments this week illustrate the problem from different directions. The U.S. Commodity Futures Trading Commission is reportedly moving to bring event contracts within swaps regulations while a legal fight over those products continues. The U.S. Treasury is targeting $1 billion in crypto allegedly linked to Iran as part of its sanctions strategy. In Europe, regulators are reviewing the use of tokenized assets as collateral.
These are policy stories, but they are also software stories. Each one asks financial platforms to identify something a blockchain address alone cannot explain: what a product legally is, who may use it, where the parties are located, and whether an asset is eligible for a particular financial purpose.
That context must eventually become machine-readable. Otherwise, crypto companies will keep building programmable money on top of compliance systems that still depend on spreadsheets, manual reviews, and hurried interpretations of breaking news.
A token does not carry its complete legal status
Public blockchains are good at recording transfers. They can show that one address sent a token to another, when the transfer occurred, and which smart contract processed it.
They generally cannot tell an application whether the token represents permissible collateral, a restricted financial product, a sanctioned interest, or something regulated differently in two jurisdictions.
Consider event contracts. A customer may see a simple yes-or-no market tied to an outcome. The software may see a smart contract, an order book, and settlement instructions. A regulator may see a swap or another category of derivative.
That classification changes the product. It can affect who may trade, what disclosures are required, which intermediary can offer access, how records must be retained, and whether a market can operate in a given location.
The reported CFTC move matters because product classification cannot remain a paragraph buried in a legal memo. If event contracts are folded into swaps regulation, affected platforms will need to translate that treatment into account permissions, market availability, reporting workflows, and transaction controls.
Code may execute the contract, but code does not decide the contract’s legal category. People and institutions do. The challenge is getting that decision into the product without introducing ambiguity at every step.
Sanctions controls require more than an address blacklist
The Treasury’s effort to seize crypto allegedly connected to Iran presents a related infrastructure problem.
Blockchain analytics can help trace flows between addresses, but a sanctions decision involves more than spotting a transaction on a ledger. Platforms must connect addresses with identities, entities, jurisdictions, ownership relationships, and government actions. Those associations can change as new information becomes available.
A static blacklist is therefore an incomplete solution. It may identify an address that has already been designated or flagged, but it cannot by itself answer every question around control, exposure, or the handling of funds that pass through multiple services.
That matters for ordinary crypto businesses as much as it does for large exchanges. A payment processor, wallet provider, stablecoin issuer, or over-the-counter desk may need to determine whether to permit, pause, reject, or escalate an activity. Each decision also requires an audit trail explaining what the system knew at the time.
The practical architecture begins to resemble a policy engine. Transaction data enters on one side. Identity information, jurisdictional rules, risk signals, and asset restrictions enter on the other. The system then applies the appropriate control and records why it did so.
Artificial intelligence could assist with parts of this work. It may help organize regulatory notices, compare policy documents, or route unusual cases to human reviewers. But an AI model should not quietly invent the rule governing a transaction. Legal status needs an authoritative source, effective date, version history, and accountable owner.
A plausible-sounding answer is not enough when software is deciding whether to freeze or release money.
Tokenized collateral exposes the same missing layer
Europe’s reported review of tokenized collateral brings the issue into institutional markets.
Putting an asset on a blockchain does not automatically make it acceptable as collateral. A lender or clearing system still needs to understand what the token represents, who issued it, whether ownership is legally enforceable, how it can be valued, and what happens if the borrower defaults.
Operational details matter too. A token may trade around the clock while its underlying asset, administrator, or redemption process follows limited business hours. Transfers can settle quickly even when the legal process for recognizing or liquidating the collateral does not.
A serious collateral system therefore needs more than a price feed and a wallet balance. It needs data describing eligibility, valuation sources, concentration limits, transfer restrictions, custody arrangements, and the conditions under which the asset can be seized or sold.
Those fields must remain attached to the asset as it moves through different applications. If every platform interprets the token independently, interoperability becomes mostly cosmetic. The token can travel, but its legal and operational context gets lost along the way.
That is the difference between tokenizing an asset and integrating it into financial infrastructure.
AI agents make accurate policy data more urgent
This missing context becomes more important as developers experiment with automated financial agents.
An agent can compare rates, prepare a transaction, move collateral, or rebalance a treasury according to predefined instructions. Yet automation raises an obvious question: How does the agent know which actions are permitted?
A blockchain balance is not sufficient. The system may need to know the account holder’s jurisdiction, the legal category of the product, the identity requirements of the venue, and whether an asset has acquired a new restriction since the previous transaction.
For that to work reliably, policy information needs many of the qualities engineers already expect from market data. It should be structured, attributable, time-stamped, versioned, and available through stable interfaces. Applications also need a safe response when the information is incomplete.
“Do nothing and request review” is often a better default than letting an automated agent make a confident guess.
This will disappoint anyone expecting AI to remove compliance friction through sheer cleverness. In practice, better automation often reveals how much institutional knowledge was previously trapped in email threads and individual employees’ heads. Turning that knowledge into dependable software is slow, unglamorous work.
It is also where a meaningful product advantage could emerge. A platform that can explain why a transaction was permitted or stopped is more useful than one that merely produces a risk score with no traceable reasoning.
What smaller crypto businesses should build first
Most companies do not need to create a global regulatory database from scratch. They do need to stop treating policy as a final check performed after the product has already made a decision.
The first useful step is to separate execution from authorization. A wallet, payment service, or automated treasury tool should establish whether an action is allowed before signing or broadcasting it. When the answer is uncertain, the workflow should pause cleanly rather than fail halfway through.
Businesses should also record which policy version informed a decision. Rules, sanctions information, and product classifications can change. Without a dated record, reconstructing an old transaction becomes difficult precisely when an auditor, banking partner, or customer asks about it.
Finally, human overrides should be explicit. If an employee approves an exception, the system should retain who approved it and what evidence supported the decision. “The model said it was fine” is not durable governance.
The broader takeaway is straightforward: programmable finance needs programmable constraints. This week’s regulatory developments concern different markets, but they point to the same technical gap. Crypto can already move value automatically. The next infrastructure contest is about whether applications can carry the relevant identity, legal, and policy context alongside that value—without pretending software can resolve every judgment on its own.
Educational only. Not financial, investment, tax, or legal advice. Do your own research. Read the full disclaimer.
