As mentioned in our previous update, to mitigate against security risks, we are now requiring the user who is updating an authorised user to step-up their token.
Effective:
28 October 2024 on Sandbox
29 October 2024 on Live
Creating and updating user continues to be an operation that can be performed by a user that has either an Admin role or a User Manager role, or both. More about roles can be found in our documentation.
Review and update your application logic to accommodate the update a user endpoint that requires a stepped up token. If your user is trying to update a user and the token is not stepped up, you need to handle the new HTTP 403 STEP_UP_REQUIRED error code. This will help prevent any disruptions to your integration.
As mentioned in our previous update, whenever your customers creates a GBP payment run, all Payment Service Providers using the UK Faster Payment System will need to perform a check on the payee's name to ensure it matches the account details based on the sort code and account number. This requirement aims to help prevent payments from being accidentally sent to the wrong account or maliciously misdirected. This process is known as Confirmation of Payee (CoP).
CoP is only available for UK-domiciled accounts that use the UK domestic payment scheme of Faster Payments.
To support CoP, we made significant changes to the payment run API endpoints and the payment run lifecycle. Below is a summary of these changes:
When a user creates a payment run in Faster Payments, they must specify the type of beneficiary account, which can be either PERSONAL or BUSINESS. The state of the payment run will transition to an interim state of QUEUED instead of PENDING_CONFIRMATION.
In this state, a CoP check is performed on the payee details for each payment in the run. The HTTP 200 response response of this endpoint will return a new object called validationsOutcomes, containing the status of the matching performed (e.g. EXACT_MATCH, CLOSE_MATCH or NO_MATCH) and the reasonCode. A list of the reason codes can be found here.
To accommodate the changes for CoP, we have made updates to the states within the payment run process:
Removing theVERIFYING_REQUIREMENTS and CREATED states.
We are introducing the QUEUED state: This reflects the asynchronous nature of the payment run creation is an asynchronous process. This status indicates that the payment run is in the process of being validated. One of the validation steps being the CoP checks for every payment line within the payment run.
The get a payment run and get payment runs endpoints have been updated to reflect the removal of old states and the addition of new ones. We have also included CoP results in a the new object validationOutcomes
We have introduced a new API endpoint for updating a payment run, allowing users to modify the payee details of individual payments within the run. Based on the CoP results, this functionality enables users to edit specific payments without needing to cancel and re-create the entire payment run.
info
Updating a payment run can be done by a user with a Creator role and will help the user with a Controller role to approve the payment run.
The Payment Run Authorisation UI Component has been updated to display the CoP results next to each payment so that the user with a Controller role can further verify the payee details.
The payment run can be cancelled at any time if the CoP results do not meet the required criteria
If no action is taken, your application wouldn't be able to handle the updated responses when creating a payment run resulting to your users not being able confirm the run.
To minimize risk, at this stage we will be limiting access to the product to only Enterprise Businesses. To differentiate between Enterprise and Micro Enterprise businesses, we are adding two additional steps to the current onboarding process:
1. New Terms & Conditions agreement onboarding screen
Onboarding flows for Buyers will change to require an updated method of recording agreement to financial institution terms and conditions (FI T&Cs).
All Buyer Admin users will now be shown the following screen when onboarding:
This enables us to record the agreement of the End Customer to the FI T&Cs directly, as well as automatically update the version of T&Cs if they are revised in future. T&Cs updates will be communicated in advance in each case.
This FI T&Cs agreement screen will be added automatically to the KYB UI Component, prior to the Customer Due Diligence steps (e.g. identity verification and proof of address) in the rest of the process.
2. Updated/moved Micro-enterprise declaration in KYB onboarding
As well as the above new T&Cs step for all onboarding flows, we will now require a clearer Micro-enterprise declaration, which we are adding into the KYB onboarding:
As shown, the Buyer's Admin User needs to answer the two additional questions and then agree to the declaration about whether the Buyer is or is not considered a Micro-enterprise.
Error code micro-enterprise
If the business is a Micro-enterprise, the KYB UI Component will send you an error event with code MICRO_ENTERPRISE_NOT_SUPPORTED
We are strengthening the verification process for linking accounts by ensuring that the activation of a Linked Account requires the successful completion of two verification steps; a declaration of ownership via an SCA challenge and internal checks by Weavr:
When adding a Linked Account via the Account Information Service (AIS) UI Component it is critical to confirm that the registered linked account belongs to the Identity attempting to link it. As a result, the state of the linked account will initially transition to PENDING_CHALLENGE rather than LINKED, A user with the Controller role of the Identity must then complete an Strong Customer Authentication (SCA) challenge to confirm ownership of the Linked Account.
Linked Account declaration UI Component
More information about our Linked Account Declaration UI Component can be found here.
SCA challenge state
If the SCA challenge fails, the Linked Account will remain in the PENDING_CHALLENGE state until a successful SCA challenge is completed.
More information about linked an account can be found in our documentation.
A name verification check will be automatically triggered by the Weavr platform and, when necessary, flagged for review by the Weavr Compliance team. This ensures that the name of the Linked Account holder matches the Identity registered with Weavr. The internal checks are required as another layer in the verification process to verify that the Linked Account belongs to the same person of the Identity.
During this process, we have introduced a new state, PENDING_VERIFICATION, which will remain until the Compliance checks are completed. These checks will result in either a REJECTED or LINKED status.
Compliance Checks
The Compliance will reach out to the Identity before rejecting the Linked Account.
Updates to the Linked Account webhooks and Get endpoints
If no action is taken, your application will be unable to handle the updated responses when linking a new account, preventing your users from performing an SCA challenge. As a result, the linked account will remain in the PENDING_CHALLENGE state.
New Linked Account SCA Declaration Challenge UI Components
In the UK, APP (Authorized Push Payment) Fraud is a growing type of scam, where fraudsters trick individuals into authorizing payments to accounts controlled by criminals. Unlike traditional fraud, where unauthorized transactions are made without the victim’s consent, APP fraud involves convincing the victim to willingly transfer money under false pretenses.
Weavr is committed to mitigating this type of fraud. To that end, we have enhanced our security measures for when your users add a linked account and we have refined the onboarding process.
To minimize risk, at this stage we will be limiting access to the product to only Enterprise Businesses. To differentiate between Enterprise and Micro Enterprise businesses, we are adding two additional steps to the current onboarding process:
1. New Terms & Conditions agreement onboarding screen
Onboarding flows for Buyers will change to require an updated method of recording agreement to financial institution terms and conditions (FI T&Cs).
All Buyer Admin users will now be shown the following screen when onboarding:
This enables us to record the agreement of the End Customer to the FI T&Cs directly, as well as automatically update the version of T&Cs if they are revised in future. T&Cs updates will be communicated in advance in each case.
This FI T&Cs agreement screen will be added automatically to the KYB UI Component, prior to the Customer Due Diligence steps (e.g. identity verification and proof of address) in the rest of the process.
2. Updated/moved Micro-enterprise declaration in KYB onboarding
As well as the above new T&Cs step for all onboarding flows, we will now require a clearer Micro-enterprise declaration, which we are adding into the KYB onboarding:
As shown, the Buyer's Admin User needs to answer the two additional questions and then agree to the declaration about whether the Buyer is or is not considered a Micro-enterprise.
Error code micro-enterprise
If the business is a Micro-enterprise, the KYB UI Component will send you an error event with code MICRO_ENTERPRISE_NOT_SUPPORTED
We are strengthening the verification process for linking accounts by ensuring that the activation of a Linked Account requires the successful completion of two verification steps; a declaration of ownership via an SCA challenge and internal checks by Weavr:
When adding a Linked Account via the Account Information Service (AIS) UI Component it is critical to confirm that the registered linked account belongs to the Identity attempting to link it. As a result, the state of the linked account will initially transition to PENDING_CHALLENGE rather than LINKED, A user with the Controller role of the Identity must then complete an Strong Customer Authentication (SCA) challenge to confirm ownership of the Linked Account.
Linked Account declaration
The ownership declaration is facilitated through an SCA challenge via a UI Component, which will be provided by Weavr.
SCA challenge state
If the SCA challenge fails, the Linked Account will remain in the PENDING_CHALLENGE state until a successful SCA challenge is completed.
More information about linked an account can be found in our documentation.
A name verification check will be automatically triggered by the Weavr platform and, when necessary, flagged for review by the Weavr Compliance team. This ensures that the name of the Linked Account holder matches the Identity registered with Weavr. The internal checks are required as another layer in the verification process to verify that the Linked Account belongs to the same person of the Identity.
During this process, we have introduced a new state, PENDING_VERIFICATION, which will remain until the Compliance checks are completed. These checks will result in either a REJECTED or LINKED status.
Compliance Checks
The Compliance will reach out to the Identity before rejecting the Linked Account.
Updates to the Linked Account webhooks and Get endpoints
If no action is taken, your application will be unable to handle the updated responses when linking a new account, preventing your users from performing an SCA challenge. As a result, the linked account will remain in the PENDING_CHALLENGE state.
New Linked Account SCA Declaration Challenge UI Components
To mitigate against security risks, we are now requiring the user who is updating an authorised user to step-up their token.
Effective:
28 October 2024 on Sandbox
29 October 2024 on Live
Creating and updating user continues to be an operation that can be performed by a user that has either an Admin role or a User Manager role, or both. More about roles can be found in our documentation.
Review and update your application logic to accommodate the update a user endpoint that requires a stepped up token. If your user is trying to update a user and the token is not stepped up, you need to handle the new HTTP 403 STEP_UP_REQUIRED error code. This will help prevent any disruptions to your integration.
Starting this October, whenever your customers creates a GBP payment run, all Payment Service Providers using the UK Faster Payment System will need to perform a check on the payee's name to ensure it matches the account details based on the sort code and account number. This requirement aims to help prevent payments from being accidentally sent to the wrong account or maliciously misdirected. This process is known as Confirmation of Payee (CoP).
CoP is only available for UK-domiciled accounts that use the UK domestic payment scheme of Faster Payments.
To support CoP, we made significant changes to the payment run API endpoints and the payment run lifecycle. Below is a summary of these changes:
When a user creates a payment run in Faster Payments, they must specify the type of beneficiary account, which can be either PERSONAL or BUSINESS. The state of the payment run will transition to an interim state of QUEUED instead of PENDING_CONFIRMATION.
In this state, a CoP check is performed on the payee details for each payment in the run. The HTTP 200 response response of this endpoint will return a new object called validationsOutcomes, containing the status of the matching performed (e.g. EXACT_MATCH, CLOSE_MATCH or NO_MATCH) and the reasonCode. A list of the reason codes can be found here.
To accommodate the changes for CoP, we have made updates to the states within the payment run process:
Removing theVERIFYING_REQUIREMENTS and CREATED states.
We are introducing the QUEUED state: This reflects the asynchronous nature of the payment run creation is an asynchronous process. This status indicates that the payment run is in the process of being validated. One of the validation steps being the CoP checks for every payment line within the payment run.
The get a payment run and get payment runs endpoints have been updated to reflect the removal of old states and the addition of new ones. We have also included CoP results in a the new object validationOutcomes
We have introduced a new API endpoint for updating a payment run, allowing users to modify the payee details of individual payments within the run. Based on the CoP results, this functionality enables users to edit specific payments without needing to cancel and re-create the entire payment run.
info
Updating a payment run can be done by a user with a Creator role and will help the user with a Controller role to approve the payment run.
The Payment Run Authorisation Component has been updated to display the CoP results next to each payment so that the user with a Controller role can further verify the payee details.
The payment run can be cancelled at any time if the CoP results do not meet the required criteria
If no action is taken, your application wouldn't be able to handle the updated responses when creating a payment run resulting to your users not being able confirm the run.
As previously communicated, we are introducing a breaking change to the Buyer endpoints to enhance your ability to track the status of currency creation. This breaking change will include modifications to the HTTP 200 response when creating and updating a buyer, as well as changes to the webhook events to support buyer updates.
In the HTTP 200 response of the create a buyer endpoint, the supportedCurrencies field has been restructured as an array of objects. We have added a status field to indicate the status of each supported currency created. The status field will include the following enums:
PENDING_KYB_APPROVAL: The buyer’s KYB process is pending approval.
STEPUP_LOGIN_REQUIRED: The buyer needs to perform a stepped-up login for higher authentication.
PENDING_CREATION: The system is awaiting the completion of the ZBA creation process.
ACTIVE: The ZBA has been successfully created and is ready for use.
UNAVAILABLE: The currency is unavailable and cannot be used.
note
The HTTP 200 response of the get buyer details have also been updated to support the supportedCurrencies field has been restructured as an array of objects and the addition of the status field to indicate the status of each supported currency created.
The update a buyer endpoint has been enhanced to allow updating the admin user's roles and the supportedCurrencies. The HTTP 201 response now includes supportedCurrencies as an array of objects, each with a status field indicating the status of each supported currency.
KYB information (company and adminUser information) has been removed from the update a buyer endpoint, and a new endpoint Update Buyer's KYB details has been created specifically for updating KYB.
note
We also removed the resetMobileCounter from the update a buyer endpoint which had redundant information.
To accommodate these changes, we have updated buyer activation webhook to a Buyer Update webhook. The new webhook now includes the status of a buyer's supportedCurrency updates in its payload.
Review and update your application logic to accommodate the changes in the supportedCurrencies field and begin capturing the associated status. This will help prevent any disruptions to your integration.
The original communication indicated that the deprecated delete a linked account endpoint would be removed by 3 July 2024. This removal has now been rescheduled to 20 August 2024 on the Live environment.
On 3rd September 2024, we are introducing a breaking change to the Buyer endpoints to enhance your ability to track the status of currency creation. This breaking change will include modifications to the HTTP 200 response when creating and updating a buyer, as well as changes to the webhook events to support buyer updates.
In the HTTP 200 response of the create a buyer endpoint, the supportedCurrencies field has been restructured as an array of objects. We have added a status field to indicate the status of each supported currency created. The status field will include the following enums:
PENDING_KYB_APPROVAL: The buyer’s KYB process is pending approval.
STEPUP_LOGIN_REQUIRED: The buyer needs to perform a stepped-up login for higher authentication.
PENDING_CREATION: The system is awaiting the completion of the ZBA creation process.
ACTIVE: The ZBA has been successfully created and is ready for use.
UNAVAILABLE: The currency is unavailable and cannot be used.
note
The HTTP 200 response of the get buyer details have also been updated to support the supportedCurrencies field has been restructured as an array of objects and the addition of the status field to indicate the status of each supported currency created.
The update a buyer endpoint has been enhanced to allow updating the admin user's roles and the supportedCurrencies. The HTTP 201 response now includes supportedCurrencies as an array of objects, each with a status field indicating the status of each supported currency.
KYB information (company and adminUser information) has been removed from the update a buyer endpoint, and a new endpoint Update Buyer's KYB details has been created specifically for updating KYB.
note
We also removed the resetMobileCounter from the update a buyer endpoint which had redundant information.
To accommodate these changes, we have updated buyer activation webhook to a Buyer Update webhook. The new webhook now includes the status of a buyer's supportedCurrency updates in its payload.
Review and update your application logic to accommodate the changes in the supportedCurrencies field and begin capturing the associated status. This will help prevent any disruptions to your integration.
We are removing the baseCurrency field from the Buyer object.
After the change, you will not be required to send the baseCurrency field when creating or updating a buyer. When retrieving the buyer details, the baseCurrency field will not be returned anymore.
If no action is taken, your application may fail when retrieving the details of a buyer if it is expecting to receive the baseCurrency field as part of the response.
The Account Information Service (AIS) consents are granted for up to 90 days, after which, your users are required to extend their consent to continue using the associated Linked Account therefore we have updated the AIS component to support the extension of the consent.
Retrieve the linked account consent expiry and status
The consent can be initiated before 90 days elapse, this means that your user will be shown a consent renewal request screen for Weavr to continue accessing their bank account information. If the user clicks on 'I Consent' then the AIS consent will extended for another 90 days.
Initiating the AIS consent after 90 days, can still be extended, however your user will be shown an expired consent screen. To renew the consent, your user will be redirected to their Bank's portal to approve the consent request. In the Banking portal, the bank will ask them to authenticate and re-confirm the bank account to be shared.
The creation of an Authorised User for a Buyer is a key moment in the integrity of the security for that Buyer. To mitigate against security risks, we are now requiring the user who is creating a new authorised user to step-up their token. Creating Authorised Users continues to be an operation that can be performed by a user that has the Admin role.
When the user inputs a wrong OTP, they will be shown an error message and will be allowed to re-enter a new OTP. If they reach the last try, a message will be shown specifying that is the last try. Once a wrong OTP is inputted for the last try the Secure UI Component will return an error event with code CHALLENGE_LIMIT_EXCEEDED.