Revised FATF Recommendation 16 raises the bar on payment transparency: payment messages must carry more verified originator and beneficiary data, in structured formats, with an implementation horizon of the end of 2030. The revision keeps the travel rule's purpose but extends it, adds fraud as an explicit objective, and asks institutions to detect misdirected payments.
The FATF adopted the revision on 13 June 2025, and it gives an unusually long runway: countries and institutions have until the end of 2030 to comply. Implementation guidance is still being developed, so some mechanics will be settled closer to the deadline.
This guide is written for heads of AML and CTOs at banks, e-money issuers, remittance firms and VASPs who have to plan the data, screening and monitoring changes the revision will require.
What did the FATF change in Recommendation 16?
It expanded the information that must travel with a payment, required that information to be verified and structured, and widened the rule's objectives to include fraud.
The FATF's revision of Recommendation 16 follows the principle of same activity, same risk, same rules. The obligations track the payment, not the technology carrying it. As CGAP's summary sets out, payment messages must carry more originator and beneficiary information, ideally in a structured format such as ISO 20022, and that information must be verified. Fraud is now an explicit objective alongside money laundering and terrorist financing, and the rule references UN Security Council resolutions on proliferation financing. The FATF also cautions that the standard should not harm financial inclusion through overly rigid rules.
What information must travel with a payment now?
For cross-border payments above the de minimis threshold, verified name, account and address or identifier data for both the originator and the beneficiary.
The requirements scale with the payment. For a cross-border payment above the threshold, the message needs the name and account number of both parties, or a unique transaction reference. For individuals it adds the originator's address and the beneficiary's country and town; for legal entities, an official identifier such as a BIC or LEI. The data must be verified. Below the de minimis threshold, which countries set no higher than USD or EUR 1,000, the message needs name and account number for both parties, with verification required only where money laundering or terrorist financing is suspected.

How does the threshold work, and what about misdirected payments?
Countries set a de minimis threshold no higher than USD or EUR 1,000, and above it, beneficiary institutions are expected to check for misdirected payments.
The threshold is a ceiling, not a fixed figure: a country may set it lower, but not higher than USD or EUR 1,000. For cross-border payments above that line, the revision expects the beneficiary institution to use the beneficiary data to detect payments misdirected by fraud or error, which is where the new fraud objective becomes operational. A payment whose stated beneficiary does not match the receiving account is now a signal the institution is expected to catch, not a formatting curiosity. This connects the travel rule to the kind of behaviour our guide to payment screening versus transaction monitoring describes.
How are card and instant payments treated?
Card payments for goods and services stay largely outside the rule when the card number travels; other card uses and instant payments follow the general requirements.
A card purchase of goods or services is largely excluded, provided the card number accompanies the transfer and the institutions' names and locations are available on request. Card payments used for other purposes, such as person-to-person transfers, have to meet the cross-border or domestic requirements like any other transfer. Cross-border cash withdrawals must carry the card number, and the cardholder's name has to be provided within three business days if the foreign acquiring institution asks. Instant payments are not carved out, so a real-time rail has to supply the same data inside its own time budget, which is the harder engineering problem the 2030 runway is meant to absorb.
What should an institution do before 2030?
Map the gaps now in data capture, verification and screening, because the hard part is systems and message standards, not policy.
The deadline is distant, but the work is structural. Four tasks are worth starting early. Confirm which originator and beneficiary fields the institution captures today and which the revision will require. Move toward a structured message standard such as ISO 20022, because unstructured data will not satisfy a verified-information rule at scale. Decide how verification will work for each payment type and channel. And connect the inbound payment data to screening and monitoring, so the richer data improves detection instead of sitting unused. Our transaction monitoring guide and sanctions screening playbook cover the detection side, and our note on why identity verification is not KYC covers what verified data does and does not settle.
What does Recommendation 16 mean for a lean compliance team?
More data to screen, a new fraud signal to act on, and a long runway that rewards planning over a last-minute rebuild.
For a small team, the revision is an opportunity as much as a burden. Richer, verified payment data makes screening and monitoring more accurate. The misdirected-payment check also overlaps with the fraud and scam work many teams already do, a connection our post on scam proceeds and money mules draws out. The risk is leaving the systems work until 2029. A team that maps its data gaps now can phase the change, and can ask vendors the right questions early, which our AML software buyer's guide lists.
How does Fyscal ARCX support payment transparency?
Fyscal ARCX uses the originator and beneficiary data that travels with a payment to screen and monitor it, so richer messages feed better detection instead of adding noise. Real-time screening checks parties against lists as the payment moves. Transaction Monitoring compares the payment against the customer's expected behaviour, and Case Management holds the result with a timestamped trail. As message standards move to structured formats, the same data can drive the misdirected-payment and mismatch checks the revision asks for.
If you want to see richer payment data improve screening and monitoring, book a walkthrough of Fyscal ARCX and bring a payment flow you want to test.

