From Payment Transparency to Technical Capability: What FATF Recommendation 16 Means for Public Blockchains
Katashe Solutions recently contributed a permissionless public blockchain perspective to the Singapore industry response to the Financial Action Task Force’s consultation on its draft Guidance for the implementation of Recommendation 16. The consultation follows FATF’s June 2025 amendments to Recommendation 16, which governs the information that should accompany payments and value transfers. The joint industry submission, made by ACCESS, the Digital Assets Association and the Singapore FinTech Association, focuses on how those requirements can be implemented clearly, proportionately and in a technologically neutral way across different payment infrastructures.
For public blockchains, the central policy challenge is increasingly one of translation.
Recommendation 16 is designed around payment transparency: identifying the relevant parties, preserving originator and beneficiary information, and ensuring that regulated institutions can use that information for AML/CFT purposes. Public blockchain infrastructure introduces a different technical architecture through which those same objectives may need to be achieved.
The task for regulators is therefore to understand how payment instructions, transaction execution, identity information and risk signals map across this architecture.
Follow the payment instruction
One of the most useful principles in FATF’s draft Guidance is its distinction between the route of the payment instruction and the route through which funds are funded or settled. The Singapore industry response supports this as the starting point for identifying the ordering, intermediary and beneficiary financial institutions within a payment chain.
This distinction is especially useful for public blockchain transactions.
A single user instruction may interact with several smart contracts, liquidity pools or protocols before reaching its intended economic outcome. A swap may be followed by a bridge. Collateral may be deposited or withdrawn. Assets may pass through automated protocol functions as part of a single transaction sequence.
The payment chain therefore needs to be understood by reference to the financial function being performed and the instruction being acted upon.
This also helps clarify the role of technical participants.
Validators, node operators and block builders may verify protocol rules, propose blocks, or select and sequence transactions for inclusion. These activities influence transaction execution and ordering. FATF’s framework can then assess separately whether any participant is also performing a covered financial service or exercising control or sufficient influence over a qualifying DeFi arrangement.
The policy value of this approach is precision: regulatory obligations follow the relevant financial function.
Public blockchain tracing is a specialist capability
Public blockchains also introduce a significant new source of financial intelligence: transaction transparency.
Transaction histories, fund flows and smart contract interactions can often be observed directly on-chain. This creates analytical possibilities that are unavailable in many conventional payment systems.
At the same time, reconstructing complex DeFi activity can require considerable technical expertise.
A single user authorisation may trigger activity across multiple contracts or networks. Analysts may need to determine what each address or contract is doing, how assets moved, which interactions were automated, and whether any address can be attributed with confidence to a particular person or service provider.
This makes blockchain analytics and forensic capability increasingly relevant to Recommendation 16 implementation.
Specialist blockchain analytics and forensic providers already trace fund flows, identify transaction patterns and support attribution across public networks. They can provide an important starting point for institutions and supervisors that require these capabilities.
The longer-term requirement is broader.
Financial institutions, VASPs and supervisory authorities also need the ability to interpret the resulting analysis: to understand the basis for an attribution, the degree of confidence attached to it, the limits of the evidence, and the regulatory conclusion that the evidence can reasonably support.
The practical question is how regulated FIs, VASPs and supervisory authorities can access and apply specialist blockchain analytics and forensic expertise where needed, while maintaining appropriate oversight over the providers and the conclusions drawn from their tools.
Distinguish transaction provenance from identity
Public blockchain transparency is especially useful when it is paired with clear evidential categories.
A blockchain address is a technical identifier. Establishing who controls or owns that address may require several additional sources of evidence.
For example, wallet signing can establish control of a private key. Address attribution may also rely on blockchain analytics, counterparty information and other supporting evidence. In practice, some conclusions will carry a higher degree of certainty than others.
This creates an important distinction between:
transaction provenance, which describes where value moved on-chain;
address attribution, which links an address or cluster to a particular service, entity or person with a stated level of confidence; and
verified identity, which establishes the legal person behind the activity.
Keeping these categories separate improves the quality of regulatory decision-making.
The same distinction applies to origin-of-funds analysis.
In a DeFi transaction, the immediately preceding on-chain sender may be a smart contract or liquidity pool. The relevant analysis therefore needs to distinguish protocol-level transaction provenance, the Recommendation 16 originator, and any wider origin-of-funds inquiry required under the risk-based framework.
Public-chain history can strengthen this analysis substantially. The key is to interpret the technical evidence in the context of the regulatory question being asked.
Technology neutrality requires technical understanding
FATF’s technology-neutral and risk-based approach provides the right foundation for this work.
The implementation question is how those principles translate across payment architectures with different technical characteristics.
The internet provides a useful comparison.
Regulated commercial and financial services operate over shared internet infrastructure. The internet provides common technical protocols that enable those services to communicate and transact.
Permissionless blockchains also provide shared infrastructure, while adding an additional capability: smart contracts can encode and automatically execute elements of financial logic. Settlement, transaction execution and parts of a financial arrangement can therefore occur directly through shared protocol infrastructure.
That distinction matters because effective regulation depends on understanding what the technology is actually doing.
Katashe’s submission therefore calls for practical guidance on how regulators, supervisors and obliged entities can develop or access the technical capability required to assess the function and risk of different blockchain architectures, including through blockchain analytics firms, forensic specialists, technical service providers, industry expertise and supervisory capability building.
This is where technology neutrality becomes operational.
It allows the same regulatory objective to be pursued through different technical arrangements, provided regulators understand how those arrangements work and how the relevant risks are addressed.
Separate settlement data from compliance data
Recommendation 16 also raises an important architectural question: where should the required originator and beneficiary information reside?
Katashe supports an outcome-based approach.
The essential requirement is that obliged entities can obtain, use and make available the Recommendation 16 information required for their role. That information can remain securely linked to the transaction without being embedded directly into the public settlement layer.
This opens the door to architectures in which:
the blockchain provides settlement and transaction integrity, while
a separate compliance-data layer carries the required originator and beneficiary information.
Such an approach can support payment transparency while also addressing privacy, data minimisation and cross-border data protection requirements.
Holistic monitoring needs an evidential method
The same capability question becomes even more important in holistic ongoing monitoring, or HOM. Public blockchains can strengthen HOM by providing transaction histories, flow patterns and network-risk indicators that are often unavailable in account-based payment systems.
The practical challenge is turning those signals into reliable compliance conclusions.
Katashe proposed an evidence-led methodology.
The process would begin with a defined risk trigger or anomaly. Where tracing is warranted, institutions would use or access appropriate blockchain analytics or forensic capability to reconstruct relevant flows. Analysts would then classify the functions of addresses, smart contracts and service providers, test clustering and attribution hypotheses, corroborate material conclusions with additional evidence where available, and calibrate escalation or adverse action to the strength of the evidence.
This creates a simple evidential principle:
the significance of the regulatory conclusion should determine the level of corroboration required.
That matters because blockchain analytics frequently involves inference. Address clusters, transaction patterns, indirect exposure and network relationships can all provide valuable risk signals. Their evidential weight can vary considerably.
Effective supervision therefore depends on both access to analytical tools and the institutional capability to interpret their outputs appropriately.
The next regulatory challenge is capability
The first phase of virtual asset regulation focused heavily on perimeter questions: which entities fall within scope, which activities constitute VASP services, and how existing AML/CFT obligations should apply to digital assets.
The next phase is increasingly about technical and supervisory capability.
As financial activity moves across conventional institutions, VASPs, self-hosted wallets, smart contracts and tokenised assets, regulators need a more detailed understanding of how transactions are executed and how evidence is generated.
For Recommendation 16, that means:
following the payment instruction through complex technical environments;
building access to specialist blockchain tracing and forensic capability;
distinguishing transaction provenance, attribution and verified identity;
designing compliance-data architectures that work alongside public settlement infrastructure; and
developing an evidential discipline for the use of public-ledger analytics.
The objective remains the same: effective payment transparency and robust AML/CFT controls.
The emerging policy challenge is ensuring that institutions and supervisors have the technical capability to achieve those outcomes across a new generation of financial infrastructure.
