SCT Inst Rejection and Timeout Runbook for Payment Operators
Operator runbook for SCT Inst rejections, timeouts, returns, and recalls — pacs.002 status handling, action per failure class, and bank escalation checklists.
SCT Inst failures are synchronous: pacs.002 RJCT or silence within 10 seconds, not a next-day return. Covers the 5/7/9/10-second framework, rejection vs timeout vs return vs recall taxonomy, ACCP/RJCT handling, operator action per failure class, and bank escalation checklists.
When a SEPA Instant Credit Transfer (SCT Inst) fails, you receive a pacs.002 RJCT within seconds or silence by the 10-second hard limit — not a return the following day. The beneficiary PSP must respond within 7 seconds; the originator PSP must restore the payer's account by the 10th second if no confirmation arrives. For rejects, the reason code in the pacs.002 tells you why. For timeouts, treat funds as held (not lost) and check status via pacs.028 before any retry. For post-settlement returns, the procedure mirrors SCT but happens far faster. For recalls, use camt.056 (DUPL/TECH/FRAD — 10 banking business days; FRAD extends to 13 months). The R-code lookup lives in the SEPA R-transaction reference; this runbook is the operational handling layer on top of it.
When a SEPA Instant Credit Transfer goes wrong, the failure mode is nothing like batch SCT. You do not receive an R-transaction the next banking day. You get a pacs.002 rejection within seconds — or silence, and silence itself has a hard meaning at the 10-second wall. This runbook tells operators what to do in each case.
The reason-code lookup lives in the SEPA R-transaction reference — this document does not duplicate those tables. This runbook is the operational handling layer: the taxonomy, the status message mechanics, the action table, the customer messaging, and the escalation checklists that sit on top of the codes.
What SCT Inst changes operationally
The most important shift from batch SCT is that failure is synchronous. In batch SCT, a reject or return arrives asynchronously — sometimes hours later, often the next banking day. The creditor has time to wait. In SCT Inst, the entire execution cycle — submission, routing, beneficiary acceptance, settlement, and confirmation back to the originator — must complete within 10 seconds. Failure is immediate.
Three operational consequences follow:
Retry logic must be purpose-built. In batch SCT, a retry the following day is normal. In SCT Inst, retrying within seconds on the same account after an AB-code (bank unavailable) may be reasonable; retrying after an AC04 (closed account) is not. The reason code in the pacs.002 drives the retry decision — infrastructure failures support retry, account-state failures do not.
The 24/7/365 availability requirement means there is no maintenance window to hide in. If your PSP’s SCT Inst processing degrades at 2 AM on a Sunday, your customers experience that in real time. Monitor continuously, not just during business hours.
Irrevocability is near-immediate. Once a positive pacs.002 confirmation is received, the funds are at the beneficiary. The recall window (camt.056) exists, but recovery depends on beneficiary-bank cooperation and is not guaranteed. Prevention — pre-submission Verification of Payee, correct IBAN validation — is more effective than post-settlement recall.
The 10-second execution framework
The 2025 SCT Inst rulebook (EPC004-16 2025 v1.1, in force 5 October 2025; v1.1 superseded v1.0 with no changes to the timing framework) defines the following internal deadlines within the 10-second maximum:
| Second | Threshold | Party obligation |
|---|---|---|
| T+0 | Time of Receipt (ToR) | Originator PSP marks ToR; execution clock starts |
| T+5 | Target execution time | Originator PSP should have forwarded the pacs.008 and received a response (positive or negative) |
| T+7 | CSM hard timeout | CSM must have received the beneficiary PSP’s pacs.002; if not, CSM automatically sends negative confirmation to both PSPs |
| T+9 | Final confirmation deadline | Originator PSP must have received the final pacs.002 (positive or negative) |
| T+10 | Account restoration | If no confirmation received by the 10th second, originator PSP must release (unfreeze) the payer’s account balance and inform the payer |
What the beneficiary PSP must do at expiry: The CSM (TIPS or RT1) enforces the 7-second threshold. If the beneficiary PSP has not responded by T+7, the CSM automatically generates a negative confirmation — the beneficiary PSP does not get additional time to decide. Funds are never credited after a timeout.
What the originator PSP must do at T+10: Release the held funds. The payment is treated as failed. The originator PSP must then notify the payer (real-time customer notifications are now mandatory under the 2025 rulebook).
The prior 25-second window is gone. Pre-2025 documentation sometimes quoted 20–25 seconds. The 2025 rulebook tightened this to the 5/7/9/10 framework. Do not quote stale timing figures in internal runbooks or SLA documentation.
Rejection vs timeout vs return vs recall
These four SCT Inst failure modes are distinct and require different operational responses.
| Failure mode | When it occurs | How you know | Funds status |
|---|---|---|---|
| Rejection | Within T+9 (typically seconds) | pacs.002 with RJCT status + reason code | Never moved — not debited |
| Timeout | No response by T+10 | pacs.002 absence; originator PSP triggers account restoration | Held then released — not moved |
| Post-settlement return | After settlement (longer window, see R-transaction reference) | pacs.004 with reason code | Already credited to beneficiary; reversed back |
| Recall | After settlement, up to 10 banking days (FRAD: 13 months) | camt.056 / camt.029 / pacs.004 FOCR | Already credited; recovery depends on beneficiary cooperation |
Rejection is a pre-settlement failure. The beneficiary PSP (or CSM) declined to execute. No funds moved. The pacs.002 carries a reason code that tells you why — account closed, format error, amount limit, infrastructure unavailable. See the SEPA R-transaction reference for the full code tables.
Timeout is the absence of any confirmation by T+10. The payment did not complete, but the reason is ambiguous — the beneficiary PSP may have been unreachable, or the CSM detected an issue. Treat this as “payment failed, status uncertain” until a pacs.028 status query confirms the outcome. Do not retry before confirming.
Post-settlement return is a pacs.004 message arriving after successful settlement — the beneficiary PSP is reversing a credited payment. This is far less common in SCT Inst than in batch SCT (because rejects are synchronous), but it can happen for post-settlement events (account closed between settlement and credit posting, regulatory hold). Timing windows for SCT Inst returns are longer than the 10-second reject window; the exact window follows the SCT Inst rulebook provisions for post-settlement returns.
Recall is originator-initiated after a successful, settled, and credited payment — the originator is trying to get funds back. This is the last resort for duplicates, fraud, or errors discovered after crediting.
pacs.002 status handling
The pacs.002 (FI-to-FI Payment Status Report) is the only message that carries a positive or negative outcome in SCT Inst. Two status values are used in the SCT Inst inter-PSP flow:
ACCP — Accepted Customer Profile. The beneficiary PSP has accepted the payment; settlement proceeds. The originator PSP receives a second pacs.002 from the CSM confirming settlement completion. ACCP is the positive outcome.
RJCT — Rejected. The payment has been declined. The pacs.002 carries one or more reason codes in the TxSts/StsRsnInf/Rsn element. These reason codes are the ISO 20022 External Status Reason codes documented in the SEPA R-transaction reference.
ACSC and ACCC are not used in the SCT Inst inter-PSP flow. These statuses (which appear in batch SCT and in CBPR+ cross-border flows) are not part of the SCT Inst scheme’s two-outcome model. Any system that expects ACSC/ACCC from SCT Inst confirmations will misparse the response.
When no pacs.002 arrives: pacs.028 status request
If your originator PSP receives no pacs.002 by T+10 and has restored the account, the payment is failed. But before retrying or notifying the customer, send a pacs.028 (FI-to-FI Payment Status Request) to the CSM. The CSM responds with a pacs.002 confirming the status. This step matters for:
- Confirming the payment did not settle silently (rare but possible in edge-case timing scenarios)
- Obtaining the reason code if the CSM generated a timeout rejection
- Building the investigation record before escalating to your bank
Most operator-facing implementations (PSP APIs, banking platforms) abstract the pacs.028 behind a “check payment status” endpoint. If your PSP provides this endpoint, use it before any retry.
Common rejection and unable-to-process scenarios
These are the categories you will encounter most in production. For specific reason codes within each category, see the SEPA R-transaction reference.
Account and format errors (AC01, AC04, AC06, FF01): The most common class. AC01 (incorrect IBAN) is preventable with IBAN validation at entry. AC04 (closed account) and AC06 (blocked account) require customer contact before any retry — retrying against a closed or frozen account generates further rejects without resolving the underlying issue.
Amount limit (AM02): The 2025 rulebook removed the EPC-level €100,000 cap, but individual PSPs still set their own per-transaction limits. Under the EU IPR, a PSP’s SCT Inst limit cannot be lower than its SCT limit for the same account type. AM02 means the transaction exceeds the debtor PSP’s or an agreed bilateral limit. Check what limit applies in your integration before retrying at a lower amount.
Infrastructure failures (AB05, AB06, AB07, AB08): These codes mean the beneficiary PSP or an intermediate agent was unreachable or failed to respond within the timeout. They are not account-state failures. A single retry after a brief interval (60–120 seconds) is appropriate. If AB codes persist across multiple retry attempts or affect multiple payees, escalate to your PSP — this indicates a CSM connectivity or beneficiary PSP availability issue beyond a transient glitch.
Agent availability (AG09, AG10, AG11): Similar to AB codes but indicate the beneficiary PSP’s participation in the SCT Inst scheme is suspended or they did not receive the payment within the 10-second window. AG10/AG11 (bank suspended from the scheme) require checking whether the beneficiary PSP has been excluded before retrying — a suspended PSP will continue to generate these codes until reinstated.
Regulatory codes (RR04): A sanctions or AML block. Under the 2025 IPR framework, per-transaction sanctions screening during the instant payment execution window no longer occurs (Article 5d of Regulation (EU) 2024/886 shifted to daily customer-level screening). However, RR04 can still appear when a bank-level hold has been placed outside the IPR sanctions framework, or from non-IPR compliance infrastructure at the beneficiary PSP. Do not retry without compliance review. Escalate internally.
VoP interaction and user-warning flow
Verification of Payee (VoP) is a pre-submission check — it runs before the pacs.008 is sent, not as part of the 10-second execution cycle. VoP is advisory: the payer may proceed past a No Match, and VoP is not a rejection mechanism within SCT Inst. A pacs.002 RJCT is never caused by a VoP mismatch.
The operational sequence is:
- Payer enters IBAN and beneficiary name
- Your system calls the VoP service (EPC VoP scheme, or your PSP’s implementation)
- VoP returns MTCH / CMTC / NMTC / NOAP
- MTCH: Proceed normally
- CMTC: Surface the actual account-holder name returned; ask payer to confirm before proceeding
- NMTC: Show a strong warning; do not hard-block; let payer proceed or cancel
- NOAP: Neutral notice that the check could not run; do not block; do not imply fraud
- Only after payer confirms (or after Match with no friction) does your system submit the pacs.008
Do not conflate VoP outcomes with payment outcomes. A payment that passes a VoP Match can still receive a pacs.002 RJCT (the account may have closed between VoP check and submission). A payment that proceeds past a NMTC can still succeed (false positives are common — trading names, joint accounts, abbreviations). For the full VoP code model and liability framing, see the VoP match-code reference.
Liability note: Under the EU Instant Payments Regulation compliance framework, if your PSP properly delivered a No Match warning and the payer proceeded, the payer bears the fraud loss. If the PSP failed to deliver the warning, the PSP is liable. This allocation makes the VoP warning display — and your audit log of what was shown — operationally significant.
Operator action table
| Failure class | Log level | Show to payer | Retry? | Next action |
|---|---|---|---|---|
| RJCT + AC01 (incorrect IBAN) | Warning | Yes — IBAN invalid | Yes, after correction | Validate IBAN; re-collect from payer |
| RJCT + AC04 (closed account) | Warning | Yes — payment declined | No | Contact payer; update account details |
| RJCT + AC06 (blocked account) | Warning | Yes — payment declined | No until resolved | Contact payer; do not retry on a frozen account |
| RJCT + AM02 (amount limit) | Info | Yes — amount exceeds limit | Yes, at lower amount if appropriate | Check PSP/bilateral limit; retry if business logic permits a split |
| RJCT + AB05–AB08 (infrastructure timeout) | Warning | No (internal) | Yes, after 60–120s | Single retry; if persists, escalate to PSP |
| RJCT + AG09–AG11 (beneficiary agent) | Warning | Yes — neutral (“payment could not be processed”) | Only after checking PSP status | Verify beneficiary PSP SCT Inst availability; retry when confirmed |
| RJCT + RR04 (regulatory) | Critical | Internal escalation only | No | Compliance review before any retry |
| Timeout (no pacs.002) | Warning | Yes — “payment is being confirmed” | No — check status first | Send pacs.028 (or PSP status query); confirm outcome before retry |
| pacs.004 return (post-settlement) | Warning | Yes — “payment was reversed” | Yes, after investigating reason | See reason code; treat as R-transaction return |
| camt.056 recall received | High | Internal | N/A | Respond within 15 banking business days; return via pacs.004 FOCR if agreed |
Customer-message guidance
What you tell the payer at each failure determines whether they take the right action or contact support.
RJCT + account/format errors (AC01, AC04, AC06): “Your payment could not be sent. Please check the account details with the person you’re paying and try again.” Do not disclose that the account is closed — that is the beneficiary’s information, not yours to share.
RJCT + amount limit (AM02): “This payment exceeds the limit for instant transfers. You can try a lower amount, or we can send it via standard bank transfer [if you offer fallback SCT].”
RJCT + infrastructure failures (AB codes): “Your payment could not be processed right now due to a technical issue. We’ll try again automatically.” If automated retry is not configured, tell the payer you are looking into it and will confirm. Do not blame the beneficiary bank by name.
Timeout (no confirmation): “We’re confirming your payment — this can take a moment. We’ll notify you as soon as it completes or if it needs to be re-sent.” Update once pacs.028 confirms outcome. Never leave a payer with a “confirming” message for more than a few minutes without resolution.
Post-settlement return: “A payment of [amount] was reversed by the receiving bank. Your account has been credited. Please verify the account details before retrying.”
Recall (you initiated): Explain the recall to the payer but set expectations that it requires the beneficiary’s cooperation. “We have requested return of the payment. The receiving bank has up to [X] business days to respond.”
Monitoring and reconciliation checklist
- Real-time reject rate by code category. Spike in AB codes = CSM or beneficiary PSP connectivity issue. Spike in AC codes = data quality issue (IBAN errors at entry, stale account data).
- Timeout rate. Timeouts above your baseline (set this per your PSP) indicate CSM latency or infrastructure degradation. Alert on sustained elevated timeout rates.
- pacs.002 round-trip latency. Track the time from pacs.008 submission to pacs.002 receipt. Rising latency before a timeout spike is an early warning.
- Recall response rate. Track camt.056 sent vs pacs.004 FOCR received vs camt.029 (refused). A low FOCR rate on non-FRAD recalls is normal (beneficiary may legitimately decline CUST/AM09/AC03).
- VoP result distribution. Track MTCH / CMTC / NMTC / NOAP rates. A rising NMTC rate on a specific payee corridor indicates data quality issues in your beneficiary database.
- Reconcile every pacs.008 to a pacs.002. Every SCT Inst instruction must have a matching outcome message. Open items (no pacs.002 received) should trigger pacs.028 status queries automatically before end of day.
- Daily sanctions screening logs. Under IPR Article 5d, your PSP screens customers daily — not per payment. If a customer is flagged overnight, their next instant payment attempt will generate a hold or RR04. Your monitoring should track same-day hold patterns after list updates.
Bank and PSP escalation checklist
When escalating a failed or stuck SCT Inst to your bank or PSP, provide these in order:
Always provide:
- UETR (the end-to-end transaction reference — UUID v4, present in pacs.008 and pacs.002)
- TxId / Instruction reference (your bank’s internal reference for this payment leg)
- Exact time of submission (ISO DateTime with millisecond precision, which the 2025 rulebook requires)
- Amount and currency
- Debtor IBAN and Debtor Agent BIC
- Creditor IBAN and Creditor Agent BIC
- pacs.002 status received (ACCP, RJCT, or none) and reason code if RJCT
For timeouts, also provide:
- Confirmation that account restoration occurred (T+10 passed)
- Whether a pacs.028 status query was sent and the response received
- Whether the customer has been notified
For recalls, also provide:
- Settlement timestamp (from the positive pacs.002)
- camt.056 message reference and date sent
- Recall reason code used (DUPL / TECH / FRAD for bank-initiated; CUST / AM09 / AC03 for RFRO)
- Any camt.029 response received and its negative reason code
What to quote to your bank:
- “Please confirm the pacs.002 status for UETR [xxx] received at [timestamp]”
- “Please send pacs.028 status request for UETR [xxx]”
- “Please initiate camt.056 recall for UETR [xxx] with reason FRAD”
- Reference the EPC131-17 v3.1 Clarification Paper when the bank questions recall eligibility or timelines
Recall procedure: camt.056 mechanics
For SCT Inst, recall uses the same message protocol as SCT: camt.056 (FI-to-FI Payment Cancellation Request). Two procedures apply, both covered in the SEPA R-transaction reference.
Bank-initiated Recall (10 banking business days; FRAD extends to 13 months): Initiated by the originator bank for DUPL (duplicate payment), TECH (technical error), or FRAD (fraud). The beneficiary bank has 15 banking business days to respond. A positive response returns funds via pacs.004 with FOCR. Only one recall attempt per transaction is permitted — a negative camt.029 response closes the recall procedure for that payment.
Request for Recall by Originator (RFRO, up to 13 months): Initiated by the payer via their bank, for CUST / AM09 / AC03. The beneficiary can legitimately decline. If declined, the payer’s options shift to dispute or legal channels.
Post-settlement returns (pacs.004): Separate from recall — these are bank-initiated reversals of settled payments for technical reasons. The beneficiary bank returns funds unilaterally, without requiring originator agreement. These are far less common in SCT Inst than in batch schemes.
Common pitfalls
Treating all RJCT as final without checking the code. AB and AG codes support retry after a brief interval; AC and MD codes do not. A flat “payment failed, please retry” response on an AB code is correct UX; the same response on an AC04 sends the payer on an impossible retry loop.
Retrying on timeout before confirming status. A timeout means the outcome is unknown — not that the payment failed. Retrying immediately risks a duplicate if the original settled silently. Always pacs.028 before retry.
Assuming VoP NOAP means the beneficiary account is closed. NOAP means the check could not run — the account may be open, the beneficiary PSP may simply be unreachable, or the service is temporarily down. Do not block or flag the payer as fraudulent based on NOAP.
Using stale timing figures. The pre-2025 rulebook allowed up to 25 seconds. The 2025 rulebook (effective 5 October 2025) is 5/7/9/10. Any internal SLAs, runbooks, or monitoring thresholds based on the old window are now incorrect.
Missing the 15-banking-business-day recall response window. If you receive a camt.056 from a counterparty, non-response within 15 banking business days constitutes a rulebook breach. Log and calendar every incoming camt.056 against its deadline.
Expecting granular VoP failure reasons. The EU VoP scheme returns only four codes; every failure is NOAP with no scheme-level reason. Granularity beyond the four codes is provider-proprietary.
Scope note
Tier 1 — Scheme rules (high confidence): The 5/7/9/10-second execution framework, account restoration obligation, pacs.002 ACCP/RJCT two-outcome model, recall timelines (10 banking business days / FRAD 13 months / 15-day response), camt.056/camt.029/pacs.004 FOCR mechanics, and the reason code set. Sources: EPC004-16 2025 v1.1 rulebook (gated PDF, confirmed via public secondary sources; v1.1 superseded v1.0 on 5 October 2025 with no timing or operational changes), EPC131-17 v3.1 Clarification Paper, EPC059-18 v6.0 reason code guidance.
Tier 2 — Regulatory obligations (confirmed): IPR deadlines, sanctions screening shift to daily customer screening (Article 5d), VoP mandate, pricing parity, amount cap removal. Source: Regulation (EU) 2024/886.
Tier 3 — PSP/implementation variation (noted where applicable): pacs.028 implementation (some PSPs expose a status-query endpoint that abstracts this; others require direct CSM query), per-PSP amount limits above the old €100,000 EPC cap, and specific API error representations of pacs.002 reason codes. These vary by PSP — verify with your integration documentation.
Tier 4 — Operator runbook advice: Action tables, customer messaging, and escalation checklists in this article are based on scheme mechanics plus operator documentation. Verify specific thresholds (retry intervals, escalation timelines) with your PSP.
Dropped or caveated: The prior 25-second window is explicitly superseded by the 2025 rulebook; any source quoting 25 seconds is referencing a pre-October-2025 version. ACSC and ACCC exclusion from the SCT Inst flow is confirmed by TIPS documentation but the canonical EPC IGs (EPC122-16 2025 v1.1) are gated — if your PSP’s pacs.002 schema includes ACSC/ACCC, verify their implementation profile.
Related references
- SEPA Return and Reject Codes: The R-Transaction Reference — the full reason-code tables (AB, AG, AC, AM, RR, MD codes) and scheme applicability matrix that this runbook links to rather than duplicates.
- Verification of Payee and CoP: The Match-Code Reference — the EU VoP four-code model and operator handling for the pre-submission name check.
- EU Instant Payments Regulation: The Compliance Timeline — the IPR deadlines, pricing parity, sanctions-screening shift, and VoP mandate that govern the compliance context for this runbook.
- SEPA Credit Transfer, Instant, and Direct Debit: Operator Guide — the scheme mechanics and SCT Inst participation background that underlies this runbook.
For term definitions — SEPA and IBAN — see the Payments Glossary.
Sources & methodology (11)
SCT Inst 2025 rulebook timing: 5-second target, 7-second CSM hard timeout, 9-second final confirmation deadline, 10-second account restoration obligation; effective 5 October 2025
Timing confirmed by Red Compass Labs and Mambu secondary sources; canonical source is EPC004-16 2025 v1.1 (gated PDF; v1.1 superseded v1.0 on 5 October 2025 with no changes to the timing framework)
Checked:
SCT Inst 5/7/9/10-second framework: originator PSP must process and forward within 5 seconds; beneficiary PSP or CSM must confirm by 7 seconds; originator PSP receives confirmation by 9 seconds; account restoration by 10 seconds if no confirmation
Checked:
EPC-level €100,000 SCT Inst cap removed in 2025 rulebook; PSPs set own limits which under EU IPR cannot be lower than their SCT limits
Checked:
IPR Article 5d mandates daily customer screening against EU sanctions lists (at least once per calendar day) rather than per-transaction checks; compliance deadline January 9 2025
Article 5d of Regulation (EU) 2024/886; EUR-Lex direct access returned empty content but Article number confirmed via multiple secondary sources
Checked:
pacs.002 in SCT Inst carries ACCP (positive acceptance) or RJCT (rejection); ACSC and ACCC are not used in the SCT Inst inter-PSP flow
TIPS flow shows PSP B sends pacs.002 ACCP to confirm acceptance; TIPS sends pacs.002 settlement confirmation to both PSPs post-settlement; RJCT carries reason code
Checked:
pacs.028 (FI to FI Payment Status Request) is used in SCT Inst to query payment status when no pacs.002 confirmation arrived; TIPS/RT1 responds with pacs.002
Checked:
SCT Inst recall: camt.056 initiated within 10 banking business days (FRAD 13 months); beneficiary must respond within 15 banking business days; positive response via pacs.004 with FOCR; negative via camt.029
Checked:
EPC131-17 v3.1 (April 2025) Clarification Paper on SCT and SCT Inst Scheme Rulebooks — recall reason codes DUPL/TECH/FRAD, RFRO codes CUST/AM09/AC03, 15 banking business day response obligation
PDF direct access blocked; facts cross-confirmed with the R-transaction reference article and secondary operator sources citing EPC131-17
Checked:
Regulation (EU) 2024/886 (Instant Payments Regulation) — VoP mandatory Oct 2025, pricing parity, eurozone deadlines Jan 2025 (receive) and Oct 2025 (send)
Checked:
EPC059-18 v6.0 (November 2024) Guidance on Reason Codes for SCT Inst R-transactions — AB05/AB06/AB07/AB08 infrastructure codes, AG09/AG10/AG11 availability codes, AM02 amount limit reject
Reason code set sourced from the SEPA R-transaction reference article which cites this document directly
Checked:
Mambu confirms SCT Inst 2025 rulebook: 5/7/9/10 second timing framework, timestamp millisecond precision, cap removal, only one recall per transaction
Checked:
Source types explained in our Methodology.
By Shaun Toh · Director, Digital Payments · Razer