User information for AML

Learn what details you must provide with your payments to help prevent crime.

TrueLayer provides payment initiation services (PIS) on your behalf if you do not have your own PISP license. This means you must provide certain user information with each payment you create with the Payments API, which is used as part of anti-money-laundering (AML) measures.

The user information you need to provide, and the method you use to provide it, varies based on the type of payment. You need to include user information with every payment request.

We provide an overview of the user information required on this page. There's more detailed guidance in the documentation for each payment type.

Requests for information (RFI)

As a regulated financial/payment institution, TrueLayer has a regulatory requirement to screen transactions to or from TrueLayer merchant accounts against sanctions lists. The requirement applies to all transactions by clients who are not fully regulated and authorised to provide financial services in the UK or EU.

TrueLayer double-checks transactions made by end users whose name matches an individual on a sanction list. This prevents transactions that could be related to money laundering or sanctioned individuals.

If a transaction is flagged for a sanction or AML issue, TrueLayer makes an RFI to collect the additional information needed for us to investigate.

Where sanction screening applies (which is for every transaction to/from a TrueLayer merchant account), you should provide the following extra information on the end users:

  • date_of_birth
  • address

Single payments

When you create a payment with the Payments API, you provide user information as part of the user parameter in the payment creation request.

The available fields in the user parameter are a user id, name, email, email, phone, date_of_birth and address.

Single payments can be made either to your TrueLayer merchant account, or another external account.

Learn more about providing user information as part of single payments.

Pay-ins to your TrueLayer merchant account

When you create a payment into your merchant account, you must include the user's name, and either their email address or phone number.

To comply with sanction screening obligations, and to minimise the number of RFIs raised, you should also include user details for the additional date_of_birth and address fields in your pay-in API requests.

📘

If required for your payments application, TrueLayer can check the name or date of birth of a payer before it settles. This means a payment from sanctioned parties would never settle in your account in the first place. Learn how to enable pre-payment verification.

Pay-ins to your external account

When you create a payment into an external account (not a TrueLayer merchant account, but for example a bank account owned by your or your banking partner), must provide the user's name, and either their email address orphone number.

VRP mandates

When you create a mandate with Payments v3, you provide user information as part of the user parameter in the payment creation request. The available fields for the user object are a user id, name, email, phone, date_of_birth and address.

Mandates can be made to pay either your TrueLayer merchant account, or another external account.

Learn more about providing user details as part of variable recurring payment mandates.

Mandates to pay your TrueLayer merchant account

When you create a mandate to pay into your TrueLayer merchant account, you must include the user's name, and either their email address or phone number.

To comply with sanction screening obligations, and to minimise the number of RFIs raised, you should also include user details for the additional date_of_birth and address fields in your mandate creation API requests.

Mandates to pay your external account

When you create a mandate that pays into an external account (not a TrueLayer merchant account, but for example a bank account owned by your or your banking partner), must provide the user's name, and either their email address or phone number.

Closed-loop payout

A closed-loop payout is a payout made back to an account based on the payment_source of an initial single payment. As user details were already collected in the initial single payment, there's no requirement to collect user details for a closed-loop payout.

Open-loop payout

An open-loop payout is a payout made to an external_account and is not linked to an initial payment.

account_holder_name and iban (or sort_code and account_number) are already required in order to be able to send the payout to the beneficiary.

To comply with sanction screening obligations, and to minimise the number of RFIs raised, you should also include user details for the additional date_of_birth and address fields in your open-loop payout API requests.

Refunds

A refund is a payment, or payments, made back to an account based on the id of an initial single payment. As user details were already collected in the initial single payment, there's no requirement to collect user details for a refund.