Programmable Compliance: Which Rules Travel with the Money, and How?

As money becomes programmable, across central bank digital currencies, tokenized deposits, and stablecoins, a real question is emerging about where compliance should live: embedded directly in the asset as a rule that travels with it, layered on top through richer messaging and real-time screening, or enforced separately by whichever party touches the transaction last.

Players are all building credible but different answers in parallel, and none has converged on how these should interoperate across jurisdictions with different compliance regimes. The stakes are rising on every front — real-time cross-border settlement, tokenized securities, and increasingly, autonomous agents initiating transactions on their own — all of which need a compliance check at the moment value moves, not after. What would each of these approachestto programmable compliance actually need to interoperate, and which rules win when they conflict across borders?

Discussion questions:
1.         Should compliance logic live in the asset itself, in the messaging/settlement layer, or in a separate real-time screening service, and does the answer change depending on whether it's a CBDC, a tokenized deposits, or a stablecoin?
2.         When a transaction crosses borders, whose compliance rule actually governs — sender's jurisdiction, receiver's, or the rail's — and what happens when they conflict?
3.         Retrofitting compliance onto existing settlement infrastructure and building it in from scratch are both live strategies right now — what would each need to prove to become the default, and is convergence between them actually possible?
4.         As more transactions — including those initiated by autonomous agents — require a compliance check the moment value moves, what are the minimum interoperability standards needed for rules to actually travel with money across rails?