Cross-border payment sender checks

The job

A money transfer service takes a first transfer from a person it has never met. Before the money moves, the service needs to know who the sender is, whether the sender appears on a sanctions list, and whether the details that will travel with the payment are the sender's real details. With remote onboarding all of that has to happen on a phone, in one visit.

This page follows one frame, the international standard for payment transparency, and shows where a verification session supports it and where it does not. For information; not legal advice.

What Recommendation 16 asks

The FATF Recommendations are the global standard for anti-money laundering and counter-terrorist financing. The text used here is the update of June 2026 as published by the Eurasian Group, a FATF-style regional body. Recommendation 16 is titled payment transparency.

• The rule. Countries should ensure that financial institutions include required and accurate originator information, and required beneficiary information, on payments or value transfers and related messages, and that the information stays with the payment through the payment chain.
• Accurate means verified. The glossary of terms used in the recommendation says that accurate is used to describe information that has been verified for accuracy.
• What a cross-border transfer carries. Above the de minimis threshold, the information accompanying a cross-border transfer includes the name of the originator and the beneficiary, the account number of the originator and of the beneficiary where an account is used to process the transaction (and, in the absence of an account, a unique transaction reference number), the address of the originator, the country and town of the beneficiary, and, where the originator is a natural person, the date of birth. Where full date of birth is not available, the year of birth is required.
• The threshold. Countries may adopt a de minimis threshold for cross-border transfers, no higher than USD/EUR 1 000. Below it, the transfer carries the name of the originator and of the beneficiary and the account number of the originator and of the beneficiary where an account is used to process the transaction, or a unique transaction reference number in the absence of an account, and that information need not be verified for accuracy unless there is a suspicion of money laundering or terrorist financing.
• The consequence. The ordering financial institution should not be allowed to execute the transfer if it does not comply with these requirements.
• Sanctions. Recommendation 16 also asks that, in processing payments, institutions take freezing action and prohibit transactions with designated persons and entities. A footnote adds that the recommendation does not specify whether or how the information transmitted should be screened against sanctions lists.

What a verification session can support

The recommendation binds countries and their financial institutions. The platform does not build payment messages. What it gives an institution is a verified sender, and some of the data that the message will carry.

The flow

1. Start. Your backend creates a session from the sender scenario, or the widget does it for the user. If the sender is at a computer, a QR code moves the sender to a phone.
2. Document and selfie. The sender photographs an identity document and takes a selfie, which is matched to the document portrait.
3. Liveness. The sender moves the face closer through two ovals.
4. Address. If your policy asks for the address of the originator, the sender adds an address document in the same session.
5. Screening. The AML database check runs after the session finishes. Your system learns that it is complete from the DATABASE_CHECKS_COMPLETE webhook, or reads database check results.
6. The decision. Your system reads the status and the outcome of each check. A reviewer can settle doubtful cases in the dashboard.

Read outcome before passed on every screening result. A check that never ran arrives looking like a clean one, and only outcome tells the two apart. See retrieving the AML result.

What stays with the institution

The institution decides which data its payment messages must carry, keeps the records its rules require, and monitors payments that lack required information. It also decides what a match on a list means for a transfer, and screens the beneficiary side as its own policy requires. The session supports the verification of the sender. It is one input to those duties and does not replace any of them.

Scenario setup

Build the sender scenario in the scenario editor: the document step with the countries and documents you accept, the selfie and liveness steps, the address document if you need it, and the AML step. Retention of session data is a setting of each scenario. See data controls.

What your system receives

A session status, a list of results for each step, and the database check results for the screening. See session statuses.

Source

The FATF Recommendations, International Standards on Combating Money Laundering and the Financing of Terrorism and Proliferation, updated June 2026, text as published by the Eurasian Group, fetched 27 October 2026. Recommendation 16 and its Interpretive Note.

Next

Talk to us about your sender flow, or see a verification on sample data in the interactive tour. For the screening of amounts at the point of release, see high-value payments and payouts.