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.
Updated about 1 month ago