Transaction Confirmation
Transaction confirmation under PSD2 involves verifying the identity of the customer and ensuring the security of the transaction. It typically requires the use of two or more factors from the following categories:
- Knowledge factors: Something the end-customer knows, such as a password or PIN.
- Possession factors: Something the end-customer possesses, such as a mobile phone
- Inherence factors: Something inherent to the end-customer, such as biometric data (FingerId, FaceID etc.).
The purpose of using multiple factors is to provide an extra layer of security by requiring the end-customer to provide evidence from different categories. This helps to mitigate the risks of unauthorized access and fraud.
PSD2 Exemptions
In line with PSD2, certain outgoing wire transfersWire Transfer A transaction that moves funds between accounts. An incoming wire transfer moves funds from a third-party bank account to a Weavr managed account, while an outgoing wire transfer moves funds from a Weavr managed account to a third-party bank account. Wire transfers require the managed account to have an assigned IBAN (for EUR) or sort code and account number (for GBP). & sendsSend A transaction type that allows sending funds to another identity's instrument or to a beneficiary. Send transactions may require Strong Customer Authentication depending on the destination and whether it's a trusted beneficiary. may be exempted from Strong Customer Authentication (SCASCA Strong Customer Authentication - a two-factor authentication solution required by PSD2 regulations for when end-users are accessing their payment account sensitive information or initiating transactions. SCA requires at least two of the following: something you know (password), something you have (device), or something you are (biometrics).).
- Low Value Transaction: Transactions below €30 or equivalent are not challenged, unless the user exceeds a cumulative transferTransfer A transaction that moves funds between instruments managed by Weavr. The source and destination instruments of a transfer transaction must be owned by the same identity. Transfers can be scheduled for future execution and can be performed in bulk operations. amount of €100 (or equivalent) or 5 successful transactions, or the transaction is deemed high risk.
Contact our support team to enable the Low Value exemption
- Trusted Beneficiaries: The destination instrument of the sendSend A transaction type that allows sending funds to another identity's instrument or to a beneficiary. Send transactions may require Strong Customer Authentication depending on the destination and whether it's a trusted beneficiary. transaction is the identity's trusted beneficiary list.
The status of transactions that do not require SCASCA Strong Customer Authentication - a two-factor authentication solution required by PSD2 regulations for when end-users are accessing their payment account sensitive information or initiating transactions. SCA requires at least two of the following: something you know (password), something you have (device), or something you are (biometrics). automatically moves to EXECUTED and no further action is required.
Authentication factors
To verify a transaction, the logged-in user must have enrolled their mobile device for strong customer authentication.
We currently support SMS and BIOMETRICS as possible authentication factors.
Transaction Confirmation
For transactions to be executed, the logged-in user must authenticate the transaction (unless the transaction is PSD2 exempted). These are the transactions that must be challenged:
-
Single Outgoing Wire TransfersWire Transfer A transaction that moves funds between accounts. An incoming wire transfer moves funds from a third-party bank account to a Weavr managed account, while an outgoing wire transfer moves funds from a Weavr managed account to a third-party bank account. Wire transfers require the managed account to have an assigned IBAN (for EUR) or sort code and account number (for GBP).
-
Bulk Outgoing Wire TransfersWire Transfer A transaction that moves funds between accounts. An incoming wire transfer moves funds from a third-party bank account to a Weavr managed account, while an outgoing wire transfer moves funds from a Weavr managed account to a third-party bank account. Wire transfers require the managed account to have an assigned IBAN (for EUR) or sort code and account number (for GBP).
-
Single SendSend A transaction type that allows sending funds to another identity's instrument or to a beneficiary. Send transactions may require Strong Customer Authentication depending on the destination and whether it's a trusted beneficiary. Transaction
-
Bulk SendSend A transaction type that allows sending funds to another identity's instrument or to a beneficiary. Send transactions may require Strong Customer Authentication depending on the destination and whether it's a trusted beneficiary. Transaction
You can use the challenges
/multi/challenges/otp/{channel}endpoint to verify a single, or multiple OWTsOWT Outgoing Wire Transfer - a transaction that moves funds from a Weavr managed account to a bank account held at a third-party financial institution. OWTs require the managed account to have an assigned IBAN and the user to complete Strong Customer Authentication. and SendsSend A transaction type that allows sending funds to another identity's instrument or to a beneficiary. Send transactions may require Strong Customer Authentication depending on the destination and whether it's a trusted beneficiary. at the same time, by providing the transaction ID(s) in theresourceIdsfield. This endpoint should be used in favour of the deprecated endpoint that can only be used for single OWTsOWT Outgoing Wire Transfer - a transaction that moves funds from a Weavr managed account to a bank account held at a third-party financial institution. OWTs require the managed account to have an assigned IBAN and the user to complete Strong Customer Authentication..
Read more on how to reduce the number of approvals required when executing transactions by using Beneficiaries.
Sending a Challenge
You can trigger the transaction verification process by calling the transaction challenge API. The user is requested to perform a two-factor authentication based on the channel.
If SMS is used, a text message is sent to the mobile number associated with the user's credentials. For root usersRoot user The individual who creates the identity. For corporate identities, the root user needs to be a legal representative of the corporate such as a director or a representative who has the power of attorney over the company. For consumer identities, the root user is the owner of the identity. Every identity must always have one root user., this is the mobile number provided when onboarding the corporate or consumer identity, while for authorised users, this is the mobile number provided when onboarding the user.
If you would like to authenticate the second-factor via SMS, trigger the wire transferWire Transfer A transaction that moves funds between accounts. An incoming wire transfer moves funds from a third-party bank account to a Weavr managed account, while an outgoing wire transfer moves funds from a Weavr managed account to a third-party bank account. Wire transfers require the managed account to have an assigned IBAN (for EUR) or sort code and account number (for GBP). SCASCA Strong Customer Authentication - a two-factor authentication solution required by PSD2 regulations for when end-users are accessing their payment account sensitive information or initiating transactions. SCA requires at least two of the following: something you know (password), something you have (device), or something you are (biometrics). challenge API endpoint, which sendsSend A transaction type that allows sending funds to another identity's instrument or to a beneficiary. Send transactions may require Strong Customer Authentication depending on the destination and whether it's a trusted beneficiary. an OTP via text message.
Verifying the Challenge
If SMS was the selected channel, you must build a page in your application where the user can enter the verification code they received in the text message, then submit it via the challenge verify API.
The challenge expires after 5 minutes and the number of incorrect OTP attempts is limited to reduce the risk of fraud; the challenge remains in a Pending state until the last incorrect attempt has been consumed; any further attempts beyond this return CHALLENGE_LIMIT_EXCEED. After the final incorrect attempt, the state of the corresponding transaction is updated to REJECTED and no further challenges can be triggered against this transaction.