Overview

Banks provide feedback on SEPA Direct Debit (SDD) transactions in multiple stages. Early feedback is often provisional and may be corrected in the days that follow. Below is an overview of how this feedback typically evolves over time.

Feedback timeline

Day X - Initial feedback

• On Day X, the bank provides initial feedback indicating that all transactions were successful.
• This feedback may already include some intrabank corrections (e.g. Deutsche Bank → Deutsche Bank).
• At this stage, the actual settlement status is often not yet fully known. The bank therefore assumes success by default.

Day X+1 - First corrections

• On Day X+1, the bank may report failed transactions.
• This feedback corrects the initial Day X status.
• These corrections typically concern intrabank transactions or feedback from faster-processing banks.

Day X+2 to Day X+5 - Final corrections

• From Day X+2 onwards, additional failures may be reported, further correcting earlier feedback.
• This mainly concerns interbank (cross-bank) transactions, which typically require more processing time. In most cases, the transaction status is known with more than 99% certainty at this stage.

Final confirmation timeline

CORE Mandates

• Final confirmation can take up to 8 weeks
• In fraud-related cases, this can extend to 13 months

B2B Mandates

• Final confirmation is typically received within 2-3 business days

Using bank feedback delay

Banks can correct transaction feedback in the days following the initial settlement. Without a delay, these corrections are immediately reflected in the API, which can cause transaction statuses to change multiple times (for example from paid to unpaid). Introducing a delay in the API transaction feed helps you manage this uncertainty in a controlled way. The delay can be set in the settings of your profile via the submenu payments.

This mechanism applies only to the API transaction feed. The user interface (UI) always displays the latest transaction status as received from the bank and is not affected by the configured delay.

How the delay works

• Only paid transactions are held back. A transaction that is reported as paid is kept in a pending buffer and only appears as paid in the API transaction feed once the delay has passed.
• Failed transactions are not delayed. A failure reported by the bank is exposed in the API transaction feed immediately.
• The delay is counted in bank working days from the requested collection date of the batch, not from the moment the bank feedback arrives. Weekends and bank holidays are not counted.
• The buffer is released automatically during the daily processing and each time new bank feedback is processed. Once the delay has passed, the paid transactions of that batch appear in the API transaction feed.
• If a paid transaction is corrected to failed while it is still in the buffer, your system only receives the failure. The temporary paid status is never exposed in the API transaction feed.
• When you set the delay back to 0, all paid transactions that are still in the buffer are released immediately.

Key benefits

• More stable downstream processing
• Fewer reversals and corrections to make
• Improved financial accuracy in your systems

You can choose how bank feedback is exposed to your systems f.ex. :

Without a delay

• Feedback is passed through immediately to the API, exactly as received from the bank.
• This ensures maximum transparency and timeliness.
• Your system must be able to handle status transitions (e.g. from paid to unpaid).

With a 2-day delay

• Paid transactions are temporarily withheld from the API transaction feed until 2 bank working days after the requested collection date (Day X+2).
• Failed transactions are still exposed immediately.
• This prevents interim status changes (paid, then failed) for corrections that arrive within those 2 days.

Example: the requested collection date is Monday and the delay is 2 days. A transaction reported as paid on Monday becomes visible as paid in the API transaction feed on Wednesday. If the bank reports it as failed on Tuesday, your system receives only the failure on Tuesday and never the paid status.