Introduction
In June 2025, the Financial Action Task Force (FATF) approved the most significant revision of Recommendation 16 since it was first introduced in the period following the September 2001 attacks. The recommendation, which governs the information that must travel with a payment, has been given a new title, “Payment transparency”, and its purpose now extends beyond terrorist financing to money laundering and related offences such as fraud (FATF, 2025a).
Most of the commentary on the revision has focused on policy, technology and implementation budgets. That is understandable, since the changes affect payment systems, card networks, fintech firms and correspondent banks across the world. Less attention has been given to the people who actually handle the payment messages: the branch staff who capture the customer’s instruction, the payments operators who work the repair queues, and the investigations teams who receive an alert and have to decide what it means.
Earlier in my career I worked in payment operations, where SWIFT messages were part of everyday work. From that experience, I would suggest that payment transparency is decided less by the standard itself than by what happens to a message at a small number of points along its journey. This article looks at the revised Recommendation 16 from that operational perspective, and considers what it will require from the people who process payments rather than from the systems alone.
What the revision changes
The revised Recommendation 16 and its Interpretive Note introduce several changes that are directly relevant to banks. The FATF’s explanatory note sets out the following as the most important (FATF, 2025b).
First, the payment chain is now defined by the route of the instruction. It begins with the financial institution that receives the instruction from the originator and ends with the institution that services the beneficiary’s account or pays out cash. Each institution in that chain has a defined responsibility for including information, preserving it and acting when it is missing.
Second, the information requirements for cross-border payments above USD/EUR 1,000 have been standardised. For an individual originator, the payment must carry the name, the account number or a unique transaction reference, the address (or at least the country and town where a full postal address is not available) and one further identifier, such as a national identity number, a customer identification number or the date and place of birth. For legal entities, an identifier such as a Legal Entity Identifier (LEI) or a connected BIC is expected. Beneficiary information must include the name, the account number and the country and town.
Third, information should be structured, as far as possible, in line with the established standards of the system being used, such as ISO 20022.
Fourth, beneficiary financial institutions are expected to introduce “alignment checks” to detect misdirected payments. These may take the form of a check on each transaction comparing the beneficiary name in the message against the account holder’s name, holistic monitoring for misaligned beneficiary information, or participation in a pre-validation service such as Confirmation of Payee. The FATF is clear that alignment does not require an exact match, and that the expected degree of alignment may vary with risk and context.
The FATF expects most or all of the new requirements to be in effect by the end of 2030. In October 2025 it added an annex to its assessment methodology setting out how compliance will be evaluated in mutual evaluations, and in June 2026 it consulted on draft implementation guidance, with final guidance expected later in 2026 (FATF, 2025a; FATF, 2026).
In the UK, the existing framework already provides a foundation. The retained Funds Transfer Regulation sets out the information that must accompany transfers, the Joint Money Laundering Steering Group (JMLSG) guidance on transparency in electronic payments explains how firms should apply it, and Confirmation of Payee is now well established in domestic payments (JMLSG, 2023; PSR, 2024). The Wolfsberg Group’s Payment Transparency Standards, updated in 2023, set similar expectations for correspondent banking (Wolfsberg Group, 2023). The revised Recommendation 16 will build on these, but it will also test whether they are working in practice.
Where payment information is created
The quality of the information in a payment is largely determined at the point where the instruction is first captured, and this is where the revised standard places the first and most important responsibility.
From what I have observed, the originator details in an outgoing payment are rarely typed fresh. They are usually drawn from the customer record held in the core banking system, which means that any weakness in that record travels with every payment the customer makes. An address held as a single line of free text, a date of birth that was never captured for a long-standing customer, or a company record without an LEI will each become a gap in the payment message, regardless of how well the payment system itself has been configured.
This makes payment transparency as much a customer due diligence issue as a payments issue. Institutions preparing for the revised Recommendation 16 will need to understand how complete their customer records are, particularly for older relationships that were onboarded under different standards. Where information is missing, it will need to be collected through periodic review or at the next customer contact, rather than discovered when a payment fails validation.
The repair queue
Every payments operation has a queue of messages that cannot be processed automatically because a field is missing, formatted incorrectly or too long. In my experience, the repair queue is one of the least visible yet most influential points in the payment chain for transparency, because it is where a person decides what the message will finally say.
Repair work is usually measured by volume and speed, particularly as cut-off times approach. Under that pressure, operators may abbreviate a name to fit a field, remove an address line that fails validation, or enter a generic value simply to allow the payment to proceed. Each of these actions is understandable, and none is usually intended to conceal anything, but each one reduces the accuracy of the information that the rest of the chain will rely on.
The revised standard makes this more significant. Ordering institutions must not execute a payment that lacks the required information, and the information they send must be accurate. A repair that allows the message to pass validation while removing or replacing originator details may therefore leave the institution in breach of the standard, even though the payment appears to have been processed correctly.
Structured data and the end of free-text addresses
The move to ISO 20022 is closely connected to Recommendation 16. The end of the coexistence period for cross-border payment instructions in November 2025 means that payments now travel in a format with dedicated fields for names, towns, countries, identifiers and other party details, and from November 2026 Swift will no longer support cross-border payment messages containing fully unstructured postal addresses. Messages must instead carry a structured or hybrid address, with at least the town and country in their designated fields (Swift, 2025).
For operations staff, this is a practical change rather than a technical one. Under the legacy MT format, an address could be entered as up to four free-text lines, and a reviewer would read and interpret it. Under the new structure, missing or misplaced data becomes visible, because a field is either populated correctly or it is not. This is helpful for transparency, but it also means that a weak customer record will now cause a rejected or delayed payment rather than an incomplete one, and operators will be under pressure to resolve it quickly.
Structured data also changes what screening and monitoring systems can do. A town and country held in their own fields can be screened and analysed with far greater precision than the same information buried in a free-text line. However, this benefit depends on the data being accurate. If the town field is populated with the branch location, or with a placeholder, the system will simply analyse the wrong information more efficiently.
Intermediaries and cover payments
Intermediary banks are required to retain the originator and beneficiary information that accompanies a transfer, to identify payments that lack required information and to apply risk-based policies on whether to execute, reject or suspend them. Where technical limitations prevent information from being passed on, a record must be kept for five years (FATF, 2025b).
Cover payments deserve particular attention. In a cover arrangement, the customer payment message is sent directly to the beneficiary’s bank, while the funds move separately through correspondent accounts. The introduction of the MT202 COV in 2009 was intended to ensure that intermediaries in the cover chain could see the underlying originator and beneficiary, and the same principle applies to the ISO 20022 equivalent. In practice, however, intermediaries can only act on the information they receive, and the quality of that information still depends on what the ordering bank captured at the start.
For staff in correspondent banking teams, the revised standard reinforces an expectation that already exists: payments with missing or meaningless information should not be processed without question. A message where the originator name is “one of our customers” or the address field contains only a country code should prompt a request for information, and repeated instances from the same respondent should feed into the review of that relationship.
Alignment checks at the receiving end
The requirement for beneficiary institutions to check whether the name in an incoming payment aligns with the account holder is, in my view, the change that will be most visible to customers and most demanding for operations teams.
Confirmation of Payee has shown that name checking is effective at reducing misdirected payments and certain types of authorised push payment fraud. It has also shown that name matching is rarely straightforward. Customers use shortened names, trading names, married names and transliterated names, and the same person may appear in several valid forms. For banks that serve many customers with South Asian names, transliteration and the ordering of names can produce mismatches that are entirely legitimate.
This is why the FATF’s statement that alignment does not mean an exact match is important. Institutions will need to decide what degree of variation is acceptable, how close matches are handled, and who reviews the payments that do not align. If every minor variation generates an alert, operations teams will quickly face a volume of exceptions that cannot be reviewed meaningfully. If the threshold is set too loosely, the check will not detect the misdirected and fraudulent payments it is intended to stop.
An illustrative case
Consider a personal customer of a UK bank who holds a long-standing current account. Their customer record contains a name and an address held as a single line of free text, but no date of birth, because the account was opened many years earlier under different procedures.
Over two days, the customer instructs six cross-border payments, each slightly below USD/EUR 1,000, to different individuals in the same country. Because each payment falls below the threshold, only the names and account numbers are required, and every payment passes validation without being sent to the repair queue. A seventh payment, for a higher amount, fails validation because the originator details are incomplete. A payments operator, working close to cut-off, populates the town field with the town of the branch where the account is held and releases the payment.
At the receiving end, the beneficiary bank’s alignment check identifies that the name in two of the payments does not correspond with the account holder’s name, and returns the payments with a request for information.
From a processing perspective, nothing appears unusual. Six payments passed automatically, one was repaired and released, and two were returned. From a financial crime perspective, however, the pattern raises several questions. The payments were structured just below the threshold at which fuller information would have been required, the customer record was incomplete, the repaired payment carried inaccurate originator information, and the beneficiary bank found that the names and accounts did not align.
None of these points individually proves wrongdoing, but taken together they warrant review. The difficulty is that each one was seen by a different person or system: the payment engine, the repair operator, the beneficiary bank and, later, the returns team. Unless the information is brought together, the pattern is unlikely to be recognised.
Why these issues are often missed
From what I have observed, payment transparency failures are rarely the result of a deliberate decision. They tend to arise from the way payment operations are organised and measured.
Payment operations are generally assessed on straight-through processing rates, turnaround times and the volume of payments cleared before cut-off. These measures are reasonable, but they reward the operator who clears a repair quickly rather than the one who stops a payment to request missing information. Unless transparency is reflected in the measures applied to operations teams, it will tend to give way to speed.
There is also a structural separation between payment operations and the financial crime function. Repair decisions, returned payments and requests for information from correspondent banks are often recorded within operational systems that the compliance team rarely sees. As a result, patterns that would be meaningful from a financial crime perspective remain in operational logs.
Finally, payment transparency is often treated as a technology project. The ISO 20022 migration has been managed in many institutions as a systems change, delivered by IT and payments teams with limited involvement from compliance. I discussed this execution gap in my earlier articles, and payments provide another clear example of it. The data fields may be in place, but whether they contain accurate information depends on processes, training and accountability that sit outside the technology.
Practical measures
Preparing for the revised Recommendation 16 does not only require system changes. In practical terms, institutions should consider the following measures:
- Assess the completeness of customer data before 2030. Institutions should identify which customer records lack the information that the revised standard requires, such as dates of birth, structured addresses and LEIs, and set out a plan to collect it through periodic review and customer contact.
- Define clear rules for repairing payments. Repair procedures should state what an operator may and may not change in originator and beneficiary fields. Inserting placeholder values or branch details to pass validation should be explicitly prohibited, and payments that cannot be completed accurately should be returned to the originating branch.
- Give repair and return data to the financial crime function. Repaired payments, payments returned for missing information and alignment check failures should be available to the compliance team in a form that can be reviewed by customer, so that patterns such as repeated payments just below the threshold can be identified.
- Set alignment thresholds with care. Name-matching rules should take account of transliteration, name order and trading names, and should be tested on the institution’s own customer population before they are introduced. Exceptions should be reviewed by staff who understand both naming conventions and fraud risk.
- Include payment transparency in correspondent relationship reviews. The quality of information received from each respondent bank should be monitored, and repeated deficiencies should be raised with the respondent and reflected in the risk assessment of the relationship.
- Train operations staff on why the information matters. Staff who capture, repair and review payments should understand that the information in a message is used by beneficiary banks, intermediaries and investigators, and that changes made to clear a queue may affect all of them.
The FCA’s Financial Crime Guide expects firms to have systems and controls that are proportionate to the risks they face and that operate effectively in practice (FCA, 2023). For payment transparency, that effectiveness is determined largely by the decisions made by the people who process the payments.
Conclusion
The revised Recommendation 16 is often described in terms of payment systems, data standards and the end-2030 implementation date. These elements are important, but the transparency of any individual payment still depends on what is captured when the customer gives the instruction, what is changed in the repair queue, and how carefully the receiving bank checks the beneficiary details.
The revision places clear responsibilities on each institution in the payment chain, and the move to structured data will make gaps in information more visible than they have been in the past. Institutions that use the period until 2030 to improve customer data, set clear rules for repairing payments and connect their payment operations with their financial crime function will be better placed than those that treat the change as a systems upgrade alone.
Having worked with payment messages before I developed an interest in financial crime, I have come to recognise that the fields in a payment message are only as reliable as the people and processes behind them. The revised Recommendation 16 is an opportunity to give those people a clearer role in financial crime control.
References
Financial Action Task Force (FATF) (2025a) FATF Updates Standards on Recommendation 16 on Payment Transparency. Paris: FATF.
Financial Action Task Force (FATF) (2025b) Explanatory Note for Revised Recommendation 16. Paris: FATF.
Financial Action Task Force (FATF) (2026) Public Consultation on Guidance on the Implementation of Strengthened Recommendation 16 on Payment Transparency. Paris: FATF.
Financial Conduct Authority (FCA) (2023) Financial Crime Guide: A Firm’s Guide to Countering Financial Crime Risks. London: FCA.
Joint Money Laundering Steering Group (JMLSG) (2023) Prevention of Money Laundering/Combating Terrorist Financing: Guidance for the UK Financial Sector, Part III. London: JMLSG.
Payment Systems Regulator (PSR) (2024) Specific Direction 17: Confirmation of Payee. London: PSR.
Swift (2025) ISO 20022 Milestone for November 2026: Unstructured Addresses to be Removed. La Hulpe: Swift.
Wolfsberg Group (2023) Payment Transparency Standards. Wolfsberg Group.
Leave a comment