User details for AML

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 details with each payment you create with the Payments API, which is used as part of anti-money-laundering (AML) measures.

The user details you need to provide, and the method you use to provide them, vary based on the type of payment. We provide an overview of the information required on this page. There's more detailed guidance in the documentation for each payment type.

📘

Repeated payments

Even if you receive regular payments from a user, you should still collect payment details for each payment they make.

This page explains the minimum required user details you must collect. However, you can collect more information than this.

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 details as part of the user object in the payment creation request.

The available fields for the user object 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 details as part of single payments.

📘

Payment verification

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 payment verification.

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 orphone 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.

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.

Variable recurring payments

When you create a mandate with Payments v3, you provide user details as part of the user object 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 orphone 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.