SEPA Credit Batch Transfers

Introduction

The Batch Transfer endpoint enables your customers to initiate and authorize bulk payments of up to 1,000 transfers in a single request. It supports both SEPA Credit Transfers (SCT) and SEPA Instant Credit Transfers (SCT Inst), offering flexibility to accommodate different payment requirements.

Prerequisites:

You must implement the following features in order to use SEPA Credit Batch transfers in your solution:

• Device binding
• Strong Customer Authentication
• Device Monitoring
• Verification of a Payee
• SEPA Credit Transfers
• SEPA Instant Credit Transfers

How It Works

A batch transfer functions similarly to a standard SEPA Credit Transfer (SCT) or SEPA Instant Credit Transfer (SCT Inst), but processes multiple transfers simultaneously, up to 1,000 payments in one request. Partners should enable their customers to choose whether the batch is processed as SCT or SCT Inst based on their needs.

Process Overview:

1. Customer Choice on Verification of Payee (VoP): At the start of the batch transfer process, customers must be clearly presented with two options:

   • Use the Verification of Payee (VoP) service to confirm recipient account details
   • Opt out of VoP and proceed without verification

This choice should be prominently displayed on the partner frontend (e.g., as a toggle switch). The corresponding result of the choice should be communicated to Solaris. Since using VoP is optional by regulation for batch transfers, customers should be able to update their preference at any time, with changes promptly displayed.

2. Verification of Payee Process: If the customer opts in, the partner calls the VoP endpoint to verify all IBANs in the batch. Each IBAN receives a unique VoP ID, which must be stored and included when submitting the batch transfer request.Please note that a feature enabling verification of multiple payees in a single request is under development, expected by end of July, to streamline this process.

3. Batch Transfer Setup: Following verification (if chosen), the partner collects batch details including:

   • Transfer type (SCT or SCT Inst)
   • Amounts
   • Recipient details
   • References
   • VoP id
4. Authorization: Batch transfers require two-factor authentication via SMS OTP or device signing challenge to ensure security before execution.

5. Pre-Execution Checks: Before processing, Solaris performs an account health check, verifying:

   • Sufficient available_balance
   • ACTIVE Account status Transfers proceed only when these conditions are met.

6. Execution: Solaris executes the batch transfer, posting bookings with the appropriate booking types:

   • SEPA_CREDIT_TRANSFER for SCT
   • SEPAInstantCreditTransfer for SCT Instant
7. Opting Out of VoP: If the customer opts out of VoP, the batch transfer proceeds without VoP IDs, following the process from step 3 onward.

Batch Transfer Creation

To create a batch transfer, the regulation states that the customer must be provided with an option to opt out of the verification of a payee process or proceed with the service when making a batch transfer, and thus, each transfer in a batch must include a valid verificationofpayee_id if the this option is saved as true.

Your customer is presented with an option to create the transfer with SCT_INSTANT or SCT . Also, due to regulatory requirements, it is not allowed to only offer batch transfer as just SCT anymore. The transfer type is defined in the request body with a property transfer_type . This means that all transfers listed in a batch will be executed with the payment method defined in the transfer_type field during the creation of the batch transfer.

Execution Rules for Batch Transfer

A batch transfer can allow up to 1000 transfers, if this is to be extended beyond a 1000 transfers, a request can be made through your respective partner manager.

Example:

Let’s say a customer wants to send a batch of 100 transfers.

1. If the customer opts in to VoP:

   • The partner calls the VoP endpoint once per IBAN (100 calls in total)
   • Each response returns a unique verificationofpayee_id
   • Partner must display the results from the verification of payee service to the customer and the customer decides whether to proceed with the batch transfer.
   • These IDs are included in the final batch request

2. The partner submits the batch transfer with:

   • transfertype defined (e.g. "SCTINSTANT" )
   • Full transfer details
   • Corresponding verification_of_payee_id for each entry

3. Corresponding verification_of_payee_id for each entry

   • The change request process is triggered and authorized via two-factor authentication (2FA).
   • After 2FA is completed, the batch transfer cannot be canceled

4. After authorization, Solaris performs validation checks:

   • If verification_of_payee_id is missing, duplicated, expired or invalid for any transfer where VoP was required, that individual transfer will fail
   • However, the rest of the batch will still be processed

Execution failure reasons:

A single transfer in a batch can fail for a number of reasons. Subscribe to the INSTANT_SEPA_CREDIT_TRANSFER_FAILED to receive notifications whenever an SCT instant transfer execution fails. The webhook payload will include the failure reason in the failure_reason property. Please subscribe to SEPA_CREDIT_TRANSACTION_DECLINED to receive notifications when an individual Sepa Credit Transer fails in the Batch.

Examples of decline reasons:

• Target account is blocked, transactions can't be performed.
• Source account is blocked, transactions can't be performed.
• There were insufficient funds to complete this action.
• Target account is closed, transactions can't be performed.
• Source account is closed, transactions can't be performed.

Batch Transfer Statuses

The batch transfer can have different statuses:

ACCEPTED: This is the first status after account health checks are done by Solaris and the two-factor authentication process is completed.

IN_PROGRESS: After confirming the two factor authentication, the status of the batch first goes to ACCEPTED and it turns asynchronously into IN_PROGRESS.

REJECTED: When the checks on the account are carried out by Solaris and any of the validation check fails, for instance, the account has insufficient balance or the two-factor authentication process times out, the status of the batch is changed to REJECTED.

FINISHED: When the batch transfer is completed, this means all transfers in the batch have either been executed or failed.

Related webhooks:

Solaris recommends subscribing to the following webhook events directly connected to batch transfers, to better automate your processes. For detailed instructions on implementing Solaris webhooks, check the webhooks documentation.

BATCH_TRANSFER_STATUS_CHANGED: This is sent out when the batch transfer status changes to either IN_PROGRESS, REJECTED or FINISHED.

BOOKING: Whenever the execution of the batch transfer was successful and created a booking, irrespective of the the transfer type.

INSTANT_SEPA_CREDIT_TRANSFER_EXECUTED: Only sent when individual transfers in the batch are executed with the SEPA Instant Credit Transfer.

INSTANT_SEPA_CREDIT_TRANSFER_FAILED: Only sent when the batch processing is FINISHED and transfer_type is SEPA Instant Credit Transfer, but the processing of some individual transfers in the batch failed.

SEPA_CREDIT_TRANSACTION_DECLINED: Only sent when the batch transfer was successfully executed with the SEPA Credit Transfer, but the processing of some individual transfers in the batch failed.

API reference documentation:

To implement batch transfers, integrate the following endpoints in your solution:

POST Create a Batch Transfer

GET Batch transfers for an account

GET a single Batch Transfer

SUBMIT a verification of payee request