The information in this page does not constitute legal advice. It only provides an overview of Adyen's compliance guidelines for financial products and Adyen for Platforms (referred to as the Compliance Guidelines). For additional, non-legal clarifications about this content, reach out to your Adyen contact.
If your the platform offers financial products, there are specific situations that you must notify Adyen of when they occur. There are also certain reports that you must submit to Adyen.
When to notify Adyen
Platforms must notify Adyen immediately (within 1-2 business days) in the following instances:
- The platform receives a Security, Regulatory or Legal Complaint (type B and C) (see Section 5.1). These complaints are to be notified to Adyen using the dedicated template for complaints reporting. See here for more information.
- Customer Support Circumstances: (these are to be raised through normal Adyen support lines):
- The platform, acting reasonably, cannot resolve a user’s request for support.
- Any unauthorised use, loss/theft of personal security credentials, (potential) fraud, or illegal/suspicious activity. This applies whether it was reported by the user to theplatform or by the software or systems of the platform.
- Any (dispute raised by the user about) unauthorised payment or an error on an account statement.
- A material incident, potential security breach or personal data breach;
- (Capital only) Any explicit statement made from a user through customer support channels that they are facing difficulties repaying the loan; and
- Any material non-compliance by a user that the platform has become aware of or should have been reasonably aware of.
For requests that can be done through API requests, such as a request to block or terminate an account, no additional reporting is required.
Daily reporting
The following information must be submitted by the platform to Adyen daily for each of the services available when such instances occur:
- Fraud Report (Accounts and Issuing)
- Number of fraud related incidents/disputes (including transactions charged back due to fraud-related reasons and transactions for which fraud losses were recovered by a means other than a chargeback) and subsequent reason codes/descriptions in accordance with Adyen’s API.
Note: For fraud reporting, the platform is required to integrate the Disputes API.
- (Issuing only) Cards report. Use this to report blocked, stolen, lost or damaged cards. The following information needs to be included:
- Payment instrument ID
- Scheme status code
- Action taken by platform.
Periodic reporting
To the extent not prohibited by any applicable law, the platform shall share on a quarterly basis with Adyen aggregated reporting (using the template provided by Adyen for the EU and the UK of all users’ complaints that relate to Adyen products and all relevant written documentation. The quarterly reporting period commences on the date of onboarding of the first user in your live environment.
The following information must be contained in the quarterly reports:
- Date of receipt of the complaint;
- Date complaint was acknowledged by the platform as received;
- Current status of the complaint;
- The date complaint is resolved;
- The date a resolution is communicated to the customer (if a complaint has been resolved);
- Complaint outcome (i.e., upheld or not upheld);
- user name;
- user legal entity reference;
- Country of the user
- Brief description of the complaint;
- Product to which the complaint relates (if applicable);
- Description of steps taken to resolve the complaint; and
- (UK only) If the customer was determined to be vulnerable.
Vulnerable customer information (UK only)
To the extent not prohibited by any applicable law, the platform must quarterly with Adyen aggregated reporting using the template provided here. This must contain the number of users who are vulnerable, including the following information:
| Data point | Explanation |
|---|---|
| Total number of users tagged as vulnerable | Where a user is identified as vulnerable per our training (See section 4.2 above above), this should be recorded in the platform CRM system to ensure that the user continually receives the additional support that they need for as long as it is needed |
| Total number of users flagged as vulnerable broken down by categorisation of vulnerability | The user’s specific vulnerability should be recorded under one of these four categories (Health, Life Events, Resilience, and Capability) to allow Adyen to better understand the types of vulnerability Adyen and the platform need to account for when building products and supporting their customers |
| Outcomes of any user requests for specific additional support | If a user requests specific support such as having information presented in a different way to accommodate their needs, or for more time to make a decision, this request should be documented and the outcome recorded. The outcome should cover the actions taken by the platform to accommodate the user’s needs, and details of any relevant follow-up requests from the user |
Only the total figures about vulnerable users are required.
In addition, the platform is required to share with Adyen annually any specific patterns of vulnerability they have identified within their customer base that the platform believes may require Adyen’s attention or further action.