{ "corpus": "orca-reason-codes", "format_version": "1", "built": "2026-09-26", "snapshot": "2026-09-20", "commit": "019924ac64ee0aa0742b8f02a04488a83633385d", "license": { "name": "Creative Commons Attribution 4.0 International (CC BY 4.0)", "spdx": "CC-BY-4.0", "url": "https://creativecommons.org/licenses/by/4.0/", "attribution": "Data from Orca (https://qstve.com/orca/), CC BY 4.0. Snapshot 2026-09-20.", "notice": "Reference material about published payment rules. Not legal, compliance or financial advice. Orca cites rulebooks by section and edition and does not reproduce them; rights in the cited documents stay with their authors." }, "rails": [ { "rail": "apple-pay", "name": "Apple Pay (pass-through wallet)", "governing_authority": "Apple, through the Apple Developer Program License Agreement and the Acceptable Use Guidelines for Apple Pay on the Web, for the wallet's own rules; the card network, the card issuer and the merchant's acquirer for the payment itself", "record_label": "Rail Facts", "brief": "docs/rails/pass-through-wallets.md", "snapshot": "2026-09-20", "known_gaps": [ "no money moves on this rail: Apple Pay hands a card credential to a merchant, and the payment is a card payment on the card network, so every facet below says what Apple rules and what the network rules, and links to the visa and mastercard facts rather than restating them", "the network rules themselves are not restated here and no Visa or Mastercard document was read for this rail; the wallet facts link by uid to corpus/visa, corpus/mastercard and corpus/visa-dispute, which rest on those rulebooks", "Apple Pay Platform Web Terms and Conditions: accepted inside a developer account, no public copy, not read", "Apple Platform Security (the Apple Pay chapter), the Apple Pay planning and marketing pages, the Human Interface Guidelines and the Apple Pay Marketing Guidelines: not among the pages saved on 2026-09-20 and not read, so the in-store contactless flow, the Secure Element's role and the branding rules rest only on what the pages that were read say", "PKPaymentError and the other PassKit error codes: not read; there is no code list for this rail and the token fields sit in the messages fact", "no amount limit of Apple's own was found in the pages read; whether one exists is unverified", "Apple merchant tokens for recurring and merchant-initiated charges: how one is revoked, disputed or expires was not read, so no Mandate is drafted", "the public Developer Program License Agreement is a convenience copy; the version a developer accepts in its account is the binding one, as the page itself says", "outside this rail: Apple Cash, Apple Card, transit, identity, loyalty and access passes, Tap to Pay on iPhone, and purchases of Apple's own goods and services, where Apple is the merchant" ] }, { "rail": "au-npp", "name": "New Payments Platform (Australia)", "governing_authority": "NPP Australia Limited", "record_label": "Rail Facts", "brief": "docs/rails/au-npp.md", "snapshot": "2026-09-20", "known_gaps": [ "the current edition of the governing rulebook. NPPA publishes NPP Product Rules v.31 of September 2026 openly, and all 102 pages are scanned images with no text layer and no extractable character, so every record here rests on the previous readable edition, NPP Regulations v21.0 of 24 September 2024, and what moved between the two is not held", "the NPP Product Procedures, which are available to members and direct affiliates only under AP+ Scheme Rule 1.2(e). They hold the interbank reason code values, every response timeout, every return and acknowledgement window, the mandate indemnity settlement periods, the Mandate Authorisation Standards, the Confirmation of Payee rules and the definition of a Debtor Payment Arrangement", "the interbank reason code values a rejected Clearing Request and a rejected Mandate Payment Initiation Request must carry. Regulation 6.3(a)(ii) and Regulation 17.8(b)(i) require a valid and applicable reason code and neither lists a value", "mandate status reason code values, which no public AP+ document lists", "Confirmation of Payee reason code values, which live in NPP Procedures Volume 12 and on the developer portal", "every NPP timeout, return window and service availability target. Each is a configurable value or a target prescribed in the Procedures, and no public figure exists for any of them", "the AP+ developer portal documentation, whose robots.txt disallows the documentation path and which requires an account", "which institutions subscribe to the ePayments Code. The Code binds subscribers only and ASIC's subscriber list was not opened", "whether a Clearing Participant, a Connected Institution or an Identified Institution can be named. Nothing public distinguishes them; the RBA's RITS membership list identifies Fast Settlement Service participants only", "BECS, BPAY and eftpos, which are separate schemes under the same parent and would need their own briefs" ] }, { "rail": "au-npp-reject", "name": "NPP Payment Initiation Reason Codes (Australia)", "governing_authority": "NPP Australia Limited", "record_label": "Reject Reasons", "brief": "docs/rails/au-npp.md", "snapshot": "2026-09-20", "known_gaps": [ "these 33 values belong to the customer to institution leg, not to the interbank leg. The authority publishes them as guidance for the payment instruction a corporate or government customer sends its own institution, says that accepting such instructions is proprietary and at each institution's discretion, and notes that an institution may offer alternative reason codes", "the interbank reject code values. Regulation 6.3(a)(ii) obliges a valid and applicable reason code on a rejected clearing request and Regulation 17.8(b)(i) obliges one on a rejected mandate payment initiation request, and neither lists a value. Both point at the NPP Procedures, which are available to members and direct affiliates only", "the return reason values a pacs.004 may carry, which sit in NPP Procedures Volumes 3 and 9", "mandate status reason code values, which no public AP+ document lists", "Confirmation of Payee reason code values, which sit in NPP Procedures Volume 12 and on the developer portal", "which values a given Australian institution actually uses, and with what meanings. One participant publishes its own NPP return and reversal code list of about 50 values, and on five shared values it disagrees with the authority's list; those disagreements are in corpus/conflicts.json and are not resolved here", "the four status code values ACTC, ACSC, RJCT and PART are not reason codes and are not drafted here as records. They are described in the au-npp messages fact and in au-npp:rule.messages-four-status-code-values-on-the-initiation-leg" ] }, { "rail": "bancontact", "name": "Bancontact (Belgian debit card scheme and Bancontact Pro)", "governing_authority": "Bancontact Company SA/NV (card scheme rules, not public; Bancontact Pro and Bancontact Pay terms, public)", "record_label": "Rail Facts", "brief": "docs/rails/bancontact.md", "snapshot": "2026-09-19", "known_gaps": [ "the Bancontact card scheme rules and fees manual: not public (members and candidates under NDA); card scheme lines rest on the 2014 SEPA compliance answer and processors' pages", "EPI's Wero scheme rules, including chargeback windows and grounds: not read", "the app-level limits on the Bancontact FAQ: the answers did not load", "the fall-back interchange and service fee table on the legal specifications page: published as an image, not read", "Bancontact One Click stored credentials and recurring payments (the Wallet Initiated Program): not read; a Mandate is held", "card issuers' terms for Bancontact cards and Belgian payment services law: not read", "the Bancontact Pro API references (OpenAPI files) and the new URLs of 2026-05-11: not read", "no public payment reason code list; the API statuses and error codes are in the messages fact, with no code directory", "outside this rail: Wero as a scheme, Apple Pay as a wallet, ATM withdrawals, and closed-loop balances" ] }, { "rail": "blik", "name": "BLIK", "governing_authority": "Polski Standard Płatności S.A. (PSP)", "record_label": "Rail Facts", "brief": "docs/rails/blik.md", "snapshot": "2026-09-19", "known_gaps": [ "BLIK error and response codes: they sit in the Technical Specification for Participants (Annex 3 to the rulebook), which PSP does not publish; the one code on a public PSP page, ER_PAYID_UNHANDLED, is described in the messages fact rather than as a code record", "the rulebook annexes (price lists, fees, the Technical Specification and the operating procedures for the settlement guarantee, the settlement timetable, complaints, the acquirer reverse position and fraud risk), which hold the per-transaction limit, code validity, complaint deadlines and the multi-session timetable", "NBP's own pages on BLIK oversight and SORBNET3, which answered with a bot challenge", "the Payment Services Act and the Settlement Finality Act, which the rulebook names; consumer rights are stated only as far as the rulebook and PSP's pages go", "Express Elixir, which carries most phone transfers, is not held as a rail; its rulebook is cited for the P2P leg only", "BLIK Płacę Później (deferred payment) and BLIK in Romania and Slovakia are outside this rail" ] }, { "rail": "boleto", "name": "Boleto (Brazil payment slip arrangement)", "governing_authority": "Banco Central do Brasil (BCB)", "record_label": "Rail Facts", "brief": "docs/rails/boleto.md", "snapshot": "2026-09-19", "known_gaps": [ "Núclea's SILOC operating regulation, manual of operations and manual of layouts: the documents page loads by script and was not read, so SILOC windows, default handling and the interbank devolução codes are not held", "the participants' convention in force under Res. BCB 443 art. 20: the only edition found in public is the 2021 Convenção da Cobrança, made under the revoked Circular 3.598/2012", "the central database's operations and layout manuals, which the 2021 convention treats as trade secrets given to participants only", "CNAB240 bank-to-client codes (C044 movement codes and C047 occurrence reasons): held for the first pass; version 11.0 is marked preliminary", "the exact processing cut-off between SILOC's afternoon boleto cycle (same day) and the next morning's cycle, left by the SILOC manual of operations to a SILOC processing manual not read", "BCB Comunicados on the convention governance structure and the dynamic boleto schedules, Res. BCB 150/2021, Res. BCB 304/2023 and the consumer code (Lei 8.078/1990): not read", "outside this rail: the Febraban arrecadação barcode for utility bills and taxes, protest at a notary, the duplicata escritural as an asset, and Split Payment of CBS and IBS" ] }, { "rail": "ca-acss", "name": "Canada ACSS (Automated Funds Transfer)", "governing_authority": "Payments Canada", "record_label": "Return Reason Codes", "brief": "docs/rails/ca-acss.md", "snapshot": "2026-09-18", "known_gaps": [ "scope is Canadian dollar Automated Funds Transfer (direct deposits and pre-authorized debits) on the ACSS; cheques, point-of-service items and US dollar AFT under Rule K8 and the US Bulk Exchange are not covered", "the Standard 007 transaction codes are not held as records; only the few that change a payor's rights are named inside the rail facts", "By-law No. 3 and Rules A4, A6, D1, D2, D3 and J10 have not been read, so clearing status, items in dispute and interest claims rest on cross-references only", "provincial consumer protection law and the federal financial consumer protection framework have not been read" ], "watch": { "running": true, "cadence": "monthly", "inputs": [ "Payments Canada Standard 007", "Payments Canada Standard 005", "Payments Canada Rule H1", "Payments Canada Rule F1", "Payments Canada Rules L1 and L2", "Payments Canada ACSS rules quick links index", "Canadian Payments Act (Justice Laws)" ], "last_run": "2026-09-18", "result": "no change", "inputs_seen": { "standard_007": "amendment 10, approved 2026-05-28, in force 2026-07-03; 21 return reason codes (906 retired)", "standard_005": "amendment 23, approved 2024-05-23, in force 2024-07-22", "rule_h1": "amendment 13, approved 2026-05-28, in force 2026-07-27", "rule_f1": "latest amendment approved 2026-05-28, in force 2026-07-27", "rule_l1": "amendment 14, approved 2025-12-08, in force 2026-02-09", "rule_l2": "amendment 8, approved 2025-09-18, in force 2025-11-24", "acss_index": "quick links PDF lists Rules A to L, Standards 005 to 023, By-laws 3 and 6; no dates shown", "canadian_payments_act": "Justice Laws text current to 2026-07-21" } } }, { "rail": "ch-sic", "name": "Swiss Interbank Clearing (SIC)", "governing_authority": "SIX Interbank Clearing on behalf of the Swiss National Bank", "snapshot": "2026-09-18", "record_label": "Rail Facts", "brief": "docs/rails/ch-sic.md", "known_gaps": [ "this directory holds the profile of the SIC RTGS service only; the instant payments service has its own profile in corpus/ch-sic-ip", "the SIC Handbook, SIC circulars, the three-digit SIC error code list and the SIC5 Project Phase 2 document are published only to participants on the SIC Ltd extranet and have not been read, so operating detail that lives only there is not asserted", "the SIX clearing day calendar has not been read, so which Swiss holidays open no clearing day is not asserted", "no public source read gives a deadline for answering a return request or for sending a return", "the participation agreements between participants, the SNB and SIC Ltd, and the SNB Terms of Business have not been read, so how liability is shared between them is not asserted", "the SNB instruction sheets on the intraday facility and the liquidity-shortage financing facility have not been read", "Swiss law was read only in unofficial English translations of the National Bank Ordinance, the Financial Market Infrastructure Act and the Code of Obligations; no case law or legal commentary on bank transfers was read" ], "watch": { "running": true, "cadence": "monthly", "inputs": [ "SIX download center (standardization/sic-eurosic//)", "SIC platform release notes", "SNB SIC page and Report on the SIC System and Disclosure Report", "SNB instruction sheet on admission to the SIC system" ], "inputs_seen": { "release_folder": "5-3 (release 5.3, valid from 2026-11-13); no later release folder listed", "release_notes": "Release Notes 2026 v1.3, dated 2026-09-21", "base_document": "IG Base Document CH Interbank v2.7 (2026-05-20)", "rtgs_module_docs": "release 5.3: pacs.002 v2.4, pacs.004 v2.6, pacs.008 v2.7, camt.056 v2.4, camt.029 v2.3", "snb_report": "Report on the SIC System and Disclosure Report 2025 (latest listed)", "snb_instruction_sheet": "2023-11-17, updated 2025-02-27" }, "last_run": "2026-09-18", "result": "no change" } }, { "rail": "ch-sic-ip", "name": "SIC Instant Payments (SIC IP)", "governing_authority": "SIX Interbank Clearing on behalf of the Swiss National Bank", "snapshot": "2026-09-18", "record_label": "Rail Facts", "brief": "docs/rails/ch-sic.md", "known_gaps": [ "this directory holds the profile of the SIC IP service only; the SIC RTGS service has its own profile in corpus/ch-sic, and the SIC IP reason codes sit in their own directories", "the SIC Handbook, the SIC IP Service Handbook (which holds the IP message flow diagrams), SIC circulars and the three-digit SIC error code list are published only to participants on the SIC Ltd extranet and have not been read", "the time-out after which the service cancels an instant payment, and the time a receiving participant has to answer, are not given in any public source read", "the governing text for the CHF 20,000 per payment limit and for raising it bilaterally is not public; the figure rests on the SNB report on the SIC system", "no public source read gives a deadline for answering an IP return request or for sending an IP return", "whether the Instant Payments Bridge was approved, a decision the SNB report placed in mid-2026, is not established", "Swiss law was read only in unofficial English translations of the National Bank Ordinance, the Financial Market Infrastructure Act and the Code of Obligations; no case law or legal commentary on bank transfers was read" ], "watch": { "running": true, "cadence": "monthly", "inputs": [ "SIX download center (standardization/sic-eurosic//)", "SIC platform release notes", "SNB SIC page and Report on the SIC System and Disclosure Report", "SNB instruction sheet on admission to the SIC system" ], "inputs_seen": { "release_folder": "5-3 (release 5.3, valid from 2026-11-13); no later release folder listed", "release_notes": "Release Notes 2026 v1.3, dated 2026-09-21", "ip_module_docs": "release 5.3: pacs.002 v2.4, pacs.004 v2.4, pacs.008 v2.3 (2026-02-27); camt.056 v2.3, camt.029 v2.3 (2025-02-28)", "snb_report": "Report on the SIC System and Disclosure Report 2025 (latest listed)", "snb_instruction_sheet": "2023-11-17, updated 2025-02-27; receive obligation by November 2026 unchanged" }, "last_run": "2026-09-18", "result": "no change" } }, { "rail": "ch-sic-ip-reject", "name": "SIC IP Payment Rejections", "governing_authority": "SIX Interbank Clearing on behalf of the Swiss National Bank", "snapshot": "2026-09-18", "record_label": "Reject Reasons", "brief": "docs/rails/ch-sic.md", "known_gaps": [ "the SIC IP hard time-out value and the operating detail of each status report type sit in the participant-only SIC Handbook, so no reject deadline is given", "the three-digit SIC error codes carried by NOK acknowledgements are listed only in the participant-only SIC Handbook and have no records here", "the ISO 20022 External Code Set definitions behind the permitted codes were not read, so meanings rest on the code names SIX prints", "how a failed transfer payment from the SIC IP service is reported after release 5.3 is described only in an extranet document" ], "watch": { "running": true, "cadence": "monthly", "inputs": [ "SIX download center (standardization/sic-eurosic//)", "SIC IP module document pacs.002" ], "inputs_seen": { "ip_pacs002": "release 5.3 v2.4 (2026-02-27, valid from 2026-11-13); ED06 removal unchanged, date not yet passed", "release_folder": "5-3; no later release folder listed" }, "last_run": "2026-09-18", "result": "no change" } }, { "rail": "ch-sic-ip-return-request", "name": "SIC IP Return Requests", "governing_authority": "SIX Interbank Clearing on behalf of the Swiss National Bank", "snapshot": "2026-09-18", "record_label": "Return Request Reasons", "brief": "docs/rails/ch-sic.md", "known_gaps": [ "no public text sets how long after settlement a return request may be sent or how fast the receiving participant must answer; any such limit would be in the participant-only SIC Handbook", "the ISO 20022 External Code Set definitions behind the six codes were not read, so meanings rest on the code names SIX prints", "the SIC RTGS return request codes, which SIX recommends but does not check, are not in this directory" ], "watch": { "running": true, "cadence": "monthly", "inputs": [ "SIX download center (standardization/sic-eurosic//)", "SIC IP module document camt.056" ], "inputs_seen": { "ip_camt056": "release 5.3 v2.3 (2025-02-28)", "release_folder": "5-3; no later release folder listed" }, "last_run": "2026-09-18", "result": "no change" } }, { "rail": "ch-sic-ip-return-request-rejection", "name": "SIC IP Return Request Rejections", "governing_authority": "SIX Interbank Clearing on behalf of the Swiss National Bank", "snapshot": "2026-09-18", "record_label": "Return Request Rejection Reasons", "brief": "docs/rails/ch-sic.md", "known_gaps": [ "no public text sets how fast a return request must be answered; any such limit would be in the participant-only SIC Handbook", "the ISO 20022 External Code Set definitions behind the seven codes were not read, so meanings rest on the code names SIX prints", "the SIC RTGS return request rejection codes, which SIX recommends but does not check, are not in this directory" ], "watch": { "running": true, "cadence": "monthly", "inputs": [ "SIX download center (standardization/sic-eurosic//)", "SIC IP module document camt.029" ], "inputs_seen": { "ip_camt029": "release 5.3 v2.3 (2025-02-28)", "release_folder": "5-3; no later release folder listed" }, "last_run": "2026-09-18", "result": "no change" } }, { "rail": "ch-sps-status", "name": "Swiss Payment Standards Status Report Reasons", "governing_authority": "SIX Interbank Clearing (Swiss Payment Standards)", "snapshot": "2026-09-18", "known_gaps": [ "NARR, the code a Swiss bank uses for its own free-text status reason, has no record here", "institution-specific proprietary codes that a bank may send in the Proprietary element are not covered, and no bank's list has been read", "the ISO 20022 external code set was refused to a plain request, so whether ISO has registered every CH code is not established", "each bank's own processing rules, cut-off times and duplicate-check periods sit outside the Swiss Payment Standards and are not covered", "the interbank SIC and SIC IP reason codes are a separate family and are not in this directory" ], "record_label": "Status Reasons", "brief": "docs/rails/ch-sic.md", "watch": { "running": true, "cadence": "monthly", "inputs": [ "SIX download center (standardization/sps/)", "SPS Status Report implementation guidelines", "SPS Business Rules", "SPS consultation documents" ], "inputs_seen": { "status_report_ig": "SPS 2026 v2.2 (2026-02-20, valid from 2026-11-14); SPS 2024 v2.1 still listed", "business_rules": "SPS 2026 v3.3 (2026-02-20, valid from 2026-11-14)", "consultation": "consultation-report-sps2026 and revision-ig-sps2026 listed; no SPS 2027 file listed (not opened)" }, "last_run": "2026-09-18", "result": "no change" } }, { "rail": "eps", "name": "Austria eps-Überweisung", "governing_authority": "PSA Payment Services Austria GmbH", "record_label": "Rail Facts", "brief": "docs/rails/eps.md", "snapshot": "2026-09-19", "known_gaps": [ "the eServices legal framework agreement and the eps merchant contracts, which hold the guarantee and liability terms: not public", "whether debtor banks execute eps transfers as SCT Inst: no eps document read says", "consumer law: PSD2 and the Austrian ZaDiG 2018 were not read, so the consumer-law fact is inference", "the German Pflichtenheft 2.7 and the XML schema description 2.7 on the same download page were not consulted" ] }, { "rail": "eps-error", "name": "eps Payment Messages", "governing_authority": "PSA Payment Services Austria GmbH", "record_label": "Error Codes", "brief": "docs/rails/eps.md", "snapshot": "2026-09-19", "known_gaps": [ "which BIC error 011 refers to, and which cross-border case error 013 covers: the guideline does not say", "which error code the Scheme Operator gives an initiation more than 3 minutes off its clock" ] }, { "rail": "eps-refund-error", "name": "eps Refunds", "governing_authority": "PSA Payment Services Austria GmbH", "record_label": "Error Codes", "brief": "docs/rails/eps.md", "snapshot": "2026-09-19", "known_gaps": [ "which code a refund of a payment older than 13 months draws", "what refund code 013 bars: the refund specification lists it without explanation" ] }, { "rail": "eps-status-reason", "name": "eps Payment Confirmations", "governing_authority": "PSA Payment Services Austria GmbH", "record_label": "Status Reasons", "brief": "docs/rails/eps.md", "snapshot": "2026-09-19", "known_gaps": [ "which status (NOK or UNKNOWN) each reason travels with, and whether the debtor bank or the Scheme Operator writes it: the guideline lists the codes without saying, so those links are inference", "the success value 100 (no errors) is described in the status-values Rule, not as a code" ] }, { "rail": "fednow", "name": "FedNow", "governing_authority": "Federal Reserve", "record_label": "Rail Facts", "brief": "docs/rails/fednow.md", "snapshot": "2026-09-17", "known_gaps": [ "reason and error code lists: Operating Procedures Appendix D is redacted as confidential, and the ISO 20022 message specifications that hold the permitted codes per message are on MyStandards and FedNow DevRel behind logins; only 9 codes are public (FRAD, WNTB, FR01, F002, F101, F008, F009, AG09, NARR)", "Operating Procedures sections 10.4 account activity thresholds, 10.5 Network Intelligence, 11 fraud reporting, Appendix E test cases and Appendix G service level expectations are redacted in the public version", "count of live FedNow participants not taken: the lists are spreadsheets and the routing number list is offered under an access acknowledgement", "Article 4A as set out in Regulation J appendix A not read section by section; every 4A section named in the liability, recall and finality facts is cited as Regulation J or Operating Circular 8 cites it", "Operating Circular 1 (accounts, Account Holder eligibility) and Operating Circular 5 (general financial service provisions, security procedures) not read", "the Board's 2026-04-10 Regulation J proposal on intermediaries (91 FR 18330) is still a proposal: the Federal Register lists no final rule as of 2026-09-18", "the limits fact does not yet carry the 2025-11-12 start date of the 10,000,000 dollar network maximum, which a Federal Reserve Financial Services announcement of that date gives" ], "watch": { "running": true, "cadence": "monthly", "last_run": "2026-09-18", "result": "no change", "inputs_seen": [ { "name": "Operating Circular 8", "url": "https://www.frbservices.org/resources/rules-regulations/operating-circulars.html", "class": "authoritative_primary", "seen": "effective 2026-04-01 (040126-operating-circular-8.pdf), with summary of changes and redline from the 2026-01-05 version" }, { "name": "Operating Circular 5", "url": "https://www.frbservices.org/resources/rules-regulations/operating-circulars.html", "class": "authoritative_primary", "seen": "effective 2026-05-15 (051526-operating-circular-5.pdf)" }, { "name": "FedNow Service Operating Procedures, public version", "url": "https://www.frbservices.org/binaries/content/assets/crsocms/resources/rules-regulations/042826-fednow-service-operating-procedures.pdf", "class": "authoritative_primary", "seen": "April 2026, version 3.6; 134 pages, 2,242,782 bytes; redline from the 2026-02-13 version" }, { "name": "Regulation J, 12 CFR part 210", "url": "https://www.ecfr.gov/api/versioner/v1/versions/title-12.json?part=210", "class": "authoritative_primary", "seen": "latest amendment 2022-10-12, latest issue 2023-03-29" }, { "name": "Federal Register, Federal Reserve documents on FedNow and Regulation J", "url": "https://www.federalregister.gov/api/v1/documents.json", "class": "public_primary", "seen": "newest FedNow items 2026-05-26 (Regulation D proposal; payment system risk policy notice); Regulation J proposal 2026-06996 of 2026-04-10 still the newest Regulation J rulemaking, no final rule" }, { "name": "Federal Reserve Financial Services communications", "url": "https://www.frbservices.org/news/communications", "class": "public_primary", "seen": "newest FedNow item 111225-fednow-transaction-limit-increase (2025-11-12); Network Intelligence API item listed" }, { "name": "Fed360 newsletter", "url": "https://www.frbservices.org/news/fed360", "class": "public_primary", "seen": "issue 2026-09-15; FedNow discount program from 2027-01-01 (pricing only)" }, { "name": "Technical Overview and Planning Guide", "url": "https://explore.fednow.org/resources/technical-overview-guide.pdf", "class": "public_primary", "seen": "version 1.2, 2025-07-17" } ] } }, { "rail": "gcc-afaq", "name": "GCC AFAQ (cross-currency payments)", "governing_authority": "SAMA (Saudi participant rules); GCC central banks via GPC (system)", "record_label": "Rail Facts", "brief": "docs/rails/gcc-afaq.md", "snapshot": "2026-09-18", "known_gaps": [ "this directory holds rail facts drawn from SAMA's public AFAQ operating rules and charging policy, which bind Saudi direct participants only, and from the Gulf Payments Company's public web pages; the GPC Operating Rules and Regulations are marked confidential and were not used", "the participant rules of the other five GCC central banks were not read, so facts that depend on the sending or receiving country's own rules are stated for Saudi participants only", "the controlled documents that set message formats, the design specification and the currency conversion note are shared with participants only and were not consulted", "the settlement agent used for the end-of-day net settlement between central banks is not named in any public text read", "fees and exchange rates have no facet of their own; SAMA's participant fees and its bar on an FX margin are mentioned only where they bear on returns or customers" ], "watch": { "running": true, "cadence": "monthly", "last_run": "2026-09-18", "result": "no change", "inputs_seen": [ { "name": "SAMA, Operating Rules for Cross Currency Payments using AFAQ Service, circular 42068309", "url": "https://rulebook.sama.gov.sa/en/operating-rules-cross-currency-payments-using-afaq-service", "class": "authoritative_primary", "seen": "2021-05-05 (24/9/1442 H), status In-Force, no later version" }, { "name": "SAMA, Appendix 2 - Return and Rejection Codes (part of 42068309)", "url": "https://rulebook.sama.gov.sa/en/appendix-2-return-and-rejection-codes", "class": "authoritative_primary", "seen": "2021-05-05, In-Force; 105 codes, 27 rejection (RJ00 to RJ25, RJ90) and 78 return, the same set the corpus holds (XX00 has no record by decision); Versions block unchanged" }, { "name": "SAMA, Charging Policy for Cross Currency Payments Using AFAQ Service, circular 43038107", "url": "https://rulebook.sama.gov.sa/en/charging-policy-cross-currency-payments-using-afaq-service", "class": "authoritative_primary", "seen": "2021-12-02 (27/4/1443 H), status In-Force, no later version" }, { "name": "SAMA Rulebook, SAMA Circulars list (all sectors)", "url": "https://rulebook.sama.gov.sa/en/sama-circulars", "class": "public_primary", "seen": "newest listed 482021280 (2026-08-27, 14/03/1448 H); only 42068309 and 43038107 name AFAQ, both In-Force; the Operational Rules navigation lists the same two" }, { "name": "GPC, Regulations and Procedures page (file names and dates only)", "url": "https://www.gulf-payments.com/en/document-and-regulation/", "class": "public_primary", "seen": "four files: ORR v1.0 dated 02-Aug-2021 (content not opened), business day timetable 24062024, onboarding guide v3, participant list 01092026" }, { "name": "GPC, AFAQ participant list PDF", "url": "https://www.gulf-payments.com/wp-content/uploads/2023/03/GPC_AFAQ-Cross-Currency_List-of-participants_01092026.pdf", "class": "public_primary", "seen": "file named 01092026, PDF created and modified 2026-09-07, 8 pages, includes Qatar entries" }, { "name": "GPC, working hours and official holidays page", "url": "https://www.gulf-payments.com/en/afaq-cross-currency-service/", "class": "public_primary", "seen": "timetable 08:00 to 16:00 KSA in four windows as recorded; Friday and Saturday closed, UAE Saturday and Sunday; holiday table lists five countries, still not Qatar" }, { "name": "GPC, news listing", "url": "https://www.gulf-payments.com/en/news/", "class": "public_primary", "seen": "newest item 2026-09-07 (Qatar Central Bank joins AFAQ)" }, { "name": "GPC, services and FAQ pages", "url": "https://www.gulf-payments.com/en/our-services/", "class": "public_primary", "seen": "services page lists AED, BHD, SAR, OMR, QAR, KWD; FAQ still calls QAR forthcoming (stale, as recorded in the brief)" }, { "name": "ISO 20022 external code sets (JSON)", "url": "https://www.iso20022.org/sites/default/files/media/file/ExternalCodeSets_JSON.zip", "class": "authoritative_primary", "seen": "2Q2026_externalcodesets_v3.json, zip entry dated 2026-09-02, the same file compared when the brief was written" } ] } }, { "rail": "gcc-afaq-reject", "name": "GCC AFAQ Payment Rejections", "governing_authority": "SAMA (rules for Saudi direct participants); GCC central banks via GPC (system)", "record_label": "Reject Reasons", "brief": "docs/rails/gcc-afaq.md", "snapshot": "2026-09-18", "known_gaps": [ "SAMA's code list gives each rejection code a short label and no definition, trigger or handling rule, so the triggers and actions in these records are mostly Orca's reading of the operating rules", "the live code dictionary held in the AFAQ Central Component is not published and may differ from SAMA's appendix", "which component raises each code (the sending or receiving Regional Payment Gateway, or the Central Component) is not stated per code in any public text", "the message type and field that carry a rejection code back to a Saudi participant are set in participant-only format guides and were not consulted", "the lists other GCC central banks give their own participants were not read" ] }, { "rail": "gcc-afaq-return", "name": "AFAQ Returns (SAMA rules for Saudi participants)", "governing_authority": "Saudi Central Bank (SAMA), for its direct participants; AFAQ is owned by the six GCC central banks and run by the Gulf Payments Company", "snapshot": "2026-09-18", "record_label": "Return Reasons", "brief": "docs/rails/gcc-afaq.md", "known_gaps": [ "the return code lists and deadlines that the other five GCC central banks set for their own participants were not read, so every record reports SAMA's rules only", "SAMA publishes one line per code and no guidance on when to use each; triggers and actions beyond that line are inference", "the AFAQ message format guides are controlled documents shared with participants only, so which message field carries the code and any additional information is not stated", "the live code dictionary in the AFAQ Central Component may hold codes that the published appendix lacks", "XX00, which SAMA lists as the placeholder the Central Component puts in place of an unregistered code, has no record because it names no reason" ] }, { "rail": "google-pay", "name": "Google Pay (pass-through wallet)", "governing_authority": "Google LLC, through the Google Pay API Terms of Service and the Google Pay and Wallet APIs Acceptable Use Policy, for the wallet's own rules; the card network, the card issuer and the merchant's card acquiring bank for the payment itself", "record_label": "Rail Facts", "brief": "docs/rails/pass-through-wallets.md", "snapshot": "2026-09-20", "known_gaps": [ "no money moves on this rail: Google Pay hands a card credential to a merchant, and the payment is a card payment on the card network, so every facet below says what Google rules and what the network rules, and links to the visa and mastercard facts rather than restating them", "two credentials, and only one is a token: CRYPTOGRAM_3DS returns an Android device token with a cryptogram, PAN_ONLY returns the card number saved to the user's Google Account with no cryptogram; the device-token rules, the eciIndicator and Google's liable-party table do not reach a PAN_ONLY payment", "the network rules themselves are not restated here and no Visa or Mastercard document was read for this rail; the wallet facts link by uid to corpus/visa, corpus/mastercard and corpus/visa-dispute, which rest on those rulebooks", "the pages read cover the Google Pay API for the web; Google Pay used to tap in a store, the Android API and the merchant and PSP APIs were not read, so no in-store transaction type is recorded", "the Google APIs Terms of Service, which the Google Pay API Terms of Service incorporate, the Google Pay API Brand Guidelines, the Google Wallet consumer terms and the token lifecycle management guide: named on the pages read but not read", "no amount limit of Google's own was found in the pages read; the one amount rule is that a merchant may not set a minimum or maximum specific to a buyer paying through the API", "the reach of Google's own report-a-problem flow for a card payment to a third-party merchant is not stated on the help page that was read", "Google merchant tokens (merchantTokenId, tokenUpdateUrl) for merchant-initiated charges: how one is revoked or disputed was not read, so no Mandate is drafted", "outside this rail: Google's stored balance and bank-transfer features, Google Pay in India (a UPI app), Google Wallet passes, and purchases of Google's own goods and services such as Google Play and YouTube, where Google is the seller" ] }, { "rail": "in-upi", "name": "UPI (Unified Payments Interface)", "governing_authority": "Reserve Bank of India", "record_label": "Rail Facts", "brief": "docs/rails/in-upi.md", "snapshot": "2026-09-20", "known_gaps": [ "UPI's own scheme rules, which hold finality, settlement, operating hours, transaction limits, recall, refunds, the message specification and the response and error codes. The rail brief records their names as the UPI Procedural Guidelines and the UPI Operating Circulars [Unverified: no NPCI document has been opened by Orca]. NPCI's website answered a plain automated request with HTTP 403 on 2026-09-20, as did its robots.txt, so even its crawl policy could not be read", "UPI response and error codes: no code list has been opened, so no code list's scope has been confirmed for UPI. the Reserve Bank's register shows NPCI authorised for the Immediate Payment Service, the Aadhaar Enabled Payment System, RuPay affiliation, the National Automated Clearing House and toll collection as separate payment systems, and a code list belonging to any of those is not a UPI list", "the interbank dispute and chargeback path NPCI runs, including the periods a bank has to answer and what follows when it does not; the Reserve Bank's own ombudsman guidance defers to those periods without stating them", "the Payment and Settlement Systems Act, 2007 and the Payments Regulatory Board Regulations, 2025: the India Code copy of the Act did not answer within 45 seconds on 2026-09-20 and the Reserve Bank's own PDF host returned nothing, so both are cited as the Reserve Bank's pages describe them", "the text of the Reserve Bank Integrated Ombudsman Scheme in either its 2021 or its 2026 edition; both are PDFs on the Reserve Bank's document host, which returned nothing, so the scheme is held through the 2021 covering notification and the Reserve Bank's own 2026 questions and answers", "UPI Lite, UPI Circle, credit line on UPI and RuPay credit card on UPI, each of which has its own NPCI circulars; UPI 123Pay is held only as far as the Reserve Bank's own description of it goes", "whether the Reserve Bank's 2026 ombudsman scheme still reaches a customer of a payment system: its 2021 notification named system participants among the entities covered and the Reserve Bank's 2026 list of covered entities does not repeat that category" ] }, { "rail": "mastercard", "name": "Mastercard", "governing_authority": "Mastercard", "record_label": "Rail Facts", "brief": "docs/rails/mastercard.md", "snapshot": "2026-09-19", "known_gaps": [ "this directory holds the Mastercard profile only; the decline response codes the Transaction Processing Rules name are in corpus/mastercard-decline", "chargeback message reason codes, their conditions and their time frames: they sit in the Chargeback Guide, which is on Mastercard Connect and not on Mastercard's public rules page, so no mastercard-dispute directory exists", "the Settlement Manual (cut-off times, settlement options), the Authorization Manual and the Dual and Single Message System specifications (message timers, the full set of response codes and their valid pairing with Merchant Advice Codes) are not public to Orca", "the Data Integrity Monitoring Program manual, which holds the Excessive Chargeback Program thresholds, is not public to Orca", "Mastercard announcements, which change the rules before a new edition restates them, sit in the Technical Resource Center on Mastercard Connect and are not public to Orca", "the Mastercard Switch Rules manual is excluded by decision and was not used", "regional chapters of the Mastercard Rules and most regional sections of the Transaction Processing Rules were read only where a fact names them", "the consumer protection laws the rules defer to (for example Regulation E and Regulation Z in the United States, PSD2 in the EEA) have not been read" ] }, { "rail": "mastercard-decline", "name": "Mastercard Decline Response Codes (partial)", "governing_authority": "Mastercard", "record_label": "Decline Response Codes", "brief": "docs/rails/mastercard.md", "snapshot": "2026-09-19", "known_gaps": [ "partial list: these are the 38 DE 39 decline values that the Transaction Processing Rules name in section 4.5.5 (Table 23); Mastercard's full set of response codes and their valid pairing with Merchant Advice Codes are in the Dual and Single Message System technical specifications, which are not public to Orca", "non-decline DE 39 values that the Transaction Processing Rules mention (00 and 85 for an open account, 10 partial approval, 06, 17 and 32 on reversals, 34 for a merchant fraud cancellation) and the value 31 named only in the Europe issuer failure-rate rule have no record", "the meaning of each code is taken from Mastercard's label in Table 23 and from the rules that name the code; the definitions in the technical specifications have not been read", "Table 23 sorts the codes for transit debt recovery and first ride risk claims only; how an issuer should choose among them, and the common decline guidance in the Enhance Digital Commerce Approval Rates Operational Guide, are not public to Orca", "in the EEA, the UK and Gibraltar a customer may route through a registered switch of its choice, and the response codes that switch defines (including its soft decline for Strong Customer Authentication) are not described here" ] }, { "rail": "mx-spei", "name": "SPEI (Mexico peso interbank electronic transfers)", "governing_authority": "Banco de México", "record_label": "Rail Facts", "brief": "docs/rails/mx-spei.md", "snapshot": "2026-09-20", "known_gaps": [ "SPEI has a numbered catalogue of return causes and Orca does not hold it. Regla 24a makes the receiving participant state the cause of a devolución from the catalogue in section 9 of the Manual de Operación del SPEI, and Regla 2a, fracción XXX, defines the Manual as a document the Administrador prepares and makes available to Participantes. So the catalogue exists, it is numbered, and it is longer than the ten grounds Regla 23a names, because fracción VIII of that Regla adds every further cause the catalogue marks as such. Orca holds no mx-spei reason code records and will hold none while that stands", "the Manual de Operación del SPEI itself, which is participant only and which Orca will not obtain through third parties, mirrors or document sharing sites. Besides the return cause catalogue it holds the transfer order types and message formats (section 8), the SPEI instance assignment (section 9), the CLABE structure (section 6), the clearing cycle count (section 5.7), the contingency procedures (section 5), the CEP link construction (Apéndice E), the CoDi processing advices and mobile software requirements (Apéndice AD) and the account identifier QR specification (Apéndice AS). Regla 57a makes an applicant sign a unilateral confidentiality undertaking before it may even file for admission, so there is no legitimate route to it short of a licensed feed or Banco de México publishing it", "the Convenio de Colaboración para la Protección de Clientes Emisores, the agreement among participants that Regla 43a requires and that is the only route by which a payer who did not instruct a payment gets credited funds back. It is approved by Banco de México but not published, and Regla 30a lets it set shorter return deadlines than the Reglas, which would then govern", "the SPEI PFMI disclosure is dated 2016-03-28, which is before six of the eleven amending circulares and before the SPEI instances existed. It is the only public Banco de México document describing the settlement mechanics in prose, and every line taken from it carries that date", "how many clearing cycles an unsettled order survives before the Administrador eliminates it: Regla 17a points at section 5.7 of the Manual and no public source gives the number", "the Guías bind from Circular 9/2026 and participants have until 2026-12-14 to comply, so the interface rules drawn from them describe what will be required rather than what is required today", "general Mexican consumer and financial services law was not read: the Ley para la Transparencia y Ordenamiento de los Servicios Financieros article 22, cited in Circular 9/2026's preamble, the Ley de Protección y Defensa al Usuario de Servicios Financieros and CONDUSEF's own rules", "outside this rail: SPID (US dollars, Circular 4/2016, its own Manual and its own participants), DiMo (a Cámara de Compensación de Transferencias a Través de Dispositivos Móviles authorised under Circular 3/2013), SIAC-BANXICO and DALÍ" ] }, { "rail": "my-duitnow", "name": "Malaysia DuitNow", "governing_authority": "Bank Negara Malaysia", "record_label": "Rail Facts", "brief": "docs/rails/my-duitnow.md", "snapshot": "2026-09-18", "known_gaps": [ "this directory holds rail facts drawn from Bank Negara Malaysia's public policy documents and from participants' own published terms; the operator's scheme rules, technical standards and code lists are not public or are held under the operator's own terms and were not consulted", "no reason code records exist for this rail; DuitNow reject and response codes are held pending Dave's decision on the operator's portal terms (docs/rails/my-duitnow.md)", "the Policy Document on Financial Institutions' Response to Fraud (issued 2026-06-30) was not located on BNM's site, so liability, recall and decision-points do not reflect it", "whether the Real-time Retail Payments Platform holds a certificate of finality under FSA 2013 section 38 was not established", "how a failed or rejected transfer is returned between participants, and on what clock, is set in the operator's rules and is not described in any BNM text read", "DuitNow QR, Request, AutoDebit and cross-border services are named where BNM text covers them but have no facts of their own" ], "watch": { "running": true, "cadence": "monthly", "inputs": [ "BNM payment systems and banking policy listings", "BNM policy documents the facts cite", "participant banks' public DuitNow pages the facts cite" ], "inputs_seen": { "bnm_listing": "newest payment systems PD: IFTF BNM/RH/PD 028-143 (2026-06-30); Response to Fraud PD not listed (2026-09-18)", "iftf": "pd_IFTF_June2026.pdf, last-modified 2026-06-29", "unauthorised_ebanking_pd": "BNM/RH/PD 028-139 (2024-06-28), file last-modified 2025-09-03", "rmit_pd": "BNM/RH/PD 028-98 (2025-11-28)", "emoney_pd": "BNM/RH/PD 029-57 (2025-01-31)", "rentas_myr_procedures": "op-myr-stlmt-rentas-sep25.pdf, version 1.8 (2025-09-29)", "complaints_handling_pd": "PD_Complaints_Handling.pdf, file last-modified 2025-03-28", "gxbank_faq": "V2.0, effective 2024-03-22 (file re-uploaded 2026-09-15, content unchanged for the facts cited)", "hsbc_terms": "October 2022 v1.4, file last-modified 2022-09-21", "paynet_portal": "not read: operator terms bar automated extraction" }, "last_run": "2026-09-18", "result": "no change" } }, { "rail": "nct-inst", "name": "Nordic Credit Transfer Instant (NCT Inst)", "governing_authority": "Nordic Payments Council", "snapshot": "2026-09-18", "record_label": "Reason Codes", "brief": "docs/rails/nordic-nct-inst.md", "known_gaps": [], "watch": { "running": true, "cadence": "monthly", "inputs": [ "NPC NCT Inst rulebook page and documents archive", "NPC clarification papers and guidelines page", "NPC document library (NPC014-01, NPC100-01)", "NPC change management page and news", "Riksbank RIX-INST Instructions and news", "Norges Bank news on TIPS and NBO INST", "Danmarks Nationalbank pages on TIPS DKK" ], "inputs_seen": { "rulebook": "NPC010-01 2025 v1.1 (effective 2025-11-21), in 2025-nct-inst-documents.zip (last modified 2026-07-06); no 2027 edition published", "reason_code_guidance": "NPC020-01 v3.1 (effective 2026-07-03)", "maximum_amount": "NPC014-01 v2.0 (2024-11-25)", "scheme_currencies": "NPC100-01 v1.1 (2021-11-23)", "npc_news": "latest item September 2026, information meeting 2026-10-15; March 2026 consultation news gives November 2027 for the 2027 rulebooks", "rix_inst_instructions": "June 2026 edition (PDF last modified 2026-06-05)", "norges_bank": "Financial Infrastructure 2026: NBO INST plan under revision, no new date", "danmarks_nationalbank": "no NCT Inst change found; TIPS cross-currency corridors live June 2026 (outside NCT Inst)" }, "last_run": "2026-09-18", "result": "no change" } }, { "rail": "paypal", "name": "PayPal (staged wallet)", "governing_authority": "PayPal (regional entities; US: PayPal, Inc.)", "record_label": "Rail Facts", "brief": "docs/rails/paypal.md", "snapshot": "2026-09-19", "known_gaps": [ "only three regional user agreements were read (US, UK, Ireland); the Canadian, Australian, Asian, Latin American and other regional agreements and their protection programs are not covered", "the PayPal Balance Terms and Conditions, the Commercial Entity Agreement, the fee pages and the Acceptable Use Policy were not read, so no fee amount and no balance-account rule beyond the user agreement is asserted", "the laws the agreements invoke (the Electronic Fund Transfer Act and Regulation E, the Fair Credit Billing Act, the UK Payment Services and Electronic Money Regulations, EU payment services law) were not read; consumer statements rest on how the agreements state them", "PayPal does not publish how it settles the funding leg or its internal ledger, so settlement mechanics beyond the legal nature of the balance are not stated", "Venmo, Braintree card processing, PayPal Credit and Pay Later, Xoom and cryptocurrency services are outside this rail" ], "watch": { "running": true, "cadence": "monthly", "inputs": [ "US, UK and Ireland PayPal User Agreements", "US Purchase Protection, US Seller Protection, UK and Ireland Buyer Protection pages", "US Policy Updates page", "fixed windows and thresholds the facts cite" ], "inputs_seen": { "us_user_agreement": "last updated 2026-09-14", "us_purchase_protection": "last updated 2026-01-26", "us_seller_protection": "last updated 2026-01-26", "us_policy_updates": "last updated 2026-08-06; notices effective 2026-09-01 and 2026-09-14, both in force", "uk_user_agreement": "last updated 2026-07-15", "uk_buyer_protection": "last updated 2026-09-07", "ie_user_agreement": "last updated 2026-01-22", "ie_buyer_protection": "last updated 2024-05-28", "figures": "180, 30 and 20-day protection windows on US, UK and Ireland pages; 21-day and 180-day holds and 1.5 percent over 100 sales transactions dispute ratio in the US agreement (2026-09-19)" }, "last_run": "2026-09-19", "result": "no change" } }, { "rail": "paypal-dispute", "name": "PayPal Dispute Reasons", "governing_authority": "PayPal (regional entities; US: PayPal, Inc.)", "record_label": "Dispute Reasons", "brief": "docs/rails/paypal.md", "snapshot": "2026-09-19", "known_gaps": [ "the roughly 120 to 146 adjudication reasons PayPal publishes are outcomes of a decided case, not reasons a merchant acts on, and are not held", "the sub-reasons PayPal attaches to a not-as-described dispute (damaged, different, missing parts, incomplete, other) have no records of their own", "the card network condition that an EXTERNAL dispute carries in external_reason_code is not linked yet; the card network rails are still being briefed", "PayPal gives PROBLEM_WITH_REMITTANCE a one-line meaning only and its developer guide omits it, so what triggers it is inferred", "only the US, UK and Ireland agreements were read; windows and rights for buyers in other regions are not covered" ], "watch": { "running": true, "cadence": "monthly", "inputs": [ "paypal/paypal-rest-api-specifications repository, customer_disputes_v1.json", "developer.paypal.com Disputes v1 served schema", "developer guide page on dispute reasons and evidence" ], "inputs_seen": { "repository": "last pushed 2026-04-07; licence Apache-2.0", "repository_spec": "Disputes 1.11; dispute_reason holds the same ten values; adjudication_reason 118 values", "served_schema": "Disputes 1.12; dispute_reason holds the same ten values; adjudication_reason 146 values", "reasons_guide": "nine of the ten reasons have a section; PROBLEM_WITH_REMITTANCE still absent (2026-09-19)" }, "last_run": "2026-09-19", "result": "no change" } }, { "rail": "ph-instapay", "name": "Philippines InstaPay", "governing_authority": "Bangko Sentral ng Pilipinas", "record_label": "Rail Facts", "brief": "docs/rails/ph-instapay.md", "snapshot": "2026-09-18", "watch": { "running": true, "cadence": "monthly", "last_run": "2026-09-18", "result": "change: CL-2026-029 merged BancNet and PCHC into Payments Network of the Philippines, Inc. from 2026-06-01; operator lines logged as open checks", "inputs_seen": [ { "name": "BSP issuances RSS feed", "url": "https://www.bsp.gov.ph/_layouts/15/listfeed.aspx?List=68408d09-548e-40f5-b2fd-62d36e30fd3f&View=5580f386-ff60-40ff-8531-2b5259079a97", "class": "authoritative_primary", "seen": "30 items, 2026-07-02 to 2026-09-16; NRPS-relevant: CL-2026-029 (2026-07-02)" }, { "name": "NRPS regulatory framework page", "url": "https://www.bsp.gov.ph/Pages/PAYMENTS%20AND%20SETTLEMENTS/National%20Retail%20Payment%20System/The-Regulatory-Framework.aspx", "class": "public_primary", "seen": "modified 2024-10-30; newest listed issuance M-2024-015" }, { "name": "BSP Philippine Rulebook on Payments and Settlements (ISO 20022)", "url": "https://www.bsp.gov.ph/PaymentAndSettlement/ISO20022-Rulebook.pdf", "class": "authoritative_primary", "seen": "v1.6, 2026-05-29; 210 pages" }, { "name": "InstaPay ACH Participants", "url": "https://www.bsp.gov.ph/PaymentAndSettlement/Instapay%20Participants.pdf", "class": "public_primary", "seen": "as of 2026-08-31; 96 (88 send and receive, 8 receive only)" }, { "name": "PPMI InstaPay page", "url": "https://www.philpayments.org.ph/instapay", "class": "public_primary", "seen": "PHP 50,000 per transaction, 24x7; footer 2025" }, { "name": "PPMI news and updates", "url": "https://www.philpayments.org.ph/news-and-updates", "class": "public_primary", "seen": "newest item 2025-06-16" }, { "name": "BSP Circular No. 1238 and Memorandum M-2026-025", "url": "https://www.bsp.gov.ph/Regulations/Issuances/2026/1238.pdf", "class": "authoritative_primary", "seen": "signed 2026-06-17; effectivity date not established; already reflected in refund" } ] }, "known_gaps": [ "InstaPay reject and return reason codes: the ACH operating guidelines and PSMB rulebooks that hold them are kept by PPMI and not published, so no code list exists for this rail", "the InstaPay ACH operating guidelines are not public, so timeout values, settlement cycle times in the Peso RTGS, the rules for fee return and the entity-at-fault allocation are named here without their contents", "BSP Circular No. 1196 (2024) on settlement, Circular Letter CL-2020-036 on PPMI accreditation and the National Payment Systems Act (RA 11127) are scanned images with no text layer and were not read", "RA 12010 (AFASA) and RA 11765 were not read directly; liability and consumer-law rest on the BSP circulars that implement them", "InstaPay Cash-in, InstaPay QR and the P2B bills payment use case are named but not described use case by use case" ] }, { "rail": "ph-pesonet", "name": "Philippines PESONet", "governing_authority": "Bangko Sentral ng Pilipinas", "record_label": "Rail Facts", "brief": "docs/rails/ph-instapay.md", "snapshot": "2026-09-18", "watch": { "running": true, "cadence": "monthly", "last_run": "2026-09-18", "result": "change: CL-2026-029 merged PCHC into BancNet, renamed Payments Network of the Philippines, Inc., from 2026-06-01; operator lines logged as open checks", "inputs_seen": [ { "name": "BSP issuances RSS feed", "url": "https://www.bsp.gov.ph/_layouts/15/listfeed.aspx?List=68408d09-548e-40f5-b2fd-62d36e30fd3f&View=5580f386-ff60-40ff-8531-2b5259079a97", "class": "authoritative_primary", "seen": "30 items, 2026-07-02 to 2026-09-16; NRPS-relevant: CL-2026-029 (2026-07-02)" }, { "name": "NRPS regulatory framework page", "url": "https://www.bsp.gov.ph/Pages/PAYMENTS%20AND%20SETTLEMENTS/National%20Retail%20Payment%20System/The-Regulatory-Framework.aspx", "class": "public_primary", "seen": "modified 2024-10-30; newest listed issuance M-2024-015" }, { "name": "BSP Philippine Rulebook on Payments and Settlements (ISO 20022)", "url": "https://www.bsp.gov.ph/PaymentAndSettlement/ISO20022-Rulebook.pdf", "class": "authoritative_primary", "seen": "v1.6, 2026-05-29; 210 pages" }, { "name": "PESONet ACH Participants", "url": "https://www.bsp.gov.ph/PaymentAndSettlement/PESONet%20Participants.pdf", "class": "public_primary", "seen": "as of 2026-08-31; 126" }, { "name": "PPMI PESONet page", "url": "https://www.philpayments.org.ph/pesonet", "class": "public_primary", "seen": "three cycles; cut-offs 10:00, 13:00, 16:00, credit by 13:00, 16:00, 19:00; no scheme limit; footer 2025" }, { "name": "PPMI news and updates", "url": "https://www.philpayments.org.ph/news-and-updates", "class": "public_primary", "seen": "newest item 2025-06-16" }, { "name": "BSP Circular No. 1238 and Memorandum M-2026-025", "url": "https://www.bsp.gov.ph/Regulations/Issuances/2026/1238.pdf", "class": "authoritative_primary", "seen": "signed 2026-06-17; effectivity date not established; already reflected in refund" } ] }, "known_gaps": [ "PESONet reject and return reason codes: the ACH operating guidelines and PSMB rulebooks that hold them are kept by PPMI and not published, so no code list exists for this rail", "the PESONet ACH operating guidelines are not public, so the grace period, penalty scale, fee return rules and entity-at-fault allocation are named here without their contents", "BSP Circular No. 1196 (2024) on settlement is a scanned image with no text layer; what it changed in the batch settlement rules is not stated here", "RA 12010 (AFASA) and RA 11765 were not read directly; liability and consumer-law rest on the BSP circulars that implement them", "Direct Debit PH, launched 2026-07-29 under PPMI, is a separate stream and is not described here" ] }, { "rail": "pix", "name": "Pix", "governing_authority": "Banco Central do Brasil", "record_label": "Rail Facts", "brief": "docs/rails/pix.md", "snapshot": "2026-09-17", "known_gaps": [ "no fact describes Pix Automatico or Pix Cobranca end to end; since 2026-09-22 the authorisation, its journeys, timetable, retries, cancellation and refusal code sets, and the charge and QR code rules, are Core records (mandate.pix-automatico-authorisation and the rule.automatico, rule.agendado and rule.cobranca Rules) that no rail fact lists yet, so they reach agents through core.json and the MCP server but not this page", "the Requisitos Minimos para a Experiencia do Usuario manual, the Manual de Resolucao de Disputas and the Manual de Penalidades were not read; consumer-law and liability name the routes without describing what happens along them", "no Brazilian consumer statute was read, so what a defrauded user can recover from their own bank is stated as outside the rulebook and not answered", "the DICT tracing and prioritization algorithm is not published, so decision-points cannot say why a given account is frozen", "catalog 5.13.1 enters SPI production 2026-10-25 and changes the pacs.002 reason list and the Pix Automatico code families; the messages fact describes 5.12.1 and will need a dated successor", "reason code records for this rail live in corpus/pix-reject and corpus/pix-return and are not drafted yet" ], "watch": { "running": true, "cadence": "monthly", "last_run": "2026-09-18", "result": "no change", "inputs_seen": [ { "name": "Regulamento Pix, Resolucao BCB n. 1/2020, consolidated", "url": "https://www.bcb.gov.br/api/conteudo/app/normativos/exibenormativo?p1=Resolu%C3%A7%C3%A3o%20BCB&p2=1", "class": "authoritative_primary", "seen": "version 41; newest amendment listed Resolucao BCB n. 559/2026; newest linked IN BCB n. 724/2026" }, { "name": "SPI message catalog and Catalogo de Servicos do SFN Vol. VI", "url": "https://www.bcb.gov.br/api/paginasite/sitebcb/estabilidadefinanceira/comunicacaodados", "class": "public_primary", "seen": "Vol. VI 5.13; spi.5.12.1.zip (2026-03-27, SPI production 2026-06-28) and spi.5.13.1.zip (2026-07-24, last modified 2026-07-23, SPI production 2026-10-25, Comunicado 45.630); no 5.14 listed" }, { "name": "Pix normas page", "url": "https://www.bcb.gov.br/api/paginasite/sitebcb/estabilidadefinanceira/pix-normas", "class": "public_primary", "seen": "newest IN listed IN BCB n. 748 de 18/6/2026 (capital verification); same manuals as before" }, { "name": "Manual de Tempos do Pix", "url": "https://www.bcb.gov.br/content/estabilidadefinanceira/pix/Regulamento_Pix/IX_ManualdeTemposdoPix.pdf", "class": "authoritative_primary", "seen": "version 7.0, PDF created 2026-02-04" }, { "name": "Manual Operacional do DICT", "url": "https://www.bcb.gov.br/content/estabilidadefinanceira/pix/Regulamento_Pix/X_ManualOperacionaldoDICT.pdf", "class": "authoritative_primary", "seen": "main URL still version 8.4 (PDF created 2026-07-29) pointing to 8.5; versoes_futuras 8.5 last modified 2026-07-29; no 8.6 at the predictable URL; folder has no listing" }, { "name": "Instrucao Normativa BCB n. 746/2026", "url": "https://www.bcb.gov.br/api/conteudo/app/normativos/exibenormativo?p1=Instru%C3%A7%C3%A3o%20Normativa%20BCB&p2=746", "class": "authoritative_primary", "seen": "version 1, in force 2026-10-01; text read" }, { "name": "Requisitos Minimos para a Experiencia do Usuario", "url": "https://www.bcb.gov.br/content/estabilidadefinanceira/pix/Regulamento_Pix/IV_RequisitosMinimosparaExperienciadoUsuario.pdf", "class": "authoritative_primary", "seen": "version 7.3 of December 2025, 164 pages, read 2026-09-21 with python3 and pypdf; its cover advertises version 7.4 in force from 2027-03-01, so the main URL is due a re-read on that date" }, { "name": "Manual de Padroes para Iniciacao do Pix", "url": "https://www.bcb.gov.br/content/estabilidadefinanceira/pix/Regulamento_Pix/II_ManualdePadroesparaIniciacaodoPix.pdf", "class": "authoritative_primary", "seen": "version 2.10.0, 123 pages, read 2026-09-21; carries the QR code standards and the charge fields" }, { "name": "Instrucao Normativa BCB n. 513/2024", "url": "https://www.bcb.gov.br/api/conteudo/app/normativos/exibenormativo?p1=Instru%C3%A7%C3%A3o%20Normativa%20BCB&p2=513", "class": "authoritative_primary", "seen": "version 5.0, 17 articles including art. 15-A, not revoked; the operational procedures for Pix Automatico, Pix Agendado and Pix Cobranca" } ] } }, { "rail": "pix-reject", "name": "Pix Payment Rejects", "governing_authority": "Banco Central do Brasil", "snapshot": "2026-09-17", "record_label": "Reject Reasons", "brief": "docs/rails/pix.md", "watch": { "running": true, "cadence": "monthly", "inputs_seen": { "spi_catalog": "spi.5.12.1.zip in production since 2026-06-28; spi.5.13.1.zip (2026-07-24) enters production 2026-10-25; no later catalog listed", "pending": "DS02 and DU03 drafted with effective_since 2026-10-25; RR06 narrows on 2026-10-25, supersede with a dated id on or after that date" }, "last_run": "2026-09-18", "result": "no change" } }, { "rail": "pix-return", "name": "Pix Returns (Devolucao)", "governing_authority": "Banco Central do Brasil", "snapshot": "2026-09-17", "record_label": "Return Reasons", "brief": "docs/rails/pix.md", "watch": { "running": true, "cadence": "monthly", "inputs_seen": { "spi_catalog": "pacs.004 return reasons MD06, SL02, BE08, FR01 in spi.5.12.1.zip and spi.5.13.1.zip; no later catalog listed", "dict_manual": "Manual Operacional do DICT 8.5 (versoes_futuras, last modified 2026-07-29); main URL still 8.4" }, "last_run": "2026-09-18", "result": "no change" } }, { "rail": "rtp", "name": "RTP", "governing_authority": "The Clearing House", "record_label": "Rail Facts", "brief": "docs/rails/rtp.md", "snapshot": "2026-09-17", "known_gaps": [ "this directory holds the RTP profile only; RTP reason codes sit in corpus/rtp-return-request and corpus/rtp-reject", "TCH's own permitted code lists and the pacs.002 and camt.029 status sets: they sit in the RTP Message Specifications, gated by the RTP Documentation Agreement, which Orca has not accepted (docs/rails/rtp.md, Blocked); the reject codes in corpus/rtp-reject come from public bank and processor pages instead", "ISO identifiers for the Request for Payment, Request for Information, Remittance Advice and Payment Acknowledgement; only pacs.008, pacs.002, camt.056 and camt.029 are confirmed by a public TCH document", "the payment response time-out that triggers a system cancellation: set in the RTP Technical Specifications and not published", "prefunded requirement amounts, per-participant sending limits and TCH origination control values: set per participant and not published", "participant eligibility criteria and the general limitation of TCH liability: both sit in the RTP Participation Rules, which have not been read", "Regulation E was read through the CFPB's presentation rather than section by section; eCFR refused a plain fetch, so the consumer-law facet caps at medium", "Operating Rules editions effective 2026-09-30 and 2026-10-04, which add indirect domestic send and on line originator arrangements, have not been read" ] }, { "rail": "rtp-reject", "name": "RTP Payment Rejects", "governing_authority": "The Clearing House", "record_label": "Reject Reasons", "brief": "docs/rails/rtp.md", "snapshot": "2026-09-19", "known_gaps": [ "the reject code list here comes from public bank and processor pages; TCH's own list, in the RTP Technical Specifications, was not consulted because Orca has not accepted the terms it carries", "9901, 9909, 9910, 9954, FF02, SL03, FRTR, UPAY, BLKD, INSF, AC10, BE13, FF03, T104 and the codes seen only on pages that mix RTP with FedNow: the public sources either disagree on them or only one family lists them as RTP reject codes", "which side sends most ISO codes, the receiving participant or the RTP System: no public source read says, so both are linked", "the receiving participant response time-out figure: set in the RTP Technical Specifications and not published", "the pacs.002 status codes (ACTC, RJCT, ACWP, RCVD) and the reject reasons of a request for payment response (pain.014)" ] }, { "rail": "rtp-return-request", "name": "RTP Return Request Reasons", "governing_authority": "The Clearing House", "record_label": "Return Request Reasons", "brief": "docs/rails/rtp.md", "snapshot": "2026-09-17", "watch": { "running": true, "cadence": "monthly", "last_run": "2026-09-18", "result": "no change", "inputs_seen": [ { "name": "RTP Operating Rules", "url": "https://www.theclearinghouse.org/payment-systems/rtp/document-library", "class": "authoritative_primary", "seen": "editions effective 2026-06-01 (current), 2026-09-30, 2026-10-04; Rule VII.D unchanged across all three" }, { "name": "RTP Participation Rules", "url": "https://www.theclearinghouse.org/payment-systems/rtp/document-library", "class": "authoritative_primary", "seen": "editions effective 2026-06-01 (current), 2026-09-30" }, { "name": "Summaries of rule changes", "url": "https://www.theclearinghouse.org/payment-systems/rtp/document-library", "class": "public_primary", "seen": "effective 2026-09-30; effective 2026-10-04 (dated 2026-08-18)" }, { "name": "Compendium of rule change summaries", "url": "https://www.theclearinghouse.org/-/media/New/TCH/Documents/Payment-Systems/RTP/Compendium-of-RTP-Rule-Change-Summaries---Nov-2019-to-Present.pdf", "class": "public_primary", "seen": "Nov 2019 to present; 406,447 bytes on 2026-09-17 and 2026-09-18; not reread" }, { "name": "Rules interpretations", "url": "https://www.theclearinghouse.org/payment-systems/rtp/document-library", "class": "authoritative_primary", "seen": "7 listed; newest Fraud Reporting and Acting on Alerts, dated 2026-09-14" }, { "name": "Compliance bulletins", "url": "https://www.theclearinghouse.org/payment-systems/rtp/document-library", "class": "public_primary", "seen": "1-2024, 2-2024, 1-2026 (2026-02-23), 2-2026" }, { "name": "Request for Return of Funds Guidelines", "url": "https://www.theclearinghouse.org/-/media/New/TCH/Documents/Payment-Systems/RTP_Request_for_Returns_v02-19-2021.pdf", "class": "public_primary", "seen": "dated 2021-01-21; still online, 771,942 bytes on 2026-09-17 and 2026-09-18; now listed on the document library page" } ] } }, { "rail": "sa-sarie", "name": "Saudi Arabia sarie (instant payments)", "governing_authority": "Saudi Central Bank (SAMA)", "record_label": "Rail Facts", "brief": "docs/rails/sa-sarie.md", "snapshot": "2026-09-18", "known_gaps": [ "this directory holds rail facts drawn from SAMA's public rulebook portal and from participant banks' own published pages; the sarie operating rules, technical documents and service level agreements that Saudi Payments shared with member banks are not public and were not consulted", "no reason code records exist for this rail; no sarie return or rejection code list is public, and the code appendix on SAMA's portal belongs to the AFAQ cross-currency service, not sarie", "whether SAMA has designated sarie a systemically important payment system was not established, so the statutory finality provisions are stated conditionally", "how and when participants settle sarie payments with each other is not described in any public text read", "SAMA's own sarie product page and the Saudi Payments website could not be read with a plain client, so no fact rests on them", "fees have no facet of their own; SAMA's customer fee caps for sarie transfers are recorded in the limits fact" ], "watch": { "running": true, "cadence": "monthly", "last_run": "2026-09-18", "result": "no change", "inputs_seen": [ { "name": "SAMA Rulebook, SAMA Circulars list (all sectors, including Payment Systems and Payment Services Providers)", "url": "https://rulebook.sama.gov.sa/en/sama-circulars", "class": "public_primary", "seen": "newest listed 482021280 (2026-08-27, 14/03/1448 H); no circular after 42047169 names sarie or the Instant Payments System; newest hours circular 472020433 (2025-09-17) is for the RTGS" }, { "name": "Instant Payments Launch (SARIE), circular 42047169", "url": "https://rulebook.sama.gov.sa/en/instant-payments-launch-sarie", "class": "public_primary", "seen": "2021-02-17 (6/7/1442 H), status In-Force, no later version" }, { "name": "Guide to Financial Institutions Services Fees, circular 472038000 (Arabic original)", "url": "https://rulebook.sama.gov.sa/ar/node/10681", "class": "authoritative_primary", "seen": "2025-12-22 (1447-07-02 H), single version, In-Force in the circulars list" }, { "name": "SAMA sarie product page", "url": "https://www.sama.gov.sa/en-US/payment/Pages/SARIE.aspx", "class": "public_primary", "seen": "not reachable: connection reset to a plain compressed GET on 2026-09-18" }, { "name": "Saudi Payments website", "url": "https://www.saudipayments.com", "class": "public_primary", "seen": "not reachable: TLS certificate error on 2026-09-18, not bypassed" }, { "name": "Participant bank sarie pages (Bank Albilad, SAB, The Saudi Investment Bank, Riyad Bank, Banque Saudi Fransi leaflet)", "url": "https://www.riyadbank.com", "class": "secondary", "seen": "read 2026-09-18 by the drafting of the limits fact; SAR 20,000 and SAR 2,500 ceilings; not re-read by the first watch run the same day" } ] } }, { "rail": "sepa-sct", "name": "SEPA Credit Transfer", "governing_authority": "European Payments Council", "record_label": "Reason Codes", "brief": "docs/rails/sepa.md", "snapshot": "2026-09-17", "known_gaps": [ "the ISO message identifiers for this scheme sit in EPC115-06 and EPC132-08, the Inter-PSP and Customer-to-PSP Implementation Guidelines, which have not been read; the messages fact asserts none of them", "which ISO 20022 message versions the 2025 Implementation Guidelines pin is not established", "EPC409-09, the list of SEPA scheme countries and territories, has not been read, so no country list and no count is asserted", "the SCT list of Participants has not been read, so no participant count is asserted", "the T2 closing days are named by the rulebook but not listed; no Eurosystem calendar has been read", "CSM behaviour is outside the rulebook and the detailed operational rules of STEP2 and the national CSMs are participant-only, so settlement timing, interoperability and whether the final leg is in central bank money are unanswered", "Directive 98/26/EC was not read, so settlement finality as a matter of insolvency law is unconfirmed", "national transposition of Directive (EU) 2015/2366 was not checked, and consumer positions can differ by Member State", "the date each Return, Recall and Request for Recall provision first took effect is unknown; only the 2025 v1.1 edition was read", "the 2027 rulebook is due for publication in November 2026 and would take effect in November 2027; the change requests in EPC008-26 are proposals only" ], "watch": { "running": true, "cadence": "monthly", "inputs": [ "EPC rulebook", "EPC reason code guidance", "EPC change request consultation", "EUR-Lex Regulations 260/2012 and 2024/886" ], "inputs_seen": { "rulebook": "EPC125-05 2025 v1.1 (effective 2025-10-05)", "reason_code_guidance": "EPC135-18 v6.0 (2024-11-28)", "change_request_consultation": "EPC008-26 v1.0 (2026-03-13)", "eur_lex": "not read 2026-09-18 (automated access challenged)" }, "last_run": "2026-09-18", "result": "no change" } }, { "rail": "sepa-sct-inst", "name": "SEPA Instant Credit Transfer", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "known_gaps": [ "the SCT Inst Customer-to-PSP Implementation Guidelines have not been read, so no ISO message is asserted for the customer-side datasets DS-01, DS-04 and DS-10; the inter-PSP guideline, read 2026-09-24, covers the other seven", "the payee check scheme's own internals, such as the EPC directory of its members and its API security, are out of scope since 2026-09-24, so no record describes them; the records hold only what gates an SCT Inst payment", "EPC409-09, the list of SEPA scheme countries and territories, has not been read, so no country list and no count is asserted", "the SCT Inst list of Participants has not been read, so neither a participant count nor the share that is receive-only is asserted", "the prefunding and settlement guarantee amounts behind the AM23 reject are set per CSM and per participant and are not published by the EPC", "the T2 closing days are named by the rulebook but not listed; no Eurosystem calendar has been read", "CSM behaviour is outside the rulebook and the detailed operational rules of RT1, TIPS and the national CSMs are participant-only, so settlement timing, interoperability and whether the final leg is in central bank money are unanswered", "Directive 98/26/EC was not read, so settlement finality as a matter of insolvency law is unconfirmed; the 2024 amendment that brought payment and e-money institutions into its definition of an institution was read in Regulation (EU) 2024/886, Article 4", "the scheme maximum amount carried by the 2023 rulebook was not read, so the figure the 2025 edition removed is not asserted", "national transposition of Directive (EU) 2015/2366 was not checked, and consumer positions can differ by Member State", "the 2027 rulebook is due for publication in November 2026 and would take effect in November 2027; the change requests in EPC009-26 are proposals only" ], "record_label": "Reason Codes", "brief": "docs/rails/sepa.md", "watch": { "running": true, "cadence": "monthly", "inputs": [ "EPC rulebook", "EPC reason code guidance", "EPC change request consultation", "EUR-Lex Regulations 260/2012 and 2024/886" ], "inputs_seen": { "rulebook": "EPC004-16 2025 v1.1 (effective 2025-10-05)", "reason_code_guidance": "EPC059-18 v7.0 (2025-10-05)", "change_request_consultation": "EPC009-26 v1.0 (2026-03-13)", "eur_lex": "not read 2026-09-18 (automated access challenged)" }, "last_run": "2026-09-18", "result": "no change" } }, { "rail": "sepa-sdd-b2b", "name": "SEPA Direct Debit B2B", "governing_authority": "European Payments Council", "record_label": "Reason Codes", "brief": "docs/rails/sepa.md", "snapshot": "2026-09-17", "watch": { "running": true, "cadence": "monthly", "inputs": [ "EPC rulebook", "EPC reason code guidance", "EPC change request consultation", "EUR-Lex Regulations 260/2012 and 2024/886" ], "inputs_seen": { "rulebook": "EPC222-07 2025 v1.1 (effective 2025-10-05)", "reason_code_guidance": "EPC173-14 v8.0 (2024-11-28)", "change_request_consultation": "EPC011-26 v1.0 (2026-03-13)", "eur_lex": "not read 2026-09-18 (automated access challenged)" }, "last_run": "2026-09-18", "result": "no change" }, "known_gaps": [ "the thirteen month exposure of the Debtor PSP, and the bar on recovering it from the Creditor PSP, rest on Annex VI of EPC222-07 and on Annex V of EPC016-06, which the EPC marks as informational; the operative rulebook bodies do not state either", "Annex VI still names the Compliance and Adherence Committee as the escalation route, while the Core rulebook change history records that body becoming the Dispute Resolution Committee in the 2019 v1.1 rulebook", "Article 5(6) of Regulation 260/2012 requires the payer's PSP to check amount and periodicity where there is no refund right, but the PT-04.09 check list names neither; the tension is unresolved", "Annexes I, II, III and VII of EPC222-07 were not read: the Adherence Agreement, the EPC Payment Scheme Management Rules, Risk Management and e-Mandates", "the SWIFT message used for the inquiry procedure (DS-08) is called the suitable SWIFT message and is never identified", "settlement mechanics, cut-off times and settlement finality under Directive 98/26/EC come from each CSM, not from the scheme; no CSM document was read", "no national transposition of Directive (EU) 2015/2366 was read, so which businesses may lawfully opt out of the refund right, and where microenterprises count as consumers, is unknown", "how many PSPs adhere to this scheme, and therefore how reachable it is in practice, was not established" ] }, { "rail": "sepa-sdd-core", "name": "SEPA Direct Debit Core", "governing_authority": "European Payments Council", "record_label": "Reason Codes", "brief": "docs/rails/sepa.md", "snapshot": "2026-09-17", "watch": { "running": true, "cadence": "monthly", "inputs": [ "EPC rulebook", "EPC reason code guidance", "EPC change request consultation", "EUR-Lex Regulations 260/2012 and 2024/886" ], "inputs_seen": { "rulebook": "EPC016-06 2025 v1.1 (effective 2025-10-05)", "reason_code_guidance": "EPC173-14 v8.0 (2024-11-28)", "change_request_consultation": "EPC010-26 v1.0 (2026-03-13)", "eur_lex": "not read 2026-09-18 (automated access challenged)" }, "last_run": "2026-09-18", "result": "no change" }, "known_gaps": [ "Annexes I, II, III and VI of EPC016-06 were not read: the Adherence Agreement, the EPC Payment Scheme Management Rules, Risk Management, and the Instructions for the Refund Procedure for Unauthorised Transactions", "the SWIFT message used for a refund claim (DS-08) and a mandate copy request (DS-10) is called the suitable SWIFT message and is never identified, in the rulebook or the Implementation Guidelines", "the e-mandate documents EPC002-09 and EPC114-08 were not read, so e-mandate messages and process steps are absent from the profile", "settlement mechanics, cut-off times and settlement finality under Directive 98/26/EC come from each CSM, not from the scheme; no CSM document was read", "the TARGET Days Calendar and EPC409-09, the list of SEPA scheme countries, were not read for the profile", "no national transposition of Directive (EU) 2015/2366 was read, so the consumer-law and refund facets state the Directive rather than the law a debtor actually holds", "the status of the PSD3 and PSR successor package as of September 2026 is unknown" ] }, { "rail": "uk-fps", "name": "Faster Payments (UK)", "governing_authority": "Pay.UK Limited", "record_label": "Rail Facts", "brief": "docs/rails/uk-fps.md", "snapshot": "2026-09-20", "known_gaps": [ "the FPS Rules, Rules for the Faster Payments Service, and the FPS Procedures, which hold the rejection codes (Appendix B, section 8.2), the qualifier codes (Appendix B, section 7), the response time-out figures and the Credit Payment Recovery and Bank Error Recovery procedures: Pay.UK's 2025 PFMI self-assessment, key consideration 23.1, says they are available for review by participants' legal departments, and no public copy was found", "the FPS Functional Specification and External Interface Specification, named in the Certainty of Fate annex, rule 10.1, and not published", "the FPS standards library holding the ISO 8583 specifications and the ISO 8583 to ISO 20022 mapping, which Pay.UK says requires registration", "42 of the 50 rejection codes and 6 of the 14 return reasons a participant's developer documentation lists: only one public source family carries them, or the two families that carry them disagree, so they are held rather than drafted. The held codes are listed in docs/rails/uk-fps.md", "the qualifier codes a Qualified Acceptance carries: Pay.UK publishes the five funds availability timescales they signal but no code values", "the four character Confirmation of Payee reason codes, and the reason codes a sending provider records for stopping the five business day reimbursement clock, which live in the Reimbursement Claims Management System", "the FPS Reimbursement Rules Compliance Monitoring Regime, the APP Fraud Reimbursement Best Practice Guide, PSR Specific Requirement 1, Specific Direction 19, the Consumer Standard of Caution Exception notice and the Compliance Data Reporting Standards, each named by a source read here and none of them opened", "Bacs and the Image Clearing System, which Pay.UK also operates, are separate schemes with separate code sets and are not covered here" ] }, { "rail": "uk-fps-reject", "name": "Faster Payments Rejection Codes", "governing_authority": "Pay.UK Limited", "record_label": "Reject Reasons", "brief": "docs/rails/uk-fps.md", "snapshot": "2026-09-20", "known_gaps": [ "Pay.UK does not publish the rejection code list. It is in the FPS Procedures, Appendix B, FPS Codes, section 8.2, which Pay.UK's 2025 PFMI self-assessment, key consideration 23.1, says is available for review by participants' legal departments", "42 of the 50 rejection codes a participant's developer documentation lists are not drafted here. Either only one public source family carries them, or the two families that carry them disagree on what they mean. The held codes are listed by number in docs/rails/uk-fps.md", "the qualifier codes at Appendix B section 7, which a qualified acceptance carries: Pay.UK publishes the five funds availability timescales they signal but no code values", "which side raises each code. The one public statement read is that the central infrastructure passes participant rejection codes through to the sending institution, with 1181 as the stated exception, so the codes drafted here are read as the receiving institution's [Inference]", "the response time a receiving institution has, which Pay.UK says is defined in the FPS Procedures and Technical Specifications and describes publicly only as a few seconds" ] }, { "rail": "uk-fps-return", "name": "Faster Payments Return Reasons", "governing_authority": "Pay.UK Limited", "record_label": "Return Reasons", "brief": "docs/rails/uk-fps.md", "snapshot": "2026-09-20", "known_gaps": [ "Pay.UK does not publish the return reason list. Faster Payments returns are governed by the FPS Rules and the FPS Procedures, which Pay.UK's 2025 PFMI self-assessment, key consideration 23.1, says are available for review by participants' legal departments", "6 of the 14 return reasons a participant's developer documentation lists are not drafted here. Either only one public source family carries them, or the two families that carry them disagree on what they mean. The held reasons are listed by number in docs/rails/uk-fps.md", "which of the one to three working days applies to a given return: Pay.UK states the range publicly and says it depends on the answer the receiving participant gave to the original payment, and the mapping is in the FPS Procedures", "whether any of these reasons may be raised by a party other than the receiving institution. No public source read says, and the code that covers a return at the original sender's request plainly starts elsewhere" ] }, { "rail": "us-ach", "name": "US ACH", "governing_authority": "Nacha", "record_label": "Return Codes", "brief": "docs/rails/us-ach.md", "snapshot": "2026-09-16", "rates": { "unauthorized": { "level": "0.5%", "kind": "rules violation", "codes": [ "R05", "R07", "R10", "R11", "R29", "R51" ] }, "administrative": { "level": "3%", "kind": "inquiry threshold", "codes": [ "R02", "R03", "R04" ] }, "overall": { "level": "15%", "kind": "inquiry threshold", "codes": "all debit returns" } }, "watch": { "running": false, "inputs": [ "Nacha rule change notices", "Nacha supplements", "Nacha annual rulebook edition", "FedACH operating circular" ], "cadence": null, "last_run": "2026-09-18", "result": "no change", "inputs_seen": { "nacha_upcoming_rule_changes": "2026-09-18: latest listed change R90, effective 2028-03-17", "nacha_rulebook_edition": "2026 Nacha Operating Rules", "fedach_operating_circular_4": "edition effective 2026-01-05", "ecfr_reg_e_part_1005": "latest amendment 2025-10-01 (section 1005.10(e)(1) and Supplement I, 89 FR 106836)" } }, "known_gaps": [] }, { "rail": "visa", "name": "Visa", "governing_authority": "Visa (Visa Core Rules and Visa Product and Service Rules)", "record_label": "Rail Facts", "brief": "docs/rails/visa.md", "snapshot": "2026-09-19", "known_gaps": [ "this directory holds rail facts drawn from Visa's public rulebook, the Visa Core Rules and Visa Product and Service Rules; Visa states that the public edition leaves out proprietary, competitive and network-security details, and some values appear only as a placeholder", "the Visa Europe Operating Regulations - Processing, which govern much Europe processing, were not found or read", "the Visa Supplemental Requirements (VisaNet manuals, BASE II and V.I.P. System specifications, the Visa Acquirer Monitoring Program Guide, the compelling evidence guide) were not consulted, so message formats, settlement timing and monitoring thresholds are not stated", "consumer law that applies to card payments (for example US Regulations E and Z, the EU Payment Services Directive, national law) was not read for these facts", "only the sections cited in each record were read; a rule elsewhere in the 923-page edition may qualify a statement" ], "watch": { "running": true, "cadence": "monthly", "last_run": "2026-09-19", "result": "no change", "inputs_seen": [ { "name": "Visa Core Rules and Visa Product and Service Rules", "url": "https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf", "class": "authoritative_primary", "seen": "edition 18 April 2026; PDF created 2026-04-21, modified 2026-04-22; 923 pages; 7,591,762 bytes. Covers corpus/visa, corpus/visa-decline and corpus/visa-dispute" } ] } }, { "rail": "visa-decline", "name": "Visa Authorization Declines", "governing_authority": "Visa (Visa Core Rules and Visa Product and Service Rules)", "record_label": "Decline Response Codes", "brief": "docs/rails/visa.md", "snapshot": "2026-09-19", "known_gaps": [ "Visa's decline table gives each code a short label, a category and a reattempt limit, and no definition; the triggers in these records are mostly Orca's reading", "the message field that carries the code and the full list of response values sit in VisaNet manuals, which are Visa Supplemental Requirements and were not consulted", "the public rules do not say what the 20-attempt reattempt count is measured against", "codes that Visa groups only as generic, and approval or non-decline response values, have no record of their own", "decline codes on other card networks have not been compared with these" ] }, { "rail": "visa-dispute", "name": "Visa Disputes", "governing_authority": "Visa", "record_label": "Dispute Conditions", "brief": "docs/rails/visa.md", "snapshot": "2026-09-19", "known_gaps": [ "Europe Members process under the separate Visa Europe Operating Regulations for Processing where those apply, and that document was not found or read, so Europe-processed disputes may follow rules not shown here", "domestic transactions processed outside VisaNet under a Private Agreement may follow other dispute rules", "arbitration and compliance (Visa Core Rules sections 11.11 to 11.13) are named in each record only as the last stage; filing fees, documentation and appeal rules are not described", "Rapid Dispute Resolution, the Chargeback Reduction Service and the Visa Resolve Online questionnaire content are not described", "the Visa Fraud Monitoring Program and the Card Recovery Bulletin are referred to by name; their own rules and thresholds are not described", "the older numbered chargeback reason codes that still circulate in processor documentation are not mapped to these conditions" ] } ], "entries": [ { "uid": "au-npp-reject:AC02", "id": "AC02", "rail": "au-npp-reject", "kind": "reason-code", "name": "Invalid debtor account number", "group": "account", "summary": "The paying customer's own account number is not one the institution can use: it is invalid, it was left out, or it is not an account that can be reached on the platform. The authority gives this code the ISO name for an invalid debtor account number.", "triggers": [ "The account number in the instruction was mistyped, malformed or left out", "The account given exists at the institution but is not reachable on the platform" ], "actions": [ "Payer: check the account number and the branch prefix on the instruction and send a corrected one", "Institution: tell the customer which of its accounts can be used for a platform payment" ], "retry": { "allowed": true, "rule": "A corrected instruction can be sent. Nothing left the institution, so there is nothing to reverse." }, "facts": { "return_windows": [ { "action": "payment initiation rejection", "by": "Payer Participant", "deadline": "An institution that accepts customer payment instructions answers them with status reports that acknowledge, reject or confirm settlement, and the authority's guidance says those reports are essential for tracking and reconciling the instructions. It gives no deadline for one. Nothing in the rulebook gives one either, because the scheme does not require the leg at all: the guidance says accepting these instructions and providing these reports is proprietary and at each institution's discretion. So the deadline for a rejection carrying any of the 33 published reason codes is whatever an institution has agreed with its own customer, and no public figure exists." } ], "applies_to": "a payment instruction a corporate, government or third party customer sends its own NPP financial institution, and the status report that answers it. Not the interbank leg." }, "caveat": "Not a mandatory scheme code. The governing authority publishes this list as guidance for the payment instruction a customer sends its own institution, and notes that an institution may offer alternative reason codes, so another Australian institution may use a different value for the same failure or this value for a different one. It is also not the interbank code set: the values a rejected clearing request carries are in the NPP Procedures and are not public. The string is an ISO 20022 externalised code and several values on this list carry Australian or PayTo specific meanings the ISO definition does not give, so never carry a meaning here from another rail's list or from the ISO definition. A participant's published list gives this value a different meaning. Orca records both and resolves neither; the disagreement is in the conflict register under the identifier au-npp-ac02-meaning.", "related": [ "au-npp:messages" ], "basis": { "sources": "Listed as an NPP reason code, with the meaning given here in Orca's own words, by the governing authority's own published guidance: NPP Payment Initiation Messages v4.0, Appendix F, read 2026-09-21. A second source on a different host, Westpac's public BankRec documentation for the New Payments Platform, read the same day, lists the same value and gives it a different meaning, an account that is closing or closed, which the authority's list gives a different code for. Orca does not resolve that disagreement: the two documents describe different legs of the payment, and the disagreement is logged in corpus/conflicts.json under the identifier au-npp-ac02-meaning. The authority's own note under Appendix F says an NPP financial institution may offer alternative reason codes and that further guidance on how the codes are used comes from that institution, so this record describes an indicative value on a leg the scheme does not mandate, and confidence is capped at medium for that reason and not because of the source's class.", "confidence": "medium" }, "currency": { "effective_since": "2019-11-22", "effective_to": null, "effective_note": "Effective since 2019-11-22, the date the guidance's own document control gives for version 1.0; the appendix has changed across versions and whether this value was in version 1.0 is [Unverified]. Drafted 2026-09-21 from the authority's own published list. The list is indicative: the guidance says an institution's acceptance of customer payment instructions and provision of status reports is proprietary and at its discretion, and that an institution may offer alternative reason codes. No record here may be read as saying an institution must use this value or must use it with this meaning.", "source_edition": "NPP Payment Initiation Messages, technical guidance v4.0 dated 20 November 2025, Appendix F, read 2026-09-21. The governing authority publishes this list as guidance for a leg it does not mandate, and notes under the appendix that an NPP financial institution may offer alternative reason codes. The scheme's own interbank code set is in the NPP Procedures, which are available to members and direct affiliates only and were not consulted.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.auspayplus.com.au/wp-content/uploads/2026/03/NPP-payment-initiation-V4.0.pdf", "source_class": "authoritative_primary", "source_title": "NPP Payment Initiation Messages, technical guidance for corporates, government and third parties, v4.0", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Appendix F gives AC02 the ISO name for an invalid debtor account number, described as the debtor account number being invalid, missing or not reachable via NPP, matching the record. Westpac's own list gives the same value the different meaning of an account closing or closed, already logged as a conflict register entry." } ] }, "rail_name": "NPP Payment Initiation Reason Codes (Australia)", "governing_authority": "NPP Australia Limited", "snapshot": "2026-09-20", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for Payment initiation instruction (pain.001). Its own scope line reads: a payment instruction a corporate, government or third party customer sends its own NPP financial institution, and the status report that answers it. Not the interbank leg..", "from": "applies_to" } ] }, { "uid": "au-npp-reject:AC03", "id": "AC03", "rail": "au-npp-reject", "kind": "reason-code", "name": "Invalid creditor account number", "group": "account", "summary": "The payee's account number is not usable: invalid, missing, or not reachable on the platform. The mirror of the debtor version, for the other side of the payment.", "triggers": [ "The payee's account number was mistyped, malformed or left out", "The payee's account cannot be reached on the platform" ], "actions": [ "Payer: confirm the payee's account details with the payee before sending again", "Payer: use a PayID or a name check where the institution offers one" ], "retry": { "allowed": true, "rule": "Send a corrected instruction once the payee's details are confirmed." }, "facts": { "return_windows": [ { "action": "payment initiation rejection", "by": "Payer Participant", "deadline": "An institution that accepts customer payment instructions answers them with status reports that acknowledge, reject or confirm settlement, and the authority's guidance says those reports are essential for tracking and reconciling the instructions. It gives no deadline for one. Nothing in the rulebook gives one either, because the scheme does not require the leg at all: the guidance says accepting these instructions and providing these reports is proprietary and at each institution's discretion. So the deadline for a rejection carrying any of the 33 published reason codes is whatever an institution has agreed with its own customer, and no public figure exists." } ], "applies_to": "a payment instruction a corporate, government or third party customer sends its own NPP financial institution, and the status report that answers it. Not the interbank leg." }, "caveat": "Not a mandatory scheme code. The governing authority publishes this list as guidance for the payment instruction a customer sends its own institution, and notes that an institution may offer alternative reason codes, so another Australian institution may use a different value for the same failure or this value for a different one. It is also not the interbank code set: the values a rejected clearing request carries are in the NPP Procedures and are not public. The string is an ISO 20022 externalised code and several values on this list carry Australian or PayTo specific meanings the ISO definition does not give, so never carry a meaning here from another rail's list or from the ISO definition. A participant's published list gives this value a different meaning. Orca records both and resolves neither; the disagreement is in the conflict register under the identifier au-npp-ac03-meaning.", "related": [ "au-npp:messages" ], "basis": { "sources": "Listed as an NPP reason code, with the meaning given here in Orca's own words, by the governing authority's own published guidance: NPP Payment Initiation Messages v4.0, Appendix F, read 2026-09-21. A second source on a different host, Westpac's public BankRec documentation for the New Payments Platform, read the same day, lists the same value and gives it a different meaning, an account whose status is invalid, which is about the state of an account rather than about the number being wrong. Orca does not resolve that disagreement: the two documents describe different legs of the payment, and the disagreement is logged in corpus/conflicts.json under the identifier au-npp-ac03-meaning. The authority's own note under Appendix F says an NPP financial institution may offer alternative reason codes and that further guidance on how the codes are used comes from that institution, so this record describes an indicative value on a leg the scheme does not mandate, and confidence is capped at medium for that reason and not because of the source's class.", "confidence": "medium" }, "currency": { "effective_since": "2019-11-22", "effective_to": null, "effective_note": "Effective since 2019-11-22, the date the guidance's own document control gives for version 1.0; the appendix has changed across versions and whether this value was in version 1.0 is [Unverified]. Drafted 2026-09-21 from the authority's own published list. The list is indicative: the guidance says an institution's acceptance of customer payment instructions and provision of status reports is proprietary and at its discretion, and that an institution may offer alternative reason codes. No record here may be read as saying an institution must use this value or must use it with this meaning.", "source_edition": "NPP Payment Initiation Messages, technical guidance v4.0 dated 20 November 2025, Appendix F, read 2026-09-21. The governing authority publishes this list as guidance for a leg it does not mandate, and notes under the appendix that an NPP financial institution may offer alternative reason codes. The scheme's own interbank code set is in the NPP Procedures, which are available to members and direct affiliates only and were not consulted.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.auspayplus.com.au/wp-content/uploads/2026/03/NPP-payment-initiation-V4.0.pdf", "source_class": "authoritative_primary", "source_title": "NPP Payment Initiation Messages, technical guidance for corporates, government and third parties, v4.0", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Appendix F gives AC03 the ISO name for an invalid creditor account number, described as the creditor account number being invalid, missing or not reachable via NPP, matching the record. Westpac's own list gives the same value the different meaning of an invalid account status, already logged as a conflict register entry." } ] }, "rail_name": "NPP Payment Initiation Reason Codes (Australia)", "governing_authority": "NPP Australia Limited", "snapshot": "2026-09-20", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for Payment initiation instruction (pain.001). Its own scope line reads: a payment instruction a corporate, government or third party customer sends its own NPP financial institution, and the status report that answers it. Not the interbank leg..", "from": "applies_to" } ] }, { "uid": "au-npp-reject:AC05", "id": "AC05", "rail": "au-npp-reject", "kind": "reason-code", "name": "Closed debtor account number", "group": "account", "summary": "The account the payment was to come from is closed.", "triggers": [ "The paying customer's account was closed before the instruction was processed", "The instruction names an account the customer no longer holds" ], "actions": [ "Payer: nominate an account that is open and send the instruction again", "Institution: check whether a stored instruction still points at a closed account" ], "retry": { "allowed": true, "rule": "Send the instruction again from an open account." }, "facts": { "return_windows": [ { "action": "payment initiation rejection", "by": "Payer Participant", "deadline": "An institution that accepts customer payment instructions answers them with status reports that acknowledge, reject or confirm settlement, and the authority's guidance says those reports are essential for tracking and reconciling the instructions. It gives no deadline for one. Nothing in the rulebook gives one either, because the scheme does not require the leg at all: the guidance says accepting these instructions and providing these reports is proprietary and at each institution's discretion. So the deadline for a rejection carrying any of the 33 published reason codes is whatever an institution has agreed with its own customer, and no public figure exists." } ], "applies_to": "a payment instruction a corporate, government or third party customer sends its own NPP financial institution, and the status report that answers it. Not the interbank leg." }, "caveat": "Not a mandatory scheme code. The governing authority publishes this list as guidance for the payment instruction a customer sends its own institution, and notes that an institution may offer alternative reason codes, so another Australian institution may use a different value for the same failure or this value for a different one. It is also not the interbank code set: the values a rejected clearing request carries are in the NPP Procedures and are not public. The string is an ISO 20022 externalised code and several values on this list carry Australian or PayTo specific meanings the ISO definition does not give, so never carry a meaning here from another rail's list or from the ISO definition.", "related": [ "au-npp:messages" ], "basis": { "sources": "Listed as an NPP reason code, with the meaning given here in Orca's own words, by the governing authority's own published guidance: NPP Payment Initiation Messages v4.0, Appendix F, read 2026-09-21. No second public source read carries this value. The authority's own note under Appendix F says an NPP financial institution may offer alternative reason codes and that further guidance on how the codes are used comes from that institution, so this record describes an indicative value on a leg the scheme does not mandate, and confidence is capped at medium for that reason and not because of the source's class.", "confidence": "medium" }, "currency": { "effective_since": "2019-11-22", "effective_to": null, "effective_note": "Effective since 2019-11-22, the date the guidance's own document control gives for version 1.0; the appendix has changed across versions and whether this value was in version 1.0 is [Unverified]. Drafted 2026-09-21 from the authority's own published list. The list is indicative: the guidance says an institution's acceptance of customer payment instructions and provision of status reports is proprietary and at its discretion, and that an institution may offer alternative reason codes. No record here may be read as saying an institution must use this value or must use it with this meaning.", "source_edition": "NPP Payment Initiation Messages, technical guidance v4.0 dated 20 November 2025, Appendix F, read 2026-09-21. The governing authority publishes this list as guidance for a leg it does not mandate, and notes under the appendix that an NPP financial institution may offer alternative reason codes. The scheme's own interbank code set is in the NPP Procedures, which are available to members and direct affiliates only and were not consulted.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.auspayplus.com.au/wp-content/uploads/2026/03/NPP-payment-initiation-V4.0.pdf", "source_class": "authoritative_primary", "source_title": "NPP Payment Initiation Messages, technical guidance for corporates, government and third parties, v4.0", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Appendix F gives AC05 the ISO name for a closed debtor account number, described as the debtor account number being closed, matching the record." } ] }, "rail_name": "NPP Payment Initiation Reason Codes (Australia)", "governing_authority": "NPP Australia Limited", "snapshot": "2026-09-20", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for Payment initiation instruction (pain.001). Its own scope line reads: a payment instruction a corporate, government or third party customer sends its own NPP financial institution, and the status report that answers it. Not the interbank leg..", "from": "applies_to" } ] }, { "uid": "au-npp-reject:AC06", "id": "AC06", "rail": "au-npp-reject", "kind": "reason-code", "name": "Blocked account", "group": "account", "summary": "The authority gives this value the ISO name for a blocked account and describes it as an invalid debtor or creditor account, so on this leg it covers either side. A block is a state somebody put the account into rather than a fault in the number.", "triggers": [ "A block, hold or freeze is on the paying or the receiving account", "The institution will not let the account be used for this payment" ], "actions": [ "Payer: ask the institution why the account cannot be used; the reason is often something the payer cannot see", "Institution: tell the customer whether the block is its own, a legal one, or the other institution's" ], "retry": { "allowed": false, "rule": "Sending the same instruction again will not lift a block. Find out why the account cannot be used first." }, "facts": { "return_windows": [ { "action": "payment initiation rejection", "by": "Payer Participant", "deadline": "An institution that accepts customer payment instructions answers them with status reports that acknowledge, reject or confirm settlement, and the authority's guidance says those reports are essential for tracking and reconciling the instructions. It gives no deadline for one. Nothing in the rulebook gives one either, because the scheme does not require the leg at all: the guidance says accepting these instructions and providing these reports is proprietary and at each institution's discretion. So the deadline for a rejection carrying any of the 33 published reason codes is whatever an institution has agreed with its own customer, and no public figure exists." } ], "applies_to": "a payment instruction a corporate, government or third party customer sends its own NPP financial institution, and the status report that answers it. Not the interbank leg." }, "caveat": "Not a mandatory scheme code. The governing authority publishes this list as guidance for the payment instruction a customer sends its own institution, and notes that an institution may offer alternative reason codes, so another Australian institution may use a different value for the same failure or this value for a different one. It is also not the interbank code set: the values a rejected clearing request carries are in the NPP Procedures and are not public. The string is an ISO 20022 externalised code and several values on this list carry Australian or PayTo specific meanings the ISO definition does not give, so never carry a meaning here from another rail's list or from the ISO definition. The authority's ISO name for this value and its own description of the error do not line up neatly: the name is the ISO one for a blocked account and the description reads as an invalid account on either side. A participant's published list gives this value a different meaning. Orca records both and resolves neither; the disagreement is in the conflict register under the identifier au-npp-ac06-meaning.", "related": [ "au-npp:messages" ], "basis": { "sources": "Listed as an NPP reason code, with the meaning given here in Orca's own words, by the governing authority's own published guidance: NPP Payment Initiation Messages v4.0, Appendix F, read 2026-09-21. A second source on a different host, Westpac's public BankRec documentation for the New Payments Platform, read the same day, lists the same value and gives it a different meaning, a branch that cannot be found, which is about routing rather than about the account being blocked. Orca does not resolve that disagreement: the two documents describe different legs of the payment, and the disagreement is logged in corpus/conflicts.json under the identifier au-npp-ac06-meaning. The authority's own note under Appendix F says an NPP financial institution may offer alternative reason codes and that further guidance on how the codes are used comes from that institution, so this record describes an indicative value on a leg the scheme does not mandate, and confidence is capped at medium for that reason and not because of the source's class.", "confidence": "medium" }, "currency": { "effective_since": "2019-11-22", "effective_to": null, "effective_note": "Effective since 2019-11-22, the date the guidance's own document control gives for version 1.0; the appendix has changed across versions and whether this value was in version 1.0 is [Unverified]. Drafted 2026-09-21 from the authority's own published list. The list is indicative: the guidance says an institution's acceptance of customer payment instructions and provision of status reports is proprietary and at its discretion, and that an institution may offer alternative reason codes. No record here may be read as saying an institution must use this value or must use it with this meaning.", "source_edition": "NPP Payment Initiation Messages, technical guidance v4.0 dated 20 November 2025, Appendix F, read 2026-09-21. The governing authority publishes this list as guidance for a leg it does not mandate, and notes under the appendix that an NPP financial institution may offer alternative reason codes. The scheme's own interbank code set is in the NPP Procedures, which are available to members and direct affiliates only and were not consulted.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.auspayplus.com.au/wp-content/uploads/2026/03/NPP-payment-initiation-V4.0.pdf", "source_class": "authoritative_primary", "source_title": "NPP Payment Initiation Messages, technical guidance for corporates, government and third parties, v4.0", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Appendix F gives AC06 the ISO name for a blocked account, and its own description of the error reads as an invalid debtor account or invalid creditor account, an internal mismatch between the ISO name and the description that the record's caveat already states. Westpac's own list gives the same value the different meaning of a branch that cannot be found, already logged as a conflict register entry." } ] }, "rail_name": "NPP Payment Initiation Reason Codes (Australia)", "governing_authority": "NPP Australia Limited", "snapshot": "2026-09-20", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for Payment initiation instruction (pain.001). Its own scope line reads: a payment instruction a corporate, government or third party customer sends its own NPP financial institution, and the status report that answers it. Not the interbank leg..", "from": "applies_to" } ] }, { "uid": "au-npp-reject:AC07", "id": "AC07", "rail": "au-npp-reject", "kind": "reason-code", "name": "Closed creditor account number", "group": "account", "summary": "The payee's account is closed.", "triggers": [ "The payee closed the account after giving out its details", "The details are for an account that no longer exists" ], "actions": [ "Payer: ask the payee for current account details before sending again", "Payer: check whether a stored payee record is out of date" ], "retry": { "allowed": true, "rule": "Send a new instruction once the payee gives usable details." }, "facts": { "return_windows": [ { "action": "payment initiation rejection", "by": "Payer Participant", "deadline": "An institution that accepts customer payment instructions answers them with status reports that acknowledge, reject or confirm settlement, and the authority's guidance says those reports are essential for tracking and reconciling the instructions. It gives no deadline for one. Nothing in the rulebook gives one either, because the scheme does not require the leg at all: the guidance says accepting these instructions and providing these reports is proprietary and at each institution's discretion. So the deadline for a rejection carrying any of the 33 published reason codes is whatever an institution has agreed with its own customer, and no public figure exists." } ], "applies_to": "a payment instruction a corporate, government or third party customer sends its own NPP financial institution, and the status report that answers it. Not the interbank leg." }, "caveat": "Not a mandatory scheme code. The governing authority publishes this list as guidance for the payment instruction a customer sends its own institution, and notes that an institution may offer alternative reason codes, so another Australian institution may use a different value for the same failure or this value for a different one. It is also not the interbank code set: the values a rejected clearing request carries are in the NPP Procedures and are not public. The string is an ISO 20022 externalised code and several values on this list carry Australian or PayTo specific meanings the ISO definition does not give, so never carry a meaning here from another rail's list or from the ISO definition. A participant's published list gives this value a different meaning. Orca records both and resolves neither; the disagreement is in the conflict register under the identifier au-npp-ac07-meaning.", "related": [ "au-npp:messages" ], "basis": { "sources": "Listed as an NPP reason code, with the meaning given here in Orca's own words, by the governing authority's own published guidance: NPP Payment Initiation Messages v4.0, Appendix F, read 2026-09-21. A second source on a different host, Westpac's public BankRec documentation for the New Payments Platform, read the same day, lists the same value and gives it a different meaning, an account that cannot be found, which is a different state from an account that existed and was closed. Orca does not resolve that disagreement: the two documents describe different legs of the payment, and the disagreement is logged in corpus/conflicts.json under the identifier au-npp-ac07-meaning. The authority's own note under Appendix F says an NPP financial institution may offer alternative reason codes and that further guidance on how the codes are used comes from that institution, so this record describes an indicative value on a leg the scheme does not mandate, and confidence is capped at medium for that reason and not because of the source's class.", "confidence": "medium" }, "currency": { "effective_since": "2019-11-22", "effective_to": null, "effective_note": "Effective since 2019-11-22, the date the guidance's own document control gives for version 1.0; the appendix has changed across versions and whether this value was in version 1.0 is [Unverified]. Drafted 2026-09-21 from the authority's own published list. The list is indicative: the guidance says an institution's acceptance of customer payment instructions and provision of status reports is proprietary and at its discretion, and that an institution may offer alternative reason codes. No record here may be read as saying an institution must use this value or must use it with this meaning.", "source_edition": "NPP Payment Initiation Messages, technical guidance v4.0 dated 20 November 2025, Appendix F, read 2026-09-21. The governing authority publishes this list as guidance for a leg it does not mandate, and notes under the appendix that an NPP financial institution may offer alternative reason codes. The scheme's own interbank code set is in the NPP Procedures, which are available to members and direct affiliates only and were not consulted.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.auspayplus.com.au/wp-content/uploads/2026/03/NPP-payment-initiation-V4.0.pdf", "source_class": "authoritative_primary", "source_title": "NPP Payment Initiation Messages, technical guidance for corporates, government and third parties, v4.0", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Appendix F gives AC07 the ISO name for a closed creditor account number, described as the creditor account number being closed, matching the record. Westpac's own list gives the same value the different meaning of an account that cannot be found, already logged as a conflict register entry." } ] }, "rail_name": "NPP Payment Initiation Reason Codes (Australia)", "governing_authority": "NPP Australia Limited", "snapshot": "2026-09-20", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for Payment initiation instruction (pain.001). Its own scope line reads: a payment instruction a corporate, government or third party customer sends its own NPP financial institution, and the status report that answers it. Not the interbank leg..", "from": "applies_to" } ] }, { "uid": "au-npp-reject:AC13", "id": "AC13", "rail": "au-npp-reject", "kind": "reason-code", "name": "Invalid debtor account type", "group": "account", "summary": "The account the payment would come from is not reachable on the platform. This is about the kind of account rather than about the number: some account types simply cannot send a platform payment.", "triggers": [ "The paying account is of a type that cannot send a payment on the platform", "The account is held at an institution or on a product that is not reachable" ], "actions": [ "Payer: use an account the institution says is enabled for platform payments", "Institution: tell the customer which products are reachable" ], "retry": { "allowed": true, "rule": "Send the instruction from an account that can be used on the platform." }, "facts": { "return_windows": [ { "action": "payment initiation rejection", "by": "Payer Participant", "deadline": "An institution that accepts customer payment instructions answers them with status reports that acknowledge, reject or confirm settlement, and the authority's guidance says those reports are essential for tracking and reconciling the instructions. It gives no deadline for one. Nothing in the rulebook gives one either, because the scheme does not require the leg at all: the guidance says accepting these instructions and providing these reports is proprietary and at each institution's discretion. So the deadline for a rejection carrying any of the 33 published reason codes is whatever an institution has agreed with its own customer, and no public figure exists." } ], "applies_to": "a payment instruction a corporate, government or third party customer sends its own NPP financial institution, and the status report that answers it. Not the interbank leg." }, "caveat": "Not a mandatory scheme code. The governing authority publishes this list as guidance for the payment instruction a customer sends its own institution, and notes that an institution may offer alternative reason codes, so another Australian institution may use a different value for the same failure or this value for a different one. It is also not the interbank code set: the values a rejected clearing request carries are in the NPP Procedures and are not public. The string is an ISO 20022 externalised code and several values on this list carry Australian or PayTo specific meanings the ISO definition does not give, so never carry a meaning here from another rail's list or from the ISO definition.", "related": [ "au-npp:messages" ], "basis": { "sources": "Listed as an NPP reason code, with the meaning given here in Orca's own words, by the governing authority's own published guidance: NPP Payment Initiation Messages v4.0, Appendix F, read 2026-09-21. No second public source read carries this value. The authority's own note under Appendix F says an NPP financial institution may offer alternative reason codes and that further guidance on how the codes are used comes from that institution, so this record describes an indicative value on a leg the scheme does not mandate, and confidence is capped at medium for that reason and not because of the source's class.", "confidence": "medium" }, "currency": { "effective_since": "2019-11-22", "effective_to": null, "effective_note": "Effective since 2019-11-22, the date the guidance's own document control gives for version 1.0; the appendix has changed across versions and whether this value was in version 1.0 is [Unverified]. Drafted 2026-09-21 from the authority's own published list. The list is indicative: the guidance says an institution's acceptance of customer payment instructions and provision of status reports is proprietary and at its discretion, and that an institution may offer alternative reason codes. No record here may be read as saying an institution must use this value or must use it with this meaning.", "source_edition": "NPP Payment Initiation Messages, technical guidance v4.0 dated 20 November 2025, Appendix F, read 2026-09-21. The governing authority publishes this list as guidance for a leg it does not mandate, and notes under the appendix that an NPP financial institution may offer alternative reason codes. The scheme's own interbank code set is in the NPP Procedures, which are available to members and direct affiliates only and were not consulted.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.auspayplus.com.au/wp-content/uploads/2026/03/NPP-payment-initiation-V4.0.pdf", "source_class": "authoritative_primary", "source_title": "NPP Payment Initiation Messages, technical guidance for corporates, government and third parties, v4.0", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Appendix F gives AC13 the ISO name for an invalid debtor account type, described as the debit account not being reachable via NPP, matching the record." } ] }, "rail_name": "NPP Payment Initiation Reason Codes (Australia)", "governing_authority": "NPP Australia Limited", "snapshot": "2026-09-20", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for Payment initiation instruction (pain.001). Its own scope line reads: a payment instruction a corporate, government or third party customer sends its own NPP financial institution, and the status report that answers it. Not the interbank leg..", "from": "applies_to" } ] }, { "uid": "au-npp-reject:AC14", "id": "AC14", "rail": "au-npp-reject", "kind": "reason-code", "name": "Invalid creditor account type", "group": "account", "summary": "The payee's account cannot be reached on the platform. Many Australian accounts still cannot receive a platform payment, and this is the value that says so.", "triggers": [ "The payee's account is of a type that cannot receive a platform payment", "The payee's institution has not enabled that account for the platform" ], "actions": [ "Payer: ask the payee whether they have an account that can receive a platform payment, or pay by another route", "Payee: ask their own institution whether the account can be enabled" ], "retry": { "allowed": true, "rule": "Sending the same instruction again will fail the same way. Use a different destination or a different route." }, "facts": { "return_windows": [ { "action": "payment initiation rejection", "by": "Payer Participant", "deadline": "An institution that accepts customer payment instructions answers them with status reports that acknowledge, reject or confirm settlement, and the authority's guidance says those reports are essential for tracking and reconciling the instructions. It gives no deadline for one. Nothing in the rulebook gives one either, because the scheme does not require the leg at all: the guidance says accepting these instructions and providing these reports is proprietary and at each institution's discretion. So the deadline for a rejection carrying any of the 33 published reason codes is whatever an institution has agreed with its own customer, and no public figure exists." } ], "applies_to": "a payment instruction a corporate, government or third party customer sends its own NPP financial institution, and the status report that answers it. Not the interbank leg." }, "caveat": "Not a mandatory scheme code. The governing authority publishes this list as guidance for the payment instruction a customer sends its own institution, and notes that an institution may offer alternative reason codes, so another Australian institution may use a different value for the same failure or this value for a different one. It is also not the interbank code set: the values a rejected clearing request carries are in the NPP Procedures and are not public. The string is an ISO 20022 externalised code and several values on this list carry Australian or PayTo specific meanings the ISO definition does not give, so never carry a meaning here from another rail's list or from the ISO definition.", "related": [ "au-npp:messages" ], "basis": { "sources": "Listed as an NPP reason code, with the meaning given here in Orca's own words, by the governing authority's own published guidance: NPP Payment Initiation Messages v4.0, Appendix F, read 2026-09-21. A second source on a different host, Westpac's public BankRec documentation for the New Payments Platform, read the same day, lists the same value and describes it as an account that exists but cannot accept funds on the platform. The authority's own note under Appendix F says an NPP financial institution may offer alternative reason codes and that further guidance on how the codes are used comes from that institution, so this record describes an indicative value on a leg the scheme does not mandate, and confidence is capped at medium for that reason and not because of the source's class.", "confidence": "medium" }, "currency": { "effective_since": "2019-11-22", "effective_to": null, "effective_note": "Effective since 2019-11-22, the date the guidance's own document control gives for version 1.0; the appendix has changed across versions and whether this value was in version 1.0 is [Unverified]. Drafted 2026-09-21 from the authority's own published list. The list is indicative: the guidance says an institution's acceptance of customer payment instructions and provision of status reports is proprietary and at its discretion, and that an institution may offer alternative reason codes. No record here may be read as saying an institution must use this value or must use it with this meaning.", "source_edition": "NPP Payment Initiation Messages, technical guidance v4.0 dated 20 November 2025, Appendix F, read 2026-09-21. The governing authority publishes this list as guidance for a leg it does not mandate, and notes under the appendix that an NPP financial institution may offer alternative reason codes. The scheme's own interbank code set is in the NPP Procedures, which are available to members and direct affiliates only and were not consulted.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.auspayplus.com.au/wp-content/uploads/2026/03/NPP-payment-initiation-V4.0.pdf", "source_class": "authoritative_primary", "source_title": "NPP Payment Initiation Messages, technical guidance for corporates, government and third parties, v4.0", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Appendix F gives AC14 the ISO name for an invalid creditor account type, described as the credit account not being reachable via NPP, matching the record." } ] }, "rail_name": "NPP Payment Initiation Reason Codes (Australia)", "governing_authority": "NPP Australia Limited", "snapshot": "2026-09-20", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for Payment initiation instruction (pain.001). Its own scope line reads: a payment instruction a corporate, government or third party customer sends its own NPP financial institution, and the status report that answers it. Not the interbank leg..", "from": "applies_to" } ] }, { "uid": "au-npp-reject:AC15", "id": "AC15", "rail": "au-npp-reject", "kind": "reason-code", "name": "Account details changed", "group": "account", "summary": "The PayID the payment was addressed from is now attached to a different account. This is one of the values that belongs to the addressing service rather than to the account itself.", "triggers": [ "The debtor PayID in the instruction has been moved to another account since the instruction was built", "A stored instruction still names a PayID whose registration has changed" ], "actions": [ "Payer: check which account the PayID now points at before sending again", "Institution: refresh any stored mapping between a PayID and an account" ], "retry": { "allowed": true, "rule": "Send a new instruction once the current mapping is confirmed." }, "facts": { "return_windows": [ { "action": "payment initiation rejection", "by": "Payer Participant", "deadline": "An institution that accepts customer payment instructions answers them with status reports that acknowledge, reject or confirm settlement, and the authority's guidance says those reports are essential for tracking and reconciling the instructions. It gives no deadline for one. Nothing in the rulebook gives one either, because the scheme does not require the leg at all: the guidance says accepting these instructions and providing these reports is proprietary and at each institution's discretion. So the deadline for a rejection carrying any of the 33 published reason codes is whatever an institution has agreed with its own customer, and no public figure exists." } ], "applies_to": "a payment instruction a corporate, government or third party customer sends its own NPP financial institution, and the status report that answers it. Not the interbank leg." }, "caveat": "Not a mandatory scheme code. The governing authority publishes this list as guidance for the payment instruction a customer sends its own institution, and notes that an institution may offer alternative reason codes, so another Australian institution may use a different value for the same failure or this value for a different one. It is also not the interbank code set: the values a rejected clearing request carries are in the NPP Procedures and are not public. The string is an ISO 20022 externalised code and several values on this list carry Australian or PayTo specific meanings the ISO definition does not give, so never carry a meaning here from another rail's list or from the ISO definition.", "related": [ "au-npp:messages" ], "basis": { "sources": "Listed as an NPP reason code, with the meaning given here in Orca's own words, by the governing authority's own published guidance: NPP Payment Initiation Messages v4.0, Appendix F, read 2026-09-21. No second public source read carries this value. The authority's own note under Appendix F says an NPP financial institution may offer alternative reason codes and that further guidance on how the codes are used comes from that institution, so this record describes an indicative value on a leg the scheme does not mandate, and confidence is capped at medium for that reason and not because of the source's class.", "confidence": "medium" }, "currency": { "effective_since": "2019-11-22", "effective_to": null, "effective_note": "Effective since 2019-11-22, the date the guidance's own document control gives for version 1.0; the appendix has changed across versions and whether this value was in version 1.0 is [Unverified]. Drafted 2026-09-21 from the authority's own published list. The list is indicative: the guidance says an institution's acceptance of customer payment instructions and provision of status reports is proprietary and at its discretion, and that an institution may offer alternative reason codes. No record here may be read as saying an institution must use this value or must use it with this meaning.", "source_edition": "NPP Payment Initiation Messages, technical guidance v4.0 dated 20 November 2025, Appendix F, read 2026-09-21. The governing authority publishes this list as guidance for a leg it does not mandate, and notes under the appendix that an NPP financial institution may offer alternative reason codes. The scheme's own interbank code set is in the NPP Procedures, which are available to members and direct affiliates only and were not consulted.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.auspayplus.com.au/wp-content/uploads/2026/03/NPP-payment-initiation-V4.0.pdf", "source_class": "authoritative_primary", "source_title": "NPP Payment Initiation Messages, technical guidance for corporates, government and third parties, v4.0", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Appendix F gives AC15 the ISO name for account details changed, described as the debtor PayID being linked to a different account, matching the record." } ] }, "rail_name": "NPP Payment Initiation Reason Codes (Australia)", "governing_authority": "NPP Australia Limited", "snapshot": "2026-09-20", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for Payment initiation instruction (pain.001). Its own scope line reads: a payment instruction a corporate, government or third party customer sends its own NPP financial institution, and the status report that answers it. Not the interbank leg..", "from": "applies_to" } ] }, { "uid": "au-npp-reject:AG01", "id": "AG01", "rail": "au-npp-reject", "kind": "reason-code", "name": "Transaction forbidden", "group": "authorization", "summary": "The debit or credit account is not enabled for PayTo. The authority gives this value a PayTo specific meaning that the ISO definition does not carry, which is one reason a value on this list must never be read across from another rail.", "triggers": [ "The paying account is not enabled for PayTo agreements", "The receiving account is not enabled for PayTo" ], "actions": [ "Payer: ask the institution to enable the account for PayTo, or pay another way", "Business: check whether the payer's account can hold a PayTo agreement before relying on one" ], "retry": { "allowed": false, "rule": "Sending the same instruction again will fail until the account is enabled." }, "facts": { "return_windows": [ { "action": "payment initiation rejection", "by": "Payer Participant", "deadline": "An institution that accepts customer payment instructions answers them with status reports that acknowledge, reject or confirm settlement, and the authority's guidance says those reports are essential for tracking and reconciling the instructions. It gives no deadline for one. Nothing in the rulebook gives one either, because the scheme does not require the leg at all: the guidance says accepting these instructions and providing these reports is proprietary and at each institution's discretion. So the deadline for a rejection carrying any of the 33 published reason codes is whatever an institution has agreed with its own customer, and no public figure exists." } ], "applies_to": "a payment instruction a corporate, government or third party customer sends its own NPP financial institution, and the status report that answers it. Not the interbank leg." }, "caveat": "Not a mandatory scheme code. The governing authority publishes this list as guidance for the payment instruction a customer sends its own institution, and notes that an institution may offer alternative reason codes, so another Australian institution may use a different value for the same failure or this value for a different one. It is also not the interbank code set: the values a rejected clearing request carries are in the NPP Procedures and are not public. The string is an ISO 20022 externalised code and several values on this list carry Australian or PayTo specific meanings the ISO definition does not give, so never carry a meaning here from another rail's list or from the ISO definition. A PayTo specific meaning, not the general ISO meaning of a forbidden transaction.", "related": [ "au-npp:messages" ], "basis": { "sources": "Listed as an NPP reason code, with the meaning given here in Orca's own words, by the governing authority's own published guidance: NPP Payment Initiation Messages v4.0, Appendix F, read 2026-09-21. No second public source read carries this value. The authority's own note under Appendix F says an NPP financial institution may offer alternative reason codes and that further guidance on how the codes are used comes from that institution, so this record describes an indicative value on a leg the scheme does not mandate, and confidence is capped at medium for that reason and not because of the source's class.", "confidence": "medium" }, "currency": { "effective_since": "2019-11-22", "effective_to": null, "effective_note": "Effective since 2019-11-22, the date the guidance's own document control gives for version 1.0; the appendix has changed across versions and whether this value was in version 1.0 is [Unverified]. Drafted 2026-09-21 from the authority's own published list. The list is indicative: the guidance says an institution's acceptance of customer payment instructions and provision of status reports is proprietary and at its discretion, and that an institution may offer alternative reason codes. No record here may be read as saying an institution must use this value or must use it with this meaning.", "source_edition": "NPP Payment Initiation Messages, technical guidance v4.0 dated 20 November 2025, Appendix F, read 2026-09-21. The governing authority publishes this list as guidance for a leg it does not mandate, and notes under the appendix that an NPP financial institution may offer alternative reason codes. The scheme's own interbank code set is in the NPP Procedures, which are available to members and direct affiliates only and were not consulted.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.auspayplus.com.au/wp-content/uploads/2026/03/NPP-payment-initiation-V4.0.pdf", "source_class": "authoritative_primary", "source_title": "NPP Payment Initiation Messages, technical guidance for corporates, government and third parties, v4.0", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Appendix F gives AG01 the ISO name for transaction forbidden, described as the debit or credit account not being PayTo enabled, matching the record's PayTo specific reading." } ] }, "rail_name": "NPP Payment Initiation Reason Codes (Australia)", "governing_authority": "NPP Australia Limited", "snapshot": "2026-09-20", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for Payment initiation instruction (pain.001). Its own scope line reads: a payment instruction a corporate, government or third party customer sends its own NPP financial institution, and the status report that answers it. Not the interbank leg..", "from": "applies_to" } ] }, { "uid": "au-npp-reject:AG03", "id": "AG03", "rail": "au-npp-reject", "kind": "reason-code", "name": "Transaction not supported", "group": "network", "summary": "The debit or credit account is not reachable on the platform. Where AC13 and AC14 say the account type is wrong, this value says the transaction is not one the account supports.", "triggers": [ "The account cannot be reached on the platform for this kind of payment", "The institution does not support this service on that account" ], "actions": [ "Payer: use an account or a route the institution supports", "Institution: say which services the account supports" ], "retry": { "allowed": true, "rule": "Try a different account or a different payment route." }, "facts": { "return_windows": [ { "action": "payment initiation rejection", "by": "Payer Participant", "deadline": "An institution that accepts customer payment instructions answers them with status reports that acknowledge, reject or confirm settlement, and the authority's guidance says those reports are essential for tracking and reconciling the instructions. It gives no deadline for one. Nothing in the rulebook gives one either, because the scheme does not require the leg at all: the guidance says accepting these instructions and providing these reports is proprietary and at each institution's discretion. So the deadline for a rejection carrying any of the 33 published reason codes is whatever an institution has agreed with its own customer, and no public figure exists." } ], "applies_to": "a payment instruction a corporate, government or third party customer sends its own NPP financial institution, and the status report that answers it. Not the interbank leg." }, "caveat": "Not a mandatory scheme code. The governing authority publishes this list as guidance for the payment instruction a customer sends its own institution, and notes that an institution may offer alternative reason codes, so another Australian institution may use a different value for the same failure or this value for a different one. It is also not the interbank code set: the values a rejected clearing request carries are in the NPP Procedures and are not public. The string is an ISO 20022 externalised code and several values on this list carry Australian or PayTo specific meanings the ISO definition does not give, so never carry a meaning here from another rail's list or from the ISO definition.", "related": [ "au-npp:messages" ], "basis": { "sources": "Listed as an NPP reason code, with the meaning given here in Orca's own words, by the governing authority's own published guidance: NPP Payment Initiation Messages v4.0, Appendix F, read 2026-09-21. A second source on a different host, Westpac's public BankRec documentation for the New Payments Platform, read the same day, lists the same value and describes it as an account that exists but does not support this business service. The authority's own note under Appendix F says an NPP financial institution may offer alternative reason codes and that further guidance on how the codes are used comes from that institution, so this record describes an indicative value on a leg the scheme does not mandate, and confidence is capped at medium for that reason and not because of the source's class.", "confidence": "medium" }, "currency": { "effective_since": "2019-11-22", "effective_to": null, "effective_note": "Effective since 2019-11-22, the date the guidance's own document control gives for version 1.0; the appendix has changed across versions and whether this value was in version 1.0 is [Unverified]. Drafted 2026-09-21 from the authority's own published list. The list is indicative: the guidance says an institution's acceptance of customer payment instructions and provision of status reports is proprietary and at its discretion, and that an institution may offer alternative reason codes. No record here may be read as saying an institution must use this value or must use it with this meaning.", "source_edition": "NPP Payment Initiation Messages, technical guidance v4.0 dated 20 November 2025, Appendix F, read 2026-09-21. The governing authority publishes this list as guidance for a leg it does not mandate, and notes under the appendix that an NPP financial institution may offer alternative reason codes. The scheme's own interbank code set is in the NPP Procedures, which are available to members and direct affiliates only and were not consulted.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.auspayplus.com.au/wp-content/uploads/2026/03/NPP-payment-initiation-V4.0.pdf", "source_class": "authoritative_primary", "source_title": "NPP Payment Initiation Messages, technical guidance for corporates, government and third parties, v4.0", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Appendix F gives AG03 the ISO name for transaction not supported, described as the debit or credit account not being reachable via NPP, matching the record." } ] }, "rail_name": "NPP Payment Initiation Reason Codes (Australia)", "governing_authority": "NPP Australia Limited", "snapshot": "2026-09-20", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for Payment initiation instruction (pain.001). Its own scope line reads: a payment instruction a corporate, government or third party customer sends its own NPP financial institution, and the status report that answers it. Not the interbank leg..", "from": "applies_to" } ] }, { "uid": "au-npp-reject:AGNT", "id": "AGNT", "rail": "au-npp-reject", "kind": "reason-code", "name": "Incorrect agent", "group": "network", "summary": "The account cannot be reached for a platform payment because of the institution in the path. The authority gives this the ISO name for an incorrect agent.", "triggers": [ "The branch prefix routes to an institution that cannot be reached on the platform", "Reference data about the institution in the path is wrong or out of date" ], "actions": [ "Payer: check the branch prefix and the payee's institution", "Institution: check its own reference data for the institution in the path" ], "retry": { "allowed": true, "rule": "Send a corrected instruction once the routing is right." }, "facts": { "return_windows": [ { "action": "payment initiation rejection", "by": "Payer Participant", "deadline": "An institution that accepts customer payment instructions answers them with status reports that acknowledge, reject or confirm settlement, and the authority's guidance says those reports are essential for tracking and reconciling the instructions. It gives no deadline for one. Nothing in the rulebook gives one either, because the scheme does not require the leg at all: the guidance says accepting these instructions and providing these reports is proprietary and at each institution's discretion. So the deadline for a rejection carrying any of the 33 published reason codes is whatever an institution has agreed with its own customer, and no public figure exists." } ], "applies_to": "a payment instruction a corporate, government or third party customer sends its own NPP financial institution, and the status report that answers it. Not the interbank leg." }, "caveat": "Not a mandatory scheme code. The governing authority publishes this list as guidance for the payment instruction a customer sends its own institution, and notes that an institution may offer alternative reason codes, so another Australian institution may use a different value for the same failure or this value for a different one. It is also not the interbank code set: the values a rejected clearing request carries are in the NPP Procedures and are not public. The string is an ISO 20022 externalised code and several values on this list carry Australian or PayTo specific meanings the ISO definition does not give, so never carry a meaning here from another rail's list or from the ISO definition.", "related": [ "au-npp:messages" ], "basis": { "sources": "Listed as an NPP reason code, with the meaning given here in Orca's own words, by the governing authority's own published guidance: NPP Payment Initiation Messages v4.0, Appendix F, read 2026-09-21. A second source on a different host, Westpac's public BankRec documentation for the New Payments Platform, read the same day, lists the same value and describes it as incorrect reference data or clearing and settlement agent relationships, which is the same subject described from the institution's side. The authority's own note under Appendix F says an NPP financial institution may offer alternative reason codes and that further guidance on how the codes are used comes from that institution, so this record describes an indicative value on a leg the scheme does not mandate, and confidence is capped at medium for that reason and not because of the source's class.", "confidence": "medium" }, "currency": { "effective_since": "2019-11-22", "effective_to": null, "effective_note": "Effective since 2019-11-22, the date the guidance's own document control gives for version 1.0; the appendix has changed across versions and whether this value was in version 1.0 is [Unverified]. Drafted 2026-09-21 from the authority's own published list. The list is indicative: the guidance says an institution's acceptance of customer payment instructions and provision of status reports is proprietary and at its discretion, and that an institution may offer alternative reason codes. No record here may be read as saying an institution must use this value or must use it with this meaning.", "source_edition": "NPP Payment Initiation Messages, technical guidance v4.0 dated 20 November 2025, Appendix F, read 2026-09-21. The governing authority publishes this list as guidance for a leg it does not mandate, and notes under the appendix that an NPP financial institution may offer alternative reason codes. The scheme's own interbank code set is in the NPP Procedures, which are available to members and direct affiliates only and were not consulted.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.auspayplus.com.au/wp-content/uploads/2026/03/NPP-payment-initiation-V4.0.pdf", "source_class": "authoritative_primary", "source_title": "NPP Payment Initiation Messages, technical guidance for corporates, government and third parties, v4.0", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Appendix F gives AGNT the ISO name for incorrect agent, described as the account not being reachable for an NPP payment, matching the record." } ] }, "rail_name": "NPP Payment Initiation Reason Codes (Australia)", "governing_authority": "NPP Australia Limited", "snapshot": "2026-09-20", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for Payment initiation instruction (pain.001). Its own scope line reads: a payment instruction a corporate, government or third party customer sends its own NPP financial institution, and the status report that answers it. Not the interbank leg..", "from": "applies_to" } ] }, { "uid": "au-npp-reject:AM01", "id": "AM01", "rail": "au-npp-reject", "kind": "reason-code", "name": "Zero amount", "group": "administrative", "summary": "The instruction asks for a payment of zero. The scheme itself forbids a zero value payment: a paying institution must not submit one and a receiving institution is obliged to reject one.", "triggers": [ "The amount field was left at zero", "A calculation upstream produced a zero amount" ], "actions": [ "Payer: put a real amount in and send the instruction again" ], "retry": { "allowed": true, "rule": "Send a corrected instruction with an amount above zero." }, "facts": { "return_windows": [ { "action": "payment initiation rejection", "by": "Payer Participant", "deadline": "An institution that accepts customer payment instructions answers them with status reports that acknowledge, reject or confirm settlement, and the authority's guidance says those reports are essential for tracking and reconciling the instructions. It gives no deadline for one. Nothing in the rulebook gives one either, because the scheme does not require the leg at all: the guidance says accepting these instructions and providing these reports is proprietary and at each institution's discretion. So the deadline for a rejection carrying any of the 33 published reason codes is whatever an institution has agreed with its own customer, and no public figure exists." } ], "applies_to": "a payment instruction a corporate, government or third party customer sends its own NPP financial institution, and the status report that answers it. Not the interbank leg." }, "caveat": "Not a mandatory scheme code. The governing authority publishes this list as guidance for the payment instruction a customer sends its own institution, and notes that an institution may offer alternative reason codes, so another Australian institution may use a different value for the same failure or this value for a different one. It is also not the interbank code set: the values a rejected clearing request carries are in the NPP Procedures and are not public. The string is an ISO 20022 externalised code and several values on this list carry Australian or PayTo specific meanings the ISO definition does not give, so never carry a meaning here from another rail's list or from the ISO definition. This one has a rule behind it rather than only a code: Regulation 6.1(c) forbids a zero value clearing request and obliges the receiving institution to reject one.", "related": [ "au-npp:messages" ], "basis": { "sources": "Listed as an NPP reason code, with the meaning given here in Orca's own words, by the governing authority's own published guidance: NPP Payment Initiation Messages v4.0, Appendix F, read 2026-09-21. A second source on a different host, Westpac's public BankRec documentation for the New Payments Platform, read the same day, lists the same value and describes it as the service prohibiting zero dollar payments. The authority's own note under Appendix F says an NPP financial institution may offer alternative reason codes and that further guidance on how the codes are used comes from that institution, so this record describes an indicative value on a leg the scheme does not mandate, and confidence is capped at medium for that reason and not because of the source's class.", "confidence": "medium" }, "currency": { "effective_since": "2019-11-22", "effective_to": null, "effective_note": "Effective since 2019-11-22, the date the guidance's own document control gives for version 1.0; the appendix has changed across versions and whether this value was in version 1.0 is [Unverified]. Drafted 2026-09-21 from the authority's own published list. The list is indicative: the guidance says an institution's acceptance of customer payment instructions and provision of status reports is proprietary and at its discretion, and that an institution may offer alternative reason codes. No record here may be read as saying an institution must use this value or must use it with this meaning.", "source_edition": "NPP Payment Initiation Messages, technical guidance v4.0 dated 20 November 2025, Appendix F, read 2026-09-21. The governing authority publishes this list as guidance for a leg it does not mandate, and notes under the appendix that an NPP financial institution may offer alternative reason codes. The scheme's own interbank code set is in the NPP Procedures, which are available to members and direct affiliates only and were not consulted.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.auspayplus.com.au/wp-content/uploads/2026/03/NPP-payment-initiation-V4.0.pdf", "source_class": "authoritative_primary", "source_title": "NPP Payment Initiation Messages, technical guidance for corporates, government and third parties, v4.0", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Appendix F gives AM01 the ISO name for zero amount, described as the transaction amount not being able to be zero, matching the record. The same description is given to AM02 under a different ISO name, and the record's caveat already says the guidance does not distinguish the two." } ] }, "rail_name": "NPP Payment Initiation Reason Codes (Australia)", "governing_authority": "NPP Australia Limited", "snapshot": "2026-09-20", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for Payment initiation instruction (pain.001). Its own scope line reads: a payment instruction a corporate, government or third party customer sends its own NPP financial institution, and the status report that answers it. Not the interbank leg..", "from": "applies_to" } ] }, { "uid": "au-npp-reject:AM02", "id": "AM02", "rail": "au-npp-reject", "kind": "reason-code", "name": "Not allowed amount", "group": "administrative", "summary": "The authority's own description of this value is that the transaction amount cannot be zero, which is the same description it gives AM01 under a different ISO name. Orca records what the authority prints and does not invent a distinction it does not draw.", "triggers": [ "The amount is one the institution will not accept", "The amount is zero, which is what the authority's own description of this value says" ], "actions": [ "Payer: check the amount against what the institution accepts and send a corrected instruction", "Payer: ask the institution which of the two zero amount values it actually uses" ], "retry": { "allowed": true, "rule": "Send a corrected instruction with an amount the institution accepts." }, "facts": { "return_windows": [ { "action": "payment initiation rejection", "by": "Payer Participant", "deadline": "An institution that accepts customer payment instructions answers them with status reports that acknowledge, reject or confirm settlement, and the authority's guidance says those reports are essential for tracking and reconciling the instructions. It gives no deadline for one. Nothing in the rulebook gives one either, because the scheme does not require the leg at all: the guidance says accepting these instructions and providing these reports is proprietary and at each institution's discretion. So the deadline for a rejection carrying any of the 33 published reason codes is whatever an institution has agreed with its own customer, and no public figure exists." } ], "applies_to": "a payment instruction a corporate, government or third party customer sends its own NPP financial institution, and the status report that answers it. Not the interbank leg." }, "caveat": "Not a mandatory scheme code. The governing authority publishes this list as guidance for the payment instruction a customer sends its own institution, and notes that an institution may offer alternative reason codes, so another Australian institution may use a different value for the same failure or this value for a different one. It is also not the interbank code set: the values a rejected clearing request carries are in the NPP Procedures and are not public. The string is an ISO 20022 externalised code and several values on this list carry Australian or PayTo specific meanings the ISO definition does not give, so never carry a meaning here from another rail's list or from the ISO definition. The authority's published description for this value repeats the one it gives AM01. What distinguishes the two on this leg is not stated in the guidance, and Orca does not supply a distinction. A participant's published list gives this value a different meaning. Orca records both and resolves neither; the disagreement is in the conflict register under the identifier au-npp-am02-meaning.", "related": [ "au-npp:messages" ], "basis": { "sources": "Listed as an NPP reason code, with the meaning given here in Orca's own words, by the governing authority's own published guidance: NPP Payment Initiation Messages v4.0, Appendix F, read 2026-09-21. A second source on a different host, Westpac's public BankRec documentation for the New Payments Platform, read the same day, lists the same value and gives it a different meaning, an amount above the allowed maximum, which is the opposite end of the range from the authority's own description. Orca does not resolve that disagreement: the two documents describe different legs of the payment, and the disagreement is logged in corpus/conflicts.json under the identifier au-npp-am02-meaning. The authority's own note under Appendix F says an NPP financial institution may offer alternative reason codes and that further guidance on how the codes are used comes from that institution, so this record describes an indicative value on a leg the scheme does not mandate, and confidence is capped at medium for that reason and not because of the source's class.", "confidence": "medium" }, "currency": { "effective_since": "2019-11-22", "effective_to": null, "effective_note": "Effective since 2019-11-22, the date the guidance's own document control gives for version 1.0; the appendix has changed across versions and whether this value was in version 1.0 is [Unverified]. Drafted 2026-09-21 from the authority's own published list. The list is indicative: the guidance says an institution's acceptance of customer payment instructions and provision of status reports is proprietary and at its discretion, and that an institution may offer alternative reason codes. No record here may be read as saying an institution must use this value or must use it with this meaning.", "source_edition": "NPP Payment Initiation Messages, technical guidance v4.0 dated 20 November 2025, Appendix F, read 2026-09-21. The governing authority publishes this list as guidance for a leg it does not mandate, and notes under the appendix that an NPP financial institution may offer alternative reason codes. The scheme's own interbank code set is in the NPP Procedures, which are available to members and direct affiliates only and were not consulted.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.auspayplus.com.au/wp-content/uploads/2026/03/NPP-payment-initiation-V4.0.pdf", "source_class": "authoritative_primary", "source_title": "NPP Payment Initiation Messages, technical guidance for corporates, government and third parties, v4.0", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Appendix F gives AM02 the ISO name for not allowed amount, and its own description of the error repeats word for word the description it gives AM01, the transaction amount not being able to be zero, which the record's caveat already states as an undistinguished pair. Westpac's own list gives AM02 the different meaning of an amount above the allowed maximum, already logged as a conflict register entry." } ] }, "rail_name": "NPP Payment Initiation Reason Codes (Australia)", "governing_authority": "NPP Australia Limited", "snapshot": "2026-09-20", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for Payment initiation instruction (pain.001). Its own scope line reads: a payment instruction a corporate, government or third party customer sends its own NPP financial institution, and the status report that answers it. Not the interbank leg..", "from": "applies_to" } ] }, { "uid": "au-npp-reject:AM03", "id": "AM03", "rail": "au-npp-reject", "kind": "reason-code", "name": "Not allowed currency", "group": "account", "summary": "The account the payment would come from cannot draw funds in Australian dollars. Everything on this rail is in Australian dollars between Australian domiciled accounts, so an account that cannot draw in the currency cannot be used.", "triggers": [ "The paying account is denominated in another currency", "The account is not permitted to draw Australian dollars" ], "actions": [ "Payer: use an Australian dollar account", "Payer: use a foreign exchange route instead" ], "retry": { "allowed": true, "rule": "Send the instruction from an account that can draw Australian dollars." }, "facts": { "return_windows": [ { "action": "payment initiation rejection", "by": "Payer Participant", "deadline": "An institution that accepts customer payment instructions answers them with status reports that acknowledge, reject or confirm settlement, and the authority's guidance says those reports are essential for tracking and reconciling the instructions. It gives no deadline for one. Nothing in the rulebook gives one either, because the scheme does not require the leg at all: the guidance says accepting these instructions and providing these reports is proprietary and at each institution's discretion. So the deadline for a rejection carrying any of the 33 published reason codes is whatever an institution has agreed with its own customer, and no public figure exists." } ], "applies_to": "a payment instruction a corporate, government or third party customer sends its own NPP financial institution, and the status report that answers it. Not the interbank leg." }, "caveat": "Not a mandatory scheme code. The governing authority publishes this list as guidance for the payment instruction a customer sends its own institution, and notes that an institution may offer alternative reason codes, so another Australian institution may use a different value for the same failure or this value for a different one. It is also not the interbank code set: the values a rejected clearing request carries are in the NPP Procedures and are not public. The string is an ISO 20022 externalised code and several values on this list carry Australian or PayTo specific meanings the ISO definition does not give, so never carry a meaning here from another rail's list or from the ISO definition.", "related": [ "au-npp:messages" ], "basis": { "sources": "Listed as an NPP reason code, with the meaning given here in Orca's own words, by the governing authority's own published guidance: NPP Payment Initiation Messages v4.0, Appendix F, read 2026-09-21. A second source on a different host, Westpac's public BankRec documentation for the New Payments Platform, read the same day, lists the same value and describes it as a foreign currency amount being invalid, which is the same subject in a participant's words. The authority's own note under Appendix F says an NPP financial institution may offer alternative reason codes and that further guidance on how the codes are used comes from that institution, so this record describes an indicative value on a leg the scheme does not mandate, and confidence is capped at medium for that reason and not because of the source's class.", "confidence": "medium" }, "currency": { "effective_since": "2019-11-22", "effective_to": null, "effective_note": "Effective since 2019-11-22, the date the guidance's own document control gives for version 1.0; the appendix has changed across versions and whether this value was in version 1.0 is [Unverified]. Drafted 2026-09-21 from the authority's own published list. The list is indicative: the guidance says an institution's acceptance of customer payment instructions and provision of status reports is proprietary and at its discretion, and that an institution may offer alternative reason codes. No record here may be read as saying an institution must use this value or must use it with this meaning.", "source_edition": "NPP Payment Initiation Messages, technical guidance v4.0 dated 20 November 2025, Appendix F, read 2026-09-21. The governing authority publishes this list as guidance for a leg it does not mandate, and notes under the appendix that an NPP financial institution may offer alternative reason codes. The scheme's own interbank code set is in the NPP Procedures, which are available to members and direct affiliates only and were not consulted.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.auspayplus.com.au/wp-content/uploads/2026/03/NPP-payment-initiation-V4.0.pdf", "source_class": "authoritative_primary", "source_title": "NPP Payment Initiation Messages, technical guidance for corporates, government and third parties, v4.0", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Appendix F gives AM03 the ISO name for not allowed currency, described as the account to be debited being unable to draw funds in AUD, matching the record." } ] }, "rail_name": "NPP Payment Initiation Reason Codes (Australia)", "governing_authority": "NPP Australia Limited", "snapshot": "2026-09-20", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for Payment initiation instruction (pain.001). Its own scope line reads: a payment instruction a corporate, government or third party customer sends its own NPP financial institution, and the status report that answers it. Not the interbank leg..", "from": "applies_to" } ] }, { "uid": "au-npp-reject:AM04", "id": "AM04", "rail": "au-npp-reject", "kind": "reason-code", "name": "Insufficient funds", "group": "funds", "summary": "The paying account does not have enough available balance to cover the amount asked for.", "triggers": [ "The available balance is below the amount of the payment", "Funds on the account are held or uncleared and not available" ], "actions": [ "Payer: fund the account and send the instruction again", "Payer: check whether a hold rather than the balance is the problem" ], "retry": { "allowed": true, "rule": "Send the instruction again once the funds are available. Nothing settled, so nothing has to come back." }, "facts": { "return_windows": [ { "action": "payment initiation rejection", "by": "Payer Participant", "deadline": "An institution that accepts customer payment instructions answers them with status reports that acknowledge, reject or confirm settlement, and the authority's guidance says those reports are essential for tracking and reconciling the instructions. It gives no deadline for one. Nothing in the rulebook gives one either, because the scheme does not require the leg at all: the guidance says accepting these instructions and providing these reports is proprietary and at each institution's discretion. So the deadline for a rejection carrying any of the 33 published reason codes is whatever an institution has agreed with its own customer, and no public figure exists." } ], "applies_to": "a payment instruction a corporate, government or third party customer sends its own NPP financial institution, and the status report that answers it. Not the interbank leg." }, "caveat": "Not a mandatory scheme code. The governing authority publishes this list as guidance for the payment instruction a customer sends its own institution, and notes that an institution may offer alternative reason codes, so another Australian institution may use a different value for the same failure or this value for a different one. It is also not the interbank code set: the values a rejected clearing request carries are in the NPP Procedures and are not public. The string is an ISO 20022 externalised code and several values on this list carry Australian or PayTo specific meanings the ISO definition does not give, so never carry a meaning here from another rail's list or from the ISO definition.", "related": [ "au-npp:messages" ], "basis": { "sources": "Listed as an NPP reason code, with the meaning given here in Orca's own words, by the governing authority's own published guidance: NPP Payment Initiation Messages v4.0, Appendix F, read 2026-09-21. No second public source read carries this value. The authority's own note under Appendix F says an NPP financial institution may offer alternative reason codes and that further guidance on how the codes are used comes from that institution, so this record describes an indicative value on a leg the scheme does not mandate, and confidence is capped at medium for that reason and not because of the source's class.", "confidence": "medium" }, "currency": { "effective_since": "2019-11-22", "effective_to": null, "effective_note": "Effective since 2019-11-22, the date the guidance's own document control gives for version 1.0; the appendix has changed across versions and whether this value was in version 1.0 is [Unverified]. Drafted 2026-09-21 from the authority's own published list. The list is indicative: the guidance says an institution's acceptance of customer payment instructions and provision of status reports is proprietary and at its discretion, and that an institution may offer alternative reason codes. No record here may be read as saying an institution must use this value or must use it with this meaning.", "source_edition": "NPP Payment Initiation Messages, technical guidance v4.0 dated 20 November 2025, Appendix F, read 2026-09-21. The governing authority publishes this list as guidance for a leg it does not mandate, and notes under the appendix that an NPP financial institution may offer alternative reason codes. The scheme's own interbank code set is in the NPP Procedures, which are available to members and direct affiliates only and were not consulted.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.auspayplus.com.au/wp-content/uploads/2026/03/NPP-payment-initiation-V4.0.pdf", "source_class": "authoritative_primary", "source_title": "NPP Payment Initiation Messages, technical guidance for corporates, government and third parties, v4.0", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Appendix F gives AM04 the ISO name for insufficient funds, described as the debtor account having an available balance too low to cover the requested amount, matching the record." } ] }, "rail_name": "NPP Payment Initiation Reason Codes (Australia)", "governing_authority": "NPP Australia Limited", "snapshot": "2026-09-20", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for Payment initiation instruction (pain.001). Its own scope line reads: a payment instruction a corporate, government or third party customer sends its own NPP financial institution, and the status report that answers it. Not the interbank leg..", "from": "applies_to" } ] }, { "uid": "au-npp-reject:AM06", "id": "AM06", "rail": "au-npp-reject", "kind": "reason-code", "name": "Too low amount", "group": "authorization", "summary": "The amount asked for is below the minimum the PayTo agreement allows. A PayTo specific meaning that the ISO definition does not carry.", "triggers": [ "A payment request under a PayTo agreement is for less than the agreement's minimum" ], "actions": [ "Business: send a request inside the agreed range, or send the payer an updated agreement to authorise", "Payer: check what the agreement they authorised actually allows" ], "retry": { "allowed": false, "rule": "Resending the same amount will fail again. Either the amount changes or the agreement does." }, "facts": { "return_windows": [ { "action": "payment initiation rejection", "by": "Payer Participant", "deadline": "An institution that accepts customer payment instructions answers them with status reports that acknowledge, reject or confirm settlement, and the authority's guidance says those reports are essential for tracking and reconciling the instructions. It gives no deadline for one. Nothing in the rulebook gives one either, because the scheme does not require the leg at all: the guidance says accepting these instructions and providing these reports is proprietary and at each institution's discretion. So the deadline for a rejection carrying any of the 33 published reason codes is whatever an institution has agreed with its own customer, and no public figure exists." } ], "applies_to": "a payment instruction a corporate, government or third party customer sends its own NPP financial institution, and the status report that answers it. Not the interbank leg." }, "caveat": "Not a mandatory scheme code. The governing authority publishes this list as guidance for the payment instruction a customer sends its own institution, and notes that an institution may offer alternative reason codes, so another Australian institution may use a different value for the same failure or this value for a different one. It is also not the interbank code set: the values a rejected clearing request carries are in the NPP Procedures and are not public. The string is an ISO 20022 externalised code and several values on this list carry Australian or PayTo specific meanings the ISO definition does not give, so never carry a meaning here from another rail's list or from the ISO definition. A PayTo specific meaning. Read with AM09 and AM21, which cover the other edges of what an agreement permits.", "related": [ "au-npp:messages" ], "basis": { "sources": "Listed as an NPP reason code, with the meaning given here in Orca's own words, by the governing authority's own published guidance: NPP Payment Initiation Messages v4.0, Appendix F, read 2026-09-21. No second public source read carries this value. The authority's own note under Appendix F says an NPP financial institution may offer alternative reason codes and that further guidance on how the codes are used comes from that institution, so this record describes an indicative value on a leg the scheme does not mandate, and confidence is capped at medium for that reason and not because of the source's class.", "confidence": "medium" }, "currency": { "effective_since": "2019-11-22", "effective_to": null, "effective_note": "Effective since 2019-11-22, the date the guidance's own document control gives for version 1.0; the appendix has changed across versions and whether this value was in version 1.0 is [Unverified]. Drafted 2026-09-21 from the authority's own published list. The list is indicative: the guidance says an institution's acceptance of customer payment instructions and provision of status reports is proprietary and at its discretion, and that an institution may offer alternative reason codes. No record here may be read as saying an institution must use this value or must use it with this meaning.", "source_edition": "NPP Payment Initiation Messages, technical guidance v4.0 dated 20 November 2025, Appendix F, read 2026-09-21. The governing authority publishes this list as guidance for a leg it does not mandate, and notes under the appendix that an NPP financial institution may offer alternative reason codes. The scheme's own interbank code set is in the NPP Procedures, which are available to members and direct affiliates only and were not consulted.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.auspayplus.com.au/wp-content/uploads/2026/03/NPP-payment-initiation-V4.0.pdf", "source_class": "authoritative_primary", "source_title": "NPP Payment Initiation Messages, technical guidance for corporates, government and third parties, v4.0", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Appendix F gives AM06 the ISO name for too low amount, described as the requested amount being below the minimum allowed under the PayTo agreement, matching the record's PayTo specific reading." } ] }, "rail_name": "NPP Payment Initiation Reason Codes (Australia)", "governing_authority": "NPP Australia Limited", "snapshot": "2026-09-20", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for Payment initiation instruction (pain.001). Its own scope line reads: a payment instruction a corporate, government or third party customer sends its own NPP financial institution, and the status report that answers it. Not the interbank leg..", "from": "applies_to" } ] }, { "uid": "au-npp-reject:AM09", "id": "AM09", "rail": "au-npp-reject", "kind": "reason-code", "name": "Wrong amount", "group": "authorization", "summary": "The amount in a PayTo payment request is not the amount the agreement agreed or expected. Another PayTo specific meaning.", "triggers": [ "A payment request under a PayTo agreement is for an amount the agreement did not agree or expect" ], "actions": [ "Business: send a request for the agreed amount, or send an updated agreement for the payer to authorise", "Payer: check the agreement before authorising a change the business proposes" ], "retry": { "allowed": false, "rule": "The amount has to match the agreement, or the agreement has to change and be authorised again." }, "facts": { "return_windows": [ { "action": "payment initiation rejection", "by": "Payer Participant", "deadline": "An institution that accepts customer payment instructions answers them with status reports that acknowledge, reject or confirm settlement, and the authority's guidance says those reports are essential for tracking and reconciling the instructions. It gives no deadline for one. Nothing in the rulebook gives one either, because the scheme does not require the leg at all: the guidance says accepting these instructions and providing these reports is proprietary and at each institution's discretion. So the deadline for a rejection carrying any of the 33 published reason codes is whatever an institution has agreed with its own customer, and no public figure exists." } ], "applies_to": "a payment instruction a corporate, government or third party customer sends its own NPP financial institution, and the status report that answers it. Not the interbank leg." }, "caveat": "Not a mandatory scheme code. The governing authority publishes this list as guidance for the payment instruction a customer sends its own institution, and notes that an institution may offer alternative reason codes, so another Australian institution may use a different value for the same failure or this value for a different one. It is also not the interbank code set: the values a rejected clearing request carries are in the NPP Procedures and are not public. The string is an ISO 20022 externalised code and several values on this list carry Australian or PayTo specific meanings the ISO definition does not give, so never carry a meaning here from another rail's list or from the ISO definition. A PayTo specific meaning. A payment that got through despite being outside the agreement is a mandate claim, and the record in the operator's database is the evidence of what was agreed.", "related": [ "au-npp:messages" ], "basis": { "sources": "Listed as an NPP reason code, with the meaning given here in Orca's own words, by the governing authority's own published guidance: NPP Payment Initiation Messages v4.0, Appendix F, read 2026-09-21. No second public source read carries this value. The authority's own note under Appendix F says an NPP financial institution may offer alternative reason codes and that further guidance on how the codes are used comes from that institution, so this record describes an indicative value on a leg the scheme does not mandate, and confidence is capped at medium for that reason and not because of the source's class.", "confidence": "medium" }, "currency": { "effective_since": "2019-11-22", "effective_to": null, "effective_note": "Effective since 2019-11-22, the date the guidance's own document control gives for version 1.0; the appendix has changed across versions and whether this value was in version 1.0 is [Unverified]. Drafted 2026-09-21 from the authority's own published list. The list is indicative: the guidance says an institution's acceptance of customer payment instructions and provision of status reports is proprietary and at its discretion, and that an institution may offer alternative reason codes. No record here may be read as saying an institution must use this value or must use it with this meaning.", "source_edition": "NPP Payment Initiation Messages, technical guidance v4.0 dated 20 November 2025, Appendix F, read 2026-09-21. The governing authority publishes this list as guidance for a leg it does not mandate, and notes under the appendix that an NPP financial institution may offer alternative reason codes. The scheme's own interbank code set is in the NPP Procedures, which are available to members and direct affiliates only and were not consulted.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.auspayplus.com.au/wp-content/uploads/2026/03/NPP-payment-initiation-V4.0.pdf", "source_class": "authoritative_primary", "source_title": "NPP Payment Initiation Messages, technical guidance for corporates, government and third parties, v4.0", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Appendix F gives AM09 the ISO name for wrong amount, described as the PayTo payment amount in the instruction not being the amount agreed or expected, matching the record." } ] }, "rail_name": "NPP Payment Initiation Reason Codes (Australia)", "governing_authority": "NPP Australia Limited", "snapshot": "2026-09-20", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for Payment initiation instruction (pain.001). Its own scope line reads: a payment instruction a corporate, government or third party customer sends its own NPP financial institution, and the status report that answers it. Not the interbank leg..", "from": "applies_to" } ] }, { "uid": "au-npp-reject:AM12", "id": "AM12", "rail": "au-npp-reject", "kind": "reason-code", "name": "Invalid amount", "group": "administrative", "summary": "The amount is invalid or missing: the field itself is wrong rather than the figure being unacceptable.", "triggers": [ "The amount field was left out", "The amount is malformed" ], "actions": [ "Payer: correct the instruction and send it again", "Institution: check the message the system built against the guidance" ], "retry": { "allowed": true, "rule": "Send a corrected instruction." }, "facts": { "return_windows": [ { "action": "payment initiation rejection", "by": "Payer Participant", "deadline": "An institution that accepts customer payment instructions answers them with status reports that acknowledge, reject or confirm settlement, and the authority's guidance says those reports are essential for tracking and reconciling the instructions. It gives no deadline for one. Nothing in the rulebook gives one either, because the scheme does not require the leg at all: the guidance says accepting these instructions and providing these reports is proprietary and at each institution's discretion. So the deadline for a rejection carrying any of the 33 published reason codes is whatever an institution has agreed with its own customer, and no public figure exists." } ], "applies_to": "a payment instruction a corporate, government or third party customer sends its own NPP financial institution, and the status report that answers it. Not the interbank leg." }, "caveat": "Not a mandatory scheme code. The governing authority publishes this list as guidance for the payment instruction a customer sends its own institution, and notes that an institution may offer alternative reason codes, so another Australian institution may use a different value for the same failure or this value for a different one. It is also not the interbank code set: the values a rejected clearing request carries are in the NPP Procedures and are not public. The string is an ISO 20022 externalised code and several values on this list carry Australian or PayTo specific meanings the ISO definition does not give, so never carry a meaning here from another rail's list or from the ISO definition.", "related": [ "au-npp:messages" ], "basis": { "sources": "Listed as an NPP reason code, with the meaning given here in Orca's own words, by the governing authority's own published guidance: NPP Payment Initiation Messages v4.0, Appendix F, read 2026-09-21. A second source on a different host, Westpac's public BankRec documentation for the New Payments Platform, read the same day, lists the same value and describes it as a payment amount that is invalid or missing. The authority's own note under Appendix F says an NPP financial institution may offer alternative reason codes and that further guidance on how the codes are used comes from that institution, so this record describes an indicative value on a leg the scheme does not mandate, and confidence is capped at medium for that reason and not because of the source's class.", "confidence": "medium" }, "currency": { "effective_since": "2019-11-22", "effective_to": null, "effective_note": "Effective since 2019-11-22, the date the guidance's own document control gives for version 1.0; the appendix has changed across versions and whether this value was in version 1.0 is [Unverified]. Drafted 2026-09-21 from the authority's own published list. The list is indicative: the guidance says an institution's acceptance of customer payment instructions and provision of status reports is proprietary and at its discretion, and that an institution may offer alternative reason codes. No record here may be read as saying an institution must use this value or must use it with this meaning.", "source_edition": "NPP Payment Initiation Messages, technical guidance v4.0 dated 20 November 2025, Appendix F, read 2026-09-21. The governing authority publishes this list as guidance for a leg it does not mandate, and notes under the appendix that an NPP financial institution may offer alternative reason codes. The scheme's own interbank code set is in the NPP Procedures, which are available to members and direct affiliates only and were not consulted.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.auspayplus.com.au/wp-content/uploads/2026/03/NPP-payment-initiation-V4.0.pdf", "source_class": "authoritative_primary", "source_title": "NPP Payment Initiation Messages, technical guidance for corporates, government and third parties, v4.0", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Appendix F gives AM12 the ISO name for invalid amount, described as the amount being invalid or missing, matching the record." } ] }, "rail_name": "NPP Payment Initiation Reason Codes (Australia)", "governing_authority": "NPP Australia Limited", "snapshot": "2026-09-20", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for Payment initiation instruction (pain.001). Its own scope line reads: a payment instruction a corporate, government or third party customer sends its own NPP financial institution, and the status report that answers it. Not the interbank leg..", "from": "applies_to" } ] }, { "uid": "au-npp-reject:AM19", "id": "AM19", "rail": "au-npp-reject", "kind": "reason-code", "name": "Invalid group number of transactions", "group": "administrative", "summary": "The number of transactions stated for the group is invalid or missing. This value belongs to the shape of a file rather than to a payment.", "triggers": [ "The count of transactions in the group header was left out or does not match", "The instruction file was built with an inconsistent header" ], "actions": [ "Sender: correct the header and send the file again", "Sender: check the totals against what the institution's own guidance requires" ], "retry": { "allowed": true, "rule": "Correct the file and send it again." }, "facts": { "return_windows": [ { "action": "payment initiation rejection", "by": "Payer Participant", "deadline": "An institution that accepts customer payment instructions answers them with status reports that acknowledge, reject or confirm settlement, and the authority's guidance says those reports are essential for tracking and reconciling the instructions. It gives no deadline for one. Nothing in the rulebook gives one either, because the scheme does not require the leg at all: the guidance says accepting these instructions and providing these reports is proprietary and at each institution's discretion. So the deadline for a rejection carrying any of the 33 published reason codes is whatever an institution has agreed with its own customer, and no public figure exists." } ], "applies_to": "a payment instruction a corporate, government or third party customer sends its own NPP financial institution, and the status report that answers it. Not the interbank leg." }, "caveat": "Not a mandatory scheme code. The governing authority publishes this list as guidance for the payment instruction a customer sends its own institution, and notes that an institution may offer alternative reason codes, so another Australian institution may use a different value for the same failure or this value for a different one. It is also not the interbank code set: the values a rejected clearing request carries are in the NPP Procedures and are not public. The string is an ISO 20022 externalised code and several values on this list carry Australian or PayTo specific meanings the ISO definition does not give, so never carry a meaning here from another rail's list or from the ISO definition.", "related": [ "au-npp:messages" ], "basis": { "sources": "Listed as an NPP reason code, with the meaning given here in Orca's own words, by the governing authority's own published guidance: NPP Payment Initiation Messages v4.0, Appendix F, read 2026-09-21. A second source on a different host, Westpac's public BankRec documentation for the New Payments Platform, read the same day, lists the same value and describes it as the number of transactions at group level being invalid or missing. The authority's own note under Appendix F says an NPP financial institution may offer alternative reason codes and that further guidance on how the codes are used comes from that institution, so this record describes an indicative value on a leg the scheme does not mandate, and confidence is capped at medium for that reason and not because of the source's class.", "confidence": "medium" }, "currency": { "effective_since": "2019-11-22", "effective_to": null, "effective_note": "Effective since 2019-11-22, the date the guidance's own document control gives for version 1.0; the appendix has changed across versions and whether this value was in version 1.0 is [Unverified]. Drafted 2026-09-21 from the authority's own published list. The list is indicative: the guidance says an institution's acceptance of customer payment instructions and provision of status reports is proprietary and at its discretion, and that an institution may offer alternative reason codes. No record here may be read as saying an institution must use this value or must use it with this meaning.", "source_edition": "NPP Payment Initiation Messages, technical guidance v4.0 dated 20 November 2025, Appendix F, read 2026-09-21. The governing authority publishes this list as guidance for a leg it does not mandate, and notes under the appendix that an NPP financial institution may offer alternative reason codes. The scheme's own interbank code set is in the NPP Procedures, which are available to members and direct affiliates only and were not consulted.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.auspayplus.com.au/wp-content/uploads/2026/03/NPP-payment-initiation-V4.0.pdf", "source_class": "authoritative_primary", "source_title": "NPP Payment Initiation Messages, technical guidance for corporates, government and third parties, v4.0", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Appendix F gives AM19 the ISO name for invalid group number of transactions, described as the number of transactions being invalid or missing, matching the record." } ] }, "rail_name": "NPP Payment Initiation Reason Codes (Australia)", "governing_authority": "NPP Australia Limited", "snapshot": "2026-09-20", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for Payment initiation instruction (pain.001). Its own scope line reads: a payment instruction a corporate, government or third party customer sends its own NPP financial institution, and the status report that answers it. Not the interbank leg..", "from": "applies_to" } ] }, { "uid": "au-npp-reject:AM21", "id": "AM21", "rail": "au-npp-reject", "kind": "reason-code", "name": "Limit exceeded", "group": "authorization", "summary": "The amount asked for exceeds the limit the payer and their own institution agreed. This is a third kind of PayTo amount failure and the limit behind it is a private one between a customer and their bank.", "triggers": [ "A PayTo payment request exceeds the debtor to bank limit the payer agreed with their institution" ], "actions": [ "Payer: ask their institution about the agreed limit", "Business: expect this even where the agreement itself allows the amount, because the limit is not in the agreement" ], "retry": { "allowed": false, "rule": "The limit is between the payer and their institution. Resending will fail until the limit changes." }, "facts": { "return_windows": [ { "action": "payment initiation rejection", "by": "Payer Participant", "deadline": "An institution that accepts customer payment instructions answers them with status reports that acknowledge, reject or confirm settlement, and the authority's guidance says those reports are essential for tracking and reconciling the instructions. It gives no deadline for one. Nothing in the rulebook gives one either, because the scheme does not require the leg at all: the guidance says accepting these instructions and providing these reports is proprietary and at each institution's discretion. So the deadline for a rejection carrying any of the 33 published reason codes is whatever an institution has agreed with its own customer, and no public figure exists." } ], "applies_to": "a payment instruction a corporate, government or third party customer sends its own NPP financial institution, and the status report that answers it. Not the interbank leg." }, "caveat": "Not a mandatory scheme code. The governing authority publishes this list as guidance for the payment instruction a customer sends its own institution, and notes that an institution may offer alternative reason codes, so another Australian institution may use a different value for the same failure or this value for a different one. It is also not the interbank code set: the values a rejected clearing request carries are in the NPP Procedures and are not public. The string is an ISO 20022 externalised code and several values on this list carry Australian or PayTo specific meanings the ISO definition does not give, so never carry a meaning here from another rail's list or from the ISO definition. A PayTo specific meaning, and the limit is not part of the agreement: an amount can be inside the agreement and still exceed the payer's own arrangement with their bank.", "related": [ "au-npp:messages" ], "basis": { "sources": "Listed as an NPP reason code, with the meaning given here in Orca's own words, by the governing authority's own published guidance: NPP Payment Initiation Messages v4.0, Appendix F, read 2026-09-21. No second public source read carries this value. The authority's own note under Appendix F says an NPP financial institution may offer alternative reason codes and that further guidance on how the codes are used comes from that institution, so this record describes an indicative value on a leg the scheme does not mandate, and confidence is capped at medium for that reason and not because of the source's class.", "confidence": "medium" }, "currency": { "effective_since": "2019-11-22", "effective_to": null, "effective_note": "Effective since 2019-11-22, the date the guidance's own document control gives for version 1.0; the appendix has changed across versions and whether this value was in version 1.0 is [Unverified]. Drafted 2026-09-21 from the authority's own published list. The list is indicative: the guidance says an institution's acceptance of customer payment instructions and provision of status reports is proprietary and at its discretion, and that an institution may offer alternative reason codes. No record here may be read as saying an institution must use this value or must use it with this meaning.", "source_edition": "NPP Payment Initiation Messages, technical guidance v4.0 dated 20 November 2025, Appendix F, read 2026-09-21. The governing authority publishes this list as guidance for a leg it does not mandate, and notes under the appendix that an NPP financial institution may offer alternative reason codes. The scheme's own interbank code set is in the NPP Procedures, which are available to members and direct affiliates only and were not consulted.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.auspayplus.com.au/wp-content/uploads/2026/03/NPP-payment-initiation-V4.0.pdf", "source_class": "authoritative_primary", "source_title": "NPP Payment Initiation Messages, technical guidance for corporates, government and third parties, v4.0", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Appendix F gives AM21 the ISO name for limit exceeded, described as the requested amount exceeding the agreed limit between the debtor and the bank, matching the record's reading of a limit private to the payer and their own institution." } ] }, "rail_name": "NPP Payment Initiation Reason Codes (Australia)", "governing_authority": "NPP Australia Limited", "snapshot": "2026-09-20", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for Payment initiation instruction (pain.001). Its own scope line reads: a payment instruction a corporate, government or third party customer sends its own NPP financial institution, and the status report that answers it. Not the interbank leg..", "from": "applies_to" } ] }, { "uid": "au-npp-reject:BE06", "id": "BE06", "rail": "au-npp-reject", "kind": "reason-code", "name": "Unknown end customer", "group": "account", "summary": "The account does not exist, or it exists and cannot be debited or cannot accept funds. The broadest of the account values on this list.", "triggers": [ "The account named is not one the institution knows", "The account exists but cannot be used in the direction the payment needs" ], "actions": [ "Payer: confirm the payee's details, and check whether the payee's account can take a platform payment", "Institution: say which of the two situations applies where it can" ], "retry": { "allowed": true, "rule": "Confirm the details before sending again." }, "facts": { "return_windows": [ { "action": "payment initiation rejection", "by": "Payer Participant", "deadline": "An institution that accepts customer payment instructions answers them with status reports that acknowledge, reject or confirm settlement, and the authority's guidance says those reports are essential for tracking and reconciling the instructions. It gives no deadline for one. Nothing in the rulebook gives one either, because the scheme does not require the leg at all: the guidance says accepting these instructions and providing these reports is proprietary and at each institution's discretion. So the deadline for a rejection carrying any of the 33 published reason codes is whatever an institution has agreed with its own customer, and no public figure exists." } ], "applies_to": "a payment instruction a corporate, government or third party customer sends its own NPP financial institution, and the status report that answers it. Not the interbank leg." }, "caveat": "Not a mandatory scheme code. The governing authority publishes this list as guidance for the payment instruction a customer sends its own institution, and notes that an institution may offer alternative reason codes, so another Australian institution may use a different value for the same failure or this value for a different one. It is also not the interbank code set: the values a rejected clearing request carries are in the NPP Procedures and are not public. The string is an ISO 20022 externalised code and several values on this list carry Australian or PayTo specific meanings the ISO definition does not give, so never carry a meaning here from another rail's list or from the ISO definition.", "related": [ "au-npp:messages" ], "basis": { "sources": "Listed as an NPP reason code, with the meaning given here in Orca's own words, by the governing authority's own published guidance: NPP Payment Initiation Messages v4.0, Appendix F, read 2026-09-21. A second source on a different host, Westpac's public BankRec documentation for the New Payments Platform, read the same day, lists the same value and describes it as an account that does not exist, or exists but cannot accept funds. The authority's own note under Appendix F says an NPP financial institution may offer alternative reason codes and that further guidance on how the codes are used comes from that institution, so this record describes an indicative value on a leg the scheme does not mandate, and confidence is capped at medium for that reason and not because of the source's class.", "confidence": "medium" }, "currency": { "effective_since": "2019-11-22", "effective_to": null, "effective_note": "Effective since 2019-11-22, the date the guidance's own document control gives for version 1.0; the appendix has changed across versions and whether this value was in version 1.0 is [Unverified]. Drafted 2026-09-21 from the authority's own published list. The list is indicative: the guidance says an institution's acceptance of customer payment instructions and provision of status reports is proprietary and at its discretion, and that an institution may offer alternative reason codes. No record here may be read as saying an institution must use this value or must use it with this meaning.", "source_edition": "NPP Payment Initiation Messages, technical guidance v4.0 dated 20 November 2025, Appendix F, read 2026-09-21. The governing authority publishes this list as guidance for a leg it does not mandate, and notes under the appendix that an NPP financial institution may offer alternative reason codes. The scheme's own interbank code set is in the NPP Procedures, which are available to members and direct affiliates only and were not consulted.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.auspayplus.com.au/wp-content/uploads/2026/03/NPP-payment-initiation-V4.0.pdf", "source_class": "authoritative_primary", "source_title": "NPP Payment Initiation Messages, technical guidance for corporates, government and third parties, v4.0", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Appendix F gives BE06 the ISO name for unknown end customer, described as the account not existing or existing but unable to be debited or accept funds, matching the record." } ] }, "rail_name": "NPP Payment Initiation Reason Codes (Australia)", "governing_authority": "NPP Australia Limited", "snapshot": "2026-09-20", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for Payment initiation instruction (pain.001). Its own scope line reads: a payment instruction a corporate, government or third party customer sends its own NPP financial institution, and the status report that answers it. Not the interbank leg..", "from": "applies_to" } ] }, { "uid": "au-npp-reject:BE08", "id": "BE08", "rail": "au-npp-reject", "kind": "reason-code", "name": "Missing debtor name", "group": "administrative", "summary": "The paying customer's name is required and was not supplied.", "triggers": [ "The payer name field was left out of the instruction", "The system built the message without a payer name" ], "actions": [ "Sender: put the payer's name in and send the instruction again" ], "retry": { "allowed": true, "rule": "Correct the instruction and send it again." }, "facts": { "return_windows": [ { "action": "payment initiation rejection", "by": "Payer Participant", "deadline": "An institution that accepts customer payment instructions answers them with status reports that acknowledge, reject or confirm settlement, and the authority's guidance says those reports are essential for tracking and reconciling the instructions. It gives no deadline for one. Nothing in the rulebook gives one either, because the scheme does not require the leg at all: the guidance says accepting these instructions and providing these reports is proprietary and at each institution's discretion. So the deadline for a rejection carrying any of the 33 published reason codes is whatever an institution has agreed with its own customer, and no public figure exists." } ], "applies_to": "a payment instruction a corporate, government or third party customer sends its own NPP financial institution, and the status report that answers it. Not the interbank leg." }, "caveat": "Not a mandatory scheme code. The governing authority publishes this list as guidance for the payment instruction a customer sends its own institution, and notes that an institution may offer alternative reason codes, so another Australian institution may use a different value for the same failure or this value for a different one. It is also not the interbank code set: the values a rejected clearing request carries are in the NPP Procedures and are not public. The string is an ISO 20022 externalised code and several values on this list carry Australian or PayTo specific meanings the ISO definition does not give, so never carry a meaning here from another rail's list or from the ISO definition. This value is easy to miss when counting the appendix, because the list runs from BE06 straight past it to BE22 in most summaries. The authority's Appendix F carries all three.", "related": [ "au-npp:messages" ], "basis": { "sources": "Listed as an NPP reason code, with the meaning given here in Orca's own words, by the governing authority's own published guidance: NPP Payment Initiation Messages v4.0, Appendix F, read 2026-09-21. No second public source read carries this value. The authority's own note under Appendix F says an NPP financial institution may offer alternative reason codes and that further guidance on how the codes are used comes from that institution, so this record describes an indicative value on a leg the scheme does not mandate, and confidence is capped at medium for that reason and not because of the source's class.", "confidence": "medium" }, "currency": { "effective_since": "2019-11-22", "effective_to": null, "effective_note": "Effective since 2019-11-22, the date the guidance's own document control gives for version 1.0; the appendix has changed across versions and whether this value was in version 1.0 is [Unverified]. Drafted 2026-09-21 from the authority's own published list. The list is indicative: the guidance says an institution's acceptance of customer payment instructions and provision of status reports is proprietary and at its discretion, and that an institution may offer alternative reason codes. No record here may be read as saying an institution must use this value or must use it with this meaning.", "source_edition": "NPP Payment Initiation Messages, technical guidance v4.0 dated 20 November 2025, Appendix F, read 2026-09-21. The governing authority publishes this list as guidance for a leg it does not mandate, and notes under the appendix that an NPP financial institution may offer alternative reason codes. The scheme's own interbank code set is in the NPP Procedures, which are available to members and direct affiliates only and were not consulted.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.auspayplus.com.au/wp-content/uploads/2026/03/NPP-payment-initiation-V4.0.pdf", "source_class": "authoritative_primary", "source_title": "NPP Payment Initiation Messages, technical guidance for corporates, government and third parties, v4.0", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Appendix F gives BE08 the ISO name for missing debtor name, described as the payer customer name being required but not provided, matching the record. This is the 33rd value in Appendix F, confirming the count the rail brief corrected from 32 to 33." } ] }, "rail_name": "NPP Payment Initiation Reason Codes (Australia)", "governing_authority": "NPP Australia Limited", "snapshot": "2026-09-20", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for Payment initiation instruction (pain.001). Its own scope line reads: a payment instruction a corporate, government or third party customer sends its own NPP financial institution, and the status report that answers it. Not the interbank leg..", "from": "applies_to" } ] }, { "uid": "au-npp-reject:BE22", "id": "BE22", "rail": "au-npp-reject", "kind": "reason-code", "name": "Missing creditor name", "group": "administrative", "summary": "The payee's name is required and was not supplied.", "triggers": [ "The payee name field was left out of the instruction" ], "actions": [ "Sender: put the payee's name in and send the instruction again" ], "retry": { "allowed": true, "rule": "Correct the instruction and send it again." }, "facts": { "return_windows": [ { "action": "payment initiation rejection", "by": "Payer Participant", "deadline": "An institution that accepts customer payment instructions answers them with status reports that acknowledge, reject or confirm settlement, and the authority's guidance says those reports are essential for tracking and reconciling the instructions. It gives no deadline for one. Nothing in the rulebook gives one either, because the scheme does not require the leg at all: the guidance says accepting these instructions and providing these reports is proprietary and at each institution's discretion. So the deadline for a rejection carrying any of the 33 published reason codes is whatever an institution has agreed with its own customer, and no public figure exists." } ], "applies_to": "a payment instruction a corporate, government or third party customer sends its own NPP financial institution, and the status report that answers it. Not the interbank leg." }, "caveat": "Not a mandatory scheme code. The governing authority publishes this list as guidance for the payment instruction a customer sends its own institution, and notes that an institution may offer alternative reason codes, so another Australian institution may use a different value for the same failure or this value for a different one. It is also not the interbank code set: the values a rejected clearing request carries are in the NPP Procedures and are not public. The string is an ISO 20022 externalised code and several values on this list carry Australian or PayTo specific meanings the ISO definition does not give, so never carry a meaning here from another rail's list or from the ISO definition.", "related": [ "au-npp:messages" ], "basis": { "sources": "Listed as an NPP reason code, with the meaning given here in Orca's own words, by the governing authority's own published guidance: NPP Payment Initiation Messages v4.0, Appendix F, read 2026-09-21. A second source on a different host, Westpac's public BankRec documentation for the New Payments Platform, read the same day, lists the same value and describes it as a creditor name that is required but was not provided. The authority's own note under Appendix F says an NPP financial institution may offer alternative reason codes and that further guidance on how the codes are used comes from that institution, so this record describes an indicative value on a leg the scheme does not mandate, and confidence is capped at medium for that reason and not because of the source's class.", "confidence": "medium" }, "currency": { "effective_since": "2019-11-22", "effective_to": null, "effective_note": "Effective since 2019-11-22, the date the guidance's own document control gives for version 1.0; the appendix has changed across versions and whether this value was in version 1.0 is [Unverified]. Drafted 2026-09-21 from the authority's own published list. The list is indicative: the guidance says an institution's acceptance of customer payment instructions and provision of status reports is proprietary and at its discretion, and that an institution may offer alternative reason codes. No record here may be read as saying an institution must use this value or must use it with this meaning.", "source_edition": "NPP Payment Initiation Messages, technical guidance v4.0 dated 20 November 2025, Appendix F, read 2026-09-21. The governing authority publishes this list as guidance for a leg it does not mandate, and notes under the appendix that an NPP financial institution may offer alternative reason codes. The scheme's own interbank code set is in the NPP Procedures, which are available to members and direct affiliates only and were not consulted.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.auspayplus.com.au/wp-content/uploads/2026/03/NPP-payment-initiation-V4.0.pdf", "source_class": "authoritative_primary", "source_title": "NPP Payment Initiation Messages, technical guidance for corporates, government and third parties, v4.0", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Appendix F gives BE22 the ISO name for missing creditor name, described as the payee customer name being required but not provided, matching the record." } ] }, "rail_name": "NPP Payment Initiation Reason Codes (Australia)", "governing_authority": "NPP Australia Limited", "snapshot": "2026-09-20", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for Payment initiation instruction (pain.001). Its own scope line reads: a payment instruction a corporate, government or third party customer sends its own NPP financial institution, and the status report that answers it. Not the interbank leg..", "from": "applies_to" } ] }, { "uid": "au-npp-reject:CH20", "id": "CH20", "rail": "au-npp-reject", "kind": "reason-code", "name": "Decimal points not compatible with currency", "group": "technical", "summary": "The amount does not carry either two decimal places or none.", "triggers": [ "The amount was built with one decimal place, or with more than two", "A rounding or formatting step upstream produced an amount the format does not allow" ], "actions": [ "Sender: format the amount with two decimal places or none and send it again" ], "retry": { "allowed": true, "rule": "Correct the formatting and send the instruction again." }, "facts": { "return_windows": [ { "action": "payment initiation rejection", "by": "Payer Participant", "deadline": "An institution that accepts customer payment instructions answers them with status reports that acknowledge, reject or confirm settlement, and the authority's guidance says those reports are essential for tracking and reconciling the instructions. It gives no deadline for one. Nothing in the rulebook gives one either, because the scheme does not require the leg at all: the guidance says accepting these instructions and providing these reports is proprietary and at each institution's discretion. So the deadline for a rejection carrying any of the 33 published reason codes is whatever an institution has agreed with its own customer, and no public figure exists." } ], "applies_to": "a payment instruction a corporate, government or third party customer sends its own NPP financial institution, and the status report that answers it. Not the interbank leg." }, "caveat": "Not a mandatory scheme code. The governing authority publishes this list as guidance for the payment instruction a customer sends its own institution, and notes that an institution may offer alternative reason codes, so another Australian institution may use a different value for the same failure or this value for a different one. It is also not the interbank code set: the values a rejected clearing request carries are in the NPP Procedures and are not public. The string is an ISO 20022 externalised code and several values on this list carry Australian or PayTo specific meanings the ISO definition does not give, so never carry a meaning here from another rail's list or from the ISO definition.", "related": [ "au-npp:messages" ], "basis": { "sources": "Listed as an NPP reason code, with the meaning given here in Orca's own words, by the governing authority's own published guidance: NPP Payment Initiation Messages v4.0, Appendix F, read 2026-09-21. A second source on a different host, Westpac's public BankRec documentation for the New Payments Platform, read the same day, lists the same value and describes it as decimal places in the amount not being consistent with the currency. The authority's own note under Appendix F says an NPP financial institution may offer alternative reason codes and that further guidance on how the codes are used comes from that institution, so this record describes an indicative value on a leg the scheme does not mandate, and confidence is capped at medium for that reason and not because of the source's class.", "confidence": "medium" }, "currency": { "effective_since": "2019-11-22", "effective_to": null, "effective_note": "Effective since 2019-11-22, the date the guidance's own document control gives for version 1.0; the appendix has changed across versions and whether this value was in version 1.0 is [Unverified]. Drafted 2026-09-21 from the authority's own published list. The list is indicative: the guidance says an institution's acceptance of customer payment instructions and provision of status reports is proprietary and at its discretion, and that an institution may offer alternative reason codes. No record here may be read as saying an institution must use this value or must use it with this meaning.", "source_edition": "NPP Payment Initiation Messages, technical guidance v4.0 dated 20 November 2025, Appendix F, read 2026-09-21. The governing authority publishes this list as guidance for a leg it does not mandate, and notes under the appendix that an NPP financial institution may offer alternative reason codes. The scheme's own interbank code set is in the NPP Procedures, which are available to members and direct affiliates only and were not consulted.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.auspayplus.com.au/wp-content/uploads/2026/03/NPP-payment-initiation-V4.0.pdf", "source_class": "authoritative_primary", "source_title": "NPP Payment Initiation Messages, technical guidance for corporates, government and third parties, v4.0", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Appendix F gives CH20 the ISO name for decimal points not compatible with currency, described as the amount not having two or zero fraction digits, matching the record." } ] }, "rail_name": "NPP Payment Initiation Reason Codes (Australia)", "governing_authority": "NPP Australia Limited", "snapshot": "2026-09-20", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for Payment initiation instruction (pain.001). Its own scope line reads: a payment instruction a corporate, government or third party customer sends its own NPP financial institution, and the status report that answers it. Not the interbank leg..", "from": "applies_to" } ] }, { "uid": "au-npp-reject:CH21", "id": "CH21", "rail": "au-npp-reject", "kind": "reason-code", "name": "Required compulsory element missing", "group": "administrative", "summary": "One or more mandatory fields were not provided. The catch all for a message that is missing something the format requires.", "triggers": [ "A field the guidance marks mandatory was left out", "A field the institution requires on top of the guidance was left out" ], "actions": [ "Sender: check the instruction against the institution's own field requirements, not only against the published guidance", "Sender: correct the message and send it again" ], "retry": { "allowed": true, "rule": "Correct the message and send it again." }, "facts": { "return_windows": [ { "action": "payment initiation rejection", "by": "Payer Participant", "deadline": "An institution that accepts customer payment instructions answers them with status reports that acknowledge, reject or confirm settlement, and the authority's guidance says those reports are essential for tracking and reconciling the instructions. It gives no deadline for one. Nothing in the rulebook gives one either, because the scheme does not require the leg at all: the guidance says accepting these instructions and providing these reports is proprietary and at each institution's discretion. So the deadline for a rejection carrying any of the 33 published reason codes is whatever an institution has agreed with its own customer, and no public figure exists." } ], "applies_to": "a payment instruction a corporate, government or third party customer sends its own NPP financial institution, and the status report that answers it. Not the interbank leg." }, "caveat": "Not a mandatory scheme code. The governing authority publishes this list as guidance for the payment instruction a customer sends its own institution, and notes that an institution may offer alternative reason codes, so another Australian institution may use a different value for the same failure or this value for a different one. It is also not the interbank code set: the values a rejected clearing request carries are in the NPP Procedures and are not public. The string is an ISO 20022 externalised code and several values on this list carry Australian or PayTo specific meanings the ISO definition does not give, so never carry a meaning here from another rail's list or from the ISO definition. The guidance says its own mandatory and optional markings are guidance only and that an institution may impose additional requirements, so this value can be raised by a rule that is not published anywhere.", "related": [ "au-npp:messages" ], "basis": { "sources": "Listed as an NPP reason code, with the meaning given here in Orca's own words, by the governing authority's own published guidance: NPP Payment Initiation Messages v4.0, Appendix F, read 2026-09-21. A second source on a different host, Westpac's public BankRec documentation for the New Payments Platform, read the same day, lists the same value and describes it as compulsory values being missing. The authority's own note under Appendix F says an NPP financial institution may offer alternative reason codes and that further guidance on how the codes are used comes from that institution, so this record describes an indicative value on a leg the scheme does not mandate, and confidence is capped at medium for that reason and not because of the source's class.", "confidence": "medium" }, "currency": { "effective_since": "2019-11-22", "effective_to": null, "effective_note": "Effective since 2019-11-22, the date the guidance's own document control gives for version 1.0; the appendix has changed across versions and whether this value was in version 1.0 is [Unverified]. Drafted 2026-09-21 from the authority's own published list. The list is indicative: the guidance says an institution's acceptance of customer payment instructions and provision of status reports is proprietary and at its discretion, and that an institution may offer alternative reason codes. No record here may be read as saying an institution must use this value or must use it with this meaning.", "source_edition": "NPP Payment Initiation Messages, technical guidance v4.0 dated 20 November 2025, Appendix F, read 2026-09-21. The governing authority publishes this list as guidance for a leg it does not mandate, and notes under the appendix that an NPP financial institution may offer alternative reason codes. The scheme's own interbank code set is in the NPP Procedures, which are available to members and direct affiliates only and were not consulted.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.auspayplus.com.au/wp-content/uploads/2026/03/NPP-payment-initiation-V4.0.pdf", "source_class": "authoritative_primary", "source_title": "NPP Payment Initiation Messages, technical guidance for corporates, government and third parties, v4.0", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Appendix F gives CH21 the ISO name for required compulsory element missing, described as one or more mandatory fields not having been provided, matching the record." } ] }, "rail_name": "NPP Payment Initiation Reason Codes (Australia)", "governing_authority": "NPP Australia Limited", "snapshot": "2026-09-20", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for Payment initiation instruction (pain.001). Its own scope line reads: a payment instruction a corporate, government or third party customer sends its own NPP financial institution, and the status report that answers it. Not the interbank leg..", "from": "applies_to" } ] }, { "uid": "au-npp-reject:CURR", "id": "CURR", "rail": "au-npp-reject", "kind": "reason-code", "name": "Incorrect currency", "group": "technical", "summary": "The currency of the payment is wrong. Everything on this rail is in Australian dollars.", "triggers": [ "The instruction names a currency other than Australian dollars", "The currency field is wrong or inconsistent with the amount" ], "actions": [ "Sender: set the currency to Australian dollars and send the instruction again" ], "retry": { "allowed": true, "rule": "Correct the currency and send the instruction again." }, "facts": { "return_windows": [ { "action": "payment initiation rejection", "by": "Payer Participant", "deadline": "An institution that accepts customer payment instructions answers them with status reports that acknowledge, reject or confirm settlement, and the authority's guidance says those reports are essential for tracking and reconciling the instructions. It gives no deadline for one. Nothing in the rulebook gives one either, because the scheme does not require the leg at all: the guidance says accepting these instructions and providing these reports is proprietary and at each institution's discretion. So the deadline for a rejection carrying any of the 33 published reason codes is whatever an institution has agreed with its own customer, and no public figure exists." } ], "applies_to": "a payment instruction a corporate, government or third party customer sends its own NPP financial institution, and the status report that answers it. Not the interbank leg." }, "caveat": "Not a mandatory scheme code. The governing authority publishes this list as guidance for the payment instruction a customer sends its own institution, and notes that an institution may offer alternative reason codes, so another Australian institution may use a different value for the same failure or this value for a different one. It is also not the interbank code set: the values a rejected clearing request carries are in the NPP Procedures and are not public. The string is an ISO 20022 externalised code and several values on this list carry Australian or PayTo specific meanings the ISO definition does not give, so never carry a meaning here from another rail's list or from the ISO definition.", "related": [ "au-npp:messages" ], "basis": { "sources": "Listed as an NPP reason code, with the meaning given here in Orca's own words, by the governing authority's own published guidance: NPP Payment Initiation Messages v4.0, Appendix F, read 2026-09-21. A second source on a different host, Westpac's public BankRec documentation for the New Payments Platform, read the same day, lists the same value and describes it as the currency of the payment being incorrect. The authority's own note under Appendix F says an NPP financial institution may offer alternative reason codes and that further guidance on how the codes are used comes from that institution, so this record describes an indicative value on a leg the scheme does not mandate, and confidence is capped at medium for that reason and not because of the source's class.", "confidence": "medium" }, "currency": { "effective_since": "2019-11-22", "effective_to": null, "effective_note": "Effective since 2019-11-22, the date the guidance's own document control gives for version 1.0; the appendix has changed across versions and whether this value was in version 1.0 is [Unverified]. Drafted 2026-09-21 from the authority's own published list. The list is indicative: the guidance says an institution's acceptance of customer payment instructions and provision of status reports is proprietary and at its discretion, and that an institution may offer alternative reason codes. No record here may be read as saying an institution must use this value or must use it with this meaning.", "source_edition": "NPP Payment Initiation Messages, technical guidance v4.0 dated 20 November 2025, Appendix F, read 2026-09-21. The governing authority publishes this list as guidance for a leg it does not mandate, and notes under the appendix that an NPP financial institution may offer alternative reason codes. The scheme's own interbank code set is in the NPP Procedures, which are available to members and direct affiliates only and were not consulted.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.auspayplus.com.au/wp-content/uploads/2026/03/NPP-payment-initiation-V4.0.pdf", "source_class": "authoritative_primary", "source_title": "NPP Payment Initiation Messages, technical guidance for corporates, government and third parties, v4.0", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Appendix F gives CURR the ISO name for incorrect currency, described as the currency of the payment being incorrect, matching the record." } ] }, "rail_name": "NPP Payment Initiation Reason Codes (Australia)", "governing_authority": "NPP Australia Limited", "snapshot": "2026-09-20", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for Payment initiation instruction (pain.001). Its own scope line reads: a payment instruction a corporate, government or third party customer sends its own NPP financial institution, and the status report that answers it. Not the interbank leg..", "from": "applies_to" } ] }, { "uid": "au-npp-reject:DT02", "id": "DT02", "rail": "au-npp-reject", "kind": "reason-code", "name": "Invalid creation date", "group": "administrative", "summary": "The creation date and time in the group header is invalid, for example because it is in the past.", "triggers": [ "The message was built with a creation timestamp that is not acceptable", "A file was held and sent later with its original timestamp" ], "actions": [ "Sender: rebuild the message with a current timestamp and send it again" ], "retry": { "allowed": true, "rule": "Correct the timestamp and send the instruction again." }, "facts": { "return_windows": [ { "action": "payment initiation rejection", "by": "Payer Participant", "deadline": "An institution that accepts customer payment instructions answers them with status reports that acknowledge, reject or confirm settlement, and the authority's guidance says those reports are essential for tracking and reconciling the instructions. It gives no deadline for one. Nothing in the rulebook gives one either, because the scheme does not require the leg at all: the guidance says accepting these instructions and providing these reports is proprietary and at each institution's discretion. So the deadline for a rejection carrying any of the 33 published reason codes is whatever an institution has agreed with its own customer, and no public figure exists." } ], "applies_to": "a payment instruction a corporate, government or third party customer sends its own NPP financial institution, and the status report that answers it. Not the interbank leg." }, "caveat": "Not a mandatory scheme code. The governing authority publishes this list as guidance for the payment instruction a customer sends its own institution, and notes that an institution may offer alternative reason codes, so another Australian institution may use a different value for the same failure or this value for a different one. It is also not the interbank code set: the values a rejected clearing request carries are in the NPP Procedures and are not public. The string is an ISO 20022 externalised code and several values on this list carry Australian or PayTo specific meanings the ISO definition does not give, so never carry a meaning here from another rail's list or from the ISO definition.", "related": [ "au-npp:messages" ], "basis": { "sources": "Listed as an NPP reason code, with the meaning given here in Orca's own words, by the governing authority's own published guidance: NPP Payment Initiation Messages v4.0, Appendix F, read 2026-09-21. A second source on a different host, Westpac's public BankRec documentation for the New Payments Platform, read the same day, lists the same value and describes it as an invalid creation date format, which is the same field described slightly more narrowly. The authority's own note under Appendix F says an NPP financial institution may offer alternative reason codes and that further guidance on how the codes are used comes from that institution, so this record describes an indicative value on a leg the scheme does not mandate, and confidence is capped at medium for that reason and not because of the source's class.", "confidence": "medium" }, "currency": { "effective_since": "2019-11-22", "effective_to": null, "effective_note": "Effective since 2019-11-22, the date the guidance's own document control gives for version 1.0; the appendix has changed across versions and whether this value was in version 1.0 is [Unverified]. Drafted 2026-09-21 from the authority's own published list. The list is indicative: the guidance says an institution's acceptance of customer payment instructions and provision of status reports is proprietary and at its discretion, and that an institution may offer alternative reason codes. No record here may be read as saying an institution must use this value or must use it with this meaning.", "source_edition": "NPP Payment Initiation Messages, technical guidance v4.0 dated 20 November 2025, Appendix F, read 2026-09-21. The governing authority publishes this list as guidance for a leg it does not mandate, and notes under the appendix that an NPP financial institution may offer alternative reason codes. The scheme's own interbank code set is in the NPP Procedures, which are available to members and direct affiliates only and were not consulted.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.auspayplus.com.au/wp-content/uploads/2026/03/NPP-payment-initiation-V4.0.pdf", "source_class": "authoritative_primary", "source_title": "NPP Payment Initiation Messages, technical guidance for corporates, government and third parties, v4.0", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Appendix F gives DT02 the ISO name for invalid creation date, described as an invalid creation date and time in the group header, for example a historic date, matching the record." } ] }, "rail_name": "NPP Payment Initiation Reason Codes (Australia)", "governing_authority": "NPP Australia Limited", "snapshot": "2026-09-20", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for Payment initiation instruction (pain.001). Its own scope line reads: a payment instruction a corporate, government or third party customer sends its own NPP financial institution, and the status report that answers it. Not the interbank leg..", "from": "applies_to" } ] }, { "uid": "au-npp-reject:DT04", "id": "DT04", "rail": "au-npp-reject", "kind": "reason-code", "name": "Future date not supported", "group": "administrative", "summary": "The instruction asks for a payment on a future date and future dated payments are not supported.", "triggers": [ "The requested execution date is in the future", "A scheduling feature was used that the institution does not support on this rail" ], "actions": [ "Sender: send the instruction on the day the payment is wanted", "Sender: ask the institution whether it supports a requested execution date at all" ], "retry": { "allowed": true, "rule": "Send the instruction on the day the payment should be made." }, "facts": { "return_windows": [ { "action": "payment initiation rejection", "by": "Payer Participant", "deadline": "An institution that accepts customer payment instructions answers them with status reports that acknowledge, reject or confirm settlement, and the authority's guidance says those reports are essential for tracking and reconciling the instructions. It gives no deadline for one. Nothing in the rulebook gives one either, because the scheme does not require the leg at all: the guidance says accepting these instructions and providing these reports is proprietary and at each institution's discretion. So the deadline for a rejection carrying any of the 33 published reason codes is whatever an institution has agreed with its own customer, and no public figure exists." } ], "applies_to": "a payment instruction a corporate, government or third party customer sends its own NPP financial institution, and the status report that answers it. Not the interbank leg." }, "caveat": "Not a mandatory scheme code. The governing authority publishes this list as guidance for the payment instruction a customer sends its own institution, and notes that an institution may offer alternative reason codes, so another Australian institution may use a different value for the same failure or this value for a different one. It is also not the interbank code set: the values a rejected clearing request carries are in the NPP Procedures and are not public. The string is an ISO 20022 externalised code and several values on this list carry Australian or PayTo specific meanings the ISO definition does not give, so never carry a meaning here from another rail's list or from the ISO definition. Whether an institution supports a requested execution date or a requested execution date and time is one of the things the guidance says to confirm with the institution.", "related": [ "au-npp:messages" ], "basis": { "sources": "Listed as an NPP reason code, with the meaning given here in Orca's own words, by the governing authority's own published guidance: NPP Payment Initiation Messages v4.0, Appendix F, read 2026-09-21. No second public source read carries this value. The authority's own note under Appendix F says an NPP financial institution may offer alternative reason codes and that further guidance on how the codes are used comes from that institution, so this record describes an indicative value on a leg the scheme does not mandate, and confidence is capped at medium for that reason and not because of the source's class.", "confidence": "medium" }, "currency": { "effective_since": "2019-11-22", "effective_to": null, "effective_note": "Effective since 2019-11-22, the date the guidance's own document control gives for version 1.0; the appendix has changed across versions and whether this value was in version 1.0 is [Unverified]. Drafted 2026-09-21 from the authority's own published list. The list is indicative: the guidance says an institution's acceptance of customer payment instructions and provision of status reports is proprietary and at its discretion, and that an institution may offer alternative reason codes. No record here may be read as saying an institution must use this value or must use it with this meaning.", "source_edition": "NPP Payment Initiation Messages, technical guidance v4.0 dated 20 November 2025, Appendix F, read 2026-09-21. The governing authority publishes this list as guidance for a leg it does not mandate, and notes under the appendix that an NPP financial institution may offer alternative reason codes. The scheme's own interbank code set is in the NPP Procedures, which are available to members and direct affiliates only and were not consulted.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.auspayplus.com.au/wp-content/uploads/2026/03/NPP-payment-initiation-V4.0.pdf", "source_class": "authoritative_primary", "source_title": "NPP Payment Initiation Messages, technical guidance for corporates, government and third parties, v4.0", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Appendix F gives DT04 the ISO name for future date not supported, described as future dated payments not being supported, matching the record." } ] }, "rail_name": "NPP Payment Initiation Reason Codes (Australia)", "governing_authority": "NPP Australia Limited", "snapshot": "2026-09-20", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for Payment initiation instruction (pain.001). Its own scope line reads: a payment instruction a corporate, government or third party customer sends its own NPP financial institution, and the status report that answers it. Not the interbank leg..", "from": "applies_to" } ] }, { "uid": "au-npp-reject:FF10", "id": "FF10", "rail": "au-npp-reject", "kind": "reason-code", "name": "Bank system processing error", "group": "technical", "summary": "The file or the transaction could not be processed because of a technical problem at the institution.", "triggers": [ "A system at the institution was unavailable or failed while processing", "The instruction was well formed and the institution still could not process it" ], "actions": [ "Sender: try again later; this is not a fault in the instruction", "Sender: ask the institution before resending a file, so a duplicate is not created" ], "retry": { "allowed": true, "rule": "Retry is usually right here, but check with the institution first: resending a whole file can create duplicates, and a duplicate is a payment with the same transaction identifier that is not a replay." }, "facts": { "return_windows": [ { "action": "payment initiation rejection", "by": "Payer Participant", "deadline": "An institution that accepts customer payment instructions answers them with status reports that acknowledge, reject or confirm settlement, and the authority's guidance says those reports are essential for tracking and reconciling the instructions. It gives no deadline for one. Nothing in the rulebook gives one either, because the scheme does not require the leg at all: the guidance says accepting these instructions and providing these reports is proprietary and at each institution's discretion. So the deadline for a rejection carrying any of the 33 published reason codes is whatever an institution has agreed with its own customer, and no public figure exists." } ], "applies_to": "a payment instruction a corporate, government or third party customer sends its own NPP financial institution, and the status report that answers it. Not the interbank leg." }, "caveat": "Not a mandatory scheme code. The governing authority publishes this list as guidance for the payment instruction a customer sends its own institution, and notes that an institution may offer alternative reason codes, so another Australian institution may use a different value for the same failure or this value for a different one. It is also not the interbank code set: the values a rejected clearing request carries are in the NPP Procedures and are not public. The string is an ISO 20022 externalised code and several values on this list carry Australian or PayTo specific meanings the ISO definition does not give, so never carry a meaning here from another rail's list or from the ISO definition.", "related": [ "au-npp:messages" ], "basis": { "sources": "Listed as an NPP reason code, with the meaning given here in Orca's own words, by the governing authority's own published guidance: NPP Payment Initiation Messages v4.0, Appendix F, read 2026-09-21. A second source on a different host, Westpac's public BankRec documentation for the New Payments Platform, read the same day, lists the same value and describes it as a transaction the beneficiary bank could not process, which is the same kind of failure seen from the other side. The authority's own note under Appendix F says an NPP financial institution may offer alternative reason codes and that further guidance on how the codes are used comes from that institution, so this record describes an indicative value on a leg the scheme does not mandate, and confidence is capped at medium for that reason and not because of the source's class.", "confidence": "medium" }, "currency": { "effective_since": "2019-11-22", "effective_to": null, "effective_note": "Effective since 2019-11-22, the date the guidance's own document control gives for version 1.0; the appendix has changed across versions and whether this value was in version 1.0 is [Unverified]. Drafted 2026-09-21 from the authority's own published list. The list is indicative: the guidance says an institution's acceptance of customer payment instructions and provision of status reports is proprietary and at its discretion, and that an institution may offer alternative reason codes. No record here may be read as saying an institution must use this value or must use it with this meaning.", "source_edition": "NPP Payment Initiation Messages, technical guidance v4.0 dated 20 November 2025, Appendix F, read 2026-09-21. The governing authority publishes this list as guidance for a leg it does not mandate, and notes under the appendix that an NPP financial institution may offer alternative reason codes. The scheme's own interbank code set is in the NPP Procedures, which are available to members and direct affiliates only and were not consulted.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.auspayplus.com.au/wp-content/uploads/2026/03/NPP-payment-initiation-V4.0.pdf", "source_class": "authoritative_primary", "source_title": "NPP Payment Initiation Messages, technical guidance for corporates, government and third parties, v4.0", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Appendix F gives FF10 the ISO name for bank system processing error, described as the file or transaction being unable to be processed due to technical issues at the bank side, matching the record." } ] }, "rail_name": "NPP Payment Initiation Reason Codes (Australia)", "governing_authority": "NPP Australia Limited", "snapshot": "2026-09-20", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for Payment initiation instruction (pain.001). Its own scope line reads: a payment instruction a corporate, government or third party customer sends its own NPP financial institution, and the status report that answers it. Not the interbank leg..", "from": "applies_to" } ] }, { "uid": "au-npp-reject:MD01", "id": "MD01", "rail": "au-npp-reject", "kind": "reason-code", "name": "No mandate", "group": "authorization", "summary": "The PayTo agreement identifier is missing from the payment instruction. A payment request under an agreement has to name the agreement.", "triggers": [ "The instruction was built without the agreement identifier", "A PayTo payment was attempted without an agreement behind it" ], "actions": [ "Business: include the agreement identifier the operator's database generated", "Business: check the agreement is active before sending a request against it" ], "retry": { "allowed": true, "rule": "Send the instruction again with the agreement identifier in it." }, "facts": { "return_windows": [ { "action": "payment initiation rejection", "by": "Payer Participant", "deadline": "An institution that accepts customer payment instructions answers them with status reports that acknowledge, reject or confirm settlement, and the authority's guidance says those reports are essential for tracking and reconciling the instructions. It gives no deadline for one. Nothing in the rulebook gives one either, because the scheme does not require the leg at all: the guidance says accepting these instructions and providing these reports is proprietary and at each institution's discretion. So the deadline for a rejection carrying any of the 33 published reason codes is whatever an institution has agreed with its own customer, and no public figure exists." } ], "applies_to": "a payment instruction a corporate, government or third party customer sends its own NPP financial institution, and the status report that answers it. Not the interbank leg." }, "caveat": "Not a mandatory scheme code. The governing authority publishes this list as guidance for the payment instruction a customer sends its own institution, and notes that an institution may offer alternative reason codes, so another Australian institution may use a different value for the same failure or this value for a different one. It is also not the interbank code set: the values a rejected clearing request carries are in the NPP Procedures and are not public. The string is an ISO 20022 externalised code and several values on this list carry Australian or PayTo specific meanings the ISO definition does not give, so never carry a meaning here from another rail's list or from the ISO definition. A PayTo specific meaning. The identifier is generated by the operator's Mandate Management Service, not by either party.", "related": [ "au-npp:messages" ], "basis": { "sources": "Listed as an NPP reason code, with the meaning given here in Orca's own words, by the governing authority's own published guidance: NPP Payment Initiation Messages v4.0, Appendix F, read 2026-09-21. No second public source read carries this value. The authority's own note under Appendix F says an NPP financial institution may offer alternative reason codes and that further guidance on how the codes are used comes from that institution, so this record describes an indicative value on a leg the scheme does not mandate, and confidence is capped at medium for that reason and not because of the source's class.", "confidence": "medium" }, "currency": { "effective_since": "2019-11-22", "effective_to": null, "effective_note": "Effective since 2019-11-22, the date the guidance's own document control gives for version 1.0; the appendix has changed across versions and whether this value was in version 1.0 is [Unverified]. Drafted 2026-09-21 from the authority's own published list. The list is indicative: the guidance says an institution's acceptance of customer payment instructions and provision of status reports is proprietary and at its discretion, and that an institution may offer alternative reason codes. No record here may be read as saying an institution must use this value or must use it with this meaning.", "source_edition": "NPP Payment Initiation Messages, technical guidance v4.0 dated 20 November 2025, Appendix F, read 2026-09-21. The governing authority publishes this list as guidance for a leg it does not mandate, and notes under the appendix that an NPP financial institution may offer alternative reason codes. The scheme's own interbank code set is in the NPP Procedures, which are available to members and direct affiliates only and were not consulted.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.auspayplus.com.au/wp-content/uploads/2026/03/NPP-payment-initiation-V4.0.pdf", "source_class": "authoritative_primary", "source_title": "NPP Payment Initiation Messages, technical guidance for corporates, government and third parties, v4.0", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Appendix F gives MD01 the ISO name for no mandate, described as the PayTo agreement ID being missing in the payment instruction, matching the record." } ] }, "rail_name": "NPP Payment Initiation Reason Codes (Australia)", "governing_authority": "NPP Australia Limited", "snapshot": "2026-09-20", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for Payment initiation instruction (pain.001). Its own scope line reads: a payment instruction a corporate, government or third party customer sends its own NPP financial institution, and the status report that answers it. Not the interbank leg..", "from": "applies_to" } ] }, { "uid": "au-npp-reject:NARR", "id": "NARR", "rail": "au-npp-reject", "kind": "reason-code", "name": "Narrative", "group": "administrative", "summary": "The payment was rejected and the reason is written in free text in the additional information block rather than being carried by a code. The fallback for anything the list does not cover.", "triggers": [ "The institution rejected the payment for a reason none of the other values fits", "The institution chose to explain rather than to code" ], "actions": [ "Sender: read the additional information block; the code itself says nothing", "Sender: do not treat this as a category, because two payments rejected with it can have nothing in common" ], "retry": { "allowed": false, "rule": "Whether to send again depends entirely on what the narrative says." }, "facts": { "return_windows": [ { "action": "payment initiation rejection", "by": "Payer Participant", "deadline": "An institution that accepts customer payment instructions answers them with status reports that acknowledge, reject or confirm settlement, and the authority's guidance says those reports are essential for tracking and reconciling the instructions. It gives no deadline for one. Nothing in the rulebook gives one either, because the scheme does not require the leg at all: the guidance says accepting these instructions and providing these reports is proprietary and at each institution's discretion. So the deadline for a rejection carrying any of the 33 published reason codes is whatever an institution has agreed with its own customer, and no public figure exists." } ], "applies_to": "a payment instruction a corporate, government or third party customer sends its own NPP financial institution, and the status report that answers it. Not the interbank leg." }, "caveat": "Not a mandatory scheme code. The governing authority publishes this list as guidance for the payment instruction a customer sends its own institution, and notes that an institution may offer alternative reason codes, so another Australian institution may use a different value for the same failure or this value for a different one. It is also not the interbank code set: the values a rejected clearing request carries are in the NPP Procedures and are not public. The string is an ISO 20022 externalised code and several values on this list carry Australian or PayTo specific meanings the ISO definition does not give, so never carry a meaning here from another rail's list or from the ISO definition. A value that carries no meaning of its own. Any analysis that counts codes will misread this one.", "related": [ "au-npp:messages" ], "basis": { "sources": "Listed as an NPP reason code, with the meaning given here in Orca's own words, by the governing authority's own published guidance: NPP Payment Initiation Messages v4.0, Appendix F, read 2026-09-21. No second public source read carries this value. The authority's own note under Appendix F says an NPP financial institution may offer alternative reason codes and that further guidance on how the codes are used comes from that institution, so this record describes an indicative value on a leg the scheme does not mandate, and confidence is capped at medium for that reason and not because of the source's class.", "confidence": "medium" }, "currency": { "effective_since": "2019-11-22", "effective_to": null, "effective_note": "Effective since 2019-11-22, the date the guidance's own document control gives for version 1.0; the appendix has changed across versions and whether this value was in version 1.0 is [Unverified]. Drafted 2026-09-21 from the authority's own published list. The list is indicative: the guidance says an institution's acceptance of customer payment instructions and provision of status reports is proprietary and at its discretion, and that an institution may offer alternative reason codes. No record here may be read as saying an institution must use this value or must use it with this meaning.", "source_edition": "NPP Payment Initiation Messages, technical guidance v4.0 dated 20 November 2025, Appendix F, read 2026-09-21. The governing authority publishes this list as guidance for a leg it does not mandate, and notes under the appendix that an NPP financial institution may offer alternative reason codes. The scheme's own interbank code set is in the NPP Procedures, which are available to members and direct affiliates only and were not consulted.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.auspayplus.com.au/wp-content/uploads/2026/03/NPP-payment-initiation-V4.0.pdf", "source_class": "authoritative_primary", "source_title": "NPP Payment Initiation Messages, technical guidance for corporates, government and third parties, v4.0", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Appendix F gives NARR the ISO name for narrative, described as the NPP payment being rejected with the reason carried in the additional information block, matching the record." } ] }, "rail_name": "NPP Payment Initiation Reason Codes (Australia)", "governing_authority": "NPP Australia Limited", "snapshot": "2026-09-20", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for Payment initiation instruction (pain.001). Its own scope line reads: a payment instruction a corporate, government or third party customer sends its own NPP financial institution, and the status report that answers it. Not the interbank leg..", "from": "applies_to" } ] }, { "uid": "au-npp-reject:NAUT", "id": "NAUT", "rail": "au-npp-reject", "kind": "reason-code", "name": "Not authorised", "group": "authorization", "summary": "The contents of a PayTo payment request do not line up with the terms of the agreement. Another PayTo specific meaning, and the broadest of them: where AM06, AM09 and AM21 are about the amount, this one is about the request not matching the agreement in any respect.", "triggers": [ "A payment request asks for something the agreement does not cover", "The frequency, the beneficiary or another term of the request does not match the agreement" ], "actions": [ "Business: send a request that matches the agreement, or send an updated agreement for the payer to authorise", "Payer: check the agreement in their banking app if they were not expecting the request" ], "retry": { "allowed": false, "rule": "The request has to match the agreement. A payment that went through anyway is a mandate claim, and the record in the operator's database is the evidence of what the payer authorised." }, "facts": { "return_windows": [ { "action": "payment initiation rejection", "by": "Payer Participant", "deadline": "An institution that accepts customer payment instructions answers them with status reports that acknowledge, reject or confirm settlement, and the authority's guidance says those reports are essential for tracking and reconciling the instructions. It gives no deadline for one. Nothing in the rulebook gives one either, because the scheme does not require the leg at all: the guidance says accepting these instructions and providing these reports is proprietary and at each institution's discretion. So the deadline for a rejection carrying any of the 33 published reason codes is whatever an institution has agreed with its own customer, and no public figure exists." } ], "applies_to": "a payment instruction a corporate, government or third party customer sends its own NPP financial institution, and the status report that answers it. Not the interbank leg." }, "caveat": "Not a mandatory scheme code. The governing authority publishes this list as guidance for the payment instruction a customer sends its own institution, and notes that an institution may offer alternative reason codes, so another Australian institution may use a different value for the same failure or this value for a different one. It is also not the interbank code set: the values a rejected clearing request carries are in the NPP Procedures and are not public. The string is an ISO 20022 externalised code and several values on this list carry Australian or PayTo specific meanings the ISO definition does not give, so never carry a meaning here from another rail's list or from the ISO definition. A PayTo specific meaning. Read with the mandate claim exception: this is the code for a request the payer's institution caught, and a mandate claim is what happens when one is not caught.", "related": [ "au-npp:messages" ], "basis": { "sources": "Listed as an NPP reason code, with the meaning given here in Orca's own words, by the governing authority's own published guidance: NPP Payment Initiation Messages v4.0, Appendix F, read 2026-09-21. No second public source read carries this value. The authority's own note under Appendix F says an NPP financial institution may offer alternative reason codes and that further guidance on how the codes are used comes from that institution, so this record describes an indicative value on a leg the scheme does not mandate, and confidence is capped at medium for that reason and not because of the source's class.", "confidence": "medium" }, "currency": { "effective_since": "2019-11-22", "effective_to": null, "effective_note": "Effective since 2019-11-22, the date the guidance's own document control gives for version 1.0; the appendix has changed across versions and whether this value was in version 1.0 is [Unverified]. Drafted 2026-09-21 from the authority's own published list. The list is indicative: the guidance says an institution's acceptance of customer payment instructions and provision of status reports is proprietary and at its discretion, and that an institution may offer alternative reason codes. No record here may be read as saying an institution must use this value or must use it with this meaning.", "source_edition": "NPP Payment Initiation Messages, technical guidance v4.0 dated 20 November 2025, Appendix F, read 2026-09-21. The governing authority publishes this list as guidance for a leg it does not mandate, and notes under the appendix that an NPP financial institution may offer alternative reason codes. The scheme's own interbank code set is in the NPP Procedures, which are available to members and direct affiliates only and were not consulted.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.auspayplus.com.au/wp-content/uploads/2026/03/NPP-payment-initiation-V4.0.pdf", "source_class": "authoritative_primary", "source_title": "NPP Payment Initiation Messages, technical guidance for corporates, government and third parties, v4.0", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Appendix F gives NAUT the ISO name for not authorised, described as the PayTo payment request contents not aligning with the agreement terms, matching the record." } ] }, "rail_name": "NPP Payment Initiation Reason Codes (Australia)", "governing_authority": "NPP Australia Limited", "snapshot": "2026-09-20", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for Payment initiation instruction (pain.001). Its own scope line reads: a payment instruction a corporate, government or third party customer sends its own NPP financial institution, and the status report that answers it. Not the interbank leg..", "from": "applies_to" } ] }, { "uid": "au-npp-reject:TD03", "id": "TD03", "rail": "au-npp-reject", "kind": "reason-code", "name": "Incorrect file structure", "group": "technical", "summary": "The file format is incomplete or invalid. The structure is wrong rather than any one field in it.", "triggers": [ "The file was built to the wrong structure or was truncated", "The file does not match the message version the institution supports" ], "actions": [ "Sender: check the file against the message version the institution supports and rebuild it", "Sender: confirm with the institution which message versions it accepts" ], "retry": { "allowed": true, "rule": "Rebuild the file correctly and send it again." }, "facts": { "return_windows": [ { "action": "payment initiation rejection", "by": "Payer Participant", "deadline": "An institution that accepts customer payment instructions answers them with status reports that acknowledge, reject or confirm settlement, and the authority's guidance says those reports are essential for tracking and reconciling the instructions. It gives no deadline for one. Nothing in the rulebook gives one either, because the scheme does not require the leg at all: the guidance says accepting these instructions and providing these reports is proprietary and at each institution's discretion. So the deadline for a rejection carrying any of the 33 published reason codes is whatever an institution has agreed with its own customer, and no public figure exists." } ], "applies_to": "a payment instruction a corporate, government or third party customer sends its own NPP financial institution, and the status report that answers it. Not the interbank leg." }, "caveat": "Not a mandatory scheme code. The governing authority publishes this list as guidance for the payment instruction a customer sends its own institution, and notes that an institution may offer alternative reason codes, so another Australian institution may use a different value for the same failure or this value for a different one. It is also not the interbank code set: the values a rejected clearing request carries are in the NPP Procedures and are not public. The string is an ISO 20022 externalised code and several values on this list carry Australian or PayTo specific meanings the ISO definition does not give, so never carry a meaning here from another rail's list or from the ISO definition.", "related": [ "au-npp:messages" ], "basis": { "sources": "Listed as an NPP reason code, with the meaning given here in Orca's own words, by the governing authority's own published guidance: NPP Payment Initiation Messages v4.0, Appendix F, read 2026-09-21. A second source on a different host, Westpac's public BankRec documentation for the New Payments Platform, read the same day, lists the same value and describes it as an incorrect file structure. The authority's own note under Appendix F says an NPP financial institution may offer alternative reason codes and that further guidance on how the codes are used comes from that institution, so this record describes an indicative value on a leg the scheme does not mandate, and confidence is capped at medium for that reason and not because of the source's class.", "confidence": "medium" }, "currency": { "effective_since": "2019-11-22", "effective_to": null, "effective_note": "Effective since 2019-11-22, the date the guidance's own document control gives for version 1.0; the appendix has changed across versions and whether this value was in version 1.0 is [Unverified]. Drafted 2026-09-21 from the authority's own published list. The list is indicative: the guidance says an institution's acceptance of customer payment instructions and provision of status reports is proprietary and at its discretion, and that an institution may offer alternative reason codes. No record here may be read as saying an institution must use this value or must use it with this meaning.", "source_edition": "NPP Payment Initiation Messages, technical guidance v4.0 dated 20 November 2025, Appendix F, read 2026-09-21. The governing authority publishes this list as guidance for a leg it does not mandate, and notes under the appendix that an NPP financial institution may offer alternative reason codes. The scheme's own interbank code set is in the NPP Procedures, which are available to members and direct affiliates only and were not consulted.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.auspayplus.com.au/wp-content/uploads/2026/03/NPP-payment-initiation-V4.0.pdf", "source_class": "authoritative_primary", "source_title": "NPP Payment Initiation Messages, technical guidance for corporates, government and third parties, v4.0", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Appendix F gives TD03 the ISO name for incorrect file structure, described as the file format being incomplete or invalid, matching the record." } ] }, "rail_name": "NPP Payment Initiation Reason Codes (Australia)", "governing_authority": "NPP Australia Limited", "snapshot": "2026-09-20", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for Payment initiation instruction (pain.001). Its own scope line reads: a payment instruction a corporate, government or third party customer sends its own NPP financial institution, and the status report that answers it. Not the interbank leg..", "from": "applies_to" } ] }, { "uid": "ca-acss:900", "id": "900", "rail": "ca-acss", "kind": "reason-code", "name": "Rejected at the item edit, before posting", "group": "technical", "summary": "Not a decision about the account or the customer. The receiving direct clearer's edit of the individual transaction found data that does not pass Standard 005, the ISO AFT Usage Guidelines or the Financial Institutions File, so the item goes back unposted. Standard 007 keeps this code for edit rejects and for nothing else.", "triggers": [ "An institution and branch number the edit cannot match to the Financial Institutions File (Rule F1, definition of Transaction Edit)", "An account number that fails the account format and validation criteria the receiving institution has published (Rule F1, 'Transaction Edit, Account Validation and Rejected Transactions' (b))", "A credit whose due date is more than 30 calendar days before the file creation date, which must be rejected; a debit dated more than 173 calendar days back may be (same heading, (d))", "A field that must hold zeros on first presentation, such as the invalid data element or stored transaction type, carries data (Standard 005, Section D data element dictionary)" ], "actions": [ "Read the invalid data element field on the rejected record: it holds up to five two-digit markers naming the fields that failed, plus an overflow flag (Standard 005, 'Invalid Data Element Identification')", "Fix the data and send the payment again as a new transaction. A rejected item cannot be resent as itself (Rule F1, 'Resubmission of Rejected Transactions')", "Expect a warning when many items fail: once a file has 50 or more rejects the receiving direct clearer must tell the sender at once (Rule F1, 'Transaction Edit, Account Validation and Rejected Transactions' (c)(ii))", "If the reject was on account format, compare the number against the receiving institution's entry in Payments Canada's list of account number formats and validation criteria [Inference: the list itself was not read]" ], "retry": { "allowed": true, "rule": "Only as a new transaction with the data corrected (Rule F1, 'Resubmission of Rejected Transactions'). The one-time, 30 day limit on re-presenting 901 and 908 does not apply, because nothing was dishonoured. A rejected return item or a rejected error correction is a different case: neither may be resubmitted (Rule F1, 'Re-presentment and Rejected Returned Transactions' and 'Rejected Error Correction Transactions')." }, "facts": { "return_windows": [ { "action": "reject", "by": "receiving direct clearer, after its transaction edit", "deadline": "no later than the Business Day after the original AFT file was edited" } ], "applies_to": "any AFT credit or debit, return or error correction that fails the transaction edit" }, "caveat": "900 is a reject, not a return: Standard 005 carries returns under codes above 900 and keeps 900 for edit rejects. A whole file that fails the initial file edit is a different event. It is not settled at all, and the sender hears within an hour of the exchange deadline (or before the next morning's first deadline for the evening period), with no per-item code (Rule F1, 'AFT Initial File Edit and Rejected Files'; s.40(b)). Rejected items, by contrast, are settled like any other item (Rule F1 s.40(c)).", "related": [ "ca-acss:912", "ca-acss:902" ], "basis": { "sources": "Standard 007 para 5 (code 900 for edit rejects only), para 6 and Appendix I; Rule F1 Part II, headings 'AFT Initial File Edit and Rejected Files', 'Transaction Edit, Account Validation and Rejected Transactions' and 'Resubmission of Rejected Transactions', and Part V s.40(b) and (c); Rule F1 definitions of Transaction Edit and Rejected Transaction; Standard 005 Section D data element dictionary entries Transaction Type, Invalid Data Element Identification and Stored Transaction Type. Payments Canada PDFs read 2026-09-18.", "confidence": "high" }, "currency": { "effective_since": "2016-04-18", "effective_note": "Standard 007 took effect 2016-04-18, when the code list moved out of Standard 005 (Standard 005 amendment list, item 21); the code itself is older and its first effective date is [Unverified]. Amendment 10 to Standard 007, in force 2026-07-03, changed one transaction code description and no return reason code.", "source_edition": "Payments Canada Standard 007 with amendment 10 (in force 2026-07-03); Rule F1 and Rule H1 as amended in force 2026-07-27; Rule F4 as amended in force 2026-07-27; Standard 005 as amended in force 2024-07-22", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.payments.ca/sites/default/files/standard007eng.pdf", "source_class": "authoritative_primary", "source_title": "Payments Canada Standard 007, Standards for the Use of Transaction Codes and Return Reason Codes in AFT Files, amendment 10, in force 2026-07-03", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms Standard 007 paragraph 5 states code 900 is used only for payments returned for edit rejects, and Appendix I lists 900 in the Returned Item Reasons category 900 to 999 with the label Edit Reject. Does not address the return window or retry rule." }, { "source_url": "https://www.payments.ca/sites/default/files/f1eng.pdf", "source_class": "authoritative_primary", "source_title": "Payments Canada Rule F1, Rules Applicable to Automated Funds Transfer (AFT) Transactions, as amended, in force 2026-07-27", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms rejected AFT transactions must be delivered back to the originating direct clearer no later than the Business Day following editing of the original AFT file, that a rejected transaction bears a 900 transaction type, that a file with 50 or more rejected transactions triggers immediate notice to the originating direct clearer, that a credit transaction due more than 30 calendar days before the file creation date must be rejected and a debit transaction due more than 173 calendar days before may be rejected, and that a rejected transaction may only be resubmitted by the originating direct clearer as a new transaction. Does not address the invalid data element field format, which rests on Standard 005." }, { "source_url": "https://www.payments.ca/sites/default/files/standard005eng.pdf", "source_class": "authoritative_primary", "source_title": "Payments Canada Standard 005, Standards for the Exchange of Financial Data on AFT Files, as amended, in force 2024-07-22", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the Invalid Data Element Identification field is an 11 position numeric element divided into five two character sections plus a final overflow indicator position, used on a rejected transaction returned with a 900 series code to record up to five invalid data elements, with the overflow indicator set to 1 when there are more than five errors, and that the field must be zero on initial presentation with any other value causing rejection. Does not address the return window." } ] }, "rail_name": "Canada ACSS (Automated Funds Transfer)", "governing_authority": "Payments Canada", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "ca-acss:901", "id": "901", "rail": "ca-acss", "kind": "reason-code", "name": "Not enough money in the payor's account", "group": "funds", "summary": "The payor's institution would not pay a pre-authorized debit because the balance could not cover it. The account is there and open; the money was not. Debits only: Standard 007 never uses this code for a credit.", "triggers": [ "The debit's due date fell before the payor's own pay or benefit deposit arrived [Inference]", "Other debits or cheques drew the balance down on the same day [Inference]", "A variable amount PAD came in higher than the payor had planned for [Inference]" ], "actions": [ "You may present the same debit one more time, within 30 calendar days of the return, for exactly the original amount (Rule F1 s.22; Rule H1 s.22(c))", "Do not fold a returned item fee into the re-presented debit; the rules forbid added charges on it (Rule H1 s.22(c)). [Inference] Any fee the payee's terms allow has to be collected some other way", "If the debit comes back unpaid a second time, stop: a second dishonour ends re-presentment through the clearing (Rule F1 s.22)", "Where the payor's pay cycle is the cause, move the PAD date. On a recurring Personal or Business PAD, a date change needs Pre-notification at least 10 calendar days ahead unless the agreement waived or shortened it (Rule H1 s.17 and s.19)" ], "retry": { "allowed": true, "rule": "Once only, within 30 calendar days after the original debit was returned, for the same amount and with no added charges (Rule F1 s.22; Rule F4, 'Re-presentment and Rejected Returned ISO Transactions'; Rule H1 s.22(c)). If it is dishonoured again it may not be re-presented." }, "facts": { "return_windows": [ { "action": "return", "by": "payor's institution", "deadline": "no later than the Business Day after the first unit able to decide to dishonour or refuse it received the item" } ], "applies_to": "AFT debits (pre-authorized debits) only" }, "caveat": "Re-presentment on this rail is a single further attempt inside 30 calendar days. The code says nothing about whether the account will stay open or usable; 905 and 911 cover those cases.", "related": [ "ca-acss:908", "ca-acss:905", "ca-acss:911" ], "basis": { "sources": "Standard 007 paras 5 and 6 and Appendix I (return reason code list, category 900 to 914); Rule F1 Part III, 'Time Limitation for Return' and 'Unposted/Dishonoured Transactions/Transactions Refused by Payor/Payee', and s.22 on re-presentment; Rule F4 Part III, same headings; Rule H1 s.22(a) and (c). Payments Canada PDFs read 2026-09-18. Rule H1 ss.17 and 19 on Pre-notification of a date change.", "confidence": "high" }, "currency": { "effective_since": "2016-04-18", "effective_note": "Standard 007 took effect 2016-04-18, when the code list moved out of Standard 005 (Standard 005 amendment list, item 21); the code itself is older and its first effective date is [Unverified]. Amendment 10 to Standard 007, in force 2026-07-03, changed one transaction code description and no return reason code.", "source_edition": "Payments Canada Standard 007 with amendment 10 (in force 2026-07-03); Rule F1 and Rule H1 as amended in force 2026-07-27; Rule F4 as amended in force 2026-07-27; Standard 005 as amended in force 2024-07-22", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.payments.ca/sites/default/files/standard007eng.pdf", "source_class": "authoritative_primary", "source_title": "Payments Canada Standard 007, Standards for the Use of Transaction Codes and Return Reason Codes in AFT Files, amendment 10, in force 2026-07-03", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms Appendix I lists return reason code 901 as NSF, marked Debit Only, in the FI Dishonoured Transaction category 900 to 914. Does not address the return window or retry rule." }, { "source_url": "https://www.payments.ca/sites/default/files/f1eng.pdf", "source_class": "authoritative_primary", "source_title": "Payments Canada Rule F1, Rules Applicable to Automated Funds Transfer (AFT) Transactions, as amended, in force 2026-07-27", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms a debit or credit transaction being dishonoured or refused must be returned no later than the Business Day following receipt by the first organizational unit able to act on the decision, and that a debit returned for Non-Sufficient Funds under code 901 or Funds Not Cleared under code 908 may be re-presented once, within 30 calendar days of the return, for the same amount with no added charges, and may not be re-presented again if dishonoured a second time. Does not address why a particular debit was dishonoured." } ] }, "rail_name": "Canada ACSS (Automated Funds Transfer)", "governing_authority": "Payments Canada", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "ca-acss:902", "id": "902", "rail": "ca-acss", "kind": "reason-code", "name": "No account matches the number given", "group": "account", "summary": "The receiving institution has no account under the number on the item at that branch, so it cannot post the credit or the debit. [Inference] Where 912 says the number itself is wrong or invalid, this code says a well formed number leads nowhere.", "triggers": [ "The payor or payee gave the branch or institution of a different account [Inference]", "Digits were transposed in a way that still passes the format check [Inference]", "The account was moved and the payment originator's file still holds the old details [Inference]" ], "actions": [ "Get the account details again from the payor or payee, in writing, before sending anything further [Inference]", "For a PAD, the new details need the payor's authority. A Notice of Change from the payor's institution counts as that authority only for an administrative change that does not move the payor to another institution (Rule H1 s.8(c))", "For a credit, the payee has not been paid. [Inference] Whatever you owe the payee is still owed until a corrected payment lands" ], "retry": { "allowed": false, "rule": "The rules allow re-presentment only after 901 or 908 (Rule F1 s.22; Rule F4, 'Re-presentment and Rejected Returned ISO Transactions'). [Inference] Once the underlying problem is fixed, a fresh item goes as a new transaction, and for a PAD it still needs a valid agreement and any Pre-notification that agreement requires." }, "facts": { "return_windows": [ { "action": "return", "by": "institution the item was addressed to", "deadline": "no later than the Business Day after the first unit able to decide to dishonour or refuse it received the item" } ], "applies_to": "AFT credits and debits" }, "caveat": null, "related": [ "ca-acss:912", "ca-acss:905", "ca-acss:914" ], "basis": { "sources": "Standard 007 paras 5 and 6 and Appendix I (return reason code list, category 900 to 914); Rule F1 Part III, 'Time Limitation for Return' and 'Unposted/Dishonoured Transactions/Transactions Refused by Payor/Payee', and s.22 on re-presentment; Rule F4 Part III, same headings; Rule H1 s.22(a) and (c). Payments Canada PDFs read 2026-09-18. Rule H1 s.8(c) on Notices of Change.", "confidence": "medium" }, "currency": { "effective_since": "2016-04-18", "effective_note": "Standard 007 took effect 2016-04-18, when the code list moved out of Standard 005 (Standard 005 amendment list, item 21); the code itself is older and its first effective date is [Unverified]. Amendment 10 to Standard 007, in force 2026-07-03, changed one transaction code description and no return reason code.", "source_edition": "Payments Canada Standard 007 with amendment 10 (in force 2026-07-03); Rule F1 and Rule H1 as amended in force 2026-07-27; Rule F4 as amended in force 2026-07-27; Standard 005 as amended in force 2024-07-22", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.payments.ca/sites/default/files/standard007eng.pdf", "source_class": "authoritative_primary", "source_title": "Payments Canada Standard 007, Standards for the Use of Transaction Codes and Return Reason Codes in AFT Files, amendment 10, in force 2026-07-03", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms Appendix I lists return reason code 902 as Account not found, in the FI Dishonoured Transaction category 900 to 914. Does not address the return window." }, { "source_url": "https://www.payments.ca/sites/default/files/f1eng.pdf", "source_class": "authoritative_primary", "source_title": "Payments Canada Rule F1, Rules Applicable to Automated Funds Transfer (AFT) Transactions, as amended, in force 2026-07-27", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms a debit or credit transaction being dishonoured or refused must be returned no later than the Business Day following receipt by the first organizational unit able to act on the decision. Does not address the account-not-found scenario specifically or Notice of Change procedures, which rest on Rule H1." } ] }, "rail_name": "Canada ACSS (Automated Funds Transfer)", "governing_authority": "Payments Canada", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "ca-acss:903", "id": "903", "rail": "ca-acss", "kind": "reason-code", "name": "Stop placed on the payment", "group": "authorization", "summary": "The account holder's institution has an instruction not to pay this item and returns it. For a pre-authorized debit this is typically the payor stopping it through their own institution [Inference]. The code's label also covers a recall, which none of the rules read defines for AFT [Unverified].", "triggers": [ "The payor asked their institution to stop a particular PAD, or every PAD from this payee [Inference]", "The payor cancelled the PAD agreement with the payee and also told their institution to block further debits [Inference]" ], "actions": [ "Treat the stop as withdrawn consent for this debit and speak to the payor before sending another [Inference]", "If the payor has revoked the agreement, you must cease new PADs no later than 30 calendar days after the notice, or at the end of a shorter cancellation period the agreement sets, and may not debit again without a new agreement (Rule H1 s.30)", "Do not re-present: only 901 and 908 allow that (Rule F1 s.22)" ], "retry": { "allowed": false, "rule": "The rules allow re-presentment only after 901 or 908 (Rule F1 s.22; Rule F4, 'Re-presentment and Rejected Returned ISO Transactions'). [Inference] Once the underlying problem is fixed, a fresh item goes as a new transaction, and for a PAD it still needs a valid agreement and any Pre-notification that agreement requires." }, "facts": { "return_windows": [ { "action": "return", "by": "account holder's institution", "deadline": "no later than the Business Day after the first unit able to decide to dishonour or refuse it received the item" } ], "applies_to": "AFT debits in the ordinary case; the label is not limited to debits and use on credits is [Unverified]" }, "caveat": "[Inference] A stop acts on the debit before or as it posts, as an institution dishonour. A payor who wants money back after a debit posted makes a Rule H1 claim instead, and that return carries one of 915 to 921. Standard 007 para 6 puts the two in different categories.", "related": [ "ca-acss:917", "ca-acss:920", "ca-acss:915" ], "basis": { "sources": "Standard 007 paras 5 and 6 and Appendix I (return reason code list, category 900 to 914); Rule F1 Part III, 'Time Limitation for Return' and 'Unposted/Dishonoured Transactions/Transactions Refused by Payor/Payee', and s.22 on re-presentment; Rule F4 Part III, same headings; Rule H1 s.22(a) and (c). Payments Canada PDFs read 2026-09-18. Rule H1 s.30 on revocation.", "confidence": "medium" }, "currency": { "effective_since": "2016-04-18", "effective_note": "Standard 007 took effect 2016-04-18, when the code list moved out of Standard 005 (Standard 005 amendment list, item 21); the code itself is older and its first effective date is [Unverified]. Amendment 10 to Standard 007, in force 2026-07-03, changed one transaction code description and no return reason code.", "source_edition": "Payments Canada Standard 007 with amendment 10 (in force 2026-07-03); Rule F1 and Rule H1 as amended in force 2026-07-27; Rule F4 as amended in force 2026-07-27; Standard 005 as amended in force 2024-07-22", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.payments.ca/sites/default/files/standard007eng.pdf", "source_class": "authoritative_primary", "source_title": "Payments Canada Standard 007, Standards for the Use of Transaction Codes and Return Reason Codes in AFT Files, amendment 10, in force 2026-07-03", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms Appendix I lists return reason code 903 as Payment Stopped/Recalled, in the FI Dishonoured Transaction category 900 to 914, with a single label covering both a stop and a recall and no separate definition of either term. Does not address the return window." }, { "source_url": "https://www.payments.ca/sites/default/files/f1eng.pdf", "source_class": "authoritative_primary", "source_title": "Payments Canada Rule F1, Rules Applicable to Automated Funds Transfer (AFT) Transactions, as amended, in force 2026-07-27", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the general return window is the Business Day following receipt by the first organizational unit able to act on the decision, and that re-presentment is allowed only after codes 901 and 908. Does not address the payor's stop instruction or agreement revocation, which rest on Rule H1." } ] }, "rail_name": "Canada ACSS (Automated Funds Transfer)", "governing_authority": "Payments Canada", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "ca-acss:905", "id": "905", "rail": "ca-acss", "kind": "reason-code", "name": "Account no longer open", "group": "account", "summary": "The item was addressed to an account that has been closed, so the institution cannot post it. The number was right once; it no longer leads to a live account.", "triggers": [ "The payor or payee moved their banking and closed the old account [Inference]", "The institution closed the account [Inference]" ], "actions": [ "Ask the payor or payee for the account that replaced it [Inference]", "For a PAD, debiting a different account needs the payor's authorization naming that account; the agreement's authority covers an account the payor specified (Rule H1 Appendix II, mandatory element on authority to debit an account)", "Do not wait for a Notice of Change when the payor has moved to another institution. The Notice of Change route covers administrative changes at the same institution only (Rule H1 s.8(c))" ], "retry": { "allowed": false, "rule": "The rules allow re-presentment only after 901 or 908 (Rule F1 s.22; Rule F4, 'Re-presentment and Rejected Returned ISO Transactions'). [Inference] Once the underlying problem is fixed, a fresh item goes as a new transaction, and for a PAD it still needs a valid agreement and any Pre-notification that agreement requires." }, "facts": { "return_windows": [ { "action": "return", "by": "institution the item was addressed to", "deadline": "no later than the Business Day after the first unit able to decide to dishonour or refuse it received the item" } ], "applies_to": "AFT credits and debits" }, "caveat": null, "related": [ "ca-acss:902", "ca-acss:911", "ca-acss:901" ], "basis": { "sources": "Standard 007 paras 5 and 6 and Appendix I (return reason code list, category 900 to 914); Rule F1 Part III, 'Time Limitation for Return' and 'Unposted/Dishonoured Transactions/Transactions Refused by Payor/Payee', and s.22 on re-presentment; Rule F4 Part III, same headings; Rule H1 s.22(a) and (c). Payments Canada PDFs read 2026-09-18. Rule H1 s.8(c) and Appendix II.", "confidence": "medium" }, "currency": { "effective_since": "2016-04-18", "effective_note": "Standard 007 took effect 2016-04-18, when the code list moved out of Standard 005 (Standard 005 amendment list, item 21); the code itself is older and its first effective date is [Unverified]. Amendment 10 to Standard 007, in force 2026-07-03, changed one transaction code description and no return reason code.", "source_edition": "Payments Canada Standard 007 with amendment 10 (in force 2026-07-03); Rule F1 and Rule H1 as amended in force 2026-07-27; Rule F4 as amended in force 2026-07-27; Standard 005 as amended in force 2024-07-22", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.payments.ca/sites/default/files/standard007eng.pdf", "source_class": "authoritative_primary", "source_title": "Payments Canada Standard 007, Standards for the Use of Transaction Codes and Return Reason Codes in AFT Files, amendment 10, in force 2026-07-03", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms Appendix I lists return reason code 905 as Account Closed, in the FI Dishonoured Transaction category 900 to 914. Does not address the return window." }, { "source_url": "https://www.payments.ca/sites/default/files/f1eng.pdf", "source_class": "authoritative_primary", "source_title": "Payments Canada Rule F1, Rules Applicable to Automated Funds Transfer (AFT) Transactions, as amended, in force 2026-07-27", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the general return window is the Business Day following receipt by the first organizational unit able to act on the decision. Does not address Notice of Change procedures for a closed account, which rest on Rule H1." } ] }, "rail_name": "Canada ACSS (Automated Funds Transfer)", "governing_authority": "Payments Canada", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "ca-acss:907", "id": "907", "rail": "ca-acss", "kind": "reason-code", "name": "Account does not accept debits", "group": "account", "summary": "The account exists and is open, but it is set up so that a pre-authorized debit cannot be drawn on it. [Inference] Common where an account type only takes deposits.", "triggers": [ "The payor gave the details of a savings, registered or term account that does not allow debits [Inference]", "The institution restricted the account to credits only [Inference]" ], "actions": [ "Ask the payor for an account that accepts pre-authorized debits, with a new or amended PAD agreement naming it (Rule H1 Appendix II, mandatory element on authority to debit an account)", "Do not re-present: only 901 and 908 allow that (Rule F1 s.22)" ], "retry": { "allowed": false, "rule": "The rules allow re-presentment only after 901 or 908 (Rule F1 s.22; Rule F4, 'Re-presentment and Rejected Returned ISO Transactions'). [Inference] Once the underlying problem is fixed, a fresh item goes as a new transaction, and for a PAD it still needs a valid agreement and any Pre-notification that agreement requires." }, "facts": { "return_windows": [ { "action": "return", "by": "payor's institution", "deadline": "no later than the Business Day after the first unit able to decide to dishonour or refuse it received the item" } ], "applies_to": "AFT debits [Inference from the code label; Standard 007 does not mark it debit-only as it does 901 and 908]" }, "caveat": null, "related": [ "ca-acss:905", "ca-acss:911" ], "basis": { "sources": "Standard 007 paras 5 and 6 and Appendix I (return reason code list, category 900 to 914); Rule F1 Part III, 'Time Limitation for Return' and 'Unposted/Dishonoured Transactions/Transactions Refused by Payor/Payee', and s.22 on re-presentment; Rule F4 Part III, same headings; Rule H1 s.22(a) and (c). Payments Canada PDFs read 2026-09-18. Rule H1 Appendix II.", "confidence": "medium" }, "currency": { "effective_since": "2016-04-18", "effective_note": "Standard 007 took effect 2016-04-18, when the code list moved out of Standard 005 (Standard 005 amendment list, item 21); the code itself is older and its first effective date is [Unverified]. Amendment 10 to Standard 007, in force 2026-07-03, changed one transaction code description and no return reason code.", "source_edition": "Payments Canada Standard 007 with amendment 10 (in force 2026-07-03); Rule F1 and Rule H1 as amended in force 2026-07-27; Rule F4 as amended in force 2026-07-27; Standard 005 as amended in force 2024-07-22", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.payments.ca/sites/default/files/standard007eng.pdf", "source_class": "authoritative_primary", "source_title": "Payments Canada Standard 007, Standards for the Use of Transaction Codes and Return Reason Codes in AFT Files, amendment 10, in force 2026-07-03", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms Appendix I lists return reason code 907 as No Debit Allowed, in the FI Dishonoured Transaction category 900 to 914. The label itself does not state the code is limited to debits, unlike 901 and 908 which are marked Debit Only." }, { "source_url": "https://www.payments.ca/sites/default/files/f1eng.pdf", "source_class": "authoritative_primary", "source_title": "Payments Canada Rule F1, Rules Applicable to Automated Funds Transfer (AFT) Transactions, as amended, in force 2026-07-27", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the general return window is the Business Day following receipt by the first organizational unit able to act on the decision, and that re-presentment is allowed only after codes 901 and 908. Does not address account restrictions on debiting." } ] }, "rail_name": "Canada ACSS (Automated Funds Transfer)", "governing_authority": "Payments Canada", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "ca-acss:908", "id": "908", "rail": "ca-acss", "kind": "reason-code", "name": "Deposited funds still on hold", "group": "funds", "summary": "The payor has money in the account, but not enough of it has cleared to cover the pre-authorized debit. Debits only. [Inference] The usual cause is a recent deposit still inside its hold period.", "triggers": [ "A cheque or other deposit the payor made is still on hold [Inference]", "The payor deposited funds the same day the debit was presented [Inference]" ], "actions": [ "You may present the same debit one more time, within 30 calendar days of the return, for exactly the original amount and with no added charges (Rule F1 s.22; Rule H1 s.22(c))", "[Inference] Re-presenting a few Business Days later rather than at once gives the held deposit time to clear", "If the debit is dishonoured a second time, stop: no further re-presentment is allowed (Rule F1 s.22)" ], "retry": { "allowed": true, "rule": "Once only, within 30 calendar days after the original debit was returned, for the same amount and with no added charges (Rule F1 s.22; Rule F4, 'Re-presentment and Rejected Returned ISO Transactions'; Rule H1 s.22(c)). If it is dishonoured again it may not be re-presented." }, "facts": { "return_windows": [ { "action": "return", "by": "payor's institution", "deadline": "no later than the Business Day after the first unit able to decide to dishonour or refuse it received the item" } ], "applies_to": "AFT debits (pre-authorized debits) only" }, "caveat": "901 and 908 are the only two codes after which the rules allow a re-presentment, and the same single attempt covers both.", "related": [ "ca-acss:901" ], "basis": { "sources": "Standard 007 paras 5 and 6 and Appendix I (return reason code list, category 900 to 914); Rule F1 Part III, 'Time Limitation for Return' and 'Unposted/Dishonoured Transactions/Transactions Refused by Payor/Payee', and s.22 on re-presentment; Rule F4 Part III, same headings; Rule H1 s.22(a) and (c). Payments Canada PDFs read 2026-09-18.", "confidence": "high" }, "currency": { "effective_since": "2016-04-18", "effective_note": "Standard 007 took effect 2016-04-18, when the code list moved out of Standard 005 (Standard 005 amendment list, item 21); the code itself is older and its first effective date is [Unverified]. Amendment 10 to Standard 007, in force 2026-07-03, changed one transaction code description and no return reason code.", "source_edition": "Payments Canada Standard 007 with amendment 10 (in force 2026-07-03); Rule F1 and Rule H1 as amended in force 2026-07-27; Rule F4 as amended in force 2026-07-27; Standard 005 as amended in force 2024-07-22", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.payments.ca/sites/default/files/standard007eng.pdf", "source_class": "authoritative_primary", "source_title": "Payments Canada Standard 007, Standards for the Use of Transaction Codes and Return Reason Codes in AFT Files, amendment 10, in force 2026-07-03", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms Appendix I lists return reason code 908 as Funds Not Cleared, marked Debit Only, in the FI Dishonoured Transaction category 900 to 914. Does not address the return window or retry rule." }, { "source_url": "https://www.payments.ca/sites/default/files/f1eng.pdf", "source_class": "authoritative_primary", "source_title": "Payments Canada Rule F1, Rules Applicable to Automated Funds Transfer (AFT) Transactions, as amended, in force 2026-07-27", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms a debit returned for Non-Sufficient Funds under code 901 or Funds Not Cleared under code 908 may be re-presented once, within 30 calendar days of the return, for the same amount with no added charges, may not be re-presented again if dishonoured a second time, and that the general return window is the Business Day following receipt by the first organizational unit able to act on the decision." } ] }, "rail_name": "Canada ACSS (Automated Funds Transfer)", "governing_authority": "Payments Canada", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "ca-acss:909", "id": "909", "rail": "ca-acss", "kind": "reason-code", "name": "Item currency differs from the account's currency", "group": "account", "summary": "The item is in one currency and the account it names is held in another, so the institution will not post it. [Inference] The usual case is a Canadian dollar item aimed at a US dollar account held at a Canadian institution.", "triggers": [ "The payor or payee gave the number of a US dollar account for a Canadian dollar payment [Inference]" ], "actions": [ "Ask for an account held in the currency of the payment [Inference]", "US dollar AFT between Canadian institutions runs under Rule K8 and the US Bulk Exchange, outside this rail's scope (Rule F1, Scope) [Unverified: Rule K8 not read]" ], "retry": { "allowed": false, "rule": "The rules allow re-presentment only after 901 or 908 (Rule F1 s.22; Rule F4, 'Re-presentment and Rejected Returned ISO Transactions'). [Inference] Once the underlying problem is fixed, a fresh item goes as a new transaction, and for a PAD it still needs a valid agreement and any Pre-notification that agreement requires." }, "facts": { "return_windows": [ { "action": "return", "by": "institution the item was addressed to", "deadline": "no later than the Business Day after the first unit able to decide to dishonour or refuse it received the item" } ], "applies_to": "AFT credits and debits" }, "caveat": null, "related": [ "ca-acss:902", "ca-acss:912" ], "basis": { "sources": "Standard 007 paras 5 and 6 and Appendix I (return reason code list, category 900 to 914); Rule F1 Part III, 'Time Limitation for Return' and 'Unposted/Dishonoured Transactions/Transactions Refused by Payor/Payee', and s.22 on re-presentment; Rule F4 Part III, same headings; Rule H1 s.22(a) and (c). Payments Canada PDFs read 2026-09-18. Rule F1 Scope.", "confidence": "medium" }, "currency": { "effective_since": "2016-04-18", "effective_note": "Standard 007 took effect 2016-04-18, when the code list moved out of Standard 005 (Standard 005 amendment list, item 21); the code itself is older and its first effective date is [Unverified]. Amendment 10 to Standard 007, in force 2026-07-03, changed one transaction code description and no return reason code.", "source_edition": "Payments Canada Standard 007 with amendment 10 (in force 2026-07-03); Rule F1 and Rule H1 as amended in force 2026-07-27; Rule F4 as amended in force 2026-07-27; Standard 005 as amended in force 2024-07-22", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.payments.ca/sites/default/files/standard007eng.pdf", "source_class": "authoritative_primary", "source_title": "Payments Canada Standard 007, Standards for the Use of Transaction Codes and Return Reason Codes in AFT Files, amendment 10, in force 2026-07-03", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms Appendix I lists return reason code 909 as Currency/Account Mismatch, in the FI Dishonoured Transaction category 900 to 914. Does not address the return window." }, { "source_url": "https://www.payments.ca/sites/default/files/f1eng.pdf", "source_class": "authoritative_primary", "source_title": "Payments Canada Rule F1, Rules Applicable to Automated Funds Transfer (AFT) Transactions, as amended, in force 2026-07-27", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the general return window is the Business Day following receipt by the first organizational unit able to act on the decision. Does not address US dollar AFT arrangements under Rule K8, which were not read." } ] }, "rail_name": "Canada ACSS (Automated Funds Transfer)", "governing_authority": "Payments Canada", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "ca-acss:910", "id": "910", "rail": "ca-acss", "kind": "reason-code", "name": "Account holder has died", "group": "account", "summary": "The institution knows the payor or payee has died and returns the item instead of posting it. For a credit such as a pension, the payment stops reaching the account; for a PAD, the debit is not paid.", "triggers": [ "The institution was told of the death and has changed how the account may be used [Inference]" ], "actions": [ "Stop further payments or debits to this person's account and deal with the estate or its representative [Inference]", "For recurring PADs, [Inference] the agreement was given by the payor personally, so a new agreement from whoever now controls the account is needed before any further debit (Rule H1 s.15(a)(i))" ], "retry": { "allowed": false, "rule": "The rules allow re-presentment only after 901 or 908 (Rule F1 s.22; Rule F4, 'Re-presentment and Rejected Returned ISO Transactions'). [Inference] Once the underlying problem is fixed, a fresh item goes as a new transaction, and for a PAD it still needs a valid agreement and any Pre-notification that agreement requires." }, "facts": { "return_windows": [ { "action": "return", "by": "institution the item was addressed to", "deadline": "no later than the Business Day after the first unit able to decide to dishonour or refuse it received the item" } ], "applies_to": "AFT credits and debits" }, "caveat": "Government payers may have their own arrangements for recovering payments made after a death. Those arrangements were not read and are not asserted here [Unverified].", "related": [ "ca-acss:911", "ca-acss:905" ], "basis": { "sources": "Standard 007 paras 5 and 6 and Appendix I (return reason code list, category 900 to 914); Rule F1 Part III, 'Time Limitation for Return' and 'Unposted/Dishonoured Transactions/Transactions Refused by Payor/Payee', and s.22 on re-presentment; Rule F4 Part III, same headings; Rule H1 s.22(a) and (c). Payments Canada PDFs read 2026-09-18. Rule H1 s.15(a)(i).", "confidence": "medium" }, "currency": { "effective_since": "2016-04-18", "effective_note": "Standard 007 took effect 2016-04-18, when the code list moved out of Standard 005 (Standard 005 amendment list, item 21); the code itself is older and its first effective date is [Unverified]. Amendment 10 to Standard 007, in force 2026-07-03, changed one transaction code description and no return reason code.", "source_edition": "Payments Canada Standard 007 with amendment 10 (in force 2026-07-03); Rule F1 and Rule H1 as amended in force 2026-07-27; Rule F4 as amended in force 2026-07-27; Standard 005 as amended in force 2024-07-22", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.payments.ca/sites/default/files/standard007eng.pdf", "source_class": "authoritative_primary", "source_title": "Payments Canada Standard 007, Standards for the Use of Transaction Codes and Return Reason Codes in AFT Files, amendment 10, in force 2026-07-03", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms Appendix I lists return reason code 910 as Payor/Payee Deceased, in the FI Dishonoured Transaction category 900 to 914. Does not address the return window." }, { "source_url": "https://www.payments.ca/sites/default/files/f1eng.pdf", "source_class": "authoritative_primary", "source_title": "Payments Canada Rule F1, Rules Applicable to Automated Funds Transfer (AFT) Transactions, as amended, in force 2026-07-27", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the general return window is the Business Day following receipt by the first organizational unit able to act on the decision. Does not address government payer recovery procedures after a death, which were not read." } ] }, "rail_name": "Canada ACSS (Automated Funds Transfer)", "governing_authority": "Payments Canada", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "ca-acss:911", "id": "911", "rail": "ca-acss", "kind": "reason-code", "name": "Account is blocked from activity", "group": "account", "summary": "The account is open, but a hold or restriction stops items being posted to it. [Inference] The block may come from the institution itself, a court order or another authority.", "triggers": [ "The institution froze the account over suspected fraud or a dispute [Inference]", "A garnishment, court order or legal hold restricts the account [Inference]" ], "actions": [ "Contact the payor or payee to learn whether the block is temporary [Inference]", "Do not re-present: only 901 and 908 allow that (Rule F1 s.22)" ], "retry": { "allowed": false, "rule": "The rules allow re-presentment only after 901 or 908 (Rule F1 s.22; Rule F4, 'Re-presentment and Rejected Returned ISO Transactions'). [Inference] Once the underlying problem is fixed, a fresh item goes as a new transaction, and for a PAD it still needs a valid agreement and any Pre-notification that agreement requires." }, "facts": { "return_windows": [ { "action": "return", "by": "institution the item was addressed to", "deadline": "no later than the Business Day after the first unit able to decide to dishonour or refuse it received the item" } ], "applies_to": "AFT credits and debits" }, "caveat": "The rules already bend around a restricted account: the duty to make a credit's funds available in time applies unless a restriction on the payee's account prevents it (Rule F1 s.8).", "related": [ "ca-acss:905", "ca-acss:910" ], "basis": { "sources": "Standard 007 paras 5 and 6 and Appendix I (return reason code list, category 900 to 914); Rule F1 Part III, 'Time Limitation for Return' and 'Unposted/Dishonoured Transactions/Transactions Refused by Payor/Payee', and s.22 on re-presentment; Rule F4 Part III, same headings; Rule H1 s.22(a) and (c). Payments Canada PDFs read 2026-09-18. Rule F1 s.8 (Credit Transaction Funds Availability).", "confidence": "medium" }, "currency": { "effective_since": "2016-04-18", "effective_note": "Standard 007 took effect 2016-04-18, when the code list moved out of Standard 005 (Standard 005 amendment list, item 21); the code itself is older and its first effective date is [Unverified]. Amendment 10 to Standard 007, in force 2026-07-03, changed one transaction code description and no return reason code.", "source_edition": "Payments Canada Standard 007 with amendment 10 (in force 2026-07-03); Rule F1 and Rule H1 as amended in force 2026-07-27; Rule F4 as amended in force 2026-07-27; Standard 005 as amended in force 2024-07-22", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.payments.ca/sites/default/files/standard007eng.pdf", "source_class": "authoritative_primary", "source_title": "Payments Canada Standard 007, Standards for the Use of Transaction Codes and Return Reason Codes in AFT Files, amendment 10, in force 2026-07-03", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms Appendix I lists return reason code 911 as Account Frozen, in the FI Dishonoured Transaction category 900 to 914. Does not address the return window." }, { "source_url": "https://www.payments.ca/sites/default/files/f1eng.pdf", "source_class": "authoritative_primary", "source_title": "Payments Canada Rule F1, Rules Applicable to Automated Funds Transfer (AFT) Transactions, as amended, in force 2026-07-27", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the general return window is the Business Day following receipt by the first organizational unit able to act on the decision, and that a Processing Direct Clearer's duty to make credit funds available within the stated timeframes does not apply where a prior restriction has been placed on the payee's account. Does not address the source of a freeze." } ] }, "rail_name": "Canada ACSS (Automated Funds Transfer)", "governing_authority": "Payments Canada", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "ca-acss:912", "id": "912", "rail": "ca-acss", "kind": "reason-code", "name": "Account number is wrong or malformed", "group": "account", "summary": "The account number on the item is not a valid number at the receiving institution, or is not the right number for this payor or payee. [Inference] Where the receiving direct clearer catches a malformed number in its edit the item comes back as a 900 reject instead; 912 is the return once the item has passed that edit.", "triggers": [ "A digit was dropped or added so the number cannot exist at that institution [Inference]", "The item is for an indirect clearer whose account formats are not published, so the receiving direct clearer may not reject it at the edit and it comes back later as a return [Inference from Rule F1, 'Transaction Edit, Account Validation and Rejected Transactions' (b)(ii)]" ], "actions": [ "Confirm the institution, branch and account number with the payor or payee before sending again [Inference]", "Check the number against the receiving institution's published account number formats and validation criteria (Rule F1, 'Transaction Edit, Account Validation and Rejected Transactions' (b))", "For a PAD, corrected details need the payor's authority or a qualifying Notice of Change (Rule H1 s.8(c))" ], "retry": { "allowed": false, "rule": "The rules allow re-presentment only after 901 or 908 (Rule F1 s.22; Rule F4, 'Re-presentment and Rejected Returned ISO Transactions'). [Inference] Once the underlying problem is fixed, a fresh item goes as a new transaction, and for a PAD it still needs a valid agreement and any Pre-notification that agreement requires." }, "facts": { "return_windows": [ { "action": "return", "by": "institution the item was addressed to", "deadline": "no later than the Business Day after the first unit able to decide to dishonour or refuse it received the item" } ], "applies_to": "AFT credits and debits" }, "caveat": "The ISO AFT Usage Guidelines Part C code list (portfolio dated 2017-01-31) shows this code with the label that belongs to 915. Standard 007 is the list that governs; the guideline shows only where the code travels.", "related": [ "ca-acss:902", "ca-acss:900", "ca-acss:914" ], "basis": { "sources": "Standard 007 paras 5 and 6 and Appendix I (return reason code list, category 900 to 914); Rule F1 Part III, 'Time Limitation for Return' and 'Unposted/Dishonoured Transactions/Transactions Refused by Payor/Payee', and s.22 on re-presentment; Rule F4 Part III, same headings; Rule H1 s.22(a) and (c). Payments Canada PDFs read 2026-09-18. Rule F1 Part II, 'Transaction Edit, Account Validation and Rejected Transactions' (b); Rule H1 s.8(c); ISO AFT Usage Guidelines Part C (Payment Return), datatype CPA_ReturnReasonCodesList, portfolio dated 2017-01-31.", "confidence": "medium" }, "currency": { "effective_since": "2016-04-18", "effective_note": "Standard 007 took effect 2016-04-18, when the code list moved out of Standard 005 (Standard 005 amendment list, item 21); the code itself is older and its first effective date is [Unverified]. Amendment 10 to Standard 007, in force 2026-07-03, changed one transaction code description and no return reason code.", "source_edition": "Payments Canada Standard 007 with amendment 10 (in force 2026-07-03); Rule F1 and Rule H1 as amended in force 2026-07-27; Rule F4 as amended in force 2026-07-27; Standard 005 as amended in force 2024-07-22", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.payments.ca/sites/default/files/standard007eng.pdf", "source_class": "authoritative_primary", "source_title": "Payments Canada Standard 007, Standards for the Use of Transaction Codes and Return Reason Codes in AFT Files, amendment 10, in force 2026-07-03", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms Appendix I lists return reason code 912 as Invalid/Incorrect Account No., in the FI Dishonoured Transaction category 900 to 914. Does not address the return window." }, { "source_url": "https://www.payments.ca/sites/default/files/f1eng.pdf", "source_class": "authoritative_primary", "source_title": "Payments Canada Rule F1, Rules Applicable to Automated Funds Transfer (AFT) Transactions, as amended, in force 2026-07-27", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the general return window is the Business Day following receipt by the first organizational unit able to act on the decision, and that a Processing Direct Clearer may not reject a transaction destined to an Indirect Clearer for invalid account number where the Clearing Agent has not published that Indirect Clearer's account number formats and validation criteria. Does not address Notice of Change procedures, which rest on Rule H1." } ] }, "rail_name": "Canada ACSS (Automated Funds Transfer)", "governing_authority": "Payments Canada", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "ca-acss:914", "id": "914", "rail": "ca-acss", "kind": "reason-code", "name": "Name does not match the account holder", "group": "account", "summary": "The institution returned the item because the payor or payee name on it does not match the holder of the account it names.", "triggers": [ "The payment was addressed to the right account number under someone else's name [Inference]", "A business payee's legal name differs from the name the payor gave [Inference]" ], "actions": [ "Confirm the account holder's name and number together before sending again [Inference]", "Do not re-present: only 901 and 908 allow that (Rule F1 s.22)" ], "retry": { "allowed": false, "rule": "The rules allow re-presentment only after 901 or 908 (Rule F1 s.22; Rule F4, 'Re-presentment and Rejected Returned ISO Transactions'). [Inference] Once the underlying problem is fixed, a fresh item goes as a new transaction, and for a PAD it still needs a valid agreement and any Pre-notification that agreement requires." }, "facts": { "return_windows": [ { "action": "return", "by": "institution the item was addressed to", "deadline": "no later than the Business Day after the first unit able to decide to dishonour or refuse it received the item" } ], "applies_to": "AFT credits and debits" }, "caveat": "Standard 005 was amended in 2008 to make clear that the payor or payee name field on an AFT credit or debit is for information only (Standard 005 amendment list, item 9). [Inference] So a name check is the receiving institution's own choice, and a mismatched name will often post without any return.", "related": [ "ca-acss:902", "ca-acss:912" ], "basis": { "sources": "Standard 007 paras 5 and 6 and Appendix I (return reason code list, category 900 to 914); Rule F1 Part III, 'Time Limitation for Return' and 'Unposted/Dishonoured Transactions/Transactions Refused by Payor/Payee', and s.22 on re-presentment; Rule F4 Part III, same headings; Rule H1 s.22(a) and (c). Payments Canada PDFs read 2026-09-18. Standard 005 amendment list, item 9 (effective 2008-08-18).", "confidence": "medium" }, "currency": { "effective_since": "2016-04-18", "effective_note": "Standard 007 took effect 2016-04-18, when the code list moved out of Standard 005 (Standard 005 amendment list, item 21); the code itself is older and its first effective date is [Unverified]. Amendment 10 to Standard 007, in force 2026-07-03, changed one transaction code description and no return reason code.", "source_edition": "Payments Canada Standard 007 with amendment 10 (in force 2026-07-03); Rule F1 and Rule H1 as amended in force 2026-07-27; Rule F4 as amended in force 2026-07-27; Standard 005 as amended in force 2024-07-22", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.payments.ca/sites/default/files/standard007eng.pdf", "source_class": "authoritative_primary", "source_title": "Payments Canada Standard 007, Standards for the Use of Transaction Codes and Return Reason Codes in AFT Files, amendment 10, in force 2026-07-03", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms Appendix I lists return reason code 914 as Incorrect Payor/Payee Name, in the FI Dishonoured Transaction category 900 to 914. Does not address the return window." }, { "source_url": "https://www.payments.ca/sites/default/files/f1eng.pdf", "source_class": "authoritative_primary", "source_title": "Payments Canada Rule F1, Rules Applicable to Automated Funds Transfer (AFT) Transactions, as amended, in force 2026-07-27", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the general return window is the Business Day following receipt by the first organizational unit able to act on the decision. Does not address the status of the payor or payee name field, which rests on Standard 005." }, { "source_url": "https://www.payments.ca/sites/default/files/standard005eng.pdf", "source_class": "authoritative_primary", "source_title": "Payments Canada Standard 005, Standards for the Exchange of Financial Data on AFT Files, as amended, in force 2024-07-22", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms an amendment approved by the Board June 12, 2008, effective August 18, 2008, clarified in Section D, Appendix 1 that the Payor/Payee field of an AFT credit or debit transaction is for information purposes only. Does not address the return window." } ] }, "rail_name": "Canada ACSS (Automated Funds Transfer)", "governing_authority": "Payments Canada", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "judgement", "label": "your bank's own terms", "needs": "whose terms decide it: the bank's, the participant's or the scheme's", "detail": "[Inference] So a name check is the receiving institution's own choice, and a mismatched name will often post without any return.", "from": "caveat" } ] }, { "uid": "ca-acss:915", "id": "915", "rail": "ca-acss", "kind": "reason-code", "name": "Payor says no debit agreement ever existed", "group": "authorization", "summary": "The payor told their institution that they never authorized this payee to debit them at all, and the institution refunded them and sent the debit back. [Inference] This is the code for the Rule H1 claim that no agreement existed, which reaches every PAD category. Rule F1 also makes it the code for a customer refusing an error correction that debits them.", "triggers": [ "A debit from a payee the payor has never dealt with [Inference]", "A payee debited the account using details the payor gave for some other purpose [Inference]", "A debit processed to the wrong customer's account in error (Rule H1 s.23 covers any debit erroneously processed, not only PADs)", "The customer refuses an error correction debit, Standard 005 record type E, which reverses an earlier credit (Rule F1, 'Time Limit for Error Correction Refusal')" ], "actions": [ "The payor's institution must refund the payor promptly and return the debit where the claim comes within 90 calendar days of the posting date shown on the payor's statement (Rule H1 s.23(a) and (b))", "It must take a Reimbursement Claim from the payor and keep it at least 12 months from the return (Rule H1 s.23(e) applying s.24(c); Rule F1, 'Reimbursement Claim')", "As payee you must take the return (Rule H1 s.23(e) applying s.24(e)). If you hold an agreement and think the claim is wrong, settle it with the payor outside the rules (Rule H1 s.27)", "Interest the payor's institution paid the payor may be claimed only under Rule J10, separately from the returned item (Rule H1 s.23(d)) [Unverified: Rule J10 not read]", "Check how you take agreements: every authorization has to come from a payor whose identity was verified by commercially reasonable methods (Rule H1 s.5(a) and (e))" ], "retry": { "allowed": false, "rule": "Do not debit this payor again without a new PAD agreement. Every PAD must rest on one (Rule H1 s.15(a)(i)), and the rules allow re-presentment only after 901 or 908 (Rule F1 s.22)." }, "facts": { "return_windows": [ { "action": "reimbursement claim (no agreement)", "by": "payor, to their own institution", "deadline": "no later than 90 calendar days after the posting date shown on the payor's account statement" }, { "action": "return", "by": "payor's institution", "deadline": "within the Rule H1 time limit for the claim (Rule F1 s.18)" }, { "action": "refuse an error correction debit", "by": "customer, through their institution", "deadline": "within 90 calendar days after the posting date" } ], "applies_to": "AFT debits only: every PAD category, including Cash Management PADs and Funds Transfer PADs coded 650, and any other debit processed in error; also error correction debits (record type E) the customer refuses" }, "caveat": "[Inference] Neither Rule H1 nor Standard 007 says that the no-agreement claim travels as 915; the pairing follows the code name. After 90 days a dispute over whether any agreement existed leaves the rules (Rule H1 s.23(c)). This window runs from the statement posting date, not from the debit date as the claims under 916 to 921 do. Rule H1 Appendix III states it from the processing date instead, a difference in the rule's own text [Unverified which governs].", "related": [ "ca-acss:916", "ca-acss:919", "ca-acss:922", "ca-acss:903" ], "basis": { "sources": "Standard 007 para 6 and Appendix I (category 915 to 921, debits only); Rule H1 ss.1, 5, 15, 16, 17, 20, 23 to 27, 28 to 30 and Appendix III; Rule F1 s.18 and 'Reimbursement Claim'; Rule F4 Part III exceptions for debtor-initiated returns. Payments Canada PDFs read 2026-09-18. Neither Rule H1 nor Standard 007 names the code that carries each H1 claim; the pairing in this record is an inference from the code names. Rule F1, 'Time Limit for Error Correction Refusal'; Rule F4, 'Time Limit for Refusal of an ISO AFT Payment Reversal Transaction'; Standard 007 Appendix I note 5; Standard 005 Section D, purpose of record type E.", "confidence": "medium" }, "currency": { "effective_since": "2016-04-18", "effective_note": "Standard 007 took effect 2016-04-18, when the code list moved out of Standard 005 (Standard 005 amendment list, item 21); the code itself is older and its first effective date is [Unverified]. Amendment 10 to Standard 007, in force 2026-07-03, changed one transaction code description and no return reason code. The heading of the 915 to 921 range was corrected by an administrative amendment in force 2022-11-14 (Standard 007 amendment list, item 5). The Rule H1 claim windows were last reworked in the holistic review in force 2022-10-03 and the recourse clarifications in force 2025-04-28 (H1 amendment list, items 10 and 12); the date each window first applied is [Unverified].", "source_edition": "Payments Canada Standard 007 with amendment 10 (in force 2026-07-03); Rule F1 and Rule H1 as amended in force 2026-07-27; Rule F4 as amended in force 2026-07-27; Standard 005 as amended in force 2024-07-22", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "rail_name": "Canada ACSS (Automated Funds Transfer)", "governing_authority": "Payments Canada", "snapshot": "2026-09-18", "source_class": null, "effective_status": "draft", "effective_status_reason": null, "boundaries": [] }, { "uid": "ca-acss:916", "id": "916", "rail": "ca-acss", "kind": "reason-code", "name": "Personal PAD not drawn as the agreement allows", "group": "authorization", "summary": "A payor with a valid agreement for a Personal PAD says this debit broke its terms, and claimed their money back from their own institution. [Inference] The code carries the Rule H1 s.24 claim on that ground for Personal PADs.", "triggers": [ "An amount above what the agreement allows or the Pre-notification stated [Inference]", "A debit on a date the agreement does not provide for [Inference]", "A second debit under an agreement for a single, One-Time PAD, which needs a new agreement (Rule H1 s.15(a)(iv)) [Inference that this claim ground is the one used]", "A Sporadic PAD sent without the payor's authorization for that particular debit (Rule H1 s.15(a)(iii)) [Inference that this claim ground is the one used]" ], "actions": [ "The payor's institution must reimburse the payor on a best efforts basis at once where the claim comes within 90 calendar days after the debit date (Rule H1 s.24(a)(i))", "It must take a completed Reimbursement Claim from the payor, signed or otherwise authenticated, and keep it at least 12 months from the return (Rule H1 s.24(c); Rule F1, 'Reimbursement Claim')", "As payee you must take the return: your institution is bound to honour it (Rule H1 s.24(e)). If you think the claim is wrong, the only route is with the payor directly, outside the rules (Rule H1 s.27)", "Your institution can ask for a copy of the Reimbursement Claim within the 12 months; the payor's institution must send it within 30 calendar days or pay back the amount (Rule F1, 'Reimbursement Claim')", "Interest on the returned amount is not dealt with under the rules (Rule H1 s.24(d))" ], "retry": { "allowed": false, "rule": "No re-presentment: the rules allow it only after 901 or 908 (Rule F1 s.22). [Inference] Any later debit must be one the agreement actually allows, with whatever Confirmation or Pre-notification Rule H1 ss.16 and 17 require." }, "facts": { "return_windows": [ { "action": "reimbursement claim", "by": "payor, to their own institution", "deadline": "up to and including 90 calendar days after the date the PAD was debited" }, { "action": "return", "by": "payor's institution", "deadline": "within the Rule H1 time limit for the claim (Rule F1 s.18)" } ], "applies_to": "Personal PADs, including a Personal PAD miscoded as Business; [Inference] also Funds Transfer PADs other than those coded 650, which share the Personal window but have no code of their own" }, "caveat": "[Inference] Rule H1 never names a return reason code, and Standard 007 names the codes without citing H1; this record pairs them by name. After 90 calendar days the claim leaves the rules and the PAD may not be returned through the clearing (Rule H1 s.24(g)). A PAD coded as Business that is really Personal keeps the 90 day window (Rule H1 s.24(a)(i)).", "related": [ "ca-acss:917", "ca-acss:918", "ca-acss:919", "ca-acss:915" ], "basis": { "sources": "Standard 007 para 6 and Appendix I (category 915 to 921, debits only); Rule H1 ss.1, 5, 15, 16, 17, 20, 23 to 27, 28 to 30 and Appendix III; Rule F1 s.18 and 'Reimbursement Claim'; Rule F4 Part III exceptions for debtor-initiated returns. Payments Canada PDFs read 2026-09-18. Neither Rule H1 nor Standard 007 names the code that carries each H1 claim; the pairing in this record is an inference from the code names.", "confidence": "medium" }, "currency": { "effective_since": "2016-04-18", "effective_note": "Standard 007 took effect 2016-04-18, when the code list moved out of Standard 005 (Standard 005 amendment list, item 21); the code itself is older and its first effective date is [Unverified]. Amendment 10 to Standard 007, in force 2026-07-03, changed one transaction code description and no return reason code. The heading of the 915 to 921 range was corrected by an administrative amendment in force 2022-11-14 (Standard 007 amendment list, item 5). The Rule H1 claim windows were last reworked in the holistic review in force 2022-10-03 and the recourse clarifications in force 2025-04-28 (H1 amendment list, items 10 and 12); the date each window first applied is [Unverified].", "source_edition": "Payments Canada Standard 007 with amendment 10 (in force 2026-07-03); Rule F1 and Rule H1 as amended in force 2026-07-27; Rule F4 as amended in force 2026-07-27; Standard 005 as amended in force 2024-07-22", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "rail_name": "Canada ACSS (Automated Funds Transfer)", "governing_authority": "Payments Canada", "snapshot": "2026-09-18", "source_class": null, "effective_status": "draft", "effective_status_reason": null, "boundaries": [] }, { "uid": "ca-acss:917", "id": "917", "rail": "ca-acss", "kind": "reason-code", "name": "Personal PAD sent after the payor cancelled", "group": "authorization", "summary": "The payor had cancelled their agreement for a Personal PAD before this debit's due date, the debit came anyway, and the payor claimed a refund from their own institution. [Inference] The code carries the Rule H1 s.24 claim on that ground for Personal PADs.", "triggers": [ "The payor revoked the agreement and the payee kept debiting after its cancellation period had run (Rule H1 s.30) [Inference that this claim ground is the one used]", "A cancellation reached the payee but its billing cycle had already sent the next debit [Inference]" ], "actions": [ "The payor's institution must reimburse the payor on a best efforts basis at once where the claim comes within 90 calendar days after the debit date (Rule H1 s.24(a)(i))", "It must take a completed Reimbursement Claim from the payor, signed or otherwise authenticated, and keep it at least 12 months from the return (Rule H1 s.24(c); Rule F1, 'Reimbursement Claim')", "As payee you must take the return: your institution is bound to honour it (Rule H1 s.24(e)). If you think the claim is wrong, the only route is with the payor directly, outside the rules (Rule H1 s.27)", "Your institution can ask for a copy of the Reimbursement Claim within the 12 months; the payor's institution must send it within 30 calendar days or pay back the amount (Rule F1, 'Reimbursement Claim')", "Interest on the returned amount is not dealt with under the rules (Rule H1 s.24(d))", "On a revocation the payee must use best efforts to stop the next cycle's debit and must stop issuing new PADs no later than 30 calendar days after the notice, or at the end of a shorter agreed cancellation period (Rule H1 s.30)" ], "retry": { "allowed": false, "rule": "Do not debit this payor again without a new PAD agreement (Rule H1 s.30(a)(iii)). Re-presentment is allowed only after 901 or 908 (Rule F1 s.22)." }, "facts": { "return_windows": [ { "action": "reimbursement claim", "by": "payor, to their own institution", "deadline": "up to and including 90 calendar days after the date the PAD was debited" }, { "action": "return", "by": "payor's institution", "deadline": "within the Rule H1 time limit for the claim (Rule F1 s.18)" } ], "applies_to": "Personal PADs, including a Personal PAD miscoded as Business; [Inference] also Funds Transfer PADs other than those coded 650, which share the Personal window but have no code of their own" }, "caveat": "[Inference] Rule H1 never names a return reason code, and Standard 007 names the codes without citing H1; this record pairs them by name. After 90 calendar days the claim leaves the rules and the PAD may not be returned through the clearing (Rule H1 s.24(g)). A PAD coded as Business that is really Personal keeps the 90 day window (Rule H1 s.24(a)(i)). [Inference] A debit inside an agreed cancellation period of up to 30 days may still be proper, so the date the revocation took effect matters (Rule H1 s.30(b); Appendix III, reason 2).", "related": [ "ca-acss:916", "ca-acss:918", "ca-acss:920", "ca-acss:903" ], "basis": { "sources": "Standard 007 para 6 and Appendix I (category 915 to 921, debits only); Rule H1 ss.1, 5, 15, 16, 17, 20, 23 to 27, 28 to 30 and Appendix III; Rule F1 s.18 and 'Reimbursement Claim'; Rule F4 Part III exceptions for debtor-initiated returns. Payments Canada PDFs read 2026-09-18. Neither Rule H1 nor Standard 007 names the code that carries each H1 claim; the pairing in this record is an inference from the code names.", "confidence": "medium" }, "currency": { "effective_since": "2016-04-18", "effective_note": "Standard 007 took effect 2016-04-18, when the code list moved out of Standard 005 (Standard 005 amendment list, item 21); the code itself is older and its first effective date is [Unverified]. Amendment 10 to Standard 007, in force 2026-07-03, changed one transaction code description and no return reason code. The heading of the 915 to 921 range was corrected by an administrative amendment in force 2022-11-14 (Standard 007 amendment list, item 5). The Rule H1 claim windows were last reworked in the holistic review in force 2022-10-03 and the recourse clarifications in force 2025-04-28 (H1 amendment list, items 10 and 12); the date each window first applied is [Unverified].", "source_edition": "Payments Canada Standard 007 with amendment 10 (in force 2026-07-03); Rule F1 and Rule H1 as amended in force 2026-07-27; Rule F4 as amended in force 2026-07-27; Standard 005 as amended in force 2024-07-22", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "rail_name": "Canada ACSS (Automated Funds Transfer)", "governing_authority": "Payments Canada", "snapshot": "2026-09-18", "source_class": null, "effective_status": "draft", "effective_status_reason": null, "boundaries": [] }, { "uid": "ca-acss:918", "id": "918", "rail": "ca-acss", "kind": "reason-code", "name": "Personal PAD sent without the required notice to the payor", "group": "authorization", "summary": "The payee did not give the payor a notice Rule H1 requires for a Personal PAD, and the payor claimed a refund from their own institution. The notices in question are the Confirmation of a new agreement, Pre-notification of an amount or date, and notice of an assignment or a change of payee name. [Inference] The code carries the Rule H1 s.24 claim on that ground for Personal PADs.", "triggers": [ "No Confirmation at least 10 calendar days before the first PAD, and no waiver or shortening by the payor; or, after a waiver, no Confirmation within 5 calendar days of the first PAD (Rule H1 s.16)", "A variable amount PAD, or a changed amount or date on a recurring PAD, without Pre-notification at least 10 calendar days ahead and without a valid waiver (Rule H1 ss.17 to 19)", "The agreement was assigned to another payee, or the payee's name changed, without the notice Rule H1 ss.28 and 29 call for" ], "actions": [ "The payor's institution must reimburse the payor on a best efforts basis at once where the claim comes within 90 calendar days after the debit date (Rule H1 s.24(a)(i))", "It must take a completed Reimbursement Claim from the payor, signed or otherwise authenticated, and keep it at least 12 months from the return (Rule H1 s.24(c); Rule F1, 'Reimbursement Claim')", "As payee you must take the return: your institution is bound to honour it (Rule H1 s.24(e)). If you think the claim is wrong, the only route is with the payor directly, outside the rules (Rule H1 s.27)", "Your institution can ask for a copy of the Reimbursement Claim within the 12 months; the payor's institution must send it within 30 calendar days or pay back the amount (Rule F1, 'Reimbursement Claim')", "Interest on the returned amount is not dealt with under the rules (Rule H1 s.24(d))", "Keep proof that each Confirmation and Pre-notification was given, with the audit trail the payee must hold for 12 months after the last PAD (Rule H1 s.21(a)) [Inference that proof of notice belongs in that trail]" ], "retry": { "allowed": false, "rule": "No re-presentment: the rules allow it only after 901 or 908 (Rule F1 s.22). [Inference] Any later debit must be one the agreement actually allows, with whatever Confirmation or Pre-notification Rule H1 ss.16 and 17 require." }, "facts": { "return_windows": [ { "action": "reimbursement claim", "by": "payor, to their own institution", "deadline": "up to and including 90 calendar days after the date the PAD was debited" }, { "action": "return", "by": "payor's institution", "deadline": "within the Rule H1 time limit for the claim (Rule F1 s.18)" } ], "applies_to": "Personal PADs, including a Personal PAD miscoded as Business; [Inference] also Funds Transfer PADs other than those coded 650, which share the Personal window but have no code of their own" }, "caveat": "[Inference] Rule H1 never names a return reason code, and Standard 007 names the codes without citing H1; this record pairs them by name. After 90 calendar days the claim leaves the rules and the PAD may not be returned through the clearing (Rule H1 s.24(g)). A PAD coded as Business that is really Personal keeps the 90 day window (Rule H1 s.24(a)(i)). Some changes need no Pre-notification, such as a decrease caused by a tax cut, or a change the payor asked for where the agreement provides for it (Rule H1 s.18).", "related": [ "ca-acss:916", "ca-acss:917", "ca-acss:921" ], "basis": { "sources": "Standard 007 para 6 and Appendix I (category 915 to 921, debits only); Rule H1 ss.1, 5, 15, 16, 17, 20, 23 to 27, 28 to 30 and Appendix III; Rule F1 s.18 and 'Reimbursement Claim'; Rule F4 Part III exceptions for debtor-initiated returns. Payments Canada PDFs read 2026-09-18. Neither Rule H1 nor Standard 007 names the code that carries each H1 claim; the pairing in this record is an inference from the code names.", "confidence": "medium" }, "currency": { "effective_since": "2016-04-18", "effective_note": "Standard 007 took effect 2016-04-18, when the code list moved out of Standard 005 (Standard 005 amendment list, item 21); the code itself is older and its first effective date is [Unverified]. Amendment 10 to Standard 007, in force 2026-07-03, changed one transaction code description and no return reason code. The heading of the 915 to 921 range was corrected by an administrative amendment in force 2022-11-14 (Standard 007 amendment list, item 5). The Rule H1 claim windows were last reworked in the holistic review in force 2022-10-03 and the recourse clarifications in force 2025-04-28 (H1 amendment list, items 10 and 12); the date each window first applied is [Unverified].", "source_edition": "Payments Canada Standard 007 with amendment 10 (in force 2026-07-03); Rule F1 and Rule H1 as amended in force 2026-07-27; Rule F4 as amended in force 2026-07-27; Standard 005 as amended in force 2024-07-22", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "rail_name": "Canada ACSS (Automated Funds Transfer)", "governing_authority": "Payments Canada", "snapshot": "2026-09-18", "source_class": null, "effective_status": "draft", "effective_status_reason": null, "boundaries": [] }, { "uid": "ca-acss:919", "id": "919", "rail": "ca-acss", "kind": "reason-code", "name": "Business PAD not drawn as the agreement allows", "group": "authorization", "summary": "A business payor says a Business PAD broke the terms of its agreement and claimed its money back from its own institution within the short Business PAD window. [Inference] The code carries the Rule H1 s.24 claim on that ground for Business PADs.", "triggers": [ "An amount or date outside what the agreement allows [Inference]", "A Sporadic Business PAD sent without the payor's authorization for that debit (Rule H1 s.15(a)(iii)) [Inference that this claim ground is the one used]" ], "actions": [ "The payor's institution must reimburse the payor on a best efforts basis at once where the claim comes within 10 Business Days after the debit date (Rule H1 s.24(a)(ii))", "It must take a completed Reimbursement Claim from the payor, signed or otherwise authenticated, and keep it at least 12 months from the return (Rule H1 s.24(c); Rule F1, 'Reimbursement Claim')", "As payee you must take the return: your institution is bound to honour it (Rule H1 s.24(e)). If you think the claim is wrong, the only route is with the payor directly, outside the rules (Rule H1 s.27)", "Your institution can ask for a copy of the Reimbursement Claim within the 12 months; the payor's institution must send it within 30 calendar days or pay back the amount (Rule F1, 'Reimbursement Claim')", "Interest on the returned amount is not dealt with under the rules (Rule H1 s.24(d))" ], "retry": { "allowed": false, "rule": "No re-presentment: the rules allow it only after 901 or 908 (Rule F1 s.22). [Inference] Any later debit must be one the agreement actually allows, with whatever Confirmation or Pre-notification Rule H1 ss.16 and 17 require." }, "facts": { "return_windows": [ { "action": "reimbursement claim", "by": "payor, to their own institution", "deadline": "up to and including 10 Business Days after the date the PAD was debited" }, { "action": "return", "by": "payor's institution", "deadline": "within the Rule H1 time limit for the claim (Rule F1 s.18)" } ], "applies_to": "Business PADs (transaction codes 700 to 749), except Cash Management PADs coded 717, which carry no claim on this ground (Rule H1 s.26; Standard 007 Appendix I note 4)" }, "caveat": "[Inference] Rule H1 never names a return reason code, and Standard 007 names the codes without citing H1; this record pairs them by name. The window is 10 Business Days, and a Business Day is any day that is not an ACSS Holiday (Introduction to the ACSS Rules, definitions). Later claims go outside the rules and the PAD may not be returned through the clearing (Rule H1 s.24(g)). A PAD coded Business that is really Personal takes the Personal window and, by the same pairing, a Personal code.", "related": [ "ca-acss:916", "ca-acss:920", "ca-acss:921", "ca-acss:915" ], "basis": { "sources": "Standard 007 para 6 and Appendix I (category 915 to 921, debits only); Rule H1 ss.1, 5, 15, 16, 17, 20, 23 to 27, 28 to 30 and Appendix III; Rule F1 s.18 and 'Reimbursement Claim'; Rule F4 Part III exceptions for debtor-initiated returns. Payments Canada PDFs read 2026-09-18. Neither Rule H1 nor Standard 007 names the code that carries each H1 claim; the pairing in this record is an inference from the code names. Standard 007 Appendix I note 4.", "confidence": "medium" }, "currency": { "effective_since": "2016-04-18", "effective_note": "Standard 007 took effect 2016-04-18, when the code list moved out of Standard 005 (Standard 005 amendment list, item 21); the code itself is older and its first effective date is [Unverified]. Amendment 10 to Standard 007, in force 2026-07-03, changed one transaction code description and no return reason code. The heading of the 915 to 921 range was corrected by an administrative amendment in force 2022-11-14 (Standard 007 amendment list, item 5). The Rule H1 claim windows were last reworked in the holistic review in force 2022-10-03 and the recourse clarifications in force 2025-04-28 (H1 amendment list, items 10 and 12); the date each window first applied is [Unverified].", "source_edition": "Payments Canada Standard 007 with amendment 10 (in force 2026-07-03); Rule F1 and Rule H1 as amended in force 2026-07-27; Rule F4 as amended in force 2026-07-27; Standard 005 as amended in force 2024-07-22", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "rail_name": "Canada ACSS (Automated Funds Transfer)", "governing_authority": "Payments Canada", "snapshot": "2026-09-18", "source_class": null, "effective_status": "draft", "effective_status_reason": null, "boundaries": [] }, { "uid": "ca-acss:920", "id": "920", "rail": "ca-acss", "kind": "reason-code", "name": "Business PAD sent after the payor cancelled", "group": "authorization", "summary": "A business payor had cancelled its agreement for a Business PAD before the debit's due date, the debit came anyway, and the payor claimed its money back within the Business PAD window. [Inference] The code carries the Rule H1 s.24 claim on that ground for Business PADs.", "triggers": [ "The payor revoked the agreement and the payee kept debiting after its cancellation period had run (Rule H1 s.30) [Inference that this claim ground is the one used]" ], "actions": [ "The payor's institution must reimburse the payor on a best efforts basis at once where the claim comes within 10 Business Days after the debit date (Rule H1 s.24(a)(ii))", "It must take a completed Reimbursement Claim from the payor, signed or otherwise authenticated, and keep it at least 12 months from the return (Rule H1 s.24(c); Rule F1, 'Reimbursement Claim')", "As payee you must take the return: your institution is bound to honour it (Rule H1 s.24(e)). If you think the claim is wrong, the only route is with the payor directly, outside the rules (Rule H1 s.27)", "Your institution can ask for a copy of the Reimbursement Claim within the 12 months; the payor's institution must send it within 30 calendar days or pay back the amount (Rule F1, 'Reimbursement Claim')", "Interest on the returned amount is not dealt with under the rules (Rule H1 s.24(d))", "On a revocation the payee must use best efforts to stop the next cycle's debit and must stop issuing new PADs no later than 30 calendar days after the notice, or at the end of a shorter agreed cancellation period (Rule H1 s.30)" ], "retry": { "allowed": false, "rule": "Do not debit this payor again without a new PAD agreement (Rule H1 s.30(a)(iii)). Re-presentment is allowed only after 901 or 908 (Rule F1 s.22)." }, "facts": { "return_windows": [ { "action": "reimbursement claim", "by": "payor, to their own institution", "deadline": "up to and including 10 Business Days after the date the PAD was debited" }, { "action": "return", "by": "payor's institution", "deadline": "within the Rule H1 time limit for the claim (Rule F1 s.18)" } ], "applies_to": "Business PADs (transaction codes 700 to 749), except Cash Management PADs coded 717, which carry no claim on this ground (Rule H1 s.26; Standard 007 Appendix I note 4)" }, "caveat": "[Inference] Rule H1 never names a return reason code, and Standard 007 names the codes without citing H1; this record pairs them by name. The window is 10 Business Days, and a Business Day is any day that is not an ACSS Holiday (Introduction to the ACSS Rules, definitions). Later claims go outside the rules and the PAD may not be returned through the clearing (Rule H1 s.24(g)). A PAD coded Business that is really Personal takes the Personal window and, by the same pairing, a Personal code. [Inference] A debit inside an agreed cancellation period of up to 30 days may still be proper (Rule H1 s.30(b)).", "related": [ "ca-acss:917", "ca-acss:919", "ca-acss:921", "ca-acss:903" ], "basis": { "sources": "Standard 007 para 6 and Appendix I (category 915 to 921, debits only); Rule H1 ss.1, 5, 15, 16, 17, 20, 23 to 27, 28 to 30 and Appendix III; Rule F1 s.18 and 'Reimbursement Claim'; Rule F4 Part III exceptions for debtor-initiated returns. Payments Canada PDFs read 2026-09-18. Neither Rule H1 nor Standard 007 names the code that carries each H1 claim; the pairing in this record is an inference from the code names. Standard 007 Appendix I note 4.", "confidence": "medium" }, "currency": { "effective_since": "2016-04-18", "effective_note": "Standard 007 took effect 2016-04-18, when the code list moved out of Standard 005 (Standard 005 amendment list, item 21); the code itself is older and its first effective date is [Unverified]. Amendment 10 to Standard 007, in force 2026-07-03, changed one transaction code description and no return reason code. The heading of the 915 to 921 range was corrected by an administrative amendment in force 2022-11-14 (Standard 007 amendment list, item 5). The Rule H1 claim windows were last reworked in the holistic review in force 2022-10-03 and the recourse clarifications in force 2025-04-28 (H1 amendment list, items 10 and 12); the date each window first applied is [Unverified].", "source_edition": "Payments Canada Standard 007 with amendment 10 (in force 2026-07-03); Rule F1 and Rule H1 as amended in force 2026-07-27; Rule F4 as amended in force 2026-07-27; Standard 005 as amended in force 2024-07-22", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "rail_name": "Canada ACSS (Automated Funds Transfer)", "governing_authority": "Payments Canada", "snapshot": "2026-09-18", "source_class": null, "effective_status": "draft", "effective_status_reason": null, "boundaries": [] }, { "uid": "ca-acss:921", "id": "921", "rail": "ca-acss", "kind": "reason-code", "name": "Business PAD sent without the required notice to the payor", "group": "authorization", "summary": "The payee did not give a business payor a notice Rule H1 requires for a Business PAD, whether the Confirmation, a Pre-notification, or notice of an assignment or name change, and the payor claimed its money back within the Business PAD window. [Inference] The code carries the Rule H1 s.24 claim on that ground for Business PADs.", "triggers": [ "No Confirmation before the first PAD, or after a waiver no Confirmation within 5 calendar days of it (Rule H1 s.16)", "A changed amount or date, or a variable amount, without Pre-notification at least 10 calendar days ahead and without a valid waiver (Rule H1 ss.17 to 19)", "An assignment or payee name change without the notice Rule H1 ss.28 and 29 call for" ], "actions": [ "The payor's institution must reimburse the payor on a best efforts basis at once where the claim comes within 10 Business Days after the debit date (Rule H1 s.24(a)(ii))", "It must take a completed Reimbursement Claim from the payor, signed or otherwise authenticated, and keep it at least 12 months from the return (Rule H1 s.24(c); Rule F1, 'Reimbursement Claim')", "As payee you must take the return: your institution is bound to honour it (Rule H1 s.24(e)). If you think the claim is wrong, the only route is with the payor directly, outside the rules (Rule H1 s.27)", "Your institution can ask for a copy of the Reimbursement Claim within the 12 months; the payor's institution must send it within 30 calendar days or pay back the amount (Rule F1, 'Reimbursement Claim')", "Interest on the returned amount is not dealt with under the rules (Rule H1 s.24(d))" ], "retry": { "allowed": false, "rule": "No re-presentment: the rules allow it only after 901 or 908 (Rule F1 s.22). [Inference] Any later debit must be one the agreement actually allows, with whatever Confirmation or Pre-notification Rule H1 ss.16 and 17 require." }, "facts": { "return_windows": [ { "action": "reimbursement claim", "by": "payor, to their own institution", "deadline": "up to and including 10 Business Days after the date the PAD was debited" }, { "action": "return", "by": "payor's institution", "deadline": "within the Rule H1 time limit for the claim (Rule F1 s.18)" } ], "applies_to": "Business PADs (transaction codes 700 to 749), except Cash Management PADs coded 717, which carry no claim on this ground (Rule H1 s.26; Standard 007 Appendix I note 4)" }, "caveat": "[Inference] Rule H1 never names a return reason code, and Standard 007 names the codes without citing H1; this record pairs them by name. The window is 10 Business Days, and a Business Day is any day that is not an ACSS Holiday (Introduction to the ACSS Rules, definitions). Later claims go outside the rules and the PAD may not be returned through the clearing (Rule H1 s.24(g)). A PAD coded Business that is really Personal takes the Personal window and, by the same pairing, a Personal code. Business payors often agree to waive Pre-notification; a waiver clause in the agreement must be displayed prominently to count (Rule H1 s.19).", "related": [ "ca-acss:918", "ca-acss:919", "ca-acss:920" ], "basis": { "sources": "Standard 007 para 6 and Appendix I (category 915 to 921, debits only); Rule H1 ss.1, 5, 15, 16, 17, 20, 23 to 27, 28 to 30 and Appendix III; Rule F1 s.18 and 'Reimbursement Claim'; Rule F4 Part III exceptions for debtor-initiated returns. Payments Canada PDFs read 2026-09-18. Neither Rule H1 nor Standard 007 names the code that carries each H1 claim; the pairing in this record is an inference from the code names. Standard 007 Appendix I note 4.", "confidence": "medium" }, "currency": { "effective_since": "2016-04-18", "effective_note": "Standard 007 took effect 2016-04-18, when the code list moved out of Standard 005 (Standard 005 amendment list, item 21); the code itself is older and its first effective date is [Unverified]. Amendment 10 to Standard 007, in force 2026-07-03, changed one transaction code description and no return reason code. The heading of the 915 to 921 range was corrected by an administrative amendment in force 2022-11-14 (Standard 007 amendment list, item 5). The Rule H1 claim windows were last reworked in the holistic review in force 2022-10-03 and the recourse clarifications in force 2025-04-28 (H1 amendment list, items 10 and 12); the date each window first applied is [Unverified].", "source_edition": "Payments Canada Standard 007 with amendment 10 (in force 2026-07-03); Rule F1 and Rule H1 as amended in force 2026-07-27; Rule F4 as amended in force 2026-07-27; Standard 005 as amended in force 2024-07-22", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "rail_name": "Canada ACSS (Automated Funds Transfer)", "governing_authority": "Payments Canada", "snapshot": "2026-09-18", "source_class": null, "effective_status": "draft", "effective_status_reason": null, "boundaries": [] }, { "uid": "ca-acss:922", "id": "922", "rail": "ca-acss", "kind": "reason-code", "name": "Payee refused a credit", "group": "administrative", "summary": "The payee, not their institution, turned down a credit paid into their account and asked for it to go back. Rule F1 also makes this the code for a customer refusing an error correction that credits them.", "triggers": [ "The payee did not expect the payment or says it was meant for someone else [Inference]", "The customer refuses an error correction credit, Standard 005 record type F, which reverses an earlier PAD (Rule F1, 'Time Limit for Error Correction Refusal')" ], "actions": [ "The payee may refuse the credit up to and including 90 calendar days after it was processed to their account; a later refusal is handled outside the clearing (Rule F1 s.19; Rule F4, creditor-initiated exception)", "As payment originator, find out why before paying again [Inference]", "Once a returned item has been accepted in the sender's file edit it cannot be returned again through the clearing; a disagreement about it becomes an Item in Dispute under Rule A6 (Rule F1, 'Unposted/Dishonoured Transactions/Transactions Refused by Payor/Payee') [Unverified: Rule A6 not read]" ], "retry": { "allowed": false, "rule": "No re-presentment; the rules allow it only for debits returned under 901 or 908 (Rule F1 s.22). [Inference] A payment the payee refused should not be sent again without the payee's agreement." }, "facts": { "return_windows": [ { "action": "refuse a credit", "by": "payee, through their institution", "deadline": "up to and including 90 calendar days after the credit was processed to the payee's account" }, { "action": "refuse an error correction credit", "by": "customer, through their institution", "deadline": "within 90 calendar days after the posting date" } ], "applies_to": "AFT credits only, including error correction credits (record type F) the customer refuses" }, "caveat": "[Inference] Rule F1 s.19 gives the payee the 90 day right without naming a code; 922 is the only code in Standard 007's customer-initiated credit category, so the pairing is by category. On error corrections, Standard 007 note 5 and Rule F1 look inconsistent but are not [Inference]: F1 pairs 922 with record type F, which Standard 005 defines as the reversal of a PAD, so note 5's wording names the kind of item being corrected rather than the correction.", "related": [ "ca-acss:915" ], "basis": { "sources": "Standard 007 para 6 (category 922) and Appendix I note 5; Rule F1 s.19 and headings 'Time Limit for Error Correction Refusal' and 'Unposted/Dishonoured Transactions/Transactions Refused by Payor/Payee'; Rule F4, exceptions for creditor-initiated returns and 'Time Limit for Refusal of an ISO AFT Payment Reversal Transaction'; Standard 005 Section D, purposes of record types E and F. Payments Canada PDFs read 2026-09-18.", "confidence": "medium" }, "currency": { "effective_since": "2016-04-18", "effective_note": "Standard 007 took effect 2016-04-18, when the code list moved out of Standard 005 (Standard 005 amendment list, item 21); the code itself is older and its first effective date is [Unverified]. Amendment 10 to Standard 007, in force 2026-07-03, changed one transaction code description and no return reason code.", "source_edition": "Payments Canada Standard 007 with amendment 10 (in force 2026-07-03); Rule F1 and Rule H1 as amended in force 2026-07-27; Rule F4 as amended in force 2026-07-27; Standard 005 as amended in force 2024-07-22", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.payments.ca/sites/default/files/standard007eng.pdf", "source_class": "authoritative_primary", "source_title": "Payments Canada Standard 007, Standards for the Use of Transaction Codes and Return Reason Codes in AFT Files, amendment 10, in force 2026-07-03", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms Appendix I lists return reason code 922 as Customer Initiated Return in the Credit Only category, and that note 5 states codes 915 and 922 may also be used to return an error correction, credit or debit respectively, being refused by the payor or payee, without stating a return window for that use." }, { "source_url": "https://www.payments.ca/sites/default/files/f1eng.pdf", "source_class": "authoritative_primary", "source_title": "Payments Canada Rule F1, Rules Applicable to Automated Funds Transfer (AFT) Transactions, as amended, in force 2026-07-27", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms a credit transaction may be refused by a payee up to and including 90 calendar days after it was processed to the payee's account, with later refusals addressed outside the clearing, and separately confirms that a customer refusing an AFT error correction within 90 calendar days of the posting date must have it returned using code 915 for a Logical Record Type E or code 922 for a Logical Record Type F." }, { "source_url": "https://www.payments.ca/sites/default/files/standard005eng.pdf", "source_class": "authoritative_primary", "source_title": "Payments Canada Standard 005, Standards for the Exchange of Financial Data on AFT Files, as amended, in force 2024-07-22", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms Logical Record Type F exists to allow the originator to reverse pre-authorized debit data, Logical Record Type D, and Logical Record Type E exists to allow the originator to reverse deposit data, Logical Record Type C. Does not address which return reason code carries a refused error correction; that pairing is confirmed instead by Rule F1." } ] }, "rail_name": "Canada ACSS (Automated Funds Transfer)", "governing_authority": "Payments Canada", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "ca-acss:990", "id": "990", "rail": "ca-acss", "kind": "reason-code", "name": "Institution in default", "group": "network", "summary": "The item involves an institution that has failed to settle in the ACSS, so it is sent back or dropped under the default rules instead of being posted. [Inference] The code marks items caught by a default; neither default rule names it.", "triggers": [ "A direct clearer could not settle its net debit position or failed to pledge required collateral, and the Bank of Canada gave notice of default (Rule L1 s.3(f) and s.4, referring to By-law No. 3 s.53(1)) [Unverified: By-law No. 3 not read]", "A clearing agent declared default of an indirect clearer it clears for, because a shortfall in that clearer's settlement account blocked settlement (Rule L2 s.3(a) and s.5)" ], "actions": [ "Items exchanged in the cycle for which default was declared are still settled, with the surviving direct clearers and the Bank of Canada making contributions to cover the shortfall (Rule L1 ss.11(a) and 13)", "Items for later cycles are not cleared or settled through the ACSS; members may purge them and send listings to the liquidator or trustee (Rule L1 s.11(b) and (c); Rule L2 s.10)", "Recourse for those items lies outside the rules, for example against the estate of the defaulted institution (Rule L1 s.11(b)) [Inference as to the route]", "For a payor or payee, the payment has not happened; arrange another way to pay [Inference]" ], "retry": { "allowed": false, "rule": "Not through the ACSS: every member must stop accepting items drawn on, payable by or payable to the defaulted institution (Rule L1 s.8; Rule L2 s.8)." }, "facts": { "return_windows": [ { "action": "return or reject", "by": "surviving institution holding the item", "deadline": "[Unverified] no time limit stated; Rule F1 sends default returns to Rules L1 and L2, which provide for purging rather than a return window" } ], "applies_to": "AFT credits and debits exchanged with a direct or indirect clearer in default" }, "caveat": "Neither Rule L1 nor Rule L2 mentions code 990; the link rests on Standard 007's default category and the default heading of Rule F1 [Inference]. The ISO AFT Usage Guidelines Part C code list (portfolio dated 2017-01-31) omits 990, so how it travels in an ISO AFT return is [Unverified].", "related": [ "ca-acss:900" ], "basis": { "sources": "Standard 007 para 6 (category 990) and Appendix I; Rule F1 Part V, 'Default'; Rule L1 ss.3, 4, 7, 8, 11 and 13 (latest amendment in force 2026-02-09); Rule L2 ss.3, 5, 8, 9 and 10 (latest amendment in force 2025-11-24); ISO AFT Usage Guidelines Part C, datatype CPA_ReturnReasonCodesList. Payments Canada PDFs read 2026-09-18. By-law No. 3 was not read.", "confidence": "low" }, "currency": { "effective_since": "2016-04-18", "effective_note": "Standard 007 took effect 2016-04-18, when the code list moved out of Standard 005 (Standard 005 amendment list, item 21); the code itself is older and its first effective date is [Unverified]. Amendment 10 to Standard 007, in force 2026-07-03, changed one transaction code description and no return reason code.", "source_edition": "Payments Canada Standard 007 with amendment 10 (in force 2026-07-03); Rule F1 and Rule H1 as amended in force 2026-07-27; Rule F4 as amended in force 2026-07-27; Standard 005 as amended in force 2024-07-22; Rule L1 as amended in force 2026-02-09; Rule L2 as amended in force 2025-11-24", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "rail_name": "Canada ACSS (Automated Funds Transfer)", "governing_authority": "Payments Canada", "snapshot": "2026-09-18", "source_class": null, "effective_status": "draft", "effective_status_reason": null, "boundaries": [] }, { "uid": "ch-sic-ip-reject:AB05", "id": "AB05", "rail": "ch-sic-ip-reject", "kind": "reason-code", "name": "Receiving bank ran out of time", "group": "technical", "summary": "The receiving participant turns an IP customer payment down because its own processing took too long. Nothing settles: the SIC IP service cancels the payment and hands AB05 back to the sender.", "triggers": [ "The receiving participant cannot finish its checks and the credit to the payee inside the time it allows itself [Inference from the ISO code name TimeoutCreditorAgent]", "A slowdown or outage in the receiving participant's instant payment systems [Inference]" ], "actions": [ "Sending participant: once the CNC002 arrives, treat the payment as not executed, free the amount it had reserved for the payer [Inference: the SNB says the amount is reserved first and the payment is cancelled on a negative answer], and tell the payer straight away, with the reason where the law allows (SNB-R 2025 ch. 6 footnotes 15 and 16)", "Sending participant: offer the payer a later attempt, or a normal payment through the SIC RTGS service", "Receiving participant: look for the delay in its instant payment chain; if it answers too late, the service cancels with TM01 instead [Inference]" ], "retry": { "allowed": true, "rule": "The cancelled payment stays cancelled and cannot be revived. A new IP customer payment, with a new transaction reference, may be sent later, or the transfer can go through the SIC RTGS service instead [Inference]. The public guidelines set no retry limit [Unverified]." }, "facts": { "return_windows": [ { "action": "reject the IP customer payment with a Negative IP Feedback (pacs.002 NEG002, status RJCT) carrying this code", "by": "Receiving (instructed) participant, identified by its SIC IID as originator of the feedback", "deadline": "No public deadline is published. The feedback presumably has to reach the SIC IP service before the service's hard time-out [Inference], which counts from the start time the sending participant stamps on the pacs.008 (IP-pacs.008 v2.3, element AccptncDtTm); the time-out value itself is in the participant-only SIC Handbook. The SNB describes instant payments as settled in principle within ten seconds (SNB-R 2025 ch. 6)." }, { "action": "cancel the payment and pass the code on in an IP Cancellation Information (pacs.002 CNC002, status CANC)", "by": "SIC IP service", "deadline": "No public deadline is published. The guideline says the service copies the receiving participant's code into the cancellation notice; how soon that notice goes out is not stated in the public guidelines." } ], "applies_to": "SIC IP service (Swiss franc instant payments, 24/7): the receiving participant's Negative IP Feedback (pacs.002 of type NEG002, status RJCT) on an IP customer payment (pacs.008). The service checks the code against a closed list of 14 and repeats it to the sending side in the IP Cancellation Information (CNC002)." }, "caveat": "AB05 is the receiving participant's own time-out, reported by it in a NEG002. TM01 is a different case: the SIC IP service cancels because the hard time-out passed. The sending participant sees the same code in the CNC002, with the receiving participant's SIC IID as originator (IP-pacs.002 v2.4 sections 3.1.6 and 4.3). What the payer is told is up to the sending bank; the SPS pain.002 status codes a Swiss bank customer receives are a separate family and never travel in SIC.", "related": [ "ch-sic-ip-reject:TM01", "ch-sic-ip-reject:AB09", "ch-sic-ip-reject:ED05" ], "basis": { "sources": "IP-pacs.002 v2.4 (SIX Interbank Clearing, Instant Payments Implementation Guidelines, IP Status Report, 2026-02-27, valid from 2026-11-13) sections 3.1.4 and Table 3 (permitted NEG002 codes, checked by the service), 3.1.6 (CNC002 copies the NEG002 code) and 4.3 (elements TxSts, StsRsnInf/Orgtr, Rsn/Cd); IP-pacs.002 v2.3 (2025-02-28, valid from 2025-11-21), same sections; IP-pacs.008 v2.3 (2026-02-27) element AccptncDtTm; SNB Report on the SIC System and Disclosure Report 2025 ch. 6 and footnotes 15 and 16. The code meaning rests on the ISO code name SIX prints in Table 3; the ISO External Code Set itself was not read.", "confidence": "medium" }, "currency": { "effective_since": "Since IP-pacs.002 v2.0 (first production edition)", "effective_note": "A list of permitted NEG002 codes first appears in IP-pacs.002 v1.1 (2022-05-20); v2.0 (2022-10-20) was the first edition for production, valid from the November 2023 release. The code is in v2.3, in force since 2025-11-21 with SIC platform release 5.2, and unchanged in v2.4, valid from 2026-11-13 with release 5.3. SIX plans to move all SIC IP messages to ISO 20022 2024/2025 versions in November 2027 (SIC Platform Release Notes 2026, CR2026-SIC-0002), which may change the list [Speculation].", "source_edition": "IP-pacs.002 v2.3 (2025-02-28, valid from 2025-11-21) and v2.4 (2026-02-27, valid from 2026-11-13)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.six-group.com/dam/download/banking-services/standardization/sic-eurosic/5-3/ig-module-docs-sic-ip-2026-5.3-en.zip", "source_class": "authoritative_primary", "source_title": "IP Status Report (pacs.002) v2.4, SIC IP module documents, release 5.3 archive", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "IP Status Report (pacs.002) v2.4 section 3.1.4 Table 3 lists AB05 among the 14 codes valid in the Reason element of a Negative IP Feedback (NEG002), with the ISO code name TimeoutCreditorAgent. Confirms the code sits on the closed list the SIC IP service checks and repeats to the sender in the IP Cancellation Information (CNC002); the table states only the ISO code name, no SIX-authored definition." }, { "source_url": "https://www.iso20022.org/sites/default/files/media/file/ExternalCodeSets_JSON.zip", "source_class": "authoritative_primary", "source_title": "ISO 20022 External Code Sets, 2Q2026, ExternalStatusReason1Code", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "The ISO 20022 External Code Set ExternalStatusReason1Code defines AB05 as a transaction stopped because of a timeout at the creditor agent. Confirms the record's stated meaning that the receiving participant's own processing ran out of time before the payment was accepted; does not add anything about IP-specific timing, which stays unconfirmed." } ] }, "rail_name": "SIC IP Payment Rejections", "governing_authority": "SIX Interbank Clearing on behalf of the Swiss National Bank", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "ch-sic-ip-reject:AB09", "id": "AB09", "rail": "ch-sic-ip-reject", "kind": "reason-code", "name": "Error at the receiving bank", "group": "technical", "summary": "The receiving participant rejects an IP customer payment because something went wrong on its own side. The service cancels the payment and the sender sees AB09.", "triggers": [ "A technical or processing fault at the receiving participant keeps it from accepting the payment [Inference from the ISO code name ErrorCreditorAgent]" ], "actions": [ "Sending participant: once the CNC002 arrives, treat the payment as not executed, free the amount it had reserved for the payer [Inference: the SNB says the amount is reserved first and the payment is cancelled on a negative answer], and tell the payer straight away, with the reason where the law allows (SNB-R 2025 ch. 6 footnotes 15 and 16)", "Sending participant: offer a later attempt or a payment through the SIC RTGS service", "Receiving participant: find and fix the fault; frequent AB09 answers point to a problem in its own setup [Inference]" ], "retry": { "allowed": true, "rule": "The cancelled payment stays cancelled and cannot be revived. A new IP customer payment, with a new transaction reference, may be sent later, or the transfer can go through the SIC RTGS service instead [Inference]. The public guidelines set no retry limit [Unverified]." }, "facts": { "return_windows": [ { "action": "reject the IP customer payment with a Negative IP Feedback (pacs.002 NEG002, status RJCT) carrying this code", "by": "Receiving (instructed) participant, identified by its SIC IID as originator of the feedback", "deadline": "No public deadline is published. The feedback presumably has to reach the SIC IP service before the service's hard time-out [Inference], which counts from the start time the sending participant stamps on the pacs.008 (IP-pacs.008 v2.3, element AccptncDtTm); the time-out value itself is in the participant-only SIC Handbook. The SNB describes instant payments as settled in principle within ten seconds (SNB-R 2025 ch. 6)." }, { "action": "cancel the payment and pass the code on in an IP Cancellation Information (pacs.002 CNC002, status CANC)", "by": "SIC IP service", "deadline": "No public deadline is published. The guideline says the service copies the receiving participant's code into the cancellation notice; how soon that notice goes out is not stated in the public guidelines." } ], "applies_to": "SIC IP service (Swiss franc instant payments, 24/7): the receiving participant's Negative IP Feedback (pacs.002 of type NEG002, status RJCT) on an IP customer payment (pacs.008). The service checks the code against a closed list of 14 and repeats it to the sending side in the IP Cancellation Information (CNC002)." }, "caveat": "The code says the fault lies with the receiving participant, not with the payer's data [Inference]. The sending participant sees the same code in the CNC002, with the receiving participant's SIC IID as originator (IP-pacs.002 v2.4 sections 3.1.6 and 4.3). What the payer is told is up to the sending bank; the SPS pain.002 status codes a Swiss bank customer receives are a separate family and never travel in SIC.", "related": [ "ch-sic-ip-reject:AB05", "ch-sic-ip-reject:MS03", "ch-sic-ip-reject:ED05" ], "basis": { "sources": "IP-pacs.002 v2.4 (SIX Interbank Clearing, Instant Payments Implementation Guidelines, IP Status Report, 2026-02-27, valid from 2026-11-13) sections 3.1.4 and Table 3 (permitted NEG002 codes, checked by the service), 3.1.6 (CNC002 copies the NEG002 code) and 4.3 (elements TxSts, StsRsnInf/Orgtr, Rsn/Cd); IP-pacs.002 v2.3 (2025-02-28, valid from 2025-11-21), same sections; IP-pacs.008 v2.3 (2026-02-27) element AccptncDtTm; SNB Report on the SIC System and Disclosure Report 2025 ch. 6 and footnotes 15 and 16. The code meaning rests on the ISO code name SIX prints in Table 3; the ISO External Code Set itself was not read.", "confidence": "medium" }, "currency": { "effective_since": "Since IP-pacs.002 v2.0 (first production edition)", "effective_note": "A list of permitted NEG002 codes first appears in IP-pacs.002 v1.1 (2022-05-20); v2.0 (2022-10-20) was the first edition for production, valid from the November 2023 release. The code is in v2.3, in force since 2025-11-21 with SIC platform release 5.2, and unchanged in v2.4, valid from 2026-11-13 with release 5.3. SIX plans to move all SIC IP messages to ISO 20022 2024/2025 versions in November 2027 (SIC Platform Release Notes 2026, CR2026-SIC-0002), which may change the list [Speculation].", "source_edition": "IP-pacs.002 v2.3 (2025-02-28, valid from 2025-11-21) and v2.4 (2026-02-27, valid from 2026-11-13)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.six-group.com/dam/download/banking-services/standardization/sic-eurosic/5-3/ig-module-docs-sic-ip-2026-5.3-en.zip", "source_class": "authoritative_primary", "source_title": "IP Status Report (pacs.002) v2.4, SIC IP module documents, release 5.3 archive", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "IP Status Report (pacs.002) v2.4 section 3.1.4 Table 3 lists AB09 among the 14 codes valid in the Reason element of a Negative IP Feedback (NEG002), with the ISO code name ErrorCreditorAgent. Confirms the code sits on the closed list the SIC IP service checks and repeats to the sender in the IP Cancellation Information (CNC002); the table states only the ISO code name, no SIX-authored definition." }, { "source_url": "https://www.iso20022.org/sites/default/files/media/file/ExternalCodeSets_JSON.zip", "source_class": "authoritative_primary", "source_title": "ISO 20022 External Code Sets, 2Q2026, ExternalStatusReason1Code", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "The ISO 20022 External Code Set ExternalStatusReason1Code defines AB09 as a transaction stopped because of an error at the creditor agent. Confirms the record's stated meaning that the fault lies on the receiving participant's own side rather than with the payment data; does not name what kind of error." } ] }, "rail_name": "SIC IP Payment Rejections", "governing_authority": "SIX Interbank Clearing on behalf of the Swiss National Bank", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "ch-sic-ip-reject:AC01", "id": "AC01", "rail": "ch-sic-ip-reject", "kind": "reason-code", "name": "Payee account number not valid", "group": "account", "summary": "The receiving participant cannot accept the IP customer payment because the payee's account number is wrong. The SNB gives an invalid account number as its example of why a receiving bank says no.", "triggers": [ "The creditor IBAN in the pacs.008 does not exist at the receiving participant or fails its checks [Inference from the ISO code name IncorrectAccountNumber]", "The SNB names an invalid account number for the final recipient as one example of a negative response (SNB-R 2025 ch. 6 footnote 15)" ], "actions": [ "Sending participant: once the CNC002 arrives, treat the payment as not executed, free the amount it had reserved for the payer [Inference: the SNB says the amount is reserved first and the payment is cancelled on a negative answer], and tell the payer straight away, with the reason where the law allows (SNB-R 2025 ch. 6 footnotes 15 and 16)", "Sending participant: ask the payer to confirm the payee's IBAN before any new payment", "Payer: get the correct account details from the payee" ], "retry": { "allowed": false, "rule": "Not with the same account details. A new IP customer payment with corrected creditor details may be sent [Inference]." }, "facts": { "return_windows": [ { "action": "reject the IP customer payment with a Negative IP Feedback (pacs.002 NEG002, status RJCT) carrying this code", "by": "Receiving (instructed) participant, identified by its SIC IID as originator of the feedback", "deadline": "No public deadline is published. The feedback presumably has to reach the SIC IP service before the service's hard time-out [Inference], which counts from the start time the sending participant stamps on the pacs.008 (IP-pacs.008 v2.3, element AccptncDtTm); the time-out value itself is in the participant-only SIC Handbook. The SNB describes instant payments as settled in principle within ten seconds (SNB-R 2025 ch. 6)." }, { "action": "cancel the payment and pass the code on in an IP Cancellation Information (pacs.002 CNC002, status CANC)", "by": "SIC IP service", "deadline": "No public deadline is published. The guideline says the service copies the receiving participant's code into the cancellation notice; how soon that notice goes out is not stated in the public guidelines." } ], "applies_to": "SIC IP service (Swiss franc instant payments, 24/7): the receiving participant's Negative IP Feedback (pacs.002 of type NEG002, status RJCT) on an IP customer payment (pacs.008). The service checks the code against a closed list of 14 and repeats it to the sending side in the IP Cancellation Information (CNC002)." }, "caveat": "SIC IP carries only CHF payments to an IBAN (IP-pacs.008 v2.3). AC01 here is the receiving bank refusing an instant payment; AC01 in the SPS pain.002 list is a different check on a customer's file. The sending participant sees the same code in the CNC002, with the receiving participant's SIC IID as originator (IP-pacs.002 v2.4 sections 3.1.6 and 4.3). What the payer is told is up to the sending bank; the SPS pain.002 status codes a Swiss bank customer receives are a separate family and never travel in SIC.", "related": [ "ch-sic-ip-reject:AG01", "ch-sic-ip-reject:RC01", "ch-sic-ip-return-request:AC03" ], "basis": { "sources": "IP-pacs.002 v2.4 (SIX Interbank Clearing, Instant Payments Implementation Guidelines, IP Status Report, 2026-02-27, valid from 2026-11-13) sections 3.1.4 and Table 3 (permitted NEG002 codes, checked by the service), 3.1.6 (CNC002 copies the NEG002 code) and 4.3 (elements TxSts, StsRsnInf/Orgtr, Rsn/Cd); IP-pacs.002 v2.3 (2025-02-28, valid from 2025-11-21), same sections; IP-pacs.008 v2.3 (2026-02-27) element AccptncDtTm; SNB Report on the SIC System and Disclosure Report 2025 ch. 6 and footnotes 15 and 16. The code meaning rests on the ISO code name SIX prints in Table 3; the ISO External Code Set itself was not read.", "confidence": "medium" }, "currency": { "effective_since": "Since IP-pacs.002 v2.0 (first production edition)", "effective_note": "A list of permitted NEG002 codes first appears in IP-pacs.002 v1.1 (2022-05-20); v2.0 (2022-10-20) was the first edition for production, valid from the November 2023 release. The code is in v2.3, in force since 2025-11-21 with SIC platform release 5.2, and unchanged in v2.4, valid from 2026-11-13 with release 5.3. SIX plans to move all SIC IP messages to ISO 20022 2024/2025 versions in November 2027 (SIC Platform Release Notes 2026, CR2026-SIC-0002), which may change the list [Speculation].", "source_edition": "IP-pacs.002 v2.3 (2025-02-28, valid from 2025-11-21) and v2.4 (2026-02-27, valid from 2026-11-13)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.six-group.com/dam/download/banking-services/standardization/sic-eurosic/5-3/ig-module-docs-sic-ip-2026-5.3-en.zip", "source_class": "authoritative_primary", "source_title": "IP Status Report (pacs.002) v2.4, SIC IP module documents, release 5.3 archive", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "IP Status Report (pacs.002) v2.4 section 3.1.4 Table 3 lists AC01 among the 14 codes valid in the Reason element of a Negative IP Feedback (NEG002), with the ISO code name IncorrectAccountNumber. Confirms the code sits on the closed list the SIC IP service checks and repeats to the sender in the IP Cancellation Information (CNC002); the table states only the ISO code name, no SIX-authored definition." }, { "source_url": "https://www.iso20022.org/sites/default/files/media/file/ExternalCodeSets_JSON.zip", "source_class": "authoritative_primary", "source_title": "ISO 20022 External Code Sets, 2Q2026, ExternalStatusReason1Code", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "The ISO 20022 External Code Set ExternalStatusReason1Code defines AC01 as an account number that is invalid or missing. Confirms the record's stated meaning that the payee's account number is the problem; the record's trigger about the account failing checks covers an invalid number but does not separately name a missing account number, so that half of the ISO definition is not distinguished in the record." } ] }, "rail_name": "SIC IP Payment Rejections", "governing_authority": "SIX Interbank Clearing on behalf of the Swiss National Bank", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "ch-sic-ip-reject:AG01", "id": "AG01", "rail": "ch-sic-ip-reject", "kind": "reason-code", "name": "Payee account may not take this payment", "group": "account", "summary": "The receiving participant rejects because the payee's account is not allowed to receive this transaction. SIX added the code to the permitted list with release 5.2.", "triggers": [ "The creditor account is blocked, restricted, or of a kind that cannot take this transaction [Inference from the ISO code name TransactionForbidden]" ], "actions": [ "Sending participant: once the CNC002 arrives, treat the payment as not executed, free the amount it had reserved for the payer [Inference: the SNB says the amount is reserved first and the payment is cancelled on a negative answer], and tell the payer straight away, with the reason where the law allows (SNB-R 2025 ch. 6 footnotes 15 and 16)", "Payer: ask the payee for another account or another way to pay", "Sending participant: do not resend to the same account [Inference]" ], "retry": { "allowed": false, "rule": "Not to the same account. A new payment to a different account, or by another route agreed with the payee, is a fresh instruction [Inference]." }, "facts": { "return_windows": [ { "action": "reject the IP customer payment with a Negative IP Feedback (pacs.002 NEG002, status RJCT) carrying this code", "by": "Receiving (instructed) participant, identified by its SIC IID as originator of the feedback", "deadline": "No public deadline is published. The feedback presumably has to reach the SIC IP service before the service's hard time-out [Inference], which counts from the start time the sending participant stamps on the pacs.008 (IP-pacs.008 v2.3, element AccptncDtTm); the time-out value itself is in the participant-only SIC Handbook. The SNB describes instant payments as settled in principle within ten seconds (SNB-R 2025 ch. 6)." }, { "action": "cancel the payment and pass the code on in an IP Cancellation Information (pacs.002 CNC002, status CANC)", "by": "SIC IP service", "deadline": "No public deadline is published. The guideline says the service copies the receiving participant's code into the cancellation notice; how soon that notice goes out is not stated in the public guidelines." } ], "applies_to": "SIC IP service (Swiss franc instant payments, 24/7): the receiving participant's Negative IP Feedback (pacs.002 of type NEG002, status RJCT) on an IP customer payment (pacs.008). The service checks the code against a closed list of 14 and repeats it to the sending side in the IP Cancellation Information (CNC002)." }, "caveat": "SIX added AG01 under change request CR2025-SIC5-0019 (IP-pacs.002 v2.3 change history, section 3.1.4). The sending participant sees the same code in the CNC002, with the receiving participant's SIC IID as originator (IP-pacs.002 v2.4 sections 3.1.6 and 4.3). What the payer is told is up to the sending bank; the SPS pain.002 status codes a Swiss bank customer receives are a separate family and never travel in SIC.", "related": [ "ch-sic-ip-reject:AC01", "ch-sic-ip-reject:MS03" ], "basis": { "sources": "IP-pacs.002 v2.4 (SIX Interbank Clearing, Instant Payments Implementation Guidelines, IP Status Report, 2026-02-27, valid from 2026-11-13) sections 3.1.4 and Table 3 (permitted NEG002 codes, checked by the service), 3.1.6 (CNC002 copies the NEG002 code) and 4.3 (elements TxSts, StsRsnInf/Orgtr, Rsn/Cd); IP-pacs.002 v2.3 (2025-02-28, valid from 2025-11-21), same sections; IP-pacs.008 v2.3 (2026-02-27) element AccptncDtTm; SNB Report on the SIC System and Disclosure Report 2025 ch. 6 and footnotes 15 and 16. The code meaning rests on the ISO code name SIX prints in Table 3; the ISO External Code Set itself was not read.", "confidence": "medium" }, "currency": { "effective_since": "2025-11-21", "effective_note": "Added to the NEG002 list by IP-pacs.002 v2.3 (2025-02-28, CR2025-SIC5-0019), valid from 2025-11-21 with SIC platform release 5.2. Unchanged in v2.4, valid from 2026-11-13 with release 5.3. SIX plans to move all SIC IP messages to ISO 20022 2024/2025 versions in November 2027 (SIC Platform Release Notes 2026, CR2026-SIC-0002), which may change the list [Speculation].", "source_edition": "IP-pacs.002 v2.3 (2025-02-28, valid from 2025-11-21) and v2.4 (2026-02-27, valid from 2026-11-13)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.six-group.com/dam/download/banking-services/standardization/sic-eurosic/5-3/ig-module-docs-sic-ip-2026-5.3-en.zip", "source_class": "authoritative_primary", "source_title": "IP Status Report (pacs.002) v2.4, SIC IP module documents, release 5.3 archive", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "IP Status Report (pacs.002) v2.4 section 3.1.4 Table 3 lists AG01 among the 14 codes valid in the Reason element of a Negative IP Feedback (NEG002), with the ISO code name TransactionForbidden, added to the list with version 2.3 under change request CR2025-SIC5-0019. Confirms the code sits on the closed list the SIC IP service checks and repeats to the sender in the IP Cancellation Information (CNC002); the table states only the ISO code name, no SIX-authored definition." }, { "source_url": "https://www.iso20022.org/sites/default/files/media/file/ExternalCodeSets_JSON.zip", "source_class": "authoritative_primary", "source_title": "ISO 20022 External Code Sets, 2Q2026, ExternalStatusReason1Code", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "The ISO 20022 External Code Set ExternalStatusReason1Code defines AG01, formerly named NoAgreement, as a transaction forbidden on this type of account. Confirms the record's stated meaning that the payee's account cannot take this kind of payment; the record's trigger also mentions a blocked or restricted account, which the ISO definition does not state and which the record already carries as a labelled inference." } ] }, "rail_name": "SIC IP Payment Rejections", "governing_authority": "SIX Interbank Clearing on behalf of the Swiss National Bank", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "ch-sic-ip-reject:AG02", "id": "AG02", "rail": "ch-sic-ip-reject", "kind": "reason-code", "name": "Operation code not accepted", "group": "technical", "summary": "The receiving participant rejects the IP customer payment because a code describing the kind of operation is not one it can process.", "triggers": [ "The payment carries an operation or transaction type code the receiving participant does not accept [Inference from the ISO code name InvalidBankOperationCode]", "Which pacs.008 element this points to in SIC IP is not stated in the public guidelines [Unverified]" ], "actions": [ "Sending participant: once the CNC002 arrives, treat the payment as not executed, free the amount it had reserved for the payer [Inference: the SNB says the amount is reserved first and the payment is cancelled on a negative answer], and tell the payer straight away, with the reason where the law allows (SNB-R 2025 ch. 6 footnotes 15 and 16)", "Sending participant: check how its system fills the payment type fields of the pacs.008 against IP-pacs.008 before sending again" ], "retry": { "allowed": false, "rule": "Not unchanged. Once the coding is corrected, a new IP customer payment may be sent [Inference]." }, "facts": { "return_windows": [ { "action": "reject the IP customer payment with a Negative IP Feedback (pacs.002 NEG002, status RJCT) carrying this code", "by": "Receiving (instructed) participant, identified by its SIC IID as originator of the feedback", "deadline": "No public deadline is published. The feedback presumably has to reach the SIC IP service before the service's hard time-out [Inference], which counts from the start time the sending participant stamps on the pacs.008 (IP-pacs.008 v2.3, element AccptncDtTm); the time-out value itself is in the participant-only SIC Handbook. The SNB describes instant payments as settled in principle within ten seconds (SNB-R 2025 ch. 6)." }, { "action": "cancel the payment and pass the code on in an IP Cancellation Information (pacs.002 CNC002, status CANC)", "by": "SIC IP service", "deadline": "No public deadline is published. The guideline says the service copies the receiving participant's code into the cancellation notice; how soon that notice goes out is not stated in the public guidelines." } ], "applies_to": "SIC IP service (Swiss franc instant payments, 24/7): the receiving participant's Negative IP Feedback (pacs.002 of type NEG002, status RJCT) on an IP customer payment (pacs.008). The service checks the code against a closed list of 14 and repeats it to the sending side in the IP Cancellation Information (CNC002)." }, "caveat": "The SIC IP service itself checks the IP payment type code on submission, so AG02 comes from the receiving participant's own checks [Inference]. The sending participant sees the same code in the CNC002, with the receiving participant's SIC IID as originator (IP-pacs.002 v2.4 sections 3.1.6 and 4.3). What the payer is told is up to the sending bank; the SPS pain.002 status codes a Swiss bank customer receives are a separate family and never travel in SIC.", "related": [ "ch-sic-ip-reject:AB09", "ch-sic-ip-reject:RC01" ], "basis": { "sources": "IP-pacs.002 v2.4 (SIX Interbank Clearing, Instant Payments Implementation Guidelines, IP Status Report, 2026-02-27, valid from 2026-11-13) sections 3.1.4 and Table 3 (permitted NEG002 codes, checked by the service), 3.1.6 (CNC002 copies the NEG002 code) and 4.3 (elements TxSts, StsRsnInf/Orgtr, Rsn/Cd); IP-pacs.002 v2.3 (2025-02-28, valid from 2025-11-21), same sections; IP-pacs.008 v2.3 (2026-02-27) element AccptncDtTm; SNB Report on the SIC System and Disclosure Report 2025 ch. 6 and footnotes 15 and 16. The code meaning rests on the ISO code name SIX prints in Table 3; the ISO External Code Set itself was not read.", "confidence": "medium" }, "currency": { "effective_since": "Since IP-pacs.002 v2.0 (first production edition)", "effective_note": "A list of permitted NEG002 codes first appears in IP-pacs.002 v1.1 (2022-05-20); v2.0 (2022-10-20) was the first edition for production, valid from the November 2023 release. The code is in v2.3, in force since 2025-11-21 with SIC platform release 5.2, and unchanged in v2.4, valid from 2026-11-13 with release 5.3. SIX plans to move all SIC IP messages to ISO 20022 2024/2025 versions in November 2027 (SIC Platform Release Notes 2026, CR2026-SIC-0002), which may change the list [Speculation].", "source_edition": "IP-pacs.002 v2.3 (2025-02-28, valid from 2025-11-21) and v2.4 (2026-02-27, valid from 2026-11-13)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.six-group.com/dam/download/banking-services/standardization/sic-eurosic/5-3/ig-module-docs-sic-ip-2026-5.3-en.zip", "source_class": "authoritative_primary", "source_title": "IP Status Report (pacs.002) v2.4, SIC IP module documents, release 5.3 archive", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "IP Status Report (pacs.002) v2.4 section 3.1.4 Table 3 lists AG02 among the 14 codes valid in the Reason element of a Negative IP Feedback (NEG002), with the ISO code name InvalidBankOperationCode. Confirms the code sits on the closed list the SIC IP service checks and repeats to the sender in the IP Cancellation Information (CNC002); the table states only the ISO code name, no SIX-authored definition." }, { "source_url": "https://www.iso20022.org/sites/default/files/media/file/ExternalCodeSets_JSON.zip", "source_class": "authoritative_primary", "source_title": "ISO 20022 External Code Sets, 2Q2026, ExternalStatusReason1Code", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "The ISO 20022 External Code Set ExternalStatusReason1Code defines AG02 as a bank operation code specified in the message that is not valid for the receiver. Confirms the record's stated meaning that the payment carries an operation or transaction type code the receiving participant does not accept; does not say which pacs.008 element carries that code in SIC IP, which the record already marks unverified." } ] }, "rail_name": "SIC IP Payment Rejections", "governing_authority": "SIX Interbank Clearing on behalf of the Swiss National Bank", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "ch-sic-ip-reject:AM02", "id": "AM02", "rail": "ch-sic-ip-reject", "kind": "reason-code", "name": "Amount not accepted", "group": "administrative", "summary": "The receiving participant rejects the IP customer payment because the amount is more than it will accept for this payment.", "triggers": [ "The amount is above what the receiving participant accepts [Inference from the ISO code name NotAllowedAmount]", "The SNB reports a limit of CHF 20,000 per instant payment in the IP service, which participants may raise between themselves (SNB-R 2025, principle 7); whether a receiving participant uses AM02 for an amount above its agreed limit is not stated [Unverified]" ], "actions": [ "Sending participant: once the CNC002 arrives, treat the payment as not executed, free the amount it had reserved for the payer [Inference: the SNB says the amount is reserved first and the payment is cancelled on a negative answer], and tell the payer straight away, with the reason where the law allows (SNB-R 2025 ch. 6 footnotes 15 and 16)", "Sending participant: offer the payer the SIC RTGS service for the amount instead of the instant route" ], "retry": { "allowed": false, "rule": "Not with the same amount over the instant route. The payment can go through the SIC RTGS service instead [Inference]." }, "facts": { "return_windows": [ { "action": "reject the IP customer payment with a Negative IP Feedback (pacs.002 NEG002, status RJCT) carrying this code", "by": "Receiving (instructed) participant, identified by its SIC IID as originator of the feedback", "deadline": "No public deadline is published. The feedback presumably has to reach the SIC IP service before the service's hard time-out [Inference], which counts from the start time the sending participant stamps on the pacs.008 (IP-pacs.008 v2.3, element AccptncDtTm); the time-out value itself is in the participant-only SIC Handbook. The SNB describes instant payments as settled in principle within ten seconds (SNB-R 2025 ch. 6)." }, { "action": "cancel the payment and pass the code on in an IP Cancellation Information (pacs.002 CNC002, status CANC)", "by": "SIC IP service", "deadline": "No public deadline is published. The guideline says the service copies the receiving participant's code into the cancellation notice; how soon that notice goes out is not stated in the public guidelines." } ], "applies_to": "SIC IP service (Swiss franc instant payments, 24/7): the receiving participant's Negative IP Feedback (pacs.002 of type NEG002, status RJCT) on an IP customer payment (pacs.008). The service checks the code against a closed list of 14 and repeats it to the sending side in the IP Cancellation Information (CNC002)." }, "caveat": "The CHF 20,000 figure comes from the SNB's disclosure report, not from a public rule text; the governing text is in the participant-only SIC Handbook [Unverified]. The sending participant sees the same code in the CNC002, with the receiving participant's SIC IID as originator (IP-pacs.002 v2.4 sections 3.1.6 and 4.3). What the payer is told is up to the sending bank; the SPS pain.002 status codes a Swiss bank customer receives are a separate family and never travel in SIC.", "related": [ "ch-sic-ip-reject:MS03", "ch-sic-ip-reject:AG01" ], "basis": { "sources": "IP-pacs.002 v2.4 (SIX Interbank Clearing, Instant Payments Implementation Guidelines, IP Status Report, 2026-02-27, valid from 2026-11-13) sections 3.1.4 and Table 3 (permitted NEG002 codes, checked by the service), 3.1.6 (CNC002 copies the NEG002 code) and 4.3 (elements TxSts, StsRsnInf/Orgtr, Rsn/Cd); IP-pacs.002 v2.3 (2025-02-28, valid from 2025-11-21), same sections; IP-pacs.008 v2.3 (2026-02-27) element AccptncDtTm; SNB Report on the SIC System and Disclosure Report 2025 ch. 6 and footnotes 15 and 16. The code meaning rests on the ISO code name SIX prints in Table 3; the ISO External Code Set itself was not read.", "confidence": "medium" }, "currency": { "effective_since": "Since IP-pacs.002 v2.0 (first production edition)", "effective_note": "A list of permitted NEG002 codes first appears in IP-pacs.002 v1.1 (2022-05-20); v2.0 (2022-10-20) was the first edition for production, valid from the November 2023 release. The code is in v2.3, in force since 2025-11-21 with SIC platform release 5.2, and unchanged in v2.4, valid from 2026-11-13 with release 5.3. SIX plans to move all SIC IP messages to ISO 20022 2024/2025 versions in November 2027 (SIC Platform Release Notes 2026, CR2026-SIC-0002), which may change the list [Speculation].", "source_edition": "IP-pacs.002 v2.3 (2025-02-28, valid from 2025-11-21) and v2.4 (2026-02-27, valid from 2026-11-13)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.six-group.com/dam/download/banking-services/standardization/sic-eurosic/5-3/ig-module-docs-sic-ip-2026-5.3-en.zip", "source_class": "authoritative_primary", "source_title": "IP Status Report (pacs.002) v2.4, SIC IP module documents, release 5.3 archive", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "IP Status Report (pacs.002) v2.4 section 3.1.4 Table 3 lists AM02 among the 14 codes valid in the Reason element of a Negative IP Feedback (NEG002), with the ISO code name NotAllowedAmount. Confirms the code sits on the closed list the SIC IP service checks and repeats to the sender in the IP Cancellation Information (CNC002); the table states only the ISO code name, no SIX-authored definition." }, { "source_url": "https://www.iso20022.org/sites/default/files/media/file/ExternalCodeSets_JSON.zip", "source_class": "authoritative_primary", "source_title": "ISO 20022 External Code Sets, 2Q2026, ExternalStatusReason1Code", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "The ISO 20022 External Code Set ExternalStatusReason1Code defines AM02 as a transaction or message amount greater than the allowed maximum. Confirms the record's stated meaning that the amount is above what the receiving participant accepts; does not say what that maximum is or whether it is the CHF 20,000 SIC IP limit, which the record already marks unverified." } ] }, "rail_name": "SIC IP Payment Rejections", "governing_authority": "SIX Interbank Clearing on behalf of the Swiss National Bank", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "ch-sic-ip-reject:AM05", "id": "AM05", "rail": "ch-sic-ip-reject", "kind": "reason-code", "name": "Payment already received", "group": "administrative", "summary": "The receiving participant rejects the IP customer payment as a duplicate of one it already has.", "triggers": [ "The receiving participant finds a payment it has already received with the same details [Inference from the ISO code name Duplication]" ], "actions": [ "Sending participant: before anything else, check whether the first payment settled (an IP Execution Confirmation, EXC002, for it) [Inference]", "Sending participant: tell the payer that the second payment did not go through; if the first one also did not settle, send a fresh payment [Inference]", "Sending participant: if two payments did settle, ask for one back with an IP return request coded DUPL" ], "retry": { "allowed": false, "rule": "The duplicate is not resent. Only if the first payment turns out not to have settled is a new payment sent [Inference]." }, "facts": { "return_windows": [ { "action": "reject the IP customer payment with a Negative IP Feedback (pacs.002 NEG002, status RJCT) carrying this code", "by": "Receiving (instructed) participant, identified by its SIC IID as originator of the feedback", "deadline": "No public deadline is published. The feedback presumably has to reach the SIC IP service before the service's hard time-out [Inference], which counts from the start time the sending participant stamps on the pacs.008 (IP-pacs.008 v2.3, element AccptncDtTm); the time-out value itself is in the participant-only SIC Handbook. The SNB describes instant payments as settled in principle within ten seconds (SNB-R 2025 ch. 6)." }, { "action": "cancel the payment and pass the code on in an IP Cancellation Information (pacs.002 CNC002, status CANC)", "by": "SIC IP service", "deadline": "No public deadline is published. The guideline says the service copies the receiving participant's code into the cancellation notice; how soon that notice goes out is not stated in the public guidelines." } ], "applies_to": "SIC IP service (Swiss franc instant payments, 24/7): the receiving participant's Negative IP Feedback (pacs.002 of type NEG002, status RJCT) on an IP customer payment (pacs.008). The service checks the code against a closed list of 14 and repeats it to the sending side in the IP Cancellation Information (CNC002)." }, "caveat": "The SIC IP service runs its own duplicate checks on message and transaction references; AM05 is the receiving participant's check, which may use other criteria [Unverified]. The sending participant sees the same code in the CNC002, with the receiving participant's SIC IID as originator (IP-pacs.002 v2.4 sections 3.1.6 and 4.3). What the payer is told is up to the sending bank; the SPS pain.002 status codes a Swiss bank customer receives are a separate family and never travel in SIC.", "related": [ "ch-sic-ip-reject:MS03", "ch-sic-ip-return-request:DUPL" ], "basis": { "sources": "IP-pacs.002 v2.4 (SIX Interbank Clearing, Instant Payments Implementation Guidelines, IP Status Report, 2026-02-27, valid from 2026-11-13) sections 3.1.4 and Table 3 (permitted NEG002 codes, checked by the service), 3.1.6 (CNC002 copies the NEG002 code) and 4.3 (elements TxSts, StsRsnInf/Orgtr, Rsn/Cd); IP-pacs.002 v2.3 (2025-02-28, valid from 2025-11-21), same sections; IP-pacs.008 v2.3 (2026-02-27) element AccptncDtTm; SNB Report on the SIC System and Disclosure Report 2025 ch. 6 and footnotes 15 and 16. The code meaning rests on the ISO code name SIX prints in Table 3; the ISO External Code Set itself was not read.", "confidence": "medium" }, "currency": { "effective_since": "Since IP-pacs.002 v2.0 (first production edition)", "effective_note": "A list of permitted NEG002 codes first appears in IP-pacs.002 v1.1 (2022-05-20); v2.0 (2022-10-20) was the first edition for production, valid from the November 2023 release. The code is in v2.3, in force since 2025-11-21 with SIC platform release 5.2, and unchanged in v2.4, valid from 2026-11-13 with release 5.3. SIX plans to move all SIC IP messages to ISO 20022 2024/2025 versions in November 2027 (SIC Platform Release Notes 2026, CR2026-SIC-0002), which may change the list [Speculation].", "source_edition": "IP-pacs.002 v2.3 (2025-02-28, valid from 2025-11-21) and v2.4 (2026-02-27, valid from 2026-11-13)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.six-group.com/dam/download/banking-services/standardization/sic-eurosic/5-3/ig-module-docs-sic-ip-2026-5.3-en.zip", "source_class": "authoritative_primary", "source_title": "IP Status Report (pacs.002) v2.4, SIC IP module documents, release 5.3 archive", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "IP Status Report (pacs.002) v2.4 section 3.1.4 Table 3 lists AM05 among the 14 codes valid in the Reason element of a Negative IP Feedback (NEG002), with the ISO code name Duplication. Confirms the code sits on the closed list the SIC IP service checks and repeats to the sender in the IP Cancellation Information (CNC002); the table states only the ISO code name, no SIX-authored definition." }, { "source_url": "https://www.iso20022.org/sites/default/files/media/file/ExternalCodeSets_JSON.zip", "source_class": "authoritative_primary", "source_title": "ISO 20022 External Code Sets, 2Q2026, ExternalStatusReason1Code", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "The ISO 20022 External Code Set ExternalStatusReason1Code defines AM05 with the single word Duplication and no further elaboration. Confirms the code concerns a duplicate payment; does not confirm or contradict the record's inference that the receiving participant is comparing the payment against one it has already received with the same details, which stays a labelled inference." } ] }, "rail_name": "SIC IP Payment Rejections", "governing_authority": "SIX Interbank Clearing on behalf of the Swiss National Bank", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "ch-sic-ip-reject:ED05", "id": "ED05", "rail": "ch-sic-ip-reject", "kind": "reason-code", "name": "SIC IP cancelled: settlement failed", "group": "network", "summary": "The SIC IP service cancels an IP customer payment because settlement could not be completed, and tells the participant with a CNC002 carrying ED05. It can come after the receiving participant has already accepted the payment.", "triggers": [ "Settlement in the SIC IP service fails for the payment [IP-pacs.002 v2.4 section 4.3]", "The case can follow a positive feedback: an earlier definition tied ED05 to failure despite a positive IP feedback, and v2.2 widened it to cover several situations (IP-pacs.002 v2.4 change history, versions 1.1 and 2.2)", "Which situations count as failed settlement is not listed publicly; the detail is in the participant-only SIC Handbook [Unverified]" ], "actions": [ "Sending participant: treat the payment as not executed, free any reserved amount, and tell the payer at once (SNB-R 2025 ch. 6 footnote 16) [Inference]", "Receiving participant: a positive feedback confirms the funds were made available to the payee (IP-pacs.002 v2.4 section 3.1.3), so after ED05 it must deal with a credit given without settlement under its own terms [Inference: whether the receiving participant also gets the CNC002, and how the credit is reversed, is not in the public guidelines]", "Both participants: reconcile against the IP Execution Confirmation (EXC002); a payment with ED05 has none [Inference]" ], "retry": { "allowed": true, "rule": "The cancelled payment stays cancelled and cannot be revived. A new IP customer payment, with a new transaction reference, may be sent later, or the transfer can go through the SIC RTGS service instead [Inference]. The public guidelines set no retry limit [Unverified]." }, "facts": { "return_windows": [ { "action": "cancel the payment with an IP Cancellation Information (pacs.002 CNC002, status CANC) carrying ED05", "by": "SIC IP service, with the SIC IID of SIC Ltd (099990) as originator", "deadline": "No public deadline is published. The public guidelines do not say when the service gives up on settlement; that detail is in the participant-only SIC Handbook." } ], "applies_to": "SIC IP service: the IP Cancellation Information (pacs.002 of type CNC002, status CANC) that the service itself sends when it cancels an IP customer payment (pacs.008)." }, "caveat": "The SNB says IP payments settle only if the sending participant's IP settlement account has enough cover (SNB-R 2025 ch. 6); whether lack of cover is one of the ED05 cases is not stated [Unverified]. ED05 in Pix and SEPA is a different scheme's code with its own meaning.", "related": [ "ch-sic-ip-reject:TM01", "ch-sic-ip-reject:AB09" ], "basis": { "sources": "IP-pacs.002 v2.4 (2026-02-27, valid from 2026-11-13) sections 3.1.3, 3.1.6 and 4.3 (elements TxSts, StsRsnInf/Orgtr/Id, Rsn/Cd for CNC002) and change history for versions 1.1 and 2.2; IP-pacs.002 v2.3 (2025-02-28, valid from 2025-11-21), same sections; IP-pacs.008 v2.3 (2026-02-27) element AccptncDtTm; IP-pacs.028 v2.3 (2025-02-28) section 3.1.1; SNB Report on the SIC System and Disclosure Report 2025 ch. 6 and footnote 16.", "confidence": "high" }, "currency": { "effective_since": "Since IP-pacs.002 v2.0 (first production edition)", "effective_note": "The code is a CNC002 reason in IP-pacs.002 v2.3, in force since 2025-11-21 with SIC platform release 5.2, and unchanged in v2.4, valid from 2026-11-13 with release 5.3. The v1.1 change history (2022-05-20) already revises its definition, so it predates the first production edition. SIX plans to move all SIC IP messages to ISO 20022 2024/2025 versions in November 2027 (SIC Platform Release Notes 2026, CR2026-SIC-0002) [Speculation whether this code changes].", "source_edition": "IP-pacs.002 v2.3 (2025-02-28, valid from 2025-11-21) and v2.4 (2026-02-27, valid from 2026-11-13)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.six-group.com/dam/download/banking-services/standardization/sic-eurosic/5-3/ig-module-docs-sic-ip-2026-5.3-en.zip", "source_class": "authoritative_primary", "source_title": "IP Status Report (pacs.002) v2.4, SIC IP module documents, release 5.3 archive", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "The IP Status Report guide lists ED05 among the codes the SIC IP service itself uses in an IP Cancellation Information, and describes it in its own words as cancellation due to failed settlement, distinct from TM01 for a hard time out. Confirms the code sits on the closed CNC002 list, confirms its stated meaning, and confirms the guide sets no public deadline for when the service gives up on settlement." } ] }, "rail_name": "SIC IP Payment Rejections", "governing_authority": "SIX Interbank Clearing on behalf of the Swiss National Bank", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "ch-sic-ip-reject:ED06", "id": "ED06", "rail": "ch-sic-ip-reject", "kind": "reason-code", "name": "SIC IP cancelled a transfer out of SIC IP", "group": "network", "summary": "Until release 5.3 on 2026-11-13, the SIC IP service uses ED06 to tell a participant that it cancelled that participant's own liquidity transfer out of the IP service. It is not a customer payment code, and it is withdrawn from 2026-11-13, after which cancellation notices cover only IP customer payments.", "triggers": [ "The SIC IP service cancels a transfer payment from the SIC IP service (pacs.009, payment type IPLQTF) that the participant submitted to move liquidity from its IP settlement account to its RTGS settlement account (IP-pacs.002 v2.3 sections 3.1.6 and 4.3; IP-pacs.009 v2.3 section 3.1)", "Why the service cancels such a transfer is not stated in the public guidelines [Unverified]; lack of cover on the IP settlement account is one possibility [Speculation]" ], "actions": [ "Participant (liquidity management): the funds stayed on the IP settlement account; check the RTGS position and submit a new transfer if liquidity is still needed there [Inference]", "Participant: expect no ED06 after 2026-11-13; SIX changed how transfer payments are handled under CR2026-SIC-0005, and the release notes point to an extranet document for the new process (SIC Platform Release Notes 2026 v1.3 section 4.2.3)", "Systems teams: keep ED06 readable for notices dated before 2026-11-13 and for archives [Inference]" ], "retry": { "allowed": true, "rule": "The cancelled transfer is not revived. A new transfer payment from the SIC IP service may be submitted [Inference]. The public guidelines set no retry limit [Unverified]." }, "facts": { "return_windows": [ { "action": "cancel a transfer payment from the SIC IP service with an IP Cancellation Information (pacs.002 CNC002, status CANC) carrying ED06", "by": "SIC IP service", "deadline": "No public deadline is published. Used only until 2026-11-13; from release 5.3 the service no longer sends ED06 (IP-pacs.002 v2.4 change history and section 4.3)." } ], "applies_to": "SIC IP service, until 2026-11-13 only: the IP Cancellation Information (pacs.002 CNC002, status CANC) for a transfer payment from the SIC IP service (pacs.009, payment type IPLQTF), a participant moving its own liquidity out of the IP service. Not used for customer payments." }, "caveat": "Withdrawn from 2026-11-13 with SIC platform release 5.3: IP-pacs.002 v2.4 limits cancellation information to IP customer payments (section 3.1.6) and drops ED06 from the reason list (section 4.3), as part of CR2026-SIC-0005, the move of the RTGS service to the SIC5 platform. How a failed transfer out of SIC IP is reported after that is described only in an extranet document, which is participant-only.", "related": [ "ch-sic-ip-reject:ED05", "ch-sic-ip-reject:TM01" ], "basis": { "sources": "IP-pacs.002 v2.3 (2025-02-28, valid from 2025-11-21) sections 3.1.6 and 4.3 (CNC002 for pacs.009 and code ED06); IP-pacs.002 v2.4 (2026-02-27, valid from 2026-11-13) change history for version 2.4 (CR2026-SIC-0005) and sections 3.1.6 and 4.3; IP-pacs.009 v2.3 (2026-02-27, valid from 2026-11-13) sections 3.1 and 3.2 (transfer payment from SIC IP service, IPLQTF); SIC Platform Release Notes 2026 v1.3 (dated 2026-09-21) section 4.2.3.", "confidence": "high" }, "currency": { "effective_since": "Listed in the edition in force since release 5.2; first listing not established", "effective_note": "Listed as a CNC002 reason in IP-pacs.002 v2.3 (2025-02-28), in force since 2025-11-21 with SIC platform release 5.2; which edition first listed it was not established. Withdrawn from 2026-11-13: IP-pacs.002 v2.4 (2026-02-27), valid from that date with release 5.3, removes ED06 (change history, CR2026-SIC-0005; section 4.3). Not superseded yet: the monthly watch retires this record once 2026-11-13 has passed.", "source_edition": "IP-pacs.002 v2.3 (2025-02-28, valid from 2025-11-21) and v2.4 (2026-02-27, valid from 2026-11-13)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.six-group.com/dam/download/banking-services/standardization/sic-eurosic/4-12-5-2/ig-module-docs-sic-ip-2025-5.2-en.zip", "source_class": "authoritative_primary", "source_title": "IP Status Report (pacs.002) v2.3, SIC IP module documents, release 5.2 archive", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "The IP Status Report guide in force now lists ED06 among the codes the SIC IP service itself uses in an IP Cancellation Information, and describes it in its own words as the service cancelling a transfer payment from the SIC IP service. Confirms the code is on the current closed CNC002 list, confirms its stated meaning, and confirms the guide sets no public deadline for when the service cancels such a transfer." }, { "source_url": "https://www.six-group.com/dam/download/banking-services/standardization/sic-eurosic/5-3/ig-module-docs-sic-ip-2026-5.3-en.zip", "source_class": "authoritative_primary", "source_title": "IP Status Report (pacs.002) v2.4, SIC IP module documents, release 5.3 archive", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "The IP Status Report guide valid from 13 November 2026 removes the code value ED06 from the list of permitted IP Cancellation Information reasons and states the removal under that edition's change history. Confirms the 2026-11-13 withdrawal date the record states." } ] }, "rail_name": "SIC IP Payment Rejections", "governing_authority": "SIX Interbank Clearing on behalf of the Swiss National Bank", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "ch-sic-ip-reject:MS02", "id": "MS02", "rail": "ch-sic-ip-reject", "kind": "reason-code", "name": "Refused on the payee's side, no reason given", "group": "authorization", "summary": "The receiving participant rejects the IP customer payment for a reason that comes from its customer, the payee, without saying what it is.", "triggers": [ "The payee, or the receiving participant acting on the payee's instructions, declines the payment without a stated reason [Inference from the ISO code name NotSpecifiedReasonCustomerGenerated]" ], "actions": [ "Sending participant: once the CNC002 arrives, treat the payment as not executed, free the amount it had reserved for the payer [Inference: the SNB says the amount is reserved first and the payment is cancelled on a negative answer], and tell the payer straight away, with the reason where the law allows (SNB-R 2025 ch. 6 footnotes 15 and 16)", "Payer: contact the payee to find out why and agree another way to pay" ], "retry": { "allowed": false, "rule": "Not unchanged. Any new attempt should follow contact with the payee [Inference]." }, "facts": { "return_windows": [ { "action": "reject the IP customer payment with a Negative IP Feedback (pacs.002 NEG002, status RJCT) carrying this code", "by": "Receiving (instructed) participant, identified by its SIC IID as originator of the feedback", "deadline": "No public deadline is published. The feedback presumably has to reach the SIC IP service before the service's hard time-out [Inference], which counts from the start time the sending participant stamps on the pacs.008 (IP-pacs.008 v2.3, element AccptncDtTm); the time-out value itself is in the participant-only SIC Handbook. The SNB describes instant payments as settled in principle within ten seconds (SNB-R 2025 ch. 6)." }, { "action": "cancel the payment and pass the code on in an IP Cancellation Information (pacs.002 CNC002, status CANC)", "by": "SIC IP service", "deadline": "No public deadline is published. The guideline says the service copies the receiving participant's code into the cancellation notice; how soon that notice goes out is not stated in the public guidelines." } ], "applies_to": "SIC IP service (Swiss franc instant payments, 24/7): the receiving participant's Negative IP Feedback (pacs.002 of type NEG002, status RJCT) on an IP customer payment (pacs.008). The service checks the code against a closed list of 14 and repeats it to the sending side in the IP Cancellation Information (CNC002)." }, "caveat": "The code tells the sending side nothing about the cause; it only places the refusal on the payee's side [Inference]. The sending participant sees the same code in the CNC002, with the receiving participant's SIC IID as originator (IP-pacs.002 v2.4 sections 3.1.6 and 4.3). What the payer is told is up to the sending bank; the SPS pain.002 status codes a Swiss bank customer receives are a separate family and never travel in SIC.", "related": [ "ch-sic-ip-reject:MS03", "ch-sic-ip-reject:AG01" ], "basis": { "sources": "IP-pacs.002 v2.4 (SIX Interbank Clearing, Instant Payments Implementation Guidelines, IP Status Report, 2026-02-27, valid from 2026-11-13) sections 3.1.4 and Table 3 (permitted NEG002 codes, checked by the service), 3.1.6 (CNC002 copies the NEG002 code) and 4.3 (elements TxSts, StsRsnInf/Orgtr, Rsn/Cd); IP-pacs.002 v2.3 (2025-02-28, valid from 2025-11-21), same sections; IP-pacs.008 v2.3 (2026-02-27) element AccptncDtTm; SNB Report on the SIC System and Disclosure Report 2025 ch. 6 and footnotes 15 and 16. The code meaning rests on the ISO code name SIX prints in Table 3; the ISO External Code Set itself was not read.", "confidence": "medium" }, "currency": { "effective_since": "Since IP-pacs.002 v2.0 (first production edition)", "effective_note": "A list of permitted NEG002 codes first appears in IP-pacs.002 v1.1 (2022-05-20); v2.0 (2022-10-20) was the first edition for production, valid from the November 2023 release. The code is in v2.3, in force since 2025-11-21 with SIC platform release 5.2, and unchanged in v2.4, valid from 2026-11-13 with release 5.3. SIX plans to move all SIC IP messages to ISO 20022 2024/2025 versions in November 2027 (SIC Platform Release Notes 2026, CR2026-SIC-0002), which may change the list [Speculation].", "source_edition": "IP-pacs.002 v2.3 (2025-02-28, valid from 2025-11-21) and v2.4 (2026-02-27, valid from 2026-11-13)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.six-group.com/dam/download/banking-services/standardization/sic-eurosic/5-3/ig-module-docs-sic-ip-2026-5.3-en.zip", "source_class": "authoritative_primary", "source_title": "IP Status Report (pacs.002) v2.4, SIC IP module documents, release 5.3 archive", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "IP Status Report (pacs.002) v2.4 section 3.1.4 Table 3 lists MS02 among the 14 codes valid in the Reason element of a Negative IP Feedback (NEG002), with the ISO code name NotSpecifiedReasonCustomerGenerated. Confirms the code sits on the closed list the SIC IP service checks and repeats to the sender in the IP Cancellation Information (CNC002); the table states only the ISO code name, no SIX-authored definition." }, { "source_url": "https://www.iso20022.org/sites/default/files/media/file/ExternalCodeSets_JSON.zip", "source_class": "authoritative_primary", "source_title": "ISO 20022 External Code Sets, 2Q2026, ExternalStatusReason1Code", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "The ISO 20022 External Code Set ExternalStatusReason1Code defines MS02 as a reason not specified by the end customer. Confirms the record's stated meaning that the refusal originates with the payee and carries no stated reason." } ] }, "rail_name": "SIC IP Payment Rejections", "governing_authority": "SIX Interbank Clearing on behalf of the Swiss National Bank", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "ch-sic-ip-reject:MS03", "id": "MS03", "rail": "ch-sic-ip-reject", "kind": "reason-code", "name": "Refused by the receiving bank, no reason given", "group": "administrative", "summary": "The receiving participant rejects the IP customer payment for a reason of its own that it does not state.", "triggers": [ "The receiving participant refuses for an internal reason it chooses not to give [Inference from the ISO code name NotSpecifiedReasonAgentGenerated]" ], "actions": [ "Sending participant: once the CNC002 arrives, treat the payment as not executed, free the amount it had reserved for the payer [Inference: the SNB says the amount is reserved first and the payment is cancelled on a negative answer], and tell the payer straight away, with the reason where the law allows (SNB-R 2025 ch. 6 footnotes 15 and 16)", "Payer: ask the payee to check with its bank, or use the SIC RTGS service" ], "retry": { "allowed": false, "rule": "Not unchanged over the instant route. The payer may try another route after contacting the payee [Inference]." }, "facts": { "return_windows": [ { "action": "reject the IP customer payment with a Negative IP Feedback (pacs.002 NEG002, status RJCT) carrying this code", "by": "Receiving (instructed) participant, identified by its SIC IID as originator of the feedback", "deadline": "No public deadline is published. The feedback presumably has to reach the SIC IP service before the service's hard time-out [Inference], which counts from the start time the sending participant stamps on the pacs.008 (IP-pacs.008 v2.3, element AccptncDtTm); the time-out value itself is in the participant-only SIC Handbook. The SNB describes instant payments as settled in principle within ten seconds (SNB-R 2025 ch. 6)." }, { "action": "cancel the payment and pass the code on in an IP Cancellation Information (pacs.002 CNC002, status CANC)", "by": "SIC IP service", "deadline": "No public deadline is published. The guideline says the service copies the receiving participant's code into the cancellation notice; how soon that notice goes out is not stated in the public guidelines." } ], "applies_to": "SIC IP service (Swiss franc instant payments, 24/7): the receiving participant's Negative IP Feedback (pacs.002 of type NEG002, status RJCT) on an IP customer payment (pacs.008). The service checks the code against a closed list of 14 and repeats it to the sending side in the IP Cancellation Information (CNC002)." }, "caveat": "MS03 in the SPS pain.002 list is a bank telling its own customer about a file; here it is a bank-to-bank refusal of an instant payment. The two are not the same record. The sending participant sees the same code in the CNC002, with the receiving participant's SIC IID as originator (IP-pacs.002 v2.4 sections 3.1.6 and 4.3). What the payer is told is up to the sending bank; the SPS pain.002 status codes a Swiss bank customer receives are a separate family and never travel in SIC.", "related": [ "ch-sic-ip-reject:MS02", "ch-sic-ip-reject:AB09", "ch-sic-ip-reject:RR04" ], "basis": { "sources": "IP-pacs.002 v2.4 (SIX Interbank Clearing, Instant Payments Implementation Guidelines, IP Status Report, 2026-02-27, valid from 2026-11-13) sections 3.1.4 and Table 3 (permitted NEG002 codes, checked by the service), 3.1.6 (CNC002 copies the NEG002 code) and 4.3 (elements TxSts, StsRsnInf/Orgtr, Rsn/Cd); IP-pacs.002 v2.3 (2025-02-28, valid from 2025-11-21), same sections; IP-pacs.008 v2.3 (2026-02-27) element AccptncDtTm; SNB Report on the SIC System and Disclosure Report 2025 ch. 6 and footnotes 15 and 16. The code meaning rests on the ISO code name SIX prints in Table 3; the ISO External Code Set itself was not read.", "confidence": "medium" }, "currency": { "effective_since": "Since IP-pacs.002 v2.0 (first production edition)", "effective_note": "A list of permitted NEG002 codes first appears in IP-pacs.002 v1.1 (2022-05-20); v2.0 (2022-10-20) was the first edition for production, valid from the November 2023 release. The code is in v2.3, in force since 2025-11-21 with SIC platform release 5.2, and unchanged in v2.4, valid from 2026-11-13 with release 5.3. SIX plans to move all SIC IP messages to ISO 20022 2024/2025 versions in November 2027 (SIC Platform Release Notes 2026, CR2026-SIC-0002), which may change the list [Speculation].", "source_edition": "IP-pacs.002 v2.3 (2025-02-28, valid from 2025-11-21) and v2.4 (2026-02-27, valid from 2026-11-13)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.six-group.com/dam/download/banking-services/standardization/sic-eurosic/5-3/ig-module-docs-sic-ip-2026-5.3-en.zip", "source_class": "authoritative_primary", "source_title": "IP Status Report (pacs.002) v2.4, SIC IP module documents, release 5.3 archive", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "IP Status Report (pacs.002) v2.4 section 3.1.4 Table 3 lists MS03 among the 14 codes valid in the Reason element of a Negative IP Feedback (NEG002), with the ISO code name NotSpecifiedReasonAgentGenerated. Confirms the code sits on the closed list the SIC IP service checks and repeats to the sender in the IP Cancellation Information (CNC002); the table states only the ISO code name, no SIX-authored definition." }, { "source_url": "https://www.iso20022.org/sites/default/files/media/file/ExternalCodeSets_JSON.zip", "source_class": "authoritative_primary", "source_title": "ISO 20022 External Code Sets, 2Q2026, ExternalStatusReason1Code", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "The ISO 20022 External Code Set ExternalStatusReason1Code defines MS03 as a reason not specified by the agent. Confirms the record's stated meaning that the receiving participant itself refuses without giving a reason." } ] }, "rail_name": "SIC IP Payment Rejections", "governing_authority": "SIX Interbank Clearing on behalf of the Swiss National Bank", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "ch-sic-ip-reject:RC01", "id": "RC01", "rail": "ch-sic-ip-reject", "kind": "reason-code", "name": "Bank identifier not correct", "group": "technical", "summary": "The receiving participant rejects the IP customer payment because a bank identifier in it is wrong.", "triggers": [ "A financial institution identifier in the pacs.008 is wrong for the receiving participant [Inference from the ISO code name BankIdentifierIncorrect]", "Participants in SIC IP are identified by their six-digit SIC IID with clearing system code CHSIC (IP-pacs.002 v2.4 section 3.5); which identifier a receiving participant would object to is not stated [Unverified]" ], "actions": [ "Sending participant: once the CNC002 arrives, treat the payment as not executed, free the amount it had reserved for the payer [Inference: the SNB says the amount is reserved first and the payment is cancelled on a negative answer], and tell the payer straight away, with the reason where the law allows (SNB-R 2025 ch. 6 footnotes 15 and 16)", "Sending participant: check the creditor agent and other agent identifiers it put in the pacs.008" ], "retry": { "allowed": false, "rule": "Not unchanged. Once the identifier is corrected, a new IP customer payment may be sent [Inference]." }, "facts": { "return_windows": [ { "action": "reject the IP customer payment with a Negative IP Feedback (pacs.002 NEG002, status RJCT) carrying this code", "by": "Receiving (instructed) participant, identified by its SIC IID as originator of the feedback", "deadline": "No public deadline is published. The feedback presumably has to reach the SIC IP service before the service's hard time-out [Inference], which counts from the start time the sending participant stamps on the pacs.008 (IP-pacs.008 v2.3, element AccptncDtTm); the time-out value itself is in the participant-only SIC Handbook. The SNB describes instant payments as settled in principle within ten seconds (SNB-R 2025 ch. 6)." }, { "action": "cancel the payment and pass the code on in an IP Cancellation Information (pacs.002 CNC002, status CANC)", "by": "SIC IP service", "deadline": "No public deadline is published. The guideline says the service copies the receiving participant's code into the cancellation notice; how soon that notice goes out is not stated in the public guidelines." } ], "applies_to": "SIC IP service (Swiss franc instant payments, 24/7): the receiving participant's Negative IP Feedback (pacs.002 of type NEG002, status RJCT) on an IP customer payment (pacs.008). The service checks the code against a closed list of 14 and repeats it to the sending side in the IP Cancellation Information (CNC002)." }, "caveat": "The SIC IP service routes on the SIC IID, so RC01 is most likely about an identifier the receiving participant checks itself [Inference]. The sending participant sees the same code in the CNC002, with the receiving participant's SIC IID as originator (IP-pacs.002 v2.4 sections 3.1.6 and 4.3). What the payer is told is up to the sending bank; the SPS pain.002 status codes a Swiss bank customer receives are a separate family and never travel in SIC.", "related": [ "ch-sic-ip-reject:AC01", "ch-sic-ip-reject:AG02" ], "basis": { "sources": "IP-pacs.002 v2.4 (SIX Interbank Clearing, Instant Payments Implementation Guidelines, IP Status Report, 2026-02-27, valid from 2026-11-13) sections 3.1.4 and Table 3 (permitted NEG002 codes, checked by the service), 3.1.6 (CNC002 copies the NEG002 code) and 4.3 (elements TxSts, StsRsnInf/Orgtr, Rsn/Cd); IP-pacs.002 v2.3 (2025-02-28, valid from 2025-11-21), same sections; IP-pacs.008 v2.3 (2026-02-27) element AccptncDtTm; SNB Report on the SIC System and Disclosure Report 2025 ch. 6 and footnotes 15 and 16. The code meaning rests on the ISO code name SIX prints in Table 3; the ISO External Code Set itself was not read.", "confidence": "medium" }, "currency": { "effective_since": "Since IP-pacs.002 v2.0 (first production edition)", "effective_note": "A list of permitted NEG002 codes first appears in IP-pacs.002 v1.1 (2022-05-20); v2.0 (2022-10-20) was the first edition for production, valid from the November 2023 release. The code is in v2.3, in force since 2025-11-21 with SIC platform release 5.2, and unchanged in v2.4, valid from 2026-11-13 with release 5.3. SIX plans to move all SIC IP messages to ISO 20022 2024/2025 versions in November 2027 (SIC Platform Release Notes 2026, CR2026-SIC-0002), which may change the list [Speculation].", "source_edition": "IP-pacs.002 v2.3 (2025-02-28, valid from 2025-11-21) and v2.4 (2026-02-27, valid from 2026-11-13)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.six-group.com/dam/download/banking-services/standardization/sic-eurosic/5-3/ig-module-docs-sic-ip-2026-5.3-en.zip", "source_class": "authoritative_primary", "source_title": "IP Status Report (pacs.002) v2.4, SIC IP module documents, release 5.3 archive", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "IP Status Report (pacs.002) v2.4 section 3.1.4 Table 3 lists RC01 among the 14 codes valid in the Reason element of a Negative IP Feedback (NEG002), with the ISO code name BankIdentifierIncorrect. Confirms the code sits on the closed list the SIC IP service checks and repeats to the sender in the IP Cancellation Information (CNC002); the table states only the ISO code name, no SIX-authored definition." }, { "source_url": "https://www.iso20022.org/sites/default/files/media/file/ExternalCodeSets_JSON.zip", "source_class": "authoritative_primary", "source_title": "ISO 20022 External Code Sets, 2Q2026, ExternalStatusReason1Code", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "The ISO 20022 External Code Set ExternalStatusReason1Code defines RC01, formerly named IncorrectFormatForRoutingCode, as a bank identifier code specified in the message that has an incorrect format. Confirms the record's stated meaning that a bank identifier in the payment is wrong; the ISO definition ties this specifically to a formatting fault, a distinction the record's trigger does not draw when it speaks more generally of a wrong identifier." } ] }, "rail_name": "SIC IP Payment Rejections", "governing_authority": "SIX Interbank Clearing on behalf of the Swiss National Bank", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "ch-sic-ip-reject:RR01", "id": "RR01", "rail": "ch-sic-ip-reject", "kind": "reason-code", "name": "Payer account or identification missing", "group": "administrative", "summary": "The receiving participant rejects the IP customer payment because the payer's account or identification, needed for its regulatory checks, is missing.", "triggers": [ "The debtor account or debtor identification is absent or not enough for the receiving participant's compliance checks [Inference from the ISO code name MissingDebtorAccountOrIdentification]" ], "actions": [ "Sending participant: once the CNC002 arrives, treat the payment as not executed, free the amount it had reserved for the payer [Inference: the SNB says the amount is reserved first and the payment is cancelled on a negative answer], and tell the payer straight away, with the reason where the law allows (SNB-R 2025 ch. 6 footnotes 15 and 16)", "Sending participant: complete the payer's account and identification data in its pacs.008 before sending again" ], "retry": { "allowed": true, "rule": "Only as a new IP customer payment that carries the missing payer data [Inference]. The public guidelines set no retry limit [Unverified]." }, "facts": { "return_windows": [ { "action": "reject the IP customer payment with a Negative IP Feedback (pacs.002 NEG002, status RJCT) carrying this code", "by": "Receiving (instructed) participant, identified by its SIC IID as originator of the feedback", "deadline": "No public deadline is published. The feedback presumably has to reach the SIC IP service before the service's hard time-out [Inference], which counts from the start time the sending participant stamps on the pacs.008 (IP-pacs.008 v2.3, element AccptncDtTm); the time-out value itself is in the participant-only SIC Handbook. The SNB describes instant payments as settled in principle within ten seconds (SNB-R 2025 ch. 6)." }, { "action": "cancel the payment and pass the code on in an IP Cancellation Information (pacs.002 CNC002, status CANC)", "by": "SIC IP service", "deadline": "No public deadline is published. The guideline says the service copies the receiving participant's code into the cancellation notice; how soon that notice goes out is not stated in the public guidelines." } ], "applies_to": "SIC IP service (Swiss franc instant payments, 24/7): the receiving participant's Negative IP Feedback (pacs.002 of type NEG002, status RJCT) on an IP customer payment (pacs.008). The service checks the code against a closed list of 14 and repeats it to the sending side in the IP Cancellation Information (CNC002)." }, "caveat": "The RR codes are regulatory: the receiving participant needs the data to meet its own legal duties [Inference]. The sending participant sees the same code in the CNC002, with the receiving participant's SIC IID as originator (IP-pacs.002 v2.4 sections 3.1.6 and 4.3). What the payer is told is up to the sending bank; the SPS pain.002 status codes a Swiss bank customer receives are a separate family and never travel in SIC.", "related": [ "ch-sic-ip-reject:RR02", "ch-sic-ip-reject:RR03", "ch-sic-ip-reject:RR04" ], "basis": { "sources": "IP-pacs.002 v2.4 (SIX Interbank Clearing, Instant Payments Implementation Guidelines, IP Status Report, 2026-02-27, valid from 2026-11-13) sections 3.1.4 and Table 3 (permitted NEG002 codes, checked by the service), 3.1.6 (CNC002 copies the NEG002 code) and 4.3 (elements TxSts, StsRsnInf/Orgtr, Rsn/Cd); IP-pacs.002 v2.3 (2025-02-28, valid from 2025-11-21), same sections; IP-pacs.008 v2.3 (2026-02-27) element AccptncDtTm; SNB Report on the SIC System and Disclosure Report 2025 ch. 6 and footnotes 15 and 16. The code meaning rests on the ISO code name SIX prints in Table 3; the ISO External Code Set itself was not read.", "confidence": "medium" }, "currency": { "effective_since": "Since IP-pacs.002 v2.0 (first production edition)", "effective_note": "A list of permitted NEG002 codes first appears in IP-pacs.002 v1.1 (2022-05-20); v2.0 (2022-10-20) was the first edition for production, valid from the November 2023 release. The code is in v2.3, in force since 2025-11-21 with SIC platform release 5.2, and unchanged in v2.4, valid from 2026-11-13 with release 5.3. SIX plans to move all SIC IP messages to ISO 20022 2024/2025 versions in November 2027 (SIC Platform Release Notes 2026, CR2026-SIC-0002), which may change the list [Speculation].", "source_edition": "IP-pacs.002 v2.3 (2025-02-28, valid from 2025-11-21) and v2.4 (2026-02-27, valid from 2026-11-13)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.six-group.com/dam/download/banking-services/standardization/sic-eurosic/5-3/ig-module-docs-sic-ip-2026-5.3-en.zip", "source_class": "authoritative_primary", "source_title": "IP Status Report (pacs.002) v2.4, SIC IP module documents, release 5.3 archive", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "IP Status Report (pacs.002) v2.4 section 3.1.4 Table 3 lists RR01 among the 14 codes valid in the Reason element of a Negative IP Feedback (NEG002), with the ISO code name MissingDebtorAccountOrIdentification. Confirms the code sits on the closed list the SIC IP service checks and repeats to the sender in the IP Cancellation Information (CNC002); the table states only the ISO code name, no SIX-authored definition." }, { "source_url": "https://www.iso20022.org/sites/default/files/media/file/ExternalCodeSets_JSON.zip", "source_class": "authoritative_primary", "source_title": "ISO 20022 External Code Sets, 2Q2026, ExternalStatusReason1Code", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "The ISO 20022 External Code Set ExternalStatusReason1Code defines RR01 as the debtor's account or unique identification needed for regulatory requirements being insufficient or missing. Confirms the record's stated meaning that the payer's account or identification data is absent or inadequate for the receiving participant's compliance checks." } ] }, "rail_name": "SIC IP Payment Rejections", "governing_authority": "SIX Interbank Clearing on behalf of the Swiss National Bank", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "ch-sic-ip-reject:RR02", "id": "RR02", "rail": "ch-sic-ip-reject", "kind": "reason-code", "name": "Payer name or address missing", "group": "administrative", "summary": "The receiving participant rejects the IP customer payment because the payer's name or address is missing or not usable for its regulatory checks.", "triggers": [ "The debtor name or postal address is absent or incomplete [Inference from the ISO code name MissingDebtorNameOrAddress]" ], "actions": [ "Sending participant: once the CNC002 arrives, treat the payment as not executed, free the amount it had reserved for the payer [Inference: the SNB says the amount is reserved first and the payment is cancelled on a negative answer], and tell the payer straight away, with the reason where the law allows (SNB-R 2025 ch. 6 footnotes 15 and 16)", "Sending participant: fill the payer's name and address in a form the SIC IP guidelines accept, then send a new payment" ], "retry": { "allowed": true, "rule": "Only as a new IP customer payment with the payer's name and address supplied [Inference]. The public guidelines set no retry limit [Unverified]." }, "facts": { "return_windows": [ { "action": "reject the IP customer payment with a Negative IP Feedback (pacs.002 NEG002, status RJCT) carrying this code", "by": "Receiving (instructed) participant, identified by its SIC IID as originator of the feedback", "deadline": "No public deadline is published. The feedback presumably has to reach the SIC IP service before the service's hard time-out [Inference], which counts from the start time the sending participant stamps on the pacs.008 (IP-pacs.008 v2.3, element AccptncDtTm); the time-out value itself is in the participant-only SIC Handbook. The SNB describes instant payments as settled in principle within ten seconds (SNB-R 2025 ch. 6)." }, { "action": "cancel the payment and pass the code on in an IP Cancellation Information (pacs.002 CNC002, status CANC)", "by": "SIC IP service", "deadline": "No public deadline is published. The guideline says the service copies the receiving participant's code into the cancellation notice; how soon that notice goes out is not stated in the public guidelines." } ], "applies_to": "SIC IP service (Swiss franc instant payments, 24/7): the receiving participant's Negative IP Feedback (pacs.002 of type NEG002, status RJCT) on an IP customer payment (pacs.008). The service checks the code against a closed list of 14 and repeats it to the sending side in the IP Cancellation Information (CNC002)." }, "caveat": "SIX had planned to stop accepting unstructured addresses in SIC IP with release 5.3, but that change request (CR2026-SIC-0001) will not be implemented with release 5.3 (SIC Platform Release Notes 2026 v1.3 section 4.2.1). The sending participant sees the same code in the CNC002, with the receiving participant's SIC IID as originator (IP-pacs.002 v2.4 sections 3.1.6 and 4.3). What the payer is told is up to the sending bank; the SPS pain.002 status codes a Swiss bank customer receives are a separate family and never travel in SIC.", "related": [ "ch-sic-ip-reject:RR01", "ch-sic-ip-reject:RR03", "ch-sic-ip-reject:RR04" ], "basis": { "sources": "IP-pacs.002 v2.4 (SIX Interbank Clearing, Instant Payments Implementation Guidelines, IP Status Report, 2026-02-27, valid from 2026-11-13) sections 3.1.4 and Table 3 (permitted NEG002 codes, checked by the service), 3.1.6 (CNC002 copies the NEG002 code) and 4.3 (elements TxSts, StsRsnInf/Orgtr, Rsn/Cd); IP-pacs.002 v2.3 (2025-02-28, valid from 2025-11-21), same sections; IP-pacs.008 v2.3 (2026-02-27) element AccptncDtTm; SNB Report on the SIC System and Disclosure Report 2025 ch. 6 and footnotes 15 and 16. The code meaning rests on the ISO code name SIX prints in Table 3; the ISO External Code Set itself was not read.", "confidence": "medium" }, "currency": { "effective_since": "Since IP-pacs.002 v2.0 (first production edition)", "effective_note": "A list of permitted NEG002 codes first appears in IP-pacs.002 v1.1 (2022-05-20); v2.0 (2022-10-20) was the first edition for production, valid from the November 2023 release. The code is in v2.3, in force since 2025-11-21 with SIC platform release 5.2, and unchanged in v2.4, valid from 2026-11-13 with release 5.3. SIX plans to move all SIC IP messages to ISO 20022 2024/2025 versions in November 2027 (SIC Platform Release Notes 2026, CR2026-SIC-0002), which may change the list [Speculation].", "source_edition": "IP-pacs.002 v2.3 (2025-02-28, valid from 2025-11-21) and v2.4 (2026-02-27, valid from 2026-11-13)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.six-group.com/dam/download/banking-services/standardization/sic-eurosic/5-3/ig-module-docs-sic-ip-2026-5.3-en.zip", "source_class": "authoritative_primary", "source_title": "IP Status Report (pacs.002) v2.4, SIC IP module documents, release 5.3 archive", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "IP Status Report (pacs.002) v2.4 section 3.1.4 Table 3 lists RR02 among the 14 codes valid in the Reason element of a Negative IP Feedback (NEG002), with the ISO code name MissingDebtorNameOrAddress. Confirms the code sits on the closed list the SIC IP service checks and repeats to the sender in the IP Cancellation Information (CNC002); the table states only the ISO code name, no SIX-authored definition." }, { "source_url": "https://www.iso20022.org/sites/default/files/media/file/ExternalCodeSets_JSON.zip", "source_class": "authoritative_primary", "source_title": "ISO 20022 External Code Sets, 2Q2026, ExternalStatusReason1Code", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "The ISO 20022 External Code Set ExternalStatusReason1Code defines RR02 as the debtor's name and/or address needed for regulatory requirements being insufficient or missing. Confirms the record's stated meaning that the payer's name or address is absent or inadequate for the receiving participant's compliance checks." } ] }, "rail_name": "SIC IP Payment Rejections", "governing_authority": "SIX Interbank Clearing on behalf of the Swiss National Bank", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "ch-sic-ip-reject:RR03", "id": "RR03", "rail": "ch-sic-ip-reject", "kind": "reason-code", "name": "Payee name or address missing", "group": "administrative", "summary": "The receiving participant rejects the IP customer payment because the payee's name or address is missing or not usable for its regulatory checks.", "triggers": [ "The creditor name or postal address is absent or incomplete [Inference from the ISO code name MissingCreditorNameOrAddress]" ], "actions": [ "Sending participant: once the CNC002 arrives, treat the payment as not executed, free the amount it had reserved for the payer [Inference: the SNB says the amount is reserved first and the payment is cancelled on a negative answer], and tell the payer straight away, with the reason where the law allows (SNB-R 2025 ch. 6 footnotes 15 and 16)", "Sending participant: ask the payer for the payee's full name and address and send a new payment" ], "retry": { "allowed": true, "rule": "Only as a new IP customer payment with the payee's name and address supplied [Inference]. The public guidelines set no retry limit [Unverified]." }, "facts": { "return_windows": [ { "action": "reject the IP customer payment with a Negative IP Feedback (pacs.002 NEG002, status RJCT) carrying this code", "by": "Receiving (instructed) participant, identified by its SIC IID as originator of the feedback", "deadline": "No public deadline is published. The feedback presumably has to reach the SIC IP service before the service's hard time-out [Inference], which counts from the start time the sending participant stamps on the pacs.008 (IP-pacs.008 v2.3, element AccptncDtTm); the time-out value itself is in the participant-only SIC Handbook. The SNB describes instant payments as settled in principle within ten seconds (SNB-R 2025 ch. 6)." }, { "action": "cancel the payment and pass the code on in an IP Cancellation Information (pacs.002 CNC002, status CANC)", "by": "SIC IP service", "deadline": "No public deadline is published. The guideline says the service copies the receiving participant's code into the cancellation notice; how soon that notice goes out is not stated in the public guidelines." } ], "applies_to": "SIC IP service (Swiss franc instant payments, 24/7): the receiving participant's Negative IP Feedback (pacs.002 of type NEG002, status RJCT) on an IP customer payment (pacs.008). The service checks the code against a closed list of 14 and repeats it to the sending side in the IP Cancellation Information (CNC002)." }, "caveat": "SIX had planned to stop accepting unstructured addresses in SIC IP with release 5.3, but that change request (CR2026-SIC-0001) will not be implemented with release 5.3 (SIC Platform Release Notes 2026 v1.3 section 4.2.1). The sending participant sees the same code in the CNC002, with the receiving participant's SIC IID as originator (IP-pacs.002 v2.4 sections 3.1.6 and 4.3). What the payer is told is up to the sending bank; the SPS pain.002 status codes a Swiss bank customer receives are a separate family and never travel in SIC.", "related": [ "ch-sic-ip-reject:RR01", "ch-sic-ip-reject:RR02", "ch-sic-ip-reject:RR04" ], "basis": { "sources": "IP-pacs.002 v2.4 (SIX Interbank Clearing, Instant Payments Implementation Guidelines, IP Status Report, 2026-02-27, valid from 2026-11-13) sections 3.1.4 and Table 3 (permitted NEG002 codes, checked by the service), 3.1.6 (CNC002 copies the NEG002 code) and 4.3 (elements TxSts, StsRsnInf/Orgtr, Rsn/Cd); IP-pacs.002 v2.3 (2025-02-28, valid from 2025-11-21), same sections; IP-pacs.008 v2.3 (2026-02-27) element AccptncDtTm; SNB Report on the SIC System and Disclosure Report 2025 ch. 6 and footnotes 15 and 16. The code meaning rests on the ISO code name SIX prints in Table 3; the ISO External Code Set itself was not read.", "confidence": "medium" }, "currency": { "effective_since": "Since IP-pacs.002 v2.0 (first production edition)", "effective_note": "A list of permitted NEG002 codes first appears in IP-pacs.002 v1.1 (2022-05-20); v2.0 (2022-10-20) was the first edition for production, valid from the November 2023 release. The code is in v2.3, in force since 2025-11-21 with SIC platform release 5.2, and unchanged in v2.4, valid from 2026-11-13 with release 5.3. SIX plans to move all SIC IP messages to ISO 20022 2024/2025 versions in November 2027 (SIC Platform Release Notes 2026, CR2026-SIC-0002), which may change the list [Speculation].", "source_edition": "IP-pacs.002 v2.3 (2025-02-28, valid from 2025-11-21) and v2.4 (2026-02-27, valid from 2026-11-13)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.six-group.com/dam/download/banking-services/standardization/sic-eurosic/5-3/ig-module-docs-sic-ip-2026-5.3-en.zip", "source_class": "authoritative_primary", "source_title": "IP Status Report (pacs.002) v2.4, SIC IP module documents, release 5.3 archive", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "IP Status Report (pacs.002) v2.4 section 3.1.4 Table 3 lists RR03 among the 14 codes valid in the Reason element of a Negative IP Feedback (NEG002), with the ISO code name MissingCreditorNameOrAddress. Confirms the code sits on the closed list the SIC IP service checks and repeats to the sender in the IP Cancellation Information (CNC002); the table states only the ISO code name, no SIX-authored definition." }, { "source_url": "https://www.iso20022.org/sites/default/files/media/file/ExternalCodeSets_JSON.zip", "source_class": "authoritative_primary", "source_title": "ISO 20022 External Code Sets, 2Q2026, ExternalStatusReason1Code", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "The ISO 20022 External Code Set ExternalStatusReason1Code defines RR03 as the creditor's name and/or address needed for regulatory requirements being insufficient or missing. Confirms the record's stated meaning that the payee's name or address is absent or inadequate for the receiving participant's compliance checks." } ] }, "rail_name": "SIC IP Payment Rejections", "governing_authority": "SIX Interbank Clearing on behalf of the Swiss National Bank", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "ch-sic-ip-reject:RR04", "id": "RR04", "rail": "ch-sic-ip-reject", "kind": "reason-code", "name": "Regulatory reason", "group": "administrative", "summary": "The receiving participant rejects the IP customer payment for a regulatory reason, such as a legal or compliance restriction on its side.", "triggers": [ "A legal, sanctions or compliance restriction stops the receiving participant from taking the payment [Inference from the ISO code name RegulatoryReason]" ], "actions": [ "Sending participant: once the CNC002 arrives, treat the payment as not executed, free the amount it had reserved for the payer [Inference: the SNB says the amount is reserved first and the payment is cancelled on a negative answer], and tell the payer straight away, with the reason where the law allows (SNB-R 2025 ch. 6 footnotes 15 and 16)", "Sending participant: do not resend; the SNB notes that the reason is given to the payer only as far as the law allows (SNB-R 2025 ch. 6 footnote 16)" ], "retry": { "allowed": false, "rule": "No. A regulatory refusal is not cured by sending again [Inference]." }, "facts": { "return_windows": [ { "action": "reject the IP customer payment with a Negative IP Feedback (pacs.002 NEG002, status RJCT) carrying this code", "by": "Receiving (instructed) participant, identified by its SIC IID as originator of the feedback", "deadline": "No public deadline is published. The feedback presumably has to reach the SIC IP service before the service's hard time-out [Inference], which counts from the start time the sending participant stamps on the pacs.008 (IP-pacs.008 v2.3, element AccptncDtTm); the time-out value itself is in the participant-only SIC Handbook. The SNB describes instant payments as settled in principle within ten seconds (SNB-R 2025 ch. 6)." }, { "action": "cancel the payment and pass the code on in an IP Cancellation Information (pacs.002 CNC002, status CANC)", "by": "SIC IP service", "deadline": "No public deadline is published. The guideline says the service copies the receiving participant's code into the cancellation notice; how soon that notice goes out is not stated in the public guidelines." } ], "applies_to": "SIC IP service (Swiss franc instant payments, 24/7): the receiving participant's Negative IP Feedback (pacs.002 of type NEG002, status RJCT) on an IP customer payment (pacs.008). The service checks the code against a closed list of 14 and repeats it to the sending side in the IP Cancellation Information (CNC002)." }, "caveat": "The code does not say which rule applies; the receiving participant may be barred from saying more [Inference]. The sending participant sees the same code in the CNC002, with the receiving participant's SIC IID as originator (IP-pacs.002 v2.4 sections 3.1.6 and 4.3). What the payer is told is up to the sending bank; the SPS pain.002 status codes a Swiss bank customer receives are a separate family and never travel in SIC.", "related": [ "ch-sic-ip-reject:RR01", "ch-sic-ip-reject:MS03" ], "basis": { "sources": "IP-pacs.002 v2.4 (SIX Interbank Clearing, Instant Payments Implementation Guidelines, IP Status Report, 2026-02-27, valid from 2026-11-13) sections 3.1.4 and Table 3 (permitted NEG002 codes, checked by the service), 3.1.6 (CNC002 copies the NEG002 code) and 4.3 (elements TxSts, StsRsnInf/Orgtr, Rsn/Cd); IP-pacs.002 v2.3 (2025-02-28, valid from 2025-11-21), same sections; IP-pacs.008 v2.3 (2026-02-27) element AccptncDtTm; SNB Report on the SIC System and Disclosure Report 2025 ch. 6 and footnotes 15 and 16. The code meaning rests on the ISO code name SIX prints in Table 3; the ISO External Code Set itself was not read.", "confidence": "medium" }, "currency": { "effective_since": "Since IP-pacs.002 v2.0 (first production edition)", "effective_note": "A list of permitted NEG002 codes first appears in IP-pacs.002 v1.1 (2022-05-20); v2.0 (2022-10-20) was the first edition for production, valid from the November 2023 release. The code is in v2.3, in force since 2025-11-21 with SIC platform release 5.2, and unchanged in v2.4, valid from 2026-11-13 with release 5.3. SIX plans to move all SIC IP messages to ISO 20022 2024/2025 versions in November 2027 (SIC Platform Release Notes 2026, CR2026-SIC-0002), which may change the list [Speculation].", "source_edition": "IP-pacs.002 v2.3 (2025-02-28, valid from 2025-11-21) and v2.4 (2026-02-27, valid from 2026-11-13)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.six-group.com/dam/download/banking-services/standardization/sic-eurosic/5-3/ig-module-docs-sic-ip-2026-5.3-en.zip", "source_class": "authoritative_primary", "source_title": "IP Status Report (pacs.002) v2.4, SIC IP module documents, release 5.3 archive", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "IP Status Report (pacs.002) v2.4 section 3.1.4 Table 3 lists RR04 among the 14 codes valid in the Reason element of a Negative IP Feedback (NEG002), with the ISO code name RegulatoryReason. Confirms the code sits on the closed list the SIC IP service checks and repeats to the sender in the IP Cancellation Information (CNC002); the table states only the ISO code name, no SIX-authored definition." }, { "source_url": "https://www.iso20022.org/sites/default/files/media/file/ExternalCodeSets_JSON.zip", "source_class": "authoritative_primary", "source_title": "ISO 20022 External Code Sets, 2Q2026, ExternalStatusReason1Code", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "The ISO 20022 External Code Set ExternalStatusReason1Code defines RR04 with the two words Regulatory Reason and no further elaboration. Confirms the code concerns a regulatory basis for refusal; does not confirm or contradict the record's inference that a legal, sanctions or compliance restriction is what stops the receiving participant, which stays a labelled inference." } ] }, "rail_name": "SIC IP Payment Rejections", "governing_authority": "SIX Interbank Clearing on behalf of the Swiss National Bank", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "ch-sic-ip-reject:TM01", "id": "TM01", "rail": "ch-sic-ip-reject", "kind": "reason-code", "name": "SIC IP cancelled: hard time-out", "group": "network", "summary": "The SIC IP service itself cancels an IP customer payment because it ran past the service's hard time-out, and tells the participant with a CNC002 carrying TM01. Nothing settles.", "triggers": [ "No answer from the receiving participant reached the service before the hard time-out [Inference: SIX names the case only as a hard time-out]", "The time counts from the start time the sending participant stamps on the pacs.008, which opens the maximum end-to-end window for everyone in the chain (IP-pacs.008 v2.3, element AccptncDtTm)" ], "actions": [ "Sending participant: treat the payment as not executed, free the reserved amount, and tell the payer at once with the reason (SNB-R 2025 ch. 6 footnote 16) [Inference: freeing the reservation follows from the cancellation]", "Sending participant: if neither a confirmation nor a cancellation arrives, ask for the status with a pacs.028 once the overall execution time has passed; this works for payments of the current and previous clearing day (IP-pacs.028 v2.3 section 3.1.1)", "Receiving participant: find out why its feedback was late; whether a late positive feedback has any effect is not stated publicly [Unverified]" ], "retry": { "allowed": true, "rule": "The cancelled payment stays cancelled and cannot be revived. A new IP customer payment, with a new transaction reference, may be sent later, or the transfer can go through the SIC RTGS service instead [Inference]. The public guidelines set no retry limit [Unverified]." }, "facts": { "return_windows": [ { "action": "cancel the payment with an IP Cancellation Information (pacs.002 CNC002, status CANC) carrying TM01", "by": "SIC IP service, with the SIC IID of SIC Ltd (099990) as originator", "deadline": "No public deadline is published. The service cancels once its hard time-out has passed, and the time-out value is in the participant-only SIC Handbook. The SNB says only that instant payments settle in principle within ten seconds and that the service cancels a payment that goes over a set time (SNB-R 2025 ch. 6)." } ], "applies_to": "SIC IP service: the IP Cancellation Information (pacs.002 of type CNC002, status CANC) that the service itself sends when it cancels an IP customer payment (pacs.008)." }, "caveat": "TM01 is raised by the service, not by a bank. AB05 is the receiving participant reporting its own time-out in a NEG002; TM01 means no usable answer came in time. In SEPA Instant the same letters sit on a different leg, so do not map one scheme's TM01 onto the other.", "related": [ "ch-sic-ip-reject:AB05", "ch-sic-ip-reject:ED05" ], "basis": { "sources": "IP-pacs.002 v2.4 (2026-02-27, valid from 2026-11-13) sections 3.1.3, 3.1.6 and 4.3 (elements TxSts, StsRsnInf/Orgtr/Id, Rsn/Cd for CNC002) and change history for version 2.2; IP-pacs.002 v2.3 (2025-02-28, valid from 2025-11-21), same sections; IP-pacs.008 v2.3 (2026-02-27) element AccptncDtTm; IP-pacs.028 v2.3 (2025-02-28) section 3.1.1; SNB Report on the SIC System and Disclosure Report 2025 ch. 6 and footnote 16.", "confidence": "high" }, "currency": { "effective_since": "Since IP-pacs.002 v2.0 (first production edition)", "effective_note": "The code is a CNC002 reason in IP-pacs.002 v2.3, in force since 2025-11-21 with SIC platform release 5.2, and unchanged in v2.4, valid from 2026-11-13 with release 5.3. The edition that first listed TM01 has not been established [Unverified]. SIX plans to move all SIC IP messages to ISO 20022 2024/2025 versions in November 2027 (SIC Platform Release Notes 2026, CR2026-SIC-0002) [Speculation whether this code changes].", "source_edition": "IP-pacs.002 v2.3 (2025-02-28, valid from 2025-11-21) and v2.4 (2026-02-27, valid from 2026-11-13)", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "rail_name": "SIC IP Payment Rejections", "governing_authority": "SIX Interbank Clearing on behalf of the Swiss National Bank", "snapshot": "2026-09-18", "source_class": null, "effective_status": "draft", "effective_status_reason": null, "boundaries": [] }, { "uid": "ch-sic-ip-return-request:AC03", "id": "AC03", "rail": "ch-sic-ip-return-request", "kind": "reason-code", "name": "Wrong payee account: payer asks for the money back", "group": "account", "summary": "The participant that sent an IP customer payment asks for it back on behalf of the payer, who sent it to the wrong account. The receiving side may refuse, and may then give details that help the payer recover the money by other means.", "triggers": [ "The payer used a wrong IBAN, so the payment reached a valid but unintended account [Inference from the code name Invalid Creditor Account Number]" ], "actions": [ "Sending participant: name the payer as originator of the request (the Name element, not Identification); SIX asks for this on requests made for the originator but does not check it (IP-camt.056 v2.3 element CxlRsnInf/Orgtr)", "Receiving participant, if it refuses: it may add up to ten further lines starting ATR078/ with details that could let the money be claimed back outside this process, minding data protection (IP-camt.029 v2.3 chapter 4.4)", "Receiving participant: either return the funds with a pacs.004 coded FOCR that quotes the request's CxlId, or refuse with a camt.029 whose first additional information line starts ATR072/ followed by the request reference (IP-pacs.004 v2.4 chapter 4.3; IP-camt.029 v2.3 chapter 4.4)", "Sending participant: if no answer comes, send a status request for the IP return request (pacs.028, IPSRRQ); the receiving participant then has to return or refuse (IP-pacs.028 v2.3 section 3.1.2)" ], "retry": { "allowed": false, "rule": "A return request is not sent again to chase an answer: the sender uses a status request for the IP return request (pacs.028, type IPSRRQ), which the service passes to the receiving participant (IP-pacs.028 v2.3 section 3.1.2). Whether a second camt.056 for the same payment is allowed is not stated publicly [Unverified]. Each request needs its own reference, unique within the current and the previous clearing day (IP-camt.056 v2.3 element CxlId)." }, "facts": { "return_windows": [ { "action": "send an IP return request (camt.056) with this reason", "by": "The participant that sent the original IP customer payment", "deadline": "No public deadline is published. The public guidelines set no time limit for asking; any limit would be in the participant-only SIC Handbook." }, { "action": "answer the request: send the funds back with an IP return (pacs.004, reason FOCR) or refuse with an IP return request rejection (camt.029)", "by": "The participant that received the original IP customer payment", "deadline": "No public deadline is published. The receiving participant must answer one way or the other (IP-pacs.028 v2.3 section 3.1.2), but no public text says how fast." } ], "applies_to": "SIC IP service: the IP return request (camt.056), sent by the participant that made an IP customer payment and passed on by the service to the participant that received it, asking for the settled funds back. The service checks the reason against a closed list of six." }, "caveat": "An IBAN that does not exist at the receiving participant is normally caught before settlement as a NEG002 rejection coded AC01 [Inference]; AC03 here is for a payment that settled. SIX meant DUPL, TECH and FRAD for requests a bank starts itself, and CUST, AC03 and AM09 for requests made on behalf of the payer; the service does not enforce that split (IP-camt.056 v2.3 element Rsn/Cd). The service checks format and acknowledges with camt.025, but does not check that the payment referred to ever went through SIC IP (IP-camt.056 v2.3 section 3.1). A return request is a request, not a claim on the funds [Inference]; settlement in SIC is final (SNB-R 2025 ch. 2).", "related": [ "ch-sic-ip-return-request:CUST", "ch-sic-ip-return-request:AM09", "ch-sic-ip-return-request-rejection:CUST", "ch-sic-ip-return-request-rejection:AC04", "ch-sic-ip-reject:AC01" ], "basis": { "sources": "IP-camt.056 v2.3 (SIX Interbank Clearing, Instant Payments Implementation Guidelines, IP Return Request, 2025-02-28, valid from 2025-11-21; the same edition sits in the release 5.3 archive) sections 2 and 3.1 and chapter 4.4 elements CxlId, CxlRsnInf/Orgtr and Rsn/Cd; IP-camt.029 v2.3 (2025-02-28) chapter 4.4 element AddtlInf; IP-pacs.004 v2.4 (2026-02-27, valid from 2026-11-13) chapter 4.3 elements Rsn/Cd and AddtlInf; IP-pacs.028 v2.3 (2025-02-28) section 3.1.2. The code meaning rests on the short name SIX gives next to the code; the ISO External Code Set itself was not read.", "confidence": "medium" }, "currency": { "effective_since": "Since IP-camt.056 v2.0 (first production edition)", "effective_note": "The six codes are in IP-camt.056 v2.3, in force since 2025-11-21 with SIC platform release 5.2 and carried unchanged into the release 5.3 archive for 2026-11-13. No entry in the change history from v1.0 (2022-02-28) onward touches the code list [Inference: the list dates from the first edition]. v2.0 (2022-10-20) was the first edition for production, valid from the November 2023 release. SIX plans to move all SIC IP messages to ISO 20022 2024/2025 versions in November 2027 (SIC Platform Release Notes 2026, CR2026-SIC-0002) [Speculation whether this code changes].", "source_edition": "IP-camt.056 v2.3 (2025-02-28, valid from 2025-11-21, unchanged for release 5.3)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.six-group.com/dam/download/banking-services/standardization/sic-eurosic/5-3/ig-module-docs-sic-ip-2026-5.3-en.zip", "source_class": "authoritative_primary", "source_title": "IP Return Request (camt.056) v2.3, SIC IP module documents, release 5.3 archive", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "The IP Return Request guide lists AC03 as one of six permitted reasons for a return request made on behalf of the payer, glossed by SIX as Invalid Creditor Account Number; the companion IP Return Request Rejection guide calls the same code Wrong IBAN when describing its own additional information rule. Confirms the code is on the closed list of six, confirms its meaning, and confirms no public deadline is set for the request or the answer." } ] }, "rail_name": "SIC IP Return Requests", "governing_authority": "SIX Interbank Clearing on behalf of the Swiss National Bank", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "ch-sic-ip-return-request:AM09", "id": "AM09", "rail": "ch-sic-ip-return-request", "kind": "reason-code", "name": "Wrong amount: payer asks for the money back", "group": "administrative", "summary": "The participant that sent an IP customer payment asks for it back on behalf of the payer, who sent the wrong amount.", "triggers": [ "The payer entered an amount other than the one intended [Inference from the code name Wrong Amount]" ], "actions": [ "Sending participant: name the payer as originator of the request (the Name element, not Identification); SIX asks for this on requests made for the originator but does not check it (IP-camt.056 v2.3 element CxlRsnInf/Orgtr)", "Sending participant: the request names the original amount; SIX gives no way to ask for only the excess, so the payer may have to pay the right amount again once the funds come back [Inference]", "Receiving participant: either return the funds with a pacs.004 coded FOCR that quotes the request's CxlId, or refuse with a camt.029 whose first additional information line starts ATR072/ followed by the request reference (IP-pacs.004 v2.4 chapter 4.3; IP-camt.029 v2.3 chapter 4.4)", "Sending participant: if no answer comes, send a status request for the IP return request (pacs.028, IPSRRQ); the receiving participant then has to return or refuse (IP-pacs.028 v2.3 section 3.1.2)" ], "retry": { "allowed": false, "rule": "A return request is not sent again to chase an answer: the sender uses a status request for the IP return request (pacs.028, type IPSRRQ), which the service passes to the receiving participant (IP-pacs.028 v2.3 section 3.1.2). Whether a second camt.056 for the same payment is allowed is not stated publicly [Unverified]. Each request needs its own reference, unique within the current and the previous clearing day (IP-camt.056 v2.3 element CxlId)." }, "facts": { "return_windows": [ { "action": "send an IP return request (camt.056) with this reason", "by": "The participant that sent the original IP customer payment", "deadline": "No public deadline is published. The public guidelines set no time limit for asking; any limit would be in the participant-only SIC Handbook." }, { "action": "answer the request: send the funds back with an IP return (pacs.004, reason FOCR) or refuse with an IP return request rejection (camt.029)", "by": "The participant that received the original IP customer payment", "deadline": "No public deadline is published. The receiving participant must answer one way or the other (IP-pacs.028 v2.3 section 3.1.2), but no public text says how fast." } ], "applies_to": "SIC IP service: the IP return request (camt.056), sent by the participant that made an IP customer payment and passed on by the service to the participant that received it, asking for the settled funds back. The service checks the reason against a closed list of six." }, "caveat": "Whether a partial return of the excess is possible in SIC IP is not stated publicly [Unverified]. SIX meant DUPL, TECH and FRAD for requests a bank starts itself, and CUST, AC03 and AM09 for requests made on behalf of the payer; the service does not enforce that split (IP-camt.056 v2.3 element Rsn/Cd). The service checks format and acknowledges with camt.025, but does not check that the payment referred to ever went through SIC IP (IP-camt.056 v2.3 section 3.1). A return request is a request, not a claim on the funds [Inference]; settlement in SIC is final (SNB-R 2025 ch. 2).", "related": [ "ch-sic-ip-return-request:CUST", "ch-sic-ip-return-request:AC03", "ch-sic-ip-return-request-rejection:CUST" ], "basis": { "sources": "IP-camt.056 v2.3 (SIX Interbank Clearing, Instant Payments Implementation Guidelines, IP Return Request, 2025-02-28, valid from 2025-11-21; the same edition sits in the release 5.3 archive) sections 2 and 3.1 and chapter 4.4 elements CxlId, CxlRsnInf/Orgtr and Rsn/Cd; IP-camt.029 v2.3 (2025-02-28) chapter 4.4 element AddtlInf; IP-pacs.004 v2.4 (2026-02-27, valid from 2026-11-13) chapter 4.3 elements Rsn/Cd and AddtlInf; IP-pacs.028 v2.3 (2025-02-28) section 3.1.2. The code meaning rests on the short name SIX gives next to the code; the ISO External Code Set itself was not read.", "confidence": "medium" }, "currency": { "effective_since": "Since IP-camt.056 v2.0 (first production edition)", "effective_note": "The six codes are in IP-camt.056 v2.3, in force since 2025-11-21 with SIC platform release 5.2 and carried unchanged into the release 5.3 archive for 2026-11-13. No entry in the change history from v1.0 (2022-02-28) onward touches the code list [Inference: the list dates from the first edition]. v2.0 (2022-10-20) was the first edition for production, valid from the November 2023 release. SIX plans to move all SIC IP messages to ISO 20022 2024/2025 versions in November 2027 (SIC Platform Release Notes 2026, CR2026-SIC-0002) [Speculation whether this code changes].", "source_edition": "IP-camt.056 v2.3 (2025-02-28, valid from 2025-11-21, unchanged for release 5.3)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.six-group.com/dam/download/banking-services/standardization/sic-eurosic/5-3/ig-module-docs-sic-ip-2026-5.3-en.zip", "source_class": "authoritative_primary", "source_title": "IP Return Request (camt.056) v2.3, SIC IP module documents, release 5.3 archive", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "The IP Return Request guide lists AM09 as one of six permitted reasons for a return request made on behalf of the payer, glossed by SIX as Wrong Amount. Confirms the code is on the closed list of six, confirms the short name SIX gives it, and confirms no public deadline is set for the request or the answer." } ] }, "rail_name": "SIC IP Return Requests", "governing_authority": "SIX Interbank Clearing on behalf of the Swiss National Bank", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "ch-sic-ip-return-request:CUST", "id": "CUST", "rail": "ch-sic-ip-return-request", "kind": "reason-code", "name": "Payer asks for the money back", "group": "authorization", "summary": "The participant that sent an IP customer payment asks for it back because the payer, its customer, wants it back. The payee's side may agree and return the funds, or refuse.", "triggers": [ "The payer asks its bank to recover a settled instant payment, for example one sent by mistake [Inference from the code name Requested by Customer]" ], "actions": [ "Sending participant: name the payer as originator of the request (the Name element, not Identification); SIX asks for this on requests made for the originator but does not check it (IP-camt.056 v2.3 element CxlRsnInf/Orgtr)", "Sending participant: tell the payer that the request is only a request and the payee may say no [Inference]", "Receiving participant: either return the funds with a pacs.004 coded FOCR that quotes the request's CxlId, or refuse with a camt.029 whose first additional information line starts ATR072/ followed by the request reference (IP-pacs.004 v2.4 chapter 4.3; IP-camt.029 v2.3 chapter 4.4)", "Sending participant: if no answer comes, send a status request for the IP return request (pacs.028, IPSRRQ); the receiving participant then has to return or refuse (IP-pacs.028 v2.3 section 3.1.2)" ], "retry": { "allowed": false, "rule": "A return request is not sent again to chase an answer: the sender uses a status request for the IP return request (pacs.028, type IPSRRQ), which the service passes to the receiving participant (IP-pacs.028 v2.3 section 3.1.2). Whether a second camt.056 for the same payment is allowed is not stated publicly [Unverified]. Each request needs its own reference, unique within the current and the previous clearing day (IP-camt.056 v2.3 element CxlId)." }, "facts": { "return_windows": [ { "action": "send an IP return request (camt.056) with this reason", "by": "The participant that sent the original IP customer payment", "deadline": "No public deadline is published. The public guidelines set no time limit for asking; any limit would be in the participant-only SIC Handbook." }, { "action": "answer the request: send the funds back with an IP return (pacs.004, reason FOCR) or refuse with an IP return request rejection (camt.029)", "by": "The participant that received the original IP customer payment", "deadline": "No public deadline is published. The receiving participant must answer one way or the other (IP-pacs.028 v2.3 section 3.1.2), but no public text says how fast." } ], "applies_to": "SIC IP service: the IP return request (camt.056), sent by the participant that made an IP customer payment and passed on by the service to the participant that received it, asking for the settled funds back. The service checks the reason against a closed list of six." }, "caveat": "CUST means something different in each Swiss family: here the payer asks; in the camt.029 rejection list it is the payee's refusal; in IP returns (pacs.004) CUST marks a return the payee asked for, while a return answering this request carries FOCR (IP-pacs.004 v2.4 chapter 4.3). SIX meant DUPL, TECH and FRAD for requests a bank starts itself, and CUST, AC03 and AM09 for requests made on behalf of the payer; the service does not enforce that split (IP-camt.056 v2.3 element Rsn/Cd). The service checks format and acknowledges with camt.025, but does not check that the payment referred to ever went through SIC IP (IP-camt.056 v2.3 section 3.1). A return request is a request, not a claim on the funds [Inference]; settlement in SIC is final (SNB-R 2025 ch. 2).", "related": [ "ch-sic-ip-return-request:AC03", "ch-sic-ip-return-request:AM09", "ch-sic-ip-return-request-rejection:CUST", "ch-sic-ip-return-request-rejection:NOAS" ], "basis": { "sources": "IP-camt.056 v2.3 (SIX Interbank Clearing, Instant Payments Implementation Guidelines, IP Return Request, 2025-02-28, valid from 2025-11-21; the same edition sits in the release 5.3 archive) sections 2 and 3.1 and chapter 4.4 elements CxlId, CxlRsnInf/Orgtr and Rsn/Cd; IP-camt.029 v2.3 (2025-02-28) chapter 4.4 element AddtlInf; IP-pacs.004 v2.4 (2026-02-27, valid from 2026-11-13) chapter 4.3 elements Rsn/Cd and AddtlInf; IP-pacs.028 v2.3 (2025-02-28) section 3.1.2. The code meaning rests on the short name SIX gives next to the code; the ISO External Code Set itself was not read.", "confidence": "medium" }, "currency": { "effective_since": "Since IP-camt.056 v2.0 (first production edition)", "effective_note": "The six codes are in IP-camt.056 v2.3, in force since 2025-11-21 with SIC platform release 5.2 and carried unchanged into the release 5.3 archive for 2026-11-13. No entry in the change history from v1.0 (2022-02-28) onward touches the code list [Inference: the list dates from the first edition]. v2.0 (2022-10-20) was the first edition for production, valid from the November 2023 release. SIX plans to move all SIC IP messages to ISO 20022 2024/2025 versions in November 2027 (SIC Platform Release Notes 2026, CR2026-SIC-0002) [Speculation whether this code changes].", "source_edition": "IP-camt.056 v2.3 (2025-02-28, valid from 2025-11-21, unchanged for release 5.3)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.six-group.com/dam/download/banking-services/standardization/sic-eurosic/5-3/ig-module-docs-sic-ip-2026-5.3-en.zip", "source_class": "authoritative_primary", "source_title": "IP Return Request (camt.056) v2.3, SIC IP module documents, release 5.3 archive", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "The IP Return Request guide lists CUST as one of six permitted reasons for a return request, glossed by SIX as Requested by Customer and meant for a request made on behalf of the payer. Confirms the code is on the closed list of six, confirms the short name SIX gives it, and confirms the guide sets no public deadline for sending the request or for the receiving side to answer it." } ] }, "rail_name": "SIC IP Return Requests", "governing_authority": "SIX Interbank Clearing on behalf of the Swiss National Bank", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "ch-sic-ip-return-request:DUPL", "id": "DUPL", "rail": "ch-sic-ip-return-request", "kind": "reason-code", "name": "Paid twice: bank asks for one back", "group": "administrative", "summary": "The participant that sent an IP customer payment asks the receiving participant to send back a payment that went out more than once. It is a bank-initiated request; the other side may return the funds or refuse.", "triggers": [ "The sending participant finds it sent the same IP customer payment twice, for example after a technical fault or an unclear status [Inference from the code name Duplicate Payment]" ], "actions": [ "Sending participant: identify itself as originator of the request by its SIC IID (the Identification element, not Name); SIX asks for this on bank-initiated requests but does not check it (IP-camt.056 v2.3 element CxlRsnInf/Orgtr)", "Sending participant: quote the original message and transaction references, amount in CHF and settlement date, which SIX makes mandatory (IP-camt.056 v2.3 sections 3.3 and 3.4)", "Receiving participant: either return the funds with a pacs.004 coded FOCR that quotes the request's CxlId, or refuse with a camt.029 whose first additional information line starts ATR053/ followed by the request reference (IP-pacs.004 v2.4 chapter 4.3; IP-camt.029 v2.3 chapter 4.4)", "Sending participant: if no answer comes, send a status request for the IP return request (pacs.028, IPSRRQ); the receiving participant then has to return or refuse (IP-pacs.028 v2.3 section 3.1.2)" ], "retry": { "allowed": false, "rule": "A return request is not sent again to chase an answer: the sender uses a status request for the IP return request (pacs.028, type IPSRRQ), which the service passes to the receiving participant (IP-pacs.028 v2.3 section 3.1.2). Whether a second camt.056 for the same payment is allowed is not stated publicly [Unverified]. Each request needs its own reference, unique within the current and the previous clearing day (IP-camt.056 v2.3 element CxlId)." }, "facts": { "return_windows": [ { "action": "send an IP return request (camt.056) with this reason", "by": "The participant that sent the original IP customer payment", "deadline": "No public deadline is published. The public guidelines set no time limit for asking; any limit would be in the participant-only SIC Handbook." }, { "action": "answer the request: send the funds back with an IP return (pacs.004, reason FOCR) or refuse with an IP return request rejection (camt.029)", "by": "The participant that received the original IP customer payment", "deadline": "No public deadline is published. The receiving participant must answer one way or the other (IP-pacs.028 v2.3 section 3.1.2), but no public text says how fast." } ], "applies_to": "SIC IP service: the IP return request (camt.056), sent by the participant that made an IP customer payment and passed on by the service to the participant that received it, asking for the settled funds back. The service checks the reason against a closed list of six." }, "caveat": "DUPL is for a duplicate that settled. A duplicate the receiving participant catches before settlement would show up instead as a NEG002 rejection coded AM05 [Inference]. SIX meant DUPL, TECH and FRAD for requests a bank starts itself, and CUST, AC03 and AM09 for requests made on behalf of the payer; the service does not enforce that split (IP-camt.056 v2.3 element Rsn/Cd). The service checks format and acknowledges with camt.025, but does not check that the payment referred to ever went through SIC IP (IP-camt.056 v2.3 section 3.1). A return request is a request, not a claim on the funds [Inference]; settlement in SIC is final (SNB-R 2025 ch. 2).", "related": [ "ch-sic-ip-return-request:TECH", "ch-sic-ip-return-request-rejection:ARDT", "ch-sic-ip-return-request-rejection:NOOR", "ch-sic-ip-reject:AM05" ], "basis": { "sources": "IP-camt.056 v2.3 (SIX Interbank Clearing, Instant Payments Implementation Guidelines, IP Return Request, 2025-02-28, valid from 2025-11-21; the same edition sits in the release 5.3 archive) sections 2 and 3.1 and chapter 4.4 elements CxlId, CxlRsnInf/Orgtr and Rsn/Cd; IP-camt.029 v2.3 (2025-02-28) chapter 4.4 element AddtlInf; IP-pacs.004 v2.4 (2026-02-27, valid from 2026-11-13) chapter 4.3 elements Rsn/Cd and AddtlInf; IP-pacs.028 v2.3 (2025-02-28) section 3.1.2. The code meaning rests on the short name SIX gives next to the code; the ISO External Code Set itself was not read.", "confidence": "medium" }, "currency": { "effective_since": "Since IP-camt.056 v2.0 (first production edition)", "effective_note": "The six codes are in IP-camt.056 v2.3, in force since 2025-11-21 with SIC platform release 5.2 and carried unchanged into the release 5.3 archive for 2026-11-13. No entry in the change history from v1.0 (2022-02-28) onward touches the code list [Inference: the list dates from the first edition]. v2.0 (2022-10-20) was the first edition for production, valid from the November 2023 release. SIX plans to move all SIC IP messages to ISO 20022 2024/2025 versions in November 2027 (SIC Platform Release Notes 2026, CR2026-SIC-0002) [Speculation whether this code changes].", "source_edition": "IP-camt.056 v2.3 (2025-02-28, valid from 2025-11-21, unchanged for release 5.3)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.six-group.com/dam/download/banking-services/standardization/sic-eurosic/5-3/ig-module-docs-sic-ip-2026-5.3-en.zip", "source_class": "authoritative_primary", "source_title": "IP Return Request (camt.056) v2.3, SIC IP module documents, release 5.3 archive", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "The IP Return Request guide lists DUPL as one of six permitted reasons for a return request a bank starts itself, glossed by SIX as Duplicate Payment. Confirms the code is on the closed list of six, confirms the short name SIX gives it, and confirms no public deadline is set for the request or the answer." } ] }, "rail_name": "SIC IP Return Requests", "governing_authority": "SIX Interbank Clearing on behalf of the Swiss National Bank", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "ch-sic-ip-return-request:FRAD", "id": "FRAD", "rail": "ch-sic-ip-return-request", "kind": "reason-code", "name": "Fraud: bank asks for the money back", "group": "authorization", "summary": "The participant that sent an IP customer payment asks for it back because the payment came from fraud. It is a bank-initiated request; the receiving side may refuse, and may then give details that help recover the money by other means.", "triggers": [ "The sending participant finds that the payment was initiated through fraud, such as a compromised account or a scam [Inference from the code name Fraudulent Origin]" ], "actions": [ "Sending participant: identify itself as originator of the request by its SIC IID (the Identification element, not Name); SIX asks for this on bank-initiated requests but does not check it (IP-camt.056 v2.3 element CxlRsnInf/Orgtr)", "Sending participant: act fast; the public guidelines set no deadline, but funds may be moved on once credited [Inference]", "Receiving participant, if it refuses: it may add up to ten further lines starting FRAD/ with details that could let the money be claimed back outside this process, minding data protection (IP-camt.029 v2.3 chapter 4.4)", "Receiving participant: either return the funds with a pacs.004 coded FOCR that quotes the request's CxlId, or refuse with a camt.029 whose first additional information line starts ATR053/ followed by the request reference (IP-pacs.004 v2.4 chapter 4.3; IP-camt.029 v2.3 chapter 4.4)", "Sending participant: if no answer comes, send a status request for the IP return request (pacs.028, IPSRRQ); the receiving participant then has to return or refuse (IP-pacs.028 v2.3 section 3.1.2)" ], "retry": { "allowed": false, "rule": "A return request is not sent again to chase an answer: the sender uses a status request for the IP return request (pacs.028, type IPSRRQ), which the service passes to the receiving participant (IP-pacs.028 v2.3 section 3.1.2). Whether a second camt.056 for the same payment is allowed is not stated publicly [Unverified]. Each request needs its own reference, unique within the current and the previous clearing day (IP-camt.056 v2.3 element CxlId)." }, "facts": { "return_windows": [ { "action": "send an IP return request (camt.056) with this reason", "by": "The participant that sent the original IP customer payment", "deadline": "No public deadline is published. The public guidelines set no time limit for asking; any limit would be in the participant-only SIC Handbook." }, { "action": "answer the request: send the funds back with an IP return (pacs.004, reason FOCR) or refuse with an IP return request rejection (camt.029)", "by": "The participant that received the original IP customer payment", "deadline": "No public deadline is published. The receiving participant must answer one way or the other (IP-pacs.028 v2.3 section 3.1.2), but no public text says how fast." } ], "applies_to": "SIC IP service: the IP return request (camt.056), sent by the participant that made an IP customer payment and passed on by the service to the participant that received it, asking for the settled funds back. The service checks the reason against a closed list of six." }, "caveat": "SIX does not define fraud for this code or say whether a payer who was tricked into authorising the payment is covered [Unverified]. SIX meant DUPL, TECH and FRAD for requests a bank starts itself, and CUST, AC03 and AM09 for requests made on behalf of the payer; the service does not enforce that split (IP-camt.056 v2.3 element Rsn/Cd). The service checks format and acknowledges with camt.025, but does not check that the payment referred to ever went through SIC IP (IP-camt.056 v2.3 section 3.1). A return request is a request, not a claim on the funds [Inference]; settlement in SIC is final (SNB-R 2025 ch. 2).", "related": [ "ch-sic-ip-return-request-rejection:LEGL", "ch-sic-ip-return-request-rejection:NOAS", "ch-sic-ip-return-request-rejection:CUST", "ch-sic-ip-return-request-rejection:AM04" ], "basis": { "sources": "IP-camt.056 v2.3 (SIX Interbank Clearing, Instant Payments Implementation Guidelines, IP Return Request, 2025-02-28, valid from 2025-11-21; the same edition sits in the release 5.3 archive) sections 2 and 3.1 and chapter 4.4 elements CxlId, CxlRsnInf/Orgtr and Rsn/Cd; IP-camt.029 v2.3 (2025-02-28) chapter 4.4 element AddtlInf; IP-pacs.004 v2.4 (2026-02-27, valid from 2026-11-13) chapter 4.3 elements Rsn/Cd and AddtlInf; IP-pacs.028 v2.3 (2025-02-28) section 3.1.2. The code meaning rests on the short name SIX gives next to the code; the ISO External Code Set itself was not read.", "confidence": "medium" }, "currency": { "effective_since": "Since IP-camt.056 v2.0 (first production edition)", "effective_note": "The six codes are in IP-camt.056 v2.3, in force since 2025-11-21 with SIC platform release 5.2 and carried unchanged into the release 5.3 archive for 2026-11-13. No entry in the change history from v1.0 (2022-02-28) onward touches the code list [Inference: the list dates from the first edition]. v2.0 (2022-10-20) was the first edition for production, valid from the November 2023 release. SIX plans to move all SIC IP messages to ISO 20022 2024/2025 versions in November 2027 (SIC Platform Release Notes 2026, CR2026-SIC-0002) [Speculation whether this code changes].", "source_edition": "IP-camt.056 v2.3 (2025-02-28, valid from 2025-11-21, unchanged for release 5.3)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.six-group.com/dam/download/banking-services/standardization/sic-eurosic/5-3/ig-module-docs-sic-ip-2026-5.3-en.zip", "source_class": "authoritative_primary", "source_title": "IP Return Request (camt.056) v2.3, SIC IP module documents, release 5.3 archive", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "The IP Return Request guide lists FRAD as one of six permitted reasons for a return request a bank starts itself, glossed by SIX as Fraudulent Origin. Confirms the code is on the closed list of six, confirms the short name SIX gives it, and confirms no public deadline is set for the request or the answer." } ] }, "rail_name": "SIC IP Return Requests", "governing_authority": "SIX Interbank Clearing on behalf of the Swiss National Bank", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "judgement", "label": "a fraud call", "needs": "how the bank judged this payment for fraud", "detail": "SIX does not define fraud for this code or say whether a payer who was tricked into authorising the payment is covered [Unverified].", "from": "caveat" } ] }, { "uid": "ch-sic-ip-return-request:TECH", "id": "TECH", "rail": "ch-sic-ip-return-request", "kind": "reason-code", "name": "Technical problem: bank asks for the money back", "group": "technical", "summary": "The participant that sent an IP customer payment asks for it back because a technical problem on its side caused the payment. It is a bank-initiated request.", "triggers": [ "A system fault at the sending participant released a payment that should not have gone, or went out wrong [Inference from the code name Technical Problem]" ], "actions": [ "Sending participant: identify itself as originator of the request by its SIC IID (the Identification element, not Name); SIX asks for this on bank-initiated requests but does not check it (IP-camt.056 v2.3 element CxlRsnInf/Orgtr)", "Sending participant: tell the payer, if the payer's account was debited, what it is doing to fix the error [Inference]", "Receiving participant: either return the funds with a pacs.004 coded FOCR that quotes the request's CxlId, or refuse with a camt.029 whose first additional information line starts ATR053/ followed by the request reference (IP-pacs.004 v2.4 chapter 4.3; IP-camt.029 v2.3 chapter 4.4)", "Sending participant: if no answer comes, send a status request for the IP return request (pacs.028, IPSRRQ); the receiving participant then has to return or refuse (IP-pacs.028 v2.3 section 3.1.2)" ], "retry": { "allowed": false, "rule": "A return request is not sent again to chase an answer: the sender uses a status request for the IP return request (pacs.028, type IPSRRQ), which the service passes to the receiving participant (IP-pacs.028 v2.3 section 3.1.2). Whether a second camt.056 for the same payment is allowed is not stated publicly [Unverified]. Each request needs its own reference, unique within the current and the previous clearing day (IP-camt.056 v2.3 element CxlId)." }, "facts": { "return_windows": [ { "action": "send an IP return request (camt.056) with this reason", "by": "The participant that sent the original IP customer payment", "deadline": "No public deadline is published. The public guidelines set no time limit for asking; any limit would be in the participant-only SIC Handbook." }, { "action": "answer the request: send the funds back with an IP return (pacs.004, reason FOCR) or refuse with an IP return request rejection (camt.029)", "by": "The participant that received the original IP customer payment", "deadline": "No public deadline is published. The receiving participant must answer one way or the other (IP-pacs.028 v2.3 section 3.1.2), but no public text says how fast." } ], "applies_to": "SIC IP service: the IP return request (camt.056), sent by the participant that made an IP customer payment and passed on by the service to the participant that received it, asking for the settled funds back. The service checks the reason against a closed list of six." }, "caveat": "The SIC RTGS guidelines recommend TECH for requests made for the originator as well (RTGS-camt.056 v2.4, element Rsn/Cd); SIC IP lists it only for bank-initiated requests. Do not carry the RTGS habit over. SIX meant DUPL, TECH and FRAD for requests a bank starts itself, and CUST, AC03 and AM09 for requests made on behalf of the payer; the service does not enforce that split (IP-camt.056 v2.3 element Rsn/Cd). The service checks format and acknowledges with camt.025, but does not check that the payment referred to ever went through SIC IP (IP-camt.056 v2.3 section 3.1). A return request is a request, not a claim on the funds [Inference]; settlement in SIC is final (SNB-R 2025 ch. 2).", "related": [ "ch-sic-ip-return-request:DUPL", "ch-sic-ip-return-request-rejection:ARDT", "ch-sic-ip-return-request-rejection:NOOR" ], "basis": { "sources": "IP-camt.056 v2.3 (SIX Interbank Clearing, Instant Payments Implementation Guidelines, IP Return Request, 2025-02-28, valid from 2025-11-21; the same edition sits in the release 5.3 archive) sections 2 and 3.1 and chapter 4.4 elements CxlId, CxlRsnInf/Orgtr and Rsn/Cd; IP-camt.029 v2.3 (2025-02-28) chapter 4.4 element AddtlInf; IP-pacs.004 v2.4 (2026-02-27, valid from 2026-11-13) chapter 4.3 elements Rsn/Cd and AddtlInf; IP-pacs.028 v2.3 (2025-02-28) section 3.1.2. The code meaning rests on the short name SIX gives next to the code; the ISO External Code Set itself was not read.", "confidence": "medium" }, "currency": { "effective_since": "Since IP-camt.056 v2.0 (first production edition)", "effective_note": "The six codes are in IP-camt.056 v2.3, in force since 2025-11-21 with SIC platform release 5.2 and carried unchanged into the release 5.3 archive for 2026-11-13. No entry in the change history from v1.0 (2022-02-28) onward touches the code list [Inference: the list dates from the first edition]. v2.0 (2022-10-20) was the first edition for production, valid from the November 2023 release. SIX plans to move all SIC IP messages to ISO 20022 2024/2025 versions in November 2027 (SIC Platform Release Notes 2026, CR2026-SIC-0002) [Speculation whether this code changes].", "source_edition": "IP-camt.056 v2.3 (2025-02-28, valid from 2025-11-21, unchanged for release 5.3)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.six-group.com/dam/download/banking-services/standardization/sic-eurosic/5-3/ig-module-docs-sic-ip-2026-5.3-en.zip", "source_class": "authoritative_primary", "source_title": "IP Return Request (camt.056) v2.3, SIC IP module documents, release 5.3 archive", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "The IP Return Request guide lists TECH as one of six permitted reasons for a return request a bank starts itself, glossed by SIX as Technical Problem. Confirms the code is on the closed list of six, confirms the short name SIX gives it, and confirms no public deadline is set for the request or the answer." } ] }, "rail_name": "SIC IP Return Requests", "governing_authority": "SIX Interbank Clearing on behalf of the Swiss National Bank", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "ch-sic-ip-return-request-rejection:AC04", "id": "AC04", "rail": "ch-sic-ip-return-request-rejection", "kind": "reason-code", "name": "Refused: payee account closed", "group": "account", "summary": "The receiving participant refuses a return request because the payee's account has been closed.", "triggers": [ "The account the original payment was credited to is closed, so the receiving participant says it cannot act on it [Inference from the code name Closed Account Number]" ], "actions": [ "Receiving participant: start the first additional information line with ATR053/ for a bank-initiated request, or ATR072/ for one made on behalf of the payer, followed by the reference of the request (IP-camt.029 v2.3 chapter 4.4)", "Sending participant: tell the payer that recovery through SIC IP has ended and that other steps, if any, lie outside the system [Inference]" ], "retry": { "allowed": false, "rule": "A rejection closes the request inside SIC IP; the public guidelines give no appeal or second round [Unverified]. Recovery, if any, happens outside the SIC IP process [Inference]." }, "facts": { "return_windows": [ { "action": "refuse an IP return request with an IP return request rejection (camt.029, status RJCR) carrying this reason", "by": "The participant that received the original IP customer payment and the return request", "deadline": "No public deadline is published. The receiving participant must either return the funds or refuse (IP-pacs.028 v2.3 section 3.1.2), but no public text says how fast; any limit would be in the participant-only SIC Handbook." } ], "applies_to": "SIC IP service: the IP return request rejection (camt.029, status RJCR) that the participant which received an IP customer payment sends, through the service, to refuse a return request (camt.056). The service checks the reason against a closed list of seven." }, "caveat": "Why a closed account blocks a return, and where the funds went, is not explained by SIX [Unverified]. The rejection list is the same whatever the request code was; SIX does not restrict which rejection reason may answer which request reason, and the service does not check that the request referred to a payment processed in SIC IP (IP-camt.029 v2.3 section 3.1).", "related": [ "ch-sic-ip-return-request-rejection:AM04", "ch-sic-ip-return-request-rejection:LEGL", "ch-sic-ip-return-request:AC03" ], "basis": { "sources": "IP-camt.029 v2.3 (SIX Interbank Clearing, Instant Payments Implementation Guidelines, IP Return Request Rejection, 2025-02-28, valid from 2025-11-21; the same edition sits in the release 5.3 archive) sections 2 and 3.1 and chapter 4.4 elements Conf, TxCxlSts, Rsn/Cd and AddtlInf; IP-camt.056 v2.3 (2025-02-28) element Rsn/Cd; IP-pacs.028 v2.3 (2025-02-28) section 3.1.2. The code meaning rests on the short name SIX gives next to the code; the ISO External Code Set itself was not read.", "confidence": "medium" }, "currency": { "effective_since": "Since IP-camt.029 v2.0 (first production edition)", "effective_note": "The seven codes are in IP-camt.029 v2.3, in force since 2025-11-21 with SIC platform release 5.2 and carried unchanged into the release 5.3 archive for 2026-11-13. The change history from v1.0 onward changes the additional information prefixes in v2.1 (2023-03-31) but no entry touches the code list [Inference: the list dates from the first edition]. v2.0 was the first edition for production, valid from the November 2023 release. SIX plans to move all SIC IP messages to ISO 20022 2024/2025 versions in November 2027 (SIC Platform Release Notes 2026, CR2026-SIC-0002) [Speculation whether this code changes].", "source_edition": "IP-camt.029 v2.3 (2025-02-28, valid from 2025-11-21, unchanged for release 5.3)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.six-group.com/dam/download/banking-services/standardization/sic-eurosic/5-3/ig-module-docs-sic-ip-2026-5.3-en.zip", "source_class": "authoritative_primary", "source_title": "IP Return Request Rejection (camt.029) v2.3, SIC IP module documents, release 5.3 archive", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "The IP Return Request Rejection guide lists AC04 as one of seven permitted reasons to refuse a return request, glossed by SIX as Closed Account Number. Confirms the code is on the closed list of seven, confirms the short name SIX gives it, and confirms no public deadline is set for answering a return request." } ] }, "rail_name": "SIC IP Return Request Rejections", "governing_authority": "SIX Interbank Clearing on behalf of the Swiss National Bank", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "ch-sic-ip-return-request-rejection:AM04", "id": "AM04", "rail": "ch-sic-ip-return-request-rejection", "kind": "reason-code", "name": "Refused: not enough money left", "group": "funds", "summary": "The receiving participant refuses a return request because the payee's account does not hold enough to send the money back.", "triggers": [ "The payee has already used or moved the funds [Inference from the code name Insufficient Funds]" ], "actions": [ "Receiving participant: start the first additional information line with ATR053/ for a bank-initiated request, or ATR072/ for one made on behalf of the payer, followed by the reference of the request (IP-camt.029 v2.3 chapter 4.4)", "Sending participant: tell the payer; for fraud or wrong-account requests, look for recovery details in the rejection's FRAD/ or ATR078/ lines [Inference]" ], "retry": { "allowed": false, "rule": "A rejection closes the request inside SIC IP; the public guidelines give no appeal or second round [Unverified]. Recovery, if any, happens outside the SIC IP process [Inference]." }, "facts": { "return_windows": [ { "action": "refuse an IP return request with an IP return request rejection (camt.029, status RJCR) carrying this reason", "by": "The participant that received the original IP customer payment and the return request", "deadline": "No public deadline is published. The receiving participant must either return the funds or refuse (IP-pacs.028 v2.3 section 3.1.2), but no public text says how fast; any limit would be in the participant-only SIC Handbook." } ], "applies_to": "SIC IP service: the IP return request rejection (camt.029, status RJCR) that the participant which received an IP customer payment sends, through the service, to refuse a return request (camt.056). The service checks the reason against a closed list of seven." }, "caveat": "The code does not say whether a partial return was possible [Unverified]. The rejection list is the same whatever the request code was; SIX does not restrict which rejection reason may answer which request reason, and the service does not check that the request referred to a payment processed in SIC IP (IP-camt.029 v2.3 section 3.1).", "related": [ "ch-sic-ip-return-request-rejection:AC04", "ch-sic-ip-return-request-rejection:NOAS", "ch-sic-ip-return-request:FRAD" ], "basis": { "sources": "IP-camt.029 v2.3 (SIX Interbank Clearing, Instant Payments Implementation Guidelines, IP Return Request Rejection, 2025-02-28, valid from 2025-11-21; the same edition sits in the release 5.3 archive) sections 2 and 3.1 and chapter 4.4 elements Conf, TxCxlSts, Rsn/Cd and AddtlInf; IP-camt.056 v2.3 (2025-02-28) element Rsn/Cd; IP-pacs.028 v2.3 (2025-02-28) section 3.1.2. The code meaning rests on the short name SIX gives next to the code; the ISO External Code Set itself was not read.", "confidence": "medium" }, "currency": { "effective_since": "Since IP-camt.029 v2.0 (first production edition)", "effective_note": "The seven codes are in IP-camt.029 v2.3, in force since 2025-11-21 with SIC platform release 5.2 and carried unchanged into the release 5.3 archive for 2026-11-13. The change history from v1.0 onward changes the additional information prefixes in v2.1 (2023-03-31) but no entry touches the code list [Inference: the list dates from the first edition]. v2.0 was the first edition for production, valid from the November 2023 release. SIX plans to move all SIC IP messages to ISO 20022 2024/2025 versions in November 2027 (SIC Platform Release Notes 2026, CR2026-SIC-0002) [Speculation whether this code changes].", "source_edition": "IP-camt.029 v2.3 (2025-02-28, valid from 2025-11-21, unchanged for release 5.3)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.six-group.com/dam/download/banking-services/standardization/sic-eurosic/5-3/ig-module-docs-sic-ip-2026-5.3-en.zip", "source_class": "authoritative_primary", "source_title": "IP Return Request Rejection (camt.029) v2.3, SIC IP module documents, release 5.3 archive", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "The IP Return Request Rejection guide lists AM04 as one of seven permitted reasons to refuse a return request, glossed by SIX as Insufficient Funds. Confirms the code is on the closed list of seven, confirms the short name SIX gives it, and confirms no public deadline is set for answering a return request." } ] }, "rail_name": "SIC IP Return Request Rejections", "governing_authority": "SIX Interbank Clearing on behalf of the Swiss National Bank", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "ch-sic-ip-return-request-rejection:ARDT", "id": "ARDT", "rail": "ch-sic-ip-return-request-rejection", "kind": "reason-code", "name": "Refused: already sent back", "group": "administrative", "summary": "The receiving participant refuses a return request because the funds have already been returned.", "triggers": [ "The receiving participant already sent the money back, for example with an earlier IP return (pacs.004) [Inference from the code name Already Returned]" ], "actions": [ "Receiving participant: start the first additional information line with ATR053/ for a bank-initiated request, or ATR072/ for one made on behalf of the payer, followed by the reference of the request (IP-camt.029 v2.3 chapter 4.4)", "Sending participant: look for the earlier return and its IP Execution Confirmation before chasing further [Inference]" ], "retry": { "allowed": false, "rule": "A rejection closes the request inside SIC IP; the public guidelines give no appeal or second round [Unverified]. Recovery, if any, happens outside the SIC IP process [Inference]." }, "facts": { "return_windows": [ { "action": "refuse an IP return request with an IP return request rejection (camt.029, status RJCR) carrying this reason", "by": "The participant that received the original IP customer payment and the return request", "deadline": "No public deadline is published. The receiving participant must either return the funds or refuse (IP-pacs.028 v2.3 section 3.1.2), but no public text says how fast; any limit would be in the participant-only SIC Handbook." } ], "applies_to": "SIC IP service: the IP return request rejection (camt.029, status RJCR) that the participant which received an IP customer payment sends, through the service, to refuse a return request (camt.056). The service checks the reason against a closed list of seven." }, "caveat": "The code does not name the earlier return; matching it is left to the participants [Inference]. The rejection list is the same whatever the request code was; SIX does not restrict which rejection reason may answer which request reason, and the service does not check that the request referred to a payment processed in SIC IP (IP-camt.029 v2.3 section 3.1).", "related": [ "ch-sic-ip-return-request-rejection:NOOR", "ch-sic-ip-return-request:DUPL", "ch-sic-ip-return-request:TECH" ], "basis": { "sources": "IP-camt.029 v2.3 (SIX Interbank Clearing, Instant Payments Implementation Guidelines, IP Return Request Rejection, 2025-02-28, valid from 2025-11-21; the same edition sits in the release 5.3 archive) sections 2 and 3.1 and chapter 4.4 elements Conf, TxCxlSts, Rsn/Cd and AddtlInf; IP-camt.056 v2.3 (2025-02-28) element Rsn/Cd; IP-pacs.028 v2.3 (2025-02-28) section 3.1.2. The code meaning rests on the short name SIX gives next to the code; the ISO External Code Set itself was not read.", "confidence": "medium" }, "currency": { "effective_since": "Since IP-camt.029 v2.0 (first production edition)", "effective_note": "The seven codes are in IP-camt.029 v2.3, in force since 2025-11-21 with SIC platform release 5.2 and carried unchanged into the release 5.3 archive for 2026-11-13. The change history from v1.0 onward changes the additional information prefixes in v2.1 (2023-03-31) but no entry touches the code list [Inference: the list dates from the first edition]. v2.0 was the first edition for production, valid from the November 2023 release. SIX plans to move all SIC IP messages to ISO 20022 2024/2025 versions in November 2027 (SIC Platform Release Notes 2026, CR2026-SIC-0002) [Speculation whether this code changes].", "source_edition": "IP-camt.029 v2.3 (2025-02-28, valid from 2025-11-21, unchanged for release 5.3)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.six-group.com/dam/download/banking-services/standardization/sic-eurosic/5-3/ig-module-docs-sic-ip-2026-5.3-en.zip", "source_class": "authoritative_primary", "source_title": "IP Return Request Rejection (camt.029) v2.3, SIC IP module documents, release 5.3 archive", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "The IP Return Request Rejection guide lists ARDT as one of seven permitted reasons a receiving participant may use to refuse a return request, glossed by SIX as Already Returned. Confirms the code is on the closed list of seven, confirms the short name SIX gives it, and confirms no public deadline is set for answering a return request." } ] }, "rail_name": "SIC IP Return Request Rejections", "governing_authority": "SIX Interbank Clearing on behalf of the Swiss National Bank", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "ch-sic-ip-return-request-rejection:CUST", "id": "CUST", "rail": "ch-sic-ip-return-request-rejection", "kind": "reason-code", "name": "Refused: payee said no", "group": "authorization", "summary": "The receiving participant refuses a return request because its customer, the payee, decided not to give the money back.", "triggers": [ "The payee was asked and refused [Inference from the code name Customer Decision]" ], "actions": [ "Receiving participant: start the first additional information line with ATR053/ for a bank-initiated request, or ATR072/ for one made on behalf of the payer, followed by the reference of the request (IP-camt.029 v2.3 chapter 4.4)", "Sending participant: tell the payer that the payee refused; any claim now lies between payer and payee outside SIC [Inference]" ], "retry": { "allowed": false, "rule": "A rejection closes the request inside SIC IP; the public guidelines give no appeal or second round [Unverified]. Recovery, if any, happens outside the SIC IP process [Inference]." }, "facts": { "return_windows": [ { "action": "refuse an IP return request with an IP return request rejection (camt.029, status RJCR) carrying this reason", "by": "The participant that received the original IP customer payment and the return request", "deadline": "No public deadline is published. The receiving participant must either return the funds or refuse (IP-pacs.028 v2.3 section 3.1.2), but no public text says how fast; any limit would be in the participant-only SIC Handbook." } ], "applies_to": "SIC IP service: the IP return request rejection (camt.029, status RJCR) that the participant which received an IP customer payment sends, through the service, to refuse a return request (camt.056). The service checks the reason against a closed list of seven." }, "caveat": "CUST here is the payee's refusal; in the camt.056 list the same letters mean the payer asked for the money back. They are separate records. The rejection list is the same whatever the request code was; SIX does not restrict which rejection reason may answer which request reason, and the service does not check that the request referred to a payment processed in SIC IP (IP-camt.029 v2.3 section 3.1).", "related": [ "ch-sic-ip-return-request-rejection:NOAS", "ch-sic-ip-return-request:CUST", "ch-sic-ip-return-request:AC03" ], "basis": { "sources": "IP-camt.029 v2.3 (SIX Interbank Clearing, Instant Payments Implementation Guidelines, IP Return Request Rejection, 2025-02-28, valid from 2025-11-21; the same edition sits in the release 5.3 archive) sections 2 and 3.1 and chapter 4.4 elements Conf, TxCxlSts, Rsn/Cd and AddtlInf; IP-camt.056 v2.3 (2025-02-28) element Rsn/Cd; IP-pacs.028 v2.3 (2025-02-28) section 3.1.2. The code meaning rests on the short name SIX gives next to the code; the ISO External Code Set itself was not read.", "confidence": "medium" }, "currency": { "effective_since": "Since IP-camt.029 v2.0 (first production edition)", "effective_note": "The seven codes are in IP-camt.029 v2.3, in force since 2025-11-21 with SIC platform release 5.2 and carried unchanged into the release 5.3 archive for 2026-11-13. The change history from v1.0 onward changes the additional information prefixes in v2.1 (2023-03-31) but no entry touches the code list [Inference: the list dates from the first edition]. v2.0 was the first edition for production, valid from the November 2023 release. SIX plans to move all SIC IP messages to ISO 20022 2024/2025 versions in November 2027 (SIC Platform Release Notes 2026, CR2026-SIC-0002) [Speculation whether this code changes].", "source_edition": "IP-camt.029 v2.3 (2025-02-28, valid from 2025-11-21, unchanged for release 5.3)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.six-group.com/dam/download/banking-services/standardization/sic-eurosic/5-3/ig-module-docs-sic-ip-2026-5.3-en.zip", "source_class": "authoritative_primary", "source_title": "IP Return Request Rejection (camt.029) v2.3, SIC IP module documents, release 5.3 archive", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "The IP Return Request Rejection guide lists CUST as one of seven permitted reasons to refuse a return request, glossed by SIX as Customer Decision, meaning the payee's own decision to refuse. Confirms the code is on the closed list of seven, confirms the short name SIX gives it, and confirms no public deadline is set for answering a return request." } ] }, "rail_name": "SIC IP Return Request Rejections", "governing_authority": "SIX Interbank Clearing on behalf of the Swiss National Bank", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "ch-sic-ip-return-request-rejection:LEGL", "id": "LEGL", "rail": "ch-sic-ip-return-request-rejection", "kind": "reason-code", "name": "Refused: legal decision", "group": "administrative", "summary": "The receiving participant refuses a return request for a legal reason.", "triggers": [ "A legal or official decision, such as a court order or a freeze, stops the receiving participant from returning the funds [Inference from the code name Legal Decision]" ], "actions": [ "Receiving participant: start the first additional information line with ATR053/ for a bank-initiated request, or ATR072/ for one made on behalf of the payer, followed by the reference of the request (IP-camt.029 v2.3 chapter 4.4)", "Receiving participant: when refusing a bank-initiated request, it may add up to two lines starting ATR057/ to explain the reason, minding data protection (IP-camt.029 v2.3 chapter 4.4)", "Sending participant: pass on to the payer only what the law allows [Inference]" ], "retry": { "allowed": false, "rule": "A rejection closes the request inside SIC IP; the public guidelines give no appeal or second round [Unverified]. Recovery, if any, happens outside the SIC IP process [Inference]." }, "facts": { "return_windows": [ { "action": "refuse an IP return request with an IP return request rejection (camt.029, status RJCR) carrying this reason", "by": "The participant that received the original IP customer payment and the return request", "deadline": "No public deadline is published. The receiving participant must either return the funds or refuse (IP-pacs.028 v2.3 section 3.1.2), but no public text says how fast; any limit would be in the participant-only SIC Handbook." } ], "applies_to": "SIC IP service: the IP return request rejection (camt.029, status RJCR) that the participant which received an IP customer payment sends, through the service, to refuse a return request (camt.056). The service checks the reason against a closed list of seven." }, "caveat": "SIX does not list which legal grounds qualify [Unverified]. The rejection list is the same whatever the request code was; SIX does not restrict which rejection reason may answer which request reason, and the service does not check that the request referred to a payment processed in SIC IP (IP-camt.029 v2.3 section 3.1).", "related": [ "ch-sic-ip-return-request-rejection:AC04", "ch-sic-ip-return-request:FRAD" ], "basis": { "sources": "IP-camt.029 v2.3 (SIX Interbank Clearing, Instant Payments Implementation Guidelines, IP Return Request Rejection, 2025-02-28, valid from 2025-11-21; the same edition sits in the release 5.3 archive) sections 2 and 3.1 and chapter 4.4 elements Conf, TxCxlSts, Rsn/Cd and AddtlInf; IP-camt.056 v2.3 (2025-02-28) element Rsn/Cd; IP-pacs.028 v2.3 (2025-02-28) section 3.1.2. The code meaning rests on the short name SIX gives next to the code; the ISO External Code Set itself was not read.", "confidence": "medium" }, "currency": { "effective_since": "Since IP-camt.029 v2.0 (first production edition)", "effective_note": "The seven codes are in IP-camt.029 v2.3, in force since 2025-11-21 with SIC platform release 5.2 and carried unchanged into the release 5.3 archive for 2026-11-13. The change history from v1.0 onward changes the additional information prefixes in v2.1 (2023-03-31) but no entry touches the code list [Inference: the list dates from the first edition]. v2.0 was the first edition for production, valid from the November 2023 release. SIX plans to move all SIC IP messages to ISO 20022 2024/2025 versions in November 2027 (SIC Platform Release Notes 2026, CR2026-SIC-0002) [Speculation whether this code changes].", "source_edition": "IP-camt.029 v2.3 (2025-02-28, valid from 2025-11-21, unchanged for release 5.3)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.six-group.com/dam/download/banking-services/standardization/sic-eurosic/5-3/ig-module-docs-sic-ip-2026-5.3-en.zip", "source_class": "authoritative_primary", "source_title": "IP Return Request Rejection (camt.029) v2.3, SIC IP module documents, release 5.3 archive", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "The IP Return Request Rejection guide lists LEGL as one of seven permitted reasons to refuse a return request, glossed by SIX as Legal Decision, and it is the one reason for which the guide allows extra additional information lines on request. Confirms the code is on the closed list of seven, confirms the short name SIX gives it, and confirms no public deadline is set for answering a return request." } ] }, "rail_name": "SIC IP Return Request Rejections", "governing_authority": "SIX Interbank Clearing on behalf of the Swiss National Bank", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "ch-sic-ip-return-request-rejection:NOAS", "id": "NOAS", "rail": "ch-sic-ip-return-request-rejection", "kind": "reason-code", "name": "Refused: payee did not answer", "group": "authorization", "summary": "The receiving participant refuses a return request because the payee did not respond when asked.", "triggers": [ "The receiving participant asked the payee for consent and got no reply [Inference from the code name No Answer From Customer]" ], "actions": [ "Receiving participant: start the first additional information line with ATR053/ for a bank-initiated request, or ATR072/ for one made on behalf of the payer, followed by the reference of the request (IP-camt.029 v2.3 chapter 4.4)", "Sending participant: tell the payer; any further claim lies outside SIC [Inference]" ], "retry": { "allowed": false, "rule": "A rejection closes the request inside SIC IP; the public guidelines give no appeal or second round [Unverified]. Recovery, if any, happens outside the SIC IP process [Inference]." }, "facts": { "return_windows": [ { "action": "refuse an IP return request with an IP return request rejection (camt.029, status RJCR) carrying this reason", "by": "The participant that received the original IP customer payment and the return request", "deadline": "No public deadline is published. The receiving participant must either return the funds or refuse (IP-pacs.028 v2.3 section 3.1.2), but no public text says how fast; any limit would be in the participant-only SIC Handbook." } ], "applies_to": "SIC IP service: the IP return request rejection (camt.029, status RJCR) that the participant which received an IP customer payment sends, through the service, to refuse a return request (camt.056). The service checks the reason against a closed list of seven." }, "caveat": "How long the receiving participant waits for the payee before using NOAS is not set in public text [Unverified]. The rejection list is the same whatever the request code was; SIX does not restrict which rejection reason may answer which request reason, and the service does not check that the request referred to a payment processed in SIC IP (IP-camt.029 v2.3 section 3.1).", "related": [ "ch-sic-ip-return-request-rejection:CUST", "ch-sic-ip-return-request:CUST", "ch-sic-ip-return-request:FRAD" ], "basis": { "sources": "IP-camt.029 v2.3 (SIX Interbank Clearing, Instant Payments Implementation Guidelines, IP Return Request Rejection, 2025-02-28, valid from 2025-11-21; the same edition sits in the release 5.3 archive) sections 2 and 3.1 and chapter 4.4 elements Conf, TxCxlSts, Rsn/Cd and AddtlInf; IP-camt.056 v2.3 (2025-02-28) element Rsn/Cd; IP-pacs.028 v2.3 (2025-02-28) section 3.1.2. The code meaning rests on the short name SIX gives next to the code; the ISO External Code Set itself was not read.", "confidence": "medium" }, "currency": { "effective_since": "Since IP-camt.029 v2.0 (first production edition)", "effective_note": "The seven codes are in IP-camt.029 v2.3, in force since 2025-11-21 with SIC platform release 5.2 and carried unchanged into the release 5.3 archive for 2026-11-13. The change history from v1.0 onward changes the additional information prefixes in v2.1 (2023-03-31) but no entry touches the code list [Inference: the list dates from the first edition]. v2.0 was the first edition for production, valid from the November 2023 release. SIX plans to move all SIC IP messages to ISO 20022 2024/2025 versions in November 2027 (SIC Platform Release Notes 2026, CR2026-SIC-0002) [Speculation whether this code changes].", "source_edition": "IP-camt.029 v2.3 (2025-02-28, valid from 2025-11-21, unchanged for release 5.3)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.six-group.com/dam/download/banking-services/standardization/sic-eurosic/5-3/ig-module-docs-sic-ip-2026-5.3-en.zip", "source_class": "authoritative_primary", "source_title": "IP Return Request Rejection (camt.029) v2.3, SIC IP module documents, release 5.3 archive", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "The IP Return Request Rejection guide lists NOAS as one of seven permitted reasons to refuse a return request, glossed by SIX as No Answer From Customer. Confirms the code is on the closed list of seven, confirms the short name SIX gives it, and confirms no public deadline is set for answering a return request." } ] }, "rail_name": "SIC IP Return Request Rejections", "governing_authority": "SIX Interbank Clearing on behalf of the Swiss National Bank", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "ch-sic-ip-return-request-rejection:NOOR", "id": "NOOR", "rail": "ch-sic-ip-return-request-rejection", "kind": "reason-code", "name": "Refused: original payment not found", "group": "administrative", "summary": "The receiving participant refuses a return request because it has no record of receiving the original payment.", "triggers": [ "The references in the camt.056 do not match any payment the receiving participant received [Inference from the code name No Original Transaction Received]" ], "actions": [ "Receiving participant: start the first additional information line with ATR053/ for a bank-initiated request, or ATR072/ for one made on behalf of the payer, followed by the reference of the request (IP-camt.029 v2.3 chapter 4.4)", "Sending participant: check the original message and transaction references it quoted, and whether the payment ever settled (EXC002) [Inference]" ], "retry": { "allowed": false, "rule": "A rejection closes the request inside SIC IP; the public guidelines give no appeal or second round [Unverified]. Recovery, if any, happens outside the SIC IP process [Inference]." }, "facts": { "return_windows": [ { "action": "refuse an IP return request with an IP return request rejection (camt.029, status RJCR) carrying this reason", "by": "The participant that received the original IP customer payment and the return request", "deadline": "No public deadline is published. The receiving participant must either return the funds or refuse (IP-pacs.028 v2.3 section 3.1.2), but no public text says how fast; any limit would be in the participant-only SIC Handbook." } ], "applies_to": "SIC IP service: the IP return request rejection (camt.029, status RJCR) that the participant which received an IP customer payment sends, through the service, to refuse a return request (camt.056). The service checks the reason against a closed list of seven." }, "caveat": "The SIC IP service does not check that the payment in a return request went through SIC IP, so a request can reach a participant for a payment it never had (IP-camt.056 v2.3 section 3.1). The rejection list is the same whatever the request code was; SIX does not restrict which rejection reason may answer which request reason, and the service does not check that the request referred to a payment processed in SIC IP (IP-camt.029 v2.3 section 3.1).", "related": [ "ch-sic-ip-return-request-rejection:ARDT", "ch-sic-ip-return-request:DUPL", "ch-sic-ip-return-request:TECH" ], "basis": { "sources": "IP-camt.029 v2.3 (SIX Interbank Clearing, Instant Payments Implementation Guidelines, IP Return Request Rejection, 2025-02-28, valid from 2025-11-21; the same edition sits in the release 5.3 archive) sections 2 and 3.1 and chapter 4.4 elements Conf, TxCxlSts, Rsn/Cd and AddtlInf; IP-camt.056 v2.3 (2025-02-28) element Rsn/Cd; IP-pacs.028 v2.3 (2025-02-28) section 3.1.2. The code meaning rests on the short name SIX gives next to the code; the ISO External Code Set itself was not read.", "confidence": "medium" }, "currency": { "effective_since": "Since IP-camt.029 v2.0 (first production edition)", "effective_note": "The seven codes are in IP-camt.029 v2.3, in force since 2025-11-21 with SIC platform release 5.2 and carried unchanged into the release 5.3 archive for 2026-11-13. The change history from v1.0 onward changes the additional information prefixes in v2.1 (2023-03-31) but no entry touches the code list [Inference: the list dates from the first edition]. v2.0 was the first edition for production, valid from the November 2023 release. SIX plans to move all SIC IP messages to ISO 20022 2024/2025 versions in November 2027 (SIC Platform Release Notes 2026, CR2026-SIC-0002) [Speculation whether this code changes].", "source_edition": "IP-camt.029 v2.3 (2025-02-28, valid from 2025-11-21, unchanged for release 5.3)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.six-group.com/dam/download/banking-services/standardization/sic-eurosic/5-3/ig-module-docs-sic-ip-2026-5.3-en.zip", "source_class": "authoritative_primary", "source_title": "IP Return Request Rejection (camt.029) v2.3, SIC IP module documents, release 5.3 archive", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "The IP Return Request Rejection guide lists NOOR as one of seven permitted reasons to refuse a return request, glossed by SIX as No Original Transaction Received. Confirms the code is on the closed list of seven, confirms the short name SIX gives it, and confirms no public deadline is set for answering a return request." } ] }, "rail_name": "SIC IP Return Request Rejections", "governing_authority": "SIX Interbank Clearing on behalf of the Swiss National Bank", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "ch-sps-status:AC01", "id": "AC01", "rail": "ch-sps-status", "kind": "reason-code", "name": "Account number wrong or unusable", "group": "account", "summary": "The bank found an account in the order that is invalid or cannot be used, whether an IBAN or a proprietary account number. The level that carries it is not processed, so nothing was paid or collected there.", "triggers": [ "A debtor, charges or creditor account in a pain.001 that fails the bank's account checks (CT IG v2.2 sections 4.2 and 4.3)", "A QR-IBAN given as the creditor account where the guide rules one out; banks may report this as AC01, BE09 or CH16, since the guide maps all three to that element [Inference]", "In a pain.008, a debtor account the chosen Swiss direct debit procedure cannot debit (CH-DD IG v1.2 section 2.2)" ], "actions": [ "Check the account against the invoice, QR-bill or supplier master data and correct it at the source, not only in the file", "Where the debtor or charges account is named, confirm it is held at this bank and enabled for the submitting contract [Inference]", "Send only the rejected payments again, in a new message" ], "retry": { "allowed": true, "rule": "A rejected order stays rejected: RJCT is a final status (IG-SR v2.1 Annex B, Table 21). Fix the cause and send the payment again in a new message. Give that message a new Message Identification, because most Swiss banks check it for duplicates over at least 90 days (CT IG v2.2 section 3.8). The SPS set no retry limit." }, "facts": { "return_windows": [ { "action": "send this reason in a pain.002 status report on the submitted order", "by": "the submitter's Swiss financial institution", "deadline": "None applies. A status report is the bank's answer to a submitted message, not a return, so no return window exists. The SPS expect an immediate reply but set no time limit, and cut-offs and error handling belong to each bank's own offer (IG-SR v2.1 section 3.1.1; BR v3.2 section 1.4.2)." } ], "applies_to": "Swiss Payment Standards customer-to-bank status report (pain.002), on credit transfer (pain.001) and direct debit (pain.008) submissions; the error sits at the level that carries the account: B for the debtor or charges account, C for the creditor account (IG-SR v2.1 section 3.2.3)." }, "caveat": "The SPS are a voluntary market practice. A bank may answer with any ISO status reason, with NARR plus its own text, or with a proprietary code, and handles faulty orders under its own customer terms (BR v3.2 section 1.4.2; IG-SR v2.1 section 3.2.4).", "related": [ "ch-sps-status:BE09", "ch-sps-status:CH16", "ch-sps-status:RC01" ], "basis": { "sources": "SPS Implementation Guidelines Status Report (pain.002) v2.1 of 2024-02-20, SPS 2024 (IG-SR v2.1) sections 3.1.1, 3.2.3 and 3.2.4 Table 10 (payment-type shading read from the rendered page), Annex B Table 21; SPS Implementation Guidelines Credit Transfer (pain.001) v2.2 of 2025-02-24, SPS 2025 (CT IG v2.2) chapter 4, error code column of the element tables; Implementation Guidelines Swiss Direct Debits (pain.008) v1.2 of 2018-04-06 (CH-DD IG v1.2) section 2.2, error code column; SPS Business Rules v3.2, SPS 2025 (BR v3.2) section 1.4.2; IG-SR v2.2 of 2026-02-20, SPS 2026, section 3.2.4 Table 10 (unchanged).", "confidence": "high" }, "currency": { "effective_since": "2024-11-18", "effective_note": "IG-SR v2.1 (SPS 2024) applies from 2024-11-18 and is still the current pain.002 guide under SPS 2025, because SIX has published no SPS 2025 edition of it [Inference from the SIX download center, read 2026-09-18]. IG-SR v2.2 (SPS 2026, dated 2026-02-20) applies from 2026-11-14 and keeps this code in Table 10 with the same meaning and the same payment-type shading; that edition changes only tracker data and the status sequence annex. The SPS 2021 guide (v1.1.2, from 2021-11-19) also lists it and governs 2009-schema submissions until the November 2026 release. Use of the code before 2024-11-18 is not dated here [Unverified].", "source_edition": "IG-SR v2.1 (SPS 2024); IG-SR v2.2 (SPS 2026); CT IG v2.2 (SPS 2025); CH-DD IG v1.2 (2018); BR v3.2 (SPS 2025)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.six-group.com/dam/download/banking-services/standardization/sps/ig-status-report-sps2024-en.pdf", "source_class": "authoritative_primary", "source_title": "SPS Implementation Guidelines, Status Report (pain.002), SPS 2024, version 2.1, dated 2024-02-20, in force from 2024-11-18", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms AC01 is listed in Table 10 of the Status Report implementation guidelines with a meaning matching the record's summary, and Table 10 leaves it unshaded, meaning it is valid for both credit transfer and direct debit submissions. Table 10 is identical on this point in the v2.2 edition (SPS 2026, dated 2026-02-20, in force from 2026-11-14). Does not address triggers, actions or retry detail beyond the table entry." }, { "source_url": "https://www.six-group.com/dam/download/banking-services/standardization/sps/business-rules-sps-2025-en.pdf", "source_class": "authoritative_primary", "source_title": "SPS Business Rules for Payments and Cash Management, SPS 2025, version 3.2, dated 2025-02-24, in force from 2025-11-22", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms SPS Business Rules section 1.4.2 leaves cut-off times and the handling of erroneous orders and status reporting to each financial institution's own customer offering, rather than to the Swiss Payment Standards. Supports the AC01 record's return_windows claim that no SPS-wide deadline applies to sending this status reason, and supports the caveat that the SPS are a voluntary market practice. Does not itself list AC01 or its meaning." } ] }, "rail_name": "Swiss Payment Standards Status Report Reasons", "governing_authority": "SIX Interbank Clearing (Swiss Payment Standards)", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "judgement", "label": "your bank's own terms", "needs": "whose terms decide it: the bank's, the participant's or the scheme's", "detail": "A bank may answer with any ISO status reason, with NARR plus its own text, or with a proprietary code, and handles faulty orders under its own customer terms (BR v3.2 section 1.4.2; IG-SR v2.1 section 3.2.4).", "from": "caveat" } ] }, { "uid": "ch-sps-status:AG06", "id": "AG06", "rail": "ch-sps-status", "kind": "reason-code", "name": "Creditor's bank details wrong", "group": "technical", "summary": "The bank could not accept the creditor agent (the payee's bank) as given in the order. The credit transfer guide ties this code to one element only, the country in the creditor agent's address.", "triggers": [ "A missing or invalid country in the creditor agent's postal address in a pain.001 (CT IG v2.2 section 4.3)", "Other creditor agent data the bank cannot use; no SPS guide read names further elements for this code [Unverified]" ], "actions": [ "Check the payee bank's name, address and country against the payee's bank details", "Identify the payee bank by BIC or IID where the payment type allows, rather than by name and address alone [Inference]", "Send the rejected transactions again in a new message" ], "retry": { "allowed": true, "rule": "A rejected order stays rejected: RJCT is a final status (IG-SR v2.1 Annex B, Table 21). Fix the cause and send the payment again in a new message. Give that message a new Message Identification, because most Swiss banks check it for duplicates over at least 90 days (CT IG v2.2 section 3.8). The SPS set no retry limit." }, "facts": { "return_windows": [ { "action": "send this reason in a pain.002 status report on the submitted order", "by": "the submitter's Swiss financial institution", "deadline": "None applies. A status report is the bank's answer to a submitted message, not a return, so no return window exists. The SPS expect an immediate reply but set no time limit, and cut-offs and error handling belong to each bank's own offer (IG-SR v2.1 section 3.1.1; BR v3.2 section 1.4.2)." } ], "applies_to": "Swiss Payment Standards customer-to-bank status report (pain.002), on credit transfer (pain.001) and direct debit (pain.008) submissions; C level in a pain.001." }, "caveat": "Which creditor agent errors a bank reports as AG06 rather than AGNT or RC01 is only partly stated in the guides. The SPS are a voluntary market practice. A bank may answer with any ISO status reason, with NARR plus its own text, or with a proprietary code, and handles faulty orders under its own customer terms (BR v3.2 section 1.4.2; IG-SR v2.1 section 3.2.4).", "related": [ "ch-sps-status:AGNT", "ch-sps-status:RC01", "ch-sps-status:BE09" ], "basis": { "sources": "SPS Implementation Guidelines Status Report (pain.002) v2.1 of 2024-02-20, SPS 2024 (IG-SR v2.1) sections 3.1.1, 3.2.3 and 3.2.4 Table 10 (payment-type shading read from the rendered page), Annex B Table 21; SPS Implementation Guidelines Credit Transfer (pain.001) v2.2 of 2025-02-24, SPS 2025 (CT IG v2.2) chapter 4, error code column of the element tables; SPS Business Rules v3.2, SPS 2025 (BR v3.2) section 1.4.2; IG-SR v2.2 of 2026-02-20, SPS 2026, section 3.2.4 Table 10 (unchanged).", "confidence": "medium" }, "currency": { "effective_since": "2024-11-18", "effective_note": "IG-SR v2.1 (SPS 2024) applies from 2024-11-18 and is still the current pain.002 guide under SPS 2025, because SIX has published no SPS 2025 edition of it [Inference from the SIX download center, read 2026-09-18]. IG-SR v2.2 (SPS 2026, dated 2026-02-20) applies from 2026-11-14 and keeps this code in Table 10 with the same meaning and the same payment-type shading; that edition changes only tracker data and the status sequence annex. The SPS 2021 guide (v1.1.2, from 2021-11-19) also lists it and governs 2009-schema submissions until the November 2026 release. Use of the code before 2024-11-18 is not dated here [Unverified].", "source_edition": "IG-SR v2.1 (SPS 2024); IG-SR v2.2 (SPS 2026); CT IG v2.2 (SPS 2025); BR v3.2 (SPS 2025)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.six-group.com/dam/download/banking-services/standardization/sps/ig-status-report-sps2024-en.pdf", "source_class": "authoritative_primary", "source_title": "SPS Implementation Guidelines, Status Report (pain.002), SPS 2024, version 2.1, dated 2024-02-20, in force from 2024-11-18", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms AG06 is listed in Table 10 of the Status Report implementation guidelines with a meaning matching the record's summary, and Table 10 leaves it unshaded, meaning it is valid for both credit transfer and direct debit submissions. Table 10 is identical on this point in the v2.2 edition (SPS 2026, dated 2026-02-20, in force from 2026-11-14). Does not address triggers, actions or retry detail beyond the table entry." }, { "source_url": "https://www.six-group.com/dam/download/banking-services/standardization/sps/business-rules-sps-2025-en.pdf", "source_class": "authoritative_primary", "source_title": "SPS Business Rules for Payments and Cash Management, SPS 2025, version 3.2, dated 2025-02-24, in force from 2025-11-22", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms SPS Business Rules section 1.4.2 leaves cut-off times and the handling of erroneous orders and status reporting to each financial institution's own customer offering, rather than to the Swiss Payment Standards. Supports the AG06 record's return_windows claim that no SPS-wide deadline applies to sending this status reason, and supports the caveat that the SPS are a voluntary market practice. Does not itself list AG06 or its meaning." } ] }, "rail_name": "Swiss Payment Standards Status Report Reasons", "governing_authority": "SIX Interbank Clearing (Swiss Payment Standards)", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "judgement", "label": "your bank's own terms", "needs": "whose terms decide it: the bank's, the participant's or the scheme's", "detail": "A bank may answer with any ISO status reason, with NARR plus its own text, or with a proprietary code, and handles faulty orders under its own customer terms (BR v3.2 section 1.4.2; IG-SR v2.1 section 3.2.4).", "from": "caveat" } ] }, { "uid": "ch-sps-status:AGNT", "id": "AGNT", "rail": "ch-sps-status", "kind": "reason-code", "name": "Agent identification wrong (credit transfers)", "group": "technical", "summary": "A bank named in a credit transfer order, the debtor's or the payee's, is identified in a way the bank refuses. Table 10 limits this code to credit transfers.", "triggers": [ "A debtor agent BIC or IID that is wrong, or given together with the other identifier when only one may be used (CT IG v2.2 section 4.2)", "A creditor agent BIC that does not suit the payment type, for example a bank without a SIC connection for a domestic type D payment (CT IG v2.2 section 4.3)" ], "actions": [ "Give each agent one identifier, BIC or IID, as the payment type requires", "For payments to a Swiss or Liechtenstein IBAN, the bank takes the payee's bank from the IBAN (CT IG v2.2 section 4.3), so remove creditor agent data that contradicts it", "Send the rejected payments again in a new message" ], "retry": { "allowed": true, "rule": "A rejected order stays rejected: RJCT is a final status (IG-SR v2.1 Annex B, Table 21). Fix the cause and send the payment again in a new message. Give that message a new Message Identification, because most Swiss banks check it for duplicates over at least 90 days (CT IG v2.2 section 3.8). The SPS set no retry limit." }, "facts": { "return_windows": [ { "action": "send this reason in a pain.002 status report on the submitted order", "by": "the submitter's Swiss financial institution", "deadline": "None applies. A status report is the bank's answer to a submitted message, not a return, so no return window exists. The SPS expect an immediate reply but set no time limit, and cut-offs and error handling belong to each bank's own offer (IG-SR v2.1 section 3.1.1; BR v3.2 section 1.4.2)." } ], "applies_to": "Swiss Payment Standards customer-to-bank status report (pain.002), on credit transfer (pain.001) submissions only; Table 10 shades it light blue; B level for the debtor agent, C level for the creditor agent." }, "caveat": "The SPS are a voluntary market practice. A bank may answer with any ISO status reason, with NARR plus its own text, or with a proprietary code, and handles faulty orders under its own customer terms (BR v3.2 section 1.4.2; IG-SR v2.1 section 3.2.4).", "related": [ "ch-sps-status:AG06", "ch-sps-status:RC01" ], "basis": { "sources": "SPS Implementation Guidelines Status Report (pain.002) v2.1 of 2024-02-20, SPS 2024 (IG-SR v2.1) sections 3.1.1, 3.2.3 and 3.2.4 Table 10 (payment-type shading read from the rendered page), Annex B Table 21; SPS Implementation Guidelines Credit Transfer (pain.001) v2.2 of 2025-02-24, SPS 2025 (CT IG v2.2) chapter 4, error code column of the element tables; SPS Business Rules v3.2, SPS 2025 (BR v3.2) section 1.4.2; IG-SR v2.2 of 2026-02-20, SPS 2026, section 3.2.4 Table 10 (unchanged).", "confidence": "high" }, "currency": { "effective_since": "2024-11-18", "effective_note": "IG-SR v2.1 (SPS 2024) applies from 2024-11-18 and is still the current pain.002 guide under SPS 2025, because SIX has published no SPS 2025 edition of it [Inference from the SIX download center, read 2026-09-18]. IG-SR v2.2 (SPS 2026, dated 2026-02-20) applies from 2026-11-14 and keeps this code in Table 10 with the same meaning and the same payment-type shading; that edition changes only tracker data and the status sequence annex. The SPS 2021 guide (v1.1.2, from 2021-11-19) also lists it and governs 2009-schema submissions until the November 2026 release. Use of the code before 2024-11-18 is not dated here [Unverified].", "source_edition": "IG-SR v2.1 (SPS 2024); IG-SR v2.2 (SPS 2026); CT IG v2.2 (SPS 2025); BR v3.2 (SPS 2025)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.six-group.com/dam/download/banking-services/standardization/sps/ig-status-report-sps2024-en.pdf", "source_class": "authoritative_primary", "source_title": "SPS Implementation Guidelines, Status Report (pain.002), SPS 2024, version 2.1, dated 2024-02-20, in force from 2024-11-18", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms AGNT is listed in Table 10 of the Status Report implementation guidelines with a meaning matching the record's summary, and Table 10 shades it light blue, meaning it is valid for credit transfer submissions only. Table 10 is identical on this point in the v2.2 edition (SPS 2026, dated 2026-02-20, in force from 2026-11-14). Does not address triggers, actions or retry detail beyond the table entry." }, { "source_url": "https://www.six-group.com/dam/download/banking-services/standardization/sps/business-rules-sps-2025-en.pdf", "source_class": "authoritative_primary", "source_title": "SPS Business Rules for Payments and Cash Management, SPS 2025, version 3.2, dated 2025-02-24, in force from 2025-11-22", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms SPS Business Rules section 1.4.2 leaves cut-off times and the handling of erroneous orders and status reporting to each financial institution's own customer offering, rather than to the Swiss Payment Standards. Supports the AGNT record's return_windows claim that no SPS-wide deadline applies to sending this status reason, and supports the caveat that the SPS are a voluntary market practice. Does not itself list AGNT or its meaning." } ] }, "rail_name": "Swiss Payment Standards Status Report Reasons", "governing_authority": "SIX Interbank Clearing (Swiss Payment Standards)", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "judgement", "label": "your bank's own terms", "needs": "whose terms decide it: the bank's, the participant's or the scheme's", "detail": "A bank may answer with any ISO status reason, with NARR plus its own text, or with a proprietary code, and handles faulty orders under its own customer terms (BR v3.2 section 1.4.2; IG-SR v2.1 section 3.2.4).", "from": "caveat" } ] }, { "uid": "ch-sps-status:AM01", "id": "AM01", "rail": "ch-sps-status", "kind": "reason-code", "name": "Zero-value transaction", "group": "technical", "summary": "A transaction carries an amount of zero. Every payment type in the credit transfer guide starts at 0.01, so the transaction is rejected.", "triggers": [ "An instructed or equivalent amount of 0.00 in a pain.001 (CT IG v2.2 section 4.3)", "A payment run that nets a credit note against an invoice to nothing but still writes a line [Inference]" ], "actions": [ "Find why the source system produced a zero line and remove it", "If something is still owed, pay it as a new transaction with the right amount" ], "retry": { "allowed": true, "rule": "Only with a real, non-zero amount. A rejected order stays rejected: RJCT is a final status (IG-SR v2.1 Annex B, Table 21). Fix the cause and send the payment again in a new message. Give that message a new Message Identification, because most Swiss banks check it for duplicates over at least 90 days (CT IG v2.2 section 3.8). The SPS set no retry limit." }, "facts": { "return_windows": [ { "action": "send this reason in a pain.002 status report on the submitted order", "by": "the submitter's Swiss financial institution", "deadline": "None applies. A status report is the bank's answer to a submitted message, not a return, so no return window exists. The SPS expect an immediate reply but set no time limit, and cut-offs and error handling belong to each bank's own offer (IG-SR v2.1 section 3.1.1; BR v3.2 section 1.4.2)." } ], "applies_to": "Swiss Payment Standards customer-to-bank status report (pain.002), on credit transfer (pain.001) and direct debit (pain.008) submissions; C level." }, "caveat": "The SPS are a voluntary market practice. A bank may answer with any ISO status reason, with NARR plus its own text, or with a proprietary code, and handles faulty orders under its own customer terms (BR v3.2 section 1.4.2; IG-SR v2.1 section 3.2.4).", "related": [ "ch-sps-status:AM02", "ch-sps-status:AM03", "ch-sps-status:CH20" ], "basis": { "sources": "SPS Implementation Guidelines Status Report (pain.002) v2.1 of 2024-02-20, SPS 2024 (IG-SR v2.1) sections 3.1.1, 3.2.3 and 3.2.4 Table 10 (payment-type shading read from the rendered page), Annex B Table 21; SPS Implementation Guidelines Credit Transfer (pain.001) v2.2 of 2025-02-24, SPS 2025 (CT IG v2.2) chapter 4, error code column of the element tables; SPS Business Rules v3.2, SPS 2025 (BR v3.2) section 1.4.2; IG-SR v2.2 of 2026-02-20, SPS 2026, section 3.2.4 Table 10 (unchanged).", "confidence": "high" }, "currency": { "effective_since": "2024-11-18", "effective_note": "IG-SR v2.1 (SPS 2024) applies from 2024-11-18 and is still the current pain.002 guide under SPS 2025, because SIX has published no SPS 2025 edition of it [Inference from the SIX download center, read 2026-09-18]. IG-SR v2.2 (SPS 2026, dated 2026-02-20) applies from 2026-11-14 and keeps this code in Table 10 with the same meaning and the same payment-type shading; that edition changes only tracker data and the status sequence annex. The SPS 2021 guide (v1.1.2, from 2021-11-19) also lists it and governs 2009-schema submissions until the November 2026 release. Use of the code before 2024-11-18 is not dated here [Unverified].", "source_edition": "IG-SR v2.1 (SPS 2024); IG-SR v2.2 (SPS 2026); CT IG v2.2 (SPS 2025); BR v3.2 (SPS 2025)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.six-group.com/dam/download/banking-services/standardization/sps/ig-status-report-sps2024-en.pdf", "source_class": "authoritative_primary", "source_title": "SPS Implementation Guidelines, Status Report (pain.002), SPS 2024, version 2.1, dated 2024-02-20, in force from 2024-11-18", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms AM01 is listed in Table 10 of the Status Report implementation guidelines with a meaning matching the record's summary, and Table 10 leaves it unshaded, meaning it is valid for both credit transfer and direct debit submissions. Table 10 is identical on this point in the v2.2 edition (SPS 2026, dated 2026-02-20, in force from 2026-11-14). Does not address triggers, actions or retry detail beyond the table entry." }, { "source_url": "https://www.six-group.com/dam/download/banking-services/standardization/sps/business-rules-sps-2025-en.pdf", "source_class": "authoritative_primary", "source_title": "SPS Business Rules for Payments and Cash Management, SPS 2025, version 3.2, dated 2025-02-24, in force from 2025-11-22", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms SPS Business Rules section 1.4.2 leaves cut-off times and the handling of erroneous orders and status reporting to each financial institution's own customer offering, rather than to the Swiss Payment Standards. Supports the AM01 record's return_windows claim that no SPS-wide deadline applies to sending this status reason, and supports the caveat that the SPS are a voluntary market practice. Does not itself list AM01 or its meaning." } ] }, "rail_name": "Swiss Payment Standards Status Report Reasons", "governing_authority": "SIX Interbank Clearing (Swiss Payment Standards)", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "judgement", "label": "your bank's own terms", "needs": "whose terms decide it: the bank's, the participant's or the scheme's", "detail": "A bank may answer with any ISO status reason, with NARR plus its own text, or with a proprietary code, and handles faulty orders under its own customer terms (BR v3.2 section 1.4.2; IG-SR v2.1 section 3.2.4).", "from": "caveat" } ] }, { "uid": "ch-sps-status:AM02", "id": "AM02", "rail": "ch-sps-status", "kind": "reason-code", "name": "Amount outside the allowed range", "group": "technical", "summary": "The amount is above what the payment type allows. For an instant payment, the ceiling is the instant payment limit.", "triggers": [ "An amount above the ceiling the credit transfer guide sets for the payment type, for example 999,999,999.99 for SEPA (CT IG v2.2 section 4.3)", "An instant payment (payment type D V2) above the instant payment limit (CT IG v2.2 section 4.3)", "An amount the bank's own limits refuse [Inference]" ], "actions": [ "Check the ceiling for the payment type and the instant limit the bank applies", "Send an over-limit instant payment as an ordinary payment instead; a bank may offer to do this itself (BR v3.2 section 2.1.3)", "Send the corrected payment in a new message" ], "retry": { "allowed": true, "rule": "A rejected order stays rejected: RJCT is a final status (IG-SR v2.1 Annex B, Table 21). Fix the cause and send the payment again in a new message. Give that message a new Message Identification, because most Swiss banks check it for duplicates over at least 90 days (CT IG v2.2 section 3.8). The SPS set no retry limit." }, "facts": { "return_windows": [ { "action": "send this reason in a pain.002 status report on the submitted order", "by": "the submitter's Swiss financial institution", "deadline": "None applies. A status report is the bank's answer to a submitted message, not a return, so no return window exists. The SPS expect an immediate reply but set no time limit, and cut-offs and error handling belong to each bank's own offer (IG-SR v2.1 section 3.1.1; BR v3.2 section 1.4.2)." } ], "applies_to": "Swiss Payment Standards customer-to-bank status report (pain.002), on credit transfer (pain.001) and direct debit (pain.008) submissions; C level." }, "caveat": "A bank can offer to carry out an order it rejected as an instant payment as an ordinary payment, marked with local instrument ITP and reported with status ACWC (BR v3.2 section 2.1.3). That is an optional offer, not a rule. The SPS are a voluntary market practice. A bank may answer with any ISO status reason, with NARR plus its own text, or with a proprietary code, and handles faulty orders under its own customer terms (BR v3.2 section 1.4.2; IG-SR v2.1 section 3.2.4).", "related": [ "ch-sps-status:AM01", "ch-sps-status:AM03", "ch-sps-status:CH20" ], "basis": { "sources": "SPS Implementation Guidelines Status Report (pain.002) v2.1 of 2024-02-20, SPS 2024 (IG-SR v2.1) sections 3.1.1, 3.2.3 and 3.2.4 Table 10 (payment-type shading read from the rendered page), Annex B Table 21; SPS Implementation Guidelines Credit Transfer (pain.001) v2.2 of 2025-02-24, SPS 2025 (CT IG v2.2) chapter 4, error code column of the element tables; SPS Business Rules v3.2, SPS 2025 (BR v3.2) section 2.1.3 and section 1.4.2; IG-SR v2.2 of 2026-02-20, SPS 2026, section 3.2.4 Table 10 (unchanged).", "confidence": "high" }, "currency": { "effective_since": "2024-11-18", "effective_note": "IG-SR v2.1 (SPS 2024) applies from 2024-11-18 and is still the current pain.002 guide under SPS 2025, because SIX has published no SPS 2025 edition of it [Inference from the SIX download center, read 2026-09-18]. IG-SR v2.2 (SPS 2026, dated 2026-02-20) applies from 2026-11-14 and keeps this code in Table 10 with the same meaning and the same payment-type shading; that edition changes only tracker data and the status sequence annex. The SPS 2021 guide (v1.1.2, from 2021-11-19) also lists it and governs 2009-schema submissions until the November 2026 release. Use of the code before 2024-11-18 is not dated here [Unverified].", "source_edition": "IG-SR v2.1 (SPS 2024); IG-SR v2.2 (SPS 2026); CT IG v2.2 (SPS 2025); BR v3.2 (SPS 2025)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.six-group.com/dam/download/banking-services/standardization/sps/ig-status-report-sps2024-en.pdf", "source_class": "authoritative_primary", "source_title": "SPS Implementation Guidelines, Status Report (pain.002), SPS 2024, version 2.1, dated 2024-02-20, in force from 2024-11-18", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms AM02 is listed in Table 10 of the Status Report implementation guidelines with a meaning matching the record's summary, and Table 10 leaves it unshaded, meaning it is valid for both credit transfer and direct debit submissions. Table 10 is identical on this point in the v2.2 edition (SPS 2026, dated 2026-02-20, in force from 2026-11-14). Does not address triggers, actions or retry detail beyond the table entry." }, { "source_url": "https://www.six-group.com/dam/download/banking-services/standardization/sps/business-rules-sps-2025-en.pdf", "source_class": "authoritative_primary", "source_title": "SPS Business Rules for Payments and Cash Management, SPS 2025, version 3.2, dated 2025-02-24, in force from 2025-11-22", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms SPS Business Rules section 1.4.2 leaves cut-off times and the handling of erroneous orders and status reporting to each financial institution's own customer offering, rather than to the Swiss Payment Standards. Supports the AM02 record's return_windows claim that no SPS-wide deadline applies to sending this status reason, and supports the caveat that the SPS are a voluntary market practice. Does not itself list AM02 or its meaning." } ] }, "rail_name": "Swiss Payment Standards Status Report Reasons", "governing_authority": "SIX Interbank Clearing (Swiss Payment Standards)", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "judgement", "label": "your bank's own terms", "needs": "whose terms decide it: the bank's, the participant's or the scheme's", "detail": "A bank may answer with any ISO status reason, with NARR plus its own text, or with a proprietary code, and handles faulty orders under its own customer terms (BR v3.2 section 1.4.2; IG-SR v2.1 section 3.2.4).", "from": "caveat" } ] }, { "uid": "ch-sps-status:AM03", "id": "AM03", "rail": "ch-sps-status", "kind": "reason-code", "name": "Currency not allowed", "group": "technical", "summary": "The currency of the amount is not a valid code or not allowed for the payment type chosen. The transaction is rejected.", "triggers": [ "A currency the payment type excludes, such as a non-EUR SEPA payment or a non-CHF instant payment (CT IG v2.2 section 4.3; BR v3.2 section 2.1.3)", "A currency code that does not exist; the SIX example of a C-level reject for currency XXX uses AM03 (IG-SR v2.1 Annex C, example 3)", "A currency the bank does not offer for that payment type [Inference]" ], "actions": [ "Check the currency against the payment type rules and the bank's currency offer", "Correct the currency or choose a payment type that allows it, then send the payment again in a new message" ], "retry": { "allowed": true, "rule": "A rejected order stays rejected: RJCT is a final status (IG-SR v2.1 Annex B, Table 21). Fix the cause and send the payment again in a new message. Give that message a new Message Identification, because most Swiss banks check it for duplicates over at least 90 days (CT IG v2.2 section 3.8). The SPS set no retry limit." }, "facts": { "return_windows": [ { "action": "send this reason in a pain.002 status report on the submitted order", "by": "the submitter's Swiss financial institution", "deadline": "None applies. A status report is the bank's answer to a submitted message, not a return, so no return window exists. The SPS expect an immediate reply but set no time limit, and cut-offs and error handling belong to each bank's own offer (IG-SR v2.1 section 3.1.1; BR v3.2 section 1.4.2)." } ], "applies_to": "Swiss Payment Standards customer-to-bank status report (pain.002), on credit transfer (pain.001) and direct debit (pain.008) submissions; C level." }, "caveat": "The credit transfer guide maps both AM03 and CURR to the amount's currency, so banks may differ in which one they send [Inference]. The SPS are a voluntary market practice. A bank may answer with any ISO status reason, with NARR plus its own text, or with a proprietary code, and handles faulty orders under its own customer terms (BR v3.2 section 1.4.2; IG-SR v2.1 section 3.2.4).", "related": [ "ch-sps-status:CURR", "ch-sps-status:AM02", "ch-sps-status:CH20" ], "basis": { "sources": "SPS Implementation Guidelines Status Report (pain.002) v2.1 of 2024-02-20, SPS 2024 (IG-SR v2.1) sections 3.1.1, 3.2.3 and 3.2.4 Table 10 (payment-type shading read from the rendered page), Annex B Table 21; SPS Implementation Guidelines Credit Transfer (pain.001) v2.2 of 2025-02-24, SPS 2025 (CT IG v2.2) chapter 4, error code column of the element tables; IG-SR v2.1 Annex C example 3; SPS Business Rules v3.2, SPS 2025 (BR v3.2) section 2.1.3 and section 1.4.2; IG-SR v2.2 of 2026-02-20, SPS 2026, section 3.2.4 Table 10 (unchanged).", "confidence": "high" }, "currency": { "effective_since": "2024-11-18", "effective_note": "IG-SR v2.1 (SPS 2024) applies from 2024-11-18 and is still the current pain.002 guide under SPS 2025, because SIX has published no SPS 2025 edition of it [Inference from the SIX download center, read 2026-09-18]. IG-SR v2.2 (SPS 2026, dated 2026-02-20) applies from 2026-11-14 and keeps this code in Table 10 with the same meaning and the same payment-type shading; that edition changes only tracker data and the status sequence annex. The SPS 2021 guide (v1.1.2, from 2021-11-19) also lists it and governs 2009-schema submissions until the November 2026 release. Use of the code before 2024-11-18 is not dated here [Unverified].", "source_edition": "IG-SR v2.1 (SPS 2024); IG-SR v2.2 (SPS 2026); CT IG v2.2 (SPS 2025); BR v3.2 (SPS 2025)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.six-group.com/dam/download/banking-services/standardization/sps/ig-status-report-sps2024-en.pdf", "source_class": "authoritative_primary", "source_title": "SPS Implementation Guidelines, Status Report (pain.002), SPS 2024, version 2.1, dated 2024-02-20, in force from 2024-11-18", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms AM03 is listed in Table 10 of the Status Report implementation guidelines with a meaning matching the record's summary, and Table 10 leaves it unshaded, meaning it is valid for both credit transfer and direct debit submissions. Table 10 is identical on this point in the v2.2 edition (SPS 2026, dated 2026-02-20, in force from 2026-11-14). Does not address triggers, actions or retry detail beyond the table entry." }, { "source_url": "https://www.six-group.com/dam/download/banking-services/standardization/sps/business-rules-sps-2025-en.pdf", "source_class": "authoritative_primary", "source_title": "SPS Business Rules for Payments and Cash Management, SPS 2025, version 3.2, dated 2025-02-24, in force from 2025-11-22", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms SPS Business Rules section 1.4.2 leaves cut-off times and the handling of erroneous orders and status reporting to each financial institution's own customer offering, rather than to the Swiss Payment Standards. Supports the AM03 record's return_windows claim that no SPS-wide deadline applies to sending this status reason, and supports the caveat that the SPS are a voluntary market practice. Does not itself list AM03 or its meaning." } ] }, "rail_name": "Swiss Payment Standards Status Report Reasons", "governing_authority": "SIX Interbank Clearing (Swiss Payment Standards)", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "judgement", "label": "your bank's own terms", "needs": "whose terms decide it: the bank's, the participant's or the scheme's", "detail": "A bank may answer with any ISO status reason, with NARR plus its own text, or with a proprietary code, and handles faulty orders under its own customer terms (BR v3.2 section 1.4.2; IG-SR v2.1 section 3.2.4).", "from": "caveat" } ] }, { "uid": "ch-sps-status:AM10", "id": "AM10", "rail": "ch-sps-status", "kind": "reason-code", "name": "Control sum does not add up", "group": "technical", "summary": "The control sum in the group header differs from the total of the amounts in the message. The bank rejects the whole message, so none of its payments were processed.", "triggers": [ "A group header control sum that differs from the sum of all instructed or equivalent amounts (CT IG v2.2 section 4.1)", "A file edited by hand after it was generated, or a generator that totals the run before lines are added or dropped [Inference]" ], "actions": [ "Regenerate the file from the payment run rather than editing it", "Check how the payment software computes the control sum", "Send the whole message again with a new Message Identification, since every payment in it was stopped" ], "retry": { "allowed": true, "rule": "A rejected order stays rejected: RJCT is a final status (IG-SR v2.1 Annex B, Table 21). Fix the cause and send the payment again in a new message. Give that message a new Message Identification, because most Swiss banks check it for duplicates over at least 90 days (CT IG v2.2 section 3.8). The SPS set no retry limit." }, "facts": { "return_windows": [ { "action": "send this reason in a pain.002 status report on the submitted order", "by": "the submitter's Swiss financial institution", "deadline": "None applies. A status report is the bank's answer to a submitted message, not a return, so no return window exists. The SPS expect an immediate reply but set no time limit, and cut-offs and error handling belong to each bank's own offer (IG-SR v2.1 section 3.1.1; BR v3.2 section 1.4.2)." } ], "applies_to": "Swiss Payment Standards customer-to-bank status report (pain.002), on credit transfer (pain.001) and direct debit (pain.008) submissions; A level: the whole message is rejected." }, "caveat": "The SPS are a voluntary market practice. A bank may answer with any ISO status reason, with NARR plus its own text, or with a proprietary code, and handles faulty orders under its own customer terms (BR v3.2 section 1.4.2; IG-SR v2.1 section 3.2.4).", "related": [ "ch-sps-status:AM18", "ch-sps-status:FF01", "ch-sps-status:DU01" ], "basis": { "sources": "SPS Implementation Guidelines Status Report (pain.002) v2.1 of 2024-02-20, SPS 2024 (IG-SR v2.1) sections 3.1.1, 3.2.3 and 3.2.4 Table 10 (payment-type shading read from the rendered page), Annex B Table 21; SPS Implementation Guidelines Credit Transfer (pain.001) v2.2 of 2025-02-24, SPS 2025 (CT IG v2.2) chapter 4, error code column of the element tables; SPS Implementation Guidelines SEPA Direct Debit (pain.008) v2.7, SPS 2021 (SDD IG v2.7) section 2.2, error code column; Implementation Guidelines Swiss Direct Debits (pain.008) v1.2 of 2018-04-06 (CH-DD IG v1.2) section 2.2, error code column; IG-SR v2.1 section 3.2.3; SPS Business Rules v3.2, SPS 2025 (BR v3.2) section 1.4.2; IG-SR v2.2 of 2026-02-20, SPS 2026, section 3.2.4 Table 10 (unchanged).", "confidence": "high" }, "currency": { "effective_since": "2024-11-18", "effective_note": "IG-SR v2.1 (SPS 2024) applies from 2024-11-18 and is still the current pain.002 guide under SPS 2025, because SIX has published no SPS 2025 edition of it [Inference from the SIX download center, read 2026-09-18]. IG-SR v2.2 (SPS 2026, dated 2026-02-20) applies from 2026-11-14 and keeps this code in Table 10 with the same meaning and the same payment-type shading; that edition changes only tracker data and the status sequence annex. The SPS 2021 guide (v1.1.2, from 2021-11-19) also lists it and governs 2009-schema submissions until the November 2026 release. Use of the code before 2024-11-18 is not dated here [Unverified].", "source_edition": "IG-SR v2.1 (SPS 2024); IG-SR v2.2 (SPS 2026); CT IG v2.2 (SPS 2025); SDD IG v2.7 (SPS 2021); CH-DD IG v1.2 (2018); BR v3.2 (SPS 2025)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.six-group.com/dam/download/banking-services/standardization/sps/ig-status-report-sps2024-en.pdf", "source_class": "authoritative_primary", "source_title": "SPS Implementation Guidelines, Status Report (pain.002), SPS 2024, version 2.1, dated 2024-02-20, in force from 2024-11-18", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms AM10 is listed in Table 10 of the Status Report implementation guidelines with a meaning matching the record's summary, and Table 10 leaves it unshaded, meaning it is valid for both credit transfer and direct debit submissions. Table 10 is identical on this point in the v2.2 edition (SPS 2026, dated 2026-02-20, in force from 2026-11-14). Does not address triggers, actions or retry detail beyond the table entry." }, { "source_url": "https://www.six-group.com/dam/download/banking-services/standardization/sps/business-rules-sps-2025-en.pdf", "source_class": "authoritative_primary", "source_title": "SPS Business Rules for Payments and Cash Management, SPS 2025, version 3.2, dated 2025-02-24, in force from 2025-11-22", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms SPS Business Rules section 1.4.2 leaves cut-off times and the handling of erroneous orders and status reporting to each financial institution's own customer offering, rather than to the Swiss Payment Standards. Supports the AM10 record's return_windows claim that no SPS-wide deadline applies to sending this status reason, and supports the caveat that the SPS are a voluntary market practice. Does not itself list AM10 or its meaning." } ] }, "rail_name": "Swiss Payment Standards Status Report Reasons", "governing_authority": "SIX Interbank Clearing (Swiss Payment Standards)", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "judgement", "label": "your bank's own terms", "needs": "whose terms decide it: the bank's, the participant's or the scheme's", "detail": "A bank may answer with any ISO status reason, with NARR plus its own text, or with a proprietary code, and handles faulty orders under its own customer terms (BR v3.2 section 1.4.2; IG-SR v2.1 section 3.2.4).", "from": "caveat" } ] }, { "uid": "ch-sps-status:AM18", "id": "AM18", "rail": "ch-sps-status", "kind": "reason-code", "name": "Transaction count does not match", "group": "technical", "summary": "The number of transactions stated in the group header does not match the transactions actually in the message. The whole message is rejected.", "triggers": [ "A group header transaction count that differs from the number of C-level transactions (CT IG v2.2 section 4.1)", "A message above 99,999 transactions, or above a smaller size the bank sets; the guide says such messages are rejected and lists AM18 for that element, but does not say this case uses it [Inference]" ], "actions": [ "Regenerate the file rather than editing it", "Split very large payment runs into several messages within the bank's size limit", "Send the whole message again with a new Message Identification" ], "retry": { "allowed": true, "rule": "A rejected order stays rejected: RJCT is a final status (IG-SR v2.1 Annex B, Table 21). Fix the cause and send the payment again in a new message. Give that message a new Message Identification, because most Swiss banks check it for duplicates over at least 90 days (CT IG v2.2 section 3.8). The SPS set no retry limit." }, "facts": { "return_windows": [ { "action": "send this reason in a pain.002 status report on the submitted order", "by": "the submitter's Swiss financial institution", "deadline": "None applies. A status report is the bank's answer to a submitted message, not a return, so no return window exists. The SPS expect an immediate reply but set no time limit, and cut-offs and error handling belong to each bank's own offer (IG-SR v2.1 section 3.1.1; BR v3.2 section 1.4.2)." } ], "applies_to": "Swiss Payment Standards customer-to-bank status report (pain.002), on credit transfer (pain.001) and direct debit (pain.008) submissions; A level: the whole message is rejected." }, "caveat": "The SPS are a voluntary market practice. A bank may answer with any ISO status reason, with NARR plus its own text, or with a proprietary code, and handles faulty orders under its own customer terms (BR v3.2 section 1.4.2; IG-SR v2.1 section 3.2.4).", "related": [ "ch-sps-status:AM10", "ch-sps-status:FF01" ], "basis": { "sources": "SPS Implementation Guidelines Status Report (pain.002) v2.1 of 2024-02-20, SPS 2024 (IG-SR v2.1) sections 3.1.1, 3.2.3 and 3.2.4 Table 10 (payment-type shading read from the rendered page), Annex B Table 21; SPS Implementation Guidelines Credit Transfer (pain.001) v2.2 of 2025-02-24, SPS 2025 (CT IG v2.2) chapter 4, error code column of the element tables; SPS Implementation Guidelines SEPA Direct Debit (pain.008) v2.7, SPS 2021 (SDD IG v2.7) section 2.2, error code column; Implementation Guidelines Swiss Direct Debits (pain.008) v1.2 of 2018-04-06 (CH-DD IG v1.2) section 2.2, error code column; IG-SR v2.1 section 3.2.3; SPS Business Rules v3.2, SPS 2025 (BR v3.2) section 1.4.2; IG-SR v2.2 of 2026-02-20, SPS 2026, section 3.2.4 Table 10 (unchanged).", "confidence": "high" }, "currency": { "effective_since": "2024-11-18", "effective_note": "IG-SR v2.1 (SPS 2024) applies from 2024-11-18 and is still the current pain.002 guide under SPS 2025, because SIX has published no SPS 2025 edition of it [Inference from the SIX download center, read 2026-09-18]. IG-SR v2.2 (SPS 2026, dated 2026-02-20) applies from 2026-11-14 and keeps this code in Table 10 with the same meaning and the same payment-type shading; that edition changes only tracker data and the status sequence annex. The SPS 2021 guide (v1.1.2, from 2021-11-19) also lists it and governs 2009-schema submissions until the November 2026 release. Use of the code before 2024-11-18 is not dated here [Unverified].", "source_edition": "IG-SR v2.1 (SPS 2024); IG-SR v2.2 (SPS 2026); CT IG v2.2 (SPS 2025); SDD IG v2.7 (SPS 2021); CH-DD IG v1.2 (2018); BR v3.2 (SPS 2025)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.six-group.com/dam/download/banking-services/standardization/sps/ig-status-report-sps2024-en.pdf", "source_class": "authoritative_primary", "source_title": "SPS Implementation Guidelines, Status Report (pain.002), SPS 2024, version 2.1, dated 2024-02-20, in force from 2024-11-18", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms AM18 is listed in Table 10 of the Status Report implementation guidelines with a meaning matching the record's summary, and Table 10 leaves it unshaded, meaning it is valid for both credit transfer and direct debit submissions. Table 10 is identical on this point in the v2.2 edition (SPS 2026, dated 2026-02-20, in force from 2026-11-14). Does not address triggers, actions or retry detail beyond the table entry." }, { "source_url": "https://www.six-group.com/dam/download/banking-services/standardization/sps/business-rules-sps-2025-en.pdf", "source_class": "authoritative_primary", "source_title": "SPS Business Rules for Payments and Cash Management, SPS 2025, version 3.2, dated 2025-02-24, in force from 2025-11-22", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms SPS Business Rules section 1.4.2 leaves cut-off times and the handling of erroneous orders and status reporting to each financial institution's own customer offering, rather than to the Swiss Payment Standards. Supports the AM18 record's return_windows claim that no SPS-wide deadline applies to sending this status reason, and supports the caveat that the SPS are a voluntary market practice. Does not itself list AM18 or its meaning." } ] }, "rail_name": "Swiss Payment Standards Status Report Reasons", "governing_authority": "SIX Interbank Clearing (Swiss Payment Standards)", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "judgement", "label": "your bank's own terms", "needs": "whose terms decide it: the bank's, the participant's or the scheme's", "detail": "A bank may answer with any ISO status reason, with NARR plus its own text, or with a proprietary code, and handles faulty orders under its own customer terms (BR v3.2 section 1.4.2; IG-SR v2.1 section 3.2.4).", "from": "caveat" } ] }, { "uid": "ch-sps-status:BE01", "id": "BE01", "rail": "ch-sps-status", "kind": "reason-code", "name": "Customer identification inconsistent (credit transfers)", "group": "account", "summary": "SIX lists this code for credit transfers only, as a customer identification that does not fit the amount given. None of the SPS guides read ties it to an element, so what a bank checks is its own choice.", "triggers": [ "A customer identification or reference that the bank finds inconsistent with the order; which element is checked is bank-specific [Unverified]", "In the ISO code set, BE01 concerns an end customer identification that does not fit the account [Unverified: the ISO list could not be read]" ], "actions": [ "Ask the bank which element it checked, because the SPS name none", "Compare party names, identifiers, references and amounts in the order with the invoice or payee data", "Send the corrected payment again in a new message" ], "retry": { "allowed": true, "rule": "A rejected order stays rejected: RJCT is a final status (IG-SR v2.1 Annex B, Table 21). Fix the cause and send the payment again in a new message. Give that message a new Message Identification, because most Swiss banks check it for duplicates over at least 90 days (CT IG v2.2 section 3.8). The SPS set no retry limit." }, "facts": { "return_windows": [ { "action": "send this reason in a pain.002 status report on the submitted order", "by": "the submitter's Swiss financial institution", "deadline": "None applies. A status report is the bank's answer to a submitted message, not a return, so no return window exists. The SPS expect an immediate reply but set no time limit, and cut-offs and error handling belong to each bank's own offer (IG-SR v2.1 section 3.1.1; BR v3.2 section 1.4.2)." } ], "applies_to": "Swiss Payment Standards customer-to-bank status report (pain.002), on credit transfer (pain.001) submissions only; Table 10 shades it light blue." }, "caveat": "The Table 10 wording ties the identification to the amount, which differs from the generic ISO meaning [Unverified]. Treat the bank's additional information text as the real reason. The SPS are a voluntary market practice. A bank may answer with any ISO status reason, with NARR plus its own text, or with a proprietary code, and handles faulty orders under its own customer terms (BR v3.2 section 1.4.2; IG-SR v2.1 section 3.2.4).", "related": [ "ch-sps-status:AC01", "ch-sps-status:MS03" ], "basis": { "sources": "SPS Implementation Guidelines Status Report (pain.002) v2.1 of 2024-02-20, SPS 2024 (IG-SR v2.1) sections 3.1.1, 3.2.3 and 3.2.4 Table 10 (payment-type shading read from the rendered page), Annex B Table 21; CT IG v2.2 read in full for this code; it does not map BE01 to any element; SPS Implementation Guidelines Credit Transfer (pain.001) v2.2 of 2025-02-24, SPS 2025 (CT IG v2.2) section 3.8; SPS Business Rules v3.2, SPS 2025 (BR v3.2) section 1.4.2; IG-SR v2.2 of 2026-02-20, SPS 2026, section 3.2.4 Table 10 (unchanged).", "confidence": "low" }, "currency": { "effective_since": "2024-11-18", "effective_note": "IG-SR v2.1 (SPS 2024) applies from 2024-11-18 and is still the current pain.002 guide under SPS 2025, because SIX has published no SPS 2025 edition of it [Inference from the SIX download center, read 2026-09-18]. IG-SR v2.2 (SPS 2026, dated 2026-02-20) applies from 2026-11-14 and keeps this code in Table 10 with the same meaning and the same payment-type shading; that edition changes only tracker data and the status sequence annex. The SPS 2021 guide (v1.1.2, from 2021-11-19) also lists it and governs 2009-schema submissions until the November 2026 release. Use of the code before 2024-11-18 is not dated here [Unverified].", "source_edition": "IG-SR v2.1 (SPS 2024); IG-SR v2.2 (SPS 2026); CT IG v2.2 (SPS 2025); BR v3.2 (SPS 2025)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.six-group.com/dam/download/banking-services/standardization/sps/ig-status-report-sps2024-en.pdf", "source_class": "authoritative_primary", "source_title": "SPS Implementation Guidelines, Status Report (pain.002), SPS 2024, version 2.1, dated 2024-02-20, in force from 2024-11-18", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms BE01 is listed in Table 10 of the Status Report implementation guidelines with a meaning matching the record's summary, and Table 10 shades it light blue, meaning it is valid for credit transfer submissions only. Table 10 is identical on this point in the v2.2 edition (SPS 2026, dated 2026-02-20, in force from 2026-11-14). Does not address triggers, actions or retry detail beyond the table entry." }, { "source_url": "https://www.six-group.com/dam/download/banking-services/standardization/sps/business-rules-sps-2025-en.pdf", "source_class": "authoritative_primary", "source_title": "SPS Business Rules for Payments and Cash Management, SPS 2025, version 3.2, dated 2025-02-24, in force from 2025-11-22", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms SPS Business Rules section 1.4.2 leaves cut-off times and the handling of erroneous orders and status reporting to each financial institution's own customer offering, rather than to the Swiss Payment Standards. Supports the BE01 record's return_windows claim that no SPS-wide deadline applies to sending this status reason, and supports the caveat that the SPS are a voluntary market practice. Does not itself list BE01 or its meaning." } ] }, "rail_name": "Swiss Payment Standards Status Report Reasons", "governing_authority": "SIX Interbank Clearing (Swiss Payment Standards)", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "judgement", "label": "your bank's own terms", "needs": "whose terms decide it: the bank's, the participant's or the scheme's", "detail": "A bank may answer with any ISO status reason, with NARR plus its own text, or with a proprietary code, and handles faulty orders under its own customer terms (BR v3.2 section 1.4.2; IG-SR v2.1 section 3.2.4).", "from": "caveat" } ] }, { "uid": "ch-sps-status:BE09", "id": "BE09", "rail": "ch-sps-status", "kind": "reason-code", "name": "Country code wrong", "group": "technical", "summary": "A country given in the order is invalid or not allowed where it is used, for example in a party's address, in an IBAN, or in regulatory reporting.", "triggers": [ "An invalid country in the creditor's or ultimate creditor's postal address (CT IG v2.2 section 4.3)", "An IBAN whose country prefix the payment type does not allow (CT IG v2.2 sections 4.2 and 4.3)", "An invalid country in regulatory reporting details (CT IG v2.2 section 4.3)", "In a pain.008, an invalid country code in an IBAN or creditor identifier (SDD IG v2.7; CH-DD IG v1.2)" ], "actions": [ "Use ISO 3166 two-letter country codes and check the party master data", "Check that the payee's IBAN country fits the payment type chosen", "Send the corrected payments again in a new message" ], "retry": { "allowed": true, "rule": "A rejected order stays rejected: RJCT is a final status (IG-SR v2.1 Annex B, Table 21). Fix the cause and send the payment again in a new message. Give that message a new Message Identification, because most Swiss banks check it for duplicates over at least 90 days (CT IG v2.2 section 3.8). The SPS set no retry limit." }, "facts": { "return_windows": [ { "action": "send this reason in a pain.002 status report on the submitted order", "by": "the submitter's Swiss financial institution", "deadline": "None applies. A status report is the bank's answer to a submitted message, not a return, so no return window exists. The SPS expect an immediate reply but set no time limit, and cut-offs and error handling belong to each bank's own offer (IG-SR v2.1 section 3.1.1; BR v3.2 section 1.4.2)." } ], "applies_to": "Swiss Payment Standards customer-to-bank status report (pain.002), on credit transfer (pain.001) and direct debit (pain.008) submissions." }, "caveat": "BE09 and BE11 both concern countries; the SPS do not say when a bank uses one rather than the other. The SPS are a voluntary market practice. A bank may answer with any ISO status reason, with NARR plus its own text, or with a proprietary code, and handles faulty orders under its own customer terms (BR v3.2 section 1.4.2; IG-SR v2.1 section 3.2.4).", "related": [ "ch-sps-status:BE11", "ch-sps-status:AC01", "ch-sps-status:RR05" ], "basis": { "sources": "SPS Implementation Guidelines Status Report (pain.002) v2.1 of 2024-02-20, SPS 2024 (IG-SR v2.1) sections 3.1.1, 3.2.3 and 3.2.4 Table 10 (payment-type shading read from the rendered page), Annex B Table 21; SPS Implementation Guidelines Credit Transfer (pain.001) v2.2 of 2025-02-24, SPS 2025 (CT IG v2.2) chapter 4, error code column of the element tables; SPS Implementation Guidelines SEPA Direct Debit (pain.008) v2.7, SPS 2021 (SDD IG v2.7) section 2.2, error code column; Implementation Guidelines Swiss Direct Debits (pain.008) v1.2 of 2018-04-06 (CH-DD IG v1.2) section 2.2, error code column; SPS Business Rules v3.2, SPS 2025 (BR v3.2) section 1.4.2; IG-SR v2.2 of 2026-02-20, SPS 2026, section 3.2.4 Table 10 (unchanged).", "confidence": "high" }, "currency": { "effective_since": "2024-11-18", "effective_note": "IG-SR v2.1 (SPS 2024) applies from 2024-11-18 and is still the current pain.002 guide under SPS 2025, because SIX has published no SPS 2025 edition of it [Inference from the SIX download center, read 2026-09-18]. IG-SR v2.2 (SPS 2026, dated 2026-02-20) applies from 2026-11-14 and keeps this code in Table 10 with the same meaning and the same payment-type shading; that edition changes only tracker data and the status sequence annex. The SPS 2021 guide (v1.1.2, from 2021-11-19) also lists it and governs 2009-schema submissions until the November 2026 release. Use of the code before 2024-11-18 is not dated here [Unverified].", "source_edition": "IG-SR v2.1 (SPS 2024); IG-SR v2.2 (SPS 2026); CT IG v2.2 (SPS 2025); SDD IG v2.7 (SPS 2021); CH-DD IG v1.2 (2018); BR v3.2 (SPS 2025)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.six-group.com/dam/download/banking-services/standardization/sps/ig-status-report-sps2024-en.pdf", "source_class": "authoritative_primary", "source_title": "SPS Implementation Guidelines, Status Report (pain.002), SPS 2024, version 2.1, dated 2024-02-20, in force from 2024-11-18", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms BE09 is listed in Table 10 of the Status Report implementation guidelines with a meaning matching the record's summary, and Table 10 leaves it unshaded, meaning it is valid for both credit transfer and direct debit submissions. Table 10 is identical on this point in the v2.2 edition (SPS 2026, dated 2026-02-20, in force from 2026-11-14). Does not address triggers, actions or retry detail beyond the table entry." }, { "source_url": "https://www.six-group.com/dam/download/banking-services/standardization/sps/business-rules-sps-2025-en.pdf", "source_class": "authoritative_primary", "source_title": "SPS Business Rules for Payments and Cash Management, SPS 2025, version 3.2, dated 2025-02-24, in force from 2025-11-22", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms SPS Business Rules section 1.4.2 leaves cut-off times and the handling of erroneous orders and status reporting to each financial institution's own customer offering, rather than to the Swiss Payment Standards. Supports the BE09 record's return_windows claim that no SPS-wide deadline applies to sending this status reason, and supports the caveat that the SPS are a voluntary market practice. Does not itself list BE09 or its meaning." } ] }, "rail_name": "Swiss Payment Standards Status Report Reasons", "governing_authority": "SIX Interbank Clearing (Swiss Payment Standards)", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "judgement", "label": "your bank's own terms", "needs": "whose terms decide it: the bank's, the participant's or the scheme's", "detail": "A bank may answer with any ISO status reason, with NARR plus its own text, or with a proprietary code, and handles faulty orders under its own customer terms (BR v3.2 section 1.4.2; IG-SR v2.1 section 3.2.4).", "from": "caveat" } ] }, { "uid": "ch-sps-status:BE11", "id": "BE11", "rail": "ch-sps-status", "kind": "reason-code", "name": "Country absent or not recognised", "group": "technical", "summary": "A country that should be present is missing, or its code is not valid. The code joined the Swiss list after SPS 2021, and the guides read do not tie it to a particular element.", "triggers": [ "A structured address without a country where the address rules require one [Inference: CT IG v2.2 maps missing mandatory elements to CH21 and country errors to BE09, not BE11]", "Country checks a bank runs beyond the SPS element tables [Unverified]" ], "actions": [ "Supply town and country in every structured address; since SPS 2025 both are required for the ultimate debtor as well (SPS delta document SPS 2024 to SPS 2025 v1.0 section 2.2.1)", "Read the additional information text for the element concerned", "Send the corrected payments again in a new message" ], "retry": { "allowed": true, "rule": "A rejected order stays rejected: RJCT is a final status (IG-SR v2.1 Annex B, Table 21). Fix the cause and send the payment again in a new message. Give that message a new Message Identification, because most Swiss banks check it for duplicates over at least 90 days (CT IG v2.2 section 3.8). The SPS set no retry limit." }, "facts": { "return_windows": [ { "action": "send this reason in a pain.002 status report on the submitted order", "by": "the submitter's Swiss financial institution", "deadline": "None applies. A status report is the bank's answer to a submitted message, not a return, so no return window exists. The SPS expect an immediate reply but set no time limit, and cut-offs and error handling belong to each bank's own offer (IG-SR v2.1 section 3.1.1; BR v3.2 section 1.4.2)." } ], "applies_to": "Swiss Payment Standards customer-to-bank status report (pain.002), on credit transfer (pain.001) and direct debit (pain.008) submissions." }, "caveat": "The SPS are a voluntary market practice. A bank may answer with any ISO status reason, with NARR plus its own text, or with a proprietary code, and handles faulty orders under its own customer terms (BR v3.2 section 1.4.2; IG-SR v2.1 section 3.2.4).", "related": [ "ch-sps-status:BE09", "ch-sps-status:CH21" ], "basis": { "sources": "SPS Implementation Guidelines Status Report (pain.002) v2.1 of 2024-02-20, SPS 2024 (IG-SR v2.1) sections 3.1.1, 3.2.3 and 3.2.4 Table 10 (payment-type shading read from the rendered page), Annex B Table 21; CT IG v2.2 read for this code; it does not map BE11 to any element; SPS delta document SPS 2024 to SPS 2025 v1.0 of 2025-11-22 section 2.2.1; SPS Implementation Guidelines Credit Transfer (pain.001) v2.2 of 2025-02-24, SPS 2025 (CT IG v2.2) section 3.8; SPS Business Rules v3.2, SPS 2025 (BR v3.2) section 1.4.2; IG-SR v2.2 of 2026-02-20, SPS 2026, section 3.2.4 Table 10 (unchanged).", "confidence": "medium" }, "currency": { "effective_since": "2024-11-18", "effective_note": "IG-SR v2.1 (SPS 2024) applies from 2024-11-18 and is still the current pain.002 guide under SPS 2025, because SIX has published no SPS 2025 edition of it [Inference from the SIX download center, read 2026-09-18]. IG-SR v2.2 (SPS 2026, dated 2026-02-20) applies from 2026-11-14 and keeps this code in Table 10 with the same meaning and the same payment-type shading; that edition changes only tracker data and the status sequence annex. The code is absent from the SPS 2021 guide (v1.1.2), which still governs 2009-schema submissions until the November 2026 release. Use of the code before 2024-11-18 is not dated here [Unverified].", "source_edition": "IG-SR v2.1 (SPS 2024); IG-SR v2.2 (SPS 2026); CT IG v2.2 (SPS 2025); delta document SPS 2025 v1.0; BR v3.2 (SPS 2025)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.six-group.com/dam/download/banking-services/standardization/sps/ig-status-report-sps2024-en.pdf", "source_class": "authoritative_primary", "source_title": "SPS Implementation Guidelines, Status Report (pain.002), SPS 2024, version 2.1, dated 2024-02-20, in force from 2024-11-18", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms BE11 is listed in Table 10 of the Status Report implementation guidelines with a meaning matching the record's summary, and Table 10 leaves it unshaded, meaning it is valid for both credit transfer and direct debit submissions. Table 10 is identical on this point in the v2.2 edition (SPS 2026, dated 2026-02-20, in force from 2026-11-14). Does not address triggers, actions or retry detail beyond the table entry." }, { "source_url": "https://www.six-group.com/dam/download/banking-services/standardization/sps/business-rules-sps-2025-en.pdf", "source_class": "authoritative_primary", "source_title": "SPS Business Rules for Payments and Cash Management, SPS 2025, version 3.2, dated 2025-02-24, in force from 2025-11-22", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms SPS Business Rules section 1.4.2 leaves cut-off times and the handling of erroneous orders and status reporting to each financial institution's own customer offering, rather than to the Swiss Payment Standards. Supports the BE11 record's return_windows claim that no SPS-wide deadline applies to sending this status reason, and supports the caveat that the SPS are a voluntary market practice. Does not itself list BE11 or its meaning." } ] }, "rail_name": "Swiss Payment Standards Status Report Reasons", "governing_authority": "SIX Interbank Clearing (Swiss Payment Standards)", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "judgement", "label": "your bank's own terms", "needs": "whose terms decide it: the bank's, the participant's or the scheme's", "detail": "A bank may answer with any ISO status reason, with NARR plus its own text, or with a proprietary code, and handles faulty orders under its own customer terms (BR v3.2 section 1.4.2; IG-SR v2.1 section 3.2.4).", "from": "caveat" } ] }, { "uid": "ch-sps-status:CH03", "id": "CH03", "rail": "ch-sps-status", "kind": "reason-code", "name": "Execution or collection date too far ahead", "group": "technical", "summary": "The requested execution date of a credit transfer, or the requested collection date of a direct debit, lies further in the future than the bank or the procedure accepts.", "triggers": [ "A pain.001 execution date beyond the bank's forward window; the credit transfer guide sets no fixed window, so each bank sets its own (CT IG v2.2 section 4.2) [Inference]", "A Swiss direct debit sent too early: CH-DD accepts files at most 2 years before the processing date, LSV+/BDD at most 30 calendar days before (CH-DD IG v1.2 element 2.18)", "A SEPA direct debit outside the delivery deadlines agreed with the bank, where the bank rejects the payment group rather than moving the date (SDD IG v2.7 element 2.18)" ], "actions": [ "Check the bank's forward-dating window and hold the order until it falls inside it", "Send the rejected payment group again in a new message" ], "retry": { "allowed": true, "rule": "A rejected order stays rejected: RJCT is a final status (IG-SR v2.1 Annex B, Table 21). Fix the cause and send the payment again in a new message. Give that message a new Message Identification, because most Swiss banks check it for duplicates over at least 90 days (CT IG v2.2 section 3.8). The SPS set no retry limit." }, "facts": { "return_windows": [ { "action": "send this reason in a pain.002 status report on the submitted order", "by": "the submitter's Swiss financial institution", "deadline": "None applies. A status report is the bank's answer to a submitted message, not a return, so no return window exists. The SPS expect an immediate reply but set no time limit, and cut-offs and error handling belong to each bank's own offer (IG-SR v2.1 section 3.1.1; BR v3.2 section 1.4.2)." } ], "applies_to": "Swiss Payment Standards customer-to-bank status report (pain.002), on credit transfer (pain.001) and direct debit (pain.008) submissions; B level, where the date sits." }, "caveat": "The SPS are a voluntary market practice. A bank may answer with any ISO status reason, with NARR plus its own text, or with a proprietary code, and handles faulty orders under its own customer terms (BR v3.2 section 1.4.2; IG-SR v2.1 section 3.2.4).", "related": [ "ch-sps-status:CH04", "ch-sps-status:DT01", "ch-sps-status:DT06", "ch-sps-status:CH19" ], "basis": { "sources": "SPS Implementation Guidelines Status Report (pain.002) v2.1 of 2024-02-20, SPS 2024 (IG-SR v2.1) sections 3.1.1, 3.2.3 and 3.2.4 Table 10 (payment-type shading read from the rendered page), Annex B Table 21; SPS Implementation Guidelines Credit Transfer (pain.001) v2.2 of 2025-02-24, SPS 2025 (CT IG v2.2) chapter 4, error code column of the element tables; SPS Implementation Guidelines SEPA Direct Debit (pain.008) v2.7, SPS 2021 (SDD IG v2.7) section 2.2, error code column; Implementation Guidelines Swiss Direct Debits (pain.008) v1.2 of 2018-04-06 (CH-DD IG v1.2) section 2.2, error code column; SPS Business Rules v3.2, SPS 2025 (BR v3.2) section 1.4.2; IG-SR v2.2 of 2026-02-20, SPS 2026, section 3.2.4 Table 10 (unchanged).", "confidence": "high" }, "currency": { "effective_since": "2024-11-18", "effective_note": "IG-SR v2.1 (SPS 2024) applies from 2024-11-18 and is still the current pain.002 guide under SPS 2025, because SIX has published no SPS 2025 edition of it [Inference from the SIX download center, read 2026-09-18]. IG-SR v2.2 (SPS 2026, dated 2026-02-20) applies from 2026-11-14 and keeps this code in Table 10 with the same meaning and the same payment-type shading; that edition changes only tracker data and the status sequence annex. The SPS 2021 guide (v1.1.2, from 2021-11-19) also lists it and governs 2009-schema submissions until the November 2026 release. Use of the code before 2024-11-18 is not dated here [Unverified].", "source_edition": "IG-SR v2.1 (SPS 2024); IG-SR v2.2 (SPS 2026); CT IG v2.2 (SPS 2025); SDD IG v2.7 (SPS 2021); CH-DD IG v1.2 (2018); BR v3.2 (SPS 2025)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.six-group.com/dam/download/banking-services/standardization/sps/ig-status-report-sps2024-en.pdf", "source_class": "authoritative_primary", "source_title": "SPS Implementation Guidelines, Status Report (pain.002), SPS 2024, version 2.1, dated 2024-02-20, in force from 2024-11-18", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms CH03 is listed in Table 10 of the Status Report implementation guidelines with a meaning matching the record's summary, and Table 10 leaves it unshaded, meaning it is valid for both credit transfer and direct debit submissions. Table 10 is identical on this point in the v2.2 edition (SPS 2026, dated 2026-02-20, in force from 2026-11-14). Does not address triggers, actions or retry detail beyond the table entry." }, { "source_url": "https://www.six-group.com/dam/download/banking-services/standardization/sps/business-rules-sps-2025-en.pdf", "source_class": "authoritative_primary", "source_title": "SPS Business Rules for Payments and Cash Management, SPS 2025, version 3.2, dated 2025-02-24, in force from 2025-11-22", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms SPS Business Rules section 1.4.2 leaves cut-off times and the handling of erroneous orders and status reporting to each financial institution's own customer offering, rather than to the Swiss Payment Standards. Supports the CH03 record's return_windows claim that no SPS-wide deadline applies to sending this status reason, and supports the caveat that the SPS are a voluntary market practice. Does not itself list CH03 or its meaning." } ] }, "rail_name": "Swiss Payment Standards Status Report Reasons", "governing_authority": "SIX Interbank Clearing (Swiss Payment Standards)", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "judgement", "label": "your bank's own terms", "needs": "whose terms decide it: the bank's, the participant's or the scheme's", "detail": "A bank may answer with any ISO status reason, with NARR plus its own text, or with a proprietary code, and handles faulty orders under its own customer terms (BR v3.2 section 1.4.2; IG-SR v2.1 section 3.2.4).", "from": "caveat" } ] }, { "uid": "ch-sps-status:CH04", "id": "CH04", "rail": "ch-sps-status", "kind": "reason-code", "name": "Execution or collection date too far back", "group": "technical", "summary": "The requested execution or collection date lies further in the past than the bank or procedure accepts. A date only slightly past may instead be moved forward and reported with DT06.", "triggers": [ "A pain.001 execution date older than the bank accepts; the guide lets banks move a date to the next business day, so only dates beyond that tolerance are rejected [Inference from CT IG v2.2 section 4.2]", "A Swiss direct debit sent too late: at most 90 calendar days after the processing date for CH-DD, 10 for LSV+/BDD (CH-DD IG v1.2 element 2.18)", "A SEPA direct debit delivered after the agreed deadline, where the bank rejects rather than moves the date (SDD IG v2.7 element 2.18)" ], "actions": [ "Set a current or future date and send the payment group again in a new message", "For a direct debit, check that the new collection date still matches what the debtor was told in advance [Inference]" ], "retry": { "allowed": true, "rule": "A rejected order stays rejected: RJCT is a final status (IG-SR v2.1 Annex B, Table 21). Fix the cause and send the payment again in a new message. Give that message a new Message Identification, because most Swiss banks check it for duplicates over at least 90 days (CT IG v2.2 section 3.8). The SPS set no retry limit." }, "facts": { "return_windows": [ { "action": "send this reason in a pain.002 status report on the submitted order", "by": "the submitter's Swiss financial institution", "deadline": "None applies. A status report is the bank's answer to a submitted message, not a return, so no return window exists. The SPS expect an immediate reply but set no time limit, and cut-offs and error handling belong to each bank's own offer (IG-SR v2.1 section 3.1.1; BR v3.2 section 1.4.2)." } ], "applies_to": "Swiss Payment Standards customer-to-bank status report (pain.002), on credit transfer (pain.001) and direct debit (pain.008) submissions; B level, where the date sits." }, "caveat": "The SPS are a voluntary market practice. A bank may answer with any ISO status reason, with NARR plus its own text, or with a proprietary code, and handles faulty orders under its own customer terms (BR v3.2 section 1.4.2; IG-SR v2.1 section 3.2.4).", "related": [ "ch-sps-status:CH03", "ch-sps-status:DT01", "ch-sps-status:DT06", "ch-sps-status:CH19" ], "basis": { "sources": "SPS Implementation Guidelines Status Report (pain.002) v2.1 of 2024-02-20, SPS 2024 (IG-SR v2.1) sections 3.1.1, 3.2.3 and 3.2.4 Table 10 (payment-type shading read from the rendered page), Annex B Table 21; SPS Implementation Guidelines Credit Transfer (pain.001) v2.2 of 2025-02-24, SPS 2025 (CT IG v2.2) chapter 4, error code column of the element tables; SPS Implementation Guidelines SEPA Direct Debit (pain.008) v2.7, SPS 2021 (SDD IG v2.7) section 2.2, error code column; Implementation Guidelines Swiss Direct Debits (pain.008) v1.2 of 2018-04-06 (CH-DD IG v1.2) section 2.2, error code column; SPS Business Rules v3.2, SPS 2025 (BR v3.2) section 1.4.2; IG-SR v2.2 of 2026-02-20, SPS 2026, section 3.2.4 Table 10 (unchanged).", "confidence": "high" }, "currency": { "effective_since": "2024-11-18", "effective_note": "IG-SR v2.1 (SPS 2024) applies from 2024-11-18 and is still the current pain.002 guide under SPS 2025, because SIX has published no SPS 2025 edition of it [Inference from the SIX download center, read 2026-09-18]. IG-SR v2.2 (SPS 2026, dated 2026-02-20) applies from 2026-11-14 and keeps this code in Table 10 with the same meaning and the same payment-type shading; that edition changes only tracker data and the status sequence annex. The SPS 2021 guide (v1.1.2, from 2021-11-19) also lists it and governs 2009-schema submissions until the November 2026 release. Use of the code before 2024-11-18 is not dated here [Unverified].", "source_edition": "IG-SR v2.1 (SPS 2024); IG-SR v2.2 (SPS 2026); CT IG v2.2 (SPS 2025); SDD IG v2.7 (SPS 2021); CH-DD IG v1.2 (2018); BR v3.2 (SPS 2025)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.six-group.com/dam/download/banking-services/standardization/sps/ig-status-report-sps2024-en.pdf", "source_class": "authoritative_primary", "source_title": "SPS Implementation Guidelines, Status Report (pain.002), SPS 2024, version 2.1, dated 2024-02-20, in force from 2024-11-18", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms CH04 is listed in Table 10 of the Status Report implementation guidelines with a meaning matching the record's summary, and Table 10 leaves it unshaded, meaning it is valid for both credit transfer and direct debit submissions. Table 10 is identical on this point in the v2.2 edition (SPS 2026, dated 2026-02-20, in force from 2026-11-14). Does not address triggers, actions or retry detail beyond the table entry." }, { "source_url": "https://www.six-group.com/dam/download/banking-services/standardization/sps/business-rules-sps-2025-en.pdf", "source_class": "authoritative_primary", "source_title": "SPS Business Rules for Payments and Cash Management, SPS 2025, version 3.2, dated 2025-02-24, in force from 2025-11-22", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms SPS Business Rules section 1.4.2 leaves cut-off times and the handling of erroneous orders and status reporting to each financial institution's own customer offering, rather than to the Swiss Payment Standards. Supports the CH04 record's return_windows claim that no SPS-wide deadline applies to sending this status reason, and supports the caveat that the SPS are a voluntary market practice. Does not itself list CH04 or its meaning." } ] }, "rail_name": "Swiss Payment Standards Status Report Reasons", "governing_authority": "SIX Interbank Clearing (Swiss Payment Standards)", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "judgement", "label": "your bank's own terms", "needs": "whose terms decide it: the bank's, the participant's or the scheme's", "detail": "A bank may answer with any ISO status reason, with NARR plus its own text, or with a proprietary code, and handles faulty orders under its own customer terms (BR v3.2 section 1.4.2; IG-SR v2.1 section 3.2.4).", "from": "caveat" } ] }, { "uid": "ch-sps-status:CH07", "id": "CH07", "rail": "ch-sps-status", "kind": "reason-code", "name": "Element given at both B and C level", "group": "technical", "summary": "An element that may sit either at the payment group (B) level or at the transaction (C) level was given at both. The Swiss rules allow one level only.", "triggers": [ "Payment type information, ultimate debtor or charge bearer at both levels of a pain.001 (CT IG v2.2 sections 4.2 and 4.3; BR v3.2 section 2.1.4)", "The same duplication in a pain.008 (SDD IG v2.7; CH-DD IG v1.2)" ], "actions": [ "Put the element at one level only: B level when it holds for every transaction in the group, C level otherwise", "Fix the mapping in the payment software, then send the rejected part again in a new message" ], "retry": { "allowed": true, "rule": "A rejected order stays rejected: RJCT is a final status (IG-SR v2.1 Annex B, Table 21). Fix the cause and send the payment again in a new message. Give that message a new Message Identification, because most Swiss banks check it for duplicates over at least 90 days (CT IG v2.2 section 3.8). The SPS set no retry limit." }, "facts": { "return_windows": [ { "action": "send this reason in a pain.002 status report on the submitted order", "by": "the submitter's Swiss financial institution", "deadline": "None applies. A status report is the bank's answer to a submitted message, not a return, so no return window exists. The SPS expect an immediate reply but set no time limit, and cut-offs and error handling belong to each bank's own offer (IG-SR v2.1 section 3.1.1; BR v3.2 section 1.4.2)." } ], "applies_to": "Swiss Payment Standards customer-to-bank status report (pain.002), on credit transfer (pain.001) and direct debit (pain.008) submissions." }, "caveat": "Some banks accept payment type information at both levels as long as no sub-element repeats (CT IG v2.2 section 4.2). The SPS are a voluntary market practice. A bank may answer with any ISO status reason, with NARR plus its own text, or with a proprietary code, and handles faulty orders under its own customer terms (BR v3.2 section 1.4.2; IG-SR v2.1 section 3.2.4).", "related": [ "ch-sps-status:CH17", "ch-sps-status:CH16" ], "basis": { "sources": "SPS Implementation Guidelines Status Report (pain.002) v2.1 of 2024-02-20, SPS 2024 (IG-SR v2.1) sections 3.1.1, 3.2.3 and 3.2.4 Table 10 (payment-type shading read from the rendered page), Annex B Table 21; SPS Implementation Guidelines Credit Transfer (pain.001) v2.2 of 2025-02-24, SPS 2025 (CT IG v2.2) chapter 4, error code column of the element tables; SPS Implementation Guidelines SEPA Direct Debit (pain.008) v2.7, SPS 2021 (SDD IG v2.7) section 2.2, error code column; Implementation Guidelines Swiss Direct Debits (pain.008) v1.2 of 2018-04-06 (CH-DD IG v1.2) section 2.2, error code column; SPS Business Rules v3.2, SPS 2025 (BR v3.2) section 2.1.4 and section 1.4.2; IG-SR v2.2 of 2026-02-20, SPS 2026, section 3.2.4 Table 10 (unchanged).", "confidence": "high" }, "currency": { "effective_since": "2024-11-18", "effective_note": "IG-SR v2.1 (SPS 2024) applies from 2024-11-18 and is still the current pain.002 guide under SPS 2025, because SIX has published no SPS 2025 edition of it [Inference from the SIX download center, read 2026-09-18]. IG-SR v2.2 (SPS 2026, dated 2026-02-20) applies from 2026-11-14 and keeps this code in Table 10 with the same meaning and the same payment-type shading; that edition changes only tracker data and the status sequence annex. The SPS 2021 guide (v1.1.2, from 2021-11-19) also lists it and governs 2009-schema submissions until the November 2026 release. Use of the code before 2024-11-18 is not dated here [Unverified].", "source_edition": "IG-SR v2.1 (SPS 2024); IG-SR v2.2 (SPS 2026); CT IG v2.2 (SPS 2025); SDD IG v2.7 (SPS 2021); CH-DD IG v1.2 (2018); BR v3.2 (SPS 2025)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.six-group.com/dam/download/banking-services/standardization/sps/ig-status-report-sps2024-en.pdf", "source_class": "authoritative_primary", "source_title": "SPS Implementation Guidelines, Status Report (pain.002), SPS 2024, version 2.1, dated 2024-02-20, in force from 2024-11-18", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms CH07 is listed in Table 10 of the Status Report implementation guidelines with a meaning matching the record's summary, and Table 10 leaves it unshaded, meaning it is valid for both credit transfer and direct debit submissions. Table 10 is identical on this point in the v2.2 edition (SPS 2026, dated 2026-02-20, in force from 2026-11-14). Does not address triggers, actions or retry detail beyond the table entry." }, { "source_url": "https://www.six-group.com/dam/download/banking-services/standardization/sps/business-rules-sps-2025-en.pdf", "source_class": "authoritative_primary", "source_title": "SPS Business Rules for Payments and Cash Management, SPS 2025, version 3.2, dated 2025-02-24, in force from 2025-11-22", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms SPS Business Rules section 1.4.2 leaves cut-off times and the handling of erroneous orders and status reporting to each financial institution's own customer offering, rather than to the Swiss Payment Standards. Supports the CH07 record's return_windows claim that no SPS-wide deadline applies to sending this status reason, and supports the caveat that the SPS are a voluntary market practice. Does not itself list CH07 or its meaning." } ] }, "rail_name": "Swiss Payment Standards Status Report Reasons", "governing_authority": "SIX Interbank Clearing (Swiss Payment Standards)", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "judgement", "label": "your bank's own terms", "needs": "whose terms decide it: the bank's, the participant's or the scheme's", "detail": "A bank may answer with any ISO status reason, with NARR plus its own text, or with a proprietary code, and handles faulty orders under its own customer terms (BR v3.2 section 1.4.2; IG-SR v2.1 section 3.2.4).", "from": "caveat" } ] }, { "uid": "ch-sps-status:CH09", "id": "CH09", "rail": "ch-sps-status", "kind": "reason-code", "name": "Mandate amendment not accepted", "group": "authorization", "summary": "A SEPA direct debit carries mandate amendment details that the bank does not accept in that form. The transaction is rejected.", "triggers": [ "Mandate amendment details that break the guide's rules for the amendment indicator and its sub-elements (SDD IG v2.7, amendment information details)", "Amendment details sent in a case the guide does not provide for [Inference: the guide maps CH09 and CH10 to the same element without separating the cases]" ], "actions": [ "Send amendment details only when the mandate really changed, with the amendment indicator set to true", "Check which mandate fields changed against the SEPA Direct Debit rulebook's amendment attributes", "Send the corrected collection again in a new message" ], "retry": { "allowed": true, "rule": "A rejected order stays rejected: RJCT is a final status (IG-SR v2.1 Annex B, Table 21). Fix the cause and send the payment again in a new message. Give that message a new Message Identification, because most Swiss banks check it for duplicates over at least 90 days (CT IG v2.2 section 3.8). The SPS set no retry limit." }, "facts": { "return_windows": [ { "action": "send this reason in a pain.002 status report on the submitted order", "by": "the submitter's Swiss financial institution", "deadline": "None applies. A status report is the bank's answer to a submitted message, not a return, so no return window exists. The SPS expect an immediate reply but set no time limit, and cut-offs and error handling belong to each bank's own offer (IG-SR v2.1 section 3.1.1; BR v3.2 section 1.4.2)." } ], "applies_to": "Swiss Payment Standards customer-to-bank status report (pain.002), on direct debit (pain.008) submissions only, Swiss or SEPA; Table 10 shades it grey; C level of a SEPA direct debit." }, "caveat": "The SPS are a voluntary market practice. A bank may answer with any ISO status reason, with NARR plus its own text, or with a proprietary code, and handles faulty orders under its own customer terms (BR v3.2 section 1.4.2; IG-SR v2.1 section 3.2.4).", "related": [ "ch-sps-status:CH10", "ch-sps-status:CH14", "ch-sps-status:MD01" ], "basis": { "sources": "SPS Implementation Guidelines Status Report (pain.002) v2.1 of 2024-02-20, SPS 2024 (IG-SR v2.1) sections 3.1.1, 3.2.3 and 3.2.4 Table 10 (payment-type shading read from the rendered page), Annex B Table 21; SPS Implementation Guidelines SEPA Direct Debit (pain.008) v2.7, SPS 2021 (SDD IG v2.7) section 2.2, error code column; SPS Implementation Guidelines Credit Transfer (pain.001) v2.2 of 2025-02-24, SPS 2025 (CT IG v2.2) section 3.8; SPS Business Rules v3.2, SPS 2025 (BR v3.2) section 1.4.2; IG-SR v2.2 of 2026-02-20, SPS 2026, section 3.2.4 Table 10 (unchanged).", "confidence": "medium" }, "currency": { "effective_since": "2024-11-18", "effective_note": "IG-SR v2.1 (SPS 2024) applies from 2024-11-18 and is still the current pain.002 guide under SPS 2025, because SIX has published no SPS 2025 edition of it [Inference from the SIX download center, read 2026-09-18]. IG-SR v2.2 (SPS 2026, dated 2026-02-20) applies from 2026-11-14 and keeps this code in Table 10 with the same meaning and the same payment-type shading; that edition changes only tracker data and the status sequence annex. The SPS 2021 guide (v1.1.2, from 2021-11-19) also lists it and governs 2009-schema submissions until the November 2026 release. Use of the code before 2024-11-18 is not dated here [Unverified].", "source_edition": "IG-SR v2.1 (SPS 2024); IG-SR v2.2 (SPS 2026); SDD IG v2.7 (SPS 2021); BR v3.2 (SPS 2025); CT IG v2.2 (SPS 2025)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.six-group.com/dam/download/banking-services/standardization/sps/ig-status-report-sps2024-en.pdf", "source_class": "authoritative_primary", "source_title": "SPS Implementation Guidelines, Status Report (pain.002), SPS 2024, version 2.1, dated 2024-02-20, in force from 2024-11-18", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms CH09 is listed in Table 10 of the Status Report implementation guidelines with a meaning matching the record's summary, and Table 10 shades it gray with no payment-type wording, meaning it is valid for Swiss and/or SEPA direct debit submissions only, not credit transfers. Table 10 is identical on this point in the v2.2 edition (SPS 2026, dated 2026-02-20, in force from 2026-11-14). Does not address triggers, actions or retry detail beyond the table entry." }, { "source_url": "https://www.six-group.com/dam/download/banking-services/standardization/sps/business-rules-sps-2025-en.pdf", "source_class": "authoritative_primary", "source_title": "SPS Business Rules for Payments and Cash Management, SPS 2025, version 3.2, dated 2025-02-24, in force from 2025-11-22", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms SPS Business Rules section 1.4.2 leaves cut-off times and the handling of erroneous orders and status reporting to each financial institution's own customer offering, rather than to the Swiss Payment Standards. Supports the CH09 record's return_windows claim that no SPS-wide deadline applies to sending this status reason, and supports the caveat that the SPS are a voluntary market practice. Does not itself list CH09 or its meaning." } ] }, "rail_name": "Swiss Payment Standards Status Report Reasons", "governing_authority": "SIX Interbank Clearing (Swiss Payment Standards)", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "judgement", "label": "your bank's own terms", "needs": "whose terms decide it: the bank's, the participant's or the scheme's", "detail": "A bank may answer with any ISO status reason, with NARR plus its own text, or with a proprietary code, and handles faulty orders under its own customer terms (BR v3.2 section 1.4.2; IG-SR v2.1 section 3.2.4).", "from": "caveat" } ] }, { "uid": "ch-sps-status:CH10", "id": "CH10", "rail": "ch-sps-status", "kind": "reason-code", "name": "Mandate amendment details missing", "group": "authorization", "summary": "A SEPA direct debit says the mandate was amended but gives no amendment details. The transaction is rejected.", "triggers": [ "Amendment indicator true with no amendment detail sub-element (SDD IG v2.7, amendment information details)" ], "actions": [ "Add the changed mandate data, such as the original mandate reference or creditor identifier, or clear the amendment indicator if nothing changed", "Send the corrected collection again in a new message" ], "retry": { "allowed": true, "rule": "A rejected order stays rejected: RJCT is a final status (IG-SR v2.1 Annex B, Table 21). Fix the cause and send the payment again in a new message. Give that message a new Message Identification, because most Swiss banks check it for duplicates over at least 90 days (CT IG v2.2 section 3.8). The SPS set no retry limit." }, "facts": { "return_windows": [ { "action": "send this reason in a pain.002 status report on the submitted order", "by": "the submitter's Swiss financial institution", "deadline": "None applies. A status report is the bank's answer to a submitted message, not a return, so no return window exists. The SPS expect an immediate reply but set no time limit, and cut-offs and error handling belong to each bank's own offer (IG-SR v2.1 section 3.1.1; BR v3.2 section 1.4.2)." } ], "applies_to": "Swiss Payment Standards customer-to-bank status report (pain.002), on direct debit (pain.008) submissions only, Swiss or SEPA; Table 10 shades it grey; C level of a SEPA direct debit." }, "caveat": "The SPS are a voluntary market practice. A bank may answer with any ISO status reason, with NARR plus its own text, or with a proprietary code, and handles faulty orders under its own customer terms (BR v3.2 section 1.4.2; IG-SR v2.1 section 3.2.4).", "related": [ "ch-sps-status:CH09", "ch-sps-status:CH14", "ch-sps-status:MD02" ], "basis": { "sources": "SPS Implementation Guidelines Status Report (pain.002) v2.1 of 2024-02-20, SPS 2024 (IG-SR v2.1) sections 3.1.1, 3.2.3 and 3.2.4 Table 10 (payment-type shading read from the rendered page), Annex B Table 21; SPS Implementation Guidelines SEPA Direct Debit (pain.008) v2.7, SPS 2021 (SDD IG v2.7) section 2.2, error code column; SPS Implementation Guidelines Credit Transfer (pain.001) v2.2 of 2025-02-24, SPS 2025 (CT IG v2.2) section 3.8; SPS Business Rules v3.2, SPS 2025 (BR v3.2) section 1.4.2; IG-SR v2.2 of 2026-02-20, SPS 2026, section 3.2.4 Table 10 (unchanged).", "confidence": "high" }, "currency": { "effective_since": "2024-11-18", "effective_note": "IG-SR v2.1 (SPS 2024) applies from 2024-11-18 and is still the current pain.002 guide under SPS 2025, because SIX has published no SPS 2025 edition of it [Inference from the SIX download center, read 2026-09-18]. IG-SR v2.2 (SPS 2026, dated 2026-02-20) applies from 2026-11-14 and keeps this code in Table 10 with the same meaning and the same payment-type shading; that edition changes only tracker data and the status sequence annex. The SPS 2021 guide (v1.1.2, from 2021-11-19) also lists it and governs 2009-schema submissions until the November 2026 release. Use of the code before 2024-11-18 is not dated here [Unverified].", "source_edition": "IG-SR v2.1 (SPS 2024); IG-SR v2.2 (SPS 2026); SDD IG v2.7 (SPS 2021); BR v3.2 (SPS 2025); CT IG v2.2 (SPS 2025)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.six-group.com/dam/download/banking-services/standardization/sps/ig-status-report-sps2024-en.pdf", "source_class": "authoritative_primary", "source_title": "SPS Implementation Guidelines, Status Report (pain.002), SPS 2024, version 2.1, dated 2024-02-20, in force from 2024-11-18", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms CH10 is listed in Table 10 of the Status Report implementation guidelines with a meaning matching the record's summary, and Table 10 shades it gray with no payment-type wording, meaning it is valid for Swiss and/or SEPA direct debit submissions only, not credit transfers. Table 10 is identical on this point in the v2.2 edition (SPS 2026, dated 2026-02-20, in force from 2026-11-14). Does not address triggers, actions or retry detail beyond the table entry." }, { "source_url": "https://www.six-group.com/dam/download/banking-services/standardization/sps/business-rules-sps-2025-en.pdf", "source_class": "authoritative_primary", "source_title": "SPS Business Rules for Payments and Cash Management, SPS 2025, version 3.2, dated 2025-02-24, in force from 2025-11-22", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms SPS Business Rules section 1.4.2 leaves cut-off times and the handling of erroneous orders and status reporting to each financial institution's own customer offering, rather than to the Swiss Payment Standards. Supports the CH10 record's return_windows claim that no SPS-wide deadline applies to sending this status reason, and supports the caveat that the SPS are a voluntary market practice. Does not itself list CH10 or its meaning." } ] }, "rail_name": "Swiss Payment Standards Status Report Reasons", "governing_authority": "SIX Interbank Clearing (Swiss Payment Standards)", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "judgement", "label": "your bank's own terms", "needs": "whose terms decide it: the bank's, the participant's or the scheme's", "detail": "A bank may answer with any ISO status reason, with NARR plus its own text, or with a proprietary code, and handles faulty orders under its own customer terms (BR v3.2 section 1.4.2; IG-SR v2.1 section 3.2.4).", "from": "caveat" } ] }, { "uid": "ch-sps-status:CH11", "id": "CH11", "rail": "ch-sps-status", "kind": "reason-code", "name": "Creditor identifier wrong", "group": "administrative", "summary": "The creditor's identifier in a direct debit is not valid: the SEPA Creditor Identifier, or for Swiss direct debits the RS-PID (CH-DD) or the LSV+/BDD identification.", "triggers": [ "A SEPA Creditor Identifier with a bad country code or check digits, or one that fails the mandate check agreed with the bank (SDD IG v2.7)", "A CH-DD RS-PID whose check digits fail (Modulo 97-10), or a wrong LSV+/BDD identification (CH-DD IG v1.2)" ], "actions": [ "Use the identifier issued for the procedure; it is not the company's UID or VAT number [Inference]", "Check the identifier stored in the payment software for each creditor entity", "Send the rejected payment group again in a new message" ], "retry": { "allowed": true, "rule": "A rejected order stays rejected: RJCT is a final status (IG-SR v2.1 Annex B, Table 21). Fix the cause and send the payment again in a new message. Give that message a new Message Identification, because most Swiss banks check it for duplicates over at least 90 days (CT IG v2.2 section 3.8). The SPS set no retry limit." }, "facts": { "return_windows": [ { "action": "send this reason in a pain.002 status report on the submitted order", "by": "the submitter's Swiss financial institution", "deadline": "None applies. A status report is the bank's answer to a submitted message, not a return, so no return window exists. The SPS expect an immediate reply but set no time limit, and cut-offs and error handling belong to each bank's own offer (IG-SR v2.1 section 3.1.1; BR v3.2 section 1.4.2)." } ], "applies_to": "Swiss Payment Standards customer-to-bank status report (pain.002), on direct debit (pain.008) submissions only, Swiss or SEPA; Table 10 shades it grey; B level with all its transactions, or C level where the identifier sits in the transaction." }, "caveat": "SIX plans to discontinue the LSV+/BDD direct debit procedures on 30 September 2028 (BR v3.2 section 2.2). The SPS are a voluntary market practice. A bank may answer with any ISO status reason, with NARR plus its own text, or with a proprietary code, and handles faulty orders under its own customer terms (BR v3.2 section 1.4.2; IG-SR v2.1 section 3.2.4).", "related": [ "ch-sps-status:CH12", "ch-sps-status:MD01", "ch-sps-status:RR12" ], "basis": { "sources": "SPS Implementation Guidelines Status Report (pain.002) v2.1 of 2024-02-20, SPS 2024 (IG-SR v2.1) sections 3.1.1, 3.2.3 and 3.2.4 Table 10 (payment-type shading read from the rendered page), Annex B Table 21; SPS Implementation Guidelines SEPA Direct Debit (pain.008) v2.7, SPS 2021 (SDD IG v2.7) section 2.2, error code column; Implementation Guidelines Swiss Direct Debits (pain.008) v1.2 of 2018-04-06 (CH-DD IG v1.2) section 2.2, error code column; SPS Business Rules v3.2, SPS 2025 (BR v3.2) section 2.2 and section 1.4.2; SPS Implementation Guidelines Credit Transfer (pain.001) v2.2 of 2025-02-24, SPS 2025 (CT IG v2.2) section 3.8; IG-SR v2.2 of 2026-02-20, SPS 2026, section 3.2.4 Table 10 (unchanged).", "confidence": "high" }, "currency": { "effective_since": "2024-11-18", "effective_note": "IG-SR v2.1 (SPS 2024) applies from 2024-11-18 and is still the current pain.002 guide under SPS 2025, because SIX has published no SPS 2025 edition of it [Inference from the SIX download center, read 2026-09-18]. IG-SR v2.2 (SPS 2026, dated 2026-02-20) applies from 2026-11-14 and keeps this code in Table 10 with the same meaning and the same payment-type shading; that edition changes only tracker data and the status sequence annex. The SPS 2021 guide (v1.1.2, from 2021-11-19) also lists it and governs 2009-schema submissions until the November 2026 release. Use of the code before 2024-11-18 is not dated here [Unverified].", "source_edition": "IG-SR v2.1 (SPS 2024); IG-SR v2.2 (SPS 2026); SDD IG v2.7 (SPS 2021); CH-DD IG v1.2 (2018); BR v3.2 (SPS 2025); CT IG v2.2 (SPS 2025)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.six-group.com/dam/download/banking-services/standardization/sps/ig-status-report-sps2024-en.pdf", "source_class": "authoritative_primary", "source_title": "SPS Implementation Guidelines, Status Report (pain.002), SPS 2024, version 2.1, dated 2024-02-20, in force from 2024-11-18", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms CH11 is listed in Table 10 of the Status Report implementation guidelines with a meaning matching the record's summary, and Table 10 shades it gray with no payment-type wording, meaning it is valid for Swiss and/or SEPA direct debit submissions only, not credit transfers. Table 10 is identical on this point in the v2.2 edition (SPS 2026, dated 2026-02-20, in force from 2026-11-14). Does not address triggers, actions or retry detail beyond the table entry." }, { "source_url": "https://www.six-group.com/dam/download/banking-services/standardization/sps/business-rules-sps-2025-en.pdf", "source_class": "authoritative_primary", "source_title": "SPS Business Rules for Payments and Cash Management, SPS 2025, version 3.2, dated 2025-02-24, in force from 2025-11-22", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms SPS Business Rules section 1.4.2 leaves cut-off times and the handling of erroneous orders and status reporting to each financial institution's own customer offering, rather than to the Swiss Payment Standards. Supports the CH11 record's return_windows claim that no SPS-wide deadline applies to sending this status reason, and supports the caveat that the SPS are a voluntary market practice. Does not itself list CH11 or its meaning." } ] }, "rail_name": "Swiss Payment Standards Status Report Reasons", "governing_authority": "SIX Interbank Clearing (Swiss Payment Standards)", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "judgement", "label": "your bank's own terms", "needs": "whose terms decide it: the bank's, the participant's or the scheme's", "detail": "A bank may answer with any ISO status reason, with NARR plus its own text, or with a proprietary code, and handles faulty orders under its own customer terms (BR v3.2 section 1.4.2; IG-SR v2.1 section 3.2.4).", "from": "caveat" } ] }, { "uid": "ch-sps-status:CH12", "id": "CH12", "rail": "ch-sps-status", "kind": "reason-code", "name": "Creditor identifier not uniform in a payment group (SEPA DD)", "group": "administrative", "summary": "In a SEPA direct debit order, the collections in one payment group do not share a single creditor identifier. Table 10 limits this code to SEPA direct debits.", "triggers": [ "A creditor identifier carried at transaction level that differs between transactions of one payment group; the whole group is then rejected (SDD IG v2.7 element 2.66)" ], "actions": [ "Group collections by creditor identifier, one payment group each", "Send the rejected group again in a new message" ], "retry": { "allowed": true, "rule": "A rejected order stays rejected: RJCT is a final status (IG-SR v2.1 Annex B, Table 21). Fix the cause and send the payment again in a new message. Give that message a new Message Identification, because most Swiss banks check it for duplicates over at least 90 days (CT IG v2.2 section 3.8). The SPS set no retry limit." }, "facts": { "return_windows": [ { "action": "send this reason in a pain.002 status report on the submitted order", "by": "the submitter's Swiss financial institution", "deadline": "None applies. A status report is the bank's answer to a submitted message, not a return, so no return window exists. The SPS expect an immediate reply but set no time limit, and cut-offs and error handling belong to each bank's own offer (IG-SR v2.1 section 3.1.1; BR v3.2 section 1.4.2)." } ], "applies_to": "Swiss Payment Standards customer-to-bank status report (pain.002), on SEPA direct debit (pain.008) submissions only; Table 10 shades it grey and its entry names SEPA direct debit; B level of a SEPA direct debit." }, "caveat": "The SPS are a voluntary market practice. A bank may answer with any ISO status reason, with NARR plus its own text, or with a proprietary code, and handles faulty orders under its own customer terms (BR v3.2 section 1.4.2; IG-SR v2.1 section 3.2.4).", "related": [ "ch-sps-status:CH11", "ch-sps-status:CH22" ], "basis": { "sources": "SPS Implementation Guidelines Status Report (pain.002) v2.1 of 2024-02-20, SPS 2024 (IG-SR v2.1) sections 3.1.1, 3.2.3 and 3.2.4 Table 10 (payment-type shading read from the rendered page), Annex B Table 21; SPS Implementation Guidelines SEPA Direct Debit (pain.008) v2.7, SPS 2021 (SDD IG v2.7) section 2.2, error code column; SPS Implementation Guidelines Credit Transfer (pain.001) v2.2 of 2025-02-24, SPS 2025 (CT IG v2.2) section 3.8; SPS Business Rules v3.2, SPS 2025 (BR v3.2) section 1.4.2; IG-SR v2.2 of 2026-02-20, SPS 2026, section 3.2.4 Table 10 (unchanged).", "confidence": "high" }, "currency": { "effective_since": "2024-11-18", "effective_note": "IG-SR v2.1 (SPS 2024) applies from 2024-11-18 and is still the current pain.002 guide under SPS 2025, because SIX has published no SPS 2025 edition of it [Inference from the SIX download center, read 2026-09-18]. IG-SR v2.2 (SPS 2026, dated 2026-02-20) applies from 2026-11-14 and keeps this code in Table 10 with the same meaning and the same payment-type shading; that edition changes only tracker data and the status sequence annex. The SPS 2021 guide (v1.1.2, from 2021-11-19) also lists it and governs 2009-schema submissions until the November 2026 release. Use of the code before 2024-11-18 is not dated here [Unverified].", "source_edition": "IG-SR v2.1 (SPS 2024); IG-SR v2.2 (SPS 2026); SDD IG v2.7 (SPS 2021); BR v3.2 (SPS 2025); CT IG v2.2 (SPS 2025)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.six-group.com/dam/download/banking-services/standardization/sps/ig-status-report-sps2024-en.pdf", "source_class": "authoritative_primary", "source_title": "SPS Implementation Guidelines, Status Report (pain.002), SPS 2024, version 2.1, dated 2024-02-20, in force from 2024-11-18", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms CH12 is listed in Table 10 of the Status Report implementation guidelines with a meaning matching the record's summary, and Table 10 shades it gray with wording naming SEPA Direct Debit, meaning it is valid for SEPA direct debit submissions only. Table 10 is identical on this point in the v2.2 edition (SPS 2026, dated 2026-02-20, in force from 2026-11-14). Does not address triggers, actions or retry detail beyond the table entry." }, { "source_url": "https://www.six-group.com/dam/download/banking-services/standardization/sps/business-rules-sps-2025-en.pdf", "source_class": "authoritative_primary", "source_title": "SPS Business Rules for Payments and Cash Management, SPS 2025, version 3.2, dated 2025-02-24, in force from 2025-11-22", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms SPS Business Rules section 1.4.2 leaves cut-off times and the handling of erroneous orders and status reporting to each financial institution's own customer offering, rather than to the Swiss Payment Standards. Supports the CH12 record's return_windows claim that no SPS-wide deadline applies to sending this status reason, and supports the caveat that the SPS are a voluntary market practice. Does not itself list CH12 or its meaning." } ] }, "rail_name": "Swiss Payment Standards Status Report Reasons", "governing_authority": "SIX Interbank Clearing (Swiss Payment Standards)", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "judgement", "label": "your bank's own terms", "needs": "whose terms decide it: the bank's, the participant's or the scheme's", "detail": "A bank may answer with any ISO status reason, with NARR plus its own text, or with a proprietary code, and handles faulty orders under its own customer terms (BR v3.2 section 1.4.2; IG-SR v2.1 section 3.2.4).", "from": "caveat" } ] }, { "uid": "ch-sps-status:CH14", "id": "CH14", "rail": "ch-sps-status", "kind": "reason-code", "name": "Original debtor agent not allowed (SEPA DD)", "group": "authorization", "summary": "A SEPA direct debit gives the original debtor agent in its mandate amendment details where the guide forbids it. Table 10 limits this code to SEPA direct debits.", "triggers": [ "Original debtor agent sent in a mandate amendment case where the guide does not allow it, including together with the SMNDA marker in the original debtor account (SDD IG v2.7, amendment information details)" ], "actions": [ "Leave the element out unless the amendment case calls for it, and follow the SEPA Direct Debit rulebook's rules on a debtor changing account", "Send the corrected collection again in a new message" ], "retry": { "allowed": true, "rule": "A rejected order stays rejected: RJCT is a final status (IG-SR v2.1 Annex B, Table 21). Fix the cause and send the payment again in a new message. Give that message a new Message Identification, because most Swiss banks check it for duplicates over at least 90 days (CT IG v2.2 section 3.8). The SPS set no retry limit." }, "facts": { "return_windows": [ { "action": "send this reason in a pain.002 status report on the submitted order", "by": "the submitter's Swiss financial institution", "deadline": "None applies. A status report is the bank's answer to a submitted message, not a return, so no return window exists. The SPS expect an immediate reply but set no time limit, and cut-offs and error handling belong to each bank's own offer (IG-SR v2.1 section 3.1.1; BR v3.2 section 1.4.2)." } ], "applies_to": "Swiss Payment Standards customer-to-bank status report (pain.002), on SEPA direct debit (pain.008) submissions only; Table 10 shades it grey and its entry names SEPA direct debit; C level of a SEPA direct debit." }, "caveat": "The SPS are a voluntary market practice. A bank may answer with any ISO status reason, with NARR plus its own text, or with a proprietary code, and handles faulty orders under its own customer terms (BR v3.2 section 1.4.2; IG-SR v2.1 section 3.2.4).", "related": [ "ch-sps-status:CH09", "ch-sps-status:CH10" ], "basis": { "sources": "SPS Implementation Guidelines Status Report (pain.002) v2.1 of 2024-02-20, SPS 2024 (IG-SR v2.1) sections 3.1.1, 3.2.3 and 3.2.4 Table 10 (payment-type shading read from the rendered page), Annex B Table 21; SPS Implementation Guidelines SEPA Direct Debit (pain.008) v2.7, SPS 2021 (SDD IG v2.7) section 2.2, error code column; SPS Implementation Guidelines Credit Transfer (pain.001) v2.2 of 2025-02-24, SPS 2025 (CT IG v2.2) section 3.8; SPS Business Rules v3.2, SPS 2025 (BR v3.2) section 1.4.2; IG-SR v2.2 of 2026-02-20, SPS 2026, section 3.2.4 Table 10 (unchanged).", "confidence": "high" }, "currency": { "effective_since": "2024-11-18", "effective_note": "IG-SR v2.1 (SPS 2024) applies from 2024-11-18 and is still the current pain.002 guide under SPS 2025, because SIX has published no SPS 2025 edition of it [Inference from the SIX download center, read 2026-09-18]. IG-SR v2.2 (SPS 2026, dated 2026-02-20) applies from 2026-11-14 and keeps this code in Table 10 with the same meaning and the same payment-type shading; that edition changes only tracker data and the status sequence annex. The SPS 2021 guide (v1.1.2, from 2021-11-19) also lists it and governs 2009-schema submissions until the November 2026 release. Use of the code before 2024-11-18 is not dated here [Unverified].", "source_edition": "IG-SR v2.1 (SPS 2024); IG-SR v2.2 (SPS 2026); SDD IG v2.7 (SPS 2021); BR v3.2 (SPS 2025); CT IG v2.2 (SPS 2025)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.six-group.com/dam/download/banking-services/standardization/sps/ig-status-report-sps2024-en.pdf", "source_class": "authoritative_primary", "source_title": "SPS Implementation Guidelines, Status Report (pain.002), SPS 2024, version 2.1, dated 2024-02-20, in force from 2024-11-18", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms CH14 is listed in Table 10 of the Status Report implementation guidelines with a meaning matching the record's summary, and Table 10 shades it gray with wording naming SEPA Direct Debit, meaning it is valid for SEPA direct debit submissions only. Table 10 is identical on this point in the v2.2 edition (SPS 2026, dated 2026-02-20, in force from 2026-11-14). Does not address triggers, actions or retry detail beyond the table entry." }, { "source_url": "https://www.six-group.com/dam/download/banking-services/standardization/sps/business-rules-sps-2025-en.pdf", "source_class": "authoritative_primary", "source_title": "SPS Business Rules for Payments and Cash Management, SPS 2025, version 3.2, dated 2025-02-24, in force from 2025-11-22", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms SPS Business Rules section 1.4.2 leaves cut-off times and the handling of erroneous orders and status reporting to each financial institution's own customer offering, rather than to the Swiss Payment Standards. Supports the CH14 record's return_windows claim that no SPS-wide deadline applies to sending this status reason, and supports the caveat that the SPS are a voluntary market practice. Does not itself list CH14 or its meaning." } ] }, "rail_name": "Swiss Payment Standards Status Report Reasons", "governing_authority": "SIX Interbank Clearing (Swiss Payment Standards)", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "judgement", "label": "your bank's own terms", "needs": "whose terms decide it: the bank's, the participant's or the scheme's", "detail": "A bank may answer with any ISO status reason, with NARR plus its own text, or with a proprietary code, and handles faulty orders under its own customer terms (BR v3.2 section 1.4.2; IG-SR v2.1 section 3.2.4).", "from": "caveat" } ] }, { "uid": "ch-sps-status:CH15", "id": "CH15", "rail": "ch-sps-status", "kind": "reason-code", "name": "Structured remittance information too long", "group": "technical", "summary": "A transaction's structured remittance information is longer than 140 characters, counting the XML tags of its sub-elements.", "triggers": [ "Structured remittance information in a SEPA credit transfer over 140 characters including sub-element tags (CT IG v2.2 section 4.3)", "The same limit in a pain.008 (SDD IG v2.7; CH-DD IG v1.2)" ], "actions": [ "Shorten the structured block, for example to the creditor reference alone [Inference]", "Send the corrected transaction again in a new message" ], "retry": { "allowed": true, "rule": "A rejected order stays rejected: RJCT is a final status (IG-SR v2.1 Annex B, Table 21). Fix the cause and send the payment again in a new message. Give that message a new Message Identification, because most Swiss banks check it for duplicates over at least 90 days (CT IG v2.2 section 3.8). The SPS set no retry limit." }, "facts": { "return_windows": [ { "action": "send this reason in a pain.002 status report on the submitted order", "by": "the submitter's Swiss financial institution", "deadline": "None applies. A status report is the bank's answer to a submitted message, not a return, so no return window exists. The SPS expect an immediate reply but set no time limit, and cut-offs and error handling belong to each bank's own offer (IG-SR v2.1 section 3.1.1; BR v3.2 section 1.4.2)." } ], "applies_to": "Swiss Payment Standards customer-to-bank status report (pain.002), on credit transfer (pain.001) and direct debit (pain.008) submissions; C level." }, "caveat": "The SPS are a voluntary market practice. A bank may answer with any ISO status reason, with NARR plus its own text, or with a proprietary code, and handles faulty orders under its own customer terms (BR v3.2 section 1.4.2; IG-SR v2.1 section 3.2.4).", "related": [ "ch-sps-status:CH16", "ch-sps-status:CH17" ], "basis": { "sources": "SPS Implementation Guidelines Status Report (pain.002) v2.1 of 2024-02-20, SPS 2024 (IG-SR v2.1) sections 3.1.1, 3.2.3 and 3.2.4 Table 10 (payment-type shading read from the rendered page), Annex B Table 21; SPS Implementation Guidelines Credit Transfer (pain.001) v2.2 of 2025-02-24, SPS 2025 (CT IG v2.2) chapter 4, error code column of the element tables; SPS Implementation Guidelines SEPA Direct Debit (pain.008) v2.7, SPS 2021 (SDD IG v2.7) section 2.2, error code column; Implementation Guidelines Swiss Direct Debits (pain.008) v1.2 of 2018-04-06 (CH-DD IG v1.2) section 2.2, error code column; SPS Business Rules v3.2, SPS 2025 (BR v3.2) section 1.4.2; IG-SR v2.2 of 2026-02-20, SPS 2026, section 3.2.4 Table 10 (unchanged).", "confidence": "high" }, "currency": { "effective_since": "2024-11-18", "effective_note": "IG-SR v2.1 (SPS 2024) applies from 2024-11-18 and is still the current pain.002 guide under SPS 2025, because SIX has published no SPS 2025 edition of it [Inference from the SIX download center, read 2026-09-18]. IG-SR v2.2 (SPS 2026, dated 2026-02-20) applies from 2026-11-14 and keeps this code in Table 10 with the same meaning and the same payment-type shading; that edition changes only tracker data and the status sequence annex. The SPS 2021 guide (v1.1.2, from 2021-11-19) also lists it and governs 2009-schema submissions until the November 2026 release. Use of the code before 2024-11-18 is not dated here [Unverified].", "source_edition": "IG-SR v2.1 (SPS 2024); IG-SR v2.2 (SPS 2026); CT IG v2.2 (SPS 2025); SDD IG v2.7 (SPS 2021); CH-DD IG v1.2 (2018); BR v3.2 (SPS 2025)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.six-group.com/dam/download/banking-services/standardization/sps/ig-status-report-sps2024-en.pdf", "source_class": "authoritative_primary", "source_title": "SPS Implementation Guidelines, Status Report (pain.002), SPS 2024, version 2.1, dated 2024-02-20, in force from 2024-11-18", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms CH15 is listed in Table 10 of the Status Report implementation guidelines with a meaning matching the record's summary, and Table 10 leaves it unshaded, meaning it is valid for both credit transfer and direct debit submissions. Table 10 is identical on this point in the v2.2 edition (SPS 2026, dated 2026-02-20, in force from 2026-11-14). Does not address triggers, actions or retry detail beyond the table entry." }, { "source_url": "https://www.six-group.com/dam/download/banking-services/standardization/sps/business-rules-sps-2025-en.pdf", "source_class": "authoritative_primary", "source_title": "SPS Business Rules for Payments and Cash Management, SPS 2025, version 3.2, dated 2025-02-24, in force from 2025-11-22", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms SPS Business Rules section 1.4.2 leaves cut-off times and the handling of erroneous orders and status reporting to each financial institution's own customer offering, rather than to the Swiss Payment Standards. Supports the CH15 record's return_windows claim that no SPS-wide deadline applies to sending this status reason, and supports the caveat that the SPS are a voluntary market practice. Does not itself list CH15 or its meaning." } ] }, "rail_name": "Swiss Payment Standards Status Report Reasons", "governing_authority": "SIX Interbank Clearing (Swiss Payment Standards)", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "judgement", "label": "your bank's own terms", "needs": "whose terms decide it: the bank's, the participant's or the scheme's", "detail": "A bank may answer with any ISO status reason, with NARR plus its own text, or with a proprietary code, and handles faulty orders under its own customer terms (BR v3.2 section 1.4.2; IG-SR v2.1 section 3.2.4).", "from": "caveat" } ] }, { "uid": "ch-sps-status:CH16", "id": "CH16", "rail": "ch-sps-status", "kind": "reason-code", "name": "Element content in the wrong form", "group": "technical", "summary": "An element is present but its content breaks the guide's rules, for instance a check digit, a pattern, the character set, or a value the payment type does not allow. It is one of the reason codes the Swiss element tables name most often.", "triggers": [ "An IBAN, reference or other identifier that fails its check digits or format; the SIX example of a C-level reject for an invalid creditor IBAN uses CH16 (IG-SR v2.1 chapter 5, Table 20)", "Content outside what the element tables allow for the payment type (CT IG v2.2 chapter 4; IG-SR v2.1 section 3.2.1 calls these technical validation errors)", "The same kinds of error in a pain.008 (SDD IG v2.7; CH-DD IG v1.2)" ], "actions": [ "Read the additional information text, up to 105 characters, which usually names the element (IG-SR v2.1 section 3.1.5)", "Fix the payment software or master data that produced the value", "Send the corrected payments again in a new message" ], "retry": { "allowed": true, "rule": "A rejected order stays rejected: RJCT is a final status (IG-SR v2.1 Annex B, Table 21). Fix the cause and send the payment again in a new message. Give that message a new Message Identification, because most Swiss banks check it for duplicates over at least 90 days (CT IG v2.2 section 3.8). The SPS set no retry limit." }, "facts": { "return_windows": [ { "action": "send this reason in a pain.002 status report on the submitted order", "by": "the submitter's Swiss financial institution", "deadline": "None applies. A status report is the bank's answer to a submitted message, not a return, so no return window exists. The SPS expect an immediate reply but set no time limit, and cut-offs and error handling belong to each bank's own offer (IG-SR v2.1 section 3.1.1; BR v3.2 section 1.4.2)." } ], "applies_to": "Swiss Payment Standards customer-to-bank status report (pain.002), on credit transfer (pain.001) and direct debit (pain.008) submissions." }, "caveat": "The SPS are a voluntary market practice. A bank may answer with any ISO status reason, with NARR plus its own text, or with a proprietary code, and handles faulty orders under its own customer terms (BR v3.2 section 1.4.2; IG-SR v2.1 section 3.2.4).", "related": [ "ch-sps-status:CH17", "ch-sps-status:CH21", "ch-sps-status:FF01", "ch-sps-status:AC01" ], "basis": { "sources": "SPS Implementation Guidelines Status Report (pain.002) v2.1 of 2024-02-20, SPS 2024 (IG-SR v2.1) sections 3.1.1, 3.2.3 and 3.2.4 Table 10 (payment-type shading read from the rendered page), Annex B Table 21; SPS Implementation Guidelines Credit Transfer (pain.001) v2.2 of 2025-02-24, SPS 2025 (CT IG v2.2) chapter 4, error code column of the element tables; SPS Implementation Guidelines SEPA Direct Debit (pain.008) v2.7, SPS 2021 (SDD IG v2.7) section 2.2, error code column; Implementation Guidelines Swiss Direct Debits (pain.008) v1.2 of 2018-04-06 (CH-DD IG v1.2) section 2.2, error code column; IG-SR v2.1 sections 3.1.5 and 3.2.1, chapter 5 Table 20; SPS Business Rules v3.2, SPS 2025 (BR v3.2) section 1.4.2; IG-SR v2.2 of 2026-02-20, SPS 2026, section 3.2.4 Table 10 (unchanged).", "confidence": "high" }, "currency": { "effective_since": "2024-11-18", "effective_note": "IG-SR v2.1 (SPS 2024) applies from 2024-11-18 and is still the current pain.002 guide under SPS 2025, because SIX has published no SPS 2025 edition of it [Inference from the SIX download center, read 2026-09-18]. IG-SR v2.2 (SPS 2026, dated 2026-02-20) applies from 2026-11-14 and keeps this code in Table 10 with the same meaning and the same payment-type shading; that edition changes only tracker data and the status sequence annex. The SPS 2021 guide (v1.1.2, from 2021-11-19) also lists it and governs 2009-schema submissions until the November 2026 release. Use of the code before 2024-11-18 is not dated here [Unverified].", "source_edition": "IG-SR v2.1 (SPS 2024); IG-SR v2.2 (SPS 2026); CT IG v2.2 (SPS 2025); SDD IG v2.7 (SPS 2021); CH-DD IG v1.2 (2018); BR v3.2 (SPS 2025)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.six-group.com/dam/download/banking-services/standardization/sps/ig-status-report-sps2024-en.pdf", "source_class": "authoritative_primary", "source_title": "SPS Implementation Guidelines, Status Report (pain.002), SPS 2024, version 2.1, dated 2024-02-20, in force from 2024-11-18", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms CH16 is listed in Table 10 of the Status Report implementation guidelines with a meaning matching the record's summary, and Table 10 leaves it unshaded, meaning it is valid for both credit transfer and direct debit submissions. Table 10 is identical on this point in the v2.2 edition (SPS 2026, dated 2026-02-20, in force from 2026-11-14). Does not address triggers, actions or retry detail beyond the table entry." }, { "source_url": "https://www.six-group.com/dam/download/banking-services/standardization/sps/business-rules-sps-2025-en.pdf", "source_class": "authoritative_primary", "source_title": "SPS Business Rules for Payments and Cash Management, SPS 2025, version 3.2, dated 2025-02-24, in force from 2025-11-22", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms SPS Business Rules section 1.4.2 leaves cut-off times and the handling of erroneous orders and status reporting to each financial institution's own customer offering, rather than to the Swiss Payment Standards. Supports the CH16 record's return_windows claim that no SPS-wide deadline applies to sending this status reason, and supports the caveat that the SPS are a voluntary market practice. Does not itself list CH16 or its meaning." } ] }, "rail_name": "Swiss Payment Standards Status Report Reasons", "governing_authority": "SIX Interbank Clearing (Swiss Payment Standards)", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "judgement", "label": "your bank's own terms", "needs": "whose terms decide it: the bank's, the participant's or the scheme's", "detail": "A bank may answer with any ISO status reason, with NARR plus its own text, or with a proprietary code, and handles faulty orders under its own customer terms (BR v3.2 section 1.4.2; IG-SR v2.1 section 3.2.4).", "from": "caveat" } ] }, { "uid": "ch-sps-status:CH17", "id": "CH17", "rail": "ch-sps-status", "kind": "reason-code", "name": "Element not allowed here", "group": "technical", "summary": "The order contains an element that is not allowed, either at all or for the payment type chosen. The level that carries it is rejected.", "triggers": [ "An element the credit transfer guide marks as not allowed for the payment type (CT IG v2.2 chapter 4; IG-SR v2.1 section 3.2.1)", "An element outside what the direct debit guides allow (SDD IG v2.7; CH-DD IG v1.2)" ], "actions": [ "Check the payment type specific column of the guide for the element and drop it where it is not allowed", "Check that the payment software classifies the payment type correctly", "Send the corrected part again in a new message" ], "retry": { "allowed": true, "rule": "A rejected order stays rejected: RJCT is a final status (IG-SR v2.1 Annex B, Table 21). Fix the cause and send the payment again in a new message. Give that message a new Message Identification, because most Swiss banks check it for duplicates over at least 90 days (CT IG v2.2 section 3.8). The SPS set no retry limit." }, "facts": { "return_windows": [ { "action": "send this reason in a pain.002 status report on the submitted order", "by": "the submitter's Swiss financial institution", "deadline": "None applies. A status report is the bank's answer to a submitted message, not a return, so no return window exists. The SPS expect an immediate reply but set no time limit, and cut-offs and error handling belong to each bank's own offer (IG-SR v2.1 section 3.1.1; BR v3.2 section 1.4.2)." } ], "applies_to": "Swiss Payment Standards customer-to-bank status report (pain.002), on credit transfer (pain.001) and direct debit (pain.008) submissions." }, "caveat": "The SPS are a voluntary market practice. A bank may answer with any ISO status reason, with NARR plus its own text, or with a proprietary code, and handles faulty orders under its own customer terms (BR v3.2 section 1.4.2; IG-SR v2.1 section 3.2.4).", "related": [ "ch-sps-status:CH16", "ch-sps-status:CH21", "ch-sps-status:CH07" ], "basis": { "sources": "SPS Implementation Guidelines Status Report (pain.002) v2.1 of 2024-02-20, SPS 2024 (IG-SR v2.1) sections 3.1.1, 3.2.3 and 3.2.4 Table 10 (payment-type shading read from the rendered page), Annex B Table 21; SPS Implementation Guidelines Credit Transfer (pain.001) v2.2 of 2025-02-24, SPS 2025 (CT IG v2.2) chapter 4, error code column of the element tables; SPS Implementation Guidelines SEPA Direct Debit (pain.008) v2.7, SPS 2021 (SDD IG v2.7) section 2.2, error code column; Implementation Guidelines Swiss Direct Debits (pain.008) v1.2 of 2018-04-06 (CH-DD IG v1.2) section 2.2, error code column; IG-SR v2.1 section 3.2.1; SPS Business Rules v3.2, SPS 2025 (BR v3.2) section 1.4.2; IG-SR v2.2 of 2026-02-20, SPS 2026, section 3.2.4 Table 10 (unchanged).", "confidence": "high" }, "currency": { "effective_since": "2024-11-18", "effective_note": "IG-SR v2.1 (SPS 2024) applies from 2024-11-18 and is still the current pain.002 guide under SPS 2025, because SIX has published no SPS 2025 edition of it [Inference from the SIX download center, read 2026-09-18]. IG-SR v2.2 (SPS 2026, dated 2026-02-20) applies from 2026-11-14 and keeps this code in Table 10 with the same meaning and the same payment-type shading; that edition changes only tracker data and the status sequence annex. The SPS 2021 guide (v1.1.2, from 2021-11-19) also lists it and governs 2009-schema submissions until the November 2026 release. Use of the code before 2024-11-18 is not dated here [Unverified].", "source_edition": "IG-SR v2.1 (SPS 2024); IG-SR v2.2 (SPS 2026); CT IG v2.2 (SPS 2025); SDD IG v2.7 (SPS 2021); CH-DD IG v1.2 (2018); BR v3.2 (SPS 2025)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.six-group.com/dam/download/banking-services/standardization/sps/ig-status-report-sps2024-en.pdf", "source_class": "authoritative_primary", "source_title": "SPS Implementation Guidelines, Status Report (pain.002), SPS 2024, version 2.1, dated 2024-02-20, in force from 2024-11-18", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms CH17 is listed in Table 10 of the Status Report implementation guidelines with a meaning matching the record's summary, and Table 10 leaves it unshaded, meaning it is valid for both credit transfer and direct debit submissions. Table 10 is identical on this point in the v2.2 edition (SPS 2026, dated 2026-02-20, in force from 2026-11-14). Does not address triggers, actions or retry detail beyond the table entry." }, { "source_url": "https://www.six-group.com/dam/download/banking-services/standardization/sps/business-rules-sps-2025-en.pdf", "source_class": "authoritative_primary", "source_title": "SPS Business Rules for Payments and Cash Management, SPS 2025, version 3.2, dated 2025-02-24, in force from 2025-11-22", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms SPS Business Rules section 1.4.2 leaves cut-off times and the handling of erroneous orders and status reporting to each financial institution's own customer offering, rather than to the Swiss Payment Standards. Supports the CH17 record's return_windows claim that no SPS-wide deadline applies to sending this status reason, and supports the caveat that the SPS are a voluntary market practice. Does not itself list CH17 or its meaning." } ] }, "rail_name": "Swiss Payment Standards Status Report Reasons", "governing_authority": "SIX Interbank Clearing (Swiss Payment Standards)", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "judgement", "label": "your bank's own terms", "needs": "whose terms decide it: the bank's, the participant's or the scheme's", "detail": "A bank may answer with any ISO status reason, with NARR plus its own text, or with a proprietary code, and handles faulty orders under its own customer terms (BR v3.2 section 1.4.2; IG-SR v2.1 section 3.2.4).", "from": "caveat" } ] }, { "uid": "ch-sps-status:CH19", "id": "CH19", "rail": "ch-sps-status", "kind": "reason-code", "name": "Dates moved to the next business or TARGET day (SEPA DD)", "group": "technical", "summary": "The bank moved the settlement and collection date of a SEPA direct debit to the next possible banking or TARGET day, because the order came too late for the date requested. The collection goes ahead on the later date.", "triggers": [ "A SEPA direct debit that misses the delivery deadline agreed with the bank, where the bank moves the date rather than rejecting the group (SDD IG v2.7 element 2.18)" ], "actions": [ "Book the later collection date as the expected cash date", "Check whether the new date still fits the pre-notification given to the debtor, and tell the debtor if not [Inference]", "Send future collections earlier" ], "retry": { "allowed": false, "rule": "Nothing to resend: the collection is kept and moved to a later date. Sending it again would collect twice [Inference]." }, "facts": { "return_windows": [ { "action": "send this reason in a pain.002 status report on the submitted order", "by": "the submitter's Swiss financial institution", "deadline": "None applies. A status report is the bank's answer to a submitted message, not a return, so no return window exists. The SPS expect an immediate reply but set no time limit, and cut-offs and error handling belong to each bank's own offer (IG-SR v2.1 section 3.1.1; BR v3.2 section 1.4.2)." } ], "applies_to": "Swiss Payment Standards customer-to-bank status report (pain.002), on SEPA direct debit (pain.008) submissions only; Table 10 shades it grey and its entry names SEPA direct debit; B level." }, "caveat": "The SEPA direct debit guide lets a bank either move the date or reject the payment group, and names CH03, CH04, CH19 and DT06 for that element without saying which case uses which; reading CH19 as the moved-date notice follows its Table 10 description [Inference]. The status is presumably ACWC, accepted with change [Inference from IG-SR v2.1 Table 5]. The SPS are a voluntary market practice. A bank may answer with any ISO status reason, with NARR plus its own text, or with a proprietary code, and handles faulty orders under its own customer terms (BR v3.2 section 1.4.2; IG-SR v2.1 section 3.2.4).", "related": [ "ch-sps-status:DT06", "ch-sps-status:CH03", "ch-sps-status:CH04" ], "basis": { "sources": "SPS Implementation Guidelines Status Report (pain.002) v2.1 of 2024-02-20, SPS 2024 (IG-SR v2.1) sections 3.1.1, 3.2.3 and 3.2.4 Table 10 (payment-type shading read from the rendered page), Annex B Table 21; SPS Implementation Guidelines SEPA Direct Debit (pain.008) v2.7, SPS 2021 (SDD IG v2.7) section 2.2, error code column; IG-SR v2.1 section 3.1.2 Table 5; SPS Business Rules v3.2, SPS 2025 (BR v3.2) section 1.4.2; IG-SR v2.2 of 2026-02-20, SPS 2026, section 3.2.4 Table 10 (unchanged).", "confidence": "medium" }, "currency": { "effective_since": "2024-11-18", "effective_note": "IG-SR v2.1 (SPS 2024) applies from 2024-11-18 and is still the current pain.002 guide under SPS 2025, because SIX has published no SPS 2025 edition of it [Inference from the SIX download center, read 2026-09-18]. IG-SR v2.2 (SPS 2026, dated 2026-02-20) applies from 2026-11-14 and keeps this code in Table 10 with the same meaning and the same payment-type shading; that edition changes only tracker data and the status sequence annex. The SPS 2021 guide (v1.1.2, from 2021-11-19) also lists it and governs 2009-schema submissions until the November 2026 release. Use of the code before 2024-11-18 is not dated here [Unverified].", "source_edition": "IG-SR v2.1 (SPS 2024); IG-SR v2.2 (SPS 2026); SDD IG v2.7 (SPS 2021); BR v3.2 (SPS 2025)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.six-group.com/dam/download/banking-services/standardization/sps/ig-status-report-sps2024-en.pdf", "source_class": "authoritative_primary", "source_title": "SPS Implementation Guidelines, Status Report (pain.002), SPS 2024, version 2.1, dated 2024-02-20, in force from 2024-11-18", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms CH19 is listed in Table 10 of the Status Report implementation guidelines with a meaning matching the record's summary, and Table 10 shades it gray with wording naming SEPA Direct Debit, meaning it is valid for SEPA direct debit submissions only. Table 10 is identical on this point in the v2.2 edition (SPS 2026, dated 2026-02-20, in force from 2026-11-14). Does not address triggers, actions or retry detail beyond the table entry." }, { "source_url": "https://www.six-group.com/dam/download/banking-services/standardization/sps/business-rules-sps-2025-en.pdf", "source_class": "authoritative_primary", "source_title": "SPS Business Rules for Payments and Cash Management, SPS 2025, version 3.2, dated 2025-02-24, in force from 2025-11-22", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms SPS Business Rules section 1.4.2 leaves cut-off times and the handling of erroneous orders and status reporting to each financial institution's own customer offering, rather than to the Swiss Payment Standards. Supports the CH19 record's return_windows claim that no SPS-wide deadline applies to sending this status reason, and supports the caveat that the SPS are a voluntary market practice. Does not itself list CH19 or its meaning." } ] }, "rail_name": "Swiss Payment Standards Status Report Reasons", "governing_authority": "SIX Interbank Clearing (Swiss Payment Standards)", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "judgement", "label": "your bank's own terms", "needs": "whose terms decide it: the bank's, the participant's or the scheme's", "detail": "A bank may answer with any ISO status reason, with NARR plus its own text, or with a proprietary code, and handles faulty orders under its own customer terms (BR v3.2 section 1.4.2; IG-SR v2.1 section 3.2.4).", "from": "caveat" } ] }, { "uid": "ch-sps-status:CH20", "id": "CH20", "rail": "ch-sps-status", "kind": "reason-code", "name": "Too many decimal places for the currency", "group": "technical", "summary": "The amount has more decimal places than its currency allows. The transaction is rejected.", "triggers": [ "An instructed or equivalent amount with more decimals than the currency permits (CT IG v2.2 sections 3.7 and 4.3)", "Amounts computed in the source system, such as with a foreign exchange conversion, and not rounded before export [Inference]" ], "actions": [ "Round to the currency's minor unit before export", "Send the corrected transaction again in a new message" ], "retry": { "allowed": true, "rule": "A rejected order stays rejected: RJCT is a final status (IG-SR v2.1 Annex B, Table 21). Fix the cause and send the payment again in a new message. Give that message a new Message Identification, because most Swiss banks check it for duplicates over at least 90 days (CT IG v2.2 section 3.8). The SPS set no retry limit." }, "facts": { "return_windows": [ { "action": "send this reason in a pain.002 status report on the submitted order", "by": "the submitter's Swiss financial institution", "deadline": "None applies. A status report is the bank's answer to a submitted message, not a return, so no return window exists. The SPS expect an immediate reply but set no time limit, and cut-offs and error handling belong to each bank's own offer (IG-SR v2.1 section 3.1.1; BR v3.2 section 1.4.2)." } ], "applies_to": "Swiss Payment Standards customer-to-bank status report (pain.002), on credit transfer (pain.001) and direct debit (pain.008) submissions; C level." }, "caveat": "The SPS are a voluntary market practice. A bank may answer with any ISO status reason, with NARR plus its own text, or with a proprietary code, and handles faulty orders under its own customer terms (BR v3.2 section 1.4.2; IG-SR v2.1 section 3.2.4).", "related": [ "ch-sps-status:AM02", "ch-sps-status:AM03", "ch-sps-status:CURR" ], "basis": { "sources": "SPS Implementation Guidelines Status Report (pain.002) v2.1 of 2024-02-20, SPS 2024 (IG-SR v2.1) sections 3.1.1, 3.2.3 and 3.2.4 Table 10 (payment-type shading read from the rendered page), Annex B Table 21; SPS Implementation Guidelines Credit Transfer (pain.001) v2.2 of 2025-02-24, SPS 2025 (CT IG v2.2) chapter 4, error code column of the element tables; Implementation Guidelines Swiss Direct Debits (pain.008) v1.2 of 2018-04-06 (CH-DD IG v1.2) section 2.2, error code column; SPS Business Rules v3.2, SPS 2025 (BR v3.2) section 1.4.2; IG-SR v2.2 of 2026-02-20, SPS 2026, section 3.2.4 Table 10 (unchanged).", "confidence": "high" }, "currency": { "effective_since": "2024-11-18", "effective_note": "IG-SR v2.1 (SPS 2024) applies from 2024-11-18 and is still the current pain.002 guide under SPS 2025, because SIX has published no SPS 2025 edition of it [Inference from the SIX download center, read 2026-09-18]. IG-SR v2.2 (SPS 2026, dated 2026-02-20) applies from 2026-11-14 and keeps this code in Table 10 with the same meaning and the same payment-type shading; that edition changes only tracker data and the status sequence annex. The SPS 2021 guide (v1.1.2, from 2021-11-19) also lists it and governs 2009-schema submissions until the November 2026 release. Use of the code before 2024-11-18 is not dated here [Unverified].", "source_edition": "IG-SR v2.1 (SPS 2024); IG-SR v2.2 (SPS 2026); CT IG v2.2 (SPS 2025); CH-DD IG v1.2 (2018); BR v3.2 (SPS 2025)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.six-group.com/dam/download/banking-services/standardization/sps/ig-status-report-sps2024-en.pdf", "source_class": "authoritative_primary", "source_title": "SPS Implementation Guidelines, Status Report (pain.002), SPS 2024, version 2.1, dated 2024-02-20, in force from 2024-11-18", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms CH20 is listed in Table 10 of the Status Report implementation guidelines with a meaning matching the record's summary, and Table 10 leaves it unshaded, meaning it is valid for both credit transfer and direct debit submissions. Table 10 is identical on this point in the v2.2 edition (SPS 2026, dated 2026-02-20, in force from 2026-11-14). Does not address triggers, actions or retry detail beyond the table entry." }, { "source_url": "https://www.six-group.com/dam/download/banking-services/standardization/sps/business-rules-sps-2025-en.pdf", "source_class": "authoritative_primary", "source_title": "SPS Business Rules for Payments and Cash Management, SPS 2025, version 3.2, dated 2025-02-24, in force from 2025-11-22", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms SPS Business Rules section 1.4.2 leaves cut-off times and the handling of erroneous orders and status reporting to each financial institution's own customer offering, rather than to the Swiss Payment Standards. Supports the CH20 record's return_windows claim that no SPS-wide deadline applies to sending this status reason, and supports the caveat that the SPS are a voluntary market practice. Does not itself list CH20 or its meaning." } ] }, "rail_name": "Swiss Payment Standards Status Report Reasons", "governing_authority": "SIX Interbank Clearing (Swiss Payment Standards)", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "judgement", "label": "your bank's own terms", "needs": "whose terms decide it: the bank's, the participant's or the scheme's", "detail": "A bank may answer with any ISO status reason, with NARR plus its own text, or with a proprietary code, and handles faulty orders under its own customer terms (BR v3.2 section 1.4.2; IG-SR v2.1 section 3.2.4).", "from": "caveat" } ] }, { "uid": "ch-sps-status:CH21", "id": "CH21", "rail": "ch-sps-status", "kind": "reason-code", "name": "Mandatory data absent", "group": "technical", "summary": "An element that is mandatory, or mandatory in this situation, is missing or empty. Because the element is absent, the status report cannot echo it; the bank normally names it in the additional information text.", "triggers": [ "An element required for the payment type, or required because of another element, absent or empty (CT IG v2.2 chapter 4; IG-SR v2.1 section 3.2.2)", "Address details the guide requires, such as the creditor's town or country (CT IG v2.2 section 4.3)", "The same in a Swiss direct debit pain.008 (CH-DD IG v1.2)" ], "actions": [ "Read the additional information text for the missing element (IG-SR v2.1 section 3.2.2)", "Fill the element in the source data and send the corrected part again in a new message" ], "retry": { "allowed": true, "rule": "A rejected order stays rejected: RJCT is a final status (IG-SR v2.1 Annex B, Table 21). Fix the cause and send the payment again in a new message. Give that message a new Message Identification, because most Swiss banks check it for duplicates over at least 90 days (CT IG v2.2 section 3.8). The SPS set no retry limit." }, "facts": { "return_windows": [ { "action": "send this reason in a pain.002 status report on the submitted order", "by": "the submitter's Swiss financial institution", "deadline": "None applies. A status report is the bank's answer to a submitted message, not a return, so no return window exists. The SPS expect an immediate reply but set no time limit, and cut-offs and error handling belong to each bank's own offer (IG-SR v2.1 section 3.1.1; BR v3.2 section 1.4.2)." } ], "applies_to": "Swiss Payment Standards customer-to-bank status report (pain.002), on credit transfer (pain.001) and direct debit (pain.008) submissions." }, "caveat": "The guide says a missing, empty or pattern-breaking mandatory element is reported as either FF01 or CH21 (IG-SR v2.1 section 3.2.2), so the same fault can arrive under either code. The SPS are a voluntary market practice. A bank may answer with any ISO status reason, with NARR plus its own text, or with a proprietary code, and handles faulty orders under its own customer terms (BR v3.2 section 1.4.2; IG-SR v2.1 section 3.2.4).", "related": [ "ch-sps-status:CH16", "ch-sps-status:CH17", "ch-sps-status:FF01", "ch-sps-status:BE11" ], "basis": { "sources": "SPS Implementation Guidelines Status Report (pain.002) v2.1 of 2024-02-20, SPS 2024 (IG-SR v2.1) sections 3.1.1, 3.2.3 and 3.2.4 Table 10 (payment-type shading read from the rendered page), Annex B Table 21; SPS Implementation Guidelines Credit Transfer (pain.001) v2.2 of 2025-02-24, SPS 2025 (CT IG v2.2) chapter 4, error code column of the element tables; Implementation Guidelines Swiss Direct Debits (pain.008) v1.2 of 2018-04-06 (CH-DD IG v1.2) section 2.2, error code column; IG-SR v2.1 section 3.2.2; SPS Business Rules v3.2, SPS 2025 (BR v3.2) section 1.4.2; IG-SR v2.2 of 2026-02-20, SPS 2026, section 3.2.4 Table 10 (unchanged).", "confidence": "high" }, "currency": { "effective_since": "2024-11-18", "effective_note": "IG-SR v2.1 (SPS 2024) applies from 2024-11-18 and is still the current pain.002 guide under SPS 2025, because SIX has published no SPS 2025 edition of it [Inference from the SIX download center, read 2026-09-18]. IG-SR v2.2 (SPS 2026, dated 2026-02-20) applies from 2026-11-14 and keeps this code in Table 10 with the same meaning and the same payment-type shading; that edition changes only tracker data and the status sequence annex. The SPS 2021 guide (v1.1.2, from 2021-11-19) also lists it and governs 2009-schema submissions until the November 2026 release. Use of the code before 2024-11-18 is not dated here [Unverified].", "source_edition": "IG-SR v2.1 (SPS 2024); IG-SR v2.2 (SPS 2026); CT IG v2.2 (SPS 2025); CH-DD IG v1.2 (2018); BR v3.2 (SPS 2025)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.six-group.com/dam/download/banking-services/standardization/sps/ig-status-report-sps2024-en.pdf", "source_class": "authoritative_primary", "source_title": "SPS Implementation Guidelines, Status Report (pain.002), SPS 2024, version 2.1, dated 2024-02-20, in force from 2024-11-18", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms CH21 is listed in Table 10 of the Status Report implementation guidelines with a meaning matching the record's summary, and Table 10 leaves it unshaded, meaning it is valid for both credit transfer and direct debit submissions. Table 10 is identical on this point in the v2.2 edition (SPS 2026, dated 2026-02-20, in force from 2026-11-14). Does not address triggers, actions or retry detail beyond the table entry." }, { "source_url": "https://www.six-group.com/dam/download/banking-services/standardization/sps/business-rules-sps-2025-en.pdf", "source_class": "authoritative_primary", "source_title": "SPS Business Rules for Payments and Cash Management, SPS 2025, version 3.2, dated 2025-02-24, in force from 2025-11-22", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms SPS Business Rules section 1.4.2 leaves cut-off times and the handling of erroneous orders and status reporting to each financial institution's own customer offering, rather than to the Swiss Payment Standards. Supports the CH21 record's return_windows claim that no SPS-wide deadline applies to sending this status reason, and supports the caveat that the SPS are a voluntary market practice. Does not itself list CH21 or its meaning." } ] }, "rail_name": "Swiss Payment Standards Status Report Reasons", "governing_authority": "SIX Interbank Clearing (Swiss Payment Standards)", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "judgement", "label": "your bank's own terms", "needs": "whose terms decide it: the bank's, the participant's or the scheme's", "detail": "A bank may answer with any ISO status reason, with NARR plus its own text, or with a proprietary code, and handles faulty orders under its own customer terms (BR v3.2 section 1.4.2; IG-SR v2.1 section 3.2.4).", "from": "caveat" } ] }, { "uid": "ch-sps-status:CH22", "id": "CH22", "rail": "ch-sps-status", "kind": "reason-code", "name": "SDD Core and B2B mixed in one message", "group": "technical", "summary": "A SEPA direct debit message mixes Core and B2B collections. Table 10 limits this code to SEPA direct debits, and the whole message is rejected.", "triggers": [ "Different local instrument values, CORE and B2B, within one pain.008 (SDD IG v2.7, local instrument)" ], "actions": [ "Send Core and B2B collections in separate messages", "Send the whole message again, split by scheme, with new Message Identifications" ], "retry": { "allowed": true, "rule": "A rejected order stays rejected: RJCT is a final status (IG-SR v2.1 Annex B, Table 21). Fix the cause and send the payment again in a new message. Give that message a new Message Identification, because most Swiss banks check it for duplicates over at least 90 days (CT IG v2.2 section 3.8). The SPS set no retry limit." }, "facts": { "return_windows": [ { "action": "send this reason in a pain.002 status report on the submitted order", "by": "the submitter's Swiss financial institution", "deadline": "None applies. A status report is the bank's answer to a submitted message, not a return, so no return window exists. The SPS expect an immediate reply but set no time limit, and cut-offs and error handling belong to each bank's own offer (IG-SR v2.1 section 3.1.1; BR v3.2 section 1.4.2)." } ], "applies_to": "Swiss Payment Standards customer-to-bank status report (pain.002), on SEPA direct debit (pain.008) submissions only; Table 10 shades it grey and its entry names SEPA direct debit; A level: the whole message is rejected." }, "caveat": "The SPS are a voluntary market practice. A bank may answer with any ISO status reason, with NARR plus its own text, or with a proprietary code, and handles faulty orders under its own customer terms (BR v3.2 section 1.4.2; IG-SR v2.1 section 3.2.4).", "related": [ "ch-sps-status:CH12", "ch-sps-status:FF01" ], "basis": { "sources": "SPS Implementation Guidelines Status Report (pain.002) v2.1 of 2024-02-20, SPS 2024 (IG-SR v2.1) sections 3.1.1, 3.2.3 and 3.2.4 Table 10 (payment-type shading read from the rendered page), Annex B Table 21; SPS Implementation Guidelines SEPA Direct Debit (pain.008) v2.7, SPS 2021 (SDD IG v2.7) section 2.2, error code column; SPS Implementation Guidelines Credit Transfer (pain.001) v2.2 of 2025-02-24, SPS 2025 (CT IG v2.2) section 3.8; SPS Business Rules v3.2, SPS 2025 (BR v3.2) section 1.4.2; IG-SR v2.2 of 2026-02-20, SPS 2026, section 3.2.4 Table 10 (unchanged).", "confidence": "high" }, "currency": { "effective_since": "2024-11-18", "effective_note": "IG-SR v2.1 (SPS 2024) applies from 2024-11-18 and is still the current pain.002 guide under SPS 2025, because SIX has published no SPS 2025 edition of it [Inference from the SIX download center, read 2026-09-18]. IG-SR v2.2 (SPS 2026, dated 2026-02-20) applies from 2026-11-14 and keeps this code in Table 10 with the same meaning and the same payment-type shading; that edition changes only tracker data and the status sequence annex. The SPS 2021 guide (v1.1.2, from 2021-11-19) also lists it and governs 2009-schema submissions until the November 2026 release. Use of the code before 2024-11-18 is not dated here [Unverified].", "source_edition": "IG-SR v2.1 (SPS 2024); IG-SR v2.2 (SPS 2026); SDD IG v2.7 (SPS 2021); BR v3.2 (SPS 2025); CT IG v2.2 (SPS 2025)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.six-group.com/dam/download/banking-services/standardization/sps/ig-status-report-sps2024-en.pdf", "source_class": "authoritative_primary", "source_title": "SPS Implementation Guidelines, Status Report (pain.002), SPS 2024, version 2.1, dated 2024-02-20, in force from 2024-11-18", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms CH22 is listed in Table 10 of the Status Report implementation guidelines with a meaning matching the record's summary, and Table 10 shades it gray with wording naming SEPA Direct Debit, meaning it is valid for SEPA direct debit submissions only. Table 10 is identical on this point in the v2.2 edition (SPS 2026, dated 2026-02-20, in force from 2026-11-14). Does not address triggers, actions or retry detail beyond the table entry." }, { "source_url": "https://www.six-group.com/dam/download/banking-services/standardization/sps/business-rules-sps-2025-en.pdf", "source_class": "authoritative_primary", "source_title": "SPS Business Rules for Payments and Cash Management, SPS 2025, version 3.2, dated 2025-02-24, in force from 2025-11-22", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms SPS Business Rules section 1.4.2 leaves cut-off times and the handling of erroneous orders and status reporting to each financial institution's own customer offering, rather than to the Swiss Payment Standards. Supports the CH22 record's return_windows claim that no SPS-wide deadline applies to sending this status reason, and supports the caveat that the SPS are a voluntary market practice. Does not itself list CH22 or its meaning." } ] }, "rail_name": "Swiss Payment Standards Status Report Reasons", "governing_authority": "SIX Interbank Clearing (Swiss Payment Standards)", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "judgement", "label": "your bank's own terms", "needs": "whose terms decide it: the bank's, the participant's or the scheme's", "detail": "A bank may answer with any ISO status reason, with NARR plus its own text, or with a proprietary code, and handles faulty orders under its own customer terms (BR v3.2 section 1.4.2; IG-SR v2.1 section 3.2.4).", "from": "caveat" } ] }, { "uid": "ch-sps-status:CURR", "id": "CURR", "rail": "ch-sps-status", "kind": "reason-code", "name": "Currency wrong", "group": "technical", "summary": "A currency in the order is wrong for where it is used, for example the currency of the amount or the unit currency of an exchange rate.", "triggers": [ "An amount currency the payment type does not allow; the guide maps this element to both CURR and AM03 (CT IG v2.2 section 4.3)", "A wrong unit currency in the exchange rate information (CT IG v2.2 section 4.3)" ], "actions": [ "Check the currency against the payment type and any exchange rate contract details", "Send the corrected transaction again in a new message" ], "retry": { "allowed": true, "rule": "A rejected order stays rejected: RJCT is a final status (IG-SR v2.1 Annex B, Table 21). Fix the cause and send the payment again in a new message. Give that message a new Message Identification, because most Swiss banks check it for duplicates over at least 90 days (CT IG v2.2 section 3.8). The SPS set no retry limit." }, "facts": { "return_windows": [ { "action": "send this reason in a pain.002 status report on the submitted order", "by": "the submitter's Swiss financial institution", "deadline": "None applies. A status report is the bank's answer to a submitted message, not a return, so no return window exists. The SPS expect an immediate reply but set no time limit, and cut-offs and error handling belong to each bank's own offer (IG-SR v2.1 section 3.1.1; BR v3.2 section 1.4.2)." } ], "applies_to": "Swiss Payment Standards customer-to-bank status report (pain.002), on credit transfer (pain.001) and direct debit (pain.008) submissions; C level." }, "caveat": "The SPS do not separate CURR from AM03, so banks may differ in which they send for the same fault [Inference]. The SPS are a voluntary market practice. A bank may answer with any ISO status reason, with NARR plus its own text, or with a proprietary code, and handles faulty orders under its own customer terms (BR v3.2 section 1.4.2; IG-SR v2.1 section 3.2.4).", "related": [ "ch-sps-status:AM03", "ch-sps-status:AM02", "ch-sps-status:CH20" ], "basis": { "sources": "SPS Implementation Guidelines Status Report (pain.002) v2.1 of 2024-02-20, SPS 2024 (IG-SR v2.1) sections 3.1.1, 3.2.3 and 3.2.4 Table 10 (payment-type shading read from the rendered page), Annex B Table 21; SPS Implementation Guidelines Credit Transfer (pain.001) v2.2 of 2025-02-24, SPS 2025 (CT IG v2.2) chapter 4, error code column of the element tables; SPS Business Rules v3.2, SPS 2025 (BR v3.2) section 1.4.2; IG-SR v2.2 of 2026-02-20, SPS 2026, section 3.2.4 Table 10 (unchanged).", "confidence": "medium" }, "currency": { "effective_since": "2024-11-18", "effective_note": "IG-SR v2.1 (SPS 2024) applies from 2024-11-18 and is still the current pain.002 guide under SPS 2025, because SIX has published no SPS 2025 edition of it [Inference from the SIX download center, read 2026-09-18]. IG-SR v2.2 (SPS 2026, dated 2026-02-20) applies from 2026-11-14 and keeps this code in Table 10 with the same meaning and the same payment-type shading; that edition changes only tracker data and the status sequence annex. The SPS 2021 guide (v1.1.2, from 2021-11-19) also lists it and governs 2009-schema submissions until the November 2026 release. Use of the code before 2024-11-18 is not dated here [Unverified].", "source_edition": "IG-SR v2.1 (SPS 2024); IG-SR v2.2 (SPS 2026); CT IG v2.2 (SPS 2025); BR v3.2 (SPS 2025)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.six-group.com/dam/download/banking-services/standardization/sps/ig-status-report-sps2024-en.pdf", "source_class": "authoritative_primary", "source_title": "SPS Implementation Guidelines, Status Report (pain.002), SPS 2024, version 2.1, dated 2024-02-20, in force from 2024-11-18", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms CURR is listed in Table 10 of the Status Report implementation guidelines with a meaning matching the record's summary, and Table 10 leaves it unshaded, meaning it is valid for both credit transfer and direct debit submissions. Table 10 is identical on this point in the v2.2 edition (SPS 2026, dated 2026-02-20, in force from 2026-11-14). Does not address triggers, actions or retry detail beyond the table entry." }, { "source_url": "https://www.six-group.com/dam/download/banking-services/standardization/sps/business-rules-sps-2025-en.pdf", "source_class": "authoritative_primary", "source_title": "SPS Business Rules for Payments and Cash Management, SPS 2025, version 3.2, dated 2025-02-24, in force from 2025-11-22", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms SPS Business Rules section 1.4.2 leaves cut-off times and the handling of erroneous orders and status reporting to each financial institution's own customer offering, rather than to the Swiss Payment Standards. Supports the CURR record's return_windows claim that no SPS-wide deadline applies to sending this status reason, and supports the caveat that the SPS are a voluntary market practice. Does not itself list CURR or its meaning." } ] }, "rail_name": "Swiss Payment Standards Status Report Reasons", "governing_authority": "SIX Interbank Clearing (Swiss Payment Standards)", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "judgement", "label": "your bank's own terms", "needs": "whose terms decide it: the bank's, the participant's or the scheme's", "detail": "A bank may answer with any ISO status reason, with NARR plus its own text, or with a proprietary code, and handles faulty orders under its own customer terms (BR v3.2 section 1.4.2; IG-SR v2.1 section 3.2.4).", "from": "caveat" } ] }, { "uid": "ch-sps-status:CUST", "id": "CUST", "rail": "ch-sps-status", "kind": "reason-code", "name": "Order withdrawn by the debtor", "group": "administrative", "summary": "The order was not carried out because the customer who gave it cancelled it. It reports a customer decision, not a data error. Added to the Swiss list after SPS 2021.", "triggers": [ "The debtor, or someone authorised on the account, deletes or refuses to release a submitted order before execution [Inference: the SPS allow later status reports on releases, deletions and execution as an optional service, IG-SR v2.1 section 3.1.1]" ], "actions": [ "Check internally who cancelled and why before doing anything else", "Do not resend automatically; if the payment is still due, send it as a new order" ], "retry": { "allowed": true, "rule": "Only after the organisation confirms the payment is wanted. Send it as a new order in a new message. The SPS set no retry limit." }, "facts": { "return_windows": [ { "action": "send this reason in a pain.002 status report on the submitted order", "by": "the submitter's Swiss financial institution", "deadline": "None applies. A status report is the bank's answer to a submitted message, not a return, so no return window exists. The SPS expect an immediate reply but set no time limit, and cut-offs and error handling belong to each bank's own offer (IG-SR v2.1 section 3.1.1; BR v3.2 section 1.4.2)." } ], "applies_to": "Swiss Payment Standards customer-to-bank status report (pain.002), on credit transfer (pain.001) and direct debit (pain.008) submissions." }, "caveat": "The same letters mean something different in Swiss interbank messages: a customer's return request, a refusal by the payee, or a return at the original payee's request [Unverified: taken from the approved ch-sic rail brief; the SIC module documents were not read in this drafting pass]. Do not read this pain.002 code with those meanings. The SPS are a voluntary market practice. A bank may answer with any ISO status reason, with NARR plus its own text, or with a proprietary code, and handles faulty orders under its own customer terms (BR v3.2 section 1.4.2; IG-SR v2.1 section 3.2.4).", "related": [ "ch-sps-status:MS03" ], "basis": { "sources": "SPS Implementation Guidelines Status Report (pain.002) v2.1 of 2024-02-20, SPS 2024 (IG-SR v2.1) sections 3.1.1, 3.2.3 and 3.2.4 Table 10 (payment-type shading read from the rendered page), Annex B Table 21; IG-SR v2.1 section 3.1.1 (additional status reports as an optional service); SPS Business Rules v3.2, SPS 2025 (BR v3.2) section 1.4.2; IG-SR v2.2 of 2026-02-20, SPS 2026, section 3.2.4 Table 10 (unchanged).", "confidence": "medium" }, "currency": { "effective_since": "2024-11-18", "effective_note": "IG-SR v2.1 (SPS 2024) applies from 2024-11-18 and is still the current pain.002 guide under SPS 2025, because SIX has published no SPS 2025 edition of it [Inference from the SIX download center, read 2026-09-18]. IG-SR v2.2 (SPS 2026, dated 2026-02-20) applies from 2026-11-14 and keeps this code in Table 10 with the same meaning and the same payment-type shading; that edition changes only tracker data and the status sequence annex. The code is absent from the SPS 2021 guide (v1.1.2), which still governs 2009-schema submissions until the November 2026 release. Use of the code before 2024-11-18 is not dated here [Unverified].", "source_edition": "IG-SR v2.1 (SPS 2024); IG-SR v2.2 (SPS 2026); BR v3.2 (SPS 2025)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.six-group.com/dam/download/banking-services/standardization/sps/ig-status-report-sps2024-en.pdf", "source_class": "authoritative_primary", "source_title": "SPS Implementation Guidelines, Status Report (pain.002), SPS 2024, version 2.1, dated 2024-02-20, in force from 2024-11-18", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms CUST is listed in Table 10 of the Status Report implementation guidelines with a meaning matching the record's summary, and Table 10 leaves it unshaded, meaning it is valid for both credit transfer and direct debit submissions. Table 10 is identical on this point in the v2.2 edition (SPS 2026, dated 2026-02-20, in force from 2026-11-14). Does not address triggers, actions or retry detail beyond the table entry." }, { "source_url": "https://www.six-group.com/dam/download/banking-services/standardization/sps/business-rules-sps-2025-en.pdf", "source_class": "authoritative_primary", "source_title": "SPS Business Rules for Payments and Cash Management, SPS 2025, version 3.2, dated 2025-02-24, in force from 2025-11-22", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms SPS Business Rules section 1.4.2 leaves cut-off times and the handling of erroneous orders and status reporting to each financial institution's own customer offering, rather than to the Swiss Payment Standards. Supports the CUST record's return_windows claim that no SPS-wide deadline applies to sending this status reason, and supports the caveat that the SPS are a voluntary market practice. Does not itself list CUST or its meaning." } ] }, "rail_name": "Swiss Payment Standards Status Report Reasons", "governing_authority": "SIX Interbank Clearing (Swiss Payment Standards)", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "judgement", "label": "your bank's own terms", "needs": "whose terms decide it: the bank's, the participant's or the scheme's", "detail": "A bank may answer with any ISO status reason, with NARR plus its own text, or with a proprietary code, and handles faulty orders under its own customer terms (BR v3.2 section 1.4.2; IG-SR v2.1 section 3.2.4).", "from": "caveat" } ] }, { "uid": "ch-sps-status:DT01", "id": "DT01", "rail": "ch-sps-status", "kind": "reason-code", "name": "Unusable date", "group": "technical", "summary": "A date in the order is not a valid date, such as the creation date and time or the requested execution or collection date.", "triggers": [ "An invalid creation date and time in the group header (CT IG v2.2 section 4.1)", "An invalid requested execution date (CT IG v2.2 section 4.2) or requested collection date (CH-DD IG v1.2 element 2.18)" ], "actions": [ "Check the date format and the payment software's date handling", "A date that is valid but falls on a holiday is normally moved and reported with DT06 instead [Inference]", "Send the corrected part again in a new message" ], "retry": { "allowed": true, "rule": "A rejected order stays rejected: RJCT is a final status (IG-SR v2.1 Annex B, Table 21). Fix the cause and send the payment again in a new message. Give that message a new Message Identification, because most Swiss banks check it for duplicates over at least 90 days (CT IG v2.2 section 3.8). The SPS set no retry limit." }, "facts": { "return_windows": [ { "action": "send this reason in a pain.002 status report on the submitted order", "by": "the submitter's Swiss financial institution", "deadline": "None applies. A status report is the bank's answer to a submitted message, not a return, so no return window exists. The SPS expect an immediate reply but set no time limit, and cut-offs and error handling belong to each bank's own offer (IG-SR v2.1 section 3.1.1; BR v3.2 section 1.4.2)." } ], "applies_to": "Swiss Payment Standards customer-to-bank status report (pain.002), on credit transfer (pain.001) and direct debit (pain.008) submissions." }, "caveat": "The SPS are a voluntary market practice. A bank may answer with any ISO status reason, with NARR plus its own text, or with a proprietary code, and handles faulty orders under its own customer terms (BR v3.2 section 1.4.2; IG-SR v2.1 section 3.2.4).", "related": [ "ch-sps-status:CH03", "ch-sps-status:CH04", "ch-sps-status:DT06" ], "basis": { "sources": "SPS Implementation Guidelines Status Report (pain.002) v2.1 of 2024-02-20, SPS 2024 (IG-SR v2.1) sections 3.1.1, 3.2.3 and 3.2.4 Table 10 (payment-type shading read from the rendered page), Annex B Table 21; SPS Implementation Guidelines Credit Transfer (pain.001) v2.2 of 2025-02-24, SPS 2025 (CT IG v2.2) chapter 4, error code column of the element tables; Implementation Guidelines Swiss Direct Debits (pain.008) v1.2 of 2018-04-06 (CH-DD IG v1.2) section 2.2, error code column; SPS Business Rules v3.2, SPS 2025 (BR v3.2) section 1.4.2; IG-SR v2.2 of 2026-02-20, SPS 2026, section 3.2.4 Table 10 (unchanged).", "confidence": "high" }, "currency": { "effective_since": "2024-11-18", "effective_note": "IG-SR v2.1 (SPS 2024) applies from 2024-11-18 and is still the current pain.002 guide under SPS 2025, because SIX has published no SPS 2025 edition of it [Inference from the SIX download center, read 2026-09-18]. IG-SR v2.2 (SPS 2026, dated 2026-02-20) applies from 2026-11-14 and keeps this code in Table 10 with the same meaning and the same payment-type shading; that edition changes only tracker data and the status sequence annex. The SPS 2021 guide (v1.1.2, from 2021-11-19) also lists it and governs 2009-schema submissions until the November 2026 release. Use of the code before 2024-11-18 is not dated here [Unverified].", "source_edition": "IG-SR v2.1 (SPS 2024); IG-SR v2.2 (SPS 2026); CT IG v2.2 (SPS 2025); CH-DD IG v1.2 (2018); BR v3.2 (SPS 2025)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.six-group.com/dam/download/banking-services/standardization/sps/ig-status-report-sps2024-en.pdf", "source_class": "authoritative_primary", "source_title": "SPS Implementation Guidelines, Status Report (pain.002), SPS 2024, version 2.1, dated 2024-02-20, in force from 2024-11-18", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms DT01 is listed in Table 10 of the Status Report implementation guidelines with a meaning matching the record's summary, and Table 10 leaves it unshaded, meaning it is valid for both credit transfer and direct debit submissions. Table 10 is identical on this point in the v2.2 edition (SPS 2026, dated 2026-02-20, in force from 2026-11-14). Does not address triggers, actions or retry detail beyond the table entry." }, { "source_url": "https://www.six-group.com/dam/download/banking-services/standardization/sps/business-rules-sps-2025-en.pdf", "source_class": "authoritative_primary", "source_title": "SPS Business Rules for Payments and Cash Management, SPS 2025, version 3.2, dated 2025-02-24, in force from 2025-11-22", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms SPS Business Rules section 1.4.2 leaves cut-off times and the handling of erroneous orders and status reporting to each financial institution's own customer offering, rather than to the Swiss Payment Standards. Supports the DT01 record's return_windows claim that no SPS-wide deadline applies to sending this status reason, and supports the caveat that the SPS are a voluntary market practice. Does not itself list DT01 or its meaning." } ] }, "rail_name": "Swiss Payment Standards Status Report Reasons", "governing_authority": "SIX Interbank Clearing (Swiss Payment Standards)", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "judgement", "label": "your bank's own terms", "needs": "whose terms decide it: the bank's, the participant's or the scheme's", "detail": "A bank may answer with any ISO status reason, with NARR plus its own text, or with a proprietary code, and handles faulty orders under its own customer terms (BR v3.2 section 1.4.2; IG-SR v2.1 section 3.2.4).", "from": "caveat" } ] }, { "uid": "ch-sps-status:DT06", "id": "DT06", "rail": "ch-sps-status", "kind": "reason-code", "name": "Execution date moved (information only)", "group": "technical", "summary": "Information, not a rejection: the bank moved the execution date to the next possible banking or Post Office business day. The payment still goes out, on the later date.", "triggers": [ "A requested execution date the bank cannot meet, for example one that is not a banking or Post Office business day, which the bank moves forward (CT IG v2.2 section 4.2); a late delivery after cut-off may have the same effect [Inference]", "A direct debit sent too late for its date, where the bank moves the processing date (CH-DD IG v1.2 element 2.18; SDD IG v2.7 element 2.18)" ], "actions": [ "Update the expected debit or collection date in cash management", "Where a payment must arrive by a fixed date, send it earlier or use an instant payment where the bank offers one [Inference]" ], "retry": { "allowed": false, "rule": "Nothing to resend: the order is kept and executed later. Sending it again would pay twice [Inference]." }, "facts": { "return_windows": [ { "action": "send this reason in a pain.002 status report on the submitted order", "by": "the submitter's Swiss financial institution", "deadline": "None applies. A status report is the bank's answer to a submitted message, not a return, so no return window exists. The SPS expect an immediate reply but set no time limit, and cut-offs and error handling belong to each bank's own offer (IG-SR v2.1 section 3.1.1; BR v3.2 section 1.4.2)." } ], "applies_to": "Swiss Payment Standards customer-to-bank status report (pain.002), on credit transfer (pain.001) and direct debit (pain.008) submissions; B level, where the date sits." }, "caveat": "The status alongside this reason is typically ACWC, accepted with change; SIX gives a changed value date as an example of that status (IG-SR v2.1 section 3.1.2 Table 5). The SPS are a voluntary market practice. A bank may answer with any ISO status reason, with NARR plus its own text, or with a proprietary code, and handles faulty orders under its own customer terms (BR v3.2 section 1.4.2; IG-SR v2.1 section 3.2.4).", "related": [ "ch-sps-status:CH19", "ch-sps-status:CH03", "ch-sps-status:CH04", "ch-sps-status:DT01" ], "basis": { "sources": "SPS Implementation Guidelines Status Report (pain.002) v2.1 of 2024-02-20, SPS 2024 (IG-SR v2.1) sections 3.1.1, 3.2.3 and 3.2.4 Table 10 (payment-type shading read from the rendered page), Annex B Table 21; SPS Implementation Guidelines Credit Transfer (pain.001) v2.2 of 2025-02-24, SPS 2025 (CT IG v2.2) chapter 4, error code column of the element tables; SPS Implementation Guidelines SEPA Direct Debit (pain.008) v2.7, SPS 2021 (SDD IG v2.7) section 2.2, error code column; Implementation Guidelines Swiss Direct Debits (pain.008) v1.2 of 2018-04-06 (CH-DD IG v1.2) section 2.2, error code column; IG-SR v2.1 section 3.1.2 Table 5; SPS Business Rules v3.2, SPS 2025 (BR v3.2) section 1.4.2; IG-SR v2.2 of 2026-02-20, SPS 2026, section 3.2.4 Table 10 (unchanged).", "confidence": "high" }, "currency": { "effective_since": "2024-11-18", "effective_note": "IG-SR v2.1 (SPS 2024) applies from 2024-11-18 and is still the current pain.002 guide under SPS 2025, because SIX has published no SPS 2025 edition of it [Inference from the SIX download center, read 2026-09-18]. IG-SR v2.2 (SPS 2026, dated 2026-02-20) applies from 2026-11-14 and keeps this code in Table 10 with the same meaning and the same payment-type shading; that edition changes only tracker data and the status sequence annex. The SPS 2021 guide (v1.1.2, from 2021-11-19) also lists it and governs 2009-schema submissions until the November 2026 release. Use of the code before 2024-11-18 is not dated here [Unverified].", "source_edition": "IG-SR v2.1 (SPS 2024); IG-SR v2.2 (SPS 2026); CT IG v2.2 (SPS 2025); SDD IG v2.7 (SPS 2021); CH-DD IG v1.2 (2018); BR v3.2 (SPS 2025)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.six-group.com/dam/download/banking-services/standardization/sps/ig-status-report-sps2024-en.pdf", "source_class": "authoritative_primary", "source_title": "SPS Implementation Guidelines, Status Report (pain.002), SPS 2024, version 2.1, dated 2024-02-20, in force from 2024-11-18", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms DT06 is listed in Table 10 of the Status Report implementation guidelines with a meaning matching the record's summary, and Table 10 leaves it unshaded, meaning it is valid for both credit transfer and direct debit submissions. Table 10 is identical on this point in the v2.2 edition (SPS 2026, dated 2026-02-20, in force from 2026-11-14). Does not address triggers, actions or retry detail beyond the table entry." }, { "source_url": "https://www.six-group.com/dam/download/banking-services/standardization/sps/business-rules-sps-2025-en.pdf", "source_class": "authoritative_primary", "source_title": "SPS Business Rules for Payments and Cash Management, SPS 2025, version 3.2, dated 2025-02-24, in force from 2025-11-22", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms SPS Business Rules section 1.4.2 leaves cut-off times and the handling of erroneous orders and status reporting to each financial institution's own customer offering, rather than to the Swiss Payment Standards. Supports the DT06 record's return_windows claim that no SPS-wide deadline applies to sending this status reason, and supports the caveat that the SPS are a voluntary market practice. Does not itself list DT06 or its meaning." } ] }, "rail_name": "Swiss Payment Standards Status Report Reasons", "governing_authority": "SIX Interbank Clearing (Swiss Payment Standards)", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "judgement", "label": "your bank's own terms", "needs": "whose terms decide it: the bank's, the participant's or the scheme's", "detail": "A bank may answer with any ISO status reason, with NARR plus its own text, or with a proprietary code, and handles faulty orders under its own customer terms (BR v3.2 section 1.4.2; IG-SR v2.1 section 3.2.4).", "from": "caveat" } ] }, { "uid": "ch-sps-status:DU01", "id": "DU01", "rail": "ch-sps-status", "kind": "reason-code", "name": "Message identification already used", "group": "technical", "summary": "The Message Identification of the file matches one the bank has already received, so it treats the file as a duplicate and rejects it whole.", "triggers": [ "A file sent again with the same Message Identification, by mistake or after a transmission problem; most banks check over at least 90 days (CT IG v2.2 section 3.8)", "Payment software that reuses or resets its message numbering" ], "actions": [ "First find out whether the earlier file with that identification was processed; sending the same payments again under a new identification could pay twice", "Keep Message Identifications unique for as long as possible, as SIX recommends (CT IG v2.2 section 3.8)" ], "retry": { "allowed": true, "rule": "Only once the earlier file is confirmed as not processed, and only with a new Message Identification. The SPS set no retry limit." }, "facts": { "return_windows": [ { "action": "send this reason in a pain.002 status report on the submitted order", "by": "the submitter's Swiss financial institution", "deadline": "None applies. A status report is the bank's answer to a submitted message, not a return, so no return window exists. The SPS expect an immediate reply but set no time limit, and cut-offs and error handling belong to each bank's own offer (IG-SR v2.1 section 3.1.1; BR v3.2 section 1.4.2)." } ], "applies_to": "Swiss Payment Standards customer-to-bank status report (pain.002), on credit transfer (pain.001) and direct debit (pain.008) submissions; A level: the whole message is rejected." }, "caveat": "The SPS are a voluntary market practice. A bank may answer with any ISO status reason, with NARR plus its own text, or with a proprietary code, and handles faulty orders under its own customer terms (BR v3.2 section 1.4.2; IG-SR v2.1 section 3.2.4).", "related": [ "ch-sps-status:DU02", "ch-sps-status:DU05", "ch-sps-status:RF01" ], "basis": { "sources": "SPS Implementation Guidelines Status Report (pain.002) v2.1 of 2024-02-20, SPS 2024 (IG-SR v2.1) sections 3.1.1, 3.2.3 and 3.2.4 Table 10 (payment-type shading read from the rendered page), Annex B Table 21; SPS Implementation Guidelines Credit Transfer (pain.001) v2.2 of 2025-02-24, SPS 2025 (CT IG v2.2) sections 3.8 and 4.1; SPS Implementation Guidelines SEPA Direct Debit (pain.008) v2.7, SPS 2021 (SDD IG v2.7) section 2.2, error code column; Implementation Guidelines Swiss Direct Debits (pain.008) v1.2 of 2018-04-06 (CH-DD IG v1.2) section 2.2, error code column; SPS Business Rules v3.2, SPS 2025 (BR v3.2) section 1.4.2; IG-SR v2.2 of 2026-02-20, SPS 2026, section 3.2.4 Table 10 (unchanged).", "confidence": "high" }, "currency": { "effective_since": "2024-11-18", "effective_note": "IG-SR v2.1 (SPS 2024) applies from 2024-11-18 and is still the current pain.002 guide under SPS 2025, because SIX has published no SPS 2025 edition of it [Inference from the SIX download center, read 2026-09-18]. IG-SR v2.2 (SPS 2026, dated 2026-02-20) applies from 2026-11-14 and keeps this code in Table 10 with the same meaning and the same payment-type shading; that edition changes only tracker data and the status sequence annex. The SPS 2021 guide (v1.1.2, from 2021-11-19) also lists it and governs 2009-schema submissions until the November 2026 release. Use of the code before 2024-11-18 is not dated here [Unverified].", "source_edition": "IG-SR v2.1 (SPS 2024); IG-SR v2.2 (SPS 2026); CT IG v2.2 (SPS 2025); SDD IG v2.7 (SPS 2021); CH-DD IG v1.2 (2018); BR v3.2 (SPS 2025)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.six-group.com/dam/download/banking-services/standardization/sps/ig-status-report-sps2024-en.pdf", "source_class": "authoritative_primary", "source_title": "SPS Implementation Guidelines, Status Report (pain.002), SPS 2024, version 2.1, dated 2024-02-20, in force from 2024-11-18", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms DU01 is listed in Table 10 of the Status Report implementation guidelines with a meaning matching the record's summary, and Table 10 leaves it unshaded, meaning it is valid for both credit transfer and direct debit submissions. Table 10 is identical on this point in the v2.2 edition (SPS 2026, dated 2026-02-20, in force from 2026-11-14). Does not address triggers, actions or retry detail beyond the table entry." }, { "source_url": "https://www.six-group.com/dam/download/banking-services/standardization/sps/business-rules-sps-2025-en.pdf", "source_class": "authoritative_primary", "source_title": "SPS Business Rules for Payments and Cash Management, SPS 2025, version 3.2, dated 2025-02-24, in force from 2025-11-22", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms SPS Business Rules section 1.4.2 leaves cut-off times and the handling of erroneous orders and status reporting to each financial institution's own customer offering, rather than to the Swiss Payment Standards. Supports the DU01 record's return_windows claim that no SPS-wide deadline applies to sending this status reason, and supports the caveat that the SPS are a voluntary market practice. Does not itself list DU01 or its meaning." } ] }, "rail_name": "Swiss Payment Standards Status Report Reasons", "governing_authority": "SIX Interbank Clearing (Swiss Payment Standards)", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "judgement", "label": "your bank's own terms", "needs": "whose terms decide it: the bank's, the participant's or the scheme's", "detail": "A bank may answer with any ISO status reason, with NARR plus its own text, or with a proprietary code, and handles faulty orders under its own customer terms (BR v3.2 section 1.4.2; IG-SR v2.1 section 3.2.4).", "from": "caveat" } ] }, { "uid": "ch-sps-status:DU02", "id": "DU02", "rail": "ch-sps-status", "kind": "reason-code", "name": "Payment group identification repeated", "group": "technical", "summary": "Two payment groups (B levels) in the same message carry the same Payment Information Identification, which must be unique within the message because the status report refers back to it.", "triggers": [ "A repeated Payment Information Identification within one pain.001 (CT IG v2.2 section 4.2) or pain.008 (SDD IG v2.7; CH-DD IG v1.2)" ], "actions": [ "Make the payment software number each payment group uniquely", "Send the rejected groups again in a new message" ], "retry": { "allowed": true, "rule": "A rejected order stays rejected: RJCT is a final status (IG-SR v2.1 Annex B, Table 21). Fix the cause and send the payment again in a new message. Give that message a new Message Identification, because most Swiss banks check it for duplicates over at least 90 days (CT IG v2.2 section 3.8). The SPS set no retry limit." }, "facts": { "return_windows": [ { "action": "send this reason in a pain.002 status report on the submitted order", "by": "the submitter's Swiss financial institution", "deadline": "None applies. A status report is the bank's answer to a submitted message, not a return, so no return window exists. The SPS expect an immediate reply but set no time limit, and cut-offs and error handling belong to each bank's own offer (IG-SR v2.1 section 3.1.1; BR v3.2 section 1.4.2)." } ], "applies_to": "Swiss Payment Standards customer-to-bank status report (pain.002), on credit transfer (pain.001) and direct debit (pain.008) submissions; B level." }, "caveat": "The SPS are a voluntary market practice. A bank may answer with any ISO status reason, with NARR plus its own text, or with a proprietary code, and handles faulty orders under its own customer terms (BR v3.2 section 1.4.2; IG-SR v2.1 section 3.2.4).", "related": [ "ch-sps-status:DU01", "ch-sps-status:DU05" ], "basis": { "sources": "SPS Implementation Guidelines Status Report (pain.002) v2.1 of 2024-02-20, SPS 2024 (IG-SR v2.1) sections 3.1.1, 3.2.3 and 3.2.4 Table 10 (payment-type shading read from the rendered page), Annex B Table 21; SPS Implementation Guidelines Credit Transfer (pain.001) v2.2 of 2025-02-24, SPS 2025 (CT IG v2.2) chapter 4, error code column of the element tables; SPS Implementation Guidelines SEPA Direct Debit (pain.008) v2.7, SPS 2021 (SDD IG v2.7) section 2.2, error code column; Implementation Guidelines Swiss Direct Debits (pain.008) v1.2 of 2018-04-06 (CH-DD IG v1.2) section 2.2, error code column; SPS Business Rules v3.2, SPS 2025 (BR v3.2) section 1.4.2; IG-SR v2.2 of 2026-02-20, SPS 2026, section 3.2.4 Table 10 (unchanged).", "confidence": "high" }, "currency": { "effective_since": "2024-11-18", "effective_note": "IG-SR v2.1 (SPS 2024) applies from 2024-11-18 and is still the current pain.002 guide under SPS 2025, because SIX has published no SPS 2025 edition of it [Inference from the SIX download center, read 2026-09-18]. IG-SR v2.2 (SPS 2026, dated 2026-02-20) applies from 2026-11-14 and keeps this code in Table 10 with the same meaning and the same payment-type shading; that edition changes only tracker data and the status sequence annex. The SPS 2021 guide (v1.1.2, from 2021-11-19) also lists it and governs 2009-schema submissions until the November 2026 release. Use of the code before 2024-11-18 is not dated here [Unverified].", "source_edition": "IG-SR v2.1 (SPS 2024); IG-SR v2.2 (SPS 2026); CT IG v2.2 (SPS 2025); SDD IG v2.7 (SPS 2021); CH-DD IG v1.2 (2018); BR v3.2 (SPS 2025)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.six-group.com/dam/download/banking-services/standardization/sps/ig-status-report-sps2024-en.pdf", "source_class": "authoritative_primary", "source_title": "SPS Implementation Guidelines, Status Report (pain.002), SPS 2024, version 2.1, dated 2024-02-20, in force from 2024-11-18", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms DU02 is listed in Table 10 of the Status Report implementation guidelines with a meaning matching the record's summary, and Table 10 leaves it unshaded, meaning it is valid for both credit transfer and direct debit submissions. Table 10 is identical on this point in the v2.2 edition (SPS 2026, dated 2026-02-20, in force from 2026-11-14). Does not address triggers, actions or retry detail beyond the table entry." }, { "source_url": "https://www.six-group.com/dam/download/banking-services/standardization/sps/business-rules-sps-2025-en.pdf", "source_class": "authoritative_primary", "source_title": "SPS Business Rules for Payments and Cash Management, SPS 2025, version 3.2, dated 2025-02-24, in force from 2025-11-22", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms SPS Business Rules section 1.4.2 leaves cut-off times and the handling of erroneous orders and status reporting to each financial institution's own customer offering, rather than to the Swiss Payment Standards. Supports the DU02 record's return_windows claim that no SPS-wide deadline applies to sending this status reason, and supports the caveat that the SPS are a voluntary market practice. Does not itself list DU02 or its meaning." } ] }, "rail_name": "Swiss Payment Standards Status Report Reasons", "governing_authority": "SIX Interbank Clearing (Swiss Payment Standards)", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "judgement", "label": "your bank's own terms", "needs": "whose terms decide it: the bank's, the participant's or the scheme's", "detail": "A bank may answer with any ISO status reason, with NARR plus its own text, or with a proprietary code, and handles faulty orders under its own customer terms (BR v3.2 section 1.4.2; IG-SR v2.1 section 3.2.4).", "from": "caveat" } ] }, { "uid": "ch-sps-status:DU05", "id": "DU05", "rail": "ch-sps-status", "kind": "reason-code", "name": "Instruction identification repeated", "group": "technical", "summary": "Two transactions in the same payment group carry the same Instruction Identification, which the guide requires to be unique within the group.", "triggers": [ "A repeated Instruction Identification within one B level of a pain.001 (CT IG v2.2 section 4.3) or pain.008 (SDD IG v2.7; CH-DD IG v1.2)" ], "actions": [ "Make the payment software number each transaction uniquely within its group", "Send the rejected transactions again in a new message" ], "retry": { "allowed": true, "rule": "A rejected order stays rejected: RJCT is a final status (IG-SR v2.1 Annex B, Table 21). Fix the cause and send the payment again in a new message. Give that message a new Message Identification, because most Swiss banks check it for duplicates over at least 90 days (CT IG v2.2 section 3.8). The SPS set no retry limit." }, "facts": { "return_windows": [ { "action": "send this reason in a pain.002 status report on the submitted order", "by": "the submitter's Swiss financial institution", "deadline": "None applies. A status report is the bank's answer to a submitted message, not a return, so no return window exists. The SPS expect an immediate reply but set no time limit, and cut-offs and error handling belong to each bank's own offer (IG-SR v2.1 section 3.1.1; BR v3.2 section 1.4.2)." } ], "applies_to": "Swiss Payment Standards customer-to-bank status report (pain.002), on credit transfer (pain.001) and direct debit (pain.008) submissions; C level." }, "caveat": "The SPS are a voluntary market practice. A bank may answer with any ISO status reason, with NARR plus its own text, or with a proprietary code, and handles faulty orders under its own customer terms (BR v3.2 section 1.4.2; IG-SR v2.1 section 3.2.4).", "related": [ "ch-sps-status:DU01", "ch-sps-status:DU02", "ch-sps-status:RF01" ], "basis": { "sources": "SPS Implementation Guidelines Status Report (pain.002) v2.1 of 2024-02-20, SPS 2024 (IG-SR v2.1) sections 3.1.1, 3.2.3 and 3.2.4 Table 10 (payment-type shading read from the rendered page), Annex B Table 21; SPS Implementation Guidelines Credit Transfer (pain.001) v2.2 of 2025-02-24, SPS 2025 (CT IG v2.2) chapter 4, error code column of the element tables; SPS Implementation Guidelines SEPA Direct Debit (pain.008) v2.7, SPS 2021 (SDD IG v2.7) section 2.2, error code column; Implementation Guidelines Swiss Direct Debits (pain.008) v1.2 of 2018-04-06 (CH-DD IG v1.2) section 2.2, error code column; SPS Business Rules v3.2, SPS 2025 (BR v3.2) section 1.4.2; IG-SR v2.2 of 2026-02-20, SPS 2026, section 3.2.4 Table 10 (unchanged).", "confidence": "high" }, "currency": { "effective_since": "2024-11-18", "effective_note": "IG-SR v2.1 (SPS 2024) applies from 2024-11-18 and is still the current pain.002 guide under SPS 2025, because SIX has published no SPS 2025 edition of it [Inference from the SIX download center, read 2026-09-18]. IG-SR v2.2 (SPS 2026, dated 2026-02-20) applies from 2026-11-14 and keeps this code in Table 10 with the same meaning and the same payment-type shading; that edition changes only tracker data and the status sequence annex. The SPS 2021 guide (v1.1.2, from 2021-11-19) also lists it and governs 2009-schema submissions until the November 2026 release. Use of the code before 2024-11-18 is not dated here [Unverified].", "source_edition": "IG-SR v2.1 (SPS 2024); IG-SR v2.2 (SPS 2026); CT IG v2.2 (SPS 2025); SDD IG v2.7 (SPS 2021); CH-DD IG v1.2 (2018); BR v3.2 (SPS 2025)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.six-group.com/dam/download/banking-services/standardization/sps/ig-status-report-sps2024-en.pdf", "source_class": "authoritative_primary", "source_title": "SPS Implementation Guidelines, Status Report (pain.002), SPS 2024, version 2.1, dated 2024-02-20, in force from 2024-11-18", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms DU05 is listed in Table 10 of the Status Report implementation guidelines with a meaning matching the record's summary, and Table 10 leaves it unshaded, meaning it is valid for both credit transfer and direct debit submissions. Table 10 is identical on this point in the v2.2 edition (SPS 2026, dated 2026-02-20, in force from 2026-11-14). Does not address triggers, actions or retry detail beyond the table entry." }, { "source_url": "https://www.six-group.com/dam/download/banking-services/standardization/sps/business-rules-sps-2025-en.pdf", "source_class": "authoritative_primary", "source_title": "SPS Business Rules for Payments and Cash Management, SPS 2025, version 3.2, dated 2025-02-24, in force from 2025-11-22", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms SPS Business Rules section 1.4.2 leaves cut-off times and the handling of erroneous orders and status reporting to each financial institution's own customer offering, rather than to the Swiss Payment Standards. Supports the DU05 record's return_windows claim that no SPS-wide deadline applies to sending this status reason, and supports the caveat that the SPS are a voluntary market practice. Does not itself list DU05 or its meaning." } ] }, "rail_name": "Swiss Payment Standards Status Report Reasons", "governing_authority": "SIX Interbank Clearing (Swiss Payment Standards)", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "judgement", "label": "your bank's own terms", "needs": "whose terms decide it: the bank's, the participant's or the scheme's", "detail": "A bank may answer with any ISO status reason, with NARR plus its own text, or with a proprietary code, and handles faulty orders under its own customer terms (BR v3.2 section 1.4.2; IG-SR v2.1 section 3.2.4).", "from": "caveat" } ] }, { "uid": "ch-sps-status:FF01", "id": "FF01", "rail": "ch-sps-status", "kind": "reason-code", "name": "Schema or file format failure", "group": "technical", "summary": "The message fails XML schema validation, so the bank usually rejects the whole message. A value that breaks a schema pattern can also produce it.", "triggers": [ "XML that does not validate against the schema, for example elements out of order, a misspelt element name, or a code value the schema does not list (IG-SR v2.1 section 3.2.1)", "A mandatory element that is empty or breaks its pattern (IG-SR v2.1 section 3.2.2)", "A schema version the bank does not accept on that channel [Inference]" ], "actions": [ "Validate the file against the SIX schema before sending", "Expect the status report to lack some references when the bank could not read them (IG-SR v2.1 section 3.2.2)", "Send the whole message again with a new Message Identification" ], "retry": { "allowed": true, "rule": "A rejected order stays rejected: RJCT is a final status (IG-SR v2.1 Annex B, Table 21). Fix the cause and send the payment again in a new message. Give that message a new Message Identification, because most Swiss banks check it for duplicates over at least 90 days (CT IG v2.2 section 3.8). The SPS set no retry limit." }, "facts": { "return_windows": [ { "action": "send this reason in a pain.002 status report on the submitted order", "by": "the submitter's Swiss financial institution", "deadline": "None applies. A status report is the bank's answer to a submitted message, not a return, so no return window exists. The SPS expect an immediate reply but set no time limit, and cut-offs and error handling belong to each bank's own offer (IG-SR v2.1 section 3.1.1; BR v3.2 section 1.4.2)." } ], "applies_to": "Swiss Payment Standards customer-to-bank status report (pain.002), on credit transfer (pain.001) and direct debit (pain.008) submissions; normally A level, the whole message; some banks return only the affected transactions as an optional service." }, "caveat": "The credit transfer guide applies FF01 to every element when schema validation rejects a whole message, so it is not listed element by element (CT IG v2.2 section 1.5.2). The SPS are a voluntary market practice. A bank may answer with any ISO status reason, with NARR plus its own text, or with a proprietary code, and handles faulty orders under its own customer terms (BR v3.2 section 1.4.2; IG-SR v2.1 section 3.2.4).", "related": [ "ch-sps-status:CH21", "ch-sps-status:CH16", "ch-sps-status:AM18" ], "basis": { "sources": "SPS Implementation Guidelines Status Report (pain.002) v2.1 of 2024-02-20, SPS 2024 (IG-SR v2.1) sections 3.1.1, 3.2.3 and 3.2.4 Table 10 (payment-type shading read from the rendered page), Annex B Table 21; IG-SR v2.1 sections 3.2.1 and 3.2.2; SPS Implementation Guidelines Credit Transfer (pain.001) v2.2 of 2025-02-24, SPS 2025 (CT IG v2.2) section 1.5.2; SPS Implementation Guidelines SEPA Direct Debit (pain.008) v2.7, SPS 2021 (SDD IG v2.7) section 2.2, error code column; Implementation Guidelines Swiss Direct Debits (pain.008) v1.2 of 2018-04-06 (CH-DD IG v1.2) section 2.2, error code column; SPS Business Rules v3.2, SPS 2025 (BR v3.2) section 1.4.2; IG-SR v2.2 of 2026-02-20, SPS 2026, section 3.2.4 Table 10 (unchanged).", "confidence": "high" }, "currency": { "effective_since": "2024-11-18", "effective_note": "IG-SR v2.1 (SPS 2024) applies from 2024-11-18 and is still the current pain.002 guide under SPS 2025, because SIX has published no SPS 2025 edition of it [Inference from the SIX download center, read 2026-09-18]. IG-SR v2.2 (SPS 2026, dated 2026-02-20) applies from 2026-11-14 and keeps this code in Table 10 with the same meaning and the same payment-type shading; that edition changes only tracker data and the status sequence annex. The SPS 2021 guide (v1.1.2, from 2021-11-19) also lists it and governs 2009-schema submissions until the November 2026 release. Use of the code before 2024-11-18 is not dated here [Unverified].", "source_edition": "IG-SR v2.1 (SPS 2024); IG-SR v2.2 (SPS 2026); CT IG v2.2 (SPS 2025); SDD IG v2.7 (SPS 2021); CH-DD IG v1.2 (2018); BR v3.2 (SPS 2025)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.six-group.com/dam/download/banking-services/standardization/sps/ig-status-report-sps2024-en.pdf", "source_class": "authoritative_primary", "source_title": "SPS Implementation Guidelines, Status Report (pain.002), SPS 2024, version 2.1, dated 2024-02-20, in force from 2024-11-18", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms FF01 is listed in Table 10 of the Status Report implementation guidelines with a meaning matching the record's summary, and Table 10 leaves it unshaded, meaning it is valid for both credit transfer and direct debit submissions. Table 10 is identical on this point in the v2.2 edition (SPS 2026, dated 2026-02-20, in force from 2026-11-14). Does not address triggers, actions or retry detail beyond the table entry." }, { "source_url": "https://www.six-group.com/dam/download/banking-services/standardization/sps/business-rules-sps-2025-en.pdf", "source_class": "authoritative_primary", "source_title": "SPS Business Rules for Payments and Cash Management, SPS 2025, version 3.2, dated 2025-02-24, in force from 2025-11-22", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms SPS Business Rules section 1.4.2 leaves cut-off times and the handling of erroneous orders and status reporting to each financial institution's own customer offering, rather than to the Swiss Payment Standards. Supports the FF01 record's return_windows claim that no SPS-wide deadline applies to sending this status reason, and supports the caveat that the SPS are a voluntary market practice. Does not itself list FF01 or its meaning." } ] }, "rail_name": "Swiss Payment Standards Status Report Reasons", "governing_authority": "SIX Interbank Clearing (Swiss Payment Standards)", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "judgement", "label": "your bank's own terms", "needs": "whose terms decide it: the bank's, the participant's or the scheme's", "detail": "A bank may answer with any ISO status reason, with NARR plus its own text, or with a proprietary code, and handles faulty orders under its own customer terms (BR v3.2 section 1.4.2; IG-SR v2.1 section 3.2.4).", "from": "caveat" } ] }, { "uid": "ch-sps-status:MD01", "id": "MD01", "rail": "ch-sps-status", "kind": "reason-code", "name": "No mandate or debit authorisation", "group": "authorization", "summary": "The bank finds no valid mandate or debit authorisation behind a direct debit, so it does not collect.", "triggers": [ "A SEPA direct debit whose mandate reference or creditor identifier fails the mandate check agreed with the bank (SDD IG v2.7, mandate identification and creditor scheme identification)", "A Swiss direct debit to a debtor account with no debit authorisation (CH-DD IG v1.2, debtor account)" ], "actions": [ "Check that the mandate or LSV+ authorisation exists, is signed and is registered where the procedure requires [Inference]", "Do not send the collection again until the mandate is in place; collect the amount another way meanwhile", "Check the mandate reference in the file matches the one given to the debtor" ], "retry": { "allowed": true, "rule": "Only once a valid mandate or authorisation exists. A rejected order stays rejected: RJCT is a final status (IG-SR v2.1 Annex B, Table 21). Fix the cause and send the payment again in a new message. Give that message a new Message Identification, because most Swiss banks check it for duplicates over at least 90 days (CT IG v2.2 section 3.8). The SPS set no retry limit." }, "facts": { "return_windows": [ { "action": "send this reason in a pain.002 status report on the submitted order", "by": "the submitter's Swiss financial institution", "deadline": "None applies. A status report is the bank's answer to a submitted message, not a return, so no return window exists. The SPS expect an immediate reply but set no time limit, and cut-offs and error handling belong to each bank's own offer (IG-SR v2.1 section 3.1.1; BR v3.2 section 1.4.2)." } ], "applies_to": "Swiss Payment Standards customer-to-bank status report (pain.002), on direct debit (pain.008) submissions only, Swiss or SEPA; Table 10 shades it grey; C level for the transaction, or B level with all its transactions when the creditor identifier fails the check." }, "caveat": "The SPS are a voluntary market practice. A bank may answer with any ISO status reason, with NARR plus its own text, or with a proprietary code, and handles faulty orders under its own customer terms (BR v3.2 section 1.4.2; IG-SR v2.1 section 3.2.4).", "related": [ "ch-sps-status:MD02", "ch-sps-status:CH09", "ch-sps-status:CH11" ], "basis": { "sources": "SPS Implementation Guidelines Status Report (pain.002) v2.1 of 2024-02-20, SPS 2024 (IG-SR v2.1) sections 3.1.1, 3.2.3 and 3.2.4 Table 10 (payment-type shading read from the rendered page), Annex B Table 21; SPS Implementation Guidelines SEPA Direct Debit (pain.008) v2.7, SPS 2021 (SDD IG v2.7) section 2.2, error code column; Implementation Guidelines Swiss Direct Debits (pain.008) v1.2 of 2018-04-06 (CH-DD IG v1.2) section 2.2, error code column; SPS Implementation Guidelines Credit Transfer (pain.001) v2.2 of 2025-02-24, SPS 2025 (CT IG v2.2) section 3.8; SPS Business Rules v3.2, SPS 2025 (BR v3.2) section 1.4.2; IG-SR v2.2 of 2026-02-20, SPS 2026, section 3.2.4 Table 10 (unchanged).", "confidence": "high" }, "currency": { "effective_since": "2024-11-18", "effective_note": "IG-SR v2.1 (SPS 2024) applies from 2024-11-18 and is still the current pain.002 guide under SPS 2025, because SIX has published no SPS 2025 edition of it [Inference from the SIX download center, read 2026-09-18]. IG-SR v2.2 (SPS 2026, dated 2026-02-20) applies from 2026-11-14 and keeps this code in Table 10 with the same meaning and the same payment-type shading; that edition changes only tracker data and the status sequence annex. The SPS 2021 guide (v1.1.2, from 2021-11-19) also lists it and governs 2009-schema submissions until the November 2026 release. Use of the code before 2024-11-18 is not dated here [Unverified].", "source_edition": "IG-SR v2.1 (SPS 2024); IG-SR v2.2 (SPS 2026); SDD IG v2.7 (SPS 2021); CH-DD IG v1.2 (2018); BR v3.2 (SPS 2025); CT IG v2.2 (SPS 2025)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.six-group.com/dam/download/banking-services/standardization/sps/ig-status-report-sps2024-en.pdf", "source_class": "authoritative_primary", "source_title": "SPS Implementation Guidelines, Status Report (pain.002), SPS 2024, version 2.1, dated 2024-02-20, in force from 2024-11-18", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms MD01 is listed in Table 10 of the Status Report implementation guidelines with a meaning matching the record's summary, and Table 10 shades it gray with no payment-type wording, meaning it is valid for Swiss and/or SEPA direct debit submissions only, not credit transfers. Table 10 is identical on this point in the v2.2 edition (SPS 2026, dated 2026-02-20, in force from 2026-11-14). Does not address triggers, actions or retry detail beyond the table entry." }, { "source_url": "https://www.six-group.com/dam/download/banking-services/standardization/sps/business-rules-sps-2025-en.pdf", "source_class": "authoritative_primary", "source_title": "SPS Business Rules for Payments and Cash Management, SPS 2025, version 3.2, dated 2025-02-24, in force from 2025-11-22", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms SPS Business Rules section 1.4.2 leaves cut-off times and the handling of erroneous orders and status reporting to each financial institution's own customer offering, rather than to the Swiss Payment Standards. Supports the MD01 record's return_windows claim that no SPS-wide deadline applies to sending this status reason, and supports the caveat that the SPS are a voluntary market practice. Does not itself list MD01 or its meaning." } ] }, "rail_name": "Swiss Payment Standards Status Report Reasons", "governing_authority": "SIX Interbank Clearing (Swiss Payment Standards)", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "judgement", "label": "your bank's own terms", "needs": "whose terms decide it: the bank's, the participant's or the scheme's", "detail": "A bank may answer with any ISO status reason, with NARR plus its own text, or with a proprietary code, and handles faulty orders under its own customer terms (BR v3.2 section 1.4.2; IG-SR v2.1 section 3.2.4).", "from": "caveat" } ] }, { "uid": "ch-sps-status:MD02", "id": "MD02", "rail": "ch-sps-status", "kind": "reason-code", "name": "Mandate data incomplete", "group": "authorization", "summary": "Mandate data the bank needs is missing from a direct debit. Added to the Swiss list after SPS 2021; the direct debit guides read do not tie it to an element.", "triggers": [ "A direct debit without mandate details the bank requires, such as the mandate reference or signature date [Inference: SDD IG v2.7 and CH-DD IG v1.2 predate the code and do not map it]" ], "actions": [ "Read the additional information text for the missing mandate field", "Complete the mandate data in the payment software and send the collection again in a new message" ], "retry": { "allowed": true, "rule": "A rejected order stays rejected: RJCT is a final status (IG-SR v2.1 Annex B, Table 21). Fix the cause and send the payment again in a new message. Give that message a new Message Identification, because most Swiss banks check it for duplicates over at least 90 days (CT IG v2.2 section 3.8). The SPS set no retry limit." }, "facts": { "return_windows": [ { "action": "send this reason in a pain.002 status report on the submitted order", "by": "the submitter's Swiss financial institution", "deadline": "None applies. A status report is the bank's answer to a submitted message, not a return, so no return window exists. The SPS expect an immediate reply but set no time limit, and cut-offs and error handling belong to each bank's own offer (IG-SR v2.1 section 3.1.1; BR v3.2 section 1.4.2)." } ], "applies_to": "Swiss Payment Standards customer-to-bank status report (pain.002), on direct debit (pain.008) submissions only, Swiss or SEPA; Table 10 shades it grey." }, "caveat": "The SPS are a voluntary market practice. A bank may answer with any ISO status reason, with NARR plus its own text, or with a proprietary code, and handles faulty orders under its own customer terms (BR v3.2 section 1.4.2; IG-SR v2.1 section 3.2.4).", "related": [ "ch-sps-status:MD01", "ch-sps-status:CH10" ], "basis": { "sources": "SPS Implementation Guidelines Status Report (pain.002) v2.1 of 2024-02-20, SPS 2024 (IG-SR v2.1) sections 3.1.1, 3.2.3 and 3.2.4 Table 10 (payment-type shading read from the rendered page), Annex B Table 21; SDD IG v2.7 and CH-DD IG v1.2 read for this code; neither maps MD02; SPS Implementation Guidelines Credit Transfer (pain.001) v2.2 of 2025-02-24, SPS 2025 (CT IG v2.2) section 3.8; SPS Business Rules v3.2, SPS 2025 (BR v3.2) section 1.4.2; IG-SR v2.2 of 2026-02-20, SPS 2026, section 3.2.4 Table 10 (unchanged).", "confidence": "medium" }, "currency": { "effective_since": "2024-11-18", "effective_note": "IG-SR v2.1 (SPS 2024) applies from 2024-11-18 and is still the current pain.002 guide under SPS 2025, because SIX has published no SPS 2025 edition of it [Inference from the SIX download center, read 2026-09-18]. IG-SR v2.2 (SPS 2026, dated 2026-02-20) applies from 2026-11-14 and keeps this code in Table 10 with the same meaning and the same payment-type shading; that edition changes only tracker data and the status sequence annex. The code is absent from the SPS 2021 guide (v1.1.2), which still governs 2009-schema submissions until the November 2026 release. Use of the code before 2024-11-18 is not dated here [Unverified].", "source_edition": "IG-SR v2.1 (SPS 2024); IG-SR v2.2 (SPS 2026); SDD IG v2.7 (SPS 2021); CH-DD IG v1.2 (2018); BR v3.2 (SPS 2025); CT IG v2.2 (SPS 2025)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.six-group.com/dam/download/banking-services/standardization/sps/ig-status-report-sps2024-en.pdf", "source_class": "authoritative_primary", "source_title": "SPS Implementation Guidelines, Status Report (pain.002), SPS 2024, version 2.1, dated 2024-02-20, in force from 2024-11-18", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms MD02 is listed in Table 10 of the Status Report implementation guidelines with a meaning matching the record's summary, and Table 10 shades it gray with no payment-type wording, meaning it is valid for Swiss and/or SEPA direct debit submissions only, not credit transfers. Table 10 is identical on this point in the v2.2 edition (SPS 2026, dated 2026-02-20, in force from 2026-11-14). Does not address triggers, actions or retry detail beyond the table entry." }, { "source_url": "https://www.six-group.com/dam/download/banking-services/standardization/sps/business-rules-sps-2025-en.pdf", "source_class": "authoritative_primary", "source_title": "SPS Business Rules for Payments and Cash Management, SPS 2025, version 3.2, dated 2025-02-24, in force from 2025-11-22", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms SPS Business Rules section 1.4.2 leaves cut-off times and the handling of erroneous orders and status reporting to each financial institution's own customer offering, rather than to the Swiss Payment Standards. Supports the MD02 record's return_windows claim that no SPS-wide deadline applies to sending this status reason, and supports the caveat that the SPS are a voluntary market practice. Does not itself list MD02 or its meaning." } ] }, "rail_name": "Swiss Payment Standards Status Report Reasons", "governing_authority": "SIX Interbank Clearing (Swiss Payment Standards)", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "judgement", "label": "your bank's own terms", "needs": "whose terms decide it: the bank's, the participant's or the scheme's", "detail": "A bank may answer with any ISO status reason, with NARR plus its own text, or with a proprietary code, and handles faulty orders under its own customer terms (BR v3.2 section 1.4.2; IG-SR v2.1 section 3.2.4).", "from": "caveat" } ] }, { "uid": "ch-sps-status:MS03", "id": "MS03", "rail": "ch-sps-status", "kind": "reason-code", "name": "Reason not given", "group": "administrative", "summary": "The bank rejects without stating a specific reason. The code says only that the bank itself declined.", "triggers": [ "A bank check that has no code of its own in the SPS list, for example an internal limit, an account restriction or compliance screening [Inference]" ], "actions": [ "Read the additional information text, then ask the bank for the reason", "Do not resend unchanged until the reason is known" ], "retry": { "allowed": true, "rule": "Only after the bank has explained the reason and it is resolved. Send the payment again in a new message. The SPS set no retry limit." }, "facts": { "return_windows": [ { "action": "send this reason in a pain.002 status report on the submitted order", "by": "the submitter's Swiss financial institution", "deadline": "None applies. A status report is the bank's answer to a submitted message, not a return, so no return window exists. The SPS expect an immediate reply but set no time limit, and cut-offs and error handling belong to each bank's own offer (IG-SR v2.1 section 3.1.1; BR v3.2 section 1.4.2)." } ], "applies_to": "Swiss Payment Standards customer-to-bank status report (pain.002), on credit transfer (pain.001) and direct debit (pain.008) submissions." }, "caveat": "The same letters are used with a different meaning in Swiss interbank instant payment rejections [Unverified: taken from the approved ch-sic rail brief; the SIC module documents were not read in this drafting pass]. Do not read this pain.002 code with that meaning. The SPS are a voluntary market practice. A bank may answer with any ISO status reason, with NARR plus its own text, or with a proprietary code, and handles faulty orders under its own customer terms (BR v3.2 section 1.4.2; IG-SR v2.1 section 3.2.4).", "related": [ "ch-sps-status:CUST", "ch-sps-status:BE01" ], "basis": { "sources": "SPS Implementation Guidelines Status Report (pain.002) v2.1 of 2024-02-20, SPS 2024 (IG-SR v2.1) sections 3.1.1, 3.2.3 and 3.2.4 Table 10 (payment-type shading read from the rendered page), Annex B Table 21; IG-SR v2.1 section 3.1.5 (additional information text); SPS Business Rules v3.2, SPS 2025 (BR v3.2) section 1.4.2; IG-SR v2.2 of 2026-02-20, SPS 2026, section 3.2.4 Table 10 (unchanged).", "confidence": "medium" }, "currency": { "effective_since": "2024-11-18", "effective_note": "IG-SR v2.1 (SPS 2024) applies from 2024-11-18 and is still the current pain.002 guide under SPS 2025, because SIX has published no SPS 2025 edition of it [Inference from the SIX download center, read 2026-09-18]. IG-SR v2.2 (SPS 2026, dated 2026-02-20) applies from 2026-11-14 and keeps this code in Table 10 with the same meaning and the same payment-type shading; that edition changes only tracker data and the status sequence annex. The SPS 2021 guide (v1.1.2, from 2021-11-19) also lists it and governs 2009-schema submissions until the November 2026 release. Use of the code before 2024-11-18 is not dated here [Unverified].", "source_edition": "IG-SR v2.1 (SPS 2024); IG-SR v2.2 (SPS 2026); BR v3.2 (SPS 2025)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.six-group.com/dam/download/banking-services/standardization/sps/ig-status-report-sps2024-en.pdf", "source_class": "authoritative_primary", "source_title": "SPS Implementation Guidelines, Status Report (pain.002), SPS 2024, version 2.1, dated 2024-02-20, in force from 2024-11-18", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms MS03 is listed in Table 10 of the Status Report implementation guidelines with a meaning matching the record's summary, and Table 10 leaves it unshaded, meaning it is valid for both credit transfer and direct debit submissions. Table 10 is identical on this point in the v2.2 edition (SPS 2026, dated 2026-02-20, in force from 2026-11-14). Does not address triggers, actions or retry detail beyond the table entry." }, { "source_url": "https://www.six-group.com/dam/download/banking-services/standardization/sps/business-rules-sps-2025-en.pdf", "source_class": "authoritative_primary", "source_title": "SPS Business Rules for Payments and Cash Management, SPS 2025, version 3.2, dated 2025-02-24, in force from 2025-11-22", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms SPS Business Rules section 1.4.2 leaves cut-off times and the handling of erroneous orders and status reporting to each financial institution's own customer offering, rather than to the Swiss Payment Standards. Supports the MS03 record's return_windows claim that no SPS-wide deadline applies to sending this status reason, and supports the caveat that the SPS are a voluntary market practice. Does not itself list MS03 or its meaning." } ] }, "rail_name": "Swiss Payment Standards Status Report Reasons", "governing_authority": "SIX Interbank Clearing (Swiss Payment Standards)", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "judgement", "label": "your bank's own terms", "needs": "whose terms decide it: the bank's, the participant's or the scheme's", "detail": "A bank may answer with any ISO status reason, with NARR plus its own text, or with a proprietary code, and handles faulty orders under its own customer terms (BR v3.2 section 1.4.2; IG-SR v2.1 section 3.2.4).", "from": "caveat" } ] }, { "uid": "ch-sps-status:RC01", "id": "RC01", "rail": "ch-sps-status", "kind": "reason-code", "name": "Bank BIC or IID not usable", "group": "technical", "summary": "A BIC or Swiss bank identifier (IID) in the order is invalid or unusable, whether for the debtor's bank, an intermediary or a party identified by BIC.", "triggers": [ "An invalid BIC or IID for the debtor agent or an intermediary agent (CT IG v2.2 sections 4.2 and 4.3)", "An invalid BIC used to identify the initiating party or ultimate debtor (CT IG v2.2 sections 4.1 to 4.3)", "An invalid bank identifier in a pain.008 (SDD IG v2.7; CH-DD IG v1.2)" ], "actions": [ "Check the BIC or IID against the current SIX bank master data or BIC directory [Inference]", "Send the corrected payments again in a new message" ], "retry": { "allowed": true, "rule": "A rejected order stays rejected: RJCT is a final status (IG-SR v2.1 Annex B, Table 21). Fix the cause and send the payment again in a new message. Give that message a new Message Identification, because most Swiss banks check it for duplicates over at least 90 days (CT IG v2.2 section 3.8). The SPS set no retry limit." }, "facts": { "return_windows": [ { "action": "send this reason in a pain.002 status report on the submitted order", "by": "the submitter's Swiss financial institution", "deadline": "None applies. A status report is the bank's answer to a submitted message, not a return, so no return window exists. The SPS expect an immediate reply but set no time limit, and cut-offs and error handling belong to each bank's own offer (IG-SR v2.1 section 3.1.1; BR v3.2 section 1.4.2)." } ], "applies_to": "Swiss Payment Standards customer-to-bank status report (pain.002), on credit transfer (pain.001) and direct debit (pain.008) submissions." }, "caveat": "The SPS are a voluntary market practice. A bank may answer with any ISO status reason, with NARR plus its own text, or with a proprietary code, and handles faulty orders under its own customer terms (BR v3.2 section 1.4.2; IG-SR v2.1 section 3.2.4).", "related": [ "ch-sps-status:AGNT", "ch-sps-status:AG06", "ch-sps-status:AC01" ], "basis": { "sources": "SPS Implementation Guidelines Status Report (pain.002) v2.1 of 2024-02-20, SPS 2024 (IG-SR v2.1) sections 3.1.1, 3.2.3 and 3.2.4 Table 10 (payment-type shading read from the rendered page), Annex B Table 21; SPS Implementation Guidelines Credit Transfer (pain.001) v2.2 of 2025-02-24, SPS 2025 (CT IG v2.2) chapter 4, error code column of the element tables; SPS Implementation Guidelines SEPA Direct Debit (pain.008) v2.7, SPS 2021 (SDD IG v2.7) section 2.2, error code column; Implementation Guidelines Swiss Direct Debits (pain.008) v1.2 of 2018-04-06 (CH-DD IG v1.2) section 2.2, error code column; SPS Business Rules v3.2, SPS 2025 (BR v3.2) section 1.4.2; IG-SR v2.2 of 2026-02-20, SPS 2026, section 3.2.4 Table 10 (unchanged).", "confidence": "high" }, "currency": { "effective_since": "2024-11-18", "effective_note": "IG-SR v2.1 (SPS 2024) applies from 2024-11-18 and is still the current pain.002 guide under SPS 2025, because SIX has published no SPS 2025 edition of it [Inference from the SIX download center, read 2026-09-18]. IG-SR v2.2 (SPS 2026, dated 2026-02-20) applies from 2026-11-14 and keeps this code in Table 10 with the same meaning and the same payment-type shading; that edition changes only tracker data and the status sequence annex. The SPS 2021 guide (v1.1.2, from 2021-11-19) also lists it and governs 2009-schema submissions until the November 2026 release. Use of the code before 2024-11-18 is not dated here [Unverified].", "source_edition": "IG-SR v2.1 (SPS 2024); IG-SR v2.2 (SPS 2026); CT IG v2.2 (SPS 2025); SDD IG v2.7 (SPS 2021); CH-DD IG v1.2 (2018); BR v3.2 (SPS 2025)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.six-group.com/dam/download/banking-services/standardization/sps/ig-status-report-sps2024-en.pdf", "source_class": "authoritative_primary", "source_title": "SPS Implementation Guidelines, Status Report (pain.002), SPS 2024, version 2.1, dated 2024-02-20, in force from 2024-11-18", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms RC01 is listed in Table 10 of the Status Report implementation guidelines with a meaning matching the record's summary, and Table 10 leaves it unshaded, meaning it is valid for both credit transfer and direct debit submissions. Table 10 is identical on this point in the v2.2 edition (SPS 2026, dated 2026-02-20, in force from 2026-11-14). Does not address triggers, actions or retry detail beyond the table entry." }, { "source_url": "https://www.six-group.com/dam/download/banking-services/standardization/sps/business-rules-sps-2025-en.pdf", "source_class": "authoritative_primary", "source_title": "SPS Business Rules for Payments and Cash Management, SPS 2025, version 3.2, dated 2025-02-24, in force from 2025-11-22", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms SPS Business Rules section 1.4.2 leaves cut-off times and the handling of erroneous orders and status reporting to each financial institution's own customer offering, rather than to the Swiss Payment Standards. Supports the RC01 record's return_windows claim that no SPS-wide deadline applies to sending this status reason, and supports the caveat that the SPS are a voluntary market practice. Does not itself list RC01 or its meaning." } ] }, "rail_name": "Swiss Payment Standards Status Report Reasons", "governing_authority": "SIX Interbank Clearing (Swiss Payment Standards)", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "judgement", "label": "your bank's own terms", "needs": "whose terms decide it: the bank's, the participant's or the scheme's", "detail": "A bank may answer with any ISO status reason, with NARR plus its own text, or with a proprietary code, and handles faulty orders under its own customer terms (BR v3.2 section 1.4.2; IG-SR v2.1 section 3.2.4).", "from": "caveat" } ] }, { "uid": "ch-sps-status:RF01", "id": "RF01", "rail": "ch-sps-status", "kind": "reason-code", "name": "Duplicate transaction reference", "group": "technical", "summary": "A transaction reference repeats one the bank already holds. Added to the Swiss list after SPS 2021; the guides read do not tie it to an element.", "triggers": [ "An end-to-end or instruction reference reused where the bank checks uniqueness beyond the message [Inference: the guides require uniqueness only for message, payment group and instruction identifications, reported as DU01, DU02 and DU05]" ], "actions": [ "Read the additional information text for the reference concerned", "Give each transaction its own reference and send it again in a new message" ], "retry": { "allowed": true, "rule": "A rejected order stays rejected: RJCT is a final status (IG-SR v2.1 Annex B, Table 21). Fix the cause and send the payment again in a new message. Give that message a new Message Identification, because most Swiss banks check it for duplicates over at least 90 days (CT IG v2.2 section 3.8). The SPS set no retry limit." }, "facts": { "return_windows": [ { "action": "send this reason in a pain.002 status report on the submitted order", "by": "the submitter's Swiss financial institution", "deadline": "None applies. A status report is the bank's answer to a submitted message, not a return, so no return window exists. The SPS expect an immediate reply but set no time limit, and cut-offs and error handling belong to each bank's own offer (IG-SR v2.1 section 3.1.1; BR v3.2 section 1.4.2)." } ], "applies_to": "Swiss Payment Standards customer-to-bank status report (pain.002), on credit transfer (pain.001) and direct debit (pain.008) submissions." }, "caveat": "The SPS are a voluntary market practice. A bank may answer with any ISO status reason, with NARR plus its own text, or with a proprietary code, and handles faulty orders under its own customer terms (BR v3.2 section 1.4.2; IG-SR v2.1 section 3.2.4).", "related": [ "ch-sps-status:DU01", "ch-sps-status:DU05" ], "basis": { "sources": "SPS Implementation Guidelines Status Report (pain.002) v2.1 of 2024-02-20, SPS 2024 (IG-SR v2.1) sections 3.1.1, 3.2.3 and 3.2.4 Table 10 (payment-type shading read from the rendered page), Annex B Table 21; CT IG v2.2 read for this code; it does not map RF01 to any element; SPS Implementation Guidelines Credit Transfer (pain.001) v2.2 of 2025-02-24, SPS 2025 (CT IG v2.2) section 3.8; SPS Business Rules v3.2, SPS 2025 (BR v3.2) section 1.4.2; IG-SR v2.2 of 2026-02-20, SPS 2026, section 3.2.4 Table 10 (unchanged).", "confidence": "medium" }, "currency": { "effective_since": "2024-11-18", "effective_note": "IG-SR v2.1 (SPS 2024) applies from 2024-11-18 and is still the current pain.002 guide under SPS 2025, because SIX has published no SPS 2025 edition of it [Inference from the SIX download center, read 2026-09-18]. IG-SR v2.2 (SPS 2026, dated 2026-02-20) applies from 2026-11-14 and keeps this code in Table 10 with the same meaning and the same payment-type shading; that edition changes only tracker data and the status sequence annex. The code is absent from the SPS 2021 guide (v1.1.2), which still governs 2009-schema submissions until the November 2026 release. Use of the code before 2024-11-18 is not dated here [Unverified].", "source_edition": "IG-SR v2.1 (SPS 2024); IG-SR v2.2 (SPS 2026); CT IG v2.2 (SPS 2025); BR v3.2 (SPS 2025)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.six-group.com/dam/download/banking-services/standardization/sps/ig-status-report-sps2024-en.pdf", "source_class": "authoritative_primary", "source_title": "SPS Implementation Guidelines, Status Report (pain.002), SPS 2024, version 2.1, dated 2024-02-20, in force from 2024-11-18", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms RF01 is listed in Table 10 of the Status Report implementation guidelines with a meaning matching the record's summary, and Table 10 leaves it unshaded, meaning it is valid for both credit transfer and direct debit submissions. Table 10 is identical on this point in the v2.2 edition (SPS 2026, dated 2026-02-20, in force from 2026-11-14). Does not address triggers, actions or retry detail beyond the table entry." }, { "source_url": "https://www.six-group.com/dam/download/banking-services/standardization/sps/business-rules-sps-2025-en.pdf", "source_class": "authoritative_primary", "source_title": "SPS Business Rules for Payments and Cash Management, SPS 2025, version 3.2, dated 2025-02-24, in force from 2025-11-22", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms SPS Business Rules section 1.4.2 leaves cut-off times and the handling of erroneous orders and status reporting to each financial institution's own customer offering, rather than to the Swiss Payment Standards. Supports the RF01 record's return_windows claim that no SPS-wide deadline applies to sending this status reason, and supports the caveat that the SPS are a voluntary market practice. Does not itself list RF01 or its meaning." } ] }, "rail_name": "Swiss Payment Standards Status Report Reasons", "governing_authority": "SIX Interbank Clearing (Swiss Payment Standards)", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "judgement", "label": "your bank's own terms", "needs": "whose terms decide it: the bank's, the participant's or the scheme's", "detail": "A bank may answer with any ISO status reason, with NARR plus its own text, or with a proprietary code, and handles faulty orders under its own customer terms (BR v3.2 section 1.4.2; IG-SR v2.1 section 3.2.4).", "from": "caveat" } ] }, { "uid": "ch-sps-status:RR05", "id": "RR05", "rail": "ch-sps-status", "kind": "reason-code", "name": "Regulatory reporting data wrong", "group": "administrative", "summary": "Regulatory reporting information in the order, the data meant for a central bank or other authority, is invalid.", "triggers": [ "A regulatory reporting code that is invalid or given without the country it belongs to (CT IG v2.2 section 4.3)" ], "actions": [ "Check the reporting code and country against the rules of the authority the report is meant for", "Send the corrected payment again in a new message" ], "retry": { "allowed": true, "rule": "A rejected order stays rejected: RJCT is a final status (IG-SR v2.1 Annex B, Table 21). Fix the cause and send the payment again in a new message. Give that message a new Message Identification, because most Swiss banks check it for duplicates over at least 90 days (CT IG v2.2 section 3.8). The SPS set no retry limit." }, "facts": { "return_windows": [ { "action": "send this reason in a pain.002 status report on the submitted order", "by": "the submitter's Swiss financial institution", "deadline": "None applies. A status report is the bank's answer to a submitted message, not a return, so no return window exists. The SPS expect an immediate reply but set no time limit, and cut-offs and error handling belong to each bank's own offer (IG-SR v2.1 section 3.1.1; BR v3.2 section 1.4.2)." } ], "applies_to": "Swiss Payment Standards customer-to-bank status report (pain.002), on direct debit (pain.008) submissions only, Swiss or SEPA; Table 10 shades it grey; yet CT IG v2.2 also maps it to the regulatory reporting code of a pain.001." }, "caveat": "The two SIX documents disagree on scope: Table 10 marks RR05 as a direct debit code, while the credit transfer guide lists it on a credit transfer element. Which is right is not settled here. The SPS are a voluntary market practice. A bank may answer with any ISO status reason, with NARR plus its own text, or with a proprietary code, and handles faulty orders under its own customer terms (BR v3.2 section 1.4.2; IG-SR v2.1 section 3.2.4).", "related": [ "ch-sps-status:BE09" ], "basis": { "sources": "SPS Implementation Guidelines Status Report (pain.002) v2.1 of 2024-02-20, SPS 2024 (IG-SR v2.1) sections 3.1.1, 3.2.3 and 3.2.4 Table 10 (payment-type shading read from the rendered page), Annex B Table 21; SPS Implementation Guidelines Credit Transfer (pain.001) v2.2 of 2025-02-24, SPS 2025 (CT IG v2.2) chapter 4, error code column of the element tables; SPS Business Rules v3.2, SPS 2025 (BR v3.2) section 1.4.2; IG-SR v2.2 of 2026-02-20, SPS 2026, section 3.2.4 Table 10 (unchanged).", "confidence": "medium" }, "currency": { "effective_since": "2024-11-18", "effective_note": "IG-SR v2.1 (SPS 2024) applies from 2024-11-18 and is still the current pain.002 guide under SPS 2025, because SIX has published no SPS 2025 edition of it [Inference from the SIX download center, read 2026-09-18]. IG-SR v2.2 (SPS 2026, dated 2026-02-20) applies from 2026-11-14 and keeps this code in Table 10 with the same meaning and the same payment-type shading; that edition changes only tracker data and the status sequence annex. The SPS 2021 guide (v1.1.2, from 2021-11-19) also lists it and governs 2009-schema submissions until the November 2026 release. Use of the code before 2024-11-18 is not dated here [Unverified].", "source_edition": "IG-SR v2.1 (SPS 2024); IG-SR v2.2 (SPS 2026); CT IG v2.2 (SPS 2025); BR v3.2 (SPS 2025)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.six-group.com/dam/download/banking-services/standardization/sps/ig-status-report-sps2024-en.pdf", "source_class": "authoritative_primary", "source_title": "SPS Implementation Guidelines, Status Report (pain.002), SPS 2024, version 2.1, dated 2024-02-20, in force from 2024-11-18", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms RR05 is listed in Table 10 of the Status Report implementation guidelines with a meaning matching the record's summary, and Table 10 shades it gray with no payment-type wording, meaning it is valid for Swiss and/or SEPA direct debit submissions only, not credit transfers. Table 10 is identical on this point in the v2.2 edition (SPS 2026, dated 2026-02-20, in force from 2026-11-14). Does not address triggers, actions or retry detail beyond the table entry." }, { "source_url": "https://www.six-group.com/dam/download/banking-services/standardization/sps/business-rules-sps-2025-en.pdf", "source_class": "authoritative_primary", "source_title": "SPS Business Rules for Payments and Cash Management, SPS 2025, version 3.2, dated 2025-02-24, in force from 2025-11-22", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms SPS Business Rules section 1.4.2 leaves cut-off times and the handling of erroneous orders and status reporting to each financial institution's own customer offering, rather than to the Swiss Payment Standards. Supports the RR05 record's return_windows claim that no SPS-wide deadline applies to sending this status reason, and supports the caveat that the SPS are a voluntary market practice. Does not itself list RR05 or its meaning." } ] }, "rail_name": "Swiss Payment Standards Status Report Reasons", "governing_authority": "SIX Interbank Clearing (Swiss Payment Standards)", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "judgement", "label": "your bank's own terms", "needs": "whose terms decide it: the bank's, the participant's or the scheme's", "detail": "A bank may answer with any ISO status reason, with NARR plus its own text, or with a proprietary code, and handles faulty orders under its own customer terms (BR v3.2 section 1.4.2; IG-SR v2.1 section 3.2.4).", "from": "caveat" } ] }, { "uid": "ch-sps-status:RR12", "id": "RR12", "rail": "ch-sps-status", "kind": "reason-code", "name": "Sender identification wrong (Swiss direct debits)", "group": "administrative", "summary": "In a Swiss direct debit, the sender identification agreed with the bank is missing or wrong. Table 10 limits this code to Swiss direct debits, and the whole message is rejected.", "triggers": [ "An initiating party identification that is not the sender ID agreed with the receiving institution: the RS-PID for CH-DD, the LSV+/BDD identification for LSV+/BDD (CH-DD IG v1.2 section 2.2.1)" ], "actions": [ "Use the sender ID the bank or PostFinance assigned for the procedure", "Send the whole message again with a new Message Identification" ], "retry": { "allowed": true, "rule": "A rejected order stays rejected: RJCT is a final status (IG-SR v2.1 Annex B, Table 21). Fix the cause and send the payment again in a new message. Give that message a new Message Identification, because most Swiss banks check it for duplicates over at least 90 days (CT IG v2.2 section 3.8). The SPS set no retry limit." }, "facts": { "return_windows": [ { "action": "send this reason in a pain.002 status report on the submitted order", "by": "the submitter's Swiss financial institution", "deadline": "None applies. A status report is the bank's answer to a submitted message, not a return, so no return window exists. The SPS expect an immediate reply but set no time limit, and cut-offs and error handling belong to each bank's own offer (IG-SR v2.1 section 3.1.1; BR v3.2 section 1.4.2)." } ], "applies_to": "Swiss Payment Standards customer-to-bank status report (pain.002), on Swiss direct debit (pain.008) submissions only; Table 10 shades it grey and its entry names Swiss direct debit; A level: the whole message is rejected." }, "caveat": "SIX plans to discontinue the LSV+/BDD direct debit procedures on 30 September 2028 (BR v3.2 section 2.2). The SPS are a voluntary market practice. A bank may answer with any ISO status reason, with NARR plus its own text, or with a proprietary code, and handles faulty orders under its own customer terms (BR v3.2 section 1.4.2; IG-SR v2.1 section 3.2.4).", "related": [ "ch-sps-status:CH11", "ch-sps-status:MD01" ], "basis": { "sources": "SPS Implementation Guidelines Status Report (pain.002) v2.1 of 2024-02-20, SPS 2024 (IG-SR v2.1) sections 3.1.1, 3.2.3 and 3.2.4 Table 10 (payment-type shading read from the rendered page), Annex B Table 21; Implementation Guidelines Swiss Direct Debits (pain.008) v1.2 of 2018-04-06 (CH-DD IG v1.2) section 2.2.1; SPS Business Rules v3.2, SPS 2025 (BR v3.2) section 2.2 and section 1.4.2; SPS Implementation Guidelines Credit Transfer (pain.001) v2.2 of 2025-02-24, SPS 2025 (CT IG v2.2) section 3.8; IG-SR v2.2 of 2026-02-20, SPS 2026, section 3.2.4 Table 10 (unchanged).", "confidence": "high" }, "currency": { "effective_since": "2024-11-18", "effective_note": "IG-SR v2.1 (SPS 2024) applies from 2024-11-18 and is still the current pain.002 guide under SPS 2025, because SIX has published no SPS 2025 edition of it [Inference from the SIX download center, read 2026-09-18]. IG-SR v2.2 (SPS 2026, dated 2026-02-20) applies from 2026-11-14 and keeps this code in Table 10 with the same meaning and the same payment-type shading; that edition changes only tracker data and the status sequence annex. The SPS 2021 guide (v1.1.2, from 2021-11-19) also lists it and governs 2009-schema submissions until the November 2026 release. Use of the code before 2024-11-18 is not dated here [Unverified].", "source_edition": "IG-SR v2.1 (SPS 2024); IG-SR v2.2 (SPS 2026); CH-DD IG v1.2 (2018); BR v3.2 (SPS 2025); CT IG v2.2 (SPS 2025)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.six-group.com/dam/download/banking-services/standardization/sps/ig-status-report-sps2024-en.pdf", "source_class": "authoritative_primary", "source_title": "SPS Implementation Guidelines, Status Report (pain.002), SPS 2024, version 2.1, dated 2024-02-20, in force from 2024-11-18", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms RR12 is listed in Table 10 of the Status Report implementation guidelines with a meaning matching the record's summary, and Table 10 shades it gray with wording naming Swiss direct debit, meaning it is valid for Swiss direct debit submissions only. Table 10 is identical on this point in the v2.2 edition (SPS 2026, dated 2026-02-20, in force from 2026-11-14). Does not address triggers, actions or retry detail beyond the table entry." }, { "source_url": "https://www.six-group.com/dam/download/banking-services/standardization/sps/business-rules-sps-2025-en.pdf", "source_class": "authoritative_primary", "source_title": "SPS Business Rules for Payments and Cash Management, SPS 2025, version 3.2, dated 2025-02-24, in force from 2025-11-22", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms SPS Business Rules section 1.4.2 leaves cut-off times and the handling of erroneous orders and status reporting to each financial institution's own customer offering, rather than to the Swiss Payment Standards. Supports the RR12 record's return_windows claim that no SPS-wide deadline applies to sending this status reason, and supports the caveat that the SPS are a voluntary market practice. Does not itself list RR12 or its meaning." } ] }, "rail_name": "Swiss Payment Standards Status Report Reasons", "governing_authority": "SIX Interbank Clearing (Swiss Payment Standards)", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "judgement", "label": "your bank's own terms", "needs": "whose terms decide it: the bank's, the participant's or the scheme's", "detail": "A bank may answer with any ISO status reason, with NARR plus its own text, or with a proprietary code, and handles faulty orders under its own customer terms (BR v3.2 section 1.4.2; IG-SR v2.1 section 3.2.4).", "from": "caveat" } ] }, { "uid": "eps-error:002", "id": "002", "rail": "eps-error", "kind": "reason-code", "name": "Confirmation URL not usable", "group": "administrative", "summary": "The Scheme Operator refused the initiation because the ConfirmationUrl the merchant gave cannot be used, for example a local network address or a relative server address. The SO sends the vitality check and the payment confirmation to that URL, so it must be a full, reachable address.", "triggers": [ "ConfirmationUrl holds a local network address or a relative path", "ConfirmationUrl is incomplete or longer than 512 characters [Inference]" ], "actions": [ "Merchant: send the full public URL of the confirmation endpoint and initiate again" ], "retry": { "allowed": true, "rule": "After the URL is corrected; the refused initiation ended and nothing was debited." }, "facts": { "return_windows": [ { "action": "error response", "by": "Scheme Operator", "deadline": "In the response to the request itself: the Scheme Operator or the debtor bank puts the ErrorCode and an ErrorMsg in its answer (for an initiation, epsp:BankResponseDetails, forwarded to the merchant), with the prefix SO: when the SO wrote it. An initiation that draws an error is ended there." } ], "applies_to": "an eps payment" }, "caveat": "Same number, different list: eps uses the same three-digit numbers with other meanings in its error list, its status reason list and its refund error list, so read a code together with the list and message it came in.", "related": [], "basis": { "sources": "PSA, eps Standard Implementation Guideline version 2.7, read 2026-09-19: the general error table in section 4.10, the Scheme Operator's table in section 4.10 (which say who may send it). Only the SO table lists it; the bank lists in sections 6.5 and 7.1.4 do not. Meaning in Orca's own words; triggers, actions and retry guidance are Orca's reading of the workflow in section 7.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the eps documents read do not date it", "effective_to": null, "effective_note": "Drafted on 2026-09-19 from PSA's published eps documents. No document read says when this code entered the standard [Unverified].", "source_edition": "eps Standard Implementation Guideline version 2.7 (cover March 2025, file listed 2026-03-25), read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://eps-ueberweisung.at/de/download/eps-ueberweisung-dokumentation/send/2-eps-ueberweisung-dokumentation/31-eps-standard-implementation-guideline-v2-7", "source_class": "authoritative_primary", "source_title": "eps e-payment standard, Standard Implementation Guideline, version 2.7", "checked_on": "2026-09-19", "checked_by": "validator-2026-09-19", "notes": "Confirms 002 as a Scheme Operator only error for a confirmation URL that is a local network address or a relative server address." } ] }, "rail_name": "eps Payment Messages", "governing_authority": "PSA Payment Services Austria GmbH", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for eps payment (eps-Überweisung). Its own scope line reads: an eps payment.", "from": "applies_to" } ] }, { "uid": "eps-error:003", "id": "003", "rail": "eps-error", "kind": "reason-code", "name": "Currency not accepted", "group": "administrative", "summary": "The debtor bank refused the initiation over the currency given with the instructed amount. The guideline does not list accepted currencies; its examples and the refund service use euro only [Inference].", "triggers": [ "AmountCurrencyIdentifier is a currency the debtor bank does not accept" ], "actions": [ "Merchant: send the amount in euro with currency code EUR [Inference] and initiate again" ], "retry": { "allowed": true, "rule": "After the currency is corrected; nothing was debited." }, "facts": { "return_windows": [ { "action": "error response", "by": "Debtor bank", "deadline": "In the response to the request itself: the Scheme Operator or the debtor bank puts the ErrorCode and an ErrorMsg in its answer (for an initiation, epsp:BankResponseDetails, forwarded to the merchant), with the prefix SO: when the SO wrote it. An initiation that draws an error is ended there." } ], "applies_to": "an eps payment" }, "caveat": "Same number, different list: eps uses the same three-digit numbers with other meanings in its error list, its status reason list and its refund error list, so read a code together with the list and message it came in.", "related": [], "basis": { "sources": "PSA, eps Standard Implementation Guideline version 2.7, read 2026-09-19: the general error table in section 4.10, the debtor bank lists in sections 6.5 and 7.1.4 (which say who may send it). The SO table in section 4.10 does not list it, so only the debtor bank sends it. Meaning in Orca's own words; triggers, actions and retry guidance are Orca's reading of the workflow in section 7.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the eps documents read do not date it", "effective_to": null, "effective_note": "Drafted on 2026-09-19 from PSA's published eps documents. No document read says when this code entered the standard [Unverified].", "source_edition": "eps Standard Implementation Guideline version 2.7 (cover March 2025, file listed 2026-03-25), read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://eps-ueberweisung.at/de/download/eps-ueberweisung-dokumentation/send/2-eps-ueberweisung-dokumentation/31-eps-standard-implementation-guideline-v2-7", "source_class": "authoritative_primary", "source_title": "eps e-payment standard, Standard Implementation Guideline, version 2.7", "checked_on": "2026-09-19", "checked_by": "validator-2026-09-19", "notes": "Confirms 003 as a currency error the debtor bank's own response list carries, not the Scheme Operator's." } ] }, "rail_name": "eps Payment Messages", "governing_authority": "PSA Payment Services Austria GmbH", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for eps payment (eps-Überweisung). Its own scope line reads: an eps payment.", "from": "applies_to" } ] }, { "uid": "eps-error:004", "id": "004", "rail": "eps-error", "kind": "reason-code", "name": "Merchant identification failed", "group": "authorization", "summary": "The merchant could not be identified or authenticated. From the Scheme Operator this means the merchant is deleted, disabled or unknown, or the signature or fingerprint does not check out; a debtor bank may send it when the SO's own authentication toward it fails.", "triggers": [ "Merchant UserID unknown, deleted or disabled at the SO", "MD5 fingerprint or XML signature does not verify, for example a wrong merchant PIN or certificate" ], "actions": [ "Merchant: check the UserID, the merchant PIN used for the fingerprint, or the signing certificate; if the merchant is disabled, contact the creditor bank or acquirer" ], "retry": { "allowed": true, "rule": "Only after the credentials or the merchant's status are fixed; the same request draws the same error." }, "facts": { "return_windows": [ { "action": "error response", "by": "Scheme Operator or Debtor bank", "deadline": "In the response to the request itself: the Scheme Operator or the debtor bank puts the ErrorCode and an ErrorMsg in its answer (for an initiation, epsp:BankResponseDetails, forwarded to the merchant), with the prefix SO: when the SO wrote it. An initiation that draws an error is ended there." } ], "applies_to": "an eps payment" }, "caveat": "Same number, different list: eps uses the same three-digit numbers with other meanings in its error list, its status reason list and its refund error list, so read a code together with the list and message it came in.", "related": [], "basis": { "sources": "PSA, eps Standard Implementation Guideline version 2.7, read 2026-09-19: the general error table in section 4.10, the Scheme Operator's table in section 4.10; the debtor bank lists in sections 6.5 and 7.1.4 (which say who may send it). Meaning in Orca's own words; triggers, actions and retry guidance are Orca's reading of the workflow in section 7.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the eps documents read do not date it", "effective_to": null, "effective_note": "Drafted on 2026-09-19 from PSA's published eps documents. No document read says when this code entered the standard [Unverified].", "source_edition": "eps Standard Implementation Guideline version 2.7 (cover March 2025, file listed 2026-03-25), read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://eps-ueberweisung.at/de/download/eps-ueberweisung-dokumentation/send/2-eps-ueberweisung-dokumentation/31-eps-standard-implementation-guideline-v2-7", "source_class": "authoritative_primary", "source_title": "eps e-payment standard, Standard Implementation Guideline, version 2.7", "checked_on": "2026-09-19", "checked_by": "validator-2026-09-19", "notes": "Confirms 004 covers a merchant deleted, disabled or not found, or a signature or checksum that does not verify, and that both the Scheme Operator and the debtor bank may return it." } ] }, "rail_name": "eps Payment Messages", "governing_authority": "PSA Payment Services Austria GmbH", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for eps payment (eps-Überweisung). Its own scope line reads: an eps payment.", "from": "applies_to" } ] }, { "uid": "eps-error:007", "id": "007", "rail": "eps-error", "kind": "reason-code", "name": "Faulty XML message", "group": "technical", "summary": "The message could not be parsed or holds invalid content, such as a wrong content type or date specification code.", "triggers": [ "XML does not parse or does not validate against the current eps schema", "Content type other than text/xml, or an invalid code value" ], "actions": [ "Merchant: validate the message against the current eps XML schema, UTF-8 encoded, and send it again" ], "retry": { "allowed": true, "rule": "After the message is corrected; nothing was debited." }, "facts": { "return_windows": [ { "action": "error response", "by": "Scheme Operator or Debtor bank", "deadline": "In the response to the request itself: the Scheme Operator or the debtor bank puts the ErrorCode and an ErrorMsg in its answer (for an initiation, epsp:BankResponseDetails, forwarded to the merchant), with the prefix SO: when the SO wrote it. An initiation that draws an error is ended there." } ], "applies_to": "an eps payment" }, "caveat": "Same number, different list: eps uses the same three-digit numbers with other meanings in its error list, its status reason list and its refund error list, so read a code together with the list and message it came in.", "related": [], "basis": { "sources": "PSA, eps Standard Implementation Guideline version 2.7, read 2026-09-19: the general error table in section 4.10, the Scheme Operator's table in section 4.10; the debtor bank lists in sections 6.5 and 7.1.4 (which say who may send it). Meaning in Orca's own words; triggers, actions and retry guidance are Orca's reading of the workflow in section 7.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the eps documents read do not date it", "effective_to": null, "effective_note": "Drafted on 2026-09-19 from PSA's published eps documents. No document read says when this code entered the standard [Unverified].", "source_edition": "eps Standard Implementation Guideline version 2.7 (cover March 2025, file listed 2026-03-25), read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://eps-ueberweisung.at/de/download/eps-ueberweisung-dokumentation/send/2-eps-ueberweisung-dokumentation/31-eps-standard-implementation-guideline-v2-7", "source_class": "authoritative_primary", "source_title": "eps e-payment standard, Standard Implementation Guideline, version 2.7", "checked_on": "2026-09-19", "checked_by": "validator-2026-09-19", "notes": "Confirms 007 as an XML parsing or invalid content error, returnable by either the Scheme Operator or the debtor bank." } ] }, "rail_name": "eps Payment Messages", "governing_authority": "PSA Payment Services Austria GmbH", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for eps payment (eps-Überweisung). Its own scope line reads: an eps payment.", "from": "applies_to" } ] }, { "uid": "eps-error:008", "id": "008", "rail": "eps-error", "kind": "reason-code", "name": "Unknown error", "group": "technical", "summary": "A catch-all. From the Scheme Operator it covers faults such as the debtor bank not answering the initiation within the timeout, an unexpected HTTP status, a bank identifier or bank group the SO cannot find, an option the merchant is not enabled for, an invalid execution date, or a faulty call to the central bank selection.", "triggers": [ "Debtor bank did not answer the initiation within the SO timeout", "Unknown BIC or bank group, or an option not set up for the merchant" ], "actions": [ "Merchant: read ErrorMsg for the detail, fix what it names, and initiate again; if it persists, contact the creditor bank or acquirer" ], "retry": { "allowed": true, "rule": "A new initiation may be sent; after a bank timeout it may succeed later, after a set-up fault only once the fault is fixed." }, "facts": { "return_windows": [ { "action": "error response", "by": "Scheme Operator or Debtor bank", "deadline": "In the response to the request itself: the Scheme Operator or the debtor bank puts the ErrorCode and an ErrorMsg in its answer (for an initiation, epsp:BankResponseDetails, forwarded to the merchant), with the prefix SO: when the SO wrote it. An initiation that draws an error is ended there." } ], "applies_to": "an eps payment" }, "caveat": "Same number, different list: eps uses the same three-digit numbers with other meanings in its error list, its status reason list and its refund error list, so read a code together with the list and message it came in.", "related": [], "basis": { "sources": "PSA, eps Standard Implementation Guideline version 2.7, read 2026-09-19: the general error table in section 4.10, the Scheme Operator's table in section 4.10; the debtor bank lists in sections 6.5 and 7.1.4 (which say who may send it). Section 7.1.3 has the SO answer 008 when the debtor bank does not respond to the initiation in time. Meaning in Orca's own words; triggers, actions and retry guidance are Orca's reading of the workflow in section 7.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the eps documents read do not date it", "effective_to": null, "effective_note": "Drafted on 2026-09-19 from PSA's published eps documents. No document read says when this code entered the standard [Unverified].", "source_edition": "eps Standard Implementation Guideline version 2.7 (cover March 2025, file listed 2026-03-25), read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://eps-ueberweisung.at/de/download/eps-ueberweisung-dokumentation/send/2-eps-ueberweisung-dokumentation/31-eps-standard-implementation-guideline-v2-7", "source_class": "authoritative_primary", "source_title": "eps e-payment standard, Standard Implementation Guideline, version 2.7", "checked_on": "2026-09-19", "checked_by": "validator-2026-09-19", "notes": "Confirms 008 as a catch-all the Scheme Operator's own table ties to causes such as an http timeout, an unrecognised bank or bank group, or a faulty central bank selection call." } ] }, "rail_name": "eps Payment Messages", "governing_authority": "PSA Payment Services Austria GmbH", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for eps payment (eps-Überweisung). Its own scope line reads: an eps payment.", "from": "applies_to" } ] }, { "uid": "eps-error:009", "id": "009", "rail": "eps-error", "kind": "reason-code", "name": "Internal error", "group": "technical", "summary": "A general system error at the Scheme Operator or the debtor bank, not caused by the content of the request.", "triggers": [ "System fault at the SO or the debtor bank" ], "actions": [ "Merchant: offer the buyer a new eps payment a little later, or another method" ], "retry": { "allowed": true, "rule": "Later, unchanged; the fault is on the receiving side and nothing was debited." }, "facts": { "return_windows": [ { "action": "error response", "by": "Scheme Operator or Debtor bank", "deadline": "In the response to the request itself: the Scheme Operator or the debtor bank puts the ErrorCode and an ErrorMsg in its answer (for an initiation, epsp:BankResponseDetails, forwarded to the merchant), with the prefix SO: when the SO wrote it. An initiation that draws an error is ended there." } ], "applies_to": "an eps payment" }, "caveat": "Same number, different list: eps uses the same three-digit numbers with other meanings in its error list, its status reason list and its refund error list, so read a code together with the list and message it came in.", "related": [], "basis": { "sources": "PSA, eps Standard Implementation Guideline version 2.7, read 2026-09-19: the general error table in section 4.10, the Scheme Operator's table in section 4.10; the debtor bank lists in sections 6.5 and 7.1.4 (which say who may send it). Meaning in Orca's own words; triggers, actions and retry guidance are Orca's reading of the workflow in section 7.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the eps documents read do not date it", "effective_to": null, "effective_note": "Drafted on 2026-09-19 from PSA's published eps documents. No document read says when this code entered the standard [Unverified].", "source_edition": "eps Standard Implementation Guideline version 2.7 (cover March 2025, file listed 2026-03-25), read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://eps-ueberweisung.at/de/download/eps-ueberweisung-dokumentation/send/2-eps-ueberweisung-dokumentation/31-eps-standard-implementation-guideline-v2-7", "source_class": "authoritative_primary", "source_title": "eps e-payment standard, Standard Implementation Guideline, version 2.7", "checked_on": "2026-09-19", "checked_by": "validator-2026-09-19", "notes": "Confirms 009 as a general internal system error at the Scheme Operator or the debtor bank, not caused by the request's content." } ] }, "rail_name": "eps Payment Messages", "governing_authority": "PSA Payment Services Austria GmbH", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for eps payment (eps-Überweisung). Its own scope line reads: an eps payment.", "from": "applies_to" } ] }, { "uid": "eps-error:010", "id": "010", "rail": "eps-error", "kind": "reason-code", "name": "IBAN not valid for this merchant", "group": "account", "summary": "The beneficiary IBAN in the initiation is not valid or, from the Scheme Operator, is not an account registered for this merchant in the SO's merchant database.", "triggers": [ "BeneficiaryAccountIdentifier differs from the IBAN registered for the merchant at the SO", "Malformed IBAN" ], "actions": [ "Merchant: send the IBAN registered under the merchant contract, or have the creditor bank or acquirer register the account at the SO" ], "retry": { "allowed": true, "rule": "After the IBAN is corrected or registered; nothing was debited." }, "facts": { "return_windows": [ { "action": "error response", "by": "Scheme Operator or Debtor bank", "deadline": "In the response to the request itself: the Scheme Operator or the debtor bank puts the ErrorCode and an ErrorMsg in its answer (for an initiation, epsp:BankResponseDetails, forwarded to the merchant), with the prefix SO: when the SO wrote it. An initiation that draws an error is ended there." } ], "applies_to": "an eps payment" }, "caveat": "Same number, different list: eps uses the same three-digit numbers with other meanings in its error list, its status reason list and its refund error list, so read a code together with the list and message it came in.", "related": [], "basis": { "sources": "PSA, eps Standard Implementation Guideline version 2.7, read 2026-09-19: the general error table in section 4.10, the Scheme Operator's table in section 4.10; the debtor bank lists in sections 6.5 and 7.1.4 (which say who may send it). Section 7.1.2 lists the IBAN check among the SO's validations. Meaning in Orca's own words; triggers, actions and retry guidance are Orca's reading of the workflow in section 7.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the eps documents read do not date it", "effective_to": null, "effective_note": "Drafted on 2026-09-19 from PSA's published eps documents. No document read says when this code entered the standard [Unverified].", "source_edition": "eps Standard Implementation Guideline version 2.7 (cover March 2025, file listed 2026-03-25), read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://eps-ueberweisung.at/de/download/eps-ueberweisung-dokumentation/send/2-eps-ueberweisung-dokumentation/31-eps-standard-implementation-guideline-v2-7", "source_class": "authoritative_primary", "source_title": "eps e-payment standard, Standard Implementation Guideline, version 2.7", "checked_on": "2026-09-19", "checked_by": "validator-2026-09-19", "notes": "Confirms 010 as an invalid IBAN or one not registered for the merchant in the Scheme Operator's merchant database." } ] }, "rail_name": "eps Payment Messages", "governing_authority": "PSA Payment Services Austria GmbH", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for eps payment (eps-Überweisung). Its own scope line reads: an eps payment.", "from": "applies_to" } ] }, { "uid": "eps-error:011", "id": "011", "rail": "eps-error", "kind": "reason-code", "name": "BIC not valid", "group": "account", "summary": "A BIC in the initiation is not valid or, from the Scheme Operator, is not registered. The SO table does not say whether it means the beneficiary's bank or the chosen debtor bank [Unverified].", "triggers": [ "BfiBicIdentifier or the debtor bank BIC is malformed or not registered at the SO" ], "actions": [ "Merchant: use the creditor bank BIC from the merchant contract and a debtor bank BIC from the SO's current bank list" ], "retry": { "allowed": true, "rule": "After the BIC is corrected; nothing was debited." }, "facts": { "return_windows": [ { "action": "error response", "by": "Scheme Operator or Debtor bank", "deadline": "In the response to the request itself: the Scheme Operator or the debtor bank puts the ErrorCode and an ErrorMsg in its answer (for an initiation, epsp:BankResponseDetails, forwarded to the merchant), with the prefix SO: when the SO wrote it. An initiation that draws an error is ended there." } ], "applies_to": "an eps payment" }, "caveat": "Same number, different list: eps uses the same three-digit numbers with other meanings in its error list, its status reason list and its refund error list, so read a code together with the list and message it came in.", "related": [], "basis": { "sources": "PSA, eps Standard Implementation Guideline version 2.7, read 2026-09-19: the general error table in section 4.10, the Scheme Operator's table in section 4.10; the debtor bank lists in sections 6.5 and 7.1.4 (which say who may send it). Meaning in Orca's own words; triggers, actions and retry guidance are Orca's reading of the workflow in section 7.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the eps documents read do not date it", "effective_to": null, "effective_note": "Drafted on 2026-09-19 from PSA's published eps documents. No document read says when this code entered the standard [Unverified].", "source_edition": "eps Standard Implementation Guideline version 2.7 (cover March 2025, file listed 2026-03-25), read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://eps-ueberweisung.at/de/download/eps-ueberweisung-dokumentation/send/2-eps-ueberweisung-dokumentation/31-eps-standard-implementation-guideline-v2-7", "source_class": "authoritative_primary", "source_title": "eps e-payment standard, Standard Implementation Guideline, version 2.7", "checked_on": "2026-09-19", "checked_by": "validator-2026-09-19", "notes": "Confirms 011 as an invalid or unregistered BIC in the initiation, and that the guideline's table does not say whether it is the beneficiary's bank or the debtor bank." } ] }, "rail_name": "eps Payment Messages", "governing_authority": "PSA Payment Services Austria GmbH", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for eps payment (eps-Überweisung). Its own scope line reads: an eps payment.", "from": "applies_to" } ] }, { "uid": "eps-error:012", "id": "012", "rail": "eps-error", "kind": "reason-code", "name": "Expiration or execution time not valid", "group": "administrative", "summary": "The expiration time or the execution date in the initiation is outside what is allowed, or has already passed. The merchant may set an expiration time from 5 to 60 minutes after the initiation.", "triggers": [ "ExpirationTime less than 5 or more than 60 minutes after the initiation, or already past", "An execution date the bank or the merchant's set-up does not allow" ], "actions": [ "Merchant: send an absolute time with time zone inside the window, or leave it out so the SO applies 60 minutes; check the server clock" ], "retry": { "allowed": true, "rule": "After the time is corrected; nothing was debited." }, "facts": { "return_windows": [ { "action": "error response", "by": "Scheme Operator or Debtor bank", "deadline": "In the response to the request itself: the Scheme Operator or the debtor bank puts the ErrorCode and an ErrorMsg in its answer (for an initiation, epsp:BankResponseDetails, forwarded to the merchant), with the prefix SO: when the SO wrote it. An initiation that draws an error is ended there." } ], "applies_to": "an eps payment" }, "caveat": "Same number, different list: eps uses the same three-digit numbers with other meanings in its error list, its status reason list and its refund error list, so read a code together with the list and message it came in. In the refund error list 012 means a request creation time more than 3 hours off.", "related": [ "eps-refund-error:012" ], "basis": { "sources": "PSA, eps Standard Implementation Guideline version 2.7, read 2026-09-19: the general error table in section 4.10, the Scheme Operator's table in section 4.10; the debtor bank lists in sections 6.5 and 7.1.4 (which say who may send it). Meaning in Orca's own words; triggers, actions and retry guidance are Orca's reading of the workflow in section 7.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the eps documents read do not date it", "effective_to": null, "effective_note": "Drafted on 2026-09-19 from PSA's published eps documents. No document read says when this code entered the standard [Unverified].", "source_edition": "eps Standard Implementation Guideline version 2.7 (cover March 2025, file listed 2026-03-25), read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://eps-ueberweisung.at/de/download/eps-ueberweisung-dokumentation/send/2-eps-ueberweisung-dokumentation/31-eps-standard-implementation-guideline-v2-7", "source_class": "authoritative_primary", "source_title": "eps e-payment standard, Standard Implementation Guideline, version 2.7", "checked_on": "2026-09-19", "checked_by": "validator-2026-09-19", "notes": "Confirms 012 as an expiration or execution time that is invalid or has passed, matching the guideline's 5 to 60 minute merchant-set window." } ] }, "rail_name": "eps Payment Messages", "governing_authority": "PSA Payment Services Austria GmbH", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for eps payment (eps-Überweisung). Its own scope line reads: an eps payment.", "from": "applies_to" } ] }, { "uid": "eps-error:013", "id": "013", "rail": "eps-error", "kind": "reason-code", "name": "Cross-border transaction not allowed", "group": "administrative", "summary": "The Scheme Operator refused the initiation as a cross-border transaction it does not allow. Only the SO may send this code, never a debtor bank. The guideline does not define which cross-border element triggers it, the merchant's account, a bank, or the buyer's account [Unverified].", "triggers": [ "A cross-border element the SO does not permit [Unverified: not defined in the guideline]" ], "actions": [ "Merchant: ask the creditor bank or acquirer which cross-border cases the merchant contract excludes, and offer the buyer another method" ], "retry": { "allowed": false, "rule": "Not with the same parties and accounts: the refusal rests on what the payment is, not on a passing fault." }, "facts": { "return_windows": [ { "action": "error response", "by": "Scheme Operator", "deadline": "In the response to the request itself: the Scheme Operator or the debtor bank puts the ErrorCode and an ErrorMsg in its answer (for an initiation, epsp:BankResponseDetails, forwarded to the merchant), with the prefix SO: when the SO wrote it. An initiation that draws an error is ended there." } ], "applies_to": "an eps payment" }, "caveat": "Same number, different list: eps uses the same three-digit numbers with other meanings in its error list, its status reason list and its refund error list, so read a code together with the list and message it came in. PSA's consumer FAQ says a buyer can pay from anywhere they can reach their account online; that is about where the buyer sits, not what this code bars [Inference].", "related": [ "eps-refund-error:013" ], "basis": { "sources": "PSA, eps Standard Implementation Guideline version 2.7, read 2026-09-19: the general error table in section 4.10, the Scheme Operator's table in section 4.10 (which say who may send it). The note on paying from abroad is from PSA's Privatkunden page FAQ, read 2026-09-19. Meaning in Orca's own words; triggers, actions and retry guidance are Orca's reading of the workflow in section 7.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the eps documents read do not date it", "effective_to": null, "effective_note": "Drafted on 2026-09-19 from PSA's published eps documents. No document read says when this code entered the standard [Unverified].", "source_edition": "eps Standard Implementation Guideline version 2.7 (cover March 2025, file listed 2026-03-25), read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://eps-ueberweisung.at/de/download/eps-ueberweisung-dokumentation/send/2-eps-ueberweisung-dokumentation/31-eps-standard-implementation-guideline-v2-7", "source_class": "authoritative_primary", "source_title": "eps e-payment standard, Standard Implementation Guideline, version 2.7", "checked_on": "2026-09-19", "checked_by": "validator-2026-09-19", "notes": "Confirms 013 is explicitly marked for use by the Scheme Operator only, never the debtor bank, with no cross-border case defined." } ] }, "rail_name": "eps Payment Messages", "governing_authority": "PSA Payment Services Austria GmbH", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for eps payment (eps-Überweisung). Its own scope line reads: an eps payment.", "from": "applies_to" } ] }, { "uid": "eps-error:014", "id": "014", "rail": "eps-error", "kind": "reason-code", "name": "Bank or online banking not reachable", "group": "network", "summary": "The debtor bank or its online banking could not be reached, for example during maintenance, so the initiation was ended. The Scheme Operator sends it when the bank does not answer; a bank may also send it for its own online banking service.", "triggers": [ "Debtor bank or online banking down for maintenance or not answering" ], "actions": [ "Merchant: tell the buyer their bank is not available just now and offer a new eps payment later or another method" ], "retry": { "allowed": true, "rule": "Later; the bank side was unreachable and nothing was debited." }, "facts": { "return_windows": [ { "action": "error response", "by": "Scheme Operator or Debtor bank", "deadline": "In the response to the request itself: the Scheme Operator or the debtor bank puts the ErrorCode and an ErrorMsg in its answer (for an initiation, epsp:BankResponseDetails, forwarded to the merchant), with the prefix SO: when the SO wrote it. An initiation that draws an error is ended there." } ], "applies_to": "an eps payment" }, "caveat": "Same number, different list: eps uses the same three-digit numbers with other meanings in its error list, its status reason list and its refund error list, so read a code together with the list and message it came in.", "related": [], "basis": { "sources": "PSA, eps Standard Implementation Guideline version 2.7, read 2026-09-19: the general error table in section 4.10, the Scheme Operator's table in section 4.10; the debtor bank lists in sections 6.5 and 7.1.4 (which say who may send it). Section 7.1.5 has the SO forward 014 when the debtor bank is unreachable. Group network rather than technical because the fault is reaching the bank, not a message or system error. Meaning in Orca's own words; triggers, actions and retry guidance are Orca's reading of the workflow in section 7.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the eps documents read do not date it", "effective_to": null, "effective_note": "Drafted on 2026-09-19 from PSA's published eps documents. No document read says when this code entered the standard [Unverified].", "source_edition": "eps Standard Implementation Guideline version 2.7 (cover March 2025, file listed 2026-03-25), read 2026-09-19", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "rail_name": "eps Payment Messages", "governing_authority": "PSA Payment Services Austria GmbH", "snapshot": "2026-09-19", "source_class": null, "effective_status": "draft", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for eps payment (eps-Überweisung). Its own scope line reads: an eps payment.", "from": "applies_to" } ] }, { "uid": "eps-error:015", "id": "015", "rail": "eps-error", "kind": "reason-code", "name": "Bank selection not allowed", "group": "administrative", "summary": "The debtor bank the merchant pre-selected may not be used, for example because it is not an active eps bank in the Scheme Operator's list [Inference].", "triggers": [ "Merchant addressed a debtor bank by BIC or bank group that the SO does not allow" ], "actions": [ "Merchant: refresh the bank list from the SO, or use the SO's central bank selection, and initiate again" ], "retry": { "allowed": true, "rule": "After the bank selection is corrected; nothing was debited." }, "facts": { "return_windows": [ { "action": "error response", "by": "Scheme Operator or Debtor bank", "deadline": "In the response to the request itself: the Scheme Operator or the debtor bank puts the ErrorCode and an ErrorMsg in its answer (for an initiation, epsp:BankResponseDetails, forwarded to the merchant), with the prefix SO: when the SO wrote it. An initiation that draws an error is ended there." } ], "applies_to": "an eps payment" }, "caveat": "Same number, different list: eps uses the same three-digit numbers with other meanings in its error list, its status reason list and its refund error list, so read a code together with the list and message it came in.", "related": [ "eps-refund-error:015" ], "basis": { "sources": "PSA, eps Standard Implementation Guideline version 2.7, read 2026-09-19: the general error table in section 4.10, the Scheme Operator's table in section 4.10; the debtor bank lists in sections 6.5 and 7.1.4 (which say who may send it). Meaning in Orca's own words; triggers, actions and retry guidance are Orca's reading of the workflow in section 7.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the eps documents read do not date it", "effective_to": null, "effective_note": "Drafted on 2026-09-19 from PSA's published eps documents. No document read says when this code entered the standard [Unverified].", "source_edition": "eps Standard Implementation Guideline version 2.7 (cover March 2025, file listed 2026-03-25), read 2026-09-19", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "rail_name": "eps Payment Messages", "governing_authority": "PSA Payment Services Austria GmbH", "snapshot": "2026-09-19", "source_class": null, "effective_status": "draft", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for eps payment (eps-Überweisung). Its own scope line reads: an eps payment.", "from": "applies_to" } ] }, { "uid": "eps-error:020", "id": "020", "rail": "eps-error", "kind": "reason-code", "name": "Transaction ID not known", "group": "administrative", "summary": "The Scheme Operator does not know the TransactionId sent in a transaction details request or a confirmation status request. A details request is also refused with 020 once the SO holds a confirmation for that transaction.", "triggers": [ "Unknown or mistyped TransactionId", "Details requested for a transaction the SO already has a confirmation for" ], "actions": [ "Merchant: check the TransactionId from the bank response", "Debtor bank: stop fetching details for a transaction already confirmed" ], "retry": { "allowed": true, "rule": "Only with the correct TransactionId; a details request for a confirmed transaction keeps drawing 020." }, "facts": { "return_windows": [ { "action": "error response", "by": "Scheme Operator", "deadline": "In the response to the request itself: the Scheme Operator or the debtor bank puts the ErrorCode and an ErrorMsg in its answer (for an initiation, epsp:BankResponseDetails, forwarded to the merchant), with the prefix SO: when the SO wrote it. An initiation that draws an error is ended there." } ], "applies_to": "an eps payment" }, "caveat": "Same number, different list: eps uses the same three-digit numbers with other meanings in its error list, its status reason list and its refund error list, so read a code together with the list and message it came in.", "related": [ "eps-refund-error:020" ], "basis": { "sources": "PSA, eps Standard Implementation Guideline version 2.7, read 2026-09-19: the general error table in section 4.10, the Scheme Operator's table in section 4.10 (which say who may send it). Section 6.9 adds the refusal of details requests once a confirmation exists. Meaning in Orca's own words; triggers, actions and retry guidance are Orca's reading of the workflow in section 7.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the eps documents read do not date it", "effective_to": null, "effective_note": "Drafted on 2026-09-19 from PSA's published eps documents. No document read says when this code entered the standard [Unverified].", "source_edition": "eps Standard Implementation Guideline version 2.7 (cover March 2025, file listed 2026-03-25), read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://eps-ueberweisung.at/de/download/eps-ueberweisung-dokumentation/send/2-eps-ueberweisung-dokumentation/31-eps-standard-implementation-guideline-v2-7", "source_class": "authoritative_primary", "source_title": "eps e-payment standard, Standard Implementation Guideline, version 2.7", "checked_on": "2026-09-19", "checked_by": "validator-2026-09-19", "notes": "Confirms 020 as an unknown transaction ID in a transaction details or confirmation status request." } ] }, "rail_name": "eps Payment Messages", "governing_authority": "PSA Payment Services Austria GmbH", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for eps payment (eps-Überweisung). Its own scope line reads: an eps payment.", "from": "applies_to" } ] }, { "uid": "eps-error:021", "id": "021", "rail": "eps-error", "kind": "reason-code", "name": "Transaction not completed yet", "group": "administrative", "summary": "At the time of a confirmation status request the payment was still in progress, so the Scheme Operator has no final status to report yet.", "triggers": [ "Confirmation status request sent while the buyer is still in online banking or the bank has not yet confirmed" ], "actions": [ "Merchant: ask again later, within 42 days of processing, and do not treat the payment as failed or start a second one meanwhile" ], "retry": { "allowed": true, "rule": "Later: ask again once the payment has had time to finish." }, "facts": { "return_windows": [ { "action": "error response", "by": "Scheme Operator", "deadline": "In the response to the request itself: the Scheme Operator or the debtor bank puts the ErrorCode and an ErrorMsg in its answer (for an initiation, epsp:BankResponseDetails, forwarded to the merchant), with the prefix SO: when the SO wrote it. An initiation that draws an error is ended there." } ], "applies_to": "an eps payment" }, "caveat": "Same number, different list: eps uses the same three-digit numbers with other meanings in its error list, its status reason list and its refund error list, so read a code together with the list and message it came in. 021 is also a status reason (payment still ongoing) and a refund error (original payment not completed).", "related": [ "eps-status-reason:021", "eps-refund-error:021" ], "basis": { "sources": "PSA, eps Standard Implementation Guideline version 2.7, read 2026-09-19: the general error table in section 4.10, the Scheme Operator's table in section 4.10 (which say who may send it). Meaning in Orca's own words; triggers, actions and retry guidance are Orca's reading of the workflow in section 7.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the eps documents read do not date it", "effective_to": null, "effective_note": "Drafted on 2026-09-19 from PSA's published eps documents. No document read says when this code entered the standard [Unverified].", "source_edition": "eps Standard Implementation Guideline version 2.7 (cover March 2025, file listed 2026-03-25), read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://eps-ueberweisung.at/de/download/eps-ueberweisung-dokumentation/send/2-eps-ueberweisung-dokumentation/31-eps-standard-implementation-guideline-v2-7", "source_class": "authoritative_primary", "source_title": "eps e-payment standard, Standard Implementation Guideline, version 2.7", "checked_on": "2026-09-19", "checked_by": "validator-2026-09-19", "notes": "Confirms 021 as a confirmation status request answered while the transaction was still ongoing and not yet completed." } ] }, "rail_name": "eps Payment Messages", "governing_authority": "PSA Payment Services Austria GmbH", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for eps payment (eps-Überweisung). Its own scope line reads: an eps payment.", "from": "applies_to" } ] }, { "uid": "eps-refund-error:004", "id": "004", "rail": "eps-refund-error", "kind": "reason-code", "name": "Merchant authorisation failed", "group": "authorization", "summary": "The Scheme Operator could not authorise the refund request: the merchant is deleted, blocked or not found, or the checksum does not verify.", "triggers": [ "Unknown, deleted or blocked merchant", "SHA-256 fingerprint or signature does not verify, for example a wrong merchant PIN" ], "actions": [ "Merchant: check the UserId, the PIN and the fields that go into the fingerprint, and send the request again" ], "retry": { "allowed": true, "rule": "After the credentials are fixed; no payment order was created." }, "facts": { "return_windows": [ { "action": "refund request refused", "by": "Scheme Operator", "deadline": "In the EpsRefundResponse that answers the refund request: the Scheme Operator returns 000 when the merchant's bank accepted the order, or an error code with an ErrorMsg, in which case no payment order exists." } ], "applies_to": "an eps refund request" }, "caveat": "Same number, different list: eps uses the same three-digit numbers with other meanings in its error list, its status reason list and its refund error list, so read a code together with the list and message it came in.", "related": [], "basis": { "sources": "PSA, eps Refundierung version 1.0.1, read 2026-09-19: the refund error code tables in section 4.6 and the refund response in section 7.2; the SO's checks in section 8.1. The source is in German; the meaning is paraphrased in English in Orca's own words, and triggers, actions and retry guidance are Orca's reading.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the eps documents read do not date it", "effective_to": null, "effective_note": "Drafted on 2026-09-19 from PSA's published eps documents. No document read says when this code entered the standard [Unverified].", "source_edition": "eps Refundierung version 1.0.1 (22 October 2018, file listed 2022-09-01), read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://eps-ueberweisung.at/de/download/eps-ueberweisung-dokumentation/send/2-eps-ueberweisung-dokumentation/16-eps-refundierung-dokumentation", "source_class": "authoritative_primary", "source_title": "eps Refundierung, version 1.0.1", "checked_on": "2026-09-19", "checked_by": "validator-2026-09-19", "notes": "Confirms refund error 004 as the merchant deleted, blocked or not found, or the checksum not verifying." } ] }, "rail_name": "eps Refunds", "governing_authority": "PSA Payment Services Austria GmbH", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for eps refund. Its own scope line reads: an eps refund request.", "from": "applies_to" } ] }, { "uid": "eps-refund-error:007", "id": "007", "rail": "eps-refund-error", "kind": "reason-code", "name": "Faulty XML message", "group": "technical", "summary": "The refund request could not be parsed or holds invalid content.", "triggers": [ "XML does not parse or does not validate against the refund schema", "Wrong content type or code value" ], "actions": [ "Merchant: validate the request against the eps refund schema and send it again" ], "retry": { "allowed": true, "rule": "After the message is corrected; no payment order was created." }, "facts": { "return_windows": [ { "action": "refund request refused", "by": "Scheme Operator", "deadline": "In the EpsRefundResponse that answers the refund request: the Scheme Operator returns 000 when the merchant's bank accepted the order, or an error code with an ErrorMsg, in which case no payment order exists." } ], "applies_to": "an eps refund request" }, "caveat": "Same number, different list: eps uses the same three-digit numbers with other meanings in its error list, its status reason list and its refund error list, so read a code together with the list and message it came in.", "related": [], "basis": { "sources": "PSA, eps Refundierung version 1.0.1, read 2026-09-19: the refund error code tables in section 4.6 and the refund response in section 7.2; the SO's checks in section 8.1. The source is in German; the meaning is paraphrased in English in Orca's own words, and triggers, actions and retry guidance are Orca's reading.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the eps documents read do not date it", "effective_to": null, "effective_note": "Drafted on 2026-09-19 from PSA's published eps documents. No document read says when this code entered the standard [Unverified].", "source_edition": "eps Refundierung version 1.0.1 (22 October 2018, file listed 2022-09-01), read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://eps-ueberweisung.at/de/download/eps-ueberweisung-dokumentation/send/2-eps-ueberweisung-dokumentation/16-eps-refundierung-dokumentation", "source_class": "authoritative_primary", "source_title": "eps Refundierung, version 1.0.1", "checked_on": "2026-09-19", "checked_by": "validator-2026-09-19", "notes": "Confirms refund error 007 as an XML parsing error or invalid content in the refund request." } ] }, "rail_name": "eps Refunds", "governing_authority": "PSA Payment Services Austria GmbH", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for eps refund. Its own scope line reads: an eps refund request.", "from": "applies_to" } ] }, { "uid": "eps-refund-error:009", "id": "009", "rail": "eps-refund-error", "kind": "reason-code", "name": "Internal error at the Scheme Operator", "group": "technical", "summary": "A general system error at the Scheme Operator, not caused by the content of the request.", "triggers": [ "System fault at the SO" ], "actions": [ "Merchant: send the request again later" ], "retry": { "allowed": true, "rule": "Later, unchanged; no payment order was created." }, "facts": { "return_windows": [ { "action": "refund request refused", "by": "Scheme Operator", "deadline": "In the EpsRefundResponse that answers the refund request: the Scheme Operator returns 000 when the merchant's bank accepted the order, or an error code with an ErrorMsg, in which case no payment order exists." } ], "applies_to": "an eps refund request" }, "caveat": "Same number, different list: eps uses the same three-digit numbers with other meanings in its error list, its status reason list and its refund error list, so read a code together with the list and message it came in.", "related": [], "basis": { "sources": "PSA, eps Refundierung version 1.0.1, read 2026-09-19: the refund error code tables in section 4.6 and the refund response in section 7.2; the SO's checks in section 8.1. The source is in German; the meaning is paraphrased in English in Orca's own words, and triggers, actions and retry guidance are Orca's reading.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the eps documents read do not date it", "effective_to": null, "effective_note": "Drafted on 2026-09-19 from PSA's published eps documents. No document read says when this code entered the standard [Unverified].", "source_edition": "eps Refundierung version 1.0.1 (22 October 2018, file listed 2022-09-01), read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://eps-ueberweisung.at/de/download/eps-ueberweisung-dokumentation/send/2-eps-ueberweisung-dokumentation/16-eps-refundierung-dokumentation", "source_class": "authoritative_primary", "source_title": "eps Refundierung, version 1.0.1", "checked_on": "2026-09-19", "checked_by": "validator-2026-09-19", "notes": "Confirms refund error 009 as a general internal system error at the Scheme Operator." } ] }, "rail_name": "eps Refunds", "governing_authority": "PSA Payment Services Austria GmbH", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for eps refund. Its own scope line reads: an eps refund request.", "from": "applies_to" } ] }, { "uid": "eps-refund-error:010", "id": "010", "rail": "eps-refund-error", "kind": "reason-code", "name": "Merchant IBAN not valid or not registered", "group": "account", "summary": "The merchant IBAN named as the account to pay the refund from is invalid, or is not among the accounts registered for the merchant at the Scheme Operator.", "triggers": [ "MerchantIBAN malformed or not in the merchant's data at the SO" ], "actions": [ "Merchant: use an IBAN registered for the merchant at the SO, or ask the merchant's bank to register the account" ], "retry": { "allowed": true, "rule": "After a registered IBAN is used; no payment order was created." }, "facts": { "return_windows": [ { "action": "refund request refused", "by": "Scheme Operator", "deadline": "In the EpsRefundResponse that answers the refund request: the Scheme Operator returns 000 when the merchant's bank accepted the order, or an error code with an ErrorMsg, in which case no payment order exists." } ], "applies_to": "an eps refund request" }, "caveat": "Same number, different list: eps uses the same three-digit numbers with other meanings in its error list, its status reason list and its refund error list, so read a code together with the list and message it came in.", "related": [], "basis": { "sources": "PSA, eps Refundierung version 1.0.1, read 2026-09-19: the refund error code tables in section 4.6 and the refund response in section 7.2; the SO's checks in section 8.1. The source is in German; the meaning is paraphrased in English in Orca's own words, and triggers, actions and retry guidance are Orca's reading.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the eps documents read do not date it", "effective_to": null, "effective_note": "Drafted on 2026-09-19 from PSA's published eps documents. No document read says when this code entered the standard [Unverified].", "source_edition": "eps Refundierung version 1.0.1 (22 October 2018, file listed 2022-09-01), read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://eps-ueberweisung.at/de/download/eps-ueberweisung-dokumentation/send/2-eps-ueberweisung-dokumentation/16-eps-refundierung-dokumentation", "source_class": "authoritative_primary", "source_title": "eps Refundierung, version 1.0.1", "checked_on": "2026-09-19", "checked_by": "validator-2026-09-19", "notes": "Confirms refund error 010 as the merchant IBAN being invalid or not configured in the merchant's data at the Scheme Operator." } ] }, "rail_name": "eps Refunds", "governing_authority": "PSA Payment Services Austria GmbH", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for eps refund. Its own scope line reads: an eps refund request.", "from": "applies_to" } ] }, { "uid": "eps-refund-error:011", "id": "011", "rail": "eps-refund-error", "kind": "reason-code", "name": "No routing for the merchant's bank", "group": "account", "summary": "The Scheme Operator found no routing information for the merchant's bank, so it cannot deliver a refund order to it.", "triggers": [ "Merchant's bank not set up at the SO to receive refund orders [Inference]" ], "actions": [ "Merchant: ask the merchant's bank to complete its refund set-up at the SO" ], "retry": { "allowed": true, "rule": "Only after the merchant's bank routing is set up at the SO." }, "facts": { "return_windows": [ { "action": "refund request refused", "by": "Scheme Operator", "deadline": "In the EpsRefundResponse that answers the refund request: the Scheme Operator returns 000 when the merchant's bank accepted the order, or an error code with an ErrorMsg, in which case no payment order exists." } ], "applies_to": "an eps refund request" }, "caveat": "Same number, different list: eps uses the same three-digit numbers with other meanings in its error list, its status reason list and its refund error list, so read a code together with the list and message it came in.", "related": [], "basis": { "sources": "PSA, eps Refundierung version 1.0.1, read 2026-09-19: the refund error code tables in section 4.6 and the refund response in section 7.2; the SO's checks in section 8.1. The source is in German; the meaning is paraphrased in English in Orca's own words, and triggers, actions and retry guidance are Orca's reading.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the eps documents read do not date it", "effective_to": null, "effective_note": "Drafted on 2026-09-19 from PSA's published eps documents. No document read says when this code entered the standard [Unverified].", "source_edition": "eps Refundierung version 1.0.1 (22 October 2018, file listed 2022-09-01), read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://eps-ueberweisung.at/de/download/eps-ueberweisung-dokumentation/send/2-eps-ueberweisung-dokumentation/16-eps-refundierung-dokumentation", "source_class": "authoritative_primary", "source_title": "eps Refundierung, version 1.0.1", "checked_on": "2026-09-19", "checked_by": "validator-2026-09-19", "notes": "Confirms refund error 011 as no routing information found for the merchant's bank." } ] }, "rail_name": "eps Refunds", "governing_authority": "PSA Payment Services Austria GmbH", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for eps refund. Its own scope line reads: an eps refund request.", "from": "applies_to" } ] }, { "uid": "eps-refund-error:012", "id": "012", "rail": "eps-refund-error", "kind": "reason-code", "name": "Request time more than 3 hours off", "group": "administrative", "summary": "The creation time in the refund request is more than 3 hours away from the Scheme Operator's server time.", "triggers": [ "CreDtTm stale, in the future, or in the wrong time zone", "Merchant server clock out of sync" ], "actions": [ "Merchant: set CreDtTm to the current time with time zone, synchronise the server clock, and send the request again" ], "retry": { "allowed": true, "rule": "With a fresh creation time; no payment order was created." }, "facts": { "return_windows": [ { "action": "refund request refused", "by": "Scheme Operator", "deadline": "In the EpsRefundResponse that answers the refund request: the Scheme Operator returns 000 when the merchant's bank accepted the order, or an error code with an ErrorMsg, in which case no payment order exists." } ], "applies_to": "an eps refund request" }, "caveat": "Same number, different list: eps uses the same three-digit numbers with other meanings in its error list, its status reason list and its refund error list, so read a code together with the list and message it came in. In the eps error list 012 means an invalid expiration or execution time.", "related": [ "eps-error:012" ], "basis": { "sources": "PSA, eps Refundierung version 1.0.1, read 2026-09-19: the refund error code tables in section 4.6 and the refund response in section 7.2; the SO's checks in section 8.1. The source is in German; the meaning is paraphrased in English in Orca's own words, and triggers, actions and retry guidance are Orca's reading.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the eps documents read do not date it", "effective_to": null, "effective_note": "Drafted on 2026-09-19 from PSA's published eps documents. No document read says when this code entered the standard [Unverified].", "source_edition": "eps Refundierung version 1.0.1 (22 October 2018, file listed 2022-09-01), read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://eps-ueberweisung.at/de/download/eps-ueberweisung-dokumentation/send/2-eps-ueberweisung-dokumentation/16-eps-refundierung-dokumentation", "source_class": "authoritative_primary", "source_title": "eps Refundierung, version 1.0.1", "checked_on": "2026-09-19", "checked_by": "validator-2026-09-19", "notes": "Confirms refund error 012 as the request's creation time differing from the Scheme Operator's server time by more than 3 hours." } ] }, "rail_name": "eps Refunds", "governing_authority": "PSA Payment Services Austria GmbH", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for eps refund. Its own scope line reads: an eps refund request.", "from": "applies_to" } ] }, { "uid": "eps-refund-error:013", "id": "013", "rail": "eps-refund-error", "kind": "reason-code", "name": "Cross-border order not allowed", "group": "administrative", "summary": "The Scheme Operator refused the refund as a cross-border order it does not allow. The refund specification lists the code without explaining which cross-border case it covers [Unverified].", "triggers": [ "A cross-border element the SO does not permit [Unverified: not explained in the specification]" ], "actions": [ "Merchant: ask the merchant's bank which cases are excluded, and repay the buyer outside eps if needed" ], "retry": { "allowed": false, "rule": "Not with the same accounts: the refusal rests on what the order is, not on a passing fault." }, "facts": { "return_windows": [ { "action": "refund request refused", "by": "Scheme Operator", "deadline": "In the EpsRefundResponse that answers the refund request: the Scheme Operator returns 000 when the merchant's bank accepted the order, or an error code with an ErrorMsg, in which case no payment order exists." } ], "applies_to": "an eps refund request" }, "caveat": "Same number, different list: eps uses the same three-digit numbers with other meanings in its error list, its status reason list and its refund error list, so read a code together with the list and message it came in.", "related": [ "eps-error:013" ], "basis": { "sources": "PSA, eps Refundierung version 1.0.1, read 2026-09-19: the refund error code tables in section 4.6 and the refund response in section 7.2; the SO's checks in section 8.1. The source is in German; the meaning is paraphrased in English in Orca's own words, and triggers, actions and retry guidance are Orca's reading.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the eps documents read do not date it", "effective_to": null, "effective_note": "Drafted on 2026-09-19 from PSA's published eps documents. No document read says when this code entered the standard [Unverified].", "source_edition": "eps Refundierung version 1.0.1 (22 October 2018, file listed 2022-09-01), read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://eps-ueberweisung.at/de/download/eps-ueberweisung-dokumentation/send/2-eps-ueberweisung-dokumentation/16-eps-refundierung-dokumentation", "source_class": "authoritative_primary", "source_title": "eps Refundierung, version 1.0.1", "checked_on": "2026-09-19", "checked_by": "validator-2026-09-19", "notes": "Confirms refund error 013 as a cross-border order the Scheme Operator does not allow, with no case defined." } ] }, "rail_name": "eps Refunds", "governing_authority": "PSA Payment Services Austria GmbH", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for eps refund. Its own scope line reads: an eps refund request.", "from": "applies_to" } ] }, { "uid": "eps-refund-error:015", "id": "015", "rail": "eps-refund-error", "kind": "reason-code", "name": "Merchant's bank not set up for refunds", "group": "administrative", "summary": "The merchant's bank is not yet correctly configured for refunds at the Scheme Operator. The code keeps the name of the payment error it shares a number with, an invalid bank selection, but in a refund it concerns the merchant's bank.", "triggers": [ "Merchant's bank has not completed its refund configuration at the SO" ], "actions": [ "Merchant: ask the merchant's bank to enable refunds at the SO" ], "retry": { "allowed": true, "rule": "Only after the merchant's bank has completed its set-up; no payment order was created." }, "facts": { "return_windows": [ { "action": "refund request refused", "by": "Scheme Operator", "deadline": "In the EpsRefundResponse that answers the refund request: the Scheme Operator returns 000 when the merchant's bank accepted the order, or an error code with an ErrorMsg, in which case no payment order exists." } ], "applies_to": "an eps refund request" }, "caveat": "Same number, different list: eps uses the same three-digit numbers with other meanings in its error list, its status reason list and its refund error list, so read a code together with the list and message it came in.", "related": [ "eps-error:015" ], "basis": { "sources": "PSA, eps Refundierung version 1.0.1, read 2026-09-19: the refund error code tables in section 4.6 and the refund response in section 7.2; the SO's checks in section 8.1. The source is in German; the meaning is paraphrased in English in Orca's own words, and triggers, actions and retry guidance are Orca's reading.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the eps documents read do not date it", "effective_to": null, "effective_note": "Drafted on 2026-09-19 from PSA's published eps documents. No document read says when this code entered the standard [Unverified].", "source_edition": "eps Refundierung version 1.0.1 (22 October 2018, file listed 2022-09-01), read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://eps-ueberweisung.at/de/download/eps-ueberweisung-dokumentation/send/2-eps-ueberweisung-dokumentation/16-eps-refundierung-dokumentation", "source_class": "authoritative_primary", "source_title": "eps Refundierung, version 1.0.1", "checked_on": "2026-09-19", "checked_by": "validator-2026-09-19", "notes": "Confirms refund error 015 as the merchant's bank not yet correctly configured for the refund transaction." } ] }, "rail_name": "eps Refunds", "governing_authority": "PSA Payment Services Austria GmbH", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for eps refund. Its own scope line reads: an eps refund request.", "from": "applies_to" } ] }, { "uid": "eps-refund-error:020", "id": "020", "rail": "eps-refund-error", "kind": "reason-code", "name": "Transaction ID not found", "group": "administrative", "summary": "The Scheme Operator cannot find the TransactionId the refund request names, the ID the SO issued for the original eps payment.", "triggers": [ "Mistyped TransactionId, or one from another environment" ], "actions": [ "Merchant: take the TransactionId from the original bank response and send the request again" ], "retry": { "allowed": true, "rule": "With the correct TransactionId; no payment order was created." }, "facts": { "return_windows": [ { "action": "refund request refused", "by": "Scheme Operator", "deadline": "In the EpsRefundResponse that answers the refund request: the Scheme Operator returns 000 when the merchant's bank accepted the order, or an error code with an ErrorMsg, in which case no payment order exists." } ], "applies_to": "an eps refund request" }, "caveat": "Same number, different list: eps uses the same three-digit numbers with other meanings in its error list, its status reason list and its refund error list, so read a code together with the list and message it came in.", "related": [ "eps-error:020" ], "basis": { "sources": "PSA, eps Refundierung version 1.0.1, read 2026-09-19: the refund error code tables in section 4.6 and the refund response in section 7.2; the SO's checks in section 8.1. The source is in German; the meaning is paraphrased in English in Orca's own words, and triggers, actions and retry guidance are Orca's reading.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the eps documents read do not date it", "effective_to": null, "effective_note": "Drafted on 2026-09-19 from PSA's published eps documents. No document read says when this code entered the standard [Unverified].", "source_edition": "eps Refundierung version 1.0.1 (22 October 2018, file listed 2022-09-01), read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://eps-ueberweisung.at/de/download/eps-ueberweisung-dokumentation/send/2-eps-ueberweisung-dokumentation/16-eps-refundierung-dokumentation", "source_class": "authoritative_primary", "source_title": "eps Refundierung, version 1.0.1", "checked_on": "2026-09-19", "checked_by": "validator-2026-09-19", "notes": "Confirms refund error 020 as the Scheme Operator unable to find the transaction ID from the request." } ] }, "rail_name": "eps Refunds", "governing_authority": "PSA Payment Services Austria GmbH", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for eps refund. Its own scope line reads: an eps refund request.", "from": "applies_to" } ] }, { "uid": "eps-refund-error:021", "id": "021", "rail": "eps-refund-error", "kind": "reason-code", "name": "Original payment not completed", "group": "administrative", "summary": "The eps payment the refund refers to has not completed, so there is nothing to refund yet, or, if it ended NOK, nothing was ever paid.", "triggers": [ "Refund requested for a payment still in progress or one that ended without execution" ], "actions": [ "Merchant: check the payment's status; refund only a payment confirmed OK" ], "retry": { "allowed": true, "rule": "Only once the original payment has completed; a payment that ended NOK moved no money and needs no refund." }, "facts": { "return_windows": [ { "action": "refund request refused", "by": "Scheme Operator", "deadline": "In the EpsRefundResponse that answers the refund request: the Scheme Operator returns 000 when the merchant's bank accepted the order, or an error code with an ErrorMsg, in which case no payment order exists." } ], "applies_to": "an eps refund request" }, "caveat": "Same number, different list: eps uses the same three-digit numbers with other meanings in its error list, its status reason list and its refund error list, so read a code together with the list and message it came in. 021 is also an error code and a status reason, both meaning a payment still in progress.", "related": [ "eps-error:021", "eps-status-reason:021" ], "basis": { "sources": "PSA, eps Refundierung version 1.0.1, read 2026-09-19: the refund error code tables in section 4.6 and the refund response in section 7.2; the SO's checks in section 8.1. The source is in German; the meaning is paraphrased in English in Orca's own words, and triggers, actions and retry guidance are Orca's reading.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the eps documents read do not date it", "effective_to": null, "effective_note": "Drafted on 2026-09-19 from PSA's published eps documents. No document read says when this code entered the standard [Unverified].", "source_edition": "eps Refundierung version 1.0.1 (22 October 2018, file listed 2022-09-01), read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://eps-ueberweisung.at/de/download/eps-ueberweisung-dokumentation/send/2-eps-ueberweisung-dokumentation/16-eps-refundierung-dokumentation", "source_class": "authoritative_primary", "source_title": "eps Refundierung, version 1.0.1", "checked_on": "2026-09-19", "checked_by": "validator-2026-09-19", "notes": "Confirms refund error 021 as the underlying eps transaction not having completed." } ] }, "rail_name": "eps Refunds", "governing_authority": "PSA Payment Services Austria GmbH", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for eps refund. Its own scope line reads: an eps refund request.", "from": "applies_to" } ] }, { "uid": "eps-refund-error:022", "id": "022", "rail": "eps-refund-error", "kind": "reason-code", "name": "Refund amount too high", "group": "administrative", "summary": "The requested refund plus every earlier refund of the same payment would exceed the original eps amount.", "triggers": [ "Refund amount larger than what remains of the original payment", "A partial refund repeated by mistake" ], "actions": [ "Merchant: check the refunds already made and request no more than the remainder" ], "retry": { "allowed": true, "rule": "With an amount that keeps the refund total within the original payment." }, "facts": { "return_windows": [ { "action": "refund request refused", "by": "Scheme Operator", "deadline": "In the EpsRefundResponse that answers the refund request: the Scheme Operator returns 000 when the merchant's bank accepted the order, or an error code with an ErrorMsg, in which case no payment order exists." } ], "applies_to": "an eps refund request" }, "caveat": "Same number, different list: eps uses the same three-digit numbers with other meanings in its error list, its status reason list and its refund error list, so read a code together with the list and message it came in.", "related": [], "basis": { "sources": "PSA, eps Refundierung version 1.0.1, read 2026-09-19: the refund error code tables in section 4.6 and the refund response in section 7.2; the SO's checks in section 8.1. The source is in German; the meaning is paraphrased in English in Orca's own words, and triggers, actions and retry guidance are Orca's reading.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the eps documents read do not date it", "effective_to": null, "effective_note": "Drafted on 2026-09-19 from PSA's published eps documents. No document read says when this code entered the standard [Unverified].", "source_edition": "eps Refundierung version 1.0.1 (22 October 2018, file listed 2022-09-01), read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://eps-ueberweisung.at/de/download/eps-ueberweisung-dokumentation/send/2-eps-ueberweisung-dokumentation/16-eps-refundierung-dokumentation", "source_class": "authoritative_primary", "source_title": "eps Refundierung, version 1.0.1", "checked_on": "2026-09-19", "checked_by": "validator-2026-09-19", "notes": "Confirms refund error 022 as the refund amount plus all earlier refunds of the transaction exceeding the original eps payment's amount." } ] }, "rail_name": "eps Refunds", "governing_authority": "PSA Payment Services Austria GmbH", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for eps refund. Its own scope line reads: an eps refund request.", "from": "applies_to" } ] }, { "uid": "eps-status-reason:021", "id": "021", "rail": "eps-status-reason", "kind": "reason-code", "name": "Payment still in progress", "group": "administrative", "summary": "The payment had not finished when the status was reported: it is still ongoing. The reason describes an open outcome rather than a decline [Inference: it fits an UNKNOWN from the Scheme Operator better than a NOK].", "triggers": [ "Status reported while the buyer is still in online banking or the bank has not yet confirmed" ], "actions": [ "Merchant: do not ship and do not cancel yet; ask for the status with a confirmation status request later" ], "retry": { "allowed": false, "rule": "Not yet: a second payment could charge the buyer twice while this one may still complete. Check the status first." }, "facts": { "return_windows": [ { "action": "outcome unknown", "by": "Scheme Operator", "deadline": "When the debtor bank's confirmation is late: the Scheme Operator gives the bank its own redirect URLs, and if no confirmation has reached it in time it sends the merchant a confirmation with status UNKNOWN and lets the buyer be redirected to the shop. A bank confirmation arriving after that redirect is refused with HTTP 412." } ], "applies_to": "an eps payment" }, "caveat": "Same number, different list: eps uses the same three-digit numbers with other meanings in its error list, its status reason list and its refund error list, so read a code together with the list and message it came in. 021 is also an error code (status request while the payment is ongoing) and a refund error.", "related": [ "eps-error:021", "eps-refund-error:021" ], "basis": { "sources": "PSA, eps Standard Implementation Guideline version 2.7, read 2026-09-19: the ReasonCode table in section 6.2.2.8, which ties a StatusReason to a declined payment; the status rules in sections 6.2.2.7, 6.2.2.11 and 7.1. Meaning in Orca's own words. The guideline does not say which party writes each reason or which status each accompanies; those links are Orca's reading and are marked.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the eps documents read do not date it", "effective_to": null, "effective_note": "Drafted on 2026-09-19 from PSA's published eps documents. No document read says when this code entered the standard [Unverified].", "source_edition": "eps Standard Implementation Guideline version 2.7 (cover March 2025, file listed 2026-03-25), read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://eps-ueberweisung.at/de/download/eps-ueberweisung-dokumentation/send/2-eps-ueberweisung-dokumentation/31-eps-standard-implementation-guideline-v2-7", "source_class": "authoritative_primary", "source_title": "eps e-payment standard, Standard Implementation Guideline, version 2.7", "checked_on": "2026-09-19", "checked_by": "validator-2026-09-19", "notes": "Confirms StatusReason 021 as a transaction still ongoing and not yet completed." } ] }, "rail_name": "eps Payment Confirmations", "governing_authority": "PSA Payment Services Austria GmbH", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for eps payment (eps-Überweisung). Its own scope line reads: an eps payment.", "from": "applies_to" } ] }, { "uid": "eps-status-reason:030", "id": "030", "rail": "eps-status-reason", "kind": "reason-code", "name": "Cancelled by the buyer", "group": "authorization", "summary": "The buyer cancelled the payment in their bank, before or after logging in to online banking, so the debtor bank ended it with NOK and executed nothing.", "triggers": [ "Buyer pressed cancel or left the online banking payment screen" ], "actions": [ "Merchant: return the buyer to the basket and offer eps or another method again" ], "retry": { "allowed": true, "rule": "The buyer may start a new eps payment; nothing was debited." }, "facts": { "return_windows": [ { "action": "payment not completed", "by": "Debtor bank", "deadline": "Within the expiration time: the merchant may set it between 5 and 60 minutes after the initiation, and without one the Scheme Operator applies 60 minutes. The debtor bank checks it when the buyer authorises; once it has passed the bank may not send OK and must tell the buyer and send NOK." } ], "applies_to": "an eps payment" }, "caveat": "Same number, different list: eps uses the same three-digit numbers with other meanings in its error list, its status reason list and its refund error list, so read a code together with the list and message it came in.", "related": [], "basis": { "sources": "PSA, eps Standard Implementation Guideline version 2.7, read 2026-09-19: the ReasonCode table in section 6.2.2.8, which ties a StatusReason to a declined payment; the status rules in sections 6.2.2.7, 6.2.2.11 and 7.1. Meaning in Orca's own words. The guideline does not say which party writes each reason or which status each accompanies; those links are Orca's reading and are marked.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the eps documents read do not date it", "effective_to": null, "effective_note": "Drafted on 2026-09-19 from PSA's published eps documents. No document read says when this code entered the standard [Unverified].", "source_edition": "eps Standard Implementation Guideline version 2.7 (cover March 2025, file listed 2026-03-25), read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://eps-ueberweisung.at/de/download/eps-ueberweisung-dokumentation/send/2-eps-ueberweisung-dokumentation/31-eps-standard-implementation-guideline-v2-7", "source_class": "authoritative_primary", "source_title": "eps e-payment standard, Standard Implementation Guideline, version 2.7", "checked_on": "2026-09-19", "checked_by": "validator-2026-09-19", "notes": "Confirms StatusReason 030 as a transaction cancelled by the customer." } ] }, "rail_name": "eps Payment Confirmations", "governing_authority": "PSA Payment Services Austria GmbH", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for eps payment (eps-Überweisung). Its own scope line reads: an eps payment.", "from": "applies_to" } ] }, { "uid": "eps-status-reason:031", "id": "031", "rail": "eps-status-reason", "kind": "reason-code", "name": "Timed out after initiation", "group": "technical", "summary": "The payment timed out after the initiation, before it was authorised and executed [Inference: for example the buyer did not finish in online banking before the expiration time].", "triggers": [ "Buyer did not complete the payment in time", "A step between initiation and authorisation timed out" ], "actions": [ "Merchant: offer a new eps payment with a fresh expiration time" ], "retry": { "allowed": true, "rule": "A new initiation, once the NOK is in hand; with NOK nothing was debited." }, "facts": { "return_windows": [ { "action": "payment not completed", "by": "Debtor bank", "deadline": "Within the expiration time: the merchant may set it between 5 and 60 minutes after the initiation, and without one the Scheme Operator applies 60 minutes. The debtor bank checks it when the buyer authorises; once it has passed the bank may not send OK and must tell the buyer and send NOK." } ], "applies_to": "an eps payment" }, "caveat": "Same number, different list: eps uses the same three-digit numbers with other meanings in its error list, its status reason list and its refund error list, so read a code together with the list and message it came in.", "related": [], "basis": { "sources": "PSA, eps Standard Implementation Guideline version 2.7, read 2026-09-19: the ReasonCode table in section 6.2.2.8, which ties a StatusReason to a declined payment; the status rules in sections 6.2.2.7, 6.2.2.11 and 7.1. Meaning in Orca's own words. The guideline does not say which party writes each reason or which status each accompanies; those links are Orca's reading and are marked.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the eps documents read do not date it", "effective_to": null, "effective_note": "Drafted on 2026-09-19 from PSA's published eps documents. No document read says when this code entered the standard [Unverified].", "source_edition": "eps Standard Implementation Guideline version 2.7 (cover March 2025, file listed 2026-03-25), read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://eps-ueberweisung.at/de/download/eps-ueberweisung-dokumentation/send/2-eps-ueberweisung-dokumentation/31-eps-standard-implementation-guideline-v2-7", "source_class": "authoritative_primary", "source_title": "eps e-payment standard, Standard Implementation Guideline, version 2.7", "checked_on": "2026-09-19", "checked_by": "validator-2026-09-19", "notes": "Confirms StatusReason 031 as a transaction timeout occurring after initiation." } ] }, "rail_name": "eps Payment Confirmations", "governing_authority": "PSA Payment Services Austria GmbH", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for eps payment (eps-Überweisung). Its own scope line reads: an eps payment.", "from": "applies_to" } ] }, { "uid": "eps-status-reason:032", "id": "032", "rail": "eps-status-reason", "kind": "reason-code", "name": "Timed out after the vitality check", "group": "technical", "summary": "The payment timed out after the vitality check, the step where the merchant must answer before the bank executes. Reported with a declined payment it means no transfer was made [Inference from section 6.2.2.8, which ties StatusReason to a decline].", "triggers": [ "Merchant's answer to the vitality check did not come back in time [Inference]", "A later step timed out before execution [Inference]" ], "actions": [ "Merchant: check that the confirmation URL answers within 20 seconds, then offer a new eps payment" ], "retry": { "allowed": true, "rule": "Once the NOK status is confirmed; with NOK nothing was debited. If the status was UNKNOWN, check it first." }, "facts": { "return_windows": [ { "action": "payment not completed", "by": "Debtor bank", "deadline": "Within the expiration time: the merchant may set it between 5 and 60 minutes after the initiation, and without one the Scheme Operator applies 60 minutes. The debtor bank checks it when the buyer authorises; once it has passed the bank may not send OK and must tell the buyer and send NOK." } ], "applies_to": "an eps payment" }, "caveat": "Same number, different list: eps uses the same three-digit numbers with other meanings in its error list, its status reason list and its refund error list, so read a code together with the list and message it came in.", "related": [], "basis": { "sources": "PSA, eps Standard Implementation Guideline version 2.7, read 2026-09-19: the ReasonCode table in section 6.2.2.8, which ties a StatusReason to a declined payment; the status rules in sections 6.2.2.7, 6.2.2.11 and 7.1. Meaning in Orca's own words. The guideline does not say which party writes each reason or which status each accompanies; those links are Orca's reading and are marked.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the eps documents read do not date it", "effective_to": null, "effective_note": "Drafted on 2026-09-19 from PSA's published eps documents. No document read says when this code entered the standard [Unverified].", "source_edition": "eps Standard Implementation Guideline version 2.7 (cover March 2025, file listed 2026-03-25), read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://eps-ueberweisung.at/de/download/eps-ueberweisung-dokumentation/send/2-eps-ueberweisung-dokumentation/31-eps-standard-implementation-guideline-v2-7", "source_class": "authoritative_primary", "source_title": "eps e-payment standard, Standard Implementation Guideline, version 2.7", "checked_on": "2026-09-19", "checked_by": "validator-2026-09-19", "notes": "Confirms StatusReason 032 as a transaction timeout occurring after the vitality check." } ] }, "rail_name": "eps Payment Confirmations", "governing_authority": "PSA Payment Services Austria GmbH", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for eps payment (eps-Überweisung). Its own scope line reads: an eps payment.", "from": "applies_to" } ] }, { "uid": "eps-status-reason:033", "id": "033", "rail": "eps-status-reason", "kind": "reason-code", "name": "Redirect without a payment confirmation", "group": "administrative", "summary": "The buyer came back to the shop through the redirect, but no payment confirmation from the bank had arrived. The outcome is open [Inference: this is the situation in which the Scheme Operator writes UNKNOWN].", "triggers": [ "Buyer redirected before the debtor bank's confirmation reached the SO" ], "actions": [ "Merchant: hold the order and ask for the status with a confirmation status request; ship only on OK" ], "retry": { "allowed": false, "rule": "Not until the status is known: the transfer may have been executed." }, "facts": { "return_windows": [ { "action": "outcome unknown", "by": "Scheme Operator", "deadline": "When the debtor bank's confirmation is late: the Scheme Operator gives the bank its own redirect URLs, and if no confirmation has reached it in time it sends the merchant a confirmation with status UNKNOWN and lets the buyer be redirected to the shop. A bank confirmation arriving after that redirect is refused with HTTP 412." } ], "applies_to": "an eps payment" }, "caveat": "Same number, different list: eps uses the same three-digit numbers with other meanings in its error list, its status reason list and its refund error list, so read a code together with the list and message it came in.", "related": [], "basis": { "sources": "PSA, eps Standard Implementation Guideline version 2.7, read 2026-09-19: the ReasonCode table in section 6.2.2.8, which ties a StatusReason to a declined payment; the status rules in sections 6.2.2.7, 6.2.2.11 and 7.1. Meaning in Orca's own words. The guideline does not say which party writes each reason or which status each accompanies; those links are Orca's reading and are marked.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the eps documents read do not date it", "effective_to": null, "effective_note": "Drafted on 2026-09-19 from PSA's published eps documents. No document read says when this code entered the standard [Unverified].", "source_edition": "eps Standard Implementation Guideline version 2.7 (cover March 2025, file listed 2026-03-25), read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://eps-ueberweisung.at/de/download/eps-ueberweisung-dokumentation/send/2-eps-ueberweisung-dokumentation/31-eps-standard-implementation-guideline-v2-7", "source_class": "authoritative_primary", "source_title": "eps e-payment standard, Standard Implementation Guideline, version 2.7", "checked_on": "2026-09-19", "checked_by": "validator-2026-09-19", "notes": "Confirms StatusReason 033 as a redirect without a payment confirmation." } ] }, "rail_name": "eps Payment Confirmations", "governing_authority": "PSA Payment Services Austria GmbH", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for eps payment (eps-Überweisung). Its own scope line reads: an eps payment.", "from": "applies_to" } ] }, { "uid": "eps-status-reason:110", "id": "110", "rail": "eps-status-reason", "kind": "reason-code", "name": "Cancelled by the bank", "group": "administrative", "summary": "The debtor bank cancelled the payment. The eps documents give no grounds; they stay between the buyer and their bank [Inference: for example an account, limit or risk check].", "triggers": [ "Debtor bank declined to execute the payment" ], "actions": [ "Merchant: ask the buyer to contact their bank or to pay another way" ], "retry": { "allowed": true, "rule": "Only once the buyer has cleared it with their bank; repeating at once will likely fail again. Nothing was debited." }, "facts": { "return_windows": [ { "action": "payment not completed", "by": "Debtor bank", "deadline": "Within the expiration time: the merchant may set it between 5 and 60 minutes after the initiation, and without one the Scheme Operator applies 60 minutes. The debtor bank checks it when the buyer authorises; once it has passed the bank may not send OK and must tell the buyer and send NOK." } ], "applies_to": "an eps payment" }, "caveat": "Same number, different list: eps uses the same three-digit numbers with other meanings in its error list, its status reason list and its refund error list, so read a code together with the list and message it came in.", "related": [], "basis": { "sources": "PSA, eps Standard Implementation Guideline version 2.7, read 2026-09-19: the ReasonCode table in section 6.2.2.8, which ties a StatusReason to a declined payment; the status rules in sections 6.2.2.7, 6.2.2.11 and 7.1. Every NOK confirmation is created by the debtor bank (section 6.2.2), and this reason names the bank as the one cancelling. Meaning in Orca's own words. The guideline does not say which party writes each reason or which status each accompanies; those links are Orca's reading and are marked.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the eps documents read do not date it", "effective_to": null, "effective_note": "Drafted on 2026-09-19 from PSA's published eps documents. No document read says when this code entered the standard [Unverified].", "source_edition": "eps Standard Implementation Guideline version 2.7 (cover March 2025, file listed 2026-03-25), read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://eps-ueberweisung.at/de/download/eps-ueberweisung-dokumentation/send/2-eps-ueberweisung-dokumentation/31-eps-standard-implementation-guideline-v2-7", "source_class": "authoritative_primary", "source_title": "eps e-payment standard, Standard Implementation Guideline, version 2.7", "checked_on": "2026-09-19", "checked_by": "validator-2026-09-19", "notes": "Confirms StatusReason 110 as a transaction cancelled by the bank, with no grounds stated." } ] }, "rail_name": "eps Payment Confirmations", "governing_authority": "PSA Payment Services Austria GmbH", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for eps payment (eps-Überweisung). Its own scope line reads: an eps payment.", "from": "applies_to" } ] }, { "uid": "eps-status-reason:115", "id": "115", "rail": "eps-status-reason", "kind": "reason-code", "name": "Aborted by the routing service for a possible fraud check", "group": "authorization", "summary": "The Scheme Operator, as routing service, stopped the payment because of a possible fraud check. The guideline gives no criteria.", "triggers": [ "SO fraud screening flagged the payment [Unverified: criteria not published]" ], "actions": [ "Merchant: do not push the buyer to repeat at once; offer another method or let the buyer clear it with their bank" ], "retry": { "allowed": false, "rule": "Not automatically: the payment was stopped on fraud grounds, and a repeat may be stopped again." }, "facts": { "return_windows": [ { "action": "payment not completed", "by": "Scheme Operator", "deadline": "At any point before the payment completes, the routing service may abort a transaction for a possible fraud check, which the confirmation reports with status reason 115. The guideline gives no criteria [Unverified]." } ], "applies_to": "an eps payment" }, "caveat": "Same number, different list: eps uses the same three-digit numbers with other meanings in its error list, its status reason list and its refund error list, so read a code together with the list and message it came in.", "related": [], "basis": { "sources": "PSA, eps Standard Implementation Guideline version 2.7, read 2026-09-19: the ReasonCode table in section 6.2.2.8, which ties a StatusReason to a declined payment; the status rules in sections 6.2.2.7, 6.2.2.11 and 7.1. Meaning in Orca's own words. The guideline does not say which party writes each reason or which status each accompanies; those links are Orca's reading and are marked.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the eps documents read do not date it", "effective_to": null, "effective_note": "Drafted on 2026-09-19 from PSA's published eps documents. No document read says when this code entered the standard [Unverified].", "source_edition": "eps Standard Implementation Guideline version 2.7 (cover March 2025, file listed 2026-03-25), read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://eps-ueberweisung.at/de/download/eps-ueberweisung-dokumentation/send/2-eps-ueberweisung-dokumentation/31-eps-standard-implementation-guideline-v2-7", "source_class": "authoritative_primary", "source_title": "eps e-payment standard, Standard Implementation Guideline, version 2.7", "checked_on": "2026-09-19", "checked_by": "validator-2026-09-19", "notes": "Confirms StatusReason 115 as a transaction aborted by the routing service for a possible fraud check, with no criteria given." } ] }, "rail_name": "eps Payment Confirmations", "governing_authority": "PSA Payment Services Austria GmbH", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for eps payment (eps-Überweisung). Its own scope line reads: an eps payment.", "from": "applies_to" } ] }, { "uid": "eps-status-reason:120", "id": "120", "rail": "eps-status-reason", "kind": "reason-code", "name": "Technical error at the bank", "group": "technical", "summary": "A technical fault on the debtor bank's side ended the payment.", "triggers": [ "System fault at the debtor bank or its online banking" ], "actions": [ "Merchant: offer a new eps payment later or another method" ], "retry": { "allowed": true, "rule": "Later; with NOK nothing was debited." }, "facts": { "return_windows": [ { "action": "payment not completed", "by": "Debtor bank", "deadline": "Within the expiration time: the merchant may set it between 5 and 60 minutes after the initiation, and without one the Scheme Operator applies 60 minutes. The debtor bank checks it when the buyer authorises; once it has passed the bank may not send OK and must tell the buyer and send NOK." } ], "applies_to": "an eps payment" }, "caveat": "Same number, different list: eps uses the same three-digit numbers with other meanings in its error list, its status reason list and its refund error list, so read a code together with the list and message it came in.", "related": [], "basis": { "sources": "PSA, eps Standard Implementation Guideline version 2.7, read 2026-09-19: the ReasonCode table in section 6.2.2.8, which ties a StatusReason to a declined payment; the status rules in sections 6.2.2.7, 6.2.2.11 and 7.1. Meaning in Orca's own words. The guideline does not say which party writes each reason or which status each accompanies; those links are Orca's reading and are marked.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the eps documents read do not date it", "effective_to": null, "effective_note": "Drafted on 2026-09-19 from PSA's published eps documents. No document read says when this code entered the standard [Unverified].", "source_edition": "eps Standard Implementation Guideline version 2.7 (cover March 2025, file listed 2026-03-25), read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://eps-ueberweisung.at/de/download/eps-ueberweisung-dokumentation/send/2-eps-ueberweisung-dokumentation/31-eps-standard-implementation-guideline-v2-7", "source_class": "authoritative_primary", "source_title": "eps e-payment standard, Standard Implementation Guideline, version 2.7", "checked_on": "2026-09-19", "checked_by": "validator-2026-09-19", "notes": "Confirms StatusReason 120 as a technical error on the bank side." } ] }, "rail_name": "eps Payment Confirmations", "governing_authority": "PSA Payment Services Austria GmbH", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for eps payment (eps-Überweisung). Its own scope line reads: an eps payment.", "from": "applies_to" } ] }, { "uid": "eps-status-reason:121", "id": "121", "rail": "eps-status-reason", "kind": "reason-code", "name": "Technical error at the merchant", "group": "technical", "summary": "A technical fault on the merchant's side ended the payment, for example no valid answer to the vitality check [Inference].", "triggers": [ "Merchant's confirmation endpoint did not answer, answered with an error, or returned broken XML [Inference]" ], "actions": [ "Merchant: fix the confirmation URL endpoint so it answers the vitality check and the confirmation within 20 seconds, then offer a new payment" ], "retry": { "allowed": true, "rule": "After the merchant side is fixed; with NOK nothing was debited." }, "facts": { "return_windows": [ { "action": "payment not completed", "by": "Debtor bank", "deadline": "Within the expiration time: the merchant may set it between 5 and 60 minutes after the initiation, and without one the Scheme Operator applies 60 minutes. The debtor bank checks it when the buyer authorises; once it has passed the bank may not send OK and must tell the buyer and send NOK." } ], "applies_to": "an eps payment" }, "caveat": "Same number, different list: eps uses the same three-digit numbers with other meanings in its error list, its status reason list and its refund error list, so read a code together with the list and message it came in.", "related": [], "basis": { "sources": "PSA, eps Standard Implementation Guideline version 2.7, read 2026-09-19: the ReasonCode table in section 6.2.2.8, which ties a StatusReason to a declined payment; the status rules in sections 6.2.2.7, 6.2.2.11 and 7.1. Meaning in Orca's own words. The guideline does not say which party writes each reason or which status each accompanies; those links are Orca's reading and are marked.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the eps documents read do not date it", "effective_to": null, "effective_note": "Drafted on 2026-09-19 from PSA's published eps documents. No document read says when this code entered the standard [Unverified].", "source_edition": "eps Standard Implementation Guideline version 2.7 (cover March 2025, file listed 2026-03-25), read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://eps-ueberweisung.at/de/download/eps-ueberweisung-dokumentation/send/2-eps-ueberweisung-dokumentation/31-eps-standard-implementation-guideline-v2-7", "source_class": "authoritative_primary", "source_title": "eps e-payment standard, Standard Implementation Guideline, version 2.7", "checked_on": "2026-09-19", "checked_by": "validator-2026-09-19", "notes": "Confirms StatusReason 121 as a technical error on the merchant side." } ] }, "rail_name": "eps Payment Confirmations", "governing_authority": "PSA Payment Services Austria GmbH", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for eps payment (eps-Überweisung). Its own scope line reads: an eps payment.", "from": "applies_to" } ] }, { "uid": "eps-status-reason:122", "id": "122", "rail": "eps-status-reason", "kind": "reason-code", "name": "Signature check failed", "group": "authorization", "summary": "A digital signature in the payment flow did not verify, for example the Scheme Operator's signature on the initiation or the bank's on its confirmation [Inference: the guideline does not say which].", "triggers": [ "A signature or certificate in the eps message chain did not verify" ], "actions": [ "Merchant: check the signing set-up and certificates with the creditor bank or acquirer before offering eps again" ], "retry": { "allowed": true, "rule": "After the signature fault is fixed; with NOK nothing was debited." }, "facts": { "return_windows": [ { "action": "payment not completed", "by": "Debtor bank", "deadline": "Within the expiration time: the merchant may set it between 5 and 60 minutes after the initiation, and without one the Scheme Operator applies 60 minutes. The debtor bank checks it when the buyer authorises; once it has passed the bank may not send OK and must tell the buyer and send NOK." } ], "applies_to": "an eps payment" }, "caveat": "Same number, different list: eps uses the same three-digit numbers with other meanings in its error list, its status reason list and its refund error list, so read a code together with the list and message it came in.", "related": [], "basis": { "sources": "PSA, eps Standard Implementation Guideline version 2.7, read 2026-09-19: the ReasonCode table in section 6.2.2.8, which ties a StatusReason to a declined payment; the status rules in sections 6.2.2.7, 6.2.2.11 and 7.1. Meaning in Orca's own words. The guideline does not say which party writes each reason or which status each accompanies; those links are Orca's reading and are marked.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the eps documents read do not date it", "effective_to": null, "effective_note": "Drafted on 2026-09-19 from PSA's published eps documents. No document read says when this code entered the standard [Unverified].", "source_edition": "eps Standard Implementation Guideline version 2.7 (cover March 2025, file listed 2026-03-25), read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://eps-ueberweisung.at/de/download/eps-ueberweisung-dokumentation/send/2-eps-ueberweisung-dokumentation/31-eps-standard-implementation-guideline-v2-7", "source_class": "authoritative_primary", "source_title": "eps e-payment standard, Standard Implementation Guideline, version 2.7", "checked_on": "2026-09-19", "checked_by": "validator-2026-09-19", "notes": "Confirms StatusReason 122 as a signature check failure, with the guideline not saying whose signature." } ] }, "rail_name": "eps Payment Confirmations", "governing_authority": "PSA Payment Services Austria GmbH", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for eps payment (eps-Überweisung). Its own scope line reads: an eps payment.", "from": "applies_to" } ] }, { "uid": "eps-status-reason:123", "id": "123", "rail": "eps-status-reason", "kind": "reason-code", "name": "Two confirmations with different statuses", "group": "administrative", "summary": "Two confirmations with different status codes arrived for the same payment, so neither can be relied on.", "triggers": [ "The same payment was confirmed twice, with two different status codes" ], "actions": [ "Merchant: act on neither status; ask for the status and check with the creditor bank whether the money arrived" ], "retry": { "allowed": false, "rule": "Not until the true outcome is established: a new payment could charge the buyer twice." }, "facts": { "return_windows": [ { "action": "payment not completed", "by": "Scheme Operator", "deadline": "Within the expiration time: the merchant may set it between 5 and 60 minutes after the initiation, and without one the Scheme Operator applies 60 minutes. The debtor bank checks it when the buyer authorises; once it has passed the bank may not send OK and must tell the buyer and send NOK." } ], "applies_to": "an eps payment" }, "caveat": "Same number, different list: eps uses the same three-digit numbers with other meanings in its error list, its status reason list and its refund error list, so read a code together with the list and message it came in.", "related": [], "basis": { "sources": "PSA, eps Standard Implementation Guideline version 2.7, read 2026-09-19: the ReasonCode table in section 6.2.2.8, which ties a StatusReason to a declined payment; the status rules in sections 6.2.2.7, 6.2.2.11 and 7.1. Meaning in Orca's own words. The guideline does not say which party writes each reason or which status each accompanies; those links are Orca's reading and are marked.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the eps documents read do not date it", "effective_to": null, "effective_note": "Drafted on 2026-09-19 from PSA's published eps documents. No document read says when this code entered the standard [Unverified].", "source_edition": "eps Standard Implementation Guideline version 2.7 (cover March 2025, file listed 2026-03-25), read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://eps-ueberweisung.at/de/download/eps-ueberweisung-dokumentation/send/2-eps-ueberweisung-dokumentation/31-eps-standard-implementation-guideline-v2-7", "source_class": "authoritative_primary", "source_title": "eps e-payment standard, Standard Implementation Guideline, version 2.7", "checked_on": "2026-09-19", "checked_by": "validator-2026-09-19", "notes": "Confirms StatusReason 123 as a double confirmation, meaning two confirmations with different status codes for the same payment." } ] }, "rail_name": "eps Payment Confirmations", "governing_authority": "PSA Payment Services Austria GmbH", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for eps payment (eps-Überweisung). Its own scope line reads: an eps payment.", "from": "applies_to" } ] }, { "uid": "gcc-afaq-reject:RJ00", "id": "RJ00", "rail": "gcc-afaq-reject", "kind": "reason-code", "name": "System error", "group": "technical", "summary": "A catch-all for a fault inside AFAQ: a gateway or the Central Component hit a system error and could not process the payment, and SAMA's label for the code tells the participant to contact support. Nothing reached the beneficiary. This record reports SAMA's rules for Saudi direct participants.", "triggers": [ "A processing fault in a Regional Payment Gateway or in the Central Component [Inference from SAMA's label]", "A failure that no more specific RJ code describes [Inference]" ], "actions": [ "Sending participant: treat the payment as not made and raise it with support before resending; for Saudi participants the operator of the country model is SAMA, with GPC hosting the Central Component [Inference about who answers]", "Sending participant: tell the customer the transfer did not go through and resend once the fault is cleared", "Keep a record of the occurrence; SAMA's rules require participants to report events that affect their role in the service (OR 42068309 section 4.11)" ], "retry": { "allowed": true, "rule": "The refused payment stays refused. Once the cause is fixed, the sending participant may send it again as a new payment with a new unique message reference; it must not reuse the original reference, but it may keep the same UETR (OR 42068309 section 7.3). Wait until support confirms the fault has cleared [Inference]." }, "facts": { "return_windows": [ { "action": "refuse the payment and send the rejection back towards the sender", "by": "AFAQ Central Component or a Regional Payment Gateway; SAMA's list does not say which component raises which RJ code", "deadline": "At validation, before the payment is booked [Inference: the rules describe rejection as a payment the Central Component cannot process]; no time limit is published." }, { "action": "turn the rejection into a return payment to the sending participant, stating this code as the reason", "by": "Sending Regional Payment Gateway", "deadline": "No public deadline. SAMA's rules require every payment to be confirmed, returned or rejected before end-of-day processing starts (OR 42068309 section 7.5), so the same business day [Inference]." } ], "applies_to": "AFAQ cross-currency payments sent by a Saudi direct participant under SAMA's rules (circular 42068309, Appendix 2): a payment that a Regional Payment Gateway or the AFAQ Central Component refuses, reported back to the sending participant as a return payment that carries this code. Participants in other GCC countries follow their own central bank's code list, which was not read." }, "caveat": "This code reaches the sender as a return payment, but it is a rejection by AFAQ itself, not a return by the receiving bank. SAMA publishes only a short label for each RJ code, with no definition, so the triggers here are a reading of the operating rules.", "related": [ "gcc-afaq-reject:RJ25", "gcc-afaq-reject:RJ90", "gcc-afaq:messages" ], "basis": { "sources": "SAMA rulebook portal, English pages read 2026-09-18: Operating Rules for Cross Currency Payments using AFAQ Service, circular 42068309 (2021-05-05), Appendix 2 (Return and Rejection Codes, also read as its own page) for the code and its label. How the service handles it rests on sections 4.1.2, 4.1.5, 4.11 and 7.3. The portal says its pages carry no legal effect, so the class is public_primary. SAMA gives each RJ code a short label only; triggers and actions marked [Inference] are Orca's reading. The GPC Operating Rules and Regulations were not used. Nothing is quoted.", "confidence": "low" }, "currency": { "effective_since": "2021-05-05", "effective_note": "In SAMA's Appendix 2 since circular 42068309 (2021-05-05, 1442-09-24 H), In-Force with no later version shown on 2026-09-18. The appendix says the Central Component's code dictionary may be updated from time to time, so the live list may differ from the published one.", "source_edition": "OR 42068309 Appendix 2 (2021-05-05)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://rulebook.sama.gov.sa/en/operating-rules-cross-currency-payments-using-afaq-service", "source_class": "public_primary", "source_title": "Operating Rules for Cross Currency Payments using AFAQ Service (SAMA circular 42068309, including Appendix 2)", "checked_on": "2026-09-19", "checked_by": "gcc-afaq validator session", "notes": "Confirms SAMA's label for RJ00, System error, contact support, and confirms that a payment the Central Component cannot process under Appendix 2 is turned by the Sending RPG into a return sent to the sending participant stating the rejection reason, per section 7.3. Does not define the fault itself beyond the label." } ] }, "rail_name": "GCC AFAQ Payment Rejections", "governing_authority": "SAMA (rules for Saudi direct participants); GCC central banks via GPC (system)", "snapshot": "2026-09-18", "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "gcc-afaq-reject:RJ01", "id": "RJ01", "rail": "gcc-afaq-reject", "kind": "reason-code", "name": "Wrong exchange rate", "group": "technical", "summary": "The exchange rate quoted in the payment is not the confirmed rate for that currency pair on that business day. The central banks fix one rate per pair each morning and it holds all day; the gateway and the Central Component both check the rate, and a message quoting any other rate is refused. This record reports SAMA's rules for Saudi direct participants.", "triggers": [ "The sender quoted a rate from an earlier business day [Inference]", "The rate was expressed the wrong way round for the pair [Inference]", "The sender's system rounded or keyed the rate differently from the confirmed figure [Inference]" ], "actions": [ "Sending participant: reload the day's confirmed rate for the pair, which the central banks approve before the exchange period opens, and recompute the receiving-currency amount", "Resend as a new payment with a new unique message reference", "Check that internal rate tables refresh each morning after rate approval" ], "retry": { "allowed": true, "rule": "The refused payment stays refused. Once the cause is fixed, the sending participant may send it again as a new payment with a new unique message reference; it must not reuse the original reference, but it may keep the same UETR (OR 42068309 section 7.3)." }, "facts": { "return_windows": [ { "action": "refuse the payment and send the rejection back towards the sender", "by": "AFAQ Central Component or a Regional Payment Gateway; SAMA's list does not say which component raises which RJ code", "deadline": "At validation, before the payment is booked [Inference: the rules describe rejection as a payment the Central Component cannot process]; no time limit is published." }, { "action": "turn the rejection into a return payment to the sending participant, stating this code as the reason", "by": "Sending Regional Payment Gateway", "deadline": "No public deadline. SAMA's rules require every payment to be confirmed, returned or rejected before end-of-day processing starts (OR 42068309 section 7.5), so the same business day [Inference]." } ], "applies_to": "AFAQ cross-currency payments sent by a Saudi direct participant under SAMA's rules (circular 42068309, Appendix 2): a payment that a Regional Payment Gateway or the AFAQ Central Component refuses, reported back to the sending participant as a return payment that carries this code. Participants in other GCC countries follow their own central bank's code list, which was not read." }, "caveat": "This code reaches the sender as a return payment, but it is a rejection by AFAQ itself, not a return by the receiving bank. SAMA publishes only a short label for each RJ code, with no definition, so the triggers here are a reading of the operating rules.", "related": [ "gcc-afaq-reject:RJ02", "gcc-afaq-reject:RJ11", "gcc-afaq-reject:RJ14", "gcc-afaq-reject:RJ15", "gcc-afaq:settlement", "gcc-afaq:limits" ], "basis": { "sources": "SAMA rulebook portal, English pages read 2026-09-18: Operating Rules for Cross Currency Payments using AFAQ Service, circular 42068309 (2021-05-05), Appendix 2 (Return and Rejection Codes, also read as its own page) for the code and its label. How the service handles it rests on sections 1 (Confirmed Exchange Rate), 5.1 items 2 to 4, 6, 7.2 and 7.3. The portal says its pages carry no legal effect, so the class is public_primary. SAMA gives each RJ code a short label only; triggers and actions marked [Inference] are Orca's reading. The GPC Operating Rules and Regulations were not used. Nothing is quoted.", "confidence": "medium" }, "currency": { "effective_since": "2021-05-05", "effective_note": "In SAMA's Appendix 2 since circular 42068309 (2021-05-05, 1442-09-24 H), In-Force with no later version shown on 2026-09-18. The appendix says the Central Component's code dictionary may be updated from time to time, so the live list may differ from the published one.", "source_edition": "OR 42068309 Appendix 2 (2021-05-05)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://rulebook.sama.gov.sa/en/operating-rules-cross-currency-payments-using-afaq-service", "source_class": "public_primary", "source_title": "Operating Rules for Cross Currency Payments using AFAQ Service (SAMA circular 42068309, including Appendix 2)", "checked_on": "2026-09-19", "checked_by": "gcc-afaq validator session", "notes": "Confirms SAMA's label for RJ01, Incorrect FX Rate, and confirms section 6's rule that a payment message with an incorrect exchange rate is rejected, and section 7.3's rule that a rejected payment reaches the sender as a return generated by the Sending RPG." } ] }, "rail_name": "GCC AFAQ Payment Rejections", "governing_authority": "SAMA (rules for Saudi direct participants); GCC central banks via GPC (system)", "snapshot": "2026-09-18", "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "gcc-afaq-reject:RJ02", "id": "RJ02", "rail": "gcc-afaq-reject", "kind": "reason-code", "name": "Wrong amount in the receiving currency", "group": "technical", "summary": "The amount stated in the receiving country's currency does not equal the sending amount converted at the day's confirmed rate. A sender must put both amounts and the rate in the message, and the gateway and the Central Component check the arithmetic; a mismatch is refused. This record reports SAMA's rules for Saudi direct participants.", "triggers": [ "The receiving amount was calculated with a rate other than the confirmed one [Inference]", "Rounding of the converted amount differs from AFAQ's calculation [Inference]", "The sending and receiving amounts were entered in each other's fields [Inference]" ], "actions": [ "Sending participant: recompute the receiving amount from the sending amount and the day's confirmed rate", "Resend as a new payment with a new unique message reference", "If mismatches recur, compare the participant's rounding with the conversion rules in the controlled documents GPC and SAMA share with participants [Inference: the conversion note is not public]" ], "retry": { "allowed": true, "rule": "The refused payment stays refused. Once the cause is fixed, the sending participant may send it again as a new payment with a new unique message reference; it must not reuse the original reference, but it may keep the same UETR (OR 42068309 section 7.3)." }, "facts": { "return_windows": [ { "action": "refuse the payment and send the rejection back towards the sender", "by": "AFAQ Central Component or a Regional Payment Gateway; SAMA's list does not say which component raises which RJ code", "deadline": "At validation, before the payment is booked [Inference: the rules describe rejection as a payment the Central Component cannot process]; no time limit is published." }, { "action": "turn the rejection into a return payment to the sending participant, stating this code as the reason", "by": "Sending Regional Payment Gateway", "deadline": "No public deadline. SAMA's rules require every payment to be confirmed, returned or rejected before end-of-day processing starts (OR 42068309 section 7.5), so the same business day [Inference]." } ], "applies_to": "AFAQ cross-currency payments sent by a Saudi direct participant under SAMA's rules (circular 42068309, Appendix 2): a payment that a Regional Payment Gateway or the AFAQ Central Component refuses, reported back to the sending participant as a return payment that carries this code. Participants in other GCC countries follow their own central bank's code list, which was not read." }, "caveat": "This code reaches the sender as a return payment, but it is a rejection by AFAQ itself, not a return by the receiving bank. SAMA publishes only a short label for each RJ code, with no definition, so the triggers here are a reading of the operating rules.", "related": [ "gcc-afaq-reject:RJ01", "gcc-afaq-reject:RJ04", "gcc-afaq:settlement" ], "basis": { "sources": "SAMA rulebook portal, English pages read 2026-09-18: Operating Rules for Cross Currency Payments using AFAQ Service, circular 42068309 (2021-05-05), Appendix 2 (Return and Rejection Codes, also read as its own page) for the code and its label. How the service handles it rests on sections 6, 7.2 and 7.3. The portal says its pages carry no legal effect, so the class is public_primary. SAMA gives each RJ code a short label only; triggers and actions marked [Inference] are Orca's reading. The GPC Operating Rules and Regulations were not used. Nothing is quoted.", "confidence": "medium" }, "currency": { "effective_since": "2021-05-05", "effective_note": "In SAMA's Appendix 2 since circular 42068309 (2021-05-05, 1442-09-24 H), In-Force with no later version shown on 2026-09-18. The appendix says the Central Component's code dictionary may be updated from time to time, so the live list may differ from the published one.", "source_edition": "OR 42068309 Appendix 2 (2021-05-05)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://rulebook.sama.gov.sa/en/operating-rules-cross-currency-payments-using-afaq-service", "source_class": "public_primary", "source_title": "Operating Rules for Cross Currency Payments using AFAQ Service (SAMA circular 42068309, including Appendix 2)", "checked_on": "2026-09-19", "checked_by": "gcc-afaq validator session", "notes": "Confirms SAMA's label for RJ02, Incorrect Receiving Currency amount, and section 6's rule that a payment message with an incorrect converted amount is rejected, and section 7.3's return path back to the sender via the Sending RPG." } ] }, "rail_name": "GCC AFAQ Payment Rejections", "governing_authority": "SAMA (rules for Saudi direct participants); GCC central banks via GPC (system)", "snapshot": "2026-09-18", "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "gcc-afaq-reject:RJ03", "id": "RJ03", "rail": "gcc-afaq-reject", "kind": "reason-code", "name": "Invalid value date", "group": "administrative", "summary": "The value date in the payment is not one AFAQ accepts. AFAQ takes same-day value only, on a day that is a working day in both countries; a payment dated for another day is refused. Future-dated payments must be held by the sending bank until the date arrives. This record reports SAMA's rules for Saudi direct participants.", "triggers": [ "A payment dated for a future day, sent early [Inference]", "A payment carrying an earlier date, for example one retried from a previous day [Inference]", "A date that differs from the current AFAQ business day [Inference]" ], "actions": [ "Sending participant: set the value date to the current business day and resend as a new payment", "For a customer's future-dated instruction, hold it in the bank's own systems and release it on the value date, as GPC's FAQ says banks must", "Check the joint calendar before resending if the date falls near a holiday in either country" ], "retry": { "allowed": true, "rule": "The refused payment stays refused. Once the cause is fixed, the sending participant may send it again as a new payment with a new unique message reference; it must not reuse the original reference, but it may keep the same UETR (OR 42068309 section 7.3)." }, "facts": { "return_windows": [ { "action": "refuse the payment and send the rejection back towards the sender", "by": "AFAQ Central Component or a Regional Payment Gateway; SAMA's list does not say which component raises which RJ code", "deadline": "At validation, before the payment is booked [Inference: the rules describe rejection as a payment the Central Component cannot process]; no time limit is published." }, { "action": "turn the rejection into a return payment to the sending participant, stating this code as the reason", "by": "Sending Regional Payment Gateway", "deadline": "No public deadline. SAMA's rules require every payment to be confirmed, returned or rejected before end-of-day processing starts (OR 42068309 section 7.5), so the same business day [Inference]." } ], "applies_to": "AFAQ cross-currency payments sent by a Saudi direct participant under SAMA's rules (circular 42068309, Appendix 2): a payment that a Regional Payment Gateway or the AFAQ Central Component refuses, reported back to the sending participant as a return payment that carries this code. Participants in other GCC countries follow their own central bank's code list, which was not read." }, "caveat": "This code reaches the sender as a return payment, but it is a rejection by AFAQ itself, not a return by the receiving bank. SAMA publishes only a short label for each RJ code, with no definition, so the triggers here are a reading of the operating rules.", "related": [ "gcc-afaq-reject:RJ05", "gcc-afaq-reject:RJ06", "gcc-afaq-reject:RJ17", "gcc-afaq:hours", "gcc-afaq:limits" ], "basis": { "sources": "SAMA rulebook portal, English pages read 2026-09-18: Operating Rules for Cross Currency Payments using AFAQ Service, circular 42068309 (2021-05-05), Appendix 2 (Return and Rejection Codes, also read as its own page) for the code and its label. How the service handles it rests on sections 5.3 and 7.2, with the GPC AFAQ FAQs page (read 2026-09-18) on future-dated payments. The portal says its pages carry no legal effect, so the class is public_primary. SAMA gives each RJ code a short label only; triggers and actions marked [Inference] are Orca's reading. The GPC Operating Rules and Regulations were not used. Nothing is quoted.", "confidence": "medium" }, "currency": { "effective_since": "2021-05-05", "effective_note": "In SAMA's Appendix 2 since circular 42068309 (2021-05-05, 1442-09-24 H), In-Force with no later version shown on 2026-09-18. The appendix says the Central Component's code dictionary may be updated from time to time, so the live list may differ from the published one.", "source_edition": "OR 42068309 Appendix 2 (2021-05-05)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://rulebook.sama.gov.sa/en/operating-rules-cross-currency-payments-using-afaq-service", "source_class": "public_primary", "source_title": "Operating Rules for Cross Currency Payments using AFAQ Service (SAMA circular 42068309, including Appendix 2)", "checked_on": "2026-09-19", "checked_by": "gcc-afaq validator session", "notes": "Confirms SAMA's label for RJ03, Invalid Value Date, and section 7.2(c)'s same-day-value-only rule and section 5.3's joint-working-day calendar check, plus section 7.3's return path to the sender." } ] }, "rail_name": "GCC AFAQ Payment Rejections", "governing_authority": "SAMA (rules for Saudi direct participants); GCC central banks via GPC (system)", "snapshot": "2026-09-18", "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "gcc-afaq-reject:RJ04", "id": "RJ04", "rail": "gcc-afaq-reject", "kind": "reason-code", "name": "Currency code does not match the receiving country", "group": "technical", "summary": "The receiving-side currency code in the payment is not the currency of the receiving participant's country. Every AFAQ payment is paid out in the receiving country's own currency, so the code must match the country of the bank being paid. This record reports SAMA's rules for Saudi direct participants.", "triggers": [ "The receiving currency code belongs to a different GCC country from the receiving participant [Inference]", "The sending currency was repeated in the receiving currency field [Inference]", "A foreign bank branch was addressed in its home country's currency instead of the currency of the country where it participates [Inference]" ], "actions": [ "Sending participant: set the receiving currency to that of the receiving participant's country and recompute the amount at the day's confirmed rate for that pair", "Check the receiving participant's country against GPC's participant list, which groups banks by the country where they participate", "Resend as a new payment with a new unique message reference" ], "retry": { "allowed": true, "rule": "The refused payment stays refused. Once the cause is fixed, the sending participant may send it again as a new payment with a new unique message reference; it must not reuse the original reference, but it may keep the same UETR (OR 42068309 section 7.3)." }, "facts": { "return_windows": [ { "action": "refuse the payment and send the rejection back towards the sender", "by": "AFAQ Central Component or a Regional Payment Gateway; SAMA's list does not say which component raises which RJ code", "deadline": "At validation, before the payment is booked [Inference: the rules describe rejection as a payment the Central Component cannot process]; no time limit is published." }, { "action": "turn the rejection into a return payment to the sending participant, stating this code as the reason", "by": "Sending Regional Payment Gateway", "deadline": "No public deadline. SAMA's rules require every payment to be confirmed, returned or rejected before end-of-day processing starts (OR 42068309 section 7.5), so the same business day [Inference]." } ], "applies_to": "AFAQ cross-currency payments sent by a Saudi direct participant under SAMA's rules (circular 42068309, Appendix 2): a payment that a Regional Payment Gateway or the AFAQ Central Component refuses, reported back to the sending participant as a return payment that carries this code. Participants in other GCC countries follow their own central bank's code list, which was not read." }, "caveat": "This code reaches the sender as a return payment, but it is a rejection by AFAQ itself, not a return by the receiving bank. SAMA publishes only a short label for each RJ code, with no definition, so the triggers here are a reading of the operating rules.", "related": [ "gcc-afaq-reject:RJ02", "gcc-afaq-reject:RJ08", "gcc-afaq:participants" ], "basis": { "sources": "SAMA rulebook portal, English pages read 2026-09-18: Operating Rules for Cross Currency Payments using AFAQ Service, circular 42068309 (2021-05-05), Appendix 2 (Return and Rejection Codes, also read as its own page) for the code and its label. How the service handles it rests on sections 1 (Cross-currency payment), 6 and 7.2. The portal says its pages carry no legal effect, so the class is public_primary. SAMA gives each RJ code a short label only; triggers and actions marked [Inference] are Orca's reading. The GPC Operating Rules and Regulations were not used. Nothing is quoted.", "confidence": "medium" }, "currency": { "effective_since": "2021-05-05", "effective_note": "In SAMA's Appendix 2 since circular 42068309 (2021-05-05, 1442-09-24 H), In-Force with no later version shown on 2026-09-18. The appendix says the Central Component's code dictionary may be updated from time to time, so the live list may differ from the published one.", "source_edition": "OR 42068309 Appendix 2 (2021-05-05)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://rulebook.sama.gov.sa/en/operating-rules-cross-currency-payments-using-afaq-service", "source_class": "public_primary", "source_title": "Operating Rules for Cross Currency Payments using AFAQ Service (SAMA circular 42068309, including Appendix 2)", "checked_on": "2026-09-19", "checked_by": "gcc-afaq validator session", "notes": "Confirms SAMA's label for RJ04, Currency code wrong for Receiving country, and section 7.2(d)'s requirement that the message carry the correct receiving-country currency code, plus section 7.3's return path to the sender." } ] }, "rail_name": "GCC AFAQ Payment Rejections", "governing_authority": "SAMA (rules for Saudi direct participants); GCC central banks via GPC (system)", "snapshot": "2026-09-18", "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "gcc-afaq-reject:RJ05", "id": "RJ05", "rail": "gcc-afaq-reject", "kind": "reason-code", "name": "Receiving country not working that day", "group": "administrative", "summary": "The day is not a working day in the receiving country on the calendar the Central Component holds. AFAQ processes a payment only when the sending and the receiving country are both working, so a payment to a country on its weekend or a public holiday is refused. This record reports SAMA's rules for Saudi direct participants.", "triggers": [ "A public holiday in the receiving country [Inference]", "A payment to the UAE on a Sunday, when GPC says AFAQ is closed in the UAE [Inference]", "A change the receiving country's central bank made to its calendar [Inference]" ], "actions": [ "Sending participant: resend as a new payment on the next day both countries work, with that day's value date and confirmed rate", "Tell the customer when the payment will go and that the rate will be that day's", "Check GPC's working hours page, which shows each country's status for the day" ], "retry": { "allowed": true, "rule": "The refused payment stays refused. Once the cause is fixed, the sending participant may send it again as a new payment with a new unique message reference; it must not reuse the original reference, but it may keep the same UETR (OR 42068309 section 7.3). Wait for the next joint working day." }, "facts": { "return_windows": [ { "action": "refuse the payment and send the rejection back towards the sender", "by": "AFAQ Central Component or a Regional Payment Gateway; SAMA's list does not say which component raises which RJ code", "deadline": "At validation, before the payment is booked [Inference: the rules describe rejection as a payment the Central Component cannot process]; no time limit is published." }, { "action": "turn the rejection into a return payment to the sending participant, stating this code as the reason", "by": "Sending Regional Payment Gateway", "deadline": "No public deadline. SAMA's rules require every payment to be confirmed, returned or rejected before end-of-day processing starts (OR 42068309 section 7.5), so the same business day [Inference]." } ], "applies_to": "AFAQ cross-currency payments sent by a Saudi direct participant under SAMA's rules (circular 42068309, Appendix 2): a payment that a Regional Payment Gateway or the AFAQ Central Component refuses, reported back to the sending participant as a return payment that carries this code. Participants in other GCC countries follow their own central bank's code list, which was not read." }, "caveat": "This code reaches the sender as a return payment, but it is a rejection by AFAQ itself, not a return by the receiving bank. SAMA publishes only a short label for each RJ code, with no definition, so the triggers here are a reading of the operating rules.", "related": [ "gcc-afaq-reject:RJ06", "gcc-afaq-reject:RJ17", "gcc-afaq-reject:RJ03", "gcc-afaq:hours" ], "basis": { "sources": "SAMA rulebook portal, English pages read 2026-09-18: Operating Rules for Cross Currency Payments using AFAQ Service, circular 42068309 (2021-05-05), Appendix 2 (Return and Rejection Codes, also read as its own page) for the code and its label. How the service handles it rests on sections 5.3 and 7.2, with GPC's Working Hours and Official Holidays page (read 2026-09-18). The portal says its pages carry no legal effect, so the class is public_primary. SAMA gives each RJ code a short label only; triggers and actions marked [Inference] are Orca's reading. The GPC Operating Rules and Regulations were not used. Nothing is quoted.", "confidence": "medium" }, "currency": { "effective_since": "2021-05-05", "effective_note": "In SAMA's Appendix 2 since circular 42068309 (2021-05-05, 1442-09-24 H), In-Force with no later version shown on 2026-09-18. The appendix says the Central Component's code dictionary may be updated from time to time, so the live list may differ from the published one.", "source_edition": "OR 42068309 Appendix 2 (2021-05-05)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://rulebook.sama.gov.sa/en/operating-rules-cross-currency-payments-using-afaq-service", "source_class": "public_primary", "source_title": "Operating Rules for Cross Currency Payments using AFAQ Service (SAMA circular 42068309, including Appendix 2)", "checked_on": "2026-09-19", "checked_by": "gcc-afaq validator session", "notes": "Confirms SAMA's label for RJ05, A non working day in the Receiving Country, and section 5.3's rule that cross-currency payments process only when both the sending and receiving country are working, plus section 7.3's return path to the sender." } ] }, "rail_name": "GCC AFAQ Payment Rejections", "governing_authority": "SAMA (rules for Saudi direct participants); GCC central banks via GPC (system)", "snapshot": "2026-09-18", "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "gcc-afaq-reject:RJ06", "id": "RJ06", "rail": "gcc-afaq-reject", "kind": "reason-code", "name": "Sending country not working that day", "group": "administrative", "summary": "The day is not a working day in the sending country on AFAQ's calendar. For a Saudi sender that means a day SAMA has not declared an AFAQ business day, such as a weekend, a public holiday or a day SAMA switched to non-business. This record reports SAMA's rules for Saudi direct participants.", "triggers": [ "A payment released on a Saudi weekend or public holiday, for example from an automated queue [Inference]", "A day SAMA declared a non-business day for AFAQ [Inference]", "A mismatch between the participant's own calendar and AFAQ's [Inference]" ], "actions": [ "Sending participant: resend as a new payment on the next day both countries work", "Align internal calendars with the business days SAMA announces for AFAQ", "Tell the customer the new timing" ], "retry": { "allowed": true, "rule": "The refused payment stays refused. Once the cause is fixed, the sending participant may send it again as a new payment with a new unique message reference; it must not reuse the original reference, but it may keep the same UETR (OR 42068309 section 7.3). Wait for the next joint working day." }, "facts": { "return_windows": [ { "action": "refuse the payment and send the rejection back towards the sender", "by": "AFAQ Central Component or a Regional Payment Gateway; SAMA's list does not say which component raises which RJ code", "deadline": "At validation, before the payment is booked [Inference: the rules describe rejection as a payment the Central Component cannot process]; no time limit is published." }, { "action": "turn the rejection into a return payment to the sending participant, stating this code as the reason", "by": "Sending Regional Payment Gateway", "deadline": "No public deadline. SAMA's rules require every payment to be confirmed, returned or rejected before end-of-day processing starts (OR 42068309 section 7.5), so the same business day [Inference]." } ], "applies_to": "AFAQ cross-currency payments sent by a Saudi direct participant under SAMA's rules (circular 42068309, Appendix 2): a payment that a Regional Payment Gateway or the AFAQ Central Component refuses, reported back to the sending participant as a return payment that carries this code. Participants in other GCC countries follow their own central bank's code list, which was not read." }, "caveat": "This code reaches the sender as a return payment, but it is a rejection by AFAQ itself, not a return by the receiving bank. SAMA publishes only a short label for each RJ code, with no definition, so the triggers here are a reading of the operating rules.", "related": [ "gcc-afaq-reject:RJ05", "gcc-afaq-reject:RJ17", "gcc-afaq:hours" ], "basis": { "sources": "SAMA rulebook portal, English pages read 2026-09-18: Operating Rules for Cross Currency Payments using AFAQ Service, circular 42068309 (2021-05-05), Appendix 2 (Return and Rejection Codes, also read as its own page) for the code and its label. How the service handles it rests on sections 5.2, 5.3 and 7.2. The portal says its pages carry no legal effect, so the class is public_primary. SAMA gives each RJ code a short label only; triggers and actions marked [Inference] are Orca's reading. The GPC Operating Rules and Regulations were not used. Nothing is quoted.", "confidence": "medium" }, "currency": { "effective_since": "2021-05-05", "effective_note": "In SAMA's Appendix 2 since circular 42068309 (2021-05-05, 1442-09-24 H), In-Force with no later version shown on 2026-09-18. The appendix says the Central Component's code dictionary may be updated from time to time, so the live list may differ from the published one.", "source_edition": "OR 42068309 Appendix 2 (2021-05-05)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://rulebook.sama.gov.sa/en/operating-rules-cross-currency-payments-using-afaq-service", "source_class": "public_primary", "source_title": "Operating Rules for Cross Currency Payments using AFAQ Service (SAMA circular 42068309, including Appendix 2)", "checked_on": "2026-09-19", "checked_by": "gcc-afaq validator session", "notes": "Confirms SAMA's label for RJ06, A non working day in the Sending Country, and section 5.3's joint-working-day rule, plus section 7.3's return path to the sender." } ] }, "rail_name": "GCC AFAQ Payment Rejections", "governing_authority": "SAMA (rules for Saudi direct participants); GCC central banks via GPC (system)", "snapshot": "2026-09-18", "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "gcc-afaq-reject:RJ07", "id": "RJ07", "rail": "gcc-afaq-reject", "kind": "reason-code", "name": "Outside the allowed business day period", "group": "administrative", "summary": "The payment arrived in a phase of the AFAQ business day that does not take it. SAMA's rules split the day into phases, and only the exchange periods accept payments; the later part of the exchange time takes interbank payments only. A payment sent outside a phase that accepts it is refused [Inference: SAMA gives only the label]. This record reports SAMA's rules for Saudi direct participants.", "triggers": [ "A payment sent before the exchange period opens, while exchange rates are still being agreed [Inference]", "A customer payment sent in the interbank-only period [Inference]", "A payment sent after the cut-off, in the reporting or settlement phases [Inference]" ], "actions": [ "Sending participant: resend in the next exchange period; GPC's timetable shows 08:30 to 15:00 Saudi time", "If the cut-off has passed, send on the next joint working day", "For an urgent payment, a Saudi participant can ask SAMA to extend the cut-off; if SAMA agrees, it costs SAR 25,000 per 30 minutes (SAMA Charging Policy circular 43038107 section 4.1)" ], "retry": { "allowed": true, "rule": "The refused payment stays refused. Once the cause is fixed, the sending participant may send it again as a new payment with a new unique message reference; it must not reuse the original reference, but it may keep the same UETR (OR 42068309 section 7.3)." }, "facts": { "return_windows": [ { "action": "refuse the payment and send the rejection back towards the sender", "by": "AFAQ Central Component or a Regional Payment Gateway; SAMA's list does not say which component raises which RJ code", "deadline": "At validation, before the payment is booked [Inference: the rules describe rejection as a payment the Central Component cannot process]; no time limit is published." }, { "action": "turn the rejection into a return payment to the sending participant, stating this code as the reason", "by": "Sending Regional Payment Gateway", "deadline": "No public deadline. SAMA's rules require every payment to be confirmed, returned or rejected before end-of-day processing starts (OR 42068309 section 7.5), so the same business day [Inference]." } ], "applies_to": "AFAQ cross-currency payments sent by a Saudi direct participant under SAMA's rules (circular 42068309, Appendix 2): a payment that a Regional Payment Gateway or the AFAQ Central Component refuses, reported back to the sending participant as a return payment that carries this code. Participants in other GCC countries follow their own central bank's code list, which was not read." }, "caveat": "This code reaches the sender as a return payment, but it is a rejection by AFAQ itself, not a return by the receiving bank. SAMA publishes only a short label for each RJ code, with no definition, so the triggers here are a reading of the operating rules.", "related": [ "gcc-afaq-reject:RJ16", "gcc-afaq-reject:RJ17", "gcc-afaq-reject:RJ13", "gcc-afaq:hours" ], "basis": { "sources": "SAMA rulebook portal, English pages read 2026-09-18: Operating Rules for Cross Currency Payments using AFAQ Service, circular 42068309 (2021-05-05), Appendix 2 (Return and Rejection Codes, also read as its own page) for the code and its label. How the service handles it rests on sections 5.1, 5.4 and 5.5, with SAMA's Charging Policy circular 43038107 (2021-12-02) section 4.1 and GPC's Working Hours page (read 2026-09-18). The portal says its pages carry no legal effect, so the class is public_primary. SAMA gives each RJ code a short label only; triggers and actions marked [Inference] are Orca's reading. The GPC Operating Rules and Regulations were not used. Nothing is quoted.", "confidence": "medium" }, "currency": { "effective_since": "2021-05-05", "effective_note": "In SAMA's Appendix 2 since circular 42068309 (2021-05-05, 1442-09-24 H), In-Force with no later version shown on 2026-09-18. The appendix says the Central Component's code dictionary may be updated from time to time, so the live list may differ from the published one.", "source_edition": "OR 42068309 Appendix 2 (2021-05-05)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://rulebook.sama.gov.sa/en/operating-rules-cross-currency-payments-using-afaq-service", "source_class": "public_primary", "source_title": "Operating Rules for Cross Currency Payments using AFAQ Service (SAMA circular 42068309, including Appendix 2)", "checked_on": "2026-09-19", "checked_by": "gcc-afaq validator session", "notes": "Confirms SAMA's label for RJ07, Invalid business day period, and section 5.1's exchange period split into a general exchange window and a later interbank-only window, plus section 7.3's return path to the sender. Does not state which period a specific payment type falls outside of." } ] }, "rail_name": "GCC AFAQ Payment Rejections", "governing_authority": "SAMA (rules for Saudi direct participants); GCC central banks via GPC (system)", "snapshot": "2026-09-18", "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "gcc-afaq-reject:RJ08", "id": "RJ08", "rail": "gcc-afaq-reject", "kind": "reason-code", "name": "Invalid receiving participant", "group": "network", "summary": "The receiving participant named in the payment is not a valid AFAQ participant, so the payment cannot be routed. The gateways and the Central Component check each payment against the participant directory they hold. This record reports SAMA's rules for Saudi direct participants.", "triggers": [ "The beneficiary's bank is not connected to AFAQ; in the UAE, for instance, GPC lists only the central bank and one commercial bank [Inference]", "The receiving participant's identifier was mistyped [Inference]", "The bank has left AFAQ or not yet gone live [Inference]" ], "actions": [ "Sending participant: check the receiving bank against GPC's current participant list", "If the bank is not a participant, send by another channel such as correspondent banking and tell the customer", "If it is a participant, correct the identifier and resend as a new payment" ], "retry": { "allowed": true, "rule": "The refused payment stays refused. Once the cause is fixed, the sending participant may send it again as a new payment with a new unique message reference; it must not reuse the original reference, but it may keep the same UETR (OR 42068309 section 7.3). Only worth doing if the receiving bank is in fact a participant." }, "facts": { "return_windows": [ { "action": "refuse the payment and send the rejection back towards the sender", "by": "AFAQ Central Component or a Regional Payment Gateway; SAMA's list does not say which component raises which RJ code", "deadline": "At validation, before the payment is booked [Inference: the rules describe rejection as a payment the Central Component cannot process]; no time limit is published." }, { "action": "turn the rejection into a return payment to the sending participant, stating this code as the reason", "by": "Sending Regional Payment Gateway", "deadline": "No public deadline. SAMA's rules require every payment to be confirmed, returned or rejected before end-of-day processing starts (OR 42068309 section 7.5), so the same business day [Inference]." } ], "applies_to": "AFAQ cross-currency payments sent by a Saudi direct participant under SAMA's rules (circular 42068309, Appendix 2): a payment that a Regional Payment Gateway or the AFAQ Central Component refuses, reported back to the sending participant as a return payment that carries this code. Participants in other GCC countries follow their own central bank's code list, which was not read." }, "caveat": "This code reaches the sender as a return payment, but it is a rejection by AFAQ itself, not a return by the receiving bank. SAMA publishes only a short label for each RJ code, with no definition, so the triggers here are a reading of the operating rules.", "related": [ "gcc-afaq-reject:RJ09", "gcc-afaq-reject:RJ12", "gcc-afaq-reject:RJ04", "gcc-afaq:participants" ], "basis": { "sources": "SAMA rulebook portal, English pages read 2026-09-18: Operating Rules for Cross Currency Payments using AFAQ Service, circular 42068309 (2021-05-05), Appendix 2 (Return and Rejection Codes, also read as its own page) for the code and its label. How the service handles it rests on sections 4.1.2, 4.1.5 and 7.2, with GPC's AFAQ Participants page (read 2026-09-18). The portal says its pages carry no legal effect, so the class is public_primary. SAMA gives each RJ code a short label only; triggers and actions marked [Inference] are Orca's reading. The GPC Operating Rules and Regulations were not used. Nothing is quoted.", "confidence": "medium" }, "currency": { "effective_since": "2021-05-05", "effective_note": "In SAMA's Appendix 2 since circular 42068309 (2021-05-05, 1442-09-24 H), In-Force with no later version shown on 2026-09-18. The appendix says the Central Component's code dictionary may be updated from time to time, so the live list may differ from the published one.", "source_edition": "OR 42068309 Appendix 2 (2021-05-05)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://rulebook.sama.gov.sa/en/operating-rules-cross-currency-payments-using-afaq-service", "source_class": "public_primary", "source_title": "Operating Rules for Cross Currency Payments using AFAQ Service (SAMA circular 42068309, including Appendix 2)", "checked_on": "2026-09-19", "checked_by": "gcc-afaq validator session", "notes": "Confirms SAMA's label for RJ08, Invalid Receiving Direct Participant, and section 4.1.2's rule that the RPG holds the current Participant Directory for message validation, plus section 7.3's return path to the sender." } ] }, "rail_name": "GCC AFAQ Payment Rejections", "governing_authority": "SAMA (rules for Saudi direct participants); GCC central banks via GPC (system)", "snapshot": "2026-09-18", "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "gcc-afaq-reject:RJ09", "id": "RJ09", "rail": "gcc-afaq-reject", "kind": "reason-code", "name": "Participant not active", "group": "network", "summary": "A participant involved in the payment is in AFAQ's directory but not active, so the payment cannot proceed. Most likely the receiving participant has been suspended, has not yet gone live, or is withdrawing [Inference: SAMA's label does not say which participant]. This record reports SAMA's rules for Saudi direct participants.", "triggers": [ "The receiving participant is suspended by its central bank [Inference]", "The receiving participant is onboarded in the directory but not yet live [Inference]", "The sending participant's own status is suspended [Inference]" ], "actions": [ "Sending participant: check notices from SAMA, which must tell participants of suspensions and changes to other participants (OR 42068309 section 3.5)", "If the receiving bank is inactive, hold the payment or use another channel, and tell the customer", "If the sender's own status is the problem, contact SAMA" ], "retry": { "allowed": true, "rule": "The refused payment stays refused. Once the cause is fixed, the sending participant may send it again as a new payment with a new unique message reference; it must not reuse the original reference, but it may keep the same UETR (OR 42068309 section 7.3). Only after the participant is active again." }, "facts": { "return_windows": [ { "action": "refuse the payment and send the rejection back towards the sender", "by": "AFAQ Central Component or a Regional Payment Gateway; SAMA's list does not say which component raises which RJ code", "deadline": "At validation, before the payment is booked [Inference: the rules describe rejection as a payment the Central Component cannot process]; no time limit is published." }, { "action": "turn the rejection into a return payment to the sending participant, stating this code as the reason", "by": "Sending Regional Payment Gateway", "deadline": "No public deadline. SAMA's rules require every payment to be confirmed, returned or rejected before end-of-day processing starts (OR 42068309 section 7.5), so the same business day [Inference]." } ], "applies_to": "AFAQ cross-currency payments sent by a Saudi direct participant under SAMA's rules (circular 42068309, Appendix 2): a payment that a Regional Payment Gateway or the AFAQ Central Component refuses, reported back to the sending participant as a return payment that carries this code. Participants in other GCC countries follow their own central bank's code list, which was not read." }, "caveat": "This code reaches the sender as a return payment, but it is a rejection by AFAQ itself, not a return by the receiving bank. SAMA publishes only a short label for each RJ code, with no definition, so the triggers here are a reading of the operating rules.", "related": [ "gcc-afaq-reject:RJ08", "gcc-afaq-reject:RJ16", "gcc-afaq:participants" ], "basis": { "sources": "SAMA rulebook portal, English pages read 2026-09-18: Operating Rules for Cross Currency Payments using AFAQ Service, circular 42068309 (2021-05-05), Appendix 2 (Return and Rejection Codes, also read as its own page) for the code and its label. How the service handles it rests on sections 3.2, 3.5 and 4.1.2. The portal says its pages carry no legal effect, so the class is public_primary. SAMA gives each RJ code a short label only; triggers and actions marked [Inference] are Orca's reading. The GPC Operating Rules and Regulations were not used. Nothing is quoted.", "confidence": "medium" }, "currency": { "effective_since": "2021-05-05", "effective_note": "In SAMA's Appendix 2 since circular 42068309 (2021-05-05, 1442-09-24 H), In-Force with no later version shown on 2026-09-18. The appendix says the Central Component's code dictionary may be updated from time to time, so the live list may differ from the published one.", "source_edition": "OR 42068309 Appendix 2 (2021-05-05)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://rulebook.sama.gov.sa/en/operating-rules-cross-currency-payments-using-afaq-service", "source_class": "public_primary", "source_title": "Operating Rules for Cross Currency Payments using AFAQ Service (SAMA circular 42068309, including Appendix 2)", "checked_on": "2026-09-19", "checked_by": "gcc-afaq validator session", "notes": "Confirms SAMA's label for RJ09, Participant is not active, and section 7.3's return path to the sender. The rules do not state which participant status changes count as inactive, matching the record's own inference flag." } ] }, "rail_name": "GCC AFAQ Payment Rejections", "governing_authority": "SAMA (rules for Saudi direct participants); GCC central banks via GPC (system)", "snapshot": "2026-09-18", "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "gcc-afaq-reject:RJ10", "id": "RJ10", "rail": "gcc-afaq-reject", "kind": "reason-code", "name": "Not delivered to the receiving domestic RTGS", "group": "network", "summary": "The payment got through the Central Component to the receiving country's gateway, but could not be handed on to that country's domestic RTGS. SAMA's rules say gateways do not send such payments back automatically; returning one is the gateway operator's decision, and this code reports that it was returned [Inference: SAMA gives only the label]. Unlike most RJ codes, the payment had already been booked when it failed [Inference]. This record reports SAMA's rules for Saudi direct participants.", "triggers": [ "An outage or queue in the receiving country's domestic RTGS [Inference]", "The receiving domestic RTGS refused the payment on its own checks [Inference]", "A communication failure between the receiving gateway and its RTGS [Inference]" ], "actions": [ "Sending participant: treat the payment as not delivered; the return brings the original amount back", "Before resending, check with SAMA whether the receiving side is working again; the sending central bank investigates any payment with no completion confirmation after 10 minutes (OR 42068309 section 7.5)", "Resend as a new payment once the receiving side is available" ], "retry": { "allowed": true, "rule": "The refused payment stays refused. Once the cause is fixed, the sending participant may send it again as a new payment with a new unique message reference; it must not reuse the original reference, but it may keep the same UETR (OR 42068309 section 7.3)." }, "facts": { "return_windows": [ { "action": "send the undeliverable payment back as a return carrying this code", "by": "Receiving Regional Payment Gateway, at its operator's decision [Inference: which component raises RJ10 is not stated]", "deadline": "No public deadline. Payments must be confirmed or returned before end-of-day processing (OR 42068309 section 7.5), so the same business day [Inference]." } ], "applies_to": "AFAQ cross-currency payments sent by a Saudi direct participant under SAMA's rules (circular 42068309, Appendix 2): a payment that a Regional Payment Gateway or the AFAQ Central Component refuses, reported back to the sending participant as a return payment that carries this code. Participants in other GCC countries follow their own central bank's code list, which was not read." }, "caveat": "This code reaches the sender as a return payment, but it is a rejection by AFAQ itself, not a return by the receiving bank. SAMA publishes only a short label for each RJ code, with no definition, so the triggers here are a reading of the operating rules.", "related": [ "gcc-afaq-reject:RJ13", "gcc-afaq:decision-points", "gcc-afaq:finality" ], "basis": { "sources": "SAMA rulebook portal, English pages read 2026-09-18: Operating Rules for Cross Currency Payments using AFAQ Service, circular 42068309 (2021-05-05), Appendix 2 (Return and Rejection Codes, also read as its own page) for the code and its label. How the service handles it rests on sections 4.1.4, 4.1.6, 5.1 item 8, 7.3 and 7.5. The portal says its pages carry no legal effect, so the class is public_primary. SAMA gives each RJ code a short label only; triggers and actions marked [Inference] are Orca's reading. The GPC Operating Rules and Regulations were not used. Nothing is quoted.", "confidence": "medium" }, "currency": { "effective_since": "2021-05-05", "effective_note": "In SAMA's Appendix 2 since circular 42068309 (2021-05-05, 1442-09-24 H), In-Force with no later version shown on 2026-09-18. The appendix says the Central Component's code dictionary may be updated from time to time, so the live list may differ from the published one.", "source_edition": "OR 42068309 Appendix 2 (2021-05-05)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://rulebook.sama.gov.sa/en/operating-rules-cross-currency-payments-using-afaq-service", "source_class": "public_primary", "source_title": "Operating Rules for Cross Currency Payments using AFAQ Service (SAMA circular 42068309, including Appendix 2)", "checked_on": "2026-09-19", "checked_by": "gcc-afaq validator session", "notes": "Confirms SAMA's label for RJ10, Non delivery to Receiving Domestic RTGS, and section 5.1 item 8's rule that a Regional Payment Gateway does not automatically return a payment it cannot deliver to its domestic RTGS, leaving that decision to the gateway operator, matching the record's summary exactly." } ] }, "rail_name": "GCC AFAQ Payment Rejections", "governing_authority": "SAMA (rules for Saudi direct participants); GCC central banks via GPC (system)", "snapshot": "2026-09-18", "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "gcc-afaq-reject:RJ11", "id": "RJ11", "rail": "gcc-afaq-reject", "kind": "reason-code", "name": "Exchange rate not authorised", "group": "administrative", "summary": "The exchange rate for the currency pair was not authorised that day. Each morning the central banks approve or decline the computed cross-rates; a pair with no approval stays unconfirmed and AFAQ blocks payments in it for the whole day. The sender did nothing wrong. This record reports SAMA's rules for Saudi direct participants.", "triggers": [ "A central bank declined the day's rate for the pair [Inference]", "A central bank sent neither approval nor decline, leaving the rate unconfirmed [Inference]" ], "actions": [ "Sending participant: do not resend in the same pair that day unless SAMA confirms the rate has since been authorised [Inference]", "Tell the customer the payment could not go today and offer the next business day or another channel", "Ask SAMA for the status of the pair if the block is unexpected" ], "retry": { "allowed": true, "rule": "The refused payment stays refused. Once the cause is fixed, the sending participant may send it again as a new payment with a new unique message reference; it must not reuse the original reference, but it may keep the same UETR (OR 42068309 section 7.3). In practice on a later business day, once the pair's rate is confirmed [Inference]." }, "facts": { "return_windows": [ { "action": "refuse the payment and send the rejection back towards the sender", "by": "AFAQ Central Component or a Regional Payment Gateway; SAMA's list does not say which component raises which RJ code", "deadline": "At validation, before the payment is booked [Inference: the rules describe rejection as a payment the Central Component cannot process]; no time limit is published." }, { "action": "turn the rejection into a return payment to the sending participant, stating this code as the reason", "by": "Sending Regional Payment Gateway", "deadline": "No public deadline. SAMA's rules require every payment to be confirmed, returned or rejected before end-of-day processing starts (OR 42068309 section 7.5), so the same business day [Inference]." } ], "applies_to": "AFAQ cross-currency payments sent by a Saudi direct participant under SAMA's rules (circular 42068309, Appendix 2): a payment that a Regional Payment Gateway or the AFAQ Central Component refuses, reported back to the sending participant as a return payment that carries this code. Participants in other GCC countries follow their own central bank's code list, which was not read." }, "caveat": "This code reaches the sender as a return payment, but it is a rejection by AFAQ itself, not a return by the receiving bank. SAMA publishes only a short label for each RJ code, with no definition, so the triggers here are a reading of the operating rules.", "related": [ "gcc-afaq-reject:RJ14", "gcc-afaq-reject:RJ15", "gcc-afaq-reject:RJ01", "gcc-afaq:decision-points", "gcc-afaq:settlement" ], "basis": { "sources": "SAMA rulebook portal, English pages read 2026-09-18: Operating Rules for Cross Currency Payments using AFAQ Service, circular 42068309 (2021-05-05), Appendix 2 (Return and Rejection Codes, also read as its own page) for the code and its label. How the service handles it rests on sections 5.1 items 2 to 4 and 6. The portal says its pages carry no legal effect, so the class is public_primary. SAMA gives each RJ code a short label only; triggers and actions marked [Inference] are Orca's reading. The GPC Operating Rules and Regulations were not used. Nothing is quoted.", "confidence": "medium" }, "currency": { "effective_since": "2021-05-05", "effective_note": "In SAMA's Appendix 2 since circular 42068309 (2021-05-05, 1442-09-24 H), In-Force with no later version shown on 2026-09-18. The appendix says the Central Component's code dictionary may be updated from time to time, so the live list may differ from the published one.", "source_edition": "OR 42068309 Appendix 2 (2021-05-05)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://rulebook.sama.gov.sa/en/operating-rules-cross-currency-payments-using-afaq-service", "source_class": "public_primary", "source_title": "Operating Rules for Cross Currency Payments using AFAQ Service (SAMA circular 42068309, including Appendix 2)", "checked_on": "2026-09-19", "checked_by": "gcc-afaq validator session", "notes": "Confirms SAMA's label for RJ11, FX rate is not authorized, and section 5.1 items 2 to 3's rule that central banks approve or decline each day's cross-rates and that an unconfirmed pair is blocked for the whole day." } ] }, "rail_name": "GCC AFAQ Payment Rejections", "governing_authority": "SAMA (rules for Saudi direct participants); GCC central banks via GPC (system)", "snapshot": "2026-09-18", "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "gcc-afaq-reject:RJ12", "id": "RJ12", "rail": "gcc-afaq-reject", "kind": "reason-code", "name": "Invalid BIC", "group": "network", "summary": "A BIC in the payment is not valid. AFAQ identifies participants by BIC even though it does not use the SWIFT network, and the gateways check payments against the participant directory; a BIC that is malformed or unknown is refused [Inference: SAMA does not say which BIC field is checked]. This record reports SAMA's rules for Saudi direct participants.", "triggers": [ "The receiving participant's BIC was mistyped or is in the wrong format [Inference]", "A branch or head-office BIC was used where AFAQ expects another [Inference]", "The BIC belongs to a bank that is not in AFAQ's directory [Inference]" ], "actions": [ "Sending participant: correct the BIC against the participant directory", "Resend as a new payment with a new unique message reference", "If the bank is not an AFAQ participant, use another channel" ], "retry": { "allowed": true, "rule": "The refused payment stays refused. Once the cause is fixed, the sending participant may send it again as a new payment with a new unique message reference; it must not reuse the original reference, but it may keep the same UETR (OR 42068309 section 7.3)." }, "facts": { "return_windows": [ { "action": "refuse the payment and send the rejection back towards the sender", "by": "AFAQ Central Component or a Regional Payment Gateway; SAMA's list does not say which component raises which RJ code", "deadline": "At validation, before the payment is booked [Inference: the rules describe rejection as a payment the Central Component cannot process]; no time limit is published." }, { "action": "turn the rejection into a return payment to the sending participant, stating this code as the reason", "by": "Sending Regional Payment Gateway", "deadline": "No public deadline. SAMA's rules require every payment to be confirmed, returned or rejected before end-of-day processing starts (OR 42068309 section 7.5), so the same business day [Inference]." } ], "applies_to": "AFAQ cross-currency payments sent by a Saudi direct participant under SAMA's rules (circular 42068309, Appendix 2): a payment that a Regional Payment Gateway or the AFAQ Central Component refuses, reported back to the sending participant as a return payment that carries this code. Participants in other GCC countries follow their own central bank's code list, which was not read." }, "caveat": "This code reaches the sender as a return payment, but it is a rejection by AFAQ itself, not a return by the receiving bank. SAMA publishes only a short label for each RJ code, with no definition, so the triggers here are a reading of the operating rules.", "related": [ "gcc-afaq-reject:RJ08", "gcc-afaq:participants", "gcc-afaq:messages" ], "basis": { "sources": "SAMA rulebook portal, English pages read 2026-09-18: Operating Rules for Cross Currency Payments using AFAQ Service, circular 42068309 (2021-05-05), Appendix 2 (Return and Rejection Codes, also read as its own page) for the code and its label. How the service handles it rests on sections 4.1.2 and 7.2, with GPC's AFAQ FAQs page (read 2026-09-18) on the private network. The portal says its pages carry no legal effect, so the class is public_primary. SAMA gives each RJ code a short label only; triggers and actions marked [Inference] are Orca's reading. The GPC Operating Rules and Regulations were not used. Nothing is quoted.", "confidence": "medium" }, "currency": { "effective_since": "2021-05-05", "effective_note": "In SAMA's Appendix 2 since circular 42068309 (2021-05-05, 1442-09-24 H), In-Force with no later version shown on 2026-09-18. The appendix says the Central Component's code dictionary may be updated from time to time, so the live list may differ from the published one.", "source_edition": "OR 42068309 Appendix 2 (2021-05-05)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://rulebook.sama.gov.sa/en/operating-rules-cross-currency-payments-using-afaq-service", "source_class": "public_primary", "source_title": "Operating Rules for Cross Currency Payments using AFAQ Service (SAMA circular 42068309, including Appendix 2)", "checked_on": "2026-09-19", "checked_by": "gcc-afaq validator session", "notes": "Confirms SAMA's label for RJ12, BIC is invalid, and section 7.3's return path to the sender. The rules do not say which BIC field is checked or how, matching the record's own inference flag." } ] }, "rail_name": "GCC AFAQ Payment Rejections", "governing_authority": "SAMA (rules for Saudi direct participants); GCC central banks via GPC (system)", "snapshot": "2026-09-18", "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "gcc-afaq-reject:RJ13", "id": "RJ13", "rail": "gcc-afaq-reject", "kind": "reason-code", "name": "Returned at cut-off, not delivered", "group": "network", "summary": "The payment had not been delivered when the day closed, so AFAQ sent it back at the cut-off. SAMA's rules have the Central Component return, at the end of the day, any payment it could not deliver to the receiving country's gateway. The sender had been debited when the payment was booked, and this return brings the money back the same day [Inference]. This record reports SAMA's rules for Saudi direct participants.", "triggers": [ "The receiving country's gateway was unreachable until the end of the exchange period [Inference]", "A queue in the Central Component or receiving gateway that did not clear before cut-off [Inference]" ], "actions": [ "Sending participant: treat the payment as not delivered and reconcile the returned amount", "Resend as a new payment on the next day both countries work, after checking the receiving side is available", "Tell the customer the transfer will go on a later day at that day's rate" ], "retry": { "allowed": true, "rule": "The refused payment stays refused. Once the cause is fixed, the sending participant may send it again as a new payment with a new unique message reference; it must not reuse the original reference, but it may keep the same UETR (OR 42068309 section 7.3). On a later joint working day." }, "facts": { "return_windows": [ { "action": "return the undelivered payment to the sender automatically, carrying this code", "by": "AFAQ Central Component, through the sending Regional Payment Gateway", "deadline": "At the end-of-day operations after the exchange periods close (OR 42068309 section 5.1 item 8); GPC's timetable puts the close of exchange at 15:00 Saudi time." } ], "applies_to": "AFAQ cross-currency payments sent by a Saudi direct participant under SAMA's rules (circular 42068309, Appendix 2): a payment that a Regional Payment Gateway or the AFAQ Central Component refuses, reported back to the sending participant as a return payment that carries this code. Participants in other GCC countries follow their own central bank's code list, which was not read." }, "caveat": "This code reaches the sender as a return payment, but it is a rejection by AFAQ itself, not a return by the receiving bank. SAMA publishes only a short label for each RJ code, with no definition, so the triggers here are a reading of the operating rules.", "related": [ "gcc-afaq-reject:RJ10", "gcc-afaq-reject:RJ07", "gcc-afaq:finality", "gcc-afaq:hours" ], "basis": { "sources": "SAMA rulebook portal, English pages read 2026-09-18: Operating Rules for Cross Currency Payments using AFAQ Service, circular 42068309 (2021-05-05), Appendix 2 (Return and Rejection Codes, also read as its own page) for the code and its label. How the service handles it rests on sections 5.1 item 8, 7.3, 7.5 and 7.13. The portal says its pages carry no legal effect, so the class is public_primary. SAMA gives each RJ code a short label only; triggers and actions marked [Inference] are Orca's reading. The GPC Operating Rules and Regulations were not used. Nothing is quoted.", "confidence": "medium" }, "currency": { "effective_since": "2021-05-05", "effective_note": "In SAMA's Appendix 2 since circular 42068309 (2021-05-05, 1442-09-24 H), In-Force with no later version shown on 2026-09-18. The appendix says the Central Component's code dictionary may be updated from time to time, so the live list may differ from the published one.", "source_edition": "OR 42068309 Appendix 2 (2021-05-05)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://rulebook.sama.gov.sa/en/operating-rules-cross-currency-payments-using-afaq-service", "source_class": "public_primary", "source_title": "Operating Rules for Cross Currency Payments using AFAQ Service (SAMA circular 42068309, including Appendix 2)", "checked_on": "2026-09-19", "checked_by": "gcc-afaq validator session", "notes": "Confirms SAMA's label for RJ13, Returned at cut-off time as not delivered, and section 5.1 item 8's rule that the Central Component automatically returns, at end of day, payments it could not deliver to the receiving country's gateway, matching the record's summary exactly." } ] }, "rail_name": "GCC AFAQ Payment Rejections", "governing_authority": "SAMA (rules for Saudi direct participants); GCC central banks via GPC (system)", "snapshot": "2026-09-18", "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "gcc-afaq-reject:RJ14", "id": "RJ14", "rail": "gcc-afaq-reject", "kind": "reason-code", "name": "No approved exchange rate found", "group": "administrative", "summary": "No approved exchange rate for the currency pair could be found when the payment was checked. The gateways and the Central Component hold the day's approved rates; if none is on file for the pair, the payment is refused. It is close to RJ11 and RJ15, and SAMA does not explain how they differ [Inference: RJ14 may mean the rate table lacks an approved entry rather than that approval was refused]. This record reports SAMA's rules for Saudi direct participants.", "triggers": [ "The day's rates had not yet been loaded into the checking component [Inference]", "No rate for the pair was approved that day [Inference]", "A rate table in a gateway was out of step with the Central Component [Inference]" ], "actions": [ "Sending participant: check with SAMA whether the pair's rate is approved for the day", "Resend as a new payment once an approved rate is available", "Tell the customer of any delay" ], "retry": { "allowed": true, "rule": "The refused payment stays refused. Once the cause is fixed, the sending participant may send it again as a new payment with a new unique message reference; it must not reuse the original reference, but it may keep the same UETR (OR 42068309 section 7.3)." }, "facts": { "return_windows": [ { "action": "refuse the payment and send the rejection back towards the sender", "by": "AFAQ Central Component or a Regional Payment Gateway; SAMA's list does not say which component raises which RJ code", "deadline": "At validation, before the payment is booked [Inference: the rules describe rejection as a payment the Central Component cannot process]; no time limit is published." }, { "action": "turn the rejection into a return payment to the sending participant, stating this code as the reason", "by": "Sending Regional Payment Gateway", "deadline": "No public deadline. SAMA's rules require every payment to be confirmed, returned or rejected before end-of-day processing starts (OR 42068309 section 7.5), so the same business day [Inference]." } ], "applies_to": "AFAQ cross-currency payments sent by a Saudi direct participant under SAMA's rules (circular 42068309, Appendix 2): a payment that a Regional Payment Gateway or the AFAQ Central Component refuses, reported back to the sending participant as a return payment that carries this code. Participants in other GCC countries follow their own central bank's code list, which was not read." }, "caveat": "This code reaches the sender as a return payment, but it is a rejection by AFAQ itself, not a return by the receiving bank. SAMA publishes only a short label for each RJ code, with no definition, so the triggers here are a reading of the operating rules.", "related": [ "gcc-afaq-reject:RJ11", "gcc-afaq-reject:RJ15", "gcc-afaq-reject:RJ01" ], "basis": { "sources": "SAMA rulebook portal, English pages read 2026-09-18: Operating Rules for Cross Currency Payments using AFAQ Service, circular 42068309 (2021-05-05), Appendix 2 (Return and Rejection Codes, also read as its own page) for the code and its label. How the service handles it rests on sections 4.1.2, 4.1.5, 5.1 items 2 to 4 and 6. The portal says its pages carry no legal effect, so the class is public_primary. SAMA gives each RJ code a short label only; triggers and actions marked [Inference] are Orca's reading. The GPC Operating Rules and Regulations were not used. Nothing is quoted.", "confidence": "low" }, "currency": { "effective_since": "2021-05-05", "effective_note": "In SAMA's Appendix 2 since circular 42068309 (2021-05-05, 1442-09-24 H), In-Force with no later version shown on 2026-09-18. The appendix says the Central Component's code dictionary may be updated from time to time, so the live list may differ from the published one.", "source_edition": "OR 42068309 Appendix 2 (2021-05-05)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://rulebook.sama.gov.sa/en/operating-rules-cross-currency-payments-using-afaq-service", "source_class": "public_primary", "source_title": "Operating Rules for Cross Currency Payments using AFAQ Service (SAMA circular 42068309, including Appendix 2)", "checked_on": "2026-09-19", "checked_by": "gcc-afaq validator session", "notes": "Confirms SAMA's label for RJ14, Approved FX rate not found, and section 5.1 items 2 to 4's rate approval process. The rules do not explain how RJ14 differs from RJ11 or RJ15, matching the record's own inference flag." } ] }, "rail_name": "GCC AFAQ Payment Rejections", "governing_authority": "SAMA (rules for Saudi direct participants); GCC central banks via GPC (system)", "snapshot": "2026-09-18", "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "gcc-afaq-reject:RJ15", "id": "RJ15", "rail": "gcc-afaq-reject", "kind": "reason-code", "name": "Exchange rate missing", "group": "administrative", "summary": "The exchange rate is absent. SAMA's label does not say whether the rate is missing from the payment message or from AFAQ's rate table [Inference: both readings fit]. A sender must state the rate in every message, and AFAQ checks it against the confirmed rate for the day. This record reports SAMA's rules for Saudi direct participants.", "triggers": [ "The sender left the exchange rate field empty [Inference]", "No rate existed for the pair in the checking component [Inference]" ], "actions": [ "Sending participant: check that the message carries the day's confirmed rate and both currency amounts", "If the message was complete, ask SAMA whether the pair's rate is loaded", "Resend as a new payment with a new unique message reference" ], "retry": { "allowed": true, "rule": "The refused payment stays refused. Once the cause is fixed, the sending participant may send it again as a new payment with a new unique message reference; it must not reuse the original reference, but it may keep the same UETR (OR 42068309 section 7.3)." }, "facts": { "return_windows": [ { "action": "refuse the payment and send the rejection back towards the sender", "by": "AFAQ Central Component or a Regional Payment Gateway; SAMA's list does not say which component raises which RJ code", "deadline": "At validation, before the payment is booked [Inference: the rules describe rejection as a payment the Central Component cannot process]; no time limit is published." }, { "action": "turn the rejection into a return payment to the sending participant, stating this code as the reason", "by": "Sending Regional Payment Gateway", "deadline": "No public deadline. SAMA's rules require every payment to be confirmed, returned or rejected before end-of-day processing starts (OR 42068309 section 7.5), so the same business day [Inference]." } ], "applies_to": "AFAQ cross-currency payments sent by a Saudi direct participant under SAMA's rules (circular 42068309, Appendix 2): a payment that a Regional Payment Gateway or the AFAQ Central Component refuses, reported back to the sending participant as a return payment that carries this code. Participants in other GCC countries follow their own central bank's code list, which was not read." }, "caveat": "This code reaches the sender as a return payment, but it is a rejection by AFAQ itself, not a return by the receiving bank. SAMA publishes only a short label for each RJ code, with no definition, so the triggers here are a reading of the operating rules.", "related": [ "gcc-afaq-reject:RJ14", "gcc-afaq-reject:RJ11", "gcc-afaq-reject:RJ01" ], "basis": { "sources": "SAMA rulebook portal, English pages read 2026-09-18: Operating Rules for Cross Currency Payments using AFAQ Service, circular 42068309 (2021-05-05), Appendix 2 (Return and Rejection Codes, also read as its own page) for the code and its label. How the service handles it rests on sections 6 and 7.2. The portal says its pages carry no legal effect, so the class is public_primary. SAMA gives each RJ code a short label only; triggers and actions marked [Inference] are Orca's reading. The GPC Operating Rules and Regulations were not used. Nothing is quoted.", "confidence": "low" }, "currency": { "effective_since": "2021-05-05", "effective_note": "In SAMA's Appendix 2 since circular 42068309 (2021-05-05, 1442-09-24 H), In-Force with no later version shown on 2026-09-18. The appendix says the Central Component's code dictionary may be updated from time to time, so the live list may differ from the published one.", "source_edition": "OR 42068309 Appendix 2 (2021-05-05)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://rulebook.sama.gov.sa/en/operating-rules-cross-currency-payments-using-afaq-service", "source_class": "public_primary", "source_title": "Operating Rules for Cross Currency Payments using AFAQ Service (SAMA circular 42068309, including Appendix 2)", "checked_on": "2026-09-19", "checked_by": "gcc-afaq validator session", "notes": "Confirms SAMA's label for RJ15, FX rate is absent, and section 6's requirement that every message state the confirmed exchange rate. The rules do not say whether the rate is absent from the message or the rate table, matching the record's own inference flag." } ] }, "rail_name": "GCC AFAQ Payment Rejections", "governing_authority": "SAMA (rules for Saudi direct participants); GCC central banks via GPC (system)", "snapshot": "2026-09-18", "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "gcc-afaq-reject:RJ16", "id": "RJ16", "rail": "gcc-afaq-reject", "kind": "reason-code", "name": "Payments not allowed", "group": "administrative", "summary": "Payments of this kind are not allowed at that point. SAMA's rules let SAMA restrict which transaction categories are allowed at times of the business day, and part of the day takes interbank payments only; a payment outside what is allowed is refused [Inference: SAMA gives only the label]. This record reports SAMA's rules for Saudi direct participants.", "triggers": [ "A customer payment sent while only interbank payments are accepted [Inference]", "A category of payment SAMA has restricted, after telling participants [Inference]", "A participant whose permission to send has been limited [Inference]" ], "actions": [ "Sending participant: check SAMA's current notices on allowed categories and the day's phase", "Resend as a new payment when the category is allowed again", "Tell the customer of the delay" ], "retry": { "allowed": true, "rule": "The refused payment stays refused. Once the cause is fixed, the sending participant may send it again as a new payment with a new unique message reference; it must not reuse the original reference, but it may keep the same UETR (OR 42068309 section 7.3)." }, "facts": { "return_windows": [ { "action": "refuse the payment and send the rejection back towards the sender", "by": "AFAQ Central Component or a Regional Payment Gateway; SAMA's list does not say which component raises which RJ code", "deadline": "At validation, before the payment is booked [Inference: the rules describe rejection as a payment the Central Component cannot process]; no time limit is published." }, { "action": "turn the rejection into a return payment to the sending participant, stating this code as the reason", "by": "Sending Regional Payment Gateway", "deadline": "No public deadline. SAMA's rules require every payment to be confirmed, returned or rejected before end-of-day processing starts (OR 42068309 section 7.5), so the same business day [Inference]." } ], "applies_to": "AFAQ cross-currency payments sent by a Saudi direct participant under SAMA's rules (circular 42068309, Appendix 2): a payment that a Regional Payment Gateway or the AFAQ Central Component refuses, reported back to the sending participant as a return payment that carries this code. Participants in other GCC countries follow their own central bank's code list, which was not read." }, "caveat": "This code reaches the sender as a return payment, but it is a rejection by AFAQ itself, not a return by the receiving bank. SAMA publishes only a short label for each RJ code, with no definition, so the triggers here are a reading of the operating rules.", "related": [ "gcc-afaq-reject:RJ07", "gcc-afaq-reject:RJ09", "gcc-afaq:limits" ], "basis": { "sources": "SAMA rulebook portal, English pages read 2026-09-18: Operating Rules for Cross Currency Payments using AFAQ Service, circular 42068309 (2021-05-05), Appendix 2 (Return and Rejection Codes, also read as its own page) for the code and its label. How the service handles it rests on sections 3.2, 5.1 items 6 and 7, and 5.5. The portal says its pages carry no legal effect, so the class is public_primary. SAMA gives each RJ code a short label only; triggers and actions marked [Inference] are Orca's reading. The GPC Operating Rules and Regulations were not used. Nothing is quoted.", "confidence": "low" }, "currency": { "effective_since": "2021-05-05", "effective_note": "In SAMA's Appendix 2 since circular 42068309 (2021-05-05, 1442-09-24 H), In-Force with no later version shown on 2026-09-18. The appendix says the Central Component's code dictionary may be updated from time to time, so the live list may differ from the published one.", "source_edition": "OR 42068309 Appendix 2 (2021-05-05)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://rulebook.sama.gov.sa/en/operating-rules-cross-currency-payments-using-afaq-service", "source_class": "public_primary", "source_title": "Operating Rules for Cross Currency Payments using AFAQ Service (SAMA circular 42068309, including Appendix 2)", "checked_on": "2026-09-19", "checked_by": "gcc-afaq validator session", "notes": "Confirms SAMA's label for RJ16, Payments are not allowed, and section 5.5's rule that SAMA may limit the categories of transactions allowed during times of the Business Cycle, plus the interbank-only period in section 5.1 item 7." } ] }, "rail_name": "GCC AFAQ Payment Rejections", "governing_authority": "SAMA (rules for Saudi direct participants); GCC central banks via GPC (system)", "snapshot": "2026-09-18", "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "gcc-afaq-reject:RJ17", "id": "RJ17", "rail": "gcc-afaq-reject", "kind": "reason-code", "name": "No active business day", "group": "administrative", "summary": "No AFAQ business day was open when the payment arrived. The system runs one business day at a time, from start of day to system stop, and it is closed on weekends, holidays and during any closure SAMA orders; a payment reaching it with no active day is refused [Inference: SAMA gives only the label]. This record reports SAMA's rules for Saudi direct participants.", "triggers": [ "A payment sent before the day's start or after system stop [Inference]", "A payment sent on a day AFAQ is closed [Inference]", "A payment sent during a closure for maintenance or an emergency [Inference]" ], "actions": [ "Sending participant: resend as a new payment once the next business day is open", "Check GPC's working hours page for the day's status", "Tell the customer when the transfer will go" ], "retry": { "allowed": true, "rule": "The refused payment stays refused. Once the cause is fixed, the sending participant may send it again as a new payment with a new unique message reference; it must not reuse the original reference, but it may keep the same UETR (OR 42068309 section 7.3)." }, "facts": { "return_windows": [ { "action": "refuse the payment and send the rejection back towards the sender", "by": "AFAQ Central Component or a Regional Payment Gateway; SAMA's list does not say which component raises which RJ code", "deadline": "At validation, before the payment is booked [Inference: the rules describe rejection as a payment the Central Component cannot process]; no time limit is published." }, { "action": "turn the rejection into a return payment to the sending participant, stating this code as the reason", "by": "Sending Regional Payment Gateway", "deadline": "No public deadline. SAMA's rules require every payment to be confirmed, returned or rejected before end-of-day processing starts (OR 42068309 section 7.5), so the same business day [Inference]." } ], "applies_to": "AFAQ cross-currency payments sent by a Saudi direct participant under SAMA's rules (circular 42068309, Appendix 2): a payment that a Regional Payment Gateway or the AFAQ Central Component refuses, reported back to the sending participant as a return payment that carries this code. Participants in other GCC countries follow their own central bank's code list, which was not read." }, "caveat": "This code reaches the sender as a return payment, but it is a rejection by AFAQ itself, not a return by the receiving bank. SAMA publishes only a short label for each RJ code, with no definition, so the triggers here are a reading of the operating rules.", "related": [ "gcc-afaq-reject:RJ05", "gcc-afaq-reject:RJ06", "gcc-afaq-reject:RJ07", "gcc-afaq:hours" ], "basis": { "sources": "SAMA rulebook portal, English pages read 2026-09-18: Operating Rules for Cross Currency Payments using AFAQ Service, circular 42068309 (2021-05-05), Appendix 2 (Return and Rejection Codes, also read as its own page) for the code and its label. How the service handles it rests on sections 5.1, 5.2, 5.6 and 8.3, with GPC's Working Hours page (read 2026-09-18). The portal says its pages carry no legal effect, so the class is public_primary. SAMA gives each RJ code a short label only; triggers and actions marked [Inference] are Orca's reading. The GPC Operating Rules and Regulations were not used. Nothing is quoted.", "confidence": "medium" }, "currency": { "effective_since": "2021-05-05", "effective_note": "In SAMA's Appendix 2 since circular 42068309 (2021-05-05, 1442-09-24 H), In-Force with no later version shown on 2026-09-18. The appendix says the Central Component's code dictionary may be updated from time to time, so the live list may differ from the published one.", "source_edition": "OR 42068309 Appendix 2 (2021-05-05)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://rulebook.sama.gov.sa/en/operating-rules-cross-currency-payments-using-afaq-service", "source_class": "public_primary", "source_title": "Operating Rules for Cross Currency Payments using AFAQ Service (SAMA circular 42068309, including Appendix 2)", "checked_on": "2026-09-19", "checked_by": "gcc-afaq validator session", "notes": "Confirms SAMA's label for RJ17, No active business day found, and sections 5.1, 5.2 and 5.6's rules on system start and stop, SAMA's declaration of business days, and SAMA's power to close the service." } ] }, "rail_name": "GCC AFAQ Payment Rejections", "governing_authority": "SAMA (rules for Saudi direct participants); GCC central banks via GPC (system)", "snapshot": "2026-09-18", "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "gcc-afaq-reject:RJ18", "id": "RJ18", "rail": "gcc-afaq-reject", "kind": "reason-code", "name": "Invalid account", "group": "account", "summary": "An account in the payment is not valid for AFAQ. SAMA's label does not say which account. Because the Central Component keeps Saudi participants' AFAQ settlement accounts, the most likely reading is a problem with a participant's settlement account rather than the beneficiary's; a receiving bank that cannot find the beneficiary's account uses a return reason code instead [Inference]. This record reports SAMA's rules for Saudi direct participants.", "triggers": [ "The sending participant's AFAQ settlement account is missing, closed or not usable [Inference]", "An account field in the message is malformed so the system cannot match it [Inference]" ], "actions": [ "Sending participant: check its AFAQ account at SAMA and the account fields in the message", "Contact SAMA if its own settlement account is the problem", "Resend as a new payment once corrected" ], "retry": { "allowed": true, "rule": "The refused payment stays refused. Once the cause is fixed, the sending participant may send it again as a new payment with a new unique message reference; it must not reuse the original reference, but it may keep the same UETR (OR 42068309 section 7.3)." }, "facts": { "return_windows": [ { "action": "refuse the payment and send the rejection back towards the sender", "by": "AFAQ Central Component or a Regional Payment Gateway; SAMA's list does not say which component raises which RJ code", "deadline": "At validation, before the payment is booked [Inference: the rules describe rejection as a payment the Central Component cannot process]; no time limit is published." }, { "action": "turn the rejection into a return payment to the sending participant, stating this code as the reason", "by": "Sending Regional Payment Gateway", "deadline": "No public deadline. SAMA's rules require every payment to be confirmed, returned or rejected before end-of-day processing starts (OR 42068309 section 7.5), so the same business day [Inference]." } ], "applies_to": "AFAQ cross-currency payments sent by a Saudi direct participant under SAMA's rules (circular 42068309, Appendix 2): a payment that a Regional Payment Gateway or the AFAQ Central Component refuses, reported back to the sending participant as a return payment that carries this code. Participants in other GCC countries follow their own central bank's code list, which was not read." }, "caveat": "This code reaches the sender as a return payment, but it is a rejection by AFAQ itself, not a return by the receiving bank. SAMA publishes only a short label for each RJ code, with no definition, so the triggers here are a reading of the operating rules.", "related": [ "gcc-afaq-reject:RJ19", "gcc-afaq:settlement" ], "basis": { "sources": "SAMA rulebook portal, English pages read 2026-09-18: Operating Rules for Cross Currency Payments using AFAQ Service, circular 42068309 (2021-05-05), Appendix 2 (Return and Rejection Codes, also read as its own page) for the code and its label. How the service handles it rests on sections 4.1.5, 4.2, 4.19 and 7.3. The portal says its pages carry no legal effect, so the class is public_primary. SAMA gives each RJ code a short label only; triggers and actions marked [Inference] are Orca's reading. The GPC Operating Rules and Regulations were not used. Nothing is quoted.", "confidence": "low" }, "currency": { "effective_since": "2021-05-05", "effective_note": "In SAMA's Appendix 2 since circular 42068309 (2021-05-05, 1442-09-24 H), In-Force with no later version shown on 2026-09-18. The appendix says the Central Component's code dictionary may be updated from time to time, so the live list may differ from the published one.", "source_edition": "OR 42068309 Appendix 2 (2021-05-05)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://rulebook.sama.gov.sa/en/operating-rules-cross-currency-payments-using-afaq-service", "source_class": "public_primary", "source_title": "Operating Rules for Cross Currency Payments using AFAQ Service (SAMA circular 42068309, including Appendix 2)", "checked_on": "2026-09-19", "checked_by": "gcc-afaq validator session", "notes": "Confirms SAMA's label for RJ18, Invalid account, and section 4.19's rule that each direct participant must maintain a current AFAQ account at SAMA. The rules do not say which account the code refers to, matching the record's own inference flag and low confidence." } ] }, "rail_name": "GCC AFAQ Payment Rejections", "governing_authority": "SAMA (rules for Saudi direct participants); GCC central banks via GPC (system)", "snapshot": "2026-09-18", "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "gcc-afaq-reject:RJ19", "id": "RJ19", "rail": "gcc-afaq-reject", "kind": "reason-code", "name": "Insufficient funds", "group": "funds", "summary": "The sending participant did not have enough money in its AFAQ account to cover the payment. Saudi participants prefund a dedicated AFAQ account at SAMA each day from their SARIE RTGS account, and every payment they send must fit within the available balance. This record reports SAMA's rules for Saudi direct participants.", "triggers": [ "The morning prefunding was too small for the day's outgoing payments [Inference]", "A large payment exceeded the remaining balance [Inference]", "Prefunding had not arrived when the payment was sent [Inference]" ], "actions": [ "Sending participant: top up its AFAQ account with an interbank payment to SAMA through the SARIE RTGS, quoting the routing code AFAQSD100", "Resend as a new payment once the balance covers it", "Review liquidity planning; SAMA does not watch participants' liquidity (OR 42068309 section 4.7)" ], "retry": { "allowed": true, "rule": "The refused payment stays refused. Once the cause is fixed, the sending participant may send it again as a new payment with a new unique message reference; it must not reuse the original reference, but it may keep the same UETR (OR 42068309 section 7.3). After funding the AFAQ account." }, "facts": { "return_windows": [ { "action": "refuse the payment and send the rejection back towards the sender", "by": "AFAQ Central Component or a Regional Payment Gateway; SAMA's list does not say which component raises which RJ code", "deadline": "At validation, before the payment is booked [Inference: the rules describe rejection as a payment the Central Component cannot process]; no time limit is published." }, { "action": "turn the rejection into a return payment to the sending participant, stating this code as the reason", "by": "Sending Regional Payment Gateway", "deadline": "No public deadline. SAMA's rules require every payment to be confirmed, returned or rejected before end-of-day processing starts (OR 42068309 section 7.5), so the same business day [Inference]." } ], "applies_to": "AFAQ cross-currency payments sent by a Saudi direct participant under SAMA's rules (circular 42068309, Appendix 2): a payment that a Regional Payment Gateway or the AFAQ Central Component refuses, reported back to the sending participant as a return payment that carries this code. Participants in other GCC countries follow their own central bank's code list, which was not read." }, "caveat": "This code reaches the sender as a return payment, but it is a rejection by AFAQ itself, not a return by the receiving bank. SAMA publishes only a short label for each RJ code, with no definition, so the triggers here are a reading of the operating rules.", "related": [ "gcc-afaq-reject:RJ18", "gcc-afaq:settlement", "gcc-afaq:limits" ], "basis": { "sources": "SAMA rulebook portal, English pages read 2026-09-18: Operating Rules for Cross Currency Payments using AFAQ Service, circular 42068309 (2021-05-05), Appendix 2 (Return and Rejection Codes, also read as its own page) for the code and its label. How the service handles it rests on sections 4.1.1, 4.7, 4.8, 4.19 and 5.1 item 5. The portal says its pages carry no legal effect, so the class is public_primary. SAMA gives each RJ code a short label only; triggers and actions marked [Inference] are Orca's reading. The GPC Operating Rules and Regulations were not used. Nothing is quoted.", "confidence": "medium" }, "currency": { "effective_since": "2021-05-05", "effective_note": "In SAMA's Appendix 2 since circular 42068309 (2021-05-05, 1442-09-24 H), In-Force with no later version shown on 2026-09-18. The appendix says the Central Component's code dictionary may be updated from time to time, so the live list may differ from the published one.", "source_edition": "OR 42068309 Appendix 2 (2021-05-05)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://rulebook.sama.gov.sa/en/operating-rules-cross-currency-payments-using-afaq-service", "source_class": "public_primary", "source_title": "Operating Rules for Cross Currency Payments using AFAQ Service (SAMA circular 42068309, including Appendix 2)", "checked_on": "2026-09-19", "checked_by": "gcc-afaq validator session", "notes": "Confirms SAMA's label for RJ19, Lack of funds, and section 5.1 item 5's rule that a direct participant must prefund its AFAQ account through SARIE RTGS to cover all its payment messages as they fall due." } ] }, "rail_name": "GCC AFAQ Payment Rejections", "governing_authority": "SAMA (rules for Saudi direct participants); GCC central banks via GPC (system)", "snapshot": "2026-09-18", "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "gcc-afaq-reject:RJ20", "id": "RJ20", "rail": "gcc-afaq-reject", "kind": "reason-code", "name": "Return refused: original payment not found", "group": "administrative", "summary": "A return was refused because the Central Component could not find the original payment it refers to. Each return must quote the original payment's reference, and the Central Component looks that payment up before accepting the return. This record reports SAMA's rules for Saudi direct participants.", "triggers": [ "The reference in field 72 of the return does not match the original payment [Inference]", "The payment being returned did not come through AFAQ [Inference]", "The return was built from the wrong incoming payment [Inference]" ], "actions": [ "Returning participant: check the original payment's reference and quote it exactly in the return", "Resend the return within the two-business-day window", "If the original did not come through AFAQ, send the money back through the channel it came by [Inference]" ], "retry": { "allowed": true, "rule": "Allowed while the window is open: a corrected return may be sent within two business days, counting only days both countries work, of the original's arrival (OR 42068309 section 7.9)." }, "facts": { "return_windows": [ { "action": "refuse the return payment and report this code to the participant that sent the return", "by": "AFAQ Central Component, when it checks the return against the original payment", "deadline": "At validation of the return, in the exchange period in which it was sent [Inference]. The return itself must be made within two business days, counting only days both countries work, of the original payment's arrival (OR 42068309 section 7.9)." } ], "applies_to": "Return payments sent by a Saudi receiving direct participant under SAMA's rules (circular 42068309, section 7.9 and Appendix 2): a return that the AFAQ Central Component refuses when it checks it against the original payment; the code goes back to the participant that tried to return. Participants in other GCC countries follow their own central bank's rules, which were not read." }, "caveat": "This code refuses a return, not a payment: the original payment stands, and the money stays with the participant that tried to send it back until a valid return goes through. SAMA publishes only a short label for each RJ code.", "related": [ "gcc-afaq-reject:RJ21", "gcc-afaq-reject:RJ22", "gcc-afaq-reject:RJ23", "gcc-afaq:return" ], "basis": { "sources": "SAMA rulebook portal, English pages read 2026-09-18: Operating Rules for Cross Currency Payments using AFAQ Service, circular 42068309 (2021-05-05), Appendix 2 (Return and Rejection Codes, also read as its own page) for the code and its label. How the service handles it rests on sections 7.8 and 7.9. The portal says its pages carry no legal effect, so the class is public_primary. SAMA gives each RJ code a short label only; triggers and actions marked [Inference] are Orca's reading. The GPC Operating Rules and Regulations were not used. Nothing is quoted.", "confidence": "medium" }, "currency": { "effective_since": "2021-05-05", "effective_note": "In SAMA's Appendix 2 since circular 42068309 (2021-05-05, 1442-09-24 H), In-Force with no later version shown on 2026-09-18. The appendix says the Central Component's code dictionary may be updated from time to time, so the live list may differ from the published one.", "source_edition": "OR 42068309 Appendix 2 (2021-05-05)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://rulebook.sama.gov.sa/en/operating-rules-cross-currency-payments-using-afaq-service", "source_class": "public_primary", "source_title": "Operating Rules for Cross Currency Payments using AFAQ Service (SAMA circular 42068309, including Appendix 2)", "checked_on": "2026-09-19", "checked_by": "gcc-afaq validator session", "notes": "Confirms SAMA's label for RJ20, No direct credit found, and section 7.9's rule that the Central Component checks the original direct credit reference and rejects the return if it is not found." } ] }, "rail_name": "GCC AFAQ Payment Rejections", "governing_authority": "SAMA (rules for Saudi direct participants); GCC central banks via GPC (system)", "snapshot": "2026-09-18", "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "gcc-afaq-reject:RJ21", "id": "RJ21", "rail": "gcc-afaq-reject", "kind": "reason-code", "name": "Return refused: return period expired", "group": "administrative", "summary": "A return was refused because it came after the return period. SAMA's rules allow at most two business days from the original payment's arrival, counting only days both countries work, and the Central Component refuses any return later than that. This record reports SAMA's rules for Saudi direct participants.", "triggers": [ "The receiving participant took more than two joint business days to return a payment it could not credit", "The days were counted on the receiving country's calendar alone, ignoring the sending country's holidays [Inference]" ], "actions": [ "Returning participant: the funds cannot go back as an AFAQ return; arrange their return with the sending bank some other way, for example a new payment [Inference]", "Review return handling so that uncreditable payments go back the same day where possible, as SAMA's rules prefer", "Expect SAMA's late-return fee of SAR 100 to be relevant where a return is late (SAMA Charging Policy circular 43038107 section 4.2) [Unverified: how the fee applies to a return the system refused]" ], "retry": { "allowed": false, "rule": "Not as a return: the window has closed and the Central Component will refuse it again. Any repayment has to go another way [Inference]." }, "facts": { "return_windows": [ { "action": "refuse the return payment and report this code to the participant that sent the return", "by": "AFAQ Central Component, when it checks the return against the original payment", "deadline": "At validation of the return, in the exchange period in which it was sent [Inference]. The return itself must be made within two business days, counting only days both countries work, of the original payment's arrival (OR 42068309 section 7.9)." } ], "applies_to": "Return payments sent by a Saudi receiving direct participant under SAMA's rules (circular 42068309, section 7.9 and Appendix 2): a return that the AFAQ Central Component refuses when it checks it against the original payment; the code goes back to the participant that tried to return. Participants in other GCC countries follow their own central bank's rules, which were not read." }, "caveat": "This code refuses a return, not a payment: the original payment stands, and the money stays with the participant that tried to send it back until a valid return goes through. SAMA publishes only a short label for each RJ code.", "related": [ "gcc-afaq-reject:RJ20", "gcc-afaq-reject:RJ22", "gcc-afaq-reject:RJ23", "gcc-afaq:return", "gcc-afaq:liability" ], "basis": { "sources": "SAMA rulebook portal, English pages read 2026-09-18: Operating Rules for Cross Currency Payments using AFAQ Service, circular 42068309 (2021-05-05), Appendix 2 (Return and Rejection Codes, also read as its own page) for the code and its label. How the service handles it rests on sections 7.8 and 7.9, with SAMA's Charging Policy circular 43038107 (2021-12-02) section 4.2. The portal says its pages carry no legal effect, so the class is public_primary. SAMA gives each RJ code a short label only; triggers and actions marked [Inference] are Orca's reading. The GPC Operating Rules and Regulations were not used. Nothing is quoted.", "confidence": "medium" }, "currency": { "effective_since": "2021-05-05", "effective_note": "In SAMA's Appendix 2 since circular 42068309 (2021-05-05, 1442-09-24 H), In-Force with no later version shown on 2026-09-18. The appendix says the Central Component's code dictionary may be updated from time to time, so the live list may differ from the published one.", "source_edition": "OR 42068309 Appendix 2 (2021-05-05)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://rulebook.sama.gov.sa/en/operating-rules-cross-currency-payments-using-afaq-service", "source_class": "public_primary", "source_title": "Operating Rules for Cross Currency Payments using AFAQ Service (SAMA circular 42068309, including Appendix 2)", "checked_on": "2026-09-19", "checked_by": "gcc-afaq validator session", "notes": "Confirms SAMA's label for RJ21, Return period expired, and section 7.9's rule that a return is rejected if it comes more than two business days after the original payment, counted only on days both countries work." } ] }, "rail_name": "GCC AFAQ Payment Rejections", "governing_authority": "SAMA (rules for Saudi direct participants); GCC central banks via GPC (system)", "snapshot": "2026-09-18", "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "gcc-afaq-reject:RJ22", "id": "RJ22", "rail": "gcc-afaq-reject", "kind": "reason-code", "name": "Return refused: wrong return amount", "group": "administrative", "summary": "A return was refused because its amount does not match the original payment. A return must carry the same currency codes, the same two amounts and the same exchange rate as the payment received, with nothing deducted; the Central Component checks all of these. This record reports SAMA's rules for Saudi direct participants.", "triggers": [ "The returning bank deducted a fee from the returned amount [Inference]", "The return was converted at the day's new rate instead of the original rate [Inference]", "The sending and receiving amounts were swapped, given that the receiving side sees the rate inverted and the amounts in the opposite order [Inference]" ], "actions": [ "Returning participant: rebuild the return with the original rate, both original amounts and currency codes, and no deduction", "Resend the return within the two-business-day window" ], "retry": { "allowed": true, "rule": "Allowed while the window is open: a corrected return may be sent within two business days, counting only days both countries work, of the original's arrival (OR 42068309 section 7.9)." }, "facts": { "return_windows": [ { "action": "refuse the return payment and report this code to the participant that sent the return", "by": "AFAQ Central Component, when it checks the return against the original payment", "deadline": "At validation of the return, in the exchange period in which it was sent [Inference]. The return itself must be made within two business days, counting only days both countries work, of the original payment's arrival (OR 42068309 section 7.9)." } ], "applies_to": "Return payments sent by a Saudi receiving direct participant under SAMA's rules (circular 42068309, section 7.9 and Appendix 2): a return that the AFAQ Central Component refuses when it checks it against the original payment; the code goes back to the participant that tried to return. Participants in other GCC countries follow their own central bank's rules, which were not read." }, "caveat": "This code refuses a return, not a payment: the original payment stands, and the money stays with the participant that tried to send it back until a valid return goes through. SAMA publishes only a short label for each RJ code.", "related": [ "gcc-afaq-reject:RJ20", "gcc-afaq-reject:RJ21", "gcc-afaq-reject:RJ23", "gcc-afaq:return" ], "basis": { "sources": "SAMA rulebook portal, English pages read 2026-09-18: Operating Rules for Cross Currency Payments using AFAQ Service, circular 42068309 (2021-05-05), Appendix 2 (Return and Rejection Codes, also read as its own page) for the code and its label. How the service handles it rests on sections 7.3, 7.8 and 7.9, with GPC's AFAQ FAQs page (read 2026-09-18) on the return rate. The portal says its pages carry no legal effect, so the class is public_primary. SAMA gives each RJ code a short label only; triggers and actions marked [Inference] are Orca's reading. The GPC Operating Rules and Regulations were not used. Nothing is quoted.", "confidence": "medium" }, "currency": { "effective_since": "2021-05-05", "effective_note": "In SAMA's Appendix 2 since circular 42068309 (2021-05-05, 1442-09-24 H), In-Force with no later version shown on 2026-09-18. The appendix says the Central Component's code dictionary may be updated from time to time, so the live list may differ from the published one.", "source_edition": "OR 42068309 Appendix 2 (2021-05-05)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://rulebook.sama.gov.sa/en/operating-rules-cross-currency-payments-using-afaq-service", "source_class": "public_primary", "source_title": "Operating Rules for Cross Currency Payments using AFAQ Service (SAMA circular 42068309, including Appendix 2)", "checked_on": "2026-09-19", "checked_by": "gcc-afaq validator session", "notes": "Confirms SAMA's label for RJ22, Incorrect return amount, and section 7.9's rule that a return is rejected if its currency amounts, currency code or exchange rate do not match the original payment." } ] }, "rail_name": "GCC AFAQ Payment Rejections", "governing_authority": "SAMA (rules for Saudi direct participants); GCC central banks via GPC (system)", "snapshot": "2026-09-18", "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "gcc-afaq-reject:RJ23", "id": "RJ23", "rail": "gcc-afaq-reject", "kind": "reason-code", "name": "Return refused: duplicate return", "group": "administrative", "summary": "A return was refused as a duplicate: a return for the same original payment had already been accepted. Each payment can be returned successfully only once. This record reports SAMA's rules for Saudi direct participants.", "triggers": [ "The returning bank sent the same return twice, for example after a timeout on its side [Inference]", "Two teams at the returning bank each returned the same payment [Inference]" ], "actions": [ "Returning participant: check that the first return succeeded and cancel any internal duplicate", "Do not resend; the money has already gone back" ], "retry": { "allowed": false, "rule": "Not allowed: only one successful return is permitted for each payment (OR 42068309 section 7.9)." }, "facts": { "return_windows": [ { "action": "refuse the return payment and report this code to the participant that sent the return", "by": "AFAQ Central Component, when it checks the return against the original payment", "deadline": "At validation of the return, in the exchange period in which it was sent [Inference]. The return itself must be made within two business days, counting only days both countries work, of the original payment's arrival (OR 42068309 section 7.9)." } ], "applies_to": "Return payments sent by a Saudi receiving direct participant under SAMA's rules (circular 42068309, section 7.9 and Appendix 2): a return that the AFAQ Central Component refuses when it checks it against the original payment; the code goes back to the participant that tried to return. Participants in other GCC countries follow their own central bank's rules, which were not read." }, "caveat": "This code refuses a return, not a payment: the original payment stands, and the money stays with the participant that tried to send it back until a valid return goes through. SAMA publishes only a short label for each RJ code.", "related": [ "gcc-afaq-reject:RJ20", "gcc-afaq-reject:RJ21", "gcc-afaq-reject:RJ22", "gcc-afaq:return" ], "basis": { "sources": "SAMA rulebook portal, English pages read 2026-09-18: Operating Rules for Cross Currency Payments using AFAQ Service, circular 42068309 (2021-05-05), Appendix 2 (Return and Rejection Codes, also read as its own page) for the code and its label. How the service handles it rests on section 7.9. The portal says its pages carry no legal effect, so the class is public_primary. SAMA gives each RJ code a short label only; triggers and actions marked [Inference] are Orca's reading. The GPC Operating Rules and Regulations were not used. Nothing is quoted.", "confidence": "medium" }, "currency": { "effective_since": "2021-05-05", "effective_note": "In SAMA's Appendix 2 since circular 42068309 (2021-05-05, 1442-09-24 H), In-Force with no later version shown on 2026-09-18. The appendix says the Central Component's code dictionary may be updated from time to time, so the live list may differ from the published one.", "source_edition": "OR 42068309 Appendix 2 (2021-05-05)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://rulebook.sama.gov.sa/en/operating-rules-cross-currency-payments-using-afaq-service", "source_class": "public_primary", "source_title": "Operating Rules for Cross Currency Payments using AFAQ Service (SAMA circular 42068309, including Appendix 2)", "checked_on": "2026-09-19", "checked_by": "gcc-afaq validator session", "notes": "Confirms SAMA's label for RJ23, Return payment duplication, and section 7.9's rule that only one successful return is allowed for each received payment message, and that a return is rejected if a successful return has already been accepted." } ] }, "rail_name": "GCC AFAQ Payment Rejections", "governing_authority": "SAMA (rules for Saudi direct participants); GCC central banks via GPC (system)", "snapshot": "2026-09-18", "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "gcc-afaq-reject:RJ24", "id": "RJ24", "rail": "gcc-afaq-reject", "kind": "reason-code", "name": "Payment cancelled", "group": "administrative", "summary": "The payment was cancelled. SAMA's rules forbid cancelling or recalling a payment once the sender has been debited, so this code can only mean a cancellation before that point, for example of a payment still waiting to be processed [Speculation: SAMA gives only the label and no public text describes a cancellation step]. This record reports SAMA's rules for Saudi direct participants.", "triggers": [ "A queued payment was cancelled before it was booked [Speculation]", "An operator cancelled a payment during an incident or at end of day [Speculation]" ], "actions": [ "Sending participant: confirm with SAMA why the payment was cancelled before telling the customer", "Resend as a new payment if the payment is still wanted" ], "retry": { "allowed": true, "rule": "The refused payment stays refused. Once the cause is fixed, the sending participant may send it again as a new payment with a new unique message reference; it must not reuse the original reference, but it may keep the same UETR (OR 42068309 section 7.3)." }, "facts": { "return_windows": [ { "action": "refuse the payment and send the rejection back towards the sender", "by": "AFAQ Central Component or a Regional Payment Gateway; SAMA's list does not say which component raises which RJ code", "deadline": "At validation, before the payment is booked [Inference: the rules describe rejection as a payment the Central Component cannot process]; no time limit is published." }, { "action": "turn the rejection into a return payment to the sending participant, stating this code as the reason", "by": "Sending Regional Payment Gateway", "deadline": "No public deadline. SAMA's rules require every payment to be confirmed, returned or rejected before end-of-day processing starts (OR 42068309 section 7.5), so the same business day [Inference]." } ], "applies_to": "AFAQ cross-currency payments sent by a Saudi direct participant under SAMA's rules (circular 42068309, Appendix 2): a payment that a Regional Payment Gateway or the AFAQ Central Component refuses, reported back to the sending participant as a return payment that carries this code. Participants in other GCC countries follow their own central bank's code list, which was not read." }, "caveat": "This code reaches the sender as a return payment, but it is a rejection by AFAQ itself, not a return by the receiving bank. SAMA publishes only a short label for each RJ code, with no definition, so the triggers here are a reading of the operating rules.", "related": [ "gcc-afaq-reject:RJ25", "gcc-afaq:recall" ], "basis": { "sources": "SAMA rulebook portal, English pages read 2026-09-18: Operating Rules for Cross Currency Payments using AFAQ Service, circular 42068309 (2021-05-05), Appendix 2 (Return and Rejection Codes, also read as its own page) for the code and its label. How the service handles it rests on sections 7.3 and 7.14. The portal says its pages carry no legal effect, so the class is public_primary. SAMA gives each RJ code a short label only; triggers and actions marked [Inference] are Orca's reading. The GPC Operating Rules and Regulations were not used. Nothing is quoted.", "confidence": "low" }, "currency": { "effective_since": "2021-05-05", "effective_note": "In SAMA's Appendix 2 since circular 42068309 (2021-05-05, 1442-09-24 H), In-Force with no later version shown on 2026-09-18. The appendix says the Central Component's code dictionary may be updated from time to time, so the live list may differ from the published one.", "source_edition": "OR 42068309 Appendix 2 (2021-05-05)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://rulebook.sama.gov.sa/en/operating-rules-cross-currency-payments-using-afaq-service", "source_class": "public_primary", "source_title": "Operating Rules for Cross Currency Payments using AFAQ Service (SAMA circular 42068309, including Appendix 2)", "checked_on": "2026-09-19", "checked_by": "gcc-afaq validator session", "notes": "Confirms SAMA's label for RJ24, Payment was cancelled. Section 7.14 confirms no cancellation is possible once the sender is debited, consistent with the record's speculation that this code covers a step before debit; no public text describes that step, matching the record's own speculation flag and low confidence." } ] }, "rail_name": "GCC AFAQ Payment Rejections", "governing_authority": "SAMA (rules for Saudi direct participants); GCC central banks via GPC (system)", "snapshot": "2026-09-18", "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "gcc-afaq-reject:RJ25", "id": "RJ25", "rail": "gcc-afaq-reject", "kind": "reason-code", "name": "Payment rejected", "group": "administrative", "summary": "The payment was rejected, with no more specific reason given. SAMA's label adds nothing beyond the fact of rejection [Inference: it may be used where the underlying reason has no RJ code of its own]. This record reports SAMA's rules for Saudi direct participants.", "triggers": [ "A rejection whose cause has no specific RJ code [Inference]", "A rejection passed on from another component without its detailed reason [Speculation]" ], "actions": [ "Sending participant: ask SAMA for the underlying cause before resending", "Resend as a new payment once the cause is known and fixed" ], "retry": { "allowed": true, "rule": "The refused payment stays refused. Once the cause is fixed, the sending participant may send it again as a new payment with a new unique message reference; it must not reuse the original reference, but it may keep the same UETR (OR 42068309 section 7.3)." }, "facts": { "return_windows": [ { "action": "refuse the payment and send the rejection back towards the sender", "by": "AFAQ Central Component or a Regional Payment Gateway; SAMA's list does not say which component raises which RJ code", "deadline": "At validation, before the payment is booked [Inference: the rules describe rejection as a payment the Central Component cannot process]; no time limit is published." }, { "action": "turn the rejection into a return payment to the sending participant, stating this code as the reason", "by": "Sending Regional Payment Gateway", "deadline": "No public deadline. SAMA's rules require every payment to be confirmed, returned or rejected before end-of-day processing starts (OR 42068309 section 7.5), so the same business day [Inference]." } ], "applies_to": "AFAQ cross-currency payments sent by a Saudi direct participant under SAMA's rules (circular 42068309, Appendix 2): a payment that a Regional Payment Gateway or the AFAQ Central Component refuses, reported back to the sending participant as a return payment that carries this code. Participants in other GCC countries follow their own central bank's code list, which was not read." }, "caveat": "This code reaches the sender as a return payment, but it is a rejection by AFAQ itself, not a return by the receiving bank. SAMA publishes only a short label for each RJ code, with no definition, so the triggers here are a reading of the operating rules.", "related": [ "gcc-afaq-reject:RJ00", "gcc-afaq-reject:RJ24" ], "basis": { "sources": "SAMA rulebook portal, English pages read 2026-09-18: Operating Rules for Cross Currency Payments using AFAQ Service, circular 42068309 (2021-05-05), Appendix 2 (Return and Rejection Codes, also read as its own page) for the code and its label. How the service handles it rests on sections 4.1.2, 4.1.5 and 7.3. The portal says its pages carry no legal effect, so the class is public_primary. SAMA gives each RJ code a short label only; triggers and actions marked [Inference] are Orca's reading. The GPC Operating Rules and Regulations were not used. Nothing is quoted.", "confidence": "low" }, "currency": { "effective_since": "2021-05-05", "effective_note": "In SAMA's Appendix 2 since circular 42068309 (2021-05-05, 1442-09-24 H), In-Force with no later version shown on 2026-09-18. The appendix says the Central Component's code dictionary may be updated from time to time, so the live list may differ from the published one.", "source_edition": "OR 42068309 Appendix 2 (2021-05-05)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://rulebook.sama.gov.sa/en/operating-rules-cross-currency-payments-using-afaq-service", "source_class": "public_primary", "source_title": "Operating Rules for Cross Currency Payments using AFAQ Service (SAMA circular 42068309, including Appendix 2)", "checked_on": "2026-09-19", "checked_by": "gcc-afaq validator session", "notes": "Confirms SAMA's label for RJ25, Payment was rejected, and section 7.3's return path to the sender. SAMA's label adds nothing beyond the fact of rejection, matching the record's own inference flag and low confidence." } ] }, "rail_name": "GCC AFAQ Payment Rejections", "governing_authority": "SAMA (rules for Saudi direct participants); GCC central banks via GPC (system)", "snapshot": "2026-09-18", "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "gcc-afaq-reject:RJ90", "id": "RJ90", "rail": "gcc-afaq-reject", "kind": "reason-code", "name": "Access rights check failed", "group": "authorization", "summary": "An access rights check failed, so the payment was not accepted. The gateways handle access control, participants must be certified by SAMA before use, and GPC runs the public key infrastructure that secures the network; a sender without the right access, or whose credentials fail, is refused [Inference: SAMA gives only the label]. This record reports SAMA's rules for Saudi direct participants.", "triggers": [ "A user or system at the participant lacks the rights to send that message [Inference]", "A certificate or key used to sign or encrypt the message is expired or not recognised [Inference]", "A participant not yet certified for the function attempted it [Inference]" ], "actions": [ "Sending participant: check its user rights and certificates with its security team and SAMA", "Report any suspected security incident to SAMA, as the rules require", "Resend as a new payment once access is restored" ], "retry": { "allowed": true, "rule": "The refused payment stays refused. Once the cause is fixed, the sending participant may send it again as a new payment with a new unique message reference; it must not reuse the original reference, but it may keep the same UETR (OR 42068309 section 7.3). Only after the access problem is fixed." }, "facts": { "return_windows": [ { "action": "refuse the payment and send the rejection back towards the sender", "by": "AFAQ Central Component or a Regional Payment Gateway; SAMA's list does not say which component raises which RJ code", "deadline": "At validation, before the payment is booked [Inference: the rules describe rejection as a payment the Central Component cannot process]; no time limit is published." }, { "action": "turn the rejection into a return payment to the sending participant, stating this code as the reason", "by": "Sending Regional Payment Gateway", "deadline": "No public deadline. SAMA's rules require every payment to be confirmed, returned or rejected before end-of-day processing starts (OR 42068309 section 7.5), so the same business day [Inference]." } ], "applies_to": "AFAQ cross-currency payments sent by a Saudi direct participant under SAMA's rules (circular 42068309, Appendix 2): a payment that a Regional Payment Gateway or the AFAQ Central Component refuses, reported back to the sending participant as a return payment that carries this code. Participants in other GCC countries follow their own central bank's code list, which was not read." }, "caveat": "This code reaches the sender as a return payment, but it is a rejection by AFAQ itself, not a return by the receiving bank. SAMA publishes only a short label for each RJ code, with no definition, so the triggers here are a reading of the operating rules.", "related": [ "gcc-afaq-reject:RJ00", "gcc-afaq:participants" ], "basis": { "sources": "SAMA rulebook portal, English pages read 2026-09-18: Operating Rules for Cross Currency Payments using AFAQ Service, circular 42068309 (2021-05-05), Appendix 2 (Return and Rejection Codes, also read as its own page) for the code and its label. How the service handles it rests on sections 4.1.2, 4.5 and 4.17, with GPC's Our Services page (read 2026-09-18) on the public key infrastructure. The portal says its pages carry no legal effect, so the class is public_primary. SAMA gives each RJ code a short label only; triggers and actions marked [Inference] are Orca's reading. The GPC Operating Rules and Regulations were not used. Nothing is quoted.", "confidence": "low" }, "currency": { "effective_since": "2021-05-05", "effective_note": "In SAMA's Appendix 2 since circular 42068309 (2021-05-05, 1442-09-24 H), In-Force with no later version shown on 2026-09-18. The appendix says the Central Component's code dictionary may be updated from time to time, so the live list may differ from the published one.", "source_edition": "OR 42068309 Appendix 2 (2021-05-05)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://rulebook.sama.gov.sa/en/operating-rules-cross-currency-payments-using-afaq-service", "source_class": "public_primary", "source_title": "Operating Rules for Cross Currency Payments using AFAQ Service (SAMA circular 42068309, including Appendix 2)", "checked_on": "2026-09-19", "checked_by": "gcc-afaq validator session", "notes": "Confirms SAMA's label for RJ90, Access rights check failed, and section 4.1.2's rule that RPG functions include systems management and access control, and section 4.5's rule that no direct participant may use the service until it and its systems are certified by SAMA." } ] }, "rail_name": "GCC AFAQ Payment Rejections", "governing_authority": "SAMA (rules for Saudi direct participants); GCC central banks via GPC (system)", "snapshot": "2026-09-18", "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "gcc-afaq-return:AC01", "id": "AC01", "rail": "gcc-afaq-return", "kind": "reason-code", "name": "Beneficiary account number badly formed", "group": "account", "summary": "The receiving participant sends the payment back because the beneficiary account number in it is not a valid number in form, so nothing can be posted to it.", "triggers": [ "The account number in the beneficiary field fails the receiving participant's format or check digit test [Inference]", "A customer payment to a country that uses IBAN quotes something that is not a valid IBAN; SAMA's rules make a missing or invalid IBAN a possible ground to reject or return (OR 7.12) [Inference: SAMA does not say which code goes with it]" ], "actions": [ "Sending participant: tell the payer why the money came back and get beneficiary details that work before sending anything new", "Sending participant: for a country that uses IBAN, put the beneficiary's IBAN in the account field in that country's format (OR 7.12)", "Receiving participant: send back the original amounts at the original exchange rate, in both currencies and with nothing taken off, as one message whose field 72 carries the original payment's reference (OR 7.8, 7.9)", "Receiving participant: expect the Central Component to refuse the return if it differs from the original in amount, currency or rate, repeats a return already accepted, comes too late, or points at an original it cannot find (OR 7.9)" ], "retry": { "allowed": true, "rule": "Yes, as a new payment. A returned payment may not be sent again under its original Unique Message Reference; once the cause is fixed the sending participant may send it as a new payment with a new Unique Message Reference, and may keep the same UETR (OR 7.3). That sentence sits in the paragraph on rejections and is read here as covering returns too [Inference]." }, "facts": { "return_windows": [ { "action": "return the payment with this reason", "by": "Receiving direct participant (a Saudi participant under SAMA's rules)", "deadline": "Best on the business day the payment arrived; if not, by that payment type's cut-off on the next business day; never later than 2 business days after receipt, counting only days that are business days in both the sending and the receiving country (OR 7.8, 7.9, 5.3). Inside that time no compensation for use of the funds is owed (OR 7.8). The Central Component refuses a return after 2 business days (OR 7.9), and SAMA charges SAR 100 per payment message returned late, possibly plus an amount-based charge (CP 4.2, CP Appendix 2)." } ], "applies_to": "AFAQ cross-currency service, under SAMA's rules for Saudi direct participants: a return payment sent by the receiving direct participant for a payment it received through AFAQ and could not credit (OR 7.8), in the exchange period that accepts returns (OR 5.1 item 6)." }, "caveat": "AFAQ also lists IBAN, its own code for an invalid beneficiary account number, and ULBA and BADE for an account that cannot be found; SAMA says nothing about which to prefer. SAMA's explanation is ISO's own definition of this code (ISO 20022 ExternalReturnReason1Code, 2Q2026). This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "related": [ "gcc-afaq-return:IBAN", "gcc-afaq-return:AC03", "gcc-afaq-return:BADE", "gcc-afaq-return:ULBA", "sepa-sct:AC01" ], "basis": { "sources": "SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service (2021-05-05, 24/9/1442 H, In-Force), read in full on rulebook.sama.gov.sa on 2026-09-18: Appendix 2, table of returned payments, entry for AC01; sections 5.1 item 6, 5.3, 7.3, 7.8, 7.9, 7.12. SAMA circular 43038107, Charging Policy for Cross Currency Payments Using AFAQ Service (2021-12-02), section 4.2 and Appendix 2. ISO 20022 External Code Sets 2Q2026 (2Q2026_externalcodesets_v3.json, downloaded 2026-09-18), compared by script. SAMA gives one line per code and no usage guidance, so triggers and actions beyond that line are inference.", "confidence": "medium" }, "currency": { "effective_since": "2021-05-05", "effective_note": "Date of SAMA circular 42068309 (24/9/1442 H), In-Force when read on 2026-09-18. The portal's Versions block shows date ranges that end before they begin, so no later edition can be read from it. The appendix says returned codes are registered in the AFAQ Central Component dictionary, which may be updated from time to time, so the live list may differ from the published one [Inference].", "source_edition": "SAMA circular 42068309 (2021-05-05), Appendix 2", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://rulebook.sama.gov.sa/en/appendix-2-return-and-rejection-codes", "source_class": "public_primary", "source_title": "Appendix 2 - Return and Rejection Codes (SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-18", "notes": "Appendix 2 of SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service, lists AC01 with the meaning this record states. SAMA's Operating Rules, sections 7.8 and 7.9, confirm the return limits the record gives: an outer limit of 2 business days, counted only on days that both countries work, with an earlier expected deadline; no compensation for holding the funds inside that limit; and refusal by the Central Component of a return that is late, a duplicate, or inconsistent with the original payment. Section 5.1 item 6 confirms the exchange period accepts returns. SAMA's Charging Policy for Cross Currency Payments Using AFAQ Service, circular 43038107, section 4.2, confirms the SAR 100 penalty for a late return. Section 7.12 confirms the IBAN requirement for customer payments to countries using IBAN, the ground for this return." } ] }, "rail_name": "AFAQ Returns (SAMA rules for Saudi participants)", "governing_authority": "Saudi Central Bank (SAMA), for its direct participants; AFAQ is owned by the six GCC central banks and run by the Gulf Payments Company", "snapshot": "2026-09-18", "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "judgement", "label": "your bank's own terms", "needs": "whose terms decide it: the bank's, the participant's or the scheme's", "detail": "This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "from": "caveat" } ] }, { "uid": "gcc-afaq-return:AC03", "id": "AC03", "rail": "gcc-afaq-return", "kind": "reason-code", "name": "Wrong IBAN for the beneficiary", "group": "account", "summary": "Sent back because the IBAN on the payment is wrong. SAMA copied ISO's wording, which speaks of a SEPA credit transfer; on AFAQ it means an AFAQ payment whose IBAN is not the beneficiary's.", "triggers": [ "The IBAN is well formed but belongs to someone other than the beneficiary named on the payment [Inference]", "The receiving participant may credit only when the account number is the right one for the beneficiary named in field 59 (OR 7.6) and must give value to the right beneficiary (OR 7.7), so a mismatch ends in a return [Inference]" ], "actions": [ "Sending participant: tell the payer why the money came back and get beneficiary details that work before sending anything new", "Sending participant: confirm the IBAN with the payer, ideally from the beneficiary's own bank documents [Inference], before a new payment", "Receiving participant: send back the original amounts at the original exchange rate, in both currencies and with nothing taken off, as one message whose field 72 carries the original payment's reference (OR 7.8, 7.9)", "Receiving participant: expect the Central Component to refuse the return if it differs from the original in amount, currency or rate, repeats a return already accepted, comes too late, or points at an original it cannot find (OR 7.9)" ], "retry": { "allowed": true, "rule": "Yes, as a new payment. A returned payment may not be sent again under its original Unique Message Reference; once the cause is fixed the sending participant may send it as a new payment with a new Unique Message Reference, and may keep the same UETR (OR 7.3). That sentence sits in the paragraph on rejections and is read here as covering returns too [Inference]." }, "facts": { "return_windows": [ { "action": "return the payment with this reason", "by": "Receiving direct participant (a Saudi participant under SAMA's rules)", "deadline": "Best on the business day the payment arrived; if not, by that payment type's cut-off on the next business day; never later than 2 business days after receipt, counting only days that are business days in both the sending and the receiving country (OR 7.8, 7.9, 5.3). Inside that time no compensation for use of the funds is owed (OR 7.8). The Central Component refuses a return after 2 business days (OR 7.9), and SAMA charges SAR 100 per payment message returned late, possibly plus an amount-based charge (CP 4.2, CP Appendix 2)." } ], "applies_to": "AFAQ cross-currency service, under SAMA's rules for Saudi direct participants: a return payment sent by the receiving direct participant for a payment it received through AFAQ and could not credit (OR 7.8), in the exchange period that accepts returns (OR 5.1 item 6)." }, "caveat": "BDIN (name and account do not match) and BE01 cover much the same ground; no rule picks one. The ISO wording SAMA copied names a SEPA term; that is a leftover of ISO's shared code set, not an AFAQ rule. SAMA's explanation is ISO's own definition of this code (ISO 20022 ExternalReturnReason1Code, 2Q2026). This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "related": [ "gcc-afaq-return:AC01", "gcc-afaq-return:IBAN", "gcc-afaq-return:BDIN", "gcc-afaq-return:BE01" ], "basis": { "sources": "SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service (2021-05-05, 24/9/1442 H, In-Force), read in full on rulebook.sama.gov.sa on 2026-09-18: Appendix 2, table of returned payments, entry for AC03; sections 5.1 item 6, 5.3, 7.3, 7.8, 7.9, 7.6, 7.7, 7.12. SAMA circular 43038107, Charging Policy for Cross Currency Payments Using AFAQ Service (2021-12-02), section 4.2 and Appendix 2. ISO 20022 External Code Sets 2Q2026 (2Q2026_externalcodesets_v3.json, downloaded 2026-09-18), compared by script. SAMA gives one line per code and no usage guidance, so triggers and actions beyond that line are inference.", "confidence": "medium" }, "currency": { "effective_since": "2021-05-05", "effective_note": "Date of SAMA circular 42068309 (24/9/1442 H), In-Force when read on 2026-09-18. The portal's Versions block shows date ranges that end before they begin, so no later edition can be read from it. The appendix says returned codes are registered in the AFAQ Central Component dictionary, which may be updated from time to time, so the live list may differ from the published one [Inference].", "source_edition": "SAMA circular 42068309 (2021-05-05), Appendix 2", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://rulebook.sama.gov.sa/en/appendix-2-return-and-rejection-codes", "source_class": "public_primary", "source_title": "Appendix 2 - Return and Rejection Codes (SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-18", "notes": "Appendix 2 of SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service, lists AC03 with the meaning this record states. SAMA's Operating Rules, sections 7.8 and 7.9, confirm the return limits the record gives: an outer limit of 2 business days, counted only on days that both countries work, with an earlier expected deadline; no compensation for holding the funds inside that limit; and refusal by the Central Component of a return that is late, a duplicate, or inconsistent with the original payment. Section 5.1 item 6 confirms the exchange period accepts returns. SAMA's Charging Policy for Cross Currency Payments Using AFAQ Service, circular 43038107, section 4.2, confirms the SAR 100 penalty for a late return. Sections 7.6 and 7.7 confirm the rule that credit is due only to the right beneficiary, and section 7.12 the IBAN requirement, supporting this reason." } ] }, "rail_name": "AFAQ Returns (SAMA rules for Saudi participants)", "governing_authority": "Saudi Central Bank (SAMA), for its direct participants; AFAQ is owned by the six GCC central banks and run by the Gulf Payments Company", "snapshot": "2026-09-18", "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "judgement", "label": "your bank's own terms", "needs": "whose terms decide it: the bank's, the participant's or the scheme's", "detail": "This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "from": "caveat" } ] }, { "uid": "gcc-afaq-return:AC04", "id": "AC04", "rail": "gcc-afaq-return", "kind": "reason-code", "name": "Account closed", "group": "account", "summary": "The beneficiary's account at the receiving participant has been closed, so the payment comes back.", "triggers": [ "The beneficiary closed the account, or the bank closed it, before the payment arrived [Inference]" ], "actions": [ "Sending participant: tell the payer why the money came back and get beneficiary details that work before sending anything new", "Receiving participant: send back the original amounts at the original exchange rate, in both currencies and with nothing taken off, as one message whose field 72 carries the original payment's reference (OR 7.8, 7.9)", "Receiving participant: expect the Central Component to refuse the return if it differs from the original in amount, currency or rate, repeats a return already accepted, comes too late, or points at an original it cannot find (OR 7.9)" ], "retry": { "allowed": true, "rule": "Yes, as a new payment. A returned payment may not be sent again under its original Unique Message Reference; once the cause is fixed the sending participant may send it as a new payment with a new Unique Message Reference, and may keep the same UETR (OR 7.3). That sentence sits in the paragraph on rejections and is read here as covering returns too [Inference]." }, "facts": { "return_windows": [ { "action": "return the payment with this reason", "by": "Receiving direct participant (a Saudi participant under SAMA's rules)", "deadline": "Best on the business day the payment arrived; if not, by that payment type's cut-off on the next business day; never later than 2 business days after receipt, counting only days that are business days in both the sending and the receiving country (OR 7.8, 7.9, 5.3). Inside that time no compensation for use of the funds is owed (OR 7.8). The Central Component refuses a return after 2 business days (OR 7.9), and SAMA charges SAR 100 per payment message returned late, possibly plus an amount-based charge (CP 4.2, CP Appendix 2)." } ], "applies_to": "AFAQ cross-currency service, under SAMA's rules for Saudi direct participants: a return payment sent by the receiving direct participant for a payment it received through AFAQ and could not credit (OR 7.8), in the exchange period that accepts returns (OR 5.1 item 6)." }, "caveat": "BACL is AFAQ's own code for a closed beneficiary account; SAMA gives no rule on which of the two to use. SAMA's explanation is ISO's own definition of this code (ISO 20022 ExternalReturnReason1Code, 2Q2026). This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "related": [ "gcc-afaq-return:BACL", "gcc-afaq-return:AC06", "gcc-afaq-return:ADRM", "sepa-sct:AC04" ], "basis": { "sources": "SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service (2021-05-05, 24/9/1442 H, In-Force), read in full on rulebook.sama.gov.sa on 2026-09-18: Appendix 2, table of returned payments, entry for AC04; sections 5.1 item 6, 5.3, 7.3, 7.8, 7.9. SAMA circular 43038107, Charging Policy for Cross Currency Payments Using AFAQ Service (2021-12-02), section 4.2 and Appendix 2. ISO 20022 External Code Sets 2Q2026 (2Q2026_externalcodesets_v3.json, downloaded 2026-09-18), compared by script. SAMA gives one line per code and no usage guidance, so triggers and actions beyond that line are inference.", "confidence": "medium" }, "currency": { "effective_since": "2021-05-05", "effective_note": "Date of SAMA circular 42068309 (24/9/1442 H), In-Force when read on 2026-09-18. The portal's Versions block shows date ranges that end before they begin, so no later edition can be read from it. The appendix says returned codes are registered in the AFAQ Central Component dictionary, which may be updated from time to time, so the live list may differ from the published one [Inference].", "source_edition": "SAMA circular 42068309 (2021-05-05), Appendix 2", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://rulebook.sama.gov.sa/en/appendix-2-return-and-rejection-codes", "source_class": "public_primary", "source_title": "Appendix 2 - Return and Rejection Codes (SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-18", "notes": "Appendix 2 of SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service, lists AC04 with the meaning this record states. SAMA's Operating Rules, sections 7.8 and 7.9, confirm the return limits the record gives: an outer limit of 2 business days, counted only on days that both countries work, with an earlier expected deadline; no compensation for holding the funds inside that limit; and refusal by the Central Component of a return that is late, a duplicate, or inconsistent with the original payment. Section 5.1 item 6 confirms the exchange period accepts returns. SAMA's Charging Policy for Cross Currency Payments Using AFAQ Service, circular 43038107, section 4.2, confirms the SAR 100 penalty for a late return." } ] }, "rail_name": "AFAQ Returns (SAMA rules for Saudi participants)", "governing_authority": "Saudi Central Bank (SAMA), for its direct participants; AFAQ is owned by the six GCC central banks and run by the Gulf Payments Company", "snapshot": "2026-09-18", "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "judgement", "label": "your bank's own terms", "needs": "whose terms decide it: the bank's, the participant's or the scheme's", "detail": "This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "from": "caveat" } ] }, { "uid": "gcc-afaq-return:AC06", "id": "AC06", "rail": "gcc-afaq-return", "kind": "reason-code", "name": "Account blocked", "group": "account", "summary": "The beneficiary's account is frozen, so the receiving participant cannot credit it and returns the payment.", "triggers": [ "The account is frozen by the bank, a court or an authority [Inference]" ], "actions": [ "Sending participant: tell the payer why the money came back and get beneficiary details that work before sending anything new", "Beneficiary: settle the block with its own bank, or give another account [Inference]", "Receiving participant: send back the original amounts at the original exchange rate, in both currencies and with nothing taken off, as one message whose field 72 carries the original payment's reference (OR 7.8, 7.9)", "Receiving participant: expect the Central Component to refuse the return if it differs from the original in amount, currency or rate, repeats a return already accepted, comes too late, or points at an original it cannot find (OR 7.9)" ], "retry": { "allowed": true, "rule": "Yes, as a new payment. A returned payment may not be sent again under its original Unique Message Reference; once the cause is fixed the sending participant may send it as a new payment with a new Unique Message Reference, and may keep the same UETR (OR 7.3). That sentence sits in the paragraph on rejections and is read here as covering returns too [Inference]. A new payment makes sense only to another account or once the block is lifted [Inference]." }, "facts": { "return_windows": [ { "action": "return the payment with this reason", "by": "Receiving direct participant (a Saudi participant under SAMA's rules)", "deadline": "Best on the business day the payment arrived; if not, by that payment type's cut-off on the next business day; never later than 2 business days after receipt, counting only days that are business days in both the sending and the receiving country (OR 7.8, 7.9, 5.3). Inside that time no compensation for use of the funds is owed (OR 7.8). The Central Component refuses a return after 2 business days (OR 7.9), and SAMA charges SAR 100 per payment message returned late, possibly plus an amount-based charge (CP 4.2, CP Appendix 2)." } ], "applies_to": "AFAQ cross-currency service, under SAMA's rules for Saudi direct participants: a return payment sent by the receiving direct participant for a payment it received through AFAQ and could not credit (OR 7.8), in the exchange period that accepts returns (OR 5.1 item 6)." }, "caveat": "BALC is AFAQ's own code for a blocked beneficiary account; no rule chooses between them. SAMA's explanation is ISO's own definition of this code (ISO 20022 ExternalReturnReason1Code, 2Q2026). This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "related": [ "gcc-afaq-return:BALC", "gcc-afaq-return:AC04", "gcc-afaq-return:AC16", "gcc-afaq-return:NOCM", "sepa-sct:AC06" ], "basis": { "sources": "SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service (2021-05-05, 24/9/1442 H, In-Force), read in full on rulebook.sama.gov.sa on 2026-09-18: Appendix 2, table of returned payments, entry for AC06; sections 5.1 item 6, 5.3, 7.3, 7.8, 7.9. SAMA circular 43038107, Charging Policy for Cross Currency Payments Using AFAQ Service (2021-12-02), section 4.2 and Appendix 2. ISO 20022 External Code Sets 2Q2026 (2Q2026_externalcodesets_v3.json, downloaded 2026-09-18), compared by script. SAMA gives one line per code and no usage guidance, so triggers and actions beyond that line are inference.", "confidence": "medium" }, "currency": { "effective_since": "2021-05-05", "effective_note": "Date of SAMA circular 42068309 (24/9/1442 H), In-Force when read on 2026-09-18. The portal's Versions block shows date ranges that end before they begin, so no later edition can be read from it. The appendix says returned codes are registered in the AFAQ Central Component dictionary, which may be updated from time to time, so the live list may differ from the published one [Inference].", "source_edition": "SAMA circular 42068309 (2021-05-05), Appendix 2", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://rulebook.sama.gov.sa/en/appendix-2-return-and-rejection-codes", "source_class": "public_primary", "source_title": "Appendix 2 - Return and Rejection Codes (SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-18", "notes": "Appendix 2 of SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service, lists AC06 with the meaning this record states. SAMA's Operating Rules, sections 7.8 and 7.9, confirm the return limits the record gives: an outer limit of 2 business days, counted only on days that both countries work, with an earlier expected deadline; no compensation for holding the funds inside that limit; and refusal by the Central Component of a return that is late, a duplicate, or inconsistent with the original payment. Section 5.1 item 6 confirms the exchange period accepts returns. SAMA's Charging Policy for Cross Currency Payments Using AFAQ Service, circular 43038107, section 4.2, confirms the SAR 100 penalty for a late return." } ] }, "rail_name": "AFAQ Returns (SAMA rules for Saudi participants)", "governing_authority": "Saudi Central Bank (SAMA), for its direct participants; AFAQ is owned by the six GCC central banks and run by the Gulf Payments Company", "snapshot": "2026-09-18", "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "judgement", "label": "your bank's own terms", "needs": "whose terms decide it: the bank's, the participant's or the scheme's", "detail": "This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "from": "caveat" } ] }, { "uid": "gcc-afaq-return:AC13", "id": "AC13", "rail": "gcc-afaq-return", "kind": "reason-code", "name": "Payer account type missing or invalid", "group": "account", "summary": "An ISO code about the payer's (debtor's) account type. In a return from the receiving participant it would say that account type information it needed about the payer was absent or wrong [Inference].", "triggers": [ "The payment lacks, or carries an unusable, account type for the payer where the receiving side needs one [Inference]" ], "actions": [ "Sending participant: check what payer account data the receiving country expects; AFAQ's message format guides are controlled documents shared with participants (OR Appendix 1)", "Receiving participant: send back the original amounts at the original exchange rate, in both currencies and with nothing taken off, as one message whose field 72 carries the original payment's reference (OR 7.8, 7.9)", "Receiving participant: expect the Central Component to refuse the return if it differs from the original in amount, currency or rate, repeats a return already accepted, comes too late, or points at an original it cannot find (OR 7.9)" ], "retry": { "allowed": true, "rule": "Yes, as a new payment. A returned payment may not be sent again under its original Unique Message Reference; once the cause is fixed the sending participant may send it as a new payment with a new Unique Message Reference, and may keep the same UETR (OR 7.3). That sentence sits in the paragraph on rejections and is read here as covering returns too [Inference]." }, "facts": { "return_windows": [ { "action": "return the payment with this reason", "by": "Receiving direct participant (a Saudi participant under SAMA's rules)", "deadline": "Best on the business day the payment arrived; if not, by that payment type's cut-off on the next business day; never later than 2 business days after receipt, counting only days that are business days in both the sending and the receiving country (OR 7.8, 7.9, 5.3). Inside that time no compensation for use of the funds is owed (OR 7.8). The Central Component refuses a return after 2 business days (OR 7.9), and SAMA charges SAR 100 per payment message returned late, possibly plus an amount-based charge (CP 4.2, CP Appendix 2)." } ], "applies_to": "AFAQ cross-currency service, under SAMA's rules for Saudi direct participants: a return payment sent by the receiving direct participant for a payment it received through AFAQ and could not credit (OR 7.8), in the exchange period that accepts returns (OR 5.1 item 6)." }, "caveat": "SAMA says nothing about when this code applies on AFAQ, and no public AFAQ text requires a payer account type [Inference]. SAMA's explanation is ISO's own definition of this code (ISO 20022 ExternalReturnReason1Code, 2Q2026). This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "related": [ "gcc-afaq-return:RR01", "gcc-afaq-return:BE07" ], "basis": { "sources": "SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service (2021-05-05, 24/9/1442 H, In-Force), read in full on rulebook.sama.gov.sa on 2026-09-18: Appendix 2, table of returned payments, entry for AC13; sections 5.1 item 6, 5.3, 7.3, 7.8, 7.9, Appendix 1. SAMA circular 43038107, Charging Policy for Cross Currency Payments Using AFAQ Service (2021-12-02), section 4.2 and Appendix 2. ISO 20022 External Code Sets 2Q2026 (2Q2026_externalcodesets_v3.json, downloaded 2026-09-18), compared by script. SAMA gives one line per code and no usage guidance, so triggers and actions beyond that line are inference.", "confidence": "low" }, "currency": { "effective_since": "2021-05-05", "effective_note": "Date of SAMA circular 42068309 (24/9/1442 H), In-Force when read on 2026-09-18. The portal's Versions block shows date ranges that end before they begin, so no later edition can be read from it. The appendix says returned codes are registered in the AFAQ Central Component dictionary, which may be updated from time to time, so the live list may differ from the published one [Inference].", "source_edition": "SAMA circular 42068309 (2021-05-05), Appendix 2", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://rulebook.sama.gov.sa/en/appendix-2-return-and-rejection-codes", "source_class": "public_primary", "source_title": "Appendix 2 - Return and Rejection Codes (SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-18", "notes": "Appendix 2 of SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service, lists AC13 with the meaning this record states. SAMA's Operating Rules, sections 7.8 and 7.9, confirm the return limits the record gives: an outer limit of 2 business days, counted only on days that both countries work, with an earlier expected deadline; no compensation for holding the funds inside that limit; and refusal by the Central Component of a return that is late, a duplicate, or inconsistent with the original payment. Section 5.1 item 6 confirms the exchange period accepts returns. SAMA's Charging Policy for Cross Currency Payments Using AFAQ Service, circular 43038107, section 4.2, confirms the SAR 100 penalty for a late return." } ] }, "rail_name": "AFAQ Returns (SAMA rules for Saudi participants)", "governing_authority": "Saudi Central Bank (SAMA), for its direct participants; AFAQ is owned by the six GCC central banks and run by the Gulf Payments Company", "snapshot": "2026-09-18", "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "judgement", "label": "your bank's own terms", "needs": "whose terms decide it: the bank's, the participant's or the scheme's", "detail": "This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "from": "caveat" } ] }, { "uid": "gcc-afaq-return:AC14", "id": "AC14", "rail": "gcc-afaq-return", "kind": "reason-code", "name": "A bank in the chain is not usable", "group": "network", "summary": "One of the banks the payment must pass through or land at is not one the receiving participant can use, so the money goes back.", "triggers": [ "The payment is for credit to a financial institution that does not hold an account with the receiving participant; AFAQ payments may credit the receiving participant, an institution banking with it, or a customer of it (OR 7.2 f) [Inference]" ], "actions": [ "Sending participant: check the intermediary and account-holding banks named on the payment before a new one [Inference]", "Receiving participant: send back the original amounts at the original exchange rate, in both currencies and with nothing taken off, as one message whose field 72 carries the original payment's reference (OR 7.8, 7.9)", "Receiving participant: expect the Central Component to refuse the return if it differs from the original in amount, currency or rate, repeats a return already accepted, comes too late, or points at an original it cannot find (OR 7.9)" ], "retry": { "allowed": true, "rule": "Yes, as a new payment. A returned payment may not be sent again under its original Unique Message Reference; once the cause is fixed the sending participant may send it as a new payment with a new Unique Message Reference, and may keep the same UETR (OR 7.3). That sentence sits in the paragraph on rejections and is read here as covering returns too [Inference]." }, "facts": { "return_windows": [ { "action": "return the payment with this reason", "by": "Receiving direct participant (a Saudi participant under SAMA's rules)", "deadline": "Best on the business day the payment arrived; if not, by that payment type's cut-off on the next business day; never later than 2 business days after receipt, counting only days that are business days in both the sending and the receiving country (OR 7.8, 7.9, 5.3). Inside that time no compensation for use of the funds is owed (OR 7.8). The Central Component refuses a return after 2 business days (OR 7.9), and SAMA charges SAR 100 per payment message returned late, possibly plus an amount-based charge (CP 4.2, CP Appendix 2)." } ], "applies_to": "AFAQ cross-currency service, under SAMA's rules for Saudi direct participants: a return payment sent by the receiving direct participant for a payment it received through AFAQ and could not credit (OR 7.8), in the exchange period that accepts returns (OR 5.1 item 6)." }, "caveat": "SAMA's explanation is ISO's own definition of this code (ISO 20022 ExternalReturnReason1Code, 2Q2026). This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "related": [ "gcc-afaq-return:ED01", "gcc-afaq-return:IBIC", "gcc-afaq-return:RC07" ], "basis": { "sources": "SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service (2021-05-05, 24/9/1442 H, In-Force), read in full on rulebook.sama.gov.sa on 2026-09-18: Appendix 2, table of returned payments, entry for AC14; sections 5.1 item 6, 5.3, 7.3, 7.8, 7.9, 7.2. SAMA circular 43038107, Charging Policy for Cross Currency Payments Using AFAQ Service (2021-12-02), section 4.2 and Appendix 2. ISO 20022 External Code Sets 2Q2026 (2Q2026_externalcodesets_v3.json, downloaded 2026-09-18), compared by script. SAMA gives one line per code and no usage guidance, so triggers and actions beyond that line are inference.", "confidence": "medium" }, "currency": { "effective_since": "2021-05-05", "effective_note": "Date of SAMA circular 42068309 (24/9/1442 H), In-Force when read on 2026-09-18. The portal's Versions block shows date ranges that end before they begin, so no later edition can be read from it. The appendix says returned codes are registered in the AFAQ Central Component dictionary, which may be updated from time to time, so the live list may differ from the published one [Inference].", "source_edition": "SAMA circular 42068309 (2021-05-05), Appendix 2", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://rulebook.sama.gov.sa/en/appendix-2-return-and-rejection-codes", "source_class": "public_primary", "source_title": "Appendix 2 - Return and Rejection Codes (SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-18", "notes": "Appendix 2 of SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service, lists AC14 with the meaning this record states. SAMA's Operating Rules, sections 7.8 and 7.9, confirm the return limits the record gives: an outer limit of 2 business days, counted only on days that both countries work, with an earlier expected deadline; no compensation for holding the funds inside that limit; and refusal by the Central Component of a return that is late, a duplicate, or inconsistent with the original payment. Section 5.1 item 6 confirms the exchange period accepts returns. SAMA's Charging Policy for Cross Currency Payments Using AFAQ Service, circular 43038107, section 4.2, confirms the SAR 100 penalty for a late return." } ] }, "rail_name": "AFAQ Returns (SAMA rules for Saudi participants)", "governing_authority": "Saudi Central Bank (SAMA), for its direct participants; AFAQ is owned by the six GCC central banks and run by the Gulf Payments Company", "snapshot": "2026-09-18", "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "judgement", "label": "your bank's own terms", "needs": "whose terms decide it: the bank's, the participant's or the scheme's", "detail": "This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "from": "caveat" } ] }, { "uid": "gcc-afaq-return:AC15", "id": "AC15", "rail": "gcc-afaq-return", "kind": "reason-code", "name": "Account details changed", "group": "account", "summary": "The beneficiary's account details have changed since the payer got them, so the payment as addressed cannot be posted and is returned.", "triggers": [ "The account was renumbered, moved or converted, and the old details no longer lead to it [Inference]" ], "actions": [ "Sending participant: tell the payer why the money came back and get beneficiary details that work before sending anything new", "Receiving participant: send back the original amounts at the original exchange rate, in both currencies and with nothing taken off, as one message whose field 72 carries the original payment's reference (OR 7.8, 7.9)", "Receiving participant: expect the Central Component to refuse the return if it differs from the original in amount, currency or rate, repeats a return already accepted, comes too late, or points at an original it cannot find (OR 7.9)" ], "retry": { "allowed": true, "rule": "Yes, as a new payment. A returned payment may not be sent again under its original Unique Message Reference; once the cause is fixed the sending participant may send it as a new payment with a new Unique Message Reference, and may keep the same UETR (OR 7.3). That sentence sits in the paragraph on rejections and is read here as covering returns too [Inference]." }, "facts": { "return_windows": [ { "action": "return the payment with this reason", "by": "Receiving direct participant (a Saudi participant under SAMA's rules)", "deadline": "Best on the business day the payment arrived; if not, by that payment type's cut-off on the next business day; never later than 2 business days after receipt, counting only days that are business days in both the sending and the receiving country (OR 7.8, 7.9, 5.3). Inside that time no compensation for use of the funds is owed (OR 7.8). The Central Component refuses a return after 2 business days (OR 7.9), and SAMA charges SAR 100 per payment message returned late, possibly plus an amount-based charge (CP 4.2, CP Appendix 2)." } ], "applies_to": "AFAQ cross-currency service, under SAMA's rules for Saudi direct participants: a return payment sent by the receiving direct participant for a payment it received through AFAQ and could not credit (OR 7.8), in the exchange period that accepts returns (OR 5.1 item 6)." }, "caveat": "SAMA's explanation is ISO's own definition of this code (ISO 20022 ExternalReturnReason1Code, 2Q2026). This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "related": [ "gcc-afaq-return:AC01", "gcc-afaq-return:AC04", "gcc-afaq-return:ULBA" ], "basis": { "sources": "SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service (2021-05-05, 24/9/1442 H, In-Force), read in full on rulebook.sama.gov.sa on 2026-09-18: Appendix 2, table of returned payments, entry for AC15; sections 5.1 item 6, 5.3, 7.3, 7.8, 7.9. SAMA circular 43038107, Charging Policy for Cross Currency Payments Using AFAQ Service (2021-12-02), section 4.2 and Appendix 2. ISO 20022 External Code Sets 2Q2026 (2Q2026_externalcodesets_v3.json, downloaded 2026-09-18), compared by script. SAMA gives one line per code and no usage guidance, so triggers and actions beyond that line are inference.", "confidence": "medium" }, "currency": { "effective_since": "2021-05-05", "effective_note": "Date of SAMA circular 42068309 (24/9/1442 H), In-Force when read on 2026-09-18. The portal's Versions block shows date ranges that end before they begin, so no later edition can be read from it. The appendix says returned codes are registered in the AFAQ Central Component dictionary, which may be updated from time to time, so the live list may differ from the published one [Inference].", "source_edition": "SAMA circular 42068309 (2021-05-05), Appendix 2", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://rulebook.sama.gov.sa/en/appendix-2-return-and-rejection-codes", "source_class": "public_primary", "source_title": "Appendix 2 - Return and Rejection Codes (SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-18", "notes": "Appendix 2 of SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service, lists AC15 with the meaning this record states. SAMA's Operating Rules, sections 7.8 and 7.9, confirm the return limits the record gives: an outer limit of 2 business days, counted only on days that both countries work, with an earlier expected deadline; no compensation for holding the funds inside that limit; and refusal by the Central Component of a return that is late, a duplicate, or inconsistent with the original payment. Section 5.1 item 6 confirms the exchange period accepts returns. SAMA's Charging Policy for Cross Currency Payments Using AFAQ Service, circular 43038107, section 4.2, confirms the SAR 100 penalty for a late return." } ] }, "rail_name": "AFAQ Returns (SAMA rules for Saudi participants)", "governing_authority": "Saudi Central Bank (SAMA), for its direct participants; AFAQ is owned by the six GCC central banks and run by the Gulf Payments Company", "snapshot": "2026-09-18", "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "judgement", "label": "your bank's own terms", "needs": "whose terms decide it: the bank's, the participant's or the scheme's", "detail": "This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "from": "caveat" } ] }, { "uid": "gcc-afaq-return:AC16", "id": "AC16", "rail": "gcc-afaq-return", "kind": "reason-code", "name": "Account under sequestration", "group": "account", "summary": "The beneficiary's account is under sequestration, a legal seizure, and the receiving participant returns the payment rather than credit it.", "triggers": [ "A court or authority order has seized the account [Inference]" ], "actions": [ "Sending participant: tell the payer; any payment towards that beneficiary now depends on the legal process, not on AFAQ [Inference]", "Receiving participant: send back the original amounts at the original exchange rate, in both currencies and with nothing taken off, as one message whose field 72 carries the original payment's reference (OR 7.8, 7.9)", "Receiving participant: expect the Central Component to refuse the return if it differs from the original in amount, currency or rate, repeats a return already accepted, comes too late, or points at an original it cannot find (OR 7.9)" ], "retry": { "allowed": false, "rule": "Not to that account. Sending the same payment again would meet the same seizure [Inference]; a payment to another account goes as a new payment with a new Unique Message Reference (OR 7.3)." }, "facts": { "return_windows": [ { "action": "return the payment with this reason", "by": "Receiving direct participant (a Saudi participant under SAMA's rules)", "deadline": "Best on the business day the payment arrived; if not, by that payment type's cut-off on the next business day; never later than 2 business days after receipt, counting only days that are business days in both the sending and the receiving country (OR 7.8, 7.9, 5.3). Inside that time no compensation for use of the funds is owed (OR 7.8). The Central Component refuses a return after 2 business days (OR 7.9), and SAMA charges SAR 100 per payment message returned late, possibly plus an amount-based charge (CP 4.2, CP Appendix 2)." } ], "applies_to": "AFAQ cross-currency service, under SAMA's rules for Saudi direct participants: a return payment sent by the receiving direct participant for a payment it received through AFAQ and could not credit (OR 7.8), in the exchange period that accepts returns (OR 5.1 item 6)." }, "caveat": "SAMA's explanation is ISO's own definition of this code (ISO 20022 ExternalReturnReason1Code, 2Q2026). This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "related": [ "gcc-afaq-return:AC17", "gcc-afaq-return:AC06", "gcc-afaq-return:BALC" ], "basis": { "sources": "SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service (2021-05-05, 24/9/1442 H, In-Force), read in full on rulebook.sama.gov.sa on 2026-09-18: Appendix 2, table of returned payments, entry for AC16; sections 5.1 item 6, 5.3, 7.3, 7.8, 7.9. SAMA circular 43038107, Charging Policy for Cross Currency Payments Using AFAQ Service (2021-12-02), section 4.2 and Appendix 2. ISO 20022 External Code Sets 2Q2026 (2Q2026_externalcodesets_v3.json, downloaded 2026-09-18), compared by script. SAMA gives one line per code and no usage guidance, so triggers and actions beyond that line are inference.", "confidence": "medium" }, "currency": { "effective_since": "2021-05-05", "effective_note": "Date of SAMA circular 42068309 (24/9/1442 H), In-Force when read on 2026-09-18. The portal's Versions block shows date ranges that end before they begin, so no later edition can be read from it. The appendix says returned codes are registered in the AFAQ Central Component dictionary, which may be updated from time to time, so the live list may differ from the published one [Inference].", "source_edition": "SAMA circular 42068309 (2021-05-05), Appendix 2", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://rulebook.sama.gov.sa/en/appendix-2-return-and-rejection-codes", "source_class": "public_primary", "source_title": "Appendix 2 - Return and Rejection Codes (SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-18", "notes": "Appendix 2 of SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service, lists AC16 with the meaning this record states. SAMA's Operating Rules, sections 7.8 and 7.9, confirm the return limits the record gives: an outer limit of 2 business days, counted only on days that both countries work, with an earlier expected deadline; no compensation for holding the funds inside that limit; and refusal by the Central Component of a return that is late, a duplicate, or inconsistent with the original payment. Section 5.1 item 6 confirms the exchange period accepts returns. SAMA's Charging Policy for Cross Currency Payments Using AFAQ Service, circular 43038107, section 4.2, confirms the SAR 100 penalty for a late return." } ] }, "rail_name": "AFAQ Returns (SAMA rules for Saudi participants)", "governing_authority": "Saudi Central Bank (SAMA), for its direct participants; AFAQ is owned by the six GCC central banks and run by the Gulf Payments Company", "snapshot": "2026-09-18", "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "judgement", "label": "your bank's own terms", "needs": "whose terms decide it: the bank's, the participant's or the scheme's", "detail": "This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "from": "caveat" } ] }, { "uid": "gcc-afaq-return:AC17", "id": "AC17", "rail": "gcc-afaq-return", "kind": "reason-code", "name": "Account in liquidation", "group": "account", "summary": "The beneficiary's account is in liquidation, so the receiving participant does not credit it and sends the payment back.", "triggers": [ "The account holder, usually a company, is being wound up and its account no longer takes credits [Inference]" ], "actions": [ "Sending participant: tell the payer, who deals with the liquidator for any amount owed [Inference]", "Receiving participant: send back the original amounts at the original exchange rate, in both currencies and with nothing taken off, as one message whose field 72 carries the original payment's reference (OR 7.8, 7.9)", "Receiving participant: expect the Central Component to refuse the return if it differs from the original in amount, currency or rate, repeats a return already accepted, comes too late, or points at an original it cannot find (OR 7.9)" ], "retry": { "allowed": false, "rule": "Not to that account. The same payment would meet the same liquidation [Inference]; any other payment is a new one with a new Unique Message Reference (OR 7.3)." }, "facts": { "return_windows": [ { "action": "return the payment with this reason", "by": "Receiving direct participant (a Saudi participant under SAMA's rules)", "deadline": "Best on the business day the payment arrived; if not, by that payment type's cut-off on the next business day; never later than 2 business days after receipt, counting only days that are business days in both the sending and the receiving country (OR 7.8, 7.9, 5.3). Inside that time no compensation for use of the funds is owed (OR 7.8). The Central Component refuses a return after 2 business days (OR 7.9), and SAMA charges SAR 100 per payment message returned late, possibly plus an amount-based charge (CP 4.2, CP Appendix 2)." } ], "applies_to": "AFAQ cross-currency service, under SAMA's rules for Saudi direct participants: a return payment sent by the receiving direct participant for a payment it received through AFAQ and could not credit (OR 7.8), in the exchange period that accepts returns (OR 5.1 item 6)." }, "caveat": "SAMA's explanation is ISO's own definition of this code (ISO 20022 ExternalReturnReason1Code, 2Q2026). This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "related": [ "gcc-afaq-return:AC16", "gcc-afaq-return:AC04", "gcc-afaq-return:BACL" ], "basis": { "sources": "SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service (2021-05-05, 24/9/1442 H, In-Force), read in full on rulebook.sama.gov.sa on 2026-09-18: Appendix 2, table of returned payments, entry for AC17; sections 5.1 item 6, 5.3, 7.3, 7.8, 7.9. SAMA circular 43038107, Charging Policy for Cross Currency Payments Using AFAQ Service (2021-12-02), section 4.2 and Appendix 2. ISO 20022 External Code Sets 2Q2026 (2Q2026_externalcodesets_v3.json, downloaded 2026-09-18), compared by script. SAMA gives one line per code and no usage guidance, so triggers and actions beyond that line are inference.", "confidence": "medium" }, "currency": { "effective_since": "2021-05-05", "effective_note": "Date of SAMA circular 42068309 (24/9/1442 H), In-Force when read on 2026-09-18. The portal's Versions block shows date ranges that end before they begin, so no later edition can be read from it. The appendix says returned codes are registered in the AFAQ Central Component dictionary, which may be updated from time to time, so the live list may differ from the published one [Inference].", "source_edition": "SAMA circular 42068309 (2021-05-05), Appendix 2", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://rulebook.sama.gov.sa/en/appendix-2-return-and-rejection-codes", "source_class": "public_primary", "source_title": "Appendix 2 - Return and Rejection Codes (SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-18", "notes": "Appendix 2 of SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service, lists AC17 with the meaning this record states. SAMA's Operating Rules, sections 7.8 and 7.9, confirm the return limits the record gives: an outer limit of 2 business days, counted only on days that both countries work, with an earlier expected deadline; no compensation for holding the funds inside that limit; and refusal by the Central Component of a return that is late, a duplicate, or inconsistent with the original payment. Section 5.1 item 6 confirms the exchange period accepts returns. SAMA's Charging Policy for Cross Currency Payments Using AFAQ Service, circular 43038107, section 4.2, confirms the SAR 100 penalty for a late return." } ] }, "rail_name": "AFAQ Returns (SAMA rules for Saudi participants)", "governing_authority": "Saudi Central Bank (SAMA), for its direct participants; AFAQ is owned by the six GCC central banks and run by the Gulf Payments Company", "snapshot": "2026-09-18", "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "judgement", "label": "your bank's own terms", "needs": "whose terms decide it: the bank's, the participant's or the scheme's", "detail": "This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "from": "caveat" } ] }, { "uid": "gcc-afaq-return:ADRM", "id": "ADRM", "rail": "gcc-afaq-return", "kind": "reason-code", "name": "Beneficiary account dormant", "group": "account", "summary": "An AFAQ code of its own: the beneficiary's account is dormant, not in active use, and the receiving participant returns the payment instead of crediting it.", "triggers": [ "The account has had no customer activity for long enough to be classed dormant under the receiving bank's rules [Inference]" ], "actions": [ "Sending participant: tell the payer why the money came back and get beneficiary details that work before sending anything new", "Beneficiary: reactivate the account with its bank or give another one [Inference]", "Receiving participant: send back the original amounts at the original exchange rate, in both currencies and with nothing taken off, as one message whose field 72 carries the original payment's reference (OR 7.8, 7.9)", "Receiving participant: expect the Central Component to refuse the return if it differs from the original in amount, currency or rate, repeats a return already accepted, comes too late, or points at an original it cannot find (OR 7.9)" ], "retry": { "allowed": true, "rule": "Yes, as a new payment. A returned payment may not be sent again under its original Unique Message Reference; once the cause is fixed the sending participant may send it as a new payment with a new Unique Message Reference, and may keep the same UETR (OR 7.3). That sentence sits in the paragraph on rejections and is read here as covering returns too [Inference]. A new payment makes sense only once the account is active again or to another account [Inference]." }, "facts": { "return_windows": [ { "action": "return the payment with this reason", "by": "Receiving direct participant (a Saudi participant under SAMA's rules)", "deadline": "Best on the business day the payment arrived; if not, by that payment type's cut-off on the next business day; never later than 2 business days after receipt, counting only days that are business days in both the sending and the receiving country (OR 7.8, 7.9, 5.3). Inside that time no compensation for use of the funds is owed (OR 7.8). The Central Component refuses a return after 2 business days (OR 7.9), and SAMA charges SAR 100 per payment message returned late, possibly plus an amount-based charge (CP 4.2, CP Appendix 2)." } ], "applies_to": "AFAQ cross-currency service, under SAMA's rules for Saudi direct participants: a return payment sent by the receiving direct participant for a payment it received through AFAQ and could not credit (OR 7.8), in the exchange period that accepts returns (OR 5.1 item 6)." }, "caveat": "SAMA's AFAQ rules do not define dormancy; the receiving bank's own country rules decide [Inference]. The code is in no ISO 20022 external code set (2Q2026); it is AFAQ's own. This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "related": [ "gcc-afaq-return:NOCM", "gcc-afaq-return:AC06", "gcc-afaq-return:BALC" ], "basis": { "sources": "SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service (2021-05-05, 24/9/1442 H, In-Force), read in full on rulebook.sama.gov.sa on 2026-09-18: Appendix 2, table of returned payments, entry for ADRM; sections 5.1 item 6, 5.3, 7.3, 7.8, 7.9. SAMA circular 43038107, Charging Policy for Cross Currency Payments Using AFAQ Service (2021-12-02), section 4.2 and Appendix 2. ISO 20022 External Code Sets 2Q2026 (2Q2026_externalcodesets_v3.json, downloaded 2026-09-18), compared by script. SAMA gives one line per code and no usage guidance, so triggers and actions beyond that line are inference.", "confidence": "medium" }, "currency": { "effective_since": "2021-05-05", "effective_note": "Date of SAMA circular 42068309 (24/9/1442 H), In-Force when read on 2026-09-18. The portal's Versions block shows date ranges that end before they begin, so no later edition can be read from it. The appendix says returned codes are registered in the AFAQ Central Component dictionary, which may be updated from time to time, so the live list may differ from the published one [Inference].", "source_edition": "SAMA circular 42068309 (2021-05-05), Appendix 2", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://rulebook.sama.gov.sa/en/appendix-2-return-and-rejection-codes", "source_class": "public_primary", "source_title": "Appendix 2 - Return and Rejection Codes (SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-18", "notes": "Appendix 2 of SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service, lists ADRM with the meaning this record states. SAMA's Operating Rules, sections 7.8 and 7.9, confirm the return limits the record gives: an outer limit of 2 business days, counted only on days that both countries work, with an earlier expected deadline; no compensation for holding the funds inside that limit; and refusal by the Central Component of a return that is late, a duplicate, or inconsistent with the original payment. Section 5.1 item 6 confirms the exchange period accepts returns. SAMA's Charging Policy for Cross Currency Payments Using AFAQ Service, circular 43038107, section 4.2, confirms the SAR 100 penalty for a late return." } ] }, "rail_name": "AFAQ Returns (SAMA rules for Saudi participants)", "governing_authority": "Saudi Central Bank (SAMA), for its direct participants; AFAQ is owned by the six GCC central banks and run by the Gulf Payments Company", "snapshot": "2026-09-18", "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "judgement", "label": "your bank's own terms", "needs": "whose terms decide it: the bank's, the participant's or the scheme's", "detail": "This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "from": "caveat" } ] }, { "uid": "gcc-afaq-return:AG01", "id": "AG01", "rail": "gcc-afaq-return", "kind": "reason-code", "name": "Account does not take this kind of transaction", "group": "account", "summary": "The beneficiary's account is of a type on which this transaction is not allowed, so the payment is sent back. ISO notes the code once meant that no agreement was in place.", "triggers": [ "The account is a type, such as a restricted or deposit account, that cannot receive this payment [Inference]" ], "actions": [ "Sending participant: tell the payer why the money came back and get beneficiary details that work before sending anything new", "Receiving participant: send back the original amounts at the original exchange rate, in both currencies and with nothing taken off, as one message whose field 72 carries the original payment's reference (OR 7.8, 7.9)", "Receiving participant: expect the Central Component to refuse the return if it differs from the original in amount, currency or rate, repeats a return already accepted, comes too late, or points at an original it cannot find (OR 7.9)" ], "retry": { "allowed": true, "rule": "Yes, as a new payment. A returned payment may not be sent again under its original Unique Message Reference; once the cause is fixed the sending participant may send it as a new payment with a new Unique Message Reference, and may keep the same UETR (OR 7.3). That sentence sits in the paragraph on rejections and is read here as covering returns too [Inference]. The new payment should go to an account that can take it [Inference]." }, "facts": { "return_windows": [ { "action": "return the payment with this reason", "by": "Receiving direct participant (a Saudi participant under SAMA's rules)", "deadline": "Best on the business day the payment arrived; if not, by that payment type's cut-off on the next business day; never later than 2 business days after receipt, counting only days that are business days in both the sending and the receiving country (OR 7.8, 7.9, 5.3). Inside that time no compensation for use of the funds is owed (OR 7.8). The Central Component refuses a return after 2 business days (OR 7.9), and SAMA charges SAR 100 per payment message returned late, possibly plus an amount-based charge (CP 4.2, CP Appendix 2)." } ], "applies_to": "AFAQ cross-currency service, under SAMA's rules for Saudi direct participants: a return payment sent by the receiving direct participant for a payment it received through AFAQ and could not credit (OR 7.8), in the exchange period that accepts returns (OR 5.1 item 6)." }, "caveat": "SAMA's explanation matches ISO's definition of this code apart from spelling (ISO 20022 ExternalReturnReason1Code, 2Q2026). This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "related": [ "gcc-afaq-return:AG02", "gcc-afaq-return:NOCM", "sepa-sct:AG01" ], "basis": { "sources": "SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service (2021-05-05, 24/9/1442 H, In-Force), read in full on rulebook.sama.gov.sa on 2026-09-18: Appendix 2, table of returned payments, entry for AG01; sections 5.1 item 6, 5.3, 7.3, 7.8, 7.9. SAMA circular 43038107, Charging Policy for Cross Currency Payments Using AFAQ Service (2021-12-02), section 4.2 and Appendix 2. ISO 20022 External Code Sets 2Q2026 (2Q2026_externalcodesets_v3.json, downloaded 2026-09-18), compared by script. SAMA gives one line per code and no usage guidance, so triggers and actions beyond that line are inference.", "confidence": "medium" }, "currency": { "effective_since": "2021-05-05", "effective_note": "Date of SAMA circular 42068309 (24/9/1442 H), In-Force when read on 2026-09-18. The portal's Versions block shows date ranges that end before they begin, so no later edition can be read from it. The appendix says returned codes are registered in the AFAQ Central Component dictionary, which may be updated from time to time, so the live list may differ from the published one [Inference].", "source_edition": "SAMA circular 42068309 (2021-05-05), Appendix 2", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://rulebook.sama.gov.sa/en/appendix-2-return-and-rejection-codes", "source_class": "public_primary", "source_title": "Appendix 2 - Return and Rejection Codes (SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-18", "notes": "Appendix 2 of SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service, lists AG01 with the meaning this record states. SAMA's Operating Rules, sections 7.8 and 7.9, confirm the return limits the record gives: an outer limit of 2 business days, counted only on days that both countries work, with an earlier expected deadline; no compensation for holding the funds inside that limit; and refusal by the Central Component of a return that is late, a duplicate, or inconsistent with the original payment. Section 5.1 item 6 confirms the exchange period accepts returns. SAMA's Charging Policy for Cross Currency Payments Using AFAQ Service, circular 43038107, section 4.2, confirms the SAR 100 penalty for a late return." } ] }, "rail_name": "AFAQ Returns (SAMA rules for Saudi participants)", "governing_authority": "Saudi Central Bank (SAMA), for its direct participants; AFAQ is owned by the six GCC central banks and run by the Gulf Payments Company", "snapshot": "2026-09-18", "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "judgement", "label": "your bank's own terms", "needs": "whose terms decide it: the bank's, the participant's or the scheme's", "detail": "This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "from": "caveat" } ] }, { "uid": "gcc-afaq-return:AG02", "id": "AG02", "rail": "gcc-afaq-return", "kind": "reason-code", "name": "Operation code refused by the receiver", "group": "technical", "summary": "An operation code in the message is not one the receiving participant accepts, so the payment comes back.", "triggers": [ "This receiver does not accept the bank operation code the message carries [Inference: in MT form, the bank operation code field of a customer transfer]" ], "actions": [ "Sending participant: check the code against the AFAQ message format guide, a controlled document shared with participants (OR Appendix 1), and send a new payment", "Receiving participant: send back the original amounts at the original exchange rate, in both currencies and with nothing taken off, as one message whose field 72 carries the original payment's reference (OR 7.8, 7.9)", "Receiving participant: expect the Central Component to refuse the return if it differs from the original in amount, currency or rate, repeats a return already accepted, comes too late, or points at an original it cannot find (OR 7.9)" ], "retry": { "allowed": true, "rule": "Yes, as a new payment. A returned payment may not be sent again under its original Unique Message Reference; once the cause is fixed the sending participant may send it as a new payment with a new Unique Message Reference, and may keep the same UETR (OR 7.3). That sentence sits in the paragraph on rejections and is read here as covering returns too [Inference]." }, "facts": { "return_windows": [ { "action": "return the payment with this reason", "by": "Receiving direct participant (a Saudi participant under SAMA's rules)", "deadline": "Best on the business day the payment arrived; if not, by that payment type's cut-off on the next business day; never later than 2 business days after receipt, counting only days that are business days in both the sending and the receiving country (OR 7.8, 7.9, 5.3). Inside that time no compensation for use of the funds is owed (OR 7.8). The Central Component refuses a return after 2 business days (OR 7.9), and SAMA charges SAR 100 per payment message returned late, possibly plus an amount-based charge (CP 4.2, CP Appendix 2)." } ], "applies_to": "AFAQ cross-currency service, under SAMA's rules for Saudi direct participants: a return payment sent by the receiving direct participant for a payment it received through AFAQ and could not credit (OR 7.8), in the exchange period that accepts returns (OR 5.1 item 6)." }, "caveat": "SAMA's explanation is ISO's own definition of this code (ISO 20022 ExternalReturnReason1Code, 2Q2026). This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "related": [ "gcc-afaq-return:FF05", "gcc-afaq-return:AG01", "sepa-sct:AG02" ], "basis": { "sources": "SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service (2021-05-05, 24/9/1442 H, In-Force), read in full on rulebook.sama.gov.sa on 2026-09-18: Appendix 2, table of returned payments, entry for AG02; sections 5.1 item 6, 5.3, 7.3, 7.8, 7.9, Appendix 1. SAMA circular 43038107, Charging Policy for Cross Currency Payments Using AFAQ Service (2021-12-02), section 4.2 and Appendix 2. ISO 20022 External Code Sets 2Q2026 (2Q2026_externalcodesets_v3.json, downloaded 2026-09-18), compared by script. SAMA gives one line per code and no usage guidance, so triggers and actions beyond that line are inference.", "confidence": "low" }, "currency": { "effective_since": "2021-05-05", "effective_note": "Date of SAMA circular 42068309 (24/9/1442 H), In-Force when read on 2026-09-18. The portal's Versions block shows date ranges that end before they begin, so no later edition can be read from it. The appendix says returned codes are registered in the AFAQ Central Component dictionary, which may be updated from time to time, so the live list may differ from the published one [Inference].", "source_edition": "SAMA circular 42068309 (2021-05-05), Appendix 2", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://rulebook.sama.gov.sa/en/appendix-2-return-and-rejection-codes", "source_class": "public_primary", "source_title": "Appendix 2 - Return and Rejection Codes (SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-18", "notes": "Appendix 2 of SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service, lists AG02 with the meaning this record states. SAMA's Operating Rules, sections 7.8 and 7.9, confirm the return limits the record gives: an outer limit of 2 business days, counted only on days that both countries work, with an earlier expected deadline; no compensation for holding the funds inside that limit; and refusal by the Central Component of a return that is late, a duplicate, or inconsistent with the original payment. Section 5.1 item 6 confirms the exchange period accepts returns. SAMA's Charging Policy for Cross Currency Payments Using AFAQ Service, circular 43038107, section 4.2, confirms the SAR 100 penalty for a late return." } ] }, "rail_name": "AFAQ Returns (SAMA rules for Saudi participants)", "governing_authority": "Saudi Central Bank (SAMA), for its direct participants; AFAQ is owned by the six GCC central banks and run by the Gulf Payments Company", "snapshot": "2026-09-18", "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "judgement", "label": "your bank's own terms", "needs": "whose terms decide it: the bank's, the participant's or the scheme's", "detail": "This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "from": "caveat" } ] }, { "uid": "gcc-afaq-return:AM01", "id": "AM01", "rail": "gcc-afaq-return", "kind": "reason-code", "name": "Amount is zero", "group": "technical", "summary": "The payment's amount is zero, so there is nothing to credit and it is returned.", "triggers": [ "A payment with a zero amount got past validation [Inference: the RPG and Central Component check amounts and rates (OR 6), so this should be rare]" ], "actions": [ "Sending participant: correct the amount and send a new payment", "Receiving participant: send back the original amounts at the original exchange rate, in both currencies and with nothing taken off, as one message whose field 72 carries the original payment's reference (OR 7.8, 7.9)", "Receiving participant: expect the Central Component to refuse the return if it differs from the original in amount, currency or rate, repeats a return already accepted, comes too late, or points at an original it cannot find (OR 7.9)" ], "retry": { "allowed": true, "rule": "Yes, as a new payment. A returned payment may not be sent again under its original Unique Message Reference; once the cause is fixed the sending participant may send it as a new payment with a new Unique Message Reference, and may keep the same UETR (OR 7.3). That sentence sits in the paragraph on rejections and is read here as covering returns too [Inference]." }, "facts": { "return_windows": [ { "action": "return the payment with this reason", "by": "Receiving direct participant (a Saudi participant under SAMA's rules)", "deadline": "Best on the business day the payment arrived; if not, by that payment type's cut-off on the next business day; never later than 2 business days after receipt, counting only days that are business days in both the sending and the receiving country (OR 7.8, 7.9, 5.3). Inside that time no compensation for use of the funds is owed (OR 7.8). The Central Component refuses a return after 2 business days (OR 7.9), and SAMA charges SAR 100 per payment message returned late, possibly plus an amount-based charge (CP 4.2, CP Appendix 2)." } ], "applies_to": "AFAQ cross-currency service, under SAMA's rules for Saudi direct participants: a return payment sent by the receiving direct participant for a payment it received through AFAQ and could not credit (OR 7.8), in the exchange period that accepts returns (OR 5.1 item 6)." }, "caveat": "SAMA's explanation is ISO's own definition of this code (ISO 20022 ExternalReturnReason1Code, 2Q2026). This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "related": [ "gcc-afaq-return:AM02", "gcc-afaq-return:AM06" ], "basis": { "sources": "SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service (2021-05-05, 24/9/1442 H, In-Force), read in full on rulebook.sama.gov.sa on 2026-09-18: Appendix 2, table of returned payments, entry for AM01; sections 5.1 item 6, 5.3, 7.3, 7.8, 7.9, 6. SAMA circular 43038107, Charging Policy for Cross Currency Payments Using AFAQ Service (2021-12-02), section 4.2 and Appendix 2. ISO 20022 External Code Sets 2Q2026 (2Q2026_externalcodesets_v3.json, downloaded 2026-09-18), compared by script. SAMA gives one line per code and no usage guidance, so triggers and actions beyond that line are inference.", "confidence": "medium" }, "currency": { "effective_since": "2021-05-05", "effective_note": "Date of SAMA circular 42068309 (24/9/1442 H), In-Force when read on 2026-09-18. The portal's Versions block shows date ranges that end before they begin, so no later edition can be read from it. The appendix says returned codes are registered in the AFAQ Central Component dictionary, which may be updated from time to time, so the live list may differ from the published one [Inference].", "source_edition": "SAMA circular 42068309 (2021-05-05), Appendix 2", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://rulebook.sama.gov.sa/en/appendix-2-return-and-rejection-codes", "source_class": "public_primary", "source_title": "Appendix 2 - Return and Rejection Codes (SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-18", "notes": "Appendix 2 of SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service, lists AM01 with the meaning this record states. SAMA's Operating Rules, sections 7.8 and 7.9, confirm the return limits the record gives: an outer limit of 2 business days, counted only on days that both countries work, with an earlier expected deadline; no compensation for holding the funds inside that limit; and refusal by the Central Component of a return that is late, a duplicate, or inconsistent with the original payment. Section 5.1 item 6 confirms the exchange period accepts returns. SAMA's Charging Policy for Cross Currency Payments Using AFAQ Service, circular 43038107, section 4.2, confirms the SAR 100 penalty for a late return." } ] }, "rail_name": "AFAQ Returns (SAMA rules for Saudi participants)", "governing_authority": "Saudi Central Bank (SAMA), for its direct participants; AFAQ is owned by the six GCC central banks and run by the Gulf Payments Company", "snapshot": "2026-09-18", "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "judgement", "label": "your bank's own terms", "needs": "whose terms decide it: the bank's, the participant's or the scheme's", "detail": "This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "from": "caveat" } ] }, { "uid": "gcc-afaq-return:AM02", "id": "AM02", "rail": "gcc-afaq-return", "kind": "reason-code", "name": "Amount above the allowed maximum", "group": "technical", "summary": "The amount is larger than the maximum the receiving side allows, so the payment is returned.", "triggers": [ "The amount exceeds a limit the receiving participant or the receiving country applies [Inference]" ], "actions": [ "Sending participant: find out the limit that applies before a new payment [Inference]", "Receiving participant: send back the original amounts at the original exchange rate, in both currencies and with nothing taken off, as one message whose field 72 carries the original payment's reference (OR 7.8, 7.9)", "Receiving participant: expect the Central Component to refuse the return if it differs from the original in amount, currency or rate, repeats a return already accepted, comes too late, or points at an original it cannot find (OR 7.9)" ], "retry": { "allowed": true, "rule": "Yes, as a new payment. A returned payment may not be sent again under its original Unique Message Reference; once the cause is fixed the sending participant may send it as a new payment with a new Unique Message Reference, and may keep the same UETR (OR 7.3). That sentence sits in the paragraph on rejections and is read here as covering returns too [Inference]. The new payment must respect the limit; SAMA's AFAQ rules publish no amount limit." }, "facts": { "return_windows": [ { "action": "return the payment with this reason", "by": "Receiving direct participant (a Saudi participant under SAMA's rules)", "deadline": "Best on the business day the payment arrived; if not, by that payment type's cut-off on the next business day; never later than 2 business days after receipt, counting only days that are business days in both the sending and the receiving country (OR 7.8, 7.9, 5.3). Inside that time no compensation for use of the funds is owed (OR 7.8). The Central Component refuses a return after 2 business days (OR 7.9), and SAMA charges SAR 100 per payment message returned late, possibly plus an amount-based charge (CP 4.2, CP Appendix 2)." } ], "applies_to": "AFAQ cross-currency service, under SAMA's rules for Saudi direct participants: a return payment sent by the receiving direct participant for a payment it received through AFAQ and could not credit (OR 7.8), in the exchange period that accepts returns (OR 5.1 item 6)." }, "caveat": "SAMA's AFAQ rules set no amount ceiling; SAMA may restrict categories of transaction during the business cycle (OR 5.5). Whose maximum this code refers to is not stated [Inference]. SAMA's explanation is ISO's own definition of this code (ISO 20022 ExternalReturnReason1Code, 2Q2026). This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "related": [ "gcc-afaq-return:AM06", "gcc-afaq-return:AM01" ], "basis": { "sources": "SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service (2021-05-05, 24/9/1442 H, In-Force), read in full on rulebook.sama.gov.sa on 2026-09-18: Appendix 2, table of returned payments, entry for AM02; sections 5.1 item 6, 5.3, 7.3, 7.8, 7.9, 5.5. SAMA circular 43038107, Charging Policy for Cross Currency Payments Using AFAQ Service (2021-12-02), section 4.2 and Appendix 2. ISO 20022 External Code Sets 2Q2026 (2Q2026_externalcodesets_v3.json, downloaded 2026-09-18), compared by script. SAMA gives one line per code and no usage guidance, so triggers and actions beyond that line are inference.", "confidence": "medium" }, "currency": { "effective_since": "2021-05-05", "effective_note": "Date of SAMA circular 42068309 (24/9/1442 H), In-Force when read on 2026-09-18. The portal's Versions block shows date ranges that end before they begin, so no later edition can be read from it. The appendix says returned codes are registered in the AFAQ Central Component dictionary, which may be updated from time to time, so the live list may differ from the published one [Inference].", "source_edition": "SAMA circular 42068309 (2021-05-05), Appendix 2", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://rulebook.sama.gov.sa/en/appendix-2-return-and-rejection-codes", "source_class": "public_primary", "source_title": "Appendix 2 - Return and Rejection Codes (SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-18", "notes": "Appendix 2 of SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service, lists AM02 with the meaning this record states. SAMA's Operating Rules, sections 7.8 and 7.9, confirm the return limits the record gives: an outer limit of 2 business days, counted only on days that both countries work, with an earlier expected deadline; no compensation for holding the funds inside that limit; and refusal by the Central Component of a return that is late, a duplicate, or inconsistent with the original payment. Section 5.1 item 6 confirms the exchange period accepts returns. SAMA's Charging Policy for Cross Currency Payments Using AFAQ Service, circular 43038107, section 4.2, confirms the SAR 100 penalty for a late return." } ] }, "rail_name": "AFAQ Returns (SAMA rules for Saudi participants)", "governing_authority": "Saudi Central Bank (SAMA), for its direct participants; AFAQ is owned by the six GCC central banks and run by the Gulf Payments Company", "snapshot": "2026-09-18", "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "judgement", "label": "your bank's own terms", "needs": "whose terms decide it: the bank's, the participant's or the scheme's", "detail": "This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "from": "caveat" } ] }, { "uid": "gcc-afaq-return:AM03", "id": "AM03", "rail": "gcc-afaq-return", "kind": "reason-code", "name": "Currency cannot be processed", "group": "technical", "summary": "The receiving side cannot handle the currency of the amount under any agreement it has. Every AFAQ payment carries the sending country's currency, the receiving country's currency and the day's confirmed rate (OR 6, 7.2), so a wrong currency is normally rejected before it reaches the receiving participant [Inference].", "triggers": [ "The currency on the payment is not the one the receiving participant can take [Inference]" ], "actions": [ "Sending participant: check the currency pair and send a new payment in the receiving country's currency at the confirmed rate (OR 6)", "Receiving participant: send back the original amounts at the original exchange rate, in both currencies and with nothing taken off, as one message whose field 72 carries the original payment's reference (OR 7.8, 7.9)", "Receiving participant: expect the Central Component to refuse the return if it differs from the original in amount, currency or rate, repeats a return already accepted, comes too late, or points at an original it cannot find (OR 7.9)" ], "retry": { "allowed": true, "rule": "Yes, as a new payment. A returned payment may not be sent again under its original Unique Message Reference; once the cause is fixed the sending participant may send it as a new payment with a new Unique Message Reference, and may keep the same UETR (OR 7.3). That sentence sits in the paragraph on rejections and is read here as covering returns too [Inference]." }, "facts": { "return_windows": [ { "action": "return the payment with this reason", "by": "Receiving direct participant (a Saudi participant under SAMA's rules)", "deadline": "Best on the business day the payment arrived; if not, by that payment type's cut-off on the next business day; never later than 2 business days after receipt, counting only days that are business days in both the sending and the receiving country (OR 7.8, 7.9, 5.3). Inside that time no compensation for use of the funds is owed (OR 7.8). The Central Component refuses a return after 2 business days (OR 7.9), and SAMA charges SAR 100 per payment message returned late, possibly plus an amount-based charge (CP 4.2, CP Appendix 2)." } ], "applies_to": "AFAQ cross-currency service, under SAMA's rules for Saudi direct participants: a return payment sent by the receiving direct participant for a payment it received through AFAQ and could not credit (OR 7.8), in the exchange period that accepts returns (OR 5.1 item 6)." }, "caveat": "SAMA's explanation matches ISO's definition of this code apart from spelling (ISO 20022 ExternalReturnReason1Code, 2Q2026). This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "related": [ "gcc-afaq-return:CURR", "gcc-afaq-return:BADC" ], "basis": { "sources": "SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service (2021-05-05, 24/9/1442 H, In-Force), read in full on rulebook.sama.gov.sa on 2026-09-18: Appendix 2, table of returned payments, entry for AM03; sections 5.1 item 6, 5.3, 7.3, 7.8, 7.9, 6. SAMA circular 43038107, Charging Policy for Cross Currency Payments Using AFAQ Service (2021-12-02), section 4.2 and Appendix 2. ISO 20022 External Code Sets 2Q2026 (2Q2026_externalcodesets_v3.json, downloaded 2026-09-18), compared by script. SAMA gives one line per code and no usage guidance, so triggers and actions beyond that line are inference.", "confidence": "medium" }, "currency": { "effective_since": "2021-05-05", "effective_note": "Date of SAMA circular 42068309 (24/9/1442 H), In-Force when read on 2026-09-18. The portal's Versions block shows date ranges that end before they begin, so no later edition can be read from it. The appendix says returned codes are registered in the AFAQ Central Component dictionary, which may be updated from time to time, so the live list may differ from the published one [Inference].", "source_edition": "SAMA circular 42068309 (2021-05-05), Appendix 2", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://rulebook.sama.gov.sa/en/appendix-2-return-and-rejection-codes", "source_class": "public_primary", "source_title": "Appendix 2 - Return and Rejection Codes (SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-18", "notes": "Appendix 2 of SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service, lists AM03 with the meaning this record states. SAMA's Operating Rules, sections 7.8 and 7.9, confirm the return limits the record gives: an outer limit of 2 business days, counted only on days that both countries work, with an earlier expected deadline; no compensation for holding the funds inside that limit; and refusal by the Central Component of a return that is late, a duplicate, or inconsistent with the original payment. Section 5.1 item 6 confirms the exchange period accepts returns. SAMA's Charging Policy for Cross Currency Payments Using AFAQ Service, circular 43038107, section 4.2, confirms the SAR 100 penalty for a late return. Section 6 confirms the exchange rate and currency amounts are validated before a payment reaches the receiving participant." } ] }, "rail_name": "AFAQ Returns (SAMA rules for Saudi participants)", "governing_authority": "Saudi Central Bank (SAMA), for its direct participants; AFAQ is owned by the six GCC central banks and run by the Gulf Payments Company", "snapshot": "2026-09-18", "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "judgement", "label": "your bank's own terms", "needs": "whose terms decide it: the bank's, the participant's or the scheme's", "detail": "This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "from": "caveat" } ] }, { "uid": "gcc-afaq-return:AM04", "id": "AM04", "rail": "gcc-afaq-return", "kind": "reason-code", "name": "Insufficient funds", "group": "funds", "summary": "ISO's insufficient funds code. On AFAQ a returning bank has received a credit and needs no funds from its customer, so when a receiving participant would return a payment for this reason is not clear [Inference]. SAMA gives AM07 the same explanation.", "triggers": [ "SAMA does not say. A sending participant without enough money in its AFAQ account is stopped before settlement: Saudi participants prefund that account each morning (OR 5.1 item 5), and the rejection list has its own lack of funds code, RJ19 [Inference]" ], "actions": [ "Sending participant: ask the receiving participant what it meant, since the code does not fit a received credit [Inference]", "Receiving participant: send back the original amounts at the original exchange rate, in both currencies and with nothing taken off, as one message whose field 72 carries the original payment's reference (OR 7.8, 7.9)", "Receiving participant: expect the Central Component to refuse the return if it differs from the original in amount, currency or rate, repeats a return already accepted, comes too late, or points at an original it cannot find (OR 7.9)" ], "retry": { "allowed": true, "rule": "Not barred. Nothing in SAMA's rules stops a new payment once the cause is dealt with; it goes out with a new Unique Message Reference and may keep the UETR (OR 7.3) [Inference: the OR 7.3 sentence is written for rejections]. Only one successful return is allowed per payment (OR 7.9)." }, "facts": { "return_windows": [ { "action": "return the payment with this reason", "by": "Receiving direct participant (a Saudi participant under SAMA's rules)", "deadline": "Best on the business day the payment arrived; if not, by that payment type's cut-off on the next business day; never later than 2 business days after receipt, counting only days that are business days in both the sending and the receiving country (OR 7.8, 7.9, 5.3). Inside that time no compensation for use of the funds is owed (OR 7.8). The Central Component refuses a return after 2 business days (OR 7.9), and SAMA charges SAR 100 per payment message returned late, possibly plus an amount-based charge (CP 4.2, CP Appendix 2)." } ], "applies_to": "AFAQ cross-currency service, under SAMA's rules for Saudi direct participants: a return payment sent by the receiving direct participant for a payment it received through AFAQ and could not credit (OR 7.8), in the exchange period that accepts returns (OR 5.1 item 6)." }, "caveat": "SAMA's explanation is ISO's own definition of this code (ISO 20022 ExternalReturnReason1Code, 2Q2026). This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "related": [ "gcc-afaq-return:AM07" ], "basis": { "sources": "SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service (2021-05-05, 24/9/1442 H, In-Force), read in full on rulebook.sama.gov.sa on 2026-09-18: Appendix 2, table of returned payments, entry for AM04; sections 5.1 item 6, 5.3, 7.3, 7.8, 7.9, 5.1 item 5. SAMA circular 43038107, Charging Policy for Cross Currency Payments Using AFAQ Service (2021-12-02), section 4.2 and Appendix 2. ISO 20022 External Code Sets 2Q2026 (2Q2026_externalcodesets_v3.json, downloaded 2026-09-18), compared by script. SAMA gives one line per code and no usage guidance, so triggers and actions beyond that line are inference.", "confidence": "low" }, "currency": { "effective_since": "2021-05-05", "effective_note": "Date of SAMA circular 42068309 (24/9/1442 H), In-Force when read on 2026-09-18. The portal's Versions block shows date ranges that end before they begin, so no later edition can be read from it. The appendix says returned codes are registered in the AFAQ Central Component dictionary, which may be updated from time to time, so the live list may differ from the published one [Inference].", "source_edition": "SAMA circular 42068309 (2021-05-05), Appendix 2", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://rulebook.sama.gov.sa/en/appendix-2-return-and-rejection-codes", "source_class": "public_primary", "source_title": "Appendix 2 - Return and Rejection Codes (SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-18", "notes": "Appendix 2 of SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service, lists AM04 with the meaning this record states. SAMA's Operating Rules, sections 7.8 and 7.9, confirm the return limits the record gives: an outer limit of 2 business days, counted only on days that both countries work, with an earlier expected deadline; no compensation for holding the funds inside that limit; and refusal by the Central Component of a return that is late, a duplicate, or inconsistent with the original payment. Section 5.1 item 6 confirms the exchange period accepts returns. SAMA's Charging Policy for Cross Currency Payments Using AFAQ Service, circular 43038107, section 4.2, confirms the SAR 100 penalty for a late return. Appendix 2 gives AM04 and AM07 the identical wording, confirming the record's point that SAMA repeats this explanation under AM07." } ] }, "rail_name": "AFAQ Returns (SAMA rules for Saudi participants)", "governing_authority": "Saudi Central Bank (SAMA), for its direct participants; AFAQ is owned by the six GCC central banks and run by the Gulf Payments Company", "snapshot": "2026-09-18", "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "judgement", "label": "your bank's own terms", "needs": "whose terms decide it: the bank's, the participant's or the scheme's", "detail": "This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "from": "caveat" } ] }, { "uid": "gcc-afaq-return:AM05", "id": "AM05", "rail": "gcc-afaq-return", "kind": "reason-code", "name": "Duplicate payment", "group": "administrative", "summary": "The receiving participant believes it has already received this payment, and sends the second copy back.", "triggers": [ "The same payment arrives twice, for example when a sender resends after not seeing a completion confirmation [Inference]; the sending central bank is meant to investigate a confirmation missing after 10 minutes (OR 7.5)" ], "actions": [ "Sending participant: check whether the first payment completed before sending anything again (OR 7.5)", "Receiving participant: send back the original amounts at the original exchange rate, in both currencies and with nothing taken off, as one message whose field 72 carries the original payment's reference (OR 7.8, 7.9)", "Receiving participant: expect the Central Component to refuse the return if it differs from the original in amount, currency or rate, repeats a return already accepted, comes too late, or points at an original it cannot find (OR 7.9)" ], "retry": { "allowed": false, "rule": "No. The first payment already reached the beneficiary's bank [Inference]; sending it again would repeat the duplicate." }, "facts": { "return_windows": [ { "action": "return the payment with this reason", "by": "Receiving direct participant (a Saudi participant under SAMA's rules)", "deadline": "Best on the business day the payment arrived; if not, by that payment type's cut-off on the next business day; never later than 2 business days after receipt, counting only days that are business days in both the sending and the receiving country (OR 7.8, 7.9, 5.3). Inside that time no compensation for use of the funds is owed (OR 7.8). The Central Component refuses a return after 2 business days (OR 7.9), and SAMA charges SAR 100 per payment message returned late, possibly plus an amount-based charge (CP 4.2, CP Appendix 2)." } ], "applies_to": "AFAQ cross-currency service, under SAMA's rules for Saudi direct participants: a return payment sent by the receiving direct participant for a payment it received through AFAQ and could not credit (OR 7.8), in the exchange period that accepts returns (OR 5.1 item 6)." }, "caveat": "SAMA's explanation is ISO's own definition of this code (ISO 20022 ExternalReturnReason1Code, 2Q2026). This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "related": [ "gcc-afaq-return:ARDT", "gcc-afaq-return:RF01", "sepa-sct:AM05" ], "basis": { "sources": "SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service (2021-05-05, 24/9/1442 H, In-Force), read in full on rulebook.sama.gov.sa on 2026-09-18: Appendix 2, table of returned payments, entry for AM05; sections 5.1 item 6, 5.3, 7.3, 7.8, 7.9, 7.5. SAMA circular 43038107, Charging Policy for Cross Currency Payments Using AFAQ Service (2021-12-02), section 4.2 and Appendix 2. ISO 20022 External Code Sets 2Q2026 (2Q2026_externalcodesets_v3.json, downloaded 2026-09-18), compared by script. SAMA gives one line per code and no usage guidance, so triggers and actions beyond that line are inference.", "confidence": "medium" }, "currency": { "effective_since": "2021-05-05", "effective_note": "Date of SAMA circular 42068309 (24/9/1442 H), In-Force when read on 2026-09-18. The portal's Versions block shows date ranges that end before they begin, so no later edition can be read from it. The appendix says returned codes are registered in the AFAQ Central Component dictionary, which may be updated from time to time, so the live list may differ from the published one [Inference].", "source_edition": "SAMA circular 42068309 (2021-05-05), Appendix 2", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://rulebook.sama.gov.sa/en/appendix-2-return-and-rejection-codes", "source_class": "public_primary", "source_title": "Appendix 2 - Return and Rejection Codes (SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-18", "notes": "Appendix 2 of SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service, lists AM05 with the meaning this record states. SAMA's Operating Rules, sections 7.8 and 7.9, confirm the return limits the record gives: an outer limit of 2 business days, counted only on days that both countries work, with an earlier expected deadline; no compensation for holding the funds inside that limit; and refusal by the Central Component of a return that is late, a duplicate, or inconsistent with the original payment. Section 5.1 item 6 confirms the exchange period accepts returns. SAMA's Charging Policy for Cross Currency Payments Using AFAQ Service, circular 43038107, section 4.2, confirms the SAR 100 penalty for a late return." } ] }, "rail_name": "AFAQ Returns (SAMA rules for Saudi participants)", "governing_authority": "Saudi Central Bank (SAMA), for its direct participants; AFAQ is owned by the six GCC central banks and run by the Gulf Payments Company", "snapshot": "2026-09-18", "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "judgement", "label": "your bank's own terms", "needs": "whose terms decide it: the bank's, the participant's or the scheme's", "detail": "This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "from": "caveat" } ] }, { "uid": "gcc-afaq-return:AM06", "id": "AM06", "rail": "gcc-afaq-return", "kind": "reason-code", "name": "Amount below the agreed minimum", "group": "technical", "summary": "Too small: the sum falls under a minimum agreed with the receiving side, so the payment goes back.", "triggers": [ "The amount falls under a minimum the receiving side applies [Inference]" ], "actions": [ "Sending participant: find out the minimum before a new payment [Inference]", "Receiving participant: send back the original amounts at the original exchange rate, in both currencies and with nothing taken off, as one message whose field 72 carries the original payment's reference (OR 7.8, 7.9)", "Receiving participant: expect the Central Component to refuse the return if it differs from the original in amount, currency or rate, repeats a return already accepted, comes too late, or points at an original it cannot find (OR 7.9)" ], "retry": { "allowed": true, "rule": "Yes, as a new payment. A returned payment may not be sent again under its original Unique Message Reference; once the cause is fixed the sending participant may send it as a new payment with a new Unique Message Reference, and may keep the same UETR (OR 7.3). That sentence sits in the paragraph on rejections and is read here as covering returns too [Inference]." }, "facts": { "return_windows": [ { "action": "return the payment with this reason", "by": "Receiving direct participant (a Saudi participant under SAMA's rules)", "deadline": "Best on the business day the payment arrived; if not, by that payment type's cut-off on the next business day; never later than 2 business days after receipt, counting only days that are business days in both the sending and the receiving country (OR 7.8, 7.9, 5.3). Inside that time no compensation for use of the funds is owed (OR 7.8). The Central Component refuses a return after 2 business days (OR 7.9), and SAMA charges SAR 100 per payment message returned late, possibly plus an amount-based charge (CP 4.2, CP Appendix 2)." } ], "applies_to": "AFAQ cross-currency service, under SAMA's rules for Saudi direct participants: a return payment sent by the receiving direct participant for a payment it received through AFAQ and could not credit (OR 7.8), in the exchange period that accepts returns (OR 5.1 item 6)." }, "caveat": "SAMA's AFAQ rules publish no minimum amount; whose minimum applies is not stated [Inference]. SAMA's explanation is ISO's own definition of this code (ISO 20022 ExternalReturnReason1Code, 2Q2026). This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "related": [ "gcc-afaq-return:AM02", "gcc-afaq-return:AM01" ], "basis": { "sources": "SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service (2021-05-05, 24/9/1442 H, In-Force), read in full on rulebook.sama.gov.sa on 2026-09-18: Appendix 2, table of returned payments, entry for AM06; sections 5.1 item 6, 5.3, 7.3, 7.8, 7.9. SAMA circular 43038107, Charging Policy for Cross Currency Payments Using AFAQ Service (2021-12-02), section 4.2 and Appendix 2. ISO 20022 External Code Sets 2Q2026 (2Q2026_externalcodesets_v3.json, downloaded 2026-09-18), compared by script. SAMA gives one line per code and no usage guidance, so triggers and actions beyond that line are inference.", "confidence": "medium" }, "currency": { "effective_since": "2021-05-05", "effective_note": "Date of SAMA circular 42068309 (24/9/1442 H), In-Force when read on 2026-09-18. The portal's Versions block shows date ranges that end before they begin, so no later edition can be read from it. The appendix says returned codes are registered in the AFAQ Central Component dictionary, which may be updated from time to time, so the live list may differ from the published one [Inference].", "source_edition": "SAMA circular 42068309 (2021-05-05), Appendix 2", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://rulebook.sama.gov.sa/en/appendix-2-return-and-rejection-codes", "source_class": "public_primary", "source_title": "Appendix 2 - Return and Rejection Codes (SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-18", "notes": "Appendix 2 of SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service, lists AM06 with the meaning this record states. SAMA's Operating Rules, sections 7.8 and 7.9, confirm the return limits the record gives: an outer limit of 2 business days, counted only on days that both countries work, with an earlier expected deadline; no compensation for holding the funds inside that limit; and refusal by the Central Component of a return that is late, a duplicate, or inconsistent with the original payment. Section 5.1 item 6 confirms the exchange period accepts returns. SAMA's Charging Policy for Cross Currency Payments Using AFAQ Service, circular 43038107, section 4.2, confirms the SAR 100 penalty for a late return." } ] }, "rail_name": "AFAQ Returns (SAMA rules for Saudi participants)", "governing_authority": "Saudi Central Bank (SAMA), for its direct participants; AFAQ is owned by the six GCC central banks and run by the Gulf Payments Company", "snapshot": "2026-09-18", "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "judgement", "label": "your bank's own terms", "needs": "whose terms decide it: the bank's, the participant's or the scheme's", "detail": "This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "from": "caveat" } ] }, { "uid": "gcc-afaq-return:AM07", "id": "AM07", "rail": "gcc-afaq-return", "kind": "reason-code", "name": "Insufficient funds (AFAQ meaning; ISO means a regulatory block)", "group": "funds", "summary": "In SAMA's list AM07 carries the same insufficient funds explanation as AM04. ISO uses AM07 for something else, an amount that a regulator has frozen. This record follows SAMA's text, and so departs from ISO.", "triggers": [ "Whatever AM04 covers on AFAQ, which SAMA does not explain [Inference]", "A receiving bank outside Saudi Arabia, or one following ISO, may mean a regulatory block instead [Speculation]" ], "actions": [ "Sending participant: do not assume which meaning the returning bank intended; read any additional information on the return and ask if it is unclear [Inference]", "Receiving participant: send back the original amounts at the original exchange rate, in both currencies and with nothing taken off, as one message whose field 72 carries the original payment's reference (OR 7.8, 7.9)", "Receiving participant: expect the Central Component to refuse the return if it differs from the original in amount, currency or rate, repeats a return already accepted, comes too late, or points at an original it cannot find (OR 7.9)" ], "retry": { "allowed": true, "rule": "Not barred. Nothing in SAMA's rules stops a new payment once the cause is dealt with; it goes out with a new Unique Message Reference and may keep the UETR (OR 7.3) [Inference: the OR 7.3 sentence is written for rejections]. Only one successful return is allowed per payment (OR 7.9). If the returning bank meant ISO's regulatory block, a new payment is pointless until the authority's hold is resolved [Inference]." }, "facts": { "return_windows": [ { "action": "return the payment with this reason", "by": "Receiving direct participant (a Saudi participant under SAMA's rules)", "deadline": "Best on the business day the payment arrived; if not, by that payment type's cut-off on the next business day; never later than 2 business days after receipt, counting only days that are business days in both the sending and the receiving country (OR 7.8, 7.9, 5.3). Inside that time no compensation for use of the funds is owed (OR 7.8). The Central Component refuses a return after 2 business days (OR 7.9), and SAMA charges SAR 100 per payment message returned late, possibly plus an amount-based charge (CP 4.2, CP Appendix 2)." } ], "applies_to": "AFAQ cross-currency service, under SAMA's rules for Saudi direct participants: a return payment sent by the receiving direct participant for a payment it received through AFAQ and could not credit (OR 7.8), in the exchange period that accepts returns (OR 5.1 item 6)." }, "caveat": "The code alone cannot tell an agent whether SAMA's or ISO's meaning was intended. SAMA's explanation differs from ISO's definition of this code, a regulator's freeze on the amount (ISO 20022 ExternalReturnReason1Code, 2Q2026). This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "related": [ "gcc-afaq-return:AM04", "gcc-afaq-return:RR04" ], "basis": { "sources": "SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service (2021-05-05, 24/9/1442 H, In-Force), read in full on rulebook.sama.gov.sa on 2026-09-18: Appendix 2, table of returned payments, entry for AM07; sections 5.1 item 6, 5.3, 7.3, 7.8, 7.9. SAMA circular 43038107, Charging Policy for Cross Currency Payments Using AFAQ Service (2021-12-02), section 4.2 and Appendix 2. ISO 20022 External Code Sets 2Q2026 (2Q2026_externalcodesets_v3.json, downloaded 2026-09-18), compared by script. SAMA gives one line per code and no usage guidance, so triggers and actions beyond that line are inference.", "confidence": "low" }, "currency": { "effective_since": "2021-05-05", "effective_note": "Date of SAMA circular 42068309 (24/9/1442 H), In-Force when read on 2026-09-18. The portal's Versions block shows date ranges that end before they begin, so no later edition can be read from it. The appendix says returned codes are registered in the AFAQ Central Component dictionary, which may be updated from time to time, so the live list may differ from the published one [Inference].", "source_edition": "SAMA circular 42068309 (2021-05-05), Appendix 2", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://rulebook.sama.gov.sa/en/appendix-2-return-and-rejection-codes", "source_class": "public_primary", "source_title": "Appendix 2 - Return and Rejection Codes (SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-18", "notes": "Appendix 2 of SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service, lists AM07 with the meaning this record states. SAMA's Operating Rules, sections 7.8 and 7.9, confirm the return limits the record gives: an outer limit of 2 business days, counted only on days that both countries work, with an earlier expected deadline; no compensation for holding the funds inside that limit; and refusal by the Central Component of a return that is late, a duplicate, or inconsistent with the original payment. Section 5.1 item 6 confirms the exchange period accepts returns. SAMA's Charging Policy for Cross Currency Payments Using AFAQ Service, circular 43038107, section 4.2, confirms the SAR 100 penalty for a late return. Appendix 2 gives AM04 and AM07 the identical wording, confirming the record's point that SAMA repeats AM04's explanation under AM07." } ] }, "rail_name": "AFAQ Returns (SAMA rules for Saudi participants)", "governing_authority": "Saudi Central Bank (SAMA), for its direct participants; AFAQ is owned by the six GCC central banks and run by the Gulf Payments Company", "snapshot": "2026-09-18", "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "judgement", "label": "your bank's own terms", "needs": "whose terms decide it: the bank's, the participant's or the scheme's", "detail": "This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "from": "caveat" } ] }, { "uid": "gcc-afaq-return:AM09", "id": "AM09", "rail": "gcc-afaq-return", "kind": "reason-code", "name": "Amount not what was expected", "group": "technical", "summary": "The sum that arrived differs from what the beneficiary's side was expecting under their arrangement, so the payment goes back.", "triggers": [ "The beneficiary or its bank expected a different amount, for example after a conversion the payer did not foresee [Inference]", "The receiving participant checks the converted amount using the sender's original rate (OR 7.3); a wrong conversion is normally rejected before arrival (OR 6) [Inference]" ], "actions": [ "Sending participant: agree the amount with the payer and the beneficiary before a new payment", "Note that the return cannot hold back part of the money: it must carry the original amounts and rate (OR 7.8, 7.9)", "Receiving participant: send back the original amounts at the original exchange rate, in both currencies and with nothing taken off, as one message whose field 72 carries the original payment's reference (OR 7.8, 7.9)", "Receiving participant: expect the Central Component to refuse the return if it differs from the original in amount, currency or rate, repeats a return already accepted, comes too late, or points at an original it cannot find (OR 7.9)" ], "retry": { "allowed": true, "rule": "Yes, as a new payment. A returned payment may not be sent again under its original Unique Message Reference; once the cause is fixed the sending participant may send it as a new payment with a new Unique Message Reference, and may keep the same UETR (OR 7.3). That sentence sits in the paragraph on rejections and is read here as covering returns too [Inference]." }, "facts": { "return_windows": [ { "action": "return the payment with this reason", "by": "Receiving direct participant (a Saudi participant under SAMA's rules)", "deadline": "Best on the business day the payment arrived; if not, by that payment type's cut-off on the next business day; never later than 2 business days after receipt, counting only days that are business days in both the sending and the receiving country (OR 7.8, 7.9, 5.3). Inside that time no compensation for use of the funds is owed (OR 7.8). The Central Component refuses a return after 2 business days (OR 7.9), and SAMA charges SAR 100 per payment message returned late, possibly plus an amount-based charge (CP 4.2, CP Appendix 2)." } ], "applies_to": "AFAQ cross-currency service, under SAMA's rules for Saudi direct participants: a return payment sent by the receiving direct participant for a payment it received through AFAQ and could not credit (OR 7.8), in the exchange period that accepts returns (OR 5.1 item 6)." }, "caveat": "SAMA's explanation is ISO's own definition of this code (ISO 20022 ExternalReturnReason1Code, 2Q2026). This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "related": [ "gcc-afaq-return:AM10", "gcc-afaq-return:CURR" ], "basis": { "sources": "SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service (2021-05-05, 24/9/1442 H, In-Force), read in full on rulebook.sama.gov.sa on 2026-09-18: Appendix 2, table of returned payments, entry for AM09; sections 5.1 item 6, 5.3, 7.3, 7.8, 7.9, 6. SAMA circular 43038107, Charging Policy for Cross Currency Payments Using AFAQ Service (2021-12-02), section 4.2 and Appendix 2. ISO 20022 External Code Sets 2Q2026 (2Q2026_externalcodesets_v3.json, downloaded 2026-09-18), compared by script. SAMA gives one line per code and no usage guidance, so triggers and actions beyond that line are inference.", "confidence": "medium" }, "currency": { "effective_since": "2021-05-05", "effective_note": "Date of SAMA circular 42068309 (24/9/1442 H), In-Force when read on 2026-09-18. The portal's Versions block shows date ranges that end before they begin, so no later edition can be read from it. The appendix says returned codes are registered in the AFAQ Central Component dictionary, which may be updated from time to time, so the live list may differ from the published one [Inference].", "source_edition": "SAMA circular 42068309 (2021-05-05), Appendix 2", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://rulebook.sama.gov.sa/en/appendix-2-return-and-rejection-codes", "source_class": "public_primary", "source_title": "Appendix 2 - Return and Rejection Codes (SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-18", "notes": "Appendix 2 of SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service, lists AM09 with the meaning this record states. SAMA's Operating Rules, sections 7.8 and 7.9, confirm the return limits the record gives: an outer limit of 2 business days, counted only on days that both countries work, with an earlier expected deadline; no compensation for holding the funds inside that limit; and refusal by the Central Component of a return that is late, a duplicate, or inconsistent with the original payment. Section 5.1 item 6 confirms the exchange period accepts returns. SAMA's Charging Policy for Cross Currency Payments Using AFAQ Service, circular 43038107, section 4.2, confirms the SAR 100 penalty for a late return." } ] }, "rail_name": "AFAQ Returns (SAMA rules for Saudi participants)", "governing_authority": "Saudi Central Bank (SAMA), for its direct participants; AFAQ is owned by the six GCC central banks and run by the Gulf Payments Company", "snapshot": "2026-09-18", "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "judgement", "label": "your bank's own terms", "needs": "whose terms decide it: the bank's, the participant's or the scheme's", "detail": "This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "from": "caveat" } ] }, { "uid": "gcc-afaq-return:AM10", "id": "AM10", "rail": "gcc-afaq-return", "kind": "reason-code", "name": "Control sum does not add up", "group": "technical", "summary": "ISO's code for a batch whose instructed amounts do not equal its control sum. AFAQ carries single payment messages only (OR 7.2), so there is no batch control sum to fail [Inference].", "triggers": [ "SAMA does not say when this would apply on AFAQ [Inference]" ], "actions": [ "Sending participant: ask the receiving participant what it meant [Inference]", "Receiving participant: send back the original amounts at the original exchange rate, in both currencies and with nothing taken off, as one message whose field 72 carries the original payment's reference (OR 7.8, 7.9)", "Receiving participant: expect the Central Component to refuse the return if it differs from the original in amount, currency or rate, repeats a return already accepted, comes too late, or points at an original it cannot find (OR 7.9)" ], "retry": { "allowed": true, "rule": "Not barred. Nothing in SAMA's rules stops a new payment once the cause is dealt with; it goes out with a new Unique Message Reference and may keep the UETR (OR 7.3) [Inference: the OR 7.3 sentence is written for rejections]. Only one successful return is allowed per payment (OR 7.9)." }, "facts": { "return_windows": [ { "action": "return the payment with this reason", "by": "Receiving direct participant (a Saudi participant under SAMA's rules)", "deadline": "Best on the business day the payment arrived; if not, by that payment type's cut-off on the next business day; never later than 2 business days after receipt, counting only days that are business days in both the sending and the receiving country (OR 7.8, 7.9, 5.3). Inside that time no compensation for use of the funds is owed (OR 7.8). The Central Component refuses a return after 2 business days (OR 7.9), and SAMA charges SAR 100 per payment message returned late, possibly plus an amount-based charge (CP 4.2, CP Appendix 2)." } ], "applies_to": "AFAQ cross-currency service, under SAMA's rules for Saudi direct participants: a return payment sent by the receiving direct participant for a payment it received through AFAQ and could not credit (OR 7.8), in the exchange period that accepts returns (OR 5.1 item 6)." }, "caveat": "SAMA's explanation is ISO's own definition of this code (ISO 20022 ExternalReturnReason1Code, 2Q2026). This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "related": [ "gcc-afaq-return:AM09", "gcc-afaq-return:RF01" ], "basis": { "sources": "SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service (2021-05-05, 24/9/1442 H, In-Force), read in full on rulebook.sama.gov.sa on 2026-09-18: Appendix 2, table of returned payments, entry for AM10; sections 5.1 item 6, 5.3, 7.3, 7.8, 7.9, 7.2. SAMA circular 43038107, Charging Policy for Cross Currency Payments Using AFAQ Service (2021-12-02), section 4.2 and Appendix 2. ISO 20022 External Code Sets 2Q2026 (2Q2026_externalcodesets_v3.json, downloaded 2026-09-18), compared by script. SAMA gives one line per code and no usage guidance, so triggers and actions beyond that line are inference.", "confidence": "low" }, "currency": { "effective_since": "2021-05-05", "effective_note": "Date of SAMA circular 42068309 (24/9/1442 H), In-Force when read on 2026-09-18. The portal's Versions block shows date ranges that end before they begin, so no later edition can be read from it. The appendix says returned codes are registered in the AFAQ Central Component dictionary, which may be updated from time to time, so the live list may differ from the published one [Inference].", "source_edition": "SAMA circular 42068309 (2021-05-05), Appendix 2", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://rulebook.sama.gov.sa/en/appendix-2-return-and-rejection-codes", "source_class": "public_primary", "source_title": "Appendix 2 - Return and Rejection Codes (SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-18", "notes": "Appendix 2 of SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service, lists AM10 with the meaning this record states. SAMA's Operating Rules, sections 7.8 and 7.9, confirm the return limits the record gives: an outer limit of 2 business days, counted only on days that both countries work, with an earlier expected deadline; no compensation for holding the funds inside that limit; and refusal by the Central Component of a return that is late, a duplicate, or inconsistent with the original payment. Section 5.1 item 6 confirms the exchange period accepts returns. SAMA's Charging Policy for Cross Currency Payments Using AFAQ Service, circular 43038107, section 4.2, confirms the SAR 100 penalty for a late return. Section 7.2(a) confirms AFAQ carries single payment messages only, supporting the record's point that there is no batch control sum to fail." } ] }, "rail_name": "AFAQ Returns (SAMA rules for Saudi participants)", "governing_authority": "Saudi Central Bank (SAMA), for its direct participants; AFAQ is owned by the six GCC central banks and run by the Gulf Payments Company", "snapshot": "2026-09-18", "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "judgement", "label": "your bank's own terms", "needs": "whose terms decide it: the bank's, the participant's or the scheme's", "detail": "This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "from": "caveat" } ] }, { "uid": "gcc-afaq-return:ARDT", "id": "ARDT", "rail": "gcc-afaq-return", "kind": "reason-code", "name": "Already returned", "group": "administrative", "summary": "The payment has already been returned. SAMA copied ISO's wording, which speaks of a SEPA credit transfer; on AFAQ read it as an AFAQ payment already sent back.", "triggers": [ "SAMA does not say when a receiving participant would send a return with this code. Only one successful return is allowed per payment and the Central Component refuses a second (OR 7.9), so ARDT cannot be used to return the same payment twice [Inference]" ], "actions": [ "Sending participant: check its books for the earlier return before chasing the funds [Inference]", "Receiving participant: send back the original amounts at the original exchange rate, in both currencies and with nothing taken off, as one message whose field 72 carries the original payment's reference (OR 7.8, 7.9)", "Receiving participant: expect the Central Component to refuse the return if it differs from the original in amount, currency or rate, repeats a return already accepted, comes too late, or points at an original it cannot find (OR 7.9)" ], "retry": { "allowed": false, "rule": "Not applicable: the funds have already come back once, and only one return per payment can succeed (OR 7.9)." }, "facts": { "return_windows": [ { "action": "return the payment with this reason", "by": "Receiving direct participant (a Saudi participant under SAMA's rules)", "deadline": "Best on the business day the payment arrived; if not, by that payment type's cut-off on the next business day; never later than 2 business days after receipt, counting only days that are business days in both the sending and the receiving country (OR 7.8, 7.9, 5.3). Inside that time no compensation for use of the funds is owed (OR 7.8). The Central Component refuses a return after 2 business days (OR 7.9), and SAMA charges SAR 100 per payment message returned late, possibly plus an amount-based charge (CP 4.2, CP Appendix 2)." } ], "applies_to": "AFAQ cross-currency service, under SAMA's rules for Saudi direct participants: a return payment sent by the receiving direct participant for a payment it received through AFAQ and could not credit (OR 7.8), in the exchange period that accepts returns (OR 5.1 item 6)." }, "caveat": "The ISO wording SAMA copied names a SEPA term; that is a leftover of ISO's shared code set, not an AFAQ rule. SAMA's explanation is ISO's own definition of this code (ISO 20022 ExternalReturnReason1Code, 2Q2026). This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "related": [ "gcc-afaq-return:NOOR", "gcc-afaq-return:AM05" ], "basis": { "sources": "SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service (2021-05-05, 24/9/1442 H, In-Force), read in full on rulebook.sama.gov.sa on 2026-09-18: Appendix 2, table of returned payments, entry for ARDT; sections 5.1 item 6, 5.3, 7.3, 7.8, 7.9. SAMA circular 43038107, Charging Policy for Cross Currency Payments Using AFAQ Service (2021-12-02), section 4.2 and Appendix 2. ISO 20022 External Code Sets 2Q2026 (2Q2026_externalcodesets_v3.json, downloaded 2026-09-18), compared by script. SAMA gives one line per code and no usage guidance, so triggers and actions beyond that line are inference.", "confidence": "low" }, "currency": { "effective_since": "2021-05-05", "effective_note": "Date of SAMA circular 42068309 (24/9/1442 H), In-Force when read on 2026-09-18. The portal's Versions block shows date ranges that end before they begin, so no later edition can be read from it. The appendix says returned codes are registered in the AFAQ Central Component dictionary, which may be updated from time to time, so the live list may differ from the published one [Inference].", "source_edition": "SAMA circular 42068309 (2021-05-05), Appendix 2", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://rulebook.sama.gov.sa/en/appendix-2-return-and-rejection-codes", "source_class": "public_primary", "source_title": "Appendix 2 - Return and Rejection Codes (SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-18", "notes": "Appendix 2 of SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service, lists ARDT with the meaning this record states. SAMA's Operating Rules, sections 7.8 and 7.9, confirm the return limits the record gives: an outer limit of 2 business days, counted only on days that both countries work, with an earlier expected deadline; no compensation for holding the funds inside that limit; and refusal by the Central Component of a return that is late, a duplicate, or inconsistent with the original payment. Section 5.1 item 6 confirms the exchange period accepts returns. SAMA's Charging Policy for Cross Currency Payments Using AFAQ Service, circular 43038107, section 4.2, confirms the SAR 100 penalty for a late return." } ] }, "rail_name": "AFAQ Returns (SAMA rules for Saudi participants)", "governing_authority": "Saudi Central Bank (SAMA), for its direct participants; AFAQ is owned by the six GCC central banks and run by the Gulf Payments Company", "snapshot": "2026-09-18", "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "judgement", "label": "your bank's own terms", "needs": "whose terms decide it: the bank's, the participant's or the scheme's", "detail": "This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "from": "caveat" } ] }, { "uid": "gcc-afaq-return:BACL", "id": "BACL", "rail": "gcc-afaq-return", "kind": "reason-code", "name": "Beneficiary account closed", "group": "account", "summary": "An AFAQ code of its own for a beneficiary account that has been closed. It has the same effect as ISO's AC04.", "triggers": [ "The beneficiary's account at the receiving participant no longer exists as an open account [Inference]" ], "actions": [ "Sending participant: tell the payer why the money came back and get beneficiary details that work before sending anything new", "Receiving participant: send back the original amounts at the original exchange rate, in both currencies and with nothing taken off, as one message whose field 72 carries the original payment's reference (OR 7.8, 7.9)", "Receiving participant: expect the Central Component to refuse the return if it differs from the original in amount, currency or rate, repeats a return already accepted, comes too late, or points at an original it cannot find (OR 7.9)" ], "retry": { "allowed": true, "rule": "Yes, as a new payment. A returned payment may not be sent again under its original Unique Message Reference; once the cause is fixed the sending participant may send it as a new payment with a new Unique Message Reference, and may keep the same UETR (OR 7.3). That sentence sits in the paragraph on rejections and is read here as covering returns too [Inference]." }, "facts": { "return_windows": [ { "action": "return the payment with this reason", "by": "Receiving direct participant (a Saudi participant under SAMA's rules)", "deadline": "Best on the business day the payment arrived; if not, by that payment type's cut-off on the next business day; never later than 2 business days after receipt, counting only days that are business days in both the sending and the receiving country (OR 7.8, 7.9, 5.3). Inside that time no compensation for use of the funds is owed (OR 7.8). The Central Component refuses a return after 2 business days (OR 7.9), and SAMA charges SAR 100 per payment message returned late, possibly plus an amount-based charge (CP 4.2, CP Appendix 2)." } ], "applies_to": "AFAQ cross-currency service, under SAMA's rules for Saudi direct participants: a return payment sent by the receiving direct participant for a payment it received through AFAQ and could not credit (OR 7.8), in the exchange period that accepts returns (OR 5.1 item 6)." }, "caveat": "Why SAMA lists both BACL and AC04 is not stated; an agent should treat them alike [Inference]. The code is in no ISO 20022 external code set (2Q2026); it is AFAQ's own. This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "related": [ "gcc-afaq-return:AC04", "gcc-afaq-return:BALC", "gcc-afaq-return:BADE", "gcc-afaq-return:ADRM" ], "basis": { "sources": "SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service (2021-05-05, 24/9/1442 H, In-Force), read in full on rulebook.sama.gov.sa on 2026-09-18: Appendix 2, table of returned payments, entry for BACL; sections 5.1 item 6, 5.3, 7.3, 7.8, 7.9. SAMA circular 43038107, Charging Policy for Cross Currency Payments Using AFAQ Service (2021-12-02), section 4.2 and Appendix 2. ISO 20022 External Code Sets 2Q2026 (2Q2026_externalcodesets_v3.json, downloaded 2026-09-18), compared by script. SAMA gives one line per code and no usage guidance, so triggers and actions beyond that line are inference.", "confidence": "medium" }, "currency": { "effective_since": "2021-05-05", "effective_note": "Date of SAMA circular 42068309 (24/9/1442 H), In-Force when read on 2026-09-18. The portal's Versions block shows date ranges that end before they begin, so no later edition can be read from it. The appendix says returned codes are registered in the AFAQ Central Component dictionary, which may be updated from time to time, so the live list may differ from the published one [Inference].", "source_edition": "SAMA circular 42068309 (2021-05-05), Appendix 2", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://rulebook.sama.gov.sa/en/appendix-2-return-and-rejection-codes", "source_class": "public_primary", "source_title": "Appendix 2 - Return and Rejection Codes (SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-18", "notes": "Appendix 2 of SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service, lists BACL with the meaning this record states. SAMA's Operating Rules, sections 7.8 and 7.9, confirm the return limits the record gives: an outer limit of 2 business days, counted only on days that both countries work, with an earlier expected deadline; no compensation for holding the funds inside that limit; and refusal by the Central Component of a return that is late, a duplicate, or inconsistent with the original payment. Section 5.1 item 6 confirms the exchange period accepts returns. SAMA's Charging Policy for Cross Currency Payments Using AFAQ Service, circular 43038107, section 4.2, confirms the SAR 100 penalty for a late return." } ] }, "rail_name": "AFAQ Returns (SAMA rules for Saudi participants)", "governing_authority": "Saudi Central Bank (SAMA), for its direct participants; AFAQ is owned by the six GCC central banks and run by the Gulf Payments Company", "snapshot": "2026-09-18", "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "judgement", "label": "your bank's own terms", "needs": "whose terms decide it: the bank's, the participant's or the scheme's", "detail": "This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "from": "caveat" } ] }, { "uid": "gcc-afaq-return:BADC", "id": "BADC", "rail": "gcc-afaq-return", "kind": "reason-code", "name": "Beneficiary account in another currency", "group": "account", "summary": "An AFAQ code of its own: the beneficiary's account is held in a currency other than the one the payment arrives in. AFAQ always pays the receiving bank in its own country's currency (OR 1, cross-currency payment), so an account in any other currency cannot take it as sent [Inference].", "triggers": [ "The beneficiary gave a foreign currency account, for example a US dollar account, at a receiving bank that gets the payment in its local currency [Inference]" ], "actions": [ "Sending participant: tell the payer why the money came back and get beneficiary details that work before sending anything new", "Payer: ask the beneficiary for an account in the receiving country's currency [Inference]", "Receiving participant: send back the original amounts at the original exchange rate, in both currencies and with nothing taken off, as one message whose field 72 carries the original payment's reference (OR 7.8, 7.9)", "Receiving participant: expect the Central Component to refuse the return if it differs from the original in amount, currency or rate, repeats a return already accepted, comes too late, or points at an original it cannot find (OR 7.9)" ], "retry": { "allowed": true, "rule": "Yes, as a new payment. A returned payment may not be sent again under its original Unique Message Reference; once the cause is fixed the sending participant may send it as a new payment with a new Unique Message Reference, and may keep the same UETR (OR 7.3). That sentence sits in the paragraph on rejections and is read here as covering returns too [Inference]." }, "facts": { "return_windows": [ { "action": "return the payment with this reason", "by": "Receiving direct participant (a Saudi participant under SAMA's rules)", "deadline": "Best on the business day the payment arrived; if not, by that payment type's cut-off on the next business day; never later than 2 business days after receipt, counting only days that are business days in both the sending and the receiving country (OR 7.8, 7.9, 5.3). Inside that time no compensation for use of the funds is owed (OR 7.8). The Central Component refuses a return after 2 business days (OR 7.9), and SAMA charges SAR 100 per payment message returned late, possibly plus an amount-based charge (CP 4.2, CP Appendix 2)." } ], "applies_to": "AFAQ cross-currency service, under SAMA's rules for Saudi direct participants: a return payment sent by the receiving direct participant for a payment it received through AFAQ and could not credit (OR 7.8), in the exchange period that accepts returns (OR 5.1 item 6)." }, "caveat": "The code is in no ISO 20022 external code set (2Q2026); it is AFAQ's own. This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "related": [ "gcc-afaq-return:CURR", "gcc-afaq-return:AM03" ], "basis": { "sources": "SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service (2021-05-05, 24/9/1442 H, In-Force), read in full on rulebook.sama.gov.sa on 2026-09-18: Appendix 2, table of returned payments, entry for BADC; sections 5.1 item 6, 5.3, 7.3, 7.8, 7.9, 1 (definition of cross-currency payment). SAMA circular 43038107, Charging Policy for Cross Currency Payments Using AFAQ Service (2021-12-02), section 4.2 and Appendix 2. ISO 20022 External Code Sets 2Q2026 (2Q2026_externalcodesets_v3.json, downloaded 2026-09-18), compared by script. SAMA gives one line per code and no usage guidance, so triggers and actions beyond that line are inference.", "confidence": "medium" }, "currency": { "effective_since": "2021-05-05", "effective_note": "Date of SAMA circular 42068309 (24/9/1442 H), In-Force when read on 2026-09-18. The portal's Versions block shows date ranges that end before they begin, so no later edition can be read from it. The appendix says returned codes are registered in the AFAQ Central Component dictionary, which may be updated from time to time, so the live list may differ from the published one [Inference].", "source_edition": "SAMA circular 42068309 (2021-05-05), Appendix 2", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://rulebook.sama.gov.sa/en/appendix-2-return-and-rejection-codes", "source_class": "public_primary", "source_title": "Appendix 2 - Return and Rejection Codes (SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-18", "notes": "Appendix 2 of SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service, lists BADC with the meaning this record states. SAMA's Operating Rules, sections 7.8 and 7.9, confirm the return limits the record gives: an outer limit of 2 business days, counted only on days that both countries work, with an earlier expected deadline; no compensation for holding the funds inside that limit; and refusal by the Central Component of a return that is late, a duplicate, or inconsistent with the original payment. Section 5.1 item 6 confirms the exchange period accepts returns. SAMA's Charging Policy for Cross Currency Payments Using AFAQ Service, circular 43038107, section 4.2, confirms the SAR 100 penalty for a late return." } ] }, "rail_name": "AFAQ Returns (SAMA rules for Saudi participants)", "governing_authority": "Saudi Central Bank (SAMA), for its direct participants; AFAQ is owned by the six GCC central banks and run by the Gulf Payments Company", "snapshot": "2026-09-18", "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "judgement", "label": "your bank's own terms", "needs": "whose terms decide it: the bank's, the participant's or the scheme's", "detail": "This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "from": "caveat" } ] }, { "uid": "gcc-afaq-return:BADE", "id": "BADE", "rail": "gcc-afaq-return", "kind": "reason-code", "name": "No such beneficiary account", "group": "account", "summary": "An AFAQ code of its own: the account number on the payment matches no account at the receiving participant.", "triggers": [ "The number is well formed but no such account is on the receiving bank's books [Inference]" ], "actions": [ "Sending participant: tell the payer why the money came back and get beneficiary details that work before sending anything new", "Receiving participant: send back the original amounts at the original exchange rate, in both currencies and with nothing taken off, as one message whose field 72 carries the original payment's reference (OR 7.8, 7.9)", "Receiving participant: expect the Central Component to refuse the return if it differs from the original in amount, currency or rate, repeats a return already accepted, comes too late, or points at an original it cannot find (OR 7.9)" ], "retry": { "allowed": true, "rule": "Yes, as a new payment. A returned payment may not be sent again under its original Unique Message Reference; once the cause is fixed the sending participant may send it as a new payment with a new Unique Message Reference, and may keep the same UETR (OR 7.3). That sentence sits in the paragraph on rejections and is read here as covering returns too [Inference]." }, "facts": { "return_windows": [ { "action": "return the payment with this reason", "by": "Receiving direct participant (a Saudi participant under SAMA's rules)", "deadline": "Best on the business day the payment arrived; if not, by that payment type's cut-off on the next business day; never later than 2 business days after receipt, counting only days that are business days in both the sending and the receiving country (OR 7.8, 7.9, 5.3). Inside that time no compensation for use of the funds is owed (OR 7.8). The Central Component refuses a return after 2 business days (OR 7.9), and SAMA charges SAR 100 per payment message returned late, possibly plus an amount-based charge (CP 4.2, CP Appendix 2)." } ], "applies_to": "AFAQ cross-currency service, under SAMA's rules for Saudi direct participants: a return payment sent by the receiving direct participant for a payment it received through AFAQ and could not credit (OR 7.8), in the exchange period that accepts returns (OR 5.1 item 6)." }, "caveat": "ULBA (account cannot be located) and IBAN (invalid account number) sit close to this code; SAMA does not separate them. The code is in no ISO 20022 external code set (2Q2026); it is AFAQ's own. This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "related": [ "gcc-afaq-return:ULBA", "gcc-afaq-return:IBAN", "gcc-afaq-return:AC01", "gcc-afaq-return:BACL" ], "basis": { "sources": "SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service (2021-05-05, 24/9/1442 H, In-Force), read in full on rulebook.sama.gov.sa on 2026-09-18: Appendix 2, table of returned payments, entry for BADE; sections 5.1 item 6, 5.3, 7.3, 7.8, 7.9. SAMA circular 43038107, Charging Policy for Cross Currency Payments Using AFAQ Service (2021-12-02), section 4.2 and Appendix 2. ISO 20022 External Code Sets 2Q2026 (2Q2026_externalcodesets_v3.json, downloaded 2026-09-18), compared by script. SAMA gives one line per code and no usage guidance, so triggers and actions beyond that line are inference.", "confidence": "medium" }, "currency": { "effective_since": "2021-05-05", "effective_note": "Date of SAMA circular 42068309 (24/9/1442 H), In-Force when read on 2026-09-18. The portal's Versions block shows date ranges that end before they begin, so no later edition can be read from it. The appendix says returned codes are registered in the AFAQ Central Component dictionary, which may be updated from time to time, so the live list may differ from the published one [Inference].", "source_edition": "SAMA circular 42068309 (2021-05-05), Appendix 2", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://rulebook.sama.gov.sa/en/appendix-2-return-and-rejection-codes", "source_class": "public_primary", "source_title": "Appendix 2 - Return and Rejection Codes (SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-18", "notes": "Appendix 2 of SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service, lists BADE with the meaning this record states. SAMA's Operating Rules, sections 7.8 and 7.9, confirm the return limits the record gives: an outer limit of 2 business days, counted only on days that both countries work, with an earlier expected deadline; no compensation for holding the funds inside that limit; and refusal by the Central Component of a return that is late, a duplicate, or inconsistent with the original payment. Section 5.1 item 6 confirms the exchange period accepts returns. SAMA's Charging Policy for Cross Currency Payments Using AFAQ Service, circular 43038107, section 4.2, confirms the SAR 100 penalty for a late return." } ] }, "rail_name": "AFAQ Returns (SAMA rules for Saudi participants)", "governing_authority": "Saudi Central Bank (SAMA), for its direct participants; AFAQ is owned by the six GCC central banks and run by the Gulf Payments Company", "snapshot": "2026-09-18", "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "judgement", "label": "your bank's own terms", "needs": "whose terms decide it: the bank's, the participant's or the scheme's", "detail": "This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "from": "caveat" } ] }, { "uid": "gcc-afaq-return:BALC", "id": "BALC", "rail": "gcc-afaq-return", "kind": "reason-code", "name": "Beneficiary account blocked", "group": "account", "summary": "An AFAQ code of its own for a beneficiary account that is blocked, with the same effect as ISO's AC06.", "triggers": [ "The account is frozen and will not take the credit [Inference]" ], "actions": [ "Sending participant: tell the payer why the money came back and get beneficiary details that work before sending anything new", "Beneficiary: resolve the block with its bank or give another account [Inference]", "Receiving participant: send back the original amounts at the original exchange rate, in both currencies and with nothing taken off, as one message whose field 72 carries the original payment's reference (OR 7.8, 7.9)", "Receiving participant: expect the Central Component to refuse the return if it differs from the original in amount, currency or rate, repeats a return already accepted, comes too late, or points at an original it cannot find (OR 7.9)" ], "retry": { "allowed": true, "rule": "Yes, as a new payment. A returned payment may not be sent again under its original Unique Message Reference; once the cause is fixed the sending participant may send it as a new payment with a new Unique Message Reference, and may keep the same UETR (OR 7.3). That sentence sits in the paragraph on rejections and is read here as covering returns too [Inference]. A new payment makes sense only to another account or once the block is lifted [Inference]." }, "facts": { "return_windows": [ { "action": "return the payment with this reason", "by": "Receiving direct participant (a Saudi participant under SAMA's rules)", "deadline": "Best on the business day the payment arrived; if not, by that payment type's cut-off on the next business day; never later than 2 business days after receipt, counting only days that are business days in both the sending and the receiving country (OR 7.8, 7.9, 5.3). Inside that time no compensation for use of the funds is owed (OR 7.8). The Central Component refuses a return after 2 business days (OR 7.9), and SAMA charges SAR 100 per payment message returned late, possibly plus an amount-based charge (CP 4.2, CP Appendix 2)." } ], "applies_to": "AFAQ cross-currency service, under SAMA's rules for Saudi direct participants: a return payment sent by the receiving direct participant for a payment it received through AFAQ and could not credit (OR 7.8), in the exchange period that accepts returns (OR 5.1 item 6)." }, "caveat": "Why SAMA lists both BALC and AC06 is not stated; an agent should treat them alike [Inference]. The code is in no ISO 20022 external code set (2Q2026); it is AFAQ's own. This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "related": [ "gcc-afaq-return:AC06", "gcc-afaq-return:BACL", "gcc-afaq-return:ADRM" ], "basis": { "sources": "SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service (2021-05-05, 24/9/1442 H, In-Force), read in full on rulebook.sama.gov.sa on 2026-09-18: Appendix 2, table of returned payments, entry for BALC; sections 5.1 item 6, 5.3, 7.3, 7.8, 7.9. SAMA circular 43038107, Charging Policy for Cross Currency Payments Using AFAQ Service (2021-12-02), section 4.2 and Appendix 2. ISO 20022 External Code Sets 2Q2026 (2Q2026_externalcodesets_v3.json, downloaded 2026-09-18), compared by script. SAMA gives one line per code and no usage guidance, so triggers and actions beyond that line are inference.", "confidence": "medium" }, "currency": { "effective_since": "2021-05-05", "effective_note": "Date of SAMA circular 42068309 (24/9/1442 H), In-Force when read on 2026-09-18. The portal's Versions block shows date ranges that end before they begin, so no later edition can be read from it. The appendix says returned codes are registered in the AFAQ Central Component dictionary, which may be updated from time to time, so the live list may differ from the published one [Inference].", "source_edition": "SAMA circular 42068309 (2021-05-05), Appendix 2", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://rulebook.sama.gov.sa/en/appendix-2-return-and-rejection-codes", "source_class": "public_primary", "source_title": "Appendix 2 - Return and Rejection Codes (SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-18", "notes": "Appendix 2 of SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service, lists BALC with the meaning this record states. SAMA's Operating Rules, sections 7.8 and 7.9, confirm the return limits the record gives: an outer limit of 2 business days, counted only on days that both countries work, with an earlier expected deadline; no compensation for holding the funds inside that limit; and refusal by the Central Component of a return that is late, a duplicate, or inconsistent with the original payment. Section 5.1 item 6 confirms the exchange period accepts returns. SAMA's Charging Policy for Cross Currency Payments Using AFAQ Service, circular 43038107, section 4.2, confirms the SAR 100 penalty for a late return." } ] }, "rail_name": "AFAQ Returns (SAMA rules for Saudi participants)", "governing_authority": "Saudi Central Bank (SAMA), for its direct participants; AFAQ is owned by the six GCC central banks and run by the Gulf Payments Company", "snapshot": "2026-09-18", "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "judgement", "label": "your bank's own terms", "needs": "whose terms decide it: the bank's, the participant's or the scheme's", "detail": "This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "from": "caveat" } ] }, { "uid": "gcc-afaq-return:BDIN", "id": "BDIN", "rail": "gcc-afaq-return", "kind": "reason-code", "name": "Beneficiary name and account number disagree", "group": "account", "summary": "An AFAQ code of its own: the beneficiary's name on the payment does not belong to the account number given. The receiving participant credits only where the account is right for the named beneficiary (OR 7.6, 7.7), so it returns the payment.", "triggers": [ "The account number is valid but held by someone other than the person or firm named on the payment [Inference]" ], "actions": [ "Sending participant: tell the payer why the money came back and get beneficiary details that work before sending anything new", "Sending participant: check both the name and the account number with the payer before a new payment", "Receiving participant: send back the original amounts at the original exchange rate, in both currencies and with nothing taken off, as one message whose field 72 carries the original payment's reference (OR 7.8, 7.9)", "Receiving participant: expect the Central Component to refuse the return if it differs from the original in amount, currency or rate, repeats a return already accepted, comes too late, or points at an original it cannot find (OR 7.9)" ], "retry": { "allowed": true, "rule": "Yes, as a new payment. A returned payment may not be sent again under its original Unique Message Reference; once the cause is fixed the sending participant may send it as a new payment with a new Unique Message Reference, and may keep the same UETR (OR 7.3). That sentence sits in the paragraph on rejections and is read here as covering returns too [Inference]." }, "facts": { "return_windows": [ { "action": "return the payment with this reason", "by": "Receiving direct participant (a Saudi participant under SAMA's rules)", "deadline": "Best on the business day the payment arrived; if not, by that payment type's cut-off on the next business day; never later than 2 business days after receipt, counting only days that are business days in both the sending and the receiving country (OR 7.8, 7.9, 5.3). Inside that time no compensation for use of the funds is owed (OR 7.8). The Central Component refuses a return after 2 business days (OR 7.9), and SAMA charges SAR 100 per payment message returned late, possibly plus an amount-based charge (CP 4.2, CP Appendix 2)." } ], "applies_to": "AFAQ cross-currency service, under SAMA's rules for Saudi direct participants: a return payment sent by the receiving direct participant for a payment it received through AFAQ and could not credit (OR 7.8), in the exchange period that accepts returns (OR 5.1 item 6)." }, "caveat": "BE01 and AC03 describe much the same mismatch in ISO terms; no rule chooses between them. The code is in no ISO 20022 external code set (2Q2026); it is AFAQ's own. This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "related": [ "gcc-afaq-return:BE01", "gcc-afaq-return:AC03", "gcc-afaq-return:IBAN" ], "basis": { "sources": "SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service (2021-05-05, 24/9/1442 H, In-Force), read in full on rulebook.sama.gov.sa on 2026-09-18: Appendix 2, table of returned payments, entry for BDIN; sections 5.1 item 6, 5.3, 7.3, 7.8, 7.9, 7.6, 7.7. SAMA circular 43038107, Charging Policy for Cross Currency Payments Using AFAQ Service (2021-12-02), section 4.2 and Appendix 2. ISO 20022 External Code Sets 2Q2026 (2Q2026_externalcodesets_v3.json, downloaded 2026-09-18), compared by script. SAMA gives one line per code and no usage guidance, so triggers and actions beyond that line are inference.", "confidence": "medium" }, "currency": { "effective_since": "2021-05-05", "effective_note": "Date of SAMA circular 42068309 (24/9/1442 H), In-Force when read on 2026-09-18. The portal's Versions block shows date ranges that end before they begin, so no later edition can be read from it. The appendix says returned codes are registered in the AFAQ Central Component dictionary, which may be updated from time to time, so the live list may differ from the published one [Inference].", "source_edition": "SAMA circular 42068309 (2021-05-05), Appendix 2", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://rulebook.sama.gov.sa/en/appendix-2-return-and-rejection-codes", "source_class": "public_primary", "source_title": "Appendix 2 - Return and Rejection Codes (SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-18", "notes": "Appendix 2 of SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service, lists BDIN with the meaning this record states. SAMA's Operating Rules, sections 7.8 and 7.9, confirm the return limits the record gives: an outer limit of 2 business days, counted only on days that both countries work, with an earlier expected deadline; no compensation for holding the funds inside that limit; and refusal by the Central Component of a return that is late, a duplicate, or inconsistent with the original payment. Section 5.1 item 6 confirms the exchange period accepts returns. SAMA's Charging Policy for Cross Currency Payments Using AFAQ Service, circular 43038107, section 4.2, confirms the SAR 100 penalty for a late return. Sections 7.6 and 7.7 confirm the rule that the receiving participant credits only the correctly named beneficiary." } ] }, "rail_name": "AFAQ Returns (SAMA rules for Saudi participants)", "governing_authority": "Saudi Central Bank (SAMA), for its direct participants; AFAQ is owned by the six GCC central banks and run by the Gulf Payments Company", "snapshot": "2026-09-18", "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "judgement", "label": "your bank's own terms", "needs": "whose terms decide it: the bank's, the participant's or the scheme's", "detail": "This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "from": "caveat" } ] }, { "uid": "gcc-afaq-return:BE01", "id": "BE01", "rail": "gcc-afaq-return", "kind": "reason-code", "name": "Customer identity does not fit the account", "group": "account", "summary": "Who the payment says the beneficiary is does not fit the account number given, so the receiving participant does not credit it (OR 7.6, 7.7).", "triggers": [ "The name or identifier of the beneficiary does not match the holder of the account [Inference]" ], "actions": [ "Sending participant: tell the payer why the money came back and get beneficiary details that work before sending anything new", "Receiving participant: send back the original amounts at the original exchange rate, in both currencies and with nothing taken off, as one message whose field 72 carries the original payment's reference (OR 7.8, 7.9)", "Receiving participant: expect the Central Component to refuse the return if it differs from the original in amount, currency or rate, repeats a return already accepted, comes too late, or points at an original it cannot find (OR 7.9)" ], "retry": { "allowed": true, "rule": "Yes, as a new payment. A returned payment may not be sent again under its original Unique Message Reference; once the cause is fixed the sending participant may send it as a new payment with a new Unique Message Reference, and may keep the same UETR (OR 7.3). That sentence sits in the paragraph on rejections and is read here as covering returns too [Inference]." }, "facts": { "return_windows": [ { "action": "return the payment with this reason", "by": "Receiving direct participant (a Saudi participant under SAMA's rules)", "deadline": "Best on the business day the payment arrived; if not, by that payment type's cut-off on the next business day; never later than 2 business days after receipt, counting only days that are business days in both the sending and the receiving country (OR 7.8, 7.9, 5.3). Inside that time no compensation for use of the funds is owed (OR 7.8). The Central Component refuses a return after 2 business days (OR 7.9), and SAMA charges SAR 100 per payment message returned late, possibly plus an amount-based charge (CP 4.2, CP Appendix 2)." } ], "applies_to": "AFAQ cross-currency service, under SAMA's rules for Saudi direct participants: a return payment sent by the receiving direct participant for a payment it received through AFAQ and could not credit (OR 7.8), in the exchange period that accepts returns (OR 5.1 item 6)." }, "caveat": "SAMA carries an older ISO wording, which notes the code was once called Creditor Consistency; ISO's 2Q2026 definition also mentions an organisation or private identifier. BDIN is AFAQ's own code for a name and account mismatch. SAMA's explanation is an earlier form of ISO's definition, not the 2Q2026 text (ISO 20022 ExternalReturnReason1Code, 2Q2026). This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "related": [ "gcc-afaq-return:BDIN", "gcc-afaq-return:AC03", "gcc-afaq-return:BE06" ], "basis": { "sources": "SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service (2021-05-05, 24/9/1442 H, In-Force), read in full on rulebook.sama.gov.sa on 2026-09-18: Appendix 2, table of returned payments, entry for BE01; sections 5.1 item 6, 5.3, 7.3, 7.8, 7.9, 7.6, 7.7. SAMA circular 43038107, Charging Policy for Cross Currency Payments Using AFAQ Service (2021-12-02), section 4.2 and Appendix 2. ISO 20022 External Code Sets 2Q2026 (2Q2026_externalcodesets_v3.json, downloaded 2026-09-18), compared by script. SAMA gives one line per code and no usage guidance, so triggers and actions beyond that line are inference.", "confidence": "medium" }, "currency": { "effective_since": "2021-05-05", "effective_note": "Date of SAMA circular 42068309 (24/9/1442 H), In-Force when read on 2026-09-18. The portal's Versions block shows date ranges that end before they begin, so no later edition can be read from it. The appendix says returned codes are registered in the AFAQ Central Component dictionary, which may be updated from time to time, so the live list may differ from the published one [Inference].", "source_edition": "SAMA circular 42068309 (2021-05-05), Appendix 2", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://rulebook.sama.gov.sa/en/appendix-2-return-and-rejection-codes", "source_class": "public_primary", "source_title": "Appendix 2 - Return and Rejection Codes (SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-18", "notes": "Appendix 2 of SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service, lists BE01 with the meaning this record states. SAMA's Operating Rules, sections 7.8 and 7.9, confirm the return limits the record gives: an outer limit of 2 business days, counted only on days that both countries work, with an earlier expected deadline; no compensation for holding the funds inside that limit; and refusal by the Central Component of a return that is late, a duplicate, or inconsistent with the original payment. Section 5.1 item 6 confirms the exchange period accepts returns. SAMA's Charging Policy for Cross Currency Payments Using AFAQ Service, circular 43038107, section 4.2, confirms the SAR 100 penalty for a late return. Sections 7.6 and 7.7 confirm the same rule that credit is due only to the right, correctly identified beneficiary." } ] }, "rail_name": "AFAQ Returns (SAMA rules for Saudi participants)", "governing_authority": "Saudi Central Bank (SAMA), for its direct participants; AFAQ is owned by the six GCC central banks and run by the Gulf Payments Company", "snapshot": "2026-09-18", "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "judgement", "label": "your bank's own terms", "needs": "whose terms decide it: the bank's, the participant's or the scheme's", "detail": "This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "from": "caveat" } ] }, { "uid": "gcc-afaq-return:BE04", "id": "BE04", "rail": "gcc-afaq-return", "kind": "reason-code", "name": "Beneficiary address missing or wrong", "group": "administrative", "summary": "Returned because the payment has no usable address for the beneficiary (creditor), and this payment requires one. ISO notes the code was once called Incorrect Creditor Address.", "triggers": [ "The receiving side needs the beneficiary's address, for example for its own compliance checks, and the payment lacks a usable one [Inference]" ], "actions": [ "Sending participant: add the beneficiary's full address and send a new payment", "Receiving participant: send back the original amounts at the original exchange rate, in both currencies and with nothing taken off, as one message whose field 72 carries the original payment's reference (OR 7.8, 7.9)", "Receiving participant: expect the Central Component to refuse the return if it differs from the original in amount, currency or rate, repeats a return already accepted, comes too late, or points at an original it cannot find (OR 7.9)" ], "retry": { "allowed": true, "rule": "Yes, as a new payment. A returned payment may not be sent again under its original Unique Message Reference; once the cause is fixed the sending participant may send it as a new payment with a new Unique Message Reference, and may keep the same UETR (OR 7.3). That sentence sits in the paragraph on rejections and is read here as covering returns too [Inference]." }, "facts": { "return_windows": [ { "action": "return the payment with this reason", "by": "Receiving direct participant (a Saudi participant under SAMA's rules)", "deadline": "Best on the business day the payment arrived; if not, by that payment type's cut-off on the next business day; never later than 2 business days after receipt, counting only days that are business days in both the sending and the receiving country (OR 7.8, 7.9, 5.3). Inside that time no compensation for use of the funds is owed (OR 7.8). The Central Component refuses a return after 2 business days (OR 7.9), and SAMA charges SAR 100 per payment message returned late, possibly plus an amount-based charge (CP 4.2, CP Appendix 2)." } ], "applies_to": "AFAQ cross-currency service, under SAMA's rules for Saudi direct participants: a return payment sent by the receiving direct participant for a payment it received through AFAQ and could not credit (OR 7.8), in the exchange period that accepts returns (OR 5.1 item 6)." }, "caveat": "SAMA's explanation matches ISO's definition of this code apart from spelling (ISO 20022 ExternalReturnReason1Code, 2Q2026). This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "related": [ "gcc-afaq-return:RR03", "gcc-afaq-return:BE07", "sepa-sct:BE04" ], "basis": { "sources": "SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service (2021-05-05, 24/9/1442 H, In-Force), read in full on rulebook.sama.gov.sa on 2026-09-18: Appendix 2, table of returned payments, entry for BE04; sections 5.1 item 6, 5.3, 7.3, 7.8, 7.9. SAMA circular 43038107, Charging Policy for Cross Currency Payments Using AFAQ Service (2021-12-02), section 4.2 and Appendix 2. ISO 20022 External Code Sets 2Q2026 (2Q2026_externalcodesets_v3.json, downloaded 2026-09-18), compared by script. SAMA gives one line per code and no usage guidance, so triggers and actions beyond that line are inference.", "confidence": "medium" }, "currency": { "effective_since": "2021-05-05", "effective_note": "Date of SAMA circular 42068309 (24/9/1442 H), In-Force when read on 2026-09-18. The portal's Versions block shows date ranges that end before they begin, so no later edition can be read from it. The appendix says returned codes are registered in the AFAQ Central Component dictionary, which may be updated from time to time, so the live list may differ from the published one [Inference].", "source_edition": "SAMA circular 42068309 (2021-05-05), Appendix 2", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://rulebook.sama.gov.sa/en/appendix-2-return-and-rejection-codes", "source_class": "public_primary", "source_title": "Appendix 2 - Return and Rejection Codes (SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-18", "notes": "Appendix 2 of SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service, lists BE04 with the meaning this record states. SAMA's Operating Rules, sections 7.8 and 7.9, confirm the return limits the record gives: an outer limit of 2 business days, counted only on days that both countries work, with an earlier expected deadline; no compensation for holding the funds inside that limit; and refusal by the Central Component of a return that is late, a duplicate, or inconsistent with the original payment. Section 5.1 item 6 confirms the exchange period accepts returns. SAMA's Charging Policy for Cross Currency Payments Using AFAQ Service, circular 43038107, section 4.2, confirms the SAR 100 penalty for a late return." } ] }, "rail_name": "AFAQ Returns (SAMA rules for Saudi participants)", "governing_authority": "Saudi Central Bank (SAMA), for its direct participants; AFAQ is owned by the six GCC central banks and run by the Gulf Payments Company", "snapshot": "2026-09-18", "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "judgement", "label": "your bank's own terms", "needs": "whose terms decide it: the bank's, the participant's or the scheme's", "detail": "This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "from": "caveat" } ] }, { "uid": "gcc-afaq-return:BE05", "id": "BE05", "rail": "gcc-afaq-return", "kind": "reason-code", "name": "Payer not recognised by the beneficiary", "group": "authorization", "summary": "The customer at the receiving end does not know who sent this payment. On an AFAQ credit that customer is the beneficiary and the party is the payer, so read it as the beneficiary not knowing who is paying it [Inference].", "triggers": [ "The beneficiary tells its bank it does not know the payer and will not accept the money [Inference]" ], "actions": [ "Sending participant: tell the payer, who should confirm the beneficiary before paying again [Inference]", "Receiving participant: send back the original amounts at the original exchange rate, in both currencies and with nothing taken off, as one message whose field 72 carries the original payment's reference (OR 7.8, 7.9)", "Receiving participant: expect the Central Component to refuse the return if it differs from the original in amount, currency or rate, repeats a return already accepted, comes too late, or points at an original it cannot find (OR 7.9)" ], "retry": { "allowed": false, "rule": "Not unless the payer confirms the beneficiary and the beneficiary accepts the payment [Inference]." }, "facts": { "return_windows": [ { "action": "return the payment with this reason", "by": "Receiving direct participant (a Saudi participant under SAMA's rules)", "deadline": "Best on the business day the payment arrived; if not, by that payment type's cut-off on the next business day; never later than 2 business days after receipt, counting only days that are business days in both the sending and the receiving country (OR 7.8, 7.9, 5.3). Inside that time no compensation for use of the funds is owed (OR 7.8). The Central Component refuses a return after 2 business days (OR 7.9), and SAMA charges SAR 100 per payment message returned late, possibly plus an amount-based charge (CP 4.2, CP Appendix 2)." } ], "applies_to": "AFAQ cross-currency service, under SAMA's rules for Saudi direct participants: a return payment sent by the receiving direct participant for a payment it received through AFAQ and could not credit (OR 7.8), in the exchange period that accepts returns (OR 5.1 item 6)." }, "caveat": "SAMA's explanation matches ISO's definition of this code apart from spelling (ISO 20022 ExternalReturnReason1Code, 2Q2026). This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "related": [ "gcc-afaq-return:MS02", "gcc-afaq-return:UPAY", "gcc-afaq-return:BDIN" ], "basis": { "sources": "SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service (2021-05-05, 24/9/1442 H, In-Force), read in full on rulebook.sama.gov.sa on 2026-09-18: Appendix 2, table of returned payments, entry for BE05; sections 5.1 item 6, 5.3, 7.3, 7.8, 7.9. SAMA circular 43038107, Charging Policy for Cross Currency Payments Using AFAQ Service (2021-12-02), section 4.2 and Appendix 2. ISO 20022 External Code Sets 2Q2026 (2Q2026_externalcodesets_v3.json, downloaded 2026-09-18), compared by script. SAMA gives one line per code and no usage guidance, so triggers and actions beyond that line are inference.", "confidence": "medium" }, "currency": { "effective_since": "2021-05-05", "effective_note": "Date of SAMA circular 42068309 (24/9/1442 H), In-Force when read on 2026-09-18. The portal's Versions block shows date ranges that end before they begin, so no later edition can be read from it. The appendix says returned codes are registered in the AFAQ Central Component dictionary, which may be updated from time to time, so the live list may differ from the published one [Inference].", "source_edition": "SAMA circular 42068309 (2021-05-05), Appendix 2", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://rulebook.sama.gov.sa/en/appendix-2-return-and-rejection-codes", "source_class": "public_primary", "source_title": "Appendix 2 - Return and Rejection Codes (SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-18", "notes": "Appendix 2 of SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service, lists BE05 with the meaning this record states. SAMA's Operating Rules, sections 7.8 and 7.9, confirm the return limits the record gives: an outer limit of 2 business days, counted only on days that both countries work, with an earlier expected deadline; no compensation for holding the funds inside that limit; and refusal by the Central Component of a return that is late, a duplicate, or inconsistent with the original payment. Section 5.1 item 6 confirms the exchange period accepts returns. SAMA's Charging Policy for Cross Currency Payments Using AFAQ Service, circular 43038107, section 4.2, confirms the SAR 100 penalty for a late return." } ] }, "rail_name": "AFAQ Returns (SAMA rules for Saudi participants)", "governing_authority": "Saudi Central Bank (SAMA), for its direct participants; AFAQ is owned by the six GCC central banks and run by the Gulf Payments Company", "snapshot": "2026-09-18", "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "judgement", "label": "your bank's own terms", "needs": "whose terms decide it: the bank's, the participant's or the scheme's", "detail": "This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "from": "caveat" } ] }, { "uid": "gcc-afaq-return:BE06", "id": "BE06", "rail": "gcc-afaq-return", "kind": "reason-code", "name": "Beneficiary unknown at the receiving bank", "group": "account", "summary": "The receiving participant does not know the beneficiary, or the beneficiary is no longer its customer, so the payment comes back. SAMA copied ISO's wording, which ties the bank to a sort code or national bank code; AFAQ identifies banks by BIC, so read it as unknown at the receiving participant [Inference].", "triggers": [ "The beneficiary has no relationship, or no longer has one, with the receiving participant [Inference]" ], "actions": [ "Sending participant: tell the payer why the money came back and get beneficiary details that work before sending anything new", "Receiving participant: send back the original amounts at the original exchange rate, in both currencies and with nothing taken off, as one message whose field 72 carries the original payment's reference (OR 7.8, 7.9)", "Receiving participant: expect the Central Component to refuse the return if it differs from the original in amount, currency or rate, repeats a return already accepted, comes too late, or points at an original it cannot find (OR 7.9)" ], "retry": { "allowed": true, "rule": "Yes, as a new payment. A returned payment may not be sent again under its original Unique Message Reference; once the cause is fixed the sending participant may send it as a new payment with a new Unique Message Reference, and may keep the same UETR (OR 7.3). That sentence sits in the paragraph on rejections and is read here as covering returns too [Inference]." }, "facts": { "return_windows": [ { "action": "return the payment with this reason", "by": "Receiving direct participant (a Saudi participant under SAMA's rules)", "deadline": "Best on the business day the payment arrived; if not, by that payment type's cut-off on the next business day; never later than 2 business days after receipt, counting only days that are business days in both the sending and the receiving country (OR 7.8, 7.9, 5.3). Inside that time no compensation for use of the funds is owed (OR 7.8). The Central Component refuses a return after 2 business days (OR 7.9), and SAMA charges SAR 100 per payment message returned late, possibly plus an amount-based charge (CP 4.2, CP Appendix 2)." } ], "applies_to": "AFAQ cross-currency service, under SAMA's rules for Saudi direct participants: a return payment sent by the receiving direct participant for a payment it received through AFAQ and could not credit (OR 7.8), in the exchange period that accepts returns (OR 5.1 item 6)." }, "caveat": "SAMA's explanation is ISO's own definition of this code (ISO 20022 ExternalReturnReason1Code, 2Q2026). This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "related": [ "gcc-afaq-return:BADE", "gcc-afaq-return:ULBA", "gcc-afaq-return:BE01" ], "basis": { "sources": "SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service (2021-05-05, 24/9/1442 H, In-Force), read in full on rulebook.sama.gov.sa on 2026-09-18: Appendix 2, table of returned payments, entry for BE06; sections 5.1 item 6, 5.3, 7.3, 7.8, 7.9. SAMA circular 43038107, Charging Policy for Cross Currency Payments Using AFAQ Service (2021-12-02), section 4.2 and Appendix 2. ISO 20022 External Code Sets 2Q2026 (2Q2026_externalcodesets_v3.json, downloaded 2026-09-18), compared by script. SAMA gives one line per code and no usage guidance, so triggers and actions beyond that line are inference.", "confidence": "medium" }, "currency": { "effective_since": "2021-05-05", "effective_note": "Date of SAMA circular 42068309 (24/9/1442 H), In-Force when read on 2026-09-18. The portal's Versions block shows date ranges that end before they begin, so no later edition can be read from it. The appendix says returned codes are registered in the AFAQ Central Component dictionary, which may be updated from time to time, so the live list may differ from the published one [Inference].", "source_edition": "SAMA circular 42068309 (2021-05-05), Appendix 2", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://rulebook.sama.gov.sa/en/appendix-2-return-and-rejection-codes", "source_class": "public_primary", "source_title": "Appendix 2 - Return and Rejection Codes (SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-18", "notes": "Appendix 2 of SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service, lists BE06 with the meaning this record states. SAMA's Operating Rules, sections 7.8 and 7.9, confirm the return limits the record gives: an outer limit of 2 business days, counted only on days that both countries work, with an earlier expected deadline; no compensation for holding the funds inside that limit; and refusal by the Central Component of a return that is late, a duplicate, or inconsistent with the original payment. Section 5.1 item 6 confirms the exchange period accepts returns. SAMA's Charging Policy for Cross Currency Payments Using AFAQ Service, circular 43038107, section 4.2, confirms the SAR 100 penalty for a late return." } ] }, "rail_name": "AFAQ Returns (SAMA rules for Saudi participants)", "governing_authority": "Saudi Central Bank (SAMA), for its direct participants; AFAQ is owned by the six GCC central banks and run by the Gulf Payments Company", "snapshot": "2026-09-18", "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "judgement", "label": "your bank's own terms", "needs": "whose terms decide it: the bank's, the participant's or the scheme's", "detail": "This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "from": "caveat" } ] }, { "uid": "gcc-afaq-return:BE07", "id": "BE07", "rail": "gcc-afaq-return", "kind": "reason-code", "name": "Payer address missing or wrong", "group": "administrative", "summary": "Returned because the payment has no usable address for the payer (debtor), and this payment requires one.", "triggers": [ "The receiving side needs the payer's address and the payment lacks a usable one [Inference]; participants must meet anti-money laundering and counter terrorist financing law (OR 7.15)" ], "actions": [ "Sending participant: add the payer's full address and send a new payment", "Receiving participant: send back the original amounts at the original exchange rate, in both currencies and with nothing taken off, as one message whose field 72 carries the original payment's reference (OR 7.8, 7.9)", "Receiving participant: expect the Central Component to refuse the return if it differs from the original in amount, currency or rate, repeats a return already accepted, comes too late, or points at an original it cannot find (OR 7.9)" ], "retry": { "allowed": true, "rule": "Yes, as a new payment. A returned payment may not be sent again under its original Unique Message Reference; once the cause is fixed the sending participant may send it as a new payment with a new Unique Message Reference, and may keep the same UETR (OR 7.3). That sentence sits in the paragraph on rejections and is read here as covering returns too [Inference]." }, "facts": { "return_windows": [ { "action": "return the payment with this reason", "by": "Receiving direct participant (a Saudi participant under SAMA's rules)", "deadline": "Best on the business day the payment arrived; if not, by that payment type's cut-off on the next business day; never later than 2 business days after receipt, counting only days that are business days in both the sending and the receiving country (OR 7.8, 7.9, 5.3). Inside that time no compensation for use of the funds is owed (OR 7.8). The Central Component refuses a return after 2 business days (OR 7.9), and SAMA charges SAR 100 per payment message returned late, possibly plus an amount-based charge (CP 4.2, CP Appendix 2)." } ], "applies_to": "AFAQ cross-currency service, under SAMA's rules for Saudi direct participants: a return payment sent by the receiving direct participant for a payment it received through AFAQ and could not credit (OR 7.8), in the exchange period that accepts returns (OR 5.1 item 6)." }, "caveat": "SAMA's explanation is ISO's own definition of this code (ISO 20022 ExternalReturnReason1Code, 2Q2026). This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "related": [ "gcc-afaq-return:RR02", "gcc-afaq-return:BE04" ], "basis": { "sources": "SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service (2021-05-05, 24/9/1442 H, In-Force), read in full on rulebook.sama.gov.sa on 2026-09-18: Appendix 2, table of returned payments, entry for BE07; sections 5.1 item 6, 5.3, 7.3, 7.8, 7.9, 7.15. SAMA circular 43038107, Charging Policy for Cross Currency Payments Using AFAQ Service (2021-12-02), section 4.2 and Appendix 2. ISO 20022 External Code Sets 2Q2026 (2Q2026_externalcodesets_v3.json, downloaded 2026-09-18), compared by script. SAMA gives one line per code and no usage guidance, so triggers and actions beyond that line are inference.", "confidence": "medium" }, "currency": { "effective_since": "2021-05-05", "effective_note": "Date of SAMA circular 42068309 (24/9/1442 H), In-Force when read on 2026-09-18. The portal's Versions block shows date ranges that end before they begin, so no later edition can be read from it. The appendix says returned codes are registered in the AFAQ Central Component dictionary, which may be updated from time to time, so the live list may differ from the published one [Inference].", "source_edition": "SAMA circular 42068309 (2021-05-05), Appendix 2", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://rulebook.sama.gov.sa/en/appendix-2-return-and-rejection-codes", "source_class": "public_primary", "source_title": "Appendix 2 - Return and Rejection Codes (SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-18", "notes": "Appendix 2 of SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service, lists BE07 with the meaning this record states. SAMA's Operating Rules, sections 7.8 and 7.9, confirm the return limits the record gives: an outer limit of 2 business days, counted only on days that both countries work, with an earlier expected deadline; no compensation for holding the funds inside that limit; and refusal by the Central Component of a return that is late, a duplicate, or inconsistent with the original payment. Section 5.1 item 6 confirms the exchange period accepts returns. SAMA's Charging Policy for Cross Currency Payments Using AFAQ Service, circular 43038107, section 4.2, confirms the SAR 100 penalty for a late return." } ] }, "rail_name": "AFAQ Returns (SAMA rules for Saudi participants)", "governing_authority": "Saudi Central Bank (SAMA), for its direct participants; AFAQ is owned by the six GCC central banks and run by the Gulf Payments Company", "snapshot": "2026-09-18", "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "judgement", "label": "your bank's own terms", "needs": "whose terms decide it: the bank's, the participant's or the scheme's", "detail": "This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "from": "caveat" } ] }, { "uid": "gcc-afaq-return:BE08", "id": "BE08", "rail": "gcc-afaq-return", "kind": "reason-code", "name": "Bank error", "group": "administrative", "summary": "A bank's mistake, not the customer's choice, is why this payment goes back.", "triggers": [ "A participant sent or routed the payment in error, and the receiving participant sends it back [Inference]" ], "actions": [ "Sending participant: find the error with the receiving participant and send a correct payment if one is still due [Inference]", "Receiving participant: send back the original amounts at the original exchange rate, in both currencies and with nothing taken off, as one message whose field 72 carries the original payment's reference (OR 7.8, 7.9)", "Receiving participant: expect the Central Component to refuse the return if it differs from the original in amount, currency or rate, repeats a return already accepted, comes too late, or points at an original it cannot find (OR 7.9)" ], "retry": { "allowed": true, "rule": "Yes, as a new payment. A returned payment may not be sent again under its original Unique Message Reference; once the cause is fixed the sending participant may send it as a new payment with a new Unique Message Reference, and may keep the same UETR (OR 7.3). That sentence sits in the paragraph on rejections and is read here as covering returns too [Inference]." }, "facts": { "return_windows": [ { "action": "return the payment with this reason", "by": "Receiving direct participant (a Saudi participant under SAMA's rules)", "deadline": "Best on the business day the payment arrived; if not, by that payment type's cut-off on the next business day; never later than 2 business days after receipt, counting only days that are business days in both the sending and the receiving country (OR 7.8, 7.9, 5.3). Inside that time no compensation for use of the funds is owed (OR 7.8). The Central Component refuses a return after 2 business days (OR 7.9), and SAMA charges SAR 100 per payment message returned late, possibly plus an amount-based charge (CP 4.2, CP Appendix 2)." } ], "applies_to": "AFAQ cross-currency service, under SAMA's rules for Saudi direct participants: a return payment sent by the receiving direct participant for a payment it received through AFAQ and could not credit (OR 7.8), in the exchange period that accepts returns (OR 5.1 item 6)." }, "caveat": "SAMA's explanation is ISO's own definition of this code (ISO 20022 ExternalReturnReason1Code, 2Q2026). This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "related": [ "gcc-afaq-return:DS28", "gcc-afaq-return:UPAY" ], "basis": { "sources": "SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service (2021-05-05, 24/9/1442 H, In-Force), read in full on rulebook.sama.gov.sa on 2026-09-18: Appendix 2, table of returned payments, entry for BE08; sections 5.1 item 6, 5.3, 7.3, 7.8, 7.9. SAMA circular 43038107, Charging Policy for Cross Currency Payments Using AFAQ Service (2021-12-02), section 4.2 and Appendix 2. ISO 20022 External Code Sets 2Q2026 (2Q2026_externalcodesets_v3.json, downloaded 2026-09-18), compared by script. SAMA gives one line per code and no usage guidance, so triggers and actions beyond that line are inference.", "confidence": "medium" }, "currency": { "effective_since": "2021-05-05", "effective_note": "Date of SAMA circular 42068309 (24/9/1442 H), In-Force when read on 2026-09-18. The portal's Versions block shows date ranges that end before they begin, so no later edition can be read from it. The appendix says returned codes are registered in the AFAQ Central Component dictionary, which may be updated from time to time, so the live list may differ from the published one [Inference].", "source_edition": "SAMA circular 42068309 (2021-05-05), Appendix 2", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://rulebook.sama.gov.sa/en/appendix-2-return-and-rejection-codes", "source_class": "public_primary", "source_title": "Appendix 2 - Return and Rejection Codes (SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-18", "notes": "Appendix 2 of SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service, lists BE08 with the meaning this record states. SAMA's Operating Rules, sections 7.8 and 7.9, confirm the return limits the record gives: an outer limit of 2 business days, counted only on days that both countries work, with an earlier expected deadline; no compensation for holding the funds inside that limit; and refusal by the Central Component of a return that is late, a duplicate, or inconsistent with the original payment. Section 5.1 item 6 confirms the exchange period accepts returns. SAMA's Charging Policy for Cross Currency Payments Using AFAQ Service, circular 43038107, section 4.2, confirms the SAR 100 penalty for a late return." } ] }, "rail_name": "AFAQ Returns (SAMA rules for Saudi participants)", "governing_authority": "Saudi Central Bank (SAMA), for its direct participants; AFAQ is owned by the six GCC central banks and run by the Gulf Payments Company", "snapshot": "2026-09-18", "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "judgement", "label": "your bank's own terms", "needs": "whose terms decide it: the bank's, the participant's or the scheme's", "detail": "This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "from": "caveat" } ] }, { "uid": "gcc-afaq-return:CN01", "id": "CN01", "rail": "gcc-afaq-return", "kind": "reason-code", "name": "Authorisation cancelled", "group": "authorization", "summary": "ISO's code for an authorisation that has been cancelled. In ISO use it mostly concerns a mandate behind a direct debit; on AFAQ, a credit service in which a sent payment cannot be cancelled after debit (OR 7.14), its use is unclear [Inference].", "triggers": [ "SAMA does not say when this applies on AFAQ [Inference]" ], "actions": [ "Sending participant: ask the receiving participant what it meant [Inference]", "Receiving participant: send back the original amounts at the original exchange rate, in both currencies and with nothing taken off, as one message whose field 72 carries the original payment's reference (OR 7.8, 7.9)", "Receiving participant: expect the Central Component to refuse the return if it differs from the original in amount, currency or rate, repeats a return already accepted, comes too late, or points at an original it cannot find (OR 7.9)" ], "retry": { "allowed": true, "rule": "Not barred. Nothing in SAMA's rules stops a new payment once the cause is dealt with; it goes out with a new Unique Message Reference and may keep the UETR (OR 7.3) [Inference: the OR 7.3 sentence is written for rejections]. Only one successful return is allowed per payment (OR 7.9)." }, "facts": { "return_windows": [ { "action": "return the payment with this reason", "by": "Receiving direct participant (a Saudi participant under SAMA's rules)", "deadline": "Best on the business day the payment arrived; if not, by that payment type's cut-off on the next business day; never later than 2 business days after receipt, counting only days that are business days in both the sending and the receiving country (OR 7.8, 7.9, 5.3). Inside that time no compensation for use of the funds is owed (OR 7.8). The Central Component refuses a return after 2 business days (OR 7.9), and SAMA charges SAR 100 per payment message returned late, possibly plus an amount-based charge (CP 4.2, CP Appendix 2)." } ], "applies_to": "AFAQ cross-currency service, under SAMA's rules for Saudi direct participants: a return payment sent by the receiving direct participant for a payment it received through AFAQ and could not credit (OR 7.8), in the exchange period that accepts returns (OR 5.1 item 6)." }, "caveat": "SAMA's explanation matches ISO's definition of this code apart from spelling (ISO 20022 ExternalReturnReason1Code, 2Q2026). This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "related": [ "gcc-afaq-return:CUST", "gcc-afaq-return:FRTR" ], "basis": { "sources": "SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service (2021-05-05, 24/9/1442 H, In-Force), read in full on rulebook.sama.gov.sa on 2026-09-18: Appendix 2, table of returned payments, entry for CN01; sections 5.1 item 6, 5.3, 7.3, 7.8, 7.9, 7.14. SAMA circular 43038107, Charging Policy for Cross Currency Payments Using AFAQ Service (2021-12-02), section 4.2 and Appendix 2. ISO 20022 External Code Sets 2Q2026 (2Q2026_externalcodesets_v3.json, downloaded 2026-09-18), compared by script. SAMA gives one line per code and no usage guidance, so triggers and actions beyond that line are inference.", "confidence": "low" }, "currency": { "effective_since": "2021-05-05", "effective_note": "Date of SAMA circular 42068309 (24/9/1442 H), In-Force when read on 2026-09-18. The portal's Versions block shows date ranges that end before they begin, so no later edition can be read from it. The appendix says returned codes are registered in the AFAQ Central Component dictionary, which may be updated from time to time, so the live list may differ from the published one [Inference].", "source_edition": "SAMA circular 42068309 (2021-05-05), Appendix 2", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://rulebook.sama.gov.sa/en/appendix-2-return-and-rejection-codes", "source_class": "public_primary", "source_title": "Appendix 2 - Return and Rejection Codes (SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-18", "notes": "Appendix 2 of SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service, lists CN01 with the meaning this record states. SAMA's Operating Rules, sections 7.8 and 7.9, confirm the return limits the record gives: an outer limit of 2 business days, counted only on days that both countries work, with an earlier expected deadline; no compensation for holding the funds inside that limit; and refusal by the Central Component of a return that is late, a duplicate, or inconsistent with the original payment. Section 5.1 item 6 confirms the exchange period accepts returns. SAMA's Charging Policy for Cross Currency Payments Using AFAQ Service, circular 43038107, section 4.2, confirms the SAR 100 penalty for a late return. Section 7.14 confirms a debited payment cannot be cancelled or recalled, supporting the record's point that this code's ordinary meaning does not fit AFAQ well." } ] }, "rail_name": "AFAQ Returns (SAMA rules for Saudi participants)", "governing_authority": "Saudi Central Bank (SAMA), for its direct participants; AFAQ is owned by the six GCC central banks and run by the Gulf Payments Company", "snapshot": "2026-09-18", "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "judgement", "label": "your bank's own terms", "needs": "whose terms decide it: the bank's, the participant's or the scheme's", "detail": "This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "from": "caveat" } ] }, { "uid": "gcc-afaq-return:CURR", "id": "CURR", "rail": "gcc-afaq-return", "kind": "reason-code", "name": "Wrong currency", "group": "technical", "summary": "Wrong currency on the payment. AFAQ fixes the currency on each side by country: the sender pays in its own currency and the receiver is credited in its own (OR 1, 6), so a wrong currency code is normally rejected before it reaches the receiving participant [Inference].", "triggers": [ "The currency on the payment does not suit the receiving participant or the beneficiary's account [Inference]" ], "actions": [ "Sending participant: send a new payment in the receiving country's currency at the day's confirmed rate (OR 6)", "Receiving participant: send back the original amounts at the original exchange rate, in both currencies and with nothing taken off, as one message whose field 72 carries the original payment's reference (OR 7.8, 7.9)", "Receiving participant: expect the Central Component to refuse the return if it differs from the original in amount, currency or rate, repeats a return already accepted, comes too late, or points at an original it cannot find (OR 7.9)" ], "retry": { "allowed": true, "rule": "Yes, as a new payment. A returned payment may not be sent again under its original Unique Message Reference; once the cause is fixed the sending participant may send it as a new payment with a new Unique Message Reference, and may keep the same UETR (OR 7.3). That sentence sits in the paragraph on rejections and is read here as covering returns too [Inference]." }, "facts": { "return_windows": [ { "action": "return the payment with this reason", "by": "Receiving direct participant (a Saudi participant under SAMA's rules)", "deadline": "Best on the business day the payment arrived; if not, by that payment type's cut-off on the next business day; never later than 2 business days after receipt, counting only days that are business days in both the sending and the receiving country (OR 7.8, 7.9, 5.3). Inside that time no compensation for use of the funds is owed (OR 7.8). The Central Component refuses a return after 2 business days (OR 7.9), and SAMA charges SAR 100 per payment message returned late, possibly plus an amount-based charge (CP 4.2, CP Appendix 2)." } ], "applies_to": "AFAQ cross-currency service, under SAMA's rules for Saudi direct participants: a return payment sent by the receiving direct participant for a payment it received through AFAQ and could not credit (OR 7.8), in the exchange period that accepts returns (OR 5.1 item 6)." }, "caveat": "SAMA's explanation is ISO's own definition of this code (ISO 20022 ExternalReturnReason1Code, 2Q2026). This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "related": [ "gcc-afaq-return:AM03", "gcc-afaq-return:BADC" ], "basis": { "sources": "SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service (2021-05-05, 24/9/1442 H, In-Force), read in full on rulebook.sama.gov.sa on 2026-09-18: Appendix 2, table of returned payments, entry for CURR; sections 5.1 item 6, 5.3, 7.3, 7.8, 7.9, 1, 6. SAMA circular 43038107, Charging Policy for Cross Currency Payments Using AFAQ Service (2021-12-02), section 4.2 and Appendix 2. ISO 20022 External Code Sets 2Q2026 (2Q2026_externalcodesets_v3.json, downloaded 2026-09-18), compared by script. SAMA gives one line per code and no usage guidance, so triggers and actions beyond that line are inference.", "confidence": "medium" }, "currency": { "effective_since": "2021-05-05", "effective_note": "Date of SAMA circular 42068309 (24/9/1442 H), In-Force when read on 2026-09-18. The portal's Versions block shows date ranges that end before they begin, so no later edition can be read from it. The appendix says returned codes are registered in the AFAQ Central Component dictionary, which may be updated from time to time, so the live list may differ from the published one [Inference].", "source_edition": "SAMA circular 42068309 (2021-05-05), Appendix 2", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://rulebook.sama.gov.sa/en/appendix-2-return-and-rejection-codes", "source_class": "public_primary", "source_title": "Appendix 2 - Return and Rejection Codes (SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-18", "notes": "Appendix 2 of SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service, lists CURR with the meaning this record states. SAMA's Operating Rules, sections 7.8 and 7.9, confirm the return limits the record gives: an outer limit of 2 business days, counted only on days that both countries work, with an earlier expected deadline; no compensation for holding the funds inside that limit; and refusal by the Central Component of a return that is late, a duplicate, or inconsistent with the original payment. Section 5.1 item 6 confirms the exchange period accepts returns. SAMA's Charging Policy for Cross Currency Payments Using AFAQ Service, circular 43038107, section 4.2, confirms the SAR 100 penalty for a late return. Section 6 confirms the exchange rate and currency amounts are validated before a payment reaches the receiving participant." } ] }, "rail_name": "AFAQ Returns (SAMA rules for Saudi participants)", "governing_authority": "Saudi Central Bank (SAMA), for its direct participants; AFAQ is owned by the six GCC central banks and run by the Gulf Payments Company", "snapshot": "2026-09-18", "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "judgement", "label": "your bank's own terms", "needs": "whose terms decide it: the bank's, the participant's or the scheme's", "detail": "This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "from": "caveat" } ] }, { "uid": "gcc-afaq-return:CUST", "id": "CUST", "rail": "gcc-afaq-return", "kind": "reason-code", "name": "Payer asked to cancel", "group": "authorization", "summary": "ISO's code for a payer's (debtor's) request to cancel. On AFAQ a payment cannot be cancelled or recalled once the sending participant is debited (OR 7.14), and SAMA's rules set out no cancellation request, so a return with this code can only be the receiving participant choosing to send the money back after the payer's side asked [Inference].", "triggers": [ "The payer asked its bank to stop the payment after it was sent, and the receiving participant agreed to send it back [Inference]" ], "actions": [ "Sending participant: ask the receiving participant directly; it is not obliged to return a payment that has become final (OR 7.13, 7.14) [Inference]", "Receiving participant: if the beneficiary was already credited, a return may need the beneficiary's consent under the receiving country's law [Speculation]", "Receiving participant: send back the original amounts at the original exchange rate, in both currencies and with nothing taken off, as one message whose field 72 carries the original payment's reference (OR 7.8, 7.9)", "Receiving participant: expect the Central Component to refuse the return if it differs from the original in amount, currency or rate, repeats a return already accepted, comes too late, or points at an original it cannot find (OR 7.9)" ], "retry": { "allowed": false, "rule": "Not applicable: the payer wanted the payment undone." }, "facts": { "return_windows": [ { "action": "return the payment with this reason", "by": "Receiving direct participant (a Saudi participant under SAMA's rules)", "deadline": "Best on the business day the payment arrived; if not, by that payment type's cut-off on the next business day; never later than 2 business days after receipt, counting only days that are business days in both the sending and the receiving country (OR 7.8, 7.9, 5.3). Inside that time no compensation for use of the funds is owed (OR 7.8). The Central Component refuses a return after 2 business days (OR 7.9), and SAMA charges SAR 100 per payment message returned late, possibly plus an amount-based charge (CP 4.2, CP Appendix 2)." } ], "applies_to": "AFAQ cross-currency service, under SAMA's rules for Saudi direct participants: a return payment sent by the receiving direct participant for a payment it received through AFAQ and could not credit (OR 7.8), in the exchange period that accepts returns (OR 5.1 item 6)." }, "caveat": "SAMA's rules describe returns only for payments that could not be credited (OR 7.8); whether they allow a return on request after crediting is not stated [Inference]. SAMA's explanation is ISO's own definition of this code (ISO 20022 ExternalReturnReason1Code, 2Q2026). This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "related": [ "gcc-afaq-return:FOCR", "gcc-afaq-return:MD06", "gcc-afaq-return:SP01" ], "basis": { "sources": "SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service (2021-05-05, 24/9/1442 H, In-Force), read in full on rulebook.sama.gov.sa on 2026-09-18: Appendix 2, table of returned payments, entry for CUST; sections 5.1 item 6, 5.3, 7.3, 7.8, 7.9, 7.13, 7.14. SAMA circular 43038107, Charging Policy for Cross Currency Payments Using AFAQ Service (2021-12-02), section 4.2 and Appendix 2. ISO 20022 External Code Sets 2Q2026 (2Q2026_externalcodesets_v3.json, downloaded 2026-09-18), compared by script. SAMA gives one line per code and no usage guidance, so triggers and actions beyond that line are inference.", "confidence": "low" }, "currency": { "effective_since": "2021-05-05", "effective_note": "Date of SAMA circular 42068309 (24/9/1442 H), In-Force when read on 2026-09-18. The portal's Versions block shows date ranges that end before they begin, so no later edition can be read from it. The appendix says returned codes are registered in the AFAQ Central Component dictionary, which may be updated from time to time, so the live list may differ from the published one [Inference].", "source_edition": "SAMA circular 42068309 (2021-05-05), Appendix 2", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://rulebook.sama.gov.sa/en/appendix-2-return-and-rejection-codes", "source_class": "public_primary", "source_title": "Appendix 2 - Return and Rejection Codes (SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-18", "notes": "Appendix 2 of SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service, lists CUST with the meaning this record states. SAMA's Operating Rules, sections 7.8 and 7.9, confirm the return limits the record gives: an outer limit of 2 business days, counted only on days that both countries work, with an earlier expected deadline; no compensation for holding the funds inside that limit; and refusal by the Central Component of a return that is late, a duplicate, or inconsistent with the original payment. Section 5.1 item 6 confirms the exchange period accepts returns. SAMA's Charging Policy for Cross Currency Payments Using AFAQ Service, circular 43038107, section 4.2, confirms the SAR 100 penalty for a late return. Section 7.14 confirms there is no cancellation or recall once the sending participant is debited, supporting the record's reading of this as a return the receiving participant agreed to at the payer's request." } ] }, "rail_name": "AFAQ Returns (SAMA rules for Saudi participants)", "governing_authority": "Saudi Central Bank (SAMA), for its direct participants; AFAQ is owned by the six GCC central banks and run by the Gulf Payments Company", "snapshot": "2026-09-18", "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "judgement", "label": "your bank's own terms", "needs": "whose terms decide it: the bank's, the participant's or the scheme's", "detail": "This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "from": "caveat" } ] }, { "uid": "gcc-afaq-return:DS28", "id": "DS28", "rail": "gcc-afaq-return", "kind": "reason-code", "name": "Technical problem produced a wrong transaction", "group": "technical", "summary": "A fault in a system along the way produced a flawed transaction, and the money is sent back.", "triggers": [ "A system fault at a participant or in the chain created a payment that should not exist in that form [Inference]" ], "actions": [ "Sending participant: check its systems and send a correct payment if one is still due [Inference]", "Receiving participant: send back the original amounts at the original exchange rate, in both currencies and with nothing taken off, as one message whose field 72 carries the original payment's reference (OR 7.8, 7.9)", "Receiving participant: expect the Central Component to refuse the return if it differs from the original in amount, currency or rate, repeats a return already accepted, comes too late, or points at an original it cannot find (OR 7.9)" ], "retry": { "allowed": true, "rule": "Yes, as a new payment. A returned payment may not be sent again under its original Unique Message Reference; once the cause is fixed the sending participant may send it as a new payment with a new Unique Message Reference, and may keep the same UETR (OR 7.3). That sentence sits in the paragraph on rejections and is read here as covering returns too [Inference]." }, "facts": { "return_windows": [ { "action": "return the payment with this reason", "by": "Receiving direct participant (a Saudi participant under SAMA's rules)", "deadline": "Best on the business day the payment arrived; if not, by that payment type's cut-off on the next business day; never later than 2 business days after receipt, counting only days that are business days in both the sending and the receiving country (OR 7.8, 7.9, 5.3). Inside that time no compensation for use of the funds is owed (OR 7.8). The Central Component refuses a return after 2 business days (OR 7.9), and SAMA charges SAR 100 per payment message returned late, possibly plus an amount-based charge (CP 4.2, CP Appendix 2)." } ], "applies_to": "AFAQ cross-currency service, under SAMA's rules for Saudi direct participants: a return payment sent by the receiving direct participant for a payment it received through AFAQ and could not credit (OR 7.8), in the exchange period that accepts returns (OR 5.1 item 6)." }, "caveat": "SAMA's explanation is ISO's own definition of this code (ISO 20022 ExternalReturnReason1Code, 2Q2026). This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "related": [ "gcc-afaq-return:BE08", "gcc-afaq-return:ED05" ], "basis": { "sources": "SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service (2021-05-05, 24/9/1442 H, In-Force), read in full on rulebook.sama.gov.sa on 2026-09-18: Appendix 2, table of returned payments, entry for DS28; sections 5.1 item 6, 5.3, 7.3, 7.8, 7.9. SAMA circular 43038107, Charging Policy for Cross Currency Payments Using AFAQ Service (2021-12-02), section 4.2 and Appendix 2. ISO 20022 External Code Sets 2Q2026 (2Q2026_externalcodesets_v3.json, downloaded 2026-09-18), compared by script. SAMA gives one line per code and no usage guidance, so triggers and actions beyond that line are inference.", "confidence": "medium" }, "currency": { "effective_since": "2021-05-05", "effective_note": "Date of SAMA circular 42068309 (24/9/1442 H), In-Force when read on 2026-09-18. The portal's Versions block shows date ranges that end before they begin, so no later edition can be read from it. The appendix says returned codes are registered in the AFAQ Central Component dictionary, which may be updated from time to time, so the live list may differ from the published one [Inference].", "source_edition": "SAMA circular 42068309 (2021-05-05), Appendix 2", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://rulebook.sama.gov.sa/en/appendix-2-return-and-rejection-codes", "source_class": "public_primary", "source_title": "Appendix 2 - Return and Rejection Codes (SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-18", "notes": "Appendix 2 of SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service, lists DS28 with the meaning this record states. SAMA's Operating Rules, sections 7.8 and 7.9, confirm the return limits the record gives: an outer limit of 2 business days, counted only on days that both countries work, with an earlier expected deadline; no compensation for holding the funds inside that limit; and refusal by the Central Component of a return that is late, a duplicate, or inconsistent with the original payment. Section 5.1 item 6 confirms the exchange period accepts returns. SAMA's Charging Policy for Cross Currency Payments Using AFAQ Service, circular 43038107, section 4.2, confirms the SAR 100 penalty for a late return." } ] }, "rail_name": "AFAQ Returns (SAMA rules for Saudi participants)", "governing_authority": "Saudi Central Bank (SAMA), for its direct participants; AFAQ is owned by the six GCC central banks and run by the Gulf Payments Company", "snapshot": "2026-09-18", "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "judgement", "label": "your bank's own terms", "needs": "whose terms decide it: the bank's, the participant's or the scheme's", "detail": "This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "from": "caveat" } ] }, { "uid": "gcc-afaq-return:DT01", "id": "DT01", "rail": "gcc-afaq-return", "kind": "reason-code", "name": "Invalid date", "group": "technical", "summary": "The payment carries a date the receiving side cannot accept, the settlement date being the usual example. AFAQ payments are same day value only, on a day that is a working day in both countries (OR 7.2 c), and a wrong value date is normally rejected before arrival [Inference].", "triggers": [ "A date on the message does not fit the receiving side's processing day [Inference]" ], "actions": [ "Sending participant: send a new payment dated for the current joint business day (OR 7.2)", "Receiving participant: send back the original amounts at the original exchange rate, in both currencies and with nothing taken off, as one message whose field 72 carries the original payment's reference (OR 7.8, 7.9)", "Receiving participant: expect the Central Component to refuse the return if it differs from the original in amount, currency or rate, repeats a return already accepted, comes too late, or points at an original it cannot find (OR 7.9)" ], "retry": { "allowed": true, "rule": "Yes, as a new payment. A returned payment may not be sent again under its original Unique Message Reference; once the cause is fixed the sending participant may send it as a new payment with a new Unique Message Reference, and may keep the same UETR (OR 7.3). That sentence sits in the paragraph on rejections and is read here as covering returns too [Inference]." }, "facts": { "return_windows": [ { "action": "return the payment with this reason", "by": "Receiving direct participant (a Saudi participant under SAMA's rules)", "deadline": "Best on the business day the payment arrived; if not, by that payment type's cut-off on the next business day; never later than 2 business days after receipt, counting only days that are business days in both the sending and the receiving country (OR 7.8, 7.9, 5.3). Inside that time no compensation for use of the funds is owed (OR 7.8). The Central Component refuses a return after 2 business days (OR 7.9), and SAMA charges SAR 100 per payment message returned late, possibly plus an amount-based charge (CP 4.2, CP Appendix 2)." } ], "applies_to": "AFAQ cross-currency service, under SAMA's rules for Saudi direct participants: a return payment sent by the receiving direct participant for a payment it received through AFAQ and could not credit (OR 7.8), in the exchange period that accepts returns (OR 5.1 item 6)." }, "caveat": "SAMA's explanation is ISO's own definition of this code (ISO 20022 ExternalReturnReason1Code, 2Q2026). This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "related": [ "gcc-afaq-return:TMO1" ], "basis": { "sources": "SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service (2021-05-05, 24/9/1442 H, In-Force), read in full on rulebook.sama.gov.sa on 2026-09-18: Appendix 2, table of returned payments, entry for DT01; sections 5.1 item 6, 5.3, 7.3, 7.8, 7.9, 7.2. SAMA circular 43038107, Charging Policy for Cross Currency Payments Using AFAQ Service (2021-12-02), section 4.2 and Appendix 2. ISO 20022 External Code Sets 2Q2026 (2Q2026_externalcodesets_v3.json, downloaded 2026-09-18), compared by script. SAMA gives one line per code and no usage guidance, so triggers and actions beyond that line are inference.", "confidence": "medium" }, "currency": { "effective_since": "2021-05-05", "effective_note": "Date of SAMA circular 42068309 (24/9/1442 H), In-Force when read on 2026-09-18. The portal's Versions block shows date ranges that end before they begin, so no later edition can be read from it. The appendix says returned codes are registered in the AFAQ Central Component dictionary, which may be updated from time to time, so the live list may differ from the published one [Inference].", "source_edition": "SAMA circular 42068309 (2021-05-05), Appendix 2", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://rulebook.sama.gov.sa/en/appendix-2-return-and-rejection-codes", "source_class": "public_primary", "source_title": "Appendix 2 - Return and Rejection Codes (SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-18", "notes": "Appendix 2 of SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service, lists DT01 with the meaning this record states. SAMA's Operating Rules, sections 7.8 and 7.9, confirm the return limits the record gives: an outer limit of 2 business days, counted only on days that both countries work, with an earlier expected deadline; no compensation for holding the funds inside that limit; and refusal by the Central Component of a return that is late, a duplicate, or inconsistent with the original payment. Section 5.1 item 6 confirms the exchange period accepts returns. SAMA's Charging Policy for Cross Currency Payments Using AFAQ Service, circular 43038107, section 4.2, confirms the SAR 100 penalty for a late return. Section 7.2(c) confirms AFAQ payments are same-day value only, on a day that is a working day in both countries." } ] }, "rail_name": "AFAQ Returns (SAMA rules for Saudi participants)", "governing_authority": "Saudi Central Bank (SAMA), for its direct participants; AFAQ is owned by the six GCC central banks and run by the Gulf Payments Company", "snapshot": "2026-09-18", "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "judgement", "label": "your bank's own terms", "needs": "whose terms decide it: the bank's, the participant's or the scheme's", "detail": "This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "from": "caveat" } ] }, { "uid": "gcc-afaq-return:ED01", "id": "ED01", "rail": "gcc-afaq-return", "kind": "reason-code", "name": "No correspondent route available", "group": "network", "summary": "The receiving participant cannot pass the payment on through the correspondent it would need, so the payment is returned.", "triggers": [ "The payment is for a financial institution that banks with the receiving participant, and onward credit to it is not possible [Inference: AFAQ allows credit to an institution holding an account with the receiving participant, OR 7.2 f]" ], "actions": [ "Sending participant: find a route the beneficiary's bank can actually receive, or pay a participant directly [Inference]", "Receiving participant: send back the original amounts at the original exchange rate, in both currencies and with nothing taken off, as one message whose field 72 carries the original payment's reference (OR 7.8, 7.9)", "Receiving participant: expect the Central Component to refuse the return if it differs from the original in amount, currency or rate, repeats a return already accepted, comes too late, or points at an original it cannot find (OR 7.9)" ], "retry": { "allowed": true, "rule": "Yes, as a new payment. A returned payment may not be sent again under its original Unique Message Reference; once the cause is fixed the sending participant may send it as a new payment with a new Unique Message Reference, and may keep the same UETR (OR 7.3). That sentence sits in the paragraph on rejections and is read here as covering returns too [Inference]." }, "facts": { "return_windows": [ { "action": "return the payment with this reason", "by": "Receiving direct participant (a Saudi participant under SAMA's rules)", "deadline": "Best on the business day the payment arrived; if not, by that payment type's cut-off on the next business day; never later than 2 business days after receipt, counting only days that are business days in both the sending and the receiving country (OR 7.8, 7.9, 5.3). Inside that time no compensation for use of the funds is owed (OR 7.8). The Central Component refuses a return after 2 business days (OR 7.9), and SAMA charges SAR 100 per payment message returned late, possibly plus an amount-based charge (CP 4.2, CP Appendix 2)." } ], "applies_to": "AFAQ cross-currency service, under SAMA's rules for Saudi direct participants: a return payment sent by the receiving direct participant for a payment it received through AFAQ and could not credit (OR 7.8), in the exchange period that accepts returns (OR 5.1 item 6)." }, "caveat": "SAMA's explanation is ISO's own definition of this code (ISO 20022 ExternalReturnReason1Code, 2Q2026). This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "related": [ "gcc-afaq-return:AC14", "gcc-afaq-return:IBIC" ], "basis": { "sources": "SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service (2021-05-05, 24/9/1442 H, In-Force), read in full on rulebook.sama.gov.sa on 2026-09-18: Appendix 2, table of returned payments, entry for ED01; sections 5.1 item 6, 5.3, 7.3, 7.8, 7.9, 7.2. SAMA circular 43038107, Charging Policy for Cross Currency Payments Using AFAQ Service (2021-12-02), section 4.2 and Appendix 2. ISO 20022 External Code Sets 2Q2026 (2Q2026_externalcodesets_v3.json, downloaded 2026-09-18), compared by script. SAMA gives one line per code and no usage guidance, so triggers and actions beyond that line are inference.", "confidence": "medium" }, "currency": { "effective_since": "2021-05-05", "effective_note": "Date of SAMA circular 42068309 (24/9/1442 H), In-Force when read on 2026-09-18. The portal's Versions block shows date ranges that end before they begin, so no later edition can be read from it. The appendix says returned codes are registered in the AFAQ Central Component dictionary, which may be updated from time to time, so the live list may differ from the published one [Inference].", "source_edition": "SAMA circular 42068309 (2021-05-05), Appendix 2", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://rulebook.sama.gov.sa/en/appendix-2-return-and-rejection-codes", "source_class": "public_primary", "source_title": "Appendix 2 - Return and Rejection Codes (SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-18", "notes": "Appendix 2 of SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service, lists ED01 with the meaning this record states. SAMA's Operating Rules, sections 7.8 and 7.9, confirm the return limits the record gives: an outer limit of 2 business days, counted only on days that both countries work, with an earlier expected deadline; no compensation for holding the funds inside that limit; and refusal by the Central Component of a return that is late, a duplicate, or inconsistent with the original payment. Section 5.1 item 6 confirms the exchange period accepts returns. SAMA's Charging Policy for Cross Currency Payments Using AFAQ Service, circular 43038107, section 4.2, confirms the SAR 100 penalty for a late return." } ] }, "rail_name": "AFAQ Returns (SAMA rules for Saudi participants)", "governing_authority": "Saudi Central Bank (SAMA), for its direct participants; AFAQ is owned by the six GCC central banks and run by the Gulf Payments Company", "snapshot": "2026-09-18", "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "judgement", "label": "your bank's own terms", "needs": "whose terms decide it: the bank's, the participant's or the scheme's", "detail": "This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "from": "caveat" } ] }, { "uid": "gcc-afaq-return:ED03", "id": "ED03", "rail": "gcc-afaq-return", "kind": "reason-code", "name": "Balance of payments details requested", "group": "administrative", "summary": "The receiving side needs extra balance of payments information, the statistical detail central banks collect on cross-border payments, and returns the payment without it.", "triggers": [ "The payment lacks reporting details the receiving country requires for cross-border flows [Inference]; for the UAE this overlaps with the purpose of payment code (OR 7.11) [Inference]" ], "actions": [ "Sending participant: ask what information is missing, add it and send a new payment [Inference]", "Receiving participant: send back the original amounts at the original exchange rate, in both currencies and with nothing taken off, as one message whose field 72 carries the original payment's reference (OR 7.8, 7.9)", "Receiving participant: expect the Central Component to refuse the return if it differs from the original in amount, currency or rate, repeats a return already accepted, comes too late, or points at an original it cannot find (OR 7.9)" ], "retry": { "allowed": true, "rule": "Yes, as a new payment. A returned payment may not be sent again under its original Unique Message Reference; once the cause is fixed the sending participant may send it as a new payment with a new Unique Message Reference, and may keep the same UETR (OR 7.3). That sentence sits in the paragraph on rejections and is read here as covering returns too [Inference]." }, "facts": { "return_windows": [ { "action": "return the payment with this reason", "by": "Receiving direct participant (a Saudi participant under SAMA's rules)", "deadline": "Best on the business day the payment arrived; if not, by that payment type's cut-off on the next business day; never later than 2 business days after receipt, counting only days that are business days in both the sending and the receiving country (OR 7.8, 7.9, 5.3). Inside that time no compensation for use of the funds is owed (OR 7.8). The Central Component refuses a return after 2 business days (OR 7.9), and SAMA charges SAR 100 per payment message returned late, possibly plus an amount-based charge (CP 4.2, CP Appendix 2)." } ], "applies_to": "AFAQ cross-currency service, under SAMA's rules for Saudi direct participants: a return payment sent by the receiving direct participant for a payment it received through AFAQ and could not credit (OR 7.8), in the exchange period that accepts returns (OR 5.1 item 6)." }, "caveat": "SAMA's explanation is ISO's own definition of this code (ISO 20022 ExternalReturnReason1Code, 2Q2026). This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "related": [ "gcc-afaq-return:PPCI", "gcc-afaq-return:RR04" ], "basis": { "sources": "SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service (2021-05-05, 24/9/1442 H, In-Force), read in full on rulebook.sama.gov.sa on 2026-09-18: Appendix 2, table of returned payments, entry for ED03; sections 5.1 item 6, 5.3, 7.3, 7.8, 7.9, 7.11. SAMA circular 43038107, Charging Policy for Cross Currency Payments Using AFAQ Service (2021-12-02), section 4.2 and Appendix 2. ISO 20022 External Code Sets 2Q2026 (2Q2026_externalcodesets_v3.json, downloaded 2026-09-18), compared by script. SAMA gives one line per code and no usage guidance, so triggers and actions beyond that line are inference.", "confidence": "medium" }, "currency": { "effective_since": "2021-05-05", "effective_note": "Date of SAMA circular 42068309 (24/9/1442 H), In-Force when read on 2026-09-18. The portal's Versions block shows date ranges that end before they begin, so no later edition can be read from it. The appendix says returned codes are registered in the AFAQ Central Component dictionary, which may be updated from time to time, so the live list may differ from the published one [Inference].", "source_edition": "SAMA circular 42068309 (2021-05-05), Appendix 2", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://rulebook.sama.gov.sa/en/appendix-2-return-and-rejection-codes", "source_class": "public_primary", "source_title": "Appendix 2 - Return and Rejection Codes (SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-18", "notes": "Appendix 2 of SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service, lists ED03 with the meaning this record states. SAMA's Operating Rules, sections 7.8 and 7.9, confirm the return limits the record gives: an outer limit of 2 business days, counted only on days that both countries work, with an earlier expected deadline; no compensation for holding the funds inside that limit; and refusal by the Central Component of a return that is late, a duplicate, or inconsistent with the original payment. Section 5.1 item 6 confirms the exchange period accepts returns. SAMA's Charging Policy for Cross Currency Payments Using AFAQ Service, circular 43038107, section 4.2, confirms the SAR 100 penalty for a late return." } ] }, "rail_name": "AFAQ Returns (SAMA rules for Saudi participants)", "governing_authority": "Saudi Central Bank (SAMA), for its direct participants; AFAQ is owned by the six GCC central banks and run by the Gulf Payments Company", "snapshot": "2026-09-18", "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "judgement", "label": "your bank's own terms", "needs": "whose terms decide it: the bank's, the participant's or the scheme's", "detail": "This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "from": "caveat" } ] }, { "uid": "gcc-afaq-return:ED05", "id": "ED05", "rail": "gcc-afaq-return", "kind": "reason-code", "name": "Settlement failed", "group": "network", "summary": "ISO's code for a transaction whose settlement failed. On AFAQ, settlement for a participant is final once the sending participant is debited (OR 7.13), and the Central Component posts both sides at once (OR 7.3), so when a receiving participant would return a payment for this reason is not clear [Inference].", "triggers": [ "SAMA does not say [Inference]" ], "actions": [ "Sending participant: check with the receiving participant and the payment's completion confirmation (OR 7.5) [Inference]", "Receiving participant: send back the original amounts at the original exchange rate, in both currencies and with nothing taken off, as one message whose field 72 carries the original payment's reference (OR 7.8, 7.9)", "Receiving participant: expect the Central Component to refuse the return if it differs from the original in amount, currency or rate, repeats a return already accepted, comes too late, or points at an original it cannot find (OR 7.9)" ], "retry": { "allowed": true, "rule": "Not barred. Nothing in SAMA's rules stops a new payment once the cause is dealt with; it goes out with a new Unique Message Reference and may keep the UETR (OR 7.3) [Inference: the OR 7.3 sentence is written for rejections]. Only one successful return is allowed per payment (OR 7.9)." }, "facts": { "return_windows": [ { "action": "return the payment with this reason", "by": "Receiving direct participant (a Saudi participant under SAMA's rules)", "deadline": "Best on the business day the payment arrived; if not, by that payment type's cut-off on the next business day; never later than 2 business days after receipt, counting only days that are business days in both the sending and the receiving country (OR 7.8, 7.9, 5.3). Inside that time no compensation for use of the funds is owed (OR 7.8). The Central Component refuses a return after 2 business days (OR 7.9), and SAMA charges SAR 100 per payment message returned late, possibly plus an amount-based charge (CP 4.2, CP Appendix 2)." } ], "applies_to": "AFAQ cross-currency service, under SAMA's rules for Saudi direct participants: a return payment sent by the receiving direct participant for a payment it received through AFAQ and could not credit (OR 7.8), in the exchange period that accepts returns (OR 5.1 item 6)." }, "caveat": "SAMA's explanation is ISO's own definition of this code (ISO 20022 ExternalReturnReason1Code, 2Q2026). This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "related": [ "gcc-afaq-return:DS28", "gcc-afaq-return:NOOR", "sepa-sct:ED05" ], "basis": { "sources": "SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service (2021-05-05, 24/9/1442 H, In-Force), read in full on rulebook.sama.gov.sa on 2026-09-18: Appendix 2, table of returned payments, entry for ED05; sections 5.1 item 6, 5.3, 7.3, 7.8, 7.9, 7.5, 7.13. SAMA circular 43038107, Charging Policy for Cross Currency Payments Using AFAQ Service (2021-12-02), section 4.2 and Appendix 2. ISO 20022 External Code Sets 2Q2026 (2Q2026_externalcodesets_v3.json, downloaded 2026-09-18), compared by script. SAMA gives one line per code and no usage guidance, so triggers and actions beyond that line are inference.", "confidence": "low" }, "currency": { "effective_since": "2021-05-05", "effective_note": "Date of SAMA circular 42068309 (24/9/1442 H), In-Force when read on 2026-09-18. The portal's Versions block shows date ranges that end before they begin, so no later edition can be read from it. The appendix says returned codes are registered in the AFAQ Central Component dictionary, which may be updated from time to time, so the live list may differ from the published one [Inference].", "source_edition": "SAMA circular 42068309 (2021-05-05), Appendix 2", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://rulebook.sama.gov.sa/en/appendix-2-return-and-rejection-codes", "source_class": "public_primary", "source_title": "Appendix 2 - Return and Rejection Codes (SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-18", "notes": "Appendix 2 of SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service, lists ED05 with the meaning this record states. SAMA's Operating Rules, sections 7.8 and 7.9, confirm the return limits the record gives: an outer limit of 2 business days, counted only on days that both countries work, with an earlier expected deadline; no compensation for holding the funds inside that limit; and refusal by the Central Component of a return that is late, a duplicate, or inconsistent with the original payment. Section 5.1 item 6 confirms the exchange period accepts returns. SAMA's Charging Policy for Cross Currency Payments Using AFAQ Service, circular 43038107, section 4.2, confirms the SAR 100 penalty for a late return." } ] }, "rail_name": "AFAQ Returns (SAMA rules for Saudi participants)", "governing_authority": "Saudi Central Bank (SAMA), for its direct participants; AFAQ is owned by the six GCC central banks and run by the Gulf Payments Company", "snapshot": "2026-09-18", "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "judgement", "label": "your bank's own terms", "needs": "whose terms decide it: the bank's, the participant's or the scheme's", "detail": "This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "from": "caveat" } ] }, { "uid": "gcc-afaq-return:ERIN", "id": "ERIN", "rail": "gcc-afaq-return", "kind": "reason-code", "name": "Extended remittance information not supported", "group": "technical", "summary": "ISO's code for a receiver that cannot handle the Extended Remittance Information (ERI) option a payment uses. ERI is an option of SEPA credit transfers; nothing in SAMA's AFAQ rules mentions it [Inference].", "triggers": [ "SAMA does not say when this applies on AFAQ; perhaps remittance information longer or more structured than the receiver can handle [Speculation]" ], "actions": [ "Sending participant: resend with plain remittance information the receiving participant can take [Inference]", "Receiving participant: send back the original amounts at the original exchange rate, in both currencies and with nothing taken off, as one message whose field 72 carries the original payment's reference (OR 7.8, 7.9)", "Receiving participant: expect the Central Component to refuse the return if it differs from the original in amount, currency or rate, repeats a return already accepted, comes too late, or points at an original it cannot find (OR 7.9)" ], "retry": { "allowed": true, "rule": "Not barred. Nothing in SAMA's rules stops a new payment once the cause is dealt with; it goes out with a new Unique Message Reference and may keep the UETR (OR 7.3) [Inference: the OR 7.3 sentence is written for rejections]. Only one successful return is allowed per payment (OR 7.9)." }, "facts": { "return_windows": [ { "action": "return the payment with this reason", "by": "Receiving direct participant (a Saudi participant under SAMA's rules)", "deadline": "Best on the business day the payment arrived; if not, by that payment type's cut-off on the next business day; never later than 2 business days after receipt, counting only days that are business days in both the sending and the receiving country (OR 7.8, 7.9, 5.3). Inside that time no compensation for use of the funds is owed (OR 7.8). The Central Component refuses a return after 2 business days (OR 7.9), and SAMA charges SAR 100 per payment message returned late, possibly plus an amount-based charge (CP 4.2, CP Appendix 2)." } ], "applies_to": "AFAQ cross-currency service, under SAMA's rules for Saudi direct participants: a return payment sent by the receiving direct participant for a payment it received through AFAQ and could not credit (OR 7.8), in the exchange period that accepts returns (OR 5.1 item 6)." }, "caveat": "The ISO wording SAMA copied names a SEPA term; that is a leftover of ISO's shared code set, not an AFAQ rule. SAMA's explanation is ISO's own definition of this code (ISO 20022 ExternalReturnReason1Code, 2Q2026). This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "related": [ "gcc-afaq-return:FF05", "gcc-afaq-return:NARR" ], "basis": { "sources": "SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service (2021-05-05, 24/9/1442 H, In-Force), read in full on rulebook.sama.gov.sa on 2026-09-18: Appendix 2, table of returned payments, entry for ERIN; sections 5.1 item 6, 5.3, 7.3, 7.8, 7.9. SAMA circular 43038107, Charging Policy for Cross Currency Payments Using AFAQ Service (2021-12-02), section 4.2 and Appendix 2. ISO 20022 External Code Sets 2Q2026 (2Q2026_externalcodesets_v3.json, downloaded 2026-09-18), compared by script. SAMA gives one line per code and no usage guidance, so triggers and actions beyond that line are inference.", "confidence": "low" }, "currency": { "effective_since": "2021-05-05", "effective_note": "Date of SAMA circular 42068309 (24/9/1442 H), In-Force when read on 2026-09-18. The portal's Versions block shows date ranges that end before they begin, so no later edition can be read from it. The appendix says returned codes are registered in the AFAQ Central Component dictionary, which may be updated from time to time, so the live list may differ from the published one [Inference].", "source_edition": "SAMA circular 42068309 (2021-05-05), Appendix 2", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://rulebook.sama.gov.sa/en/appendix-2-return-and-rejection-codes", "source_class": "public_primary", "source_title": "Appendix 2 - Return and Rejection Codes (SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-18", "notes": "Appendix 2 of SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service, lists ERIN with the meaning this record states. SAMA's Operating Rules, sections 7.8 and 7.9, confirm the return limits the record gives: an outer limit of 2 business days, counted only on days that both countries work, with an earlier expected deadline; no compensation for holding the funds inside that limit; and refusal by the Central Component of a return that is late, a duplicate, or inconsistent with the original payment. Section 5.1 item 6 confirms the exchange period accepts returns. SAMA's Charging Policy for Cross Currency Payments Using AFAQ Service, circular 43038107, section 4.2, confirms the SAR 100 penalty for a late return." } ] }, "rail_name": "AFAQ Returns (SAMA rules for Saudi participants)", "governing_authority": "Saudi Central Bank (SAMA), for its direct participants; AFAQ is owned by the six GCC central banks and run by the Gulf Payments Company", "snapshot": "2026-09-18", "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "judgement", "label": "your bank's own terms", "needs": "whose terms decide it: the bank's, the participant's or the scheme's", "detail": "This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "from": "caveat" } ] }, { "uid": "gcc-afaq-return:FF05", "id": "FF05", "rail": "gcc-afaq-return", "kind": "reason-code", "name": "Local instrument code missing or invalid", "group": "technical", "summary": "ISO's code for trouble with the local instrument code: absent, or not one the receiver accepts. Whether AFAQ payments carry a local instrument at all is not public: the message format guides are controlled documents (OR Appendix 1).", "triggers": [ "SAMA does not say when this applies on AFAQ [Inference]" ], "actions": [ "Sending participant: check the message format guide and ask the receiving participant what it expected [Inference]", "Receiving participant: send back the original amounts at the original exchange rate, in both currencies and with nothing taken off, as one message whose field 72 carries the original payment's reference (OR 7.8, 7.9)", "Receiving participant: expect the Central Component to refuse the return if it differs from the original in amount, currency or rate, repeats a return already accepted, comes too late, or points at an original it cannot find (OR 7.9)" ], "retry": { "allowed": true, "rule": "Not barred. Nothing in SAMA's rules stops a new payment once the cause is dealt with; it goes out with a new Unique Message Reference and may keep the UETR (OR 7.3) [Inference: the OR 7.3 sentence is written for rejections]. Only one successful return is allowed per payment (OR 7.9)." }, "facts": { "return_windows": [ { "action": "return the payment with this reason", "by": "Receiving direct participant (a Saudi participant under SAMA's rules)", "deadline": "Best on the business day the payment arrived; if not, by that payment type's cut-off on the next business day; never later than 2 business days after receipt, counting only days that are business days in both the sending and the receiving country (OR 7.8, 7.9, 5.3). Inside that time no compensation for use of the funds is owed (OR 7.8). The Central Component refuses a return after 2 business days (OR 7.9), and SAMA charges SAR 100 per payment message returned late, possibly plus an amount-based charge (CP 4.2, CP Appendix 2)." } ], "applies_to": "AFAQ cross-currency service, under SAMA's rules for Saudi direct participants: a return payment sent by the receiving direct participant for a payment it received through AFAQ and could not credit (OR 7.8), in the exchange period that accepts returns (OR 5.1 item 6)." }, "caveat": "SAMA's explanation is ISO's own definition of this code (ISO 20022 ExternalReturnReason1Code, 2Q2026). This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "related": [ "gcc-afaq-return:AG02", "gcc-afaq-return:ERIN" ], "basis": { "sources": "SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service (2021-05-05, 24/9/1442 H, In-Force), read in full on rulebook.sama.gov.sa on 2026-09-18: Appendix 2, table of returned payments, entry for FF05; sections 5.1 item 6, 5.3, 7.3, 7.8, 7.9, Appendix 1. SAMA circular 43038107, Charging Policy for Cross Currency Payments Using AFAQ Service (2021-12-02), section 4.2 and Appendix 2. ISO 20022 External Code Sets 2Q2026 (2Q2026_externalcodesets_v3.json, downloaded 2026-09-18), compared by script. SAMA gives one line per code and no usage guidance, so triggers and actions beyond that line are inference.", "confidence": "low" }, "currency": { "effective_since": "2021-05-05", "effective_note": "Date of SAMA circular 42068309 (24/9/1442 H), In-Force when read on 2026-09-18. The portal's Versions block shows date ranges that end before they begin, so no later edition can be read from it. The appendix says returned codes are registered in the AFAQ Central Component dictionary, which may be updated from time to time, so the live list may differ from the published one [Inference].", "source_edition": "SAMA circular 42068309 (2021-05-05), Appendix 2", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://rulebook.sama.gov.sa/en/appendix-2-return-and-rejection-codes", "source_class": "public_primary", "source_title": "Appendix 2 - Return and Rejection Codes (SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-18", "notes": "Appendix 2 of SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service, lists FF05 with the meaning this record states. SAMA's Operating Rules, sections 7.8 and 7.9, confirm the return limits the record gives: an outer limit of 2 business days, counted only on days that both countries work, with an earlier expected deadline; no compensation for holding the funds inside that limit; and refusal by the Central Component of a return that is late, a duplicate, or inconsistent with the original payment. Section 5.1 item 6 confirms the exchange period accepts returns. SAMA's Charging Policy for Cross Currency Payments Using AFAQ Service, circular 43038107, section 4.2, confirms the SAR 100 penalty for a late return." } ] }, "rail_name": "AFAQ Returns (SAMA rules for Saudi participants)", "governing_authority": "Saudi Central Bank (SAMA), for its direct participants; AFAQ is owned by the six GCC central banks and run by the Gulf Payments Company", "snapshot": "2026-09-18", "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "judgement", "label": "your bank's own terms", "needs": "whose terms decide it: the bank's, the participant's or the scheme's", "detail": "This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "from": "caveat" } ] }, { "uid": "gcc-afaq-return:FOCR", "id": "FOCR", "rail": "gcc-afaq-return", "kind": "reason-code", "name": "Returned after a cancellation request", "group": "authorization", "summary": "ISO's code for a return that answers a cancellation request. AFAQ has no cancellation or recall once the sending participant is debited (OR 7.14) and no public cancellation request message, so the code can only mark a return the receiving participant agreed to after the sending side asked [Inference].", "triggers": [ "The sending side asked, outside any AFAQ procedure SAMA publishes, for the payment back, and the receiving participant agreed [Inference]" ], "actions": [ "Sending participant: treat the return as the answer to its request [Inference]", "Receiving participant: send back the original amounts at the original exchange rate, in both currencies and with nothing taken off, as one message whose field 72 carries the original payment's reference (OR 7.8, 7.9)", "Receiving participant: expect the Central Component to refuse the return if it differs from the original in amount, currency or rate, repeats a return already accepted, comes too late, or points at an original it cannot find (OR 7.9)" ], "retry": { "allowed": false, "rule": "Not applicable: the sending side asked for the payment back." }, "facts": { "return_windows": [ { "action": "return the payment with this reason", "by": "Receiving direct participant (a Saudi participant under SAMA's rules)", "deadline": "Best on the business day the payment arrived; if not, by that payment type's cut-off on the next business day; never later than 2 business days after receipt, counting only days that are business days in both the sending and the receiving country (OR 7.8, 7.9, 5.3). Inside that time no compensation for use of the funds is owed (OR 7.8). The Central Component refuses a return after 2 business days (OR 7.9), and SAMA charges SAR 100 per payment message returned late, possibly plus an amount-based charge (CP 4.2, CP Appendix 2)." } ], "applies_to": "AFAQ cross-currency service, under SAMA's rules for Saudi direct participants: a return payment sent by the receiving direct participant for a payment it received through AFAQ and could not credit (OR 7.8), in the exchange period that accepts returns (OR 5.1 item 6)." }, "caveat": "SAMA's rules describe returns only for payments that could not be credited (OR 7.8) [Inference]. SAMA's explanation is ISO's own definition of this code (ISO 20022 ExternalReturnReason1Code, 2Q2026). This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "related": [ "gcc-afaq-return:CUST", "gcc-afaq-return:MD06" ], "basis": { "sources": "SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service (2021-05-05, 24/9/1442 H, In-Force), read in full on rulebook.sama.gov.sa on 2026-09-18: Appendix 2, table of returned payments, entry for FOCR; sections 5.1 item 6, 5.3, 7.3, 7.8, 7.9, 7.14. SAMA circular 43038107, Charging Policy for Cross Currency Payments Using AFAQ Service (2021-12-02), section 4.2 and Appendix 2. ISO 20022 External Code Sets 2Q2026 (2Q2026_externalcodesets_v3.json, downloaded 2026-09-18), compared by script. SAMA gives one line per code and no usage guidance, so triggers and actions beyond that line are inference.", "confidence": "low" }, "currency": { "effective_since": "2021-05-05", "effective_note": "Date of SAMA circular 42068309 (24/9/1442 H), In-Force when read on 2026-09-18. The portal's Versions block shows date ranges that end before they begin, so no later edition can be read from it. The appendix says returned codes are registered in the AFAQ Central Component dictionary, which may be updated from time to time, so the live list may differ from the published one [Inference].", "source_edition": "SAMA circular 42068309 (2021-05-05), Appendix 2", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://rulebook.sama.gov.sa/en/appendix-2-return-and-rejection-codes", "source_class": "public_primary", "source_title": "Appendix 2 - Return and Rejection Codes (SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-18", "notes": "Appendix 2 of SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service, lists FOCR with the meaning this record states. SAMA's Operating Rules, sections 7.8 and 7.9, confirm the return limits the record gives: an outer limit of 2 business days, counted only on days that both countries work, with an earlier expected deadline; no compensation for holding the funds inside that limit; and refusal by the Central Component of a return that is late, a duplicate, or inconsistent with the original payment. Section 5.1 item 6 confirms the exchange period accepts returns. SAMA's Charging Policy for Cross Currency Payments Using AFAQ Service, circular 43038107, section 4.2, confirms the SAR 100 penalty for a late return. Section 7.14 confirms there is no cancellation or recall once the sending participant is debited, supporting the record's reading of this as a return the receiving participant agreed to after a cancellation request." } ] }, "rail_name": "AFAQ Returns (SAMA rules for Saudi participants)", "governing_authority": "Saudi Central Bank (SAMA), for its direct participants; AFAQ is owned by the six GCC central banks and run by the Gulf Payments Company", "snapshot": "2026-09-18", "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "judgement", "label": "your bank's own terms", "needs": "whose terms decide it: the bank's, the participant's or the scheme's", "detail": "This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "from": "caveat" } ] }, { "uid": "gcc-afaq-return:FR01", "id": "FR01", "rail": "gcc-afaq-return", "kind": "reason-code", "name": "Fraud", "group": "authorization", "summary": "The receiving participant sends the money back because the payment is tied to fraud.", "triggers": [ "The receiving participant finds that the payment is fraudulent or that the payer was defrauded [Inference]" ], "actions": [ "Participants: act on fraud involving AFAQ promptly and report it to SAMA and to the participants concerned (OR 4.18)", "Sending participant: review the payer's case before any new payment [Inference]", "Receiving participant: send back the original amounts at the original exchange rate, in both currencies and with nothing taken off, as one message whose field 72 carries the original payment's reference (OR 7.8, 7.9)", "Receiving participant: expect the Central Component to refuse the return if it differs from the original in amount, currency or rate, repeats a return already accepted, comes too late, or points at an original it cannot find (OR 7.9)" ], "retry": { "allowed": false, "rule": "No. A payment returned for fraud is not sent again [Inference]." }, "facts": { "return_windows": [ { "action": "return the payment with this reason", "by": "Receiving direct participant (a Saudi participant under SAMA's rules)", "deadline": "Best on the business day the payment arrived; if not, by that payment type's cut-off on the next business day; never later than 2 business days after receipt, counting only days that are business days in both the sending and the receiving country (OR 7.8, 7.9, 5.3). Inside that time no compensation for use of the funds is owed (OR 7.8). The Central Component refuses a return after 2 business days (OR 7.9), and SAMA charges SAR 100 per payment message returned late, possibly plus an amount-based charge (CP 4.2, CP Appendix 2)." } ], "applies_to": "AFAQ cross-currency service, under SAMA's rules for Saudi direct participants: a return payment sent by the receiving direct participant for a payment it received through AFAQ and could not credit (OR 7.8), in the exchange period that accepts returns (OR 5.1 item 6)." }, "caveat": "A return works only within the return time (OR 7.8, 7.9) and, in practice, only while the funds are still there [Inference]; outside that, AFAQ has no recall after debit (OR 7.14). SAMA's explanation is ISO's own definition of this code (ISO 20022 ExternalReturnReason1Code, 2Q2026). This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "related": [ "gcc-afaq-return:UPAY", "gcc-afaq-return:RR04", "gcc-afaq-return:CUST" ], "basis": { "sources": "SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service (2021-05-05, 24/9/1442 H, In-Force), read in full on rulebook.sama.gov.sa on 2026-09-18: Appendix 2, table of returned payments, entry for FR01; sections 5.1 item 6, 5.3, 7.3, 7.8, 7.9, 4.18, 7.14. SAMA circular 43038107, Charging Policy for Cross Currency Payments Using AFAQ Service (2021-12-02), section 4.2 and Appendix 2. ISO 20022 External Code Sets 2Q2026 (2Q2026_externalcodesets_v3.json, downloaded 2026-09-18), compared by script. SAMA gives one line per code and no usage guidance, so triggers and actions beyond that line are inference.", "confidence": "medium" }, "currency": { "effective_since": "2021-05-05", "effective_note": "Date of SAMA circular 42068309 (24/9/1442 H), In-Force when read on 2026-09-18. The portal's Versions block shows date ranges that end before they begin, so no later edition can be read from it. The appendix says returned codes are registered in the AFAQ Central Component dictionary, which may be updated from time to time, so the live list may differ from the published one [Inference].", "source_edition": "SAMA circular 42068309 (2021-05-05), Appendix 2", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://rulebook.sama.gov.sa/en/appendix-2-return-and-rejection-codes", "source_class": "public_primary", "source_title": "Appendix 2 - Return and Rejection Codes (SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-18", "notes": "Appendix 2 of SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service, lists FR01 with the meaning this record states. SAMA's Operating Rules, sections 7.8 and 7.9, confirm the return limits the record gives: an outer limit of 2 business days, counted only on days that both countries work, with an earlier expected deadline; no compensation for holding the funds inside that limit; and refusal by the Central Component of a return that is late, a duplicate, or inconsistent with the original payment. Section 5.1 item 6 confirms the exchange period accepts returns. SAMA's Charging Policy for Cross Currency Payments Using AFAQ Service, circular 43038107, section 4.2, confirms the SAR 100 penalty for a late return." } ] }, "rail_name": "AFAQ Returns (SAMA rules for Saudi participants)", "governing_authority": "Saudi Central Bank (SAMA), for its direct participants; AFAQ is owned by the six GCC central banks and run by the Gulf Payments Company", "snapshot": "2026-09-18", "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "judgement", "label": "your bank's own terms", "needs": "whose terms decide it: the bank's, the participant's or the scheme's", "detail": "This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "from": "caveat" } ] }, { "uid": "gcc-afaq-return:FRTR", "id": "FRTR", "rail": "gcc-afaq-return", "kind": "reason-code", "name": "Tracking ended because the mandate was cancelled", "group": "administrative", "summary": "ISO's code for a final response or tracking that is withdrawn because the mandate behind it was cancelled. Mandates and tracking of this kind belong to direct debits, which AFAQ does not carry (OR 7.2) [Inference].", "triggers": [ "None expected on AFAQ; SAMA does not say when it applies [Inference]" ], "actions": [ "Sending participant: ask the receiving participant what it meant [Inference]", "Receiving participant: send back the original amounts at the original exchange rate, in both currencies and with nothing taken off, as one message whose field 72 carries the original payment's reference (OR 7.8, 7.9)", "Receiving participant: expect the Central Component to refuse the return if it differs from the original in amount, currency or rate, repeats a return already accepted, comes too late, or points at an original it cannot find (OR 7.9)" ], "retry": { "allowed": true, "rule": "Not barred. Nothing in SAMA's rules stops a new payment once the cause is dealt with; it goes out with a new Unique Message Reference and may keep the UETR (OR 7.3) [Inference: the OR 7.3 sentence is written for rejections]. Only one successful return is allowed per payment (OR 7.9)." }, "facts": { "return_windows": [ { "action": "return the payment with this reason", "by": "Receiving direct participant (a Saudi participant under SAMA's rules)", "deadline": "Best on the business day the payment arrived; if not, by that payment type's cut-off on the next business day; never later than 2 business days after receipt, counting only days that are business days in both the sending and the receiving country (OR 7.8, 7.9, 5.3). Inside that time no compensation for use of the funds is owed (OR 7.8). The Central Component refuses a return after 2 business days (OR 7.9), and SAMA charges SAR 100 per payment message returned late, possibly plus an amount-based charge (CP 4.2, CP Appendix 2)." } ], "applies_to": "Listed for the AFAQ cross-currency service under SAMA's rules for Saudi direct participants, although AFAQ carries only single credit payments (OR 7.2); a return by the receiving direct participant (OR 7.8)." }, "caveat": "This is a direct debit code listed on a credit-only system: AFAQ carries single credit payments only (OR 7.2) and has no direct debit, so no ordinary AFAQ payment should draw it [Inference]. SAMA's explanation is ISO's own definition of this code (ISO 20022 ExternalReturnReason1Code, 2Q2026). This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "related": [ "gcc-afaq-return:TRAC", "gcc-afaq-return:SL11" ], "basis": { "sources": "SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service (2021-05-05, 24/9/1442 H, In-Force), read in full on rulebook.sama.gov.sa on 2026-09-18: Appendix 2, table of returned payments, entry for FRTR; sections 5.1 item 6, 5.3, 7.3, 7.8, 7.9, 7.2. SAMA circular 43038107, Charging Policy for Cross Currency Payments Using AFAQ Service (2021-12-02), section 4.2 and Appendix 2. ISO 20022 External Code Sets 2Q2026 (2Q2026_externalcodesets_v3.json, downloaded 2026-09-18), compared by script. SAMA gives one line per code and no usage guidance, so triggers and actions beyond that line are inference.", "confidence": "low" }, "currency": { "effective_since": "2021-05-05", "effective_note": "Date of SAMA circular 42068309 (24/9/1442 H), In-Force when read on 2026-09-18. The portal's Versions block shows date ranges that end before they begin, so no later edition can be read from it. The appendix says returned codes are registered in the AFAQ Central Component dictionary, which may be updated from time to time, so the live list may differ from the published one [Inference].", "source_edition": "SAMA circular 42068309 (2021-05-05), Appendix 2", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://rulebook.sama.gov.sa/en/appendix-2-return-and-rejection-codes", "source_class": "public_primary", "source_title": "Appendix 2 - Return and Rejection Codes (SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-18", "notes": "Appendix 2 of SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service, lists FRTR with the meaning this record states. SAMA's Operating Rules, sections 7.8 and 7.9, confirm the return limits the record gives: an outer limit of 2 business days, counted only on days that both countries work, with an earlier expected deadline; no compensation for holding the funds inside that limit; and refusal by the Central Component of a return that is late, a duplicate, or inconsistent with the original payment. Section 5.1 item 6 confirms the exchange period accepts returns. SAMA's Charging Policy for Cross Currency Payments Using AFAQ Service, circular 43038107, section 4.2, confirms the SAR 100 penalty for a late return. Section 7.2 confirms AFAQ carries no direct debit, supporting the record's point that the mandates and tracking this code names belong to direct debits AFAQ does not carry." } ] }, "rail_name": "AFAQ Returns (SAMA rules for Saudi participants)", "governing_authority": "Saudi Central Bank (SAMA), for its direct participants; AFAQ is owned by the six GCC central banks and run by the Gulf Payments Company", "snapshot": "2026-09-18", "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "judgement", "label": "your bank's own terms", "needs": "whose terms decide it: the bank's, the participant's or the scheme's", "detail": "This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "from": "caveat" } ] }, { "uid": "gcc-afaq-return:IBAN", "id": "IBAN", "rail": "gcc-afaq-return", "kind": "reason-code", "name": "Beneficiary account number invalid", "group": "account", "summary": "An AFAQ code of its own, named IBAN but meaning a reason: the beneficiary account number is invalid. Customer payments to countries that use IBAN must quote the beneficiary's IBAN in that country's format, and a missing or invalid IBAN can be a reason to reject or return (OR 7.12).", "triggers": [ "A customer payment to an IBAN country carries no IBAN, or one that fails the receiving country's rules (OR 7.12)", "The account number is otherwise invalid for the receiving participant [Inference]" ], "actions": [ "Sending participant: tell the payer why the money came back and get beneficiary details that work before sending anything new", "Sending participant: put the beneficiary's IBAN in the account field in the receiving country's published format (OR 7.12)", "Receiving participant: send back the original amounts at the original exchange rate, in both currencies and with nothing taken off, as one message whose field 72 carries the original payment's reference (OR 7.8, 7.9)", "Receiving participant: expect the Central Component to refuse the return if it differs from the original in amount, currency or rate, repeats a return already accepted, comes too late, or points at an original it cannot find (OR 7.9)" ], "retry": { "allowed": true, "rule": "Yes, as a new payment. A returned payment may not be sent again under its original Unique Message Reference; once the cause is fixed the sending participant may send it as a new payment with a new Unique Message Reference, and may keep the same UETR (OR 7.3). That sentence sits in the paragraph on rejections and is read here as covering returns too [Inference]." }, "facts": { "return_windows": [ { "action": "return the payment with this reason", "by": "Receiving direct participant (a Saudi participant under SAMA's rules)", "deadline": "Best on the business day the payment arrived; if not, by that payment type's cut-off on the next business day; never later than 2 business days after receipt, counting only days that are business days in both the sending and the receiving country (OR 7.8, 7.9, 5.3). Inside that time no compensation for use of the funds is owed (OR 7.8). The Central Component refuses a return after 2 business days (OR 7.9), and SAMA charges SAR 100 per payment message returned late, possibly plus an amount-based charge (CP 4.2, CP Appendix 2)." } ], "applies_to": "AFAQ cross-currency service, under SAMA's rules for Saudi direct participants: a return payment sent by the receiving direct participant for a payment it received through AFAQ and could not credit (OR 7.8), in the exchange period that accepts returns (OR 5.1 item 6)." }, "caveat": "Do not confuse the code IBAN with an IBAN value; it is a four-letter reason code. AC01 is ISO's code for a badly formed account number. The code is in no ISO 20022 external code set (2Q2026); it is AFAQ's own. This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "related": [ "gcc-afaq-return:AC01", "gcc-afaq-return:AC03", "gcc-afaq-return:BADE", "gcc-afaq-return:ULBA", "gcc-afaq-return:IBIC" ], "basis": { "sources": "SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service (2021-05-05, 24/9/1442 H, In-Force), read in full on rulebook.sama.gov.sa on 2026-09-18: Appendix 2, table of returned payments, entry for IBAN; sections 5.1 item 6, 5.3, 7.3, 7.8, 7.9, 7.12. SAMA circular 43038107, Charging Policy for Cross Currency Payments Using AFAQ Service (2021-12-02), section 4.2 and Appendix 2. ISO 20022 External Code Sets 2Q2026 (2Q2026_externalcodesets_v3.json, downloaded 2026-09-18), compared by script. SAMA gives one line per code and no usage guidance, so triggers and actions beyond that line are inference.", "confidence": "medium" }, "currency": { "effective_since": "2021-05-05", "effective_note": "Date of SAMA circular 42068309 (24/9/1442 H), In-Force when read on 2026-09-18. The portal's Versions block shows date ranges that end before they begin, so no later edition can be read from it. The appendix says returned codes are registered in the AFAQ Central Component dictionary, which may be updated from time to time, so the live list may differ from the published one [Inference].", "source_edition": "SAMA circular 42068309 (2021-05-05), Appendix 2", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://rulebook.sama.gov.sa/en/appendix-2-return-and-rejection-codes", "source_class": "public_primary", "source_title": "Appendix 2 - Return and Rejection Codes (SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-18", "notes": "Appendix 2 of SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service, lists IBAN with the meaning this record states. SAMA's Operating Rules, sections 7.8 and 7.9, confirm the return limits the record gives: an outer limit of 2 business days, counted only on days that both countries work, with an earlier expected deadline; no compensation for holding the funds inside that limit; and refusal by the Central Component of a return that is late, a duplicate, or inconsistent with the original payment. Section 5.1 item 6 confirms the exchange period accepts returns. SAMA's Charging Policy for Cross Currency Payments Using AFAQ Service, circular 43038107, section 4.2, confirms the SAR 100 penalty for a late return. Section 7.12 confirms the IBAN requirement for customer payments to countries that use it." } ] }, "rail_name": "AFAQ Returns (SAMA rules for Saudi participants)", "governing_authority": "Saudi Central Bank (SAMA), for its direct participants; AFAQ is owned by the six GCC central banks and run by the Gulf Payments Company", "snapshot": "2026-09-18", "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "judgement", "label": "your bank's own terms", "needs": "whose terms decide it: the bank's, the participant's or the scheme's", "detail": "This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "from": "caveat" } ] }, { "uid": "gcc-afaq-return:IBIC", "id": "IBIC", "rail": "gcc-afaq-return", "kind": "reason-code", "name": "Beneficiary bank BIC invalid", "group": "network", "summary": "An AFAQ code of its own: the BIC given for the beneficiary's bank is invalid. The RPG checks payments against the participant directory (OR 4.1.2), so a wrong receiving participant is normally rejected before arrival; IBIC at the return stage more likely concerns a bank further down the chain [Inference].", "triggers": [ "The beneficiary's bank BIC on the payment is wrong or not usable by the receiving participant [Inference]" ], "actions": [ "Sending participant: confirm the beneficiary bank's BIC before a new payment", "Receiving participant: send back the original amounts at the original exchange rate, in both currencies and with nothing taken off, as one message whose field 72 carries the original payment's reference (OR 7.8, 7.9)", "Receiving participant: expect the Central Component to refuse the return if it differs from the original in amount, currency or rate, repeats a return already accepted, comes too late, or points at an original it cannot find (OR 7.9)" ], "retry": { "allowed": true, "rule": "Yes, as a new payment. A returned payment may not be sent again under its original Unique Message Reference; once the cause is fixed the sending participant may send it as a new payment with a new Unique Message Reference, and may keep the same UETR (OR 7.3). That sentence sits in the paragraph on rejections and is read here as covering returns too [Inference]." }, "facts": { "return_windows": [ { "action": "return the payment with this reason", "by": "Receiving direct participant (a Saudi participant under SAMA's rules)", "deadline": "Best on the business day the payment arrived; if not, by that payment type's cut-off on the next business day; never later than 2 business days after receipt, counting only days that are business days in both the sending and the receiving country (OR 7.8, 7.9, 5.3). Inside that time no compensation for use of the funds is owed (OR 7.8). The Central Component refuses a return after 2 business days (OR 7.9), and SAMA charges SAR 100 per payment message returned late, possibly plus an amount-based charge (CP 4.2, CP Appendix 2)." } ], "applies_to": "AFAQ cross-currency service, under SAMA's rules for Saudi direct participants: a return payment sent by the receiving direct participant for a payment it received through AFAQ and could not credit (OR 7.8), in the exchange period that accepts returns (OR 5.1 item 6)." }, "caveat": "Do not confuse the code IBIC with a BIC value; it is a four-letter reason code. The code is in no ISO 20022 external code set (2Q2026); it is AFAQ's own. This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "related": [ "gcc-afaq-return:RC01", "gcc-afaq-return:RC07", "gcc-afaq-return:AC14", "gcc-afaq-return:IBAN" ], "basis": { "sources": "SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service (2021-05-05, 24/9/1442 H, In-Force), read in full on rulebook.sama.gov.sa on 2026-09-18: Appendix 2, table of returned payments, entry for IBIC; sections 5.1 item 6, 5.3, 7.3, 7.8, 7.9, 4.1.2. SAMA circular 43038107, Charging Policy for Cross Currency Payments Using AFAQ Service (2021-12-02), section 4.2 and Appendix 2. ISO 20022 External Code Sets 2Q2026 (2Q2026_externalcodesets_v3.json, downloaded 2026-09-18), compared by script. SAMA gives one line per code and no usage guidance, so triggers and actions beyond that line are inference.", "confidence": "medium" }, "currency": { "effective_since": "2021-05-05", "effective_note": "Date of SAMA circular 42068309 (24/9/1442 H), In-Force when read on 2026-09-18. The portal's Versions block shows date ranges that end before they begin, so no later edition can be read from it. The appendix says returned codes are registered in the AFAQ Central Component dictionary, which may be updated from time to time, so the live list may differ from the published one [Inference].", "source_edition": "SAMA circular 42068309 (2021-05-05), Appendix 2", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://rulebook.sama.gov.sa/en/appendix-2-return-and-rejection-codes", "source_class": "public_primary", "source_title": "Appendix 2 - Return and Rejection Codes (SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-18", "notes": "Appendix 2 of SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service, lists IBIC with the meaning this record states. SAMA's Operating Rules, sections 7.8 and 7.9, confirm the return limits the record gives: an outer limit of 2 business days, counted only on days that both countries work, with an earlier expected deadline; no compensation for holding the funds inside that limit; and refusal by the Central Component of a return that is late, a duplicate, or inconsistent with the original payment. Section 5.1 item 6 confirms the exchange period accepts returns. SAMA's Charging Policy for Cross Currency Payments Using AFAQ Service, circular 43038107, section 4.2, confirms the SAR 100 penalty for a late return. Section 4.1.2 confirms the RPG holds the current Participant Directory for message validation, supporting the record's reading that this code concerns a bank further down the chain rather than the receiving participant itself." } ] }, "rail_name": "AFAQ Returns (SAMA rules for Saudi participants)", "governing_authority": "Saudi Central Bank (SAMA), for its direct participants; AFAQ is owned by the six GCC central banks and run by the Gulf Payments Company", "snapshot": "2026-09-18", "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "judgement", "label": "your bank's own terms", "needs": "whose terms decide it: the bank's, the participant's or the scheme's", "detail": "This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "from": "caveat" } ] }, { "uid": "gcc-afaq-return:MD06", "id": "MD06", "rail": "gcc-afaq-return", "kind": "reason-code", "name": "Customer asked for the money back", "group": "authorization", "summary": "The end customer asked for the funds to be returned. ISO uses the code mainly for direct debit refunds; on AFAQ, a credit-only service with no recall after debit (OR 7.14), read it as a return the receiving participant agreed to at a customer's request [Inference].", "triggers": [ "A customer, most likely the beneficiary, asked the receiving bank to send the payment back [Inference]" ], "actions": [ "Sending participant: tell the payer and ask the returning bank for the reason if it matters [Inference]", "Receiving participant: send back the original amounts at the original exchange rate, in both currencies and with nothing taken off, as one message whose field 72 carries the original payment's reference (OR 7.8, 7.9)", "Receiving participant: expect the Central Component to refuse the return if it differs from the original in amount, currency or rate, repeats a return already accepted, comes too late, or points at an original it cannot find (OR 7.9)" ], "retry": { "allowed": false, "rule": "Not the same payment; the customer wanted it back [Inference]." }, "facts": { "return_windows": [ { "action": "return the payment with this reason", "by": "Receiving direct participant (a Saudi participant under SAMA's rules)", "deadline": "Best on the business day the payment arrived; if not, by that payment type's cut-off on the next business day; never later than 2 business days after receipt, counting only days that are business days in both the sending and the receiving country (OR 7.8, 7.9, 5.3). Inside that time no compensation for use of the funds is owed (OR 7.8). The Central Component refuses a return after 2 business days (OR 7.9), and SAMA charges SAR 100 per payment message returned late, possibly plus an amount-based charge (CP 4.2, CP Appendix 2)." } ], "applies_to": "AFAQ cross-currency service, under SAMA's rules for Saudi direct participants: a return payment sent by the receiving direct participant for a payment it received through AFAQ and could not credit (OR 7.8), in the exchange period that accepts returns (OR 5.1 item 6)." }, "caveat": "SAMA's rules describe returns only for payments that could not be credited (OR 7.8) [Inference]. SAMA's explanation is ISO's own definition of this code (ISO 20022 ExternalReturnReason1Code, 2Q2026). This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "related": [ "gcc-afaq-return:CUST", "gcc-afaq-return:FOCR", "gcc-afaq-return:MS02" ], "basis": { "sources": "SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service (2021-05-05, 24/9/1442 H, In-Force), read in full on rulebook.sama.gov.sa on 2026-09-18: Appendix 2, table of returned payments, entry for MD06; sections 5.1 item 6, 5.3, 7.3, 7.8, 7.9, 7.14. SAMA circular 43038107, Charging Policy for Cross Currency Payments Using AFAQ Service (2021-12-02), section 4.2 and Appendix 2. ISO 20022 External Code Sets 2Q2026 (2Q2026_externalcodesets_v3.json, downloaded 2026-09-18), compared by script. SAMA gives one line per code and no usage guidance, so triggers and actions beyond that line are inference.", "confidence": "low" }, "currency": { "effective_since": "2021-05-05", "effective_note": "Date of SAMA circular 42068309 (24/9/1442 H), In-Force when read on 2026-09-18. The portal's Versions block shows date ranges that end before they begin, so no later edition can be read from it. The appendix says returned codes are registered in the AFAQ Central Component dictionary, which may be updated from time to time, so the live list may differ from the published one [Inference].", "source_edition": "SAMA circular 42068309 (2021-05-05), Appendix 2", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://rulebook.sama.gov.sa/en/appendix-2-return-and-rejection-codes", "source_class": "public_primary", "source_title": "Appendix 2 - Return and Rejection Codes (SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-18", "notes": "Appendix 2 of SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service, lists MD06 with the meaning this record states. SAMA's Operating Rules, sections 7.8 and 7.9, confirm the return limits the record gives: an outer limit of 2 business days, counted only on days that both countries work, with an earlier expected deadline; no compensation for holding the funds inside that limit; and refusal by the Central Component of a return that is late, a duplicate, or inconsistent with the original payment. Section 5.1 item 6 confirms the exchange period accepts returns. SAMA's Charging Policy for Cross Currency Payments Using AFAQ Service, circular 43038107, section 4.2, confirms the SAR 100 penalty for a late return. Section 7.14 confirms there is no recall once the sending participant is debited, supporting the record's reading of this as a return the receiving participant agreed to at the customer's request." } ] }, "rail_name": "AFAQ Returns (SAMA rules for Saudi participants)", "governing_authority": "Saudi Central Bank (SAMA), for its direct participants; AFAQ is owned by the six GCC central banks and run by the Gulf Payments Company", "snapshot": "2026-09-18", "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "judgement", "label": "your bank's own terms", "needs": "whose terms decide it: the bank's, the participant's or the scheme's", "detail": "This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "from": "caveat" } ] }, { "uid": "gcc-afaq-return:MD07", "id": "MD07", "rail": "gcc-afaq-return", "kind": "reason-code", "name": "Beneficiary deceased", "group": "account", "summary": "The beneficiary has died, and the receiving participant sends the payment back rather than credit the account.", "triggers": [ "The receiving bank has been told the account holder is deceased [Inference]" ], "actions": [ "Sending participant: tell the payer; money owed to the deceased goes through whatever estate process applies in the receiving country [Inference]", "Receiving participant: send back the original amounts at the original exchange rate, in both currencies and with nothing taken off, as one message whose field 72 carries the original payment's reference (OR 7.8, 7.9)", "Receiving participant: expect the Central Component to refuse the return if it differs from the original in amount, currency or rate, repeats a return already accepted, comes too late, or points at an original it cannot find (OR 7.9)" ], "retry": { "allowed": false, "rule": "Not to the deceased's account. Any payment to the estate or heirs is a new payment with a new Unique Message Reference (OR 7.3) [Inference]." }, "facts": { "return_windows": [ { "action": "return the payment with this reason", "by": "Receiving direct participant (a Saudi participant under SAMA's rules)", "deadline": "Best on the business day the payment arrived; if not, by that payment type's cut-off on the next business day; never later than 2 business days after receipt, counting only days that are business days in both the sending and the receiving country (OR 7.8, 7.9, 5.3). Inside that time no compensation for use of the funds is owed (OR 7.8). The Central Component refuses a return after 2 business days (OR 7.9), and SAMA charges SAR 100 per payment message returned late, possibly plus an amount-based charge (CP 4.2, CP Appendix 2)." } ], "applies_to": "AFAQ cross-currency service, under SAMA's rules for Saudi direct participants: a return payment sent by the receiving direct participant for a payment it received through AFAQ and could not credit (OR 7.8), in the exchange period that accepts returns (OR 5.1 item 6)." }, "caveat": "SAMA's explanation is ISO's own definition of this code (ISO 20022 ExternalReturnReason1Code, 2Q2026). This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "related": [ "gcc-afaq-return:AC04", "gcc-afaq-return:BACL", "sepa-sct:MD07" ], "basis": { "sources": "SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service (2021-05-05, 24/9/1442 H, In-Force), read in full on rulebook.sama.gov.sa on 2026-09-18: Appendix 2, table of returned payments, entry for MD07; sections 5.1 item 6, 5.3, 7.3, 7.8, 7.9. SAMA circular 43038107, Charging Policy for Cross Currency Payments Using AFAQ Service (2021-12-02), section 4.2 and Appendix 2. ISO 20022 External Code Sets 2Q2026 (2Q2026_externalcodesets_v3.json, downloaded 2026-09-18), compared by script. SAMA gives one line per code and no usage guidance, so triggers and actions beyond that line are inference.", "confidence": "medium" }, "currency": { "effective_since": "2021-05-05", "effective_note": "Date of SAMA circular 42068309 (24/9/1442 H), In-Force when read on 2026-09-18. The portal's Versions block shows date ranges that end before they begin, so no later edition can be read from it. The appendix says returned codes are registered in the AFAQ Central Component dictionary, which may be updated from time to time, so the live list may differ from the published one [Inference].", "source_edition": "SAMA circular 42068309 (2021-05-05), Appendix 2", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://rulebook.sama.gov.sa/en/appendix-2-return-and-rejection-codes", "source_class": "public_primary", "source_title": "Appendix 2 - Return and Rejection Codes (SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-18", "notes": "Appendix 2 of SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service, lists MD07 with the meaning this record states. SAMA's Operating Rules, sections 7.8 and 7.9, confirm the return limits the record gives: an outer limit of 2 business days, counted only on days that both countries work, with an earlier expected deadline; no compensation for holding the funds inside that limit; and refusal by the Central Component of a return that is late, a duplicate, or inconsistent with the original payment. Section 5.1 item 6 confirms the exchange period accepts returns. SAMA's Charging Policy for Cross Currency Payments Using AFAQ Service, circular 43038107, section 4.2, confirms the SAR 100 penalty for a late return." } ] }, "rail_name": "AFAQ Returns (SAMA rules for Saudi participants)", "governing_authority": "Saudi Central Bank (SAMA), for its direct participants; AFAQ is owned by the six GCC central banks and run by the Gulf Payments Company", "snapshot": "2026-09-18", "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "judgement", "label": "your bank's own terms", "needs": "whose terms decide it: the bank's, the participant's or the scheme's", "detail": "This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "from": "caveat" } ] }, { "uid": "gcc-afaq-return:MS02", "id": "MS02", "rail": "gcc-afaq-return", "kind": "reason-code", "name": "Beneficiary gave no reason", "group": "authorization", "summary": "Returned at the customer's wish, with no reason given by that customer.", "triggers": [ "The beneficiary refused the payment or asked for it to go back without explaining [Inference]" ], "actions": [ "Sending participant: tell the payer, who can take it up with the beneficiary [Inference]", "Receiving participant: send back the original amounts at the original exchange rate, in both currencies and with nothing taken off, as one message whose field 72 carries the original payment's reference (OR 7.8, 7.9)", "Receiving participant: expect the Central Component to refuse the return if it differs from the original in amount, currency or rate, repeats a return already accepted, comes too late, or points at an original it cannot find (OR 7.9)" ], "retry": { "allowed": false, "rule": "Not without agreement from the beneficiary [Inference]." }, "facts": { "return_windows": [ { "action": "return the payment with this reason", "by": "Receiving direct participant (a Saudi participant under SAMA's rules)", "deadline": "Best on the business day the payment arrived; if not, by that payment type's cut-off on the next business day; never later than 2 business days after receipt, counting only days that are business days in both the sending and the receiving country (OR 7.8, 7.9, 5.3). Inside that time no compensation for use of the funds is owed (OR 7.8). The Central Component refuses a return after 2 business days (OR 7.9), and SAMA charges SAR 100 per payment message returned late, possibly plus an amount-based charge (CP 4.2, CP Appendix 2)." } ], "applies_to": "AFAQ cross-currency service, under SAMA's rules for Saudi direct participants: a return payment sent by the receiving direct participant for a payment it received through AFAQ and could not credit (OR 7.8), in the exchange period that accepts returns (OR 5.1 item 6)." }, "caveat": "SAMA's explanation is ISO's own definition of this code (ISO 20022 ExternalReturnReason1Code, 2Q2026). This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "related": [ "gcc-afaq-return:MS03", "gcc-afaq-return:NARR", "gcc-afaq-return:MD06", "sepa-sct:MS02" ], "basis": { "sources": "SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service (2021-05-05, 24/9/1442 H, In-Force), read in full on rulebook.sama.gov.sa on 2026-09-18: Appendix 2, table of returned payments, entry for MS02; sections 5.1 item 6, 5.3, 7.3, 7.8, 7.9. SAMA circular 43038107, Charging Policy for Cross Currency Payments Using AFAQ Service (2021-12-02), section 4.2 and Appendix 2. ISO 20022 External Code Sets 2Q2026 (2Q2026_externalcodesets_v3.json, downloaded 2026-09-18), compared by script. SAMA gives one line per code and no usage guidance, so triggers and actions beyond that line are inference.", "confidence": "medium" }, "currency": { "effective_since": "2021-05-05", "effective_note": "Date of SAMA circular 42068309 (24/9/1442 H), In-Force when read on 2026-09-18. The portal's Versions block shows date ranges that end before they begin, so no later edition can be read from it. The appendix says returned codes are registered in the AFAQ Central Component dictionary, which may be updated from time to time, so the live list may differ from the published one [Inference].", "source_edition": "SAMA circular 42068309 (2021-05-05), Appendix 2", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://rulebook.sama.gov.sa/en/appendix-2-return-and-rejection-codes", "source_class": "public_primary", "source_title": "Appendix 2 - Return and Rejection Codes (SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-18", "notes": "Appendix 2 of SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service, lists MS02 with the meaning this record states. SAMA's Operating Rules, sections 7.8 and 7.9, confirm the return limits the record gives: an outer limit of 2 business days, counted only on days that both countries work, with an earlier expected deadline; no compensation for holding the funds inside that limit; and refusal by the Central Component of a return that is late, a duplicate, or inconsistent with the original payment. Section 5.1 item 6 confirms the exchange period accepts returns. SAMA's Charging Policy for Cross Currency Payments Using AFAQ Service, circular 43038107, section 4.2, confirms the SAR 100 penalty for a late return." } ] }, "rail_name": "AFAQ Returns (SAMA rules for Saudi participants)", "governing_authority": "Saudi Central Bank (SAMA), for its direct participants; AFAQ is owned by the six GCC central banks and run by the Gulf Payments Company", "snapshot": "2026-09-18", "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "judgement", "label": "your bank's own terms", "needs": "whose terms decide it: the bank's, the participant's or the scheme's", "detail": "This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "from": "caveat" } ] }, { "uid": "gcc-afaq-return:MS03", "id": "MS03", "rail": "gcc-afaq-return", "kind": "reason-code", "name": "Bank gave no reason", "group": "administrative", "summary": "Returned by a bank without a stated reason.", "triggers": [ "The receiving participant returns the payment and chooses not to, or cannot, give a reason [Inference]" ], "actions": [ "Sending participant: ask the receiving participant; there may be a legal reason it cannot disclose [Inference]", "Receiving participant: send back the original amounts at the original exchange rate, in both currencies and with nothing taken off, as one message whose field 72 carries the original payment's reference (OR 7.8, 7.9)", "Receiving participant: expect the Central Component to refuse the return if it differs from the original in amount, currency or rate, repeats a return already accepted, comes too late, or points at an original it cannot find (OR 7.9)" ], "retry": { "allowed": true, "rule": "Not barred. Nothing in SAMA's rules stops a new payment once the cause is dealt with; it goes out with a new Unique Message Reference and may keep the UETR (OR 7.3) [Inference: the OR 7.3 sentence is written for rejections]. Only one successful return is allowed per payment (OR 7.9)." }, "facts": { "return_windows": [ { "action": "return the payment with this reason", "by": "Receiving direct participant (a Saudi participant under SAMA's rules)", "deadline": "Best on the business day the payment arrived; if not, by that payment type's cut-off on the next business day; never later than 2 business days after receipt, counting only days that are business days in both the sending and the receiving country (OR 7.8, 7.9, 5.3). Inside that time no compensation for use of the funds is owed (OR 7.8). The Central Component refuses a return after 2 business days (OR 7.9), and SAMA charges SAR 100 per payment message returned late, possibly plus an amount-based charge (CP 4.2, CP Appendix 2)." } ], "applies_to": "AFAQ cross-currency service, under SAMA's rules for Saudi direct participants: a return payment sent by the receiving direct participant for a payment it received through AFAQ and could not credit (OR 7.8), in the exchange period that accepts returns (OR 5.1 item 6)." }, "caveat": "SAMA's explanation is ISO's own definition of this code (ISO 20022 ExternalReturnReason1Code, 2Q2026). This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "related": [ "gcc-afaq-return:MS02", "gcc-afaq-return:NARR", "gcc-afaq-return:RR04", "sepa-sct:MS03" ], "basis": { "sources": "SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service (2021-05-05, 24/9/1442 H, In-Force), read in full on rulebook.sama.gov.sa on 2026-09-18: Appendix 2, table of returned payments, entry for MS03; sections 5.1 item 6, 5.3, 7.3, 7.8, 7.9. SAMA circular 43038107, Charging Policy for Cross Currency Payments Using AFAQ Service (2021-12-02), section 4.2 and Appendix 2. ISO 20022 External Code Sets 2Q2026 (2Q2026_externalcodesets_v3.json, downloaded 2026-09-18), compared by script. SAMA gives one line per code and no usage guidance, so triggers and actions beyond that line are inference.", "confidence": "medium" }, "currency": { "effective_since": "2021-05-05", "effective_note": "Date of SAMA circular 42068309 (24/9/1442 H), In-Force when read on 2026-09-18. The portal's Versions block shows date ranges that end before they begin, so no later edition can be read from it. The appendix says returned codes are registered in the AFAQ Central Component dictionary, which may be updated from time to time, so the live list may differ from the published one [Inference].", "source_edition": "SAMA circular 42068309 (2021-05-05), Appendix 2", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://rulebook.sama.gov.sa/en/appendix-2-return-and-rejection-codes", "source_class": "public_primary", "source_title": "Appendix 2 - Return and Rejection Codes (SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-18", "notes": "Appendix 2 of SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service, lists MS03 with the meaning this record states. SAMA's Operating Rules, sections 7.8 and 7.9, confirm the return limits the record gives: an outer limit of 2 business days, counted only on days that both countries work, with an earlier expected deadline; no compensation for holding the funds inside that limit; and refusal by the Central Component of a return that is late, a duplicate, or inconsistent with the original payment. Section 5.1 item 6 confirms the exchange period accepts returns. SAMA's Charging Policy for Cross Currency Payments Using AFAQ Service, circular 43038107, section 4.2, confirms the SAR 100 penalty for a late return." } ] }, "rail_name": "AFAQ Returns (SAMA rules for Saudi participants)", "governing_authority": "Saudi Central Bank (SAMA), for its direct participants; AFAQ is owned by the six GCC central banks and run by the Gulf Payments Company", "snapshot": "2026-09-18", "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "judgement", "label": "your bank's own terms", "needs": "whose terms decide it: the bank's, the participant's or the scheme's", "detail": "This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "from": "caveat" } ] }, { "uid": "gcc-afaq-return:NARR", "id": "NARR", "rail": "gcc-afaq-return", "kind": "reason-code", "name": "Reason given as free text", "group": "administrative", "summary": "No code carries the reason; the returning bank explains it in words alongside the return.", "triggers": [ "No listed code fits and the receiving participant explains in words [Inference]" ], "actions": [ "Sending participant: read the narrative carried with the return; where it sits in AFAQ messages is in the controlled format guides (OR Appendix 1) [Inference: in MT form, likely field 72]", "Receiving participant: send back the original amounts at the original exchange rate, in both currencies and with nothing taken off, as one message whose field 72 carries the original payment's reference (OR 7.8, 7.9)", "Receiving participant: expect the Central Component to refuse the return if it differs from the original in amount, currency or rate, repeats a return already accepted, comes too late, or points at an original it cannot find (OR 7.9)" ], "retry": { "allowed": true, "rule": "Not barred. Nothing in SAMA's rules stops a new payment once the cause is dealt with; it goes out with a new Unique Message Reference and may keep the UETR (OR 7.3) [Inference: the OR 7.3 sentence is written for rejections]. Only one successful return is allowed per payment (OR 7.9)." }, "facts": { "return_windows": [ { "action": "return the payment with this reason", "by": "Receiving direct participant (a Saudi participant under SAMA's rules)", "deadline": "Best on the business day the payment arrived; if not, by that payment type's cut-off on the next business day; never later than 2 business days after receipt, counting only days that are business days in both the sending and the receiving country (OR 7.8, 7.9, 5.3). Inside that time no compensation for use of the funds is owed (OR 7.8). The Central Component refuses a return after 2 business days (OR 7.9), and SAMA charges SAR 100 per payment message returned late, possibly plus an amount-based charge (CP 4.2, CP Appendix 2)." } ], "applies_to": "AFAQ cross-currency service, under SAMA's rules for Saudi direct participants: a return payment sent by the receiving direct participant for a payment it received through AFAQ and could not credit (OR 7.8), in the exchange period that accepts returns (OR 5.1 item 6)." }, "caveat": "SAMA's explanation is ISO's own definition of this code (ISO 20022 ExternalReturnReason1Code, 2Q2026). This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "related": [ "gcc-afaq-return:MS03", "gcc-afaq-return:MS02" ], "basis": { "sources": "SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service (2021-05-05, 24/9/1442 H, In-Force), read in full on rulebook.sama.gov.sa on 2026-09-18: Appendix 2, table of returned payments, entry for NARR; sections 5.1 item 6, 5.3, 7.3, 7.8, 7.9, Appendix 1. SAMA circular 43038107, Charging Policy for Cross Currency Payments Using AFAQ Service (2021-12-02), section 4.2 and Appendix 2. ISO 20022 External Code Sets 2Q2026 (2Q2026_externalcodesets_v3.json, downloaded 2026-09-18), compared by script. SAMA gives one line per code and no usage guidance, so triggers and actions beyond that line are inference.", "confidence": "medium" }, "currency": { "effective_since": "2021-05-05", "effective_note": "Date of SAMA circular 42068309 (24/9/1442 H), In-Force when read on 2026-09-18. The portal's Versions block shows date ranges that end before they begin, so no later edition can be read from it. The appendix says returned codes are registered in the AFAQ Central Component dictionary, which may be updated from time to time, so the live list may differ from the published one [Inference].", "source_edition": "SAMA circular 42068309 (2021-05-05), Appendix 2", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://rulebook.sama.gov.sa/en/appendix-2-return-and-rejection-codes", "source_class": "public_primary", "source_title": "Appendix 2 - Return and Rejection Codes (SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-18", "notes": "Appendix 2 of SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service, lists NARR with the meaning this record states. SAMA's Operating Rules, sections 7.8 and 7.9, confirm the return limits the record gives: an outer limit of 2 business days, counted only on days that both countries work, with an earlier expected deadline; no compensation for holding the funds inside that limit; and refusal by the Central Component of a return that is late, a duplicate, or inconsistent with the original payment. Section 5.1 item 6 confirms the exchange period accepts returns. SAMA's Charging Policy for Cross Currency Payments Using AFAQ Service, circular 43038107, section 4.2, confirms the SAR 100 penalty for a late return." } ] }, "rail_name": "AFAQ Returns (SAMA rules for Saudi participants)", "governing_authority": "Saudi Central Bank (SAMA), for its direct participants; AFAQ is owned by the six GCC central banks and run by the Gulf Payments Company", "snapshot": "2026-09-18", "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "judgement", "label": "your bank's own terms", "needs": "whose terms decide it: the bank's, the participant's or the scheme's", "detail": "This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "from": "caveat" } ] }, { "uid": "gcc-afaq-return:NOAS", "id": "NOAS", "rail": "gcc-afaq-return", "kind": "reason-code", "name": "No response from the beneficiary", "group": "administrative", "summary": "Returned because the beneficiary did not respond. ISO uses the code mostly in answers to recall requests; on AFAQ read it as a return after the receiving participant could not get an answer from the beneficiary, for example to confirm details [Inference].", "triggers": [ "The receiving participant asked the beneficiary something before crediting and heard nothing within the return time (OR 7.8, 7.9) [Inference]" ], "actions": [ "Sending participant: check the beneficiary details with the payer before a new payment [Inference]", "Receiving participant: send back the original amounts at the original exchange rate, in both currencies and with nothing taken off, as one message whose field 72 carries the original payment's reference (OR 7.8, 7.9)", "Receiving participant: expect the Central Component to refuse the return if it differs from the original in amount, currency or rate, repeats a return already accepted, comes too late, or points at an original it cannot find (OR 7.9)" ], "retry": { "allowed": true, "rule": "Yes, as a new payment. A returned payment may not be sent again under its original Unique Message Reference; once the cause is fixed the sending participant may send it as a new payment with a new Unique Message Reference, and may keep the same UETR (OR 7.3). That sentence sits in the paragraph on rejections and is read here as covering returns too [Inference]." }, "facts": { "return_windows": [ { "action": "return the payment with this reason", "by": "Receiving direct participant (a Saudi participant under SAMA's rules)", "deadline": "Best on the business day the payment arrived; if not, by that payment type's cut-off on the next business day; never later than 2 business days after receipt, counting only days that are business days in both the sending and the receiving country (OR 7.8, 7.9, 5.3). Inside that time no compensation for use of the funds is owed (OR 7.8). The Central Component refuses a return after 2 business days (OR 7.9), and SAMA charges SAR 100 per payment message returned late, possibly plus an amount-based charge (CP 4.2, CP Appendix 2)." } ], "applies_to": "AFAQ cross-currency service, under SAMA's rules for Saudi direct participants: a return payment sent by the receiving direct participant for a payment it received through AFAQ and could not credit (OR 7.8), in the exchange period that accepts returns (OR 5.1 item 6)." }, "caveat": "SAMA's explanation is ISO's own definition of this code (ISO 20022 ExternalReturnReason1Code, 2Q2026). This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "related": [ "gcc-afaq-return:RUTA", "gcc-afaq-return:BDIN", "gcc-afaq-return:MS02" ], "basis": { "sources": "SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service (2021-05-05, 24/9/1442 H, In-Force), read in full on rulebook.sama.gov.sa on 2026-09-18: Appendix 2, table of returned payments, entry for NOAS; sections 5.1 item 6, 5.3, 7.3, 7.8, 7.9. SAMA circular 43038107, Charging Policy for Cross Currency Payments Using AFAQ Service (2021-12-02), section 4.2 and Appendix 2. ISO 20022 External Code Sets 2Q2026 (2Q2026_externalcodesets_v3.json, downloaded 2026-09-18), compared by script. SAMA gives one line per code and no usage guidance, so triggers and actions beyond that line are inference.", "confidence": "medium" }, "currency": { "effective_since": "2021-05-05", "effective_note": "Date of SAMA circular 42068309 (24/9/1442 H), In-Force when read on 2026-09-18. The portal's Versions block shows date ranges that end before they begin, so no later edition can be read from it. The appendix says returned codes are registered in the AFAQ Central Component dictionary, which may be updated from time to time, so the live list may differ from the published one [Inference].", "source_edition": "SAMA circular 42068309 (2021-05-05), Appendix 2", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://rulebook.sama.gov.sa/en/appendix-2-return-and-rejection-codes", "source_class": "public_primary", "source_title": "Appendix 2 - Return and Rejection Codes (SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-18", "notes": "Appendix 2 of SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service, lists NOAS with the meaning this record states. SAMA's Operating Rules, sections 7.8 and 7.9, confirm the return limits the record gives: an outer limit of 2 business days, counted only on days that both countries work, with an earlier expected deadline; no compensation for holding the funds inside that limit; and refusal by the Central Component of a return that is late, a duplicate, or inconsistent with the original payment. Section 5.1 item 6 confirms the exchange period accepts returns. SAMA's Charging Policy for Cross Currency Payments Using AFAQ Service, circular 43038107, section 4.2, confirms the SAR 100 penalty for a late return." } ] }, "rail_name": "AFAQ Returns (SAMA rules for Saudi participants)", "governing_authority": "Saudi Central Bank (SAMA), for its direct participants; AFAQ is owned by the six GCC central banks and run by the Gulf Payments Company", "snapshot": "2026-09-18", "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "judgement", "label": "your bank's own terms", "needs": "whose terms decide it: the bank's, the participant's or the scheme's", "detail": "This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "from": "caveat" } ] }, { "uid": "gcc-afaq-return:NOCM", "id": "NOCM", "rail": "gcc-afaq-return", "kind": "reason-code", "name": "Account falls short of regulatory requirements", "group": "account", "summary": "The receiving bank has put the beneficiary's account out of action for this kind of payment because it falls short of a legal requirement, such as customer due diligence, so the payment goes back. SAMA copied ISO's example, South Africa's FICA law, which has nothing to do with AFAQ; the requirement that matters is the receiving country's own [Inference].", "triggers": [ "The receiving bank has restricted the account until the holder completes identification or similar checks [Inference]" ], "actions": [ "Sending participant: tell the payer why the money came back and get beneficiary details that work before sending anything new", "Beneficiary: complete what its bank requires before a new payment [Inference]", "Receiving participant: send back the original amounts at the original exchange rate, in both currencies and with nothing taken off, as one message whose field 72 carries the original payment's reference (OR 7.8, 7.9)", "Receiving participant: expect the Central Component to refuse the return if it differs from the original in amount, currency or rate, repeats a return already accepted, comes too late, or points at an original it cannot find (OR 7.9)" ], "retry": { "allowed": true, "rule": "Yes, as a new payment. A returned payment may not be sent again under its original Unique Message Reference; once the cause is fixed the sending participant may send it as a new payment with a new Unique Message Reference, and may keep the same UETR (OR 7.3). That sentence sits in the paragraph on rejections and is read here as covering returns too [Inference]. A new payment makes sense only once the account is back in order [Inference]." }, "facts": { "return_windows": [ { "action": "return the payment with this reason", "by": "Receiving direct participant (a Saudi participant under SAMA's rules)", "deadline": "Best on the business day the payment arrived; if not, by that payment type's cut-off on the next business day; never later than 2 business days after receipt, counting only days that are business days in both the sending and the receiving country (OR 7.8, 7.9, 5.3). Inside that time no compensation for use of the funds is owed (OR 7.8). The Central Component refuses a return after 2 business days (OR 7.9), and SAMA charges SAR 100 per payment message returned late, possibly plus an amount-based charge (CP 4.2, CP Appendix 2)." } ], "applies_to": "AFAQ cross-currency service, under SAMA's rules for Saudi direct participants: a return payment sent by the receiving direct participant for a payment it received through AFAQ and could not credit (OR 7.8), in the exchange period that accepts returns (OR 5.1 item 6)." }, "caveat": "SAMA's explanation is ISO's own definition of this code (ISO 20022 ExternalReturnReason1Code, 2Q2026). This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "related": [ "gcc-afaq-return:ADRM", "gcc-afaq-return:AC06", "gcc-afaq-return:RR04" ], "basis": { "sources": "SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service (2021-05-05, 24/9/1442 H, In-Force), read in full on rulebook.sama.gov.sa on 2026-09-18: Appendix 2, table of returned payments, entry for NOCM; sections 5.1 item 6, 5.3, 7.3, 7.8, 7.9, 7.15. SAMA circular 43038107, Charging Policy for Cross Currency Payments Using AFAQ Service (2021-12-02), section 4.2 and Appendix 2. ISO 20022 External Code Sets 2Q2026 (2Q2026_externalcodesets_v3.json, downloaded 2026-09-18), compared by script. SAMA gives one line per code and no usage guidance, so triggers and actions beyond that line are inference.", "confidence": "medium" }, "currency": { "effective_since": "2021-05-05", "effective_note": "Date of SAMA circular 42068309 (24/9/1442 H), In-Force when read on 2026-09-18. The portal's Versions block shows date ranges that end before they begin, so no later edition can be read from it. The appendix says returned codes are registered in the AFAQ Central Component dictionary, which may be updated from time to time, so the live list may differ from the published one [Inference].", "source_edition": "SAMA circular 42068309 (2021-05-05), Appendix 2", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://rulebook.sama.gov.sa/en/appendix-2-return-and-rejection-codes", "source_class": "public_primary", "source_title": "Appendix 2 - Return and Rejection Codes (SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-18", "notes": "Appendix 2 of SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service, lists NOCM with the meaning this record states. SAMA's Operating Rules, sections 7.8 and 7.9, confirm the return limits the record gives: an outer limit of 2 business days, counted only on days that both countries work, with an earlier expected deadline; no compensation for holding the funds inside that limit; and refusal by the Central Component of a return that is late, a duplicate, or inconsistent with the original payment. Section 5.1 item 6 confirms the exchange period accepts returns. SAMA's Charging Policy for Cross Currency Payments Using AFAQ Service, circular 43038107, section 4.2, confirms the SAR 100 penalty for a late return." } ] }, "rail_name": "AFAQ Returns (SAMA rules for Saudi participants)", "governing_authority": "Saudi Central Bank (SAMA), for its direct participants; AFAQ is owned by the six GCC central banks and run by the Gulf Payments Company", "snapshot": "2026-09-18", "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "judgement", "label": "your bank's own terms", "needs": "whose terms decide it: the bank's, the participant's or the scheme's", "detail": "This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "from": "caveat" } ] }, { "uid": "gcc-afaq-return:NOOR", "id": "NOOR", "rail": "gcc-afaq-return", "kind": "reason-code", "name": "Original payment never received", "group": "administrative", "summary": "The receiving side says it never received the original payment. SAMA copied ISO's wording, which speaks of a SEPA credit transfer; on AFAQ read it as an AFAQ payment.", "triggers": [ "SAMA does not say when a return would carry this code; the Central Component already refuses a return whose original reference it cannot find (OR 7.9) [Inference]" ], "actions": [ "Sending participant: trace the original payment and its completion confirmation (OR 7.5) [Inference]", "Receiving participant: send back the original amounts at the original exchange rate, in both currencies and with nothing taken off, as one message whose field 72 carries the original payment's reference (OR 7.8, 7.9)", "Receiving participant: expect the Central Component to refuse the return if it differs from the original in amount, currency or rate, repeats a return already accepted, comes too late, or points at an original it cannot find (OR 7.9)" ], "retry": { "allowed": true, "rule": "Not barred. Nothing in SAMA's rules stops a new payment once the cause is dealt with; it goes out with a new Unique Message Reference and may keep the UETR (OR 7.3) [Inference: the OR 7.3 sentence is written for rejections]. Only one successful return is allowed per payment (OR 7.9)." }, "facts": { "return_windows": [ { "action": "return the payment with this reason", "by": "Receiving direct participant (a Saudi participant under SAMA's rules)", "deadline": "Best on the business day the payment arrived; if not, by that payment type's cut-off on the next business day; never later than 2 business days after receipt, counting only days that are business days in both the sending and the receiving country (OR 7.8, 7.9, 5.3). Inside that time no compensation for use of the funds is owed (OR 7.8). The Central Component refuses a return after 2 business days (OR 7.9), and SAMA charges SAR 100 per payment message returned late, possibly plus an amount-based charge (CP 4.2, CP Appendix 2)." } ], "applies_to": "AFAQ cross-currency service, under SAMA's rules for Saudi direct participants: a return payment sent by the receiving direct participant for a payment it received through AFAQ and could not credit (OR 7.8), in the exchange period that accepts returns (OR 5.1 item 6)." }, "caveat": "The ISO wording SAMA copied names a SEPA term; that is a leftover of ISO's shared code set, not an AFAQ rule. SAMA's explanation is ISO's own definition of this code (ISO 20022 ExternalReturnReason1Code, 2Q2026). This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "related": [ "gcc-afaq-return:ARDT", "gcc-afaq-return:NOAS" ], "basis": { "sources": "SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service (2021-05-05, 24/9/1442 H, In-Force), read in full on rulebook.sama.gov.sa on 2026-09-18: Appendix 2, table of returned payments, entry for NOOR; sections 5.1 item 6, 5.3, 7.3, 7.8, 7.9, 7.5. SAMA circular 43038107, Charging Policy for Cross Currency Payments Using AFAQ Service (2021-12-02), section 4.2 and Appendix 2. ISO 20022 External Code Sets 2Q2026 (2Q2026_externalcodesets_v3.json, downloaded 2026-09-18), compared by script. SAMA gives one line per code and no usage guidance, so triggers and actions beyond that line are inference.", "confidence": "low" }, "currency": { "effective_since": "2021-05-05", "effective_note": "Date of SAMA circular 42068309 (24/9/1442 H), In-Force when read on 2026-09-18. The portal's Versions block shows date ranges that end before they begin, so no later edition can be read from it. The appendix says returned codes are registered in the AFAQ Central Component dictionary, which may be updated from time to time, so the live list may differ from the published one [Inference].", "source_edition": "SAMA circular 42068309 (2021-05-05), Appendix 2", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://rulebook.sama.gov.sa/en/appendix-2-return-and-rejection-codes", "source_class": "public_primary", "source_title": "Appendix 2 - Return and Rejection Codes (SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-18", "notes": "Appendix 2 of SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service, lists NOOR with the meaning this record states. SAMA's Operating Rules, sections 7.8 and 7.9, confirm the return limits the record gives: an outer limit of 2 business days, counted only on days that both countries work, with an earlier expected deadline; no compensation for holding the funds inside that limit; and refusal by the Central Component of a return that is late, a duplicate, or inconsistent with the original payment. Section 5.1 item 6 confirms the exchange period accepts returns. SAMA's Charging Policy for Cross Currency Payments Using AFAQ Service, circular 43038107, section 4.2, confirms the SAR 100 penalty for a late return." } ] }, "rail_name": "AFAQ Returns (SAMA rules for Saudi participants)", "governing_authority": "Saudi Central Bank (SAMA), for its direct participants; AFAQ is owned by the six GCC central banks and run by the Gulf Payments Company", "snapshot": "2026-09-18", "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "judgement", "label": "your bank's own terms", "needs": "whose terms decide it: the bank's, the participant's or the scheme's", "detail": "This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "from": "caveat" } ] }, { "uid": "gcc-afaq-return:PPCI", "id": "PPCI", "rail": "gcc-afaq-return", "kind": "reason-code", "name": "Purpose of payment code not accepted", "group": "administrative", "summary": "An AFAQ code of its own: the purpose of payment code on the payment is wrong or not valid. SAMA requires every payment to the UAE to carry the correct purpose code from the list SAMA communicates (OR 7.11).", "triggers": [ "A payment to the UAE carries a missing, wrong or invalid purpose of payment code (OR 7.11)", "Another receiving country checks a purpose code the same way [Unverified]" ], "actions": [ "Sending participant: pick the right purpose code from the list SAMA has communicated and send a new payment (OR 7.11)", "Receiving participant: send back the original amounts at the original exchange rate, in both currencies and with nothing taken off, as one message whose field 72 carries the original payment's reference (OR 7.8, 7.9)", "Receiving participant: expect the Central Component to refuse the return if it differs from the original in amount, currency or rate, repeats a return already accepted, comes too late, or points at an original it cannot find (OR 7.9)" ], "retry": { "allowed": true, "rule": "Yes, as a new payment. A returned payment may not be sent again under its original Unique Message Reference; once the cause is fixed the sending participant may send it as a new payment with a new Unique Message Reference, and may keep the same UETR (OR 7.3). That sentence sits in the paragraph on rejections and is read here as covering returns too [Inference]." }, "facts": { "return_windows": [ { "action": "return the payment with this reason", "by": "Receiving direct participant (a Saudi participant under SAMA's rules)", "deadline": "Best on the business day the payment arrived; if not, by that payment type's cut-off on the next business day; never later than 2 business days after receipt, counting only days that are business days in both the sending and the receiving country (OR 7.8, 7.9, 5.3). Inside that time no compensation for use of the funds is owed (OR 7.8). The Central Component refuses a return after 2 business days (OR 7.9), and SAMA charges SAR 100 per payment message returned late, possibly plus an amount-based charge (CP 4.2, CP Appendix 2)." } ], "applies_to": "AFAQ cross-currency service, under SAMA's rules for Saudi direct participants: a return payment sent by the receiving direct participant for a payment it received through AFAQ and could not credit (OR 7.8), in the exchange period that accepts returns (OR 5.1 item 6)." }, "caveat": "The list of purpose codes is communicated by SAMA to participants and was not read. The code is in no ISO 20022 external code set (2Q2026); it is AFAQ's own. This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "related": [ "gcc-afaq-return:ED03", "gcc-afaq-return:RR04" ], "basis": { "sources": "SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service (2021-05-05, 24/9/1442 H, In-Force), read in full on rulebook.sama.gov.sa on 2026-09-18: Appendix 2, table of returned payments, entry for PPCI; sections 5.1 item 6, 5.3, 7.3, 7.8, 7.9, 7.11. SAMA circular 43038107, Charging Policy for Cross Currency Payments Using AFAQ Service (2021-12-02), section 4.2 and Appendix 2. ISO 20022 External Code Sets 2Q2026 (2Q2026_externalcodesets_v3.json, downloaded 2026-09-18), compared by script. SAMA gives one line per code and no usage guidance, so triggers and actions beyond that line are inference.", "confidence": "medium" }, "currency": { "effective_since": "2021-05-05", "effective_note": "Date of SAMA circular 42068309 (24/9/1442 H), In-Force when read on 2026-09-18. The portal's Versions block shows date ranges that end before they begin, so no later edition can be read from it. The appendix says returned codes are registered in the AFAQ Central Component dictionary, which may be updated from time to time, so the live list may differ from the published one [Inference].", "source_edition": "SAMA circular 42068309 (2021-05-05), Appendix 2", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://rulebook.sama.gov.sa/en/appendix-2-return-and-rejection-codes", "source_class": "public_primary", "source_title": "Appendix 2 - Return and Rejection Codes (SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-18", "notes": "Appendix 2 of SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service, lists PPCI with the meaning this record states. SAMA's Operating Rules, sections 7.8 and 7.9, confirm the return limits the record gives: an outer limit of 2 business days, counted only on days that both countries work, with an earlier expected deadline; no compensation for holding the funds inside that limit; and refusal by the Central Component of a return that is late, a duplicate, or inconsistent with the original payment. Section 5.1 item 6 confirms the exchange period accepts returns. SAMA's Charging Policy for Cross Currency Payments Using AFAQ Service, circular 43038107, section 4.2, confirms the SAR 100 penalty for a late return. Section 7.11 confirms the requirement that payments to the UAE carry the correct purpose of payment code." } ] }, "rail_name": "AFAQ Returns (SAMA rules for Saudi participants)", "governing_authority": "Saudi Central Bank (SAMA), for its direct participants; AFAQ is owned by the six GCC central banks and run by the Gulf Payments Company", "snapshot": "2026-09-18", "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "judgement", "label": "your bank's own terms", "needs": "whose terms decide it: the bank's, the participant's or the scheme's", "detail": "This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "from": "caveat" } ] }, { "uid": "gcc-afaq-return:RC01", "id": "RC01", "rail": "gcc-afaq-return", "kind": "reason-code", "name": "Bank identifier badly formed", "group": "network", "summary": "A bank identifier (BIC) in the payment is not in a valid format, so the receiving participant returns it. ISO notes the code was once about routing code format.", "triggers": [ "A BIC in the message fails its format check at the receiving side [Inference; AFAQ participants are identified by BIC and the RPG validates against its directory, OR 4.1.2]" ], "actions": [ "Sending participant: correct the identifier and send a new payment", "Receiving participant: send back the original amounts at the original exchange rate, in both currencies and with nothing taken off, as one message whose field 72 carries the original payment's reference (OR 7.8, 7.9)", "Receiving participant: expect the Central Component to refuse the return if it differs from the original in amount, currency or rate, repeats a return already accepted, comes too late, or points at an original it cannot find (OR 7.9)" ], "retry": { "allowed": true, "rule": "Yes, as a new payment. A returned payment may not be sent again under its original Unique Message Reference; once the cause is fixed the sending participant may send it as a new payment with a new Unique Message Reference, and may keep the same UETR (OR 7.3). That sentence sits in the paragraph on rejections and is read here as covering returns too [Inference]." }, "facts": { "return_windows": [ { "action": "return the payment with this reason", "by": "Receiving direct participant (a Saudi participant under SAMA's rules)", "deadline": "Best on the business day the payment arrived; if not, by that payment type's cut-off on the next business day; never later than 2 business days after receipt, counting only days that are business days in both the sending and the receiving country (OR 7.8, 7.9, 5.3). Inside that time no compensation for use of the funds is owed (OR 7.8). The Central Component refuses a return after 2 business days (OR 7.9), and SAMA charges SAR 100 per payment message returned late, possibly plus an amount-based charge (CP 4.2, CP Appendix 2)." } ], "applies_to": "AFAQ cross-currency service, under SAMA's rules for Saudi direct participants: a return payment sent by the receiving direct participant for a payment it received through AFAQ and could not credit (OR 7.8), in the exchange period that accepts returns (OR 5.1 item 6)." }, "caveat": "SAMA's explanation matches ISO's definition of this code apart from spelling (ISO 20022 ExternalReturnReason1Code, 2Q2026). This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "related": [ "gcc-afaq-return:RC07", "gcc-afaq-return:IBIC", "sepa-sct:RC01" ], "basis": { "sources": "SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service (2021-05-05, 24/9/1442 H, In-Force), read in full on rulebook.sama.gov.sa on 2026-09-18: Appendix 2, table of returned payments, entry for RC01; sections 5.1 item 6, 5.3, 7.3, 7.8, 7.9, 4.1.2. SAMA circular 43038107, Charging Policy for Cross Currency Payments Using AFAQ Service (2021-12-02), section 4.2 and Appendix 2. ISO 20022 External Code Sets 2Q2026 (2Q2026_externalcodesets_v3.json, downloaded 2026-09-18), compared by script. SAMA gives one line per code and no usage guidance, so triggers and actions beyond that line are inference.", "confidence": "medium" }, "currency": { "effective_since": "2021-05-05", "effective_note": "Date of SAMA circular 42068309 (24/9/1442 H), In-Force when read on 2026-09-18. The portal's Versions block shows date ranges that end before they begin, so no later edition can be read from it. The appendix says returned codes are registered in the AFAQ Central Component dictionary, which may be updated from time to time, so the live list may differ from the published one [Inference].", "source_edition": "SAMA circular 42068309 (2021-05-05), Appendix 2", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://rulebook.sama.gov.sa/en/appendix-2-return-and-rejection-codes", "source_class": "public_primary", "source_title": "Appendix 2 - Return and Rejection Codes (SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-18", "notes": "Appendix 2 of SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service, lists RC01 with the meaning this record states. SAMA's Operating Rules, sections 7.8 and 7.9, confirm the return limits the record gives: an outer limit of 2 business days, counted only on days that both countries work, with an earlier expected deadline; no compensation for holding the funds inside that limit; and refusal by the Central Component of a return that is late, a duplicate, or inconsistent with the original payment. Section 5.1 item 6 confirms the exchange period accepts returns. SAMA's Charging Policy for Cross Currency Payments Using AFAQ Service, circular 43038107, section 4.2, confirms the SAR 100 penalty for a late return." } ] }, "rail_name": "AFAQ Returns (SAMA rules for Saudi participants)", "governing_authority": "Saudi Central Bank (SAMA), for its direct participants; AFAQ is owned by the six GCC central banks and run by the Gulf Payments Company", "snapshot": "2026-09-18", "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "judgement", "label": "your bank's own terms", "needs": "whose terms decide it: the bank's, the participant's or the scheme's", "detail": "This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "from": "caveat" } ] }, { "uid": "gcc-afaq-return:RC07", "id": "RC07", "rail": "gcc-afaq-return", "kind": "reason-code", "name": "Wrong beneficiary bank BIC", "group": "network", "summary": "The BIC given for the beneficiary's bank is wrong. SAMA copied ISO's wording, which refers to SEPA instant credit transfers (SCTR); on AFAQ read it as a wrong beneficiary bank BIC on an AFAQ payment.", "triggers": [ "The BIC is well formed but is not the beneficiary's bank [Inference]" ], "actions": [ "Sending participant: confirm the beneficiary bank's BIC before a new payment", "Receiving participant: send back the original amounts at the original exchange rate, in both currencies and with nothing taken off, as one message whose field 72 carries the original payment's reference (OR 7.8, 7.9)", "Receiving participant: expect the Central Component to refuse the return if it differs from the original in amount, currency or rate, repeats a return already accepted, comes too late, or points at an original it cannot find (OR 7.9)" ], "retry": { "allowed": true, "rule": "Yes, as a new payment. A returned payment may not be sent again under its original Unique Message Reference; once the cause is fixed the sending participant may send it as a new payment with a new Unique Message Reference, and may keep the same UETR (OR 7.3). That sentence sits in the paragraph on rejections and is read here as covering returns too [Inference]." }, "facts": { "return_windows": [ { "action": "return the payment with this reason", "by": "Receiving direct participant (a Saudi participant under SAMA's rules)", "deadline": "Best on the business day the payment arrived; if not, by that payment type's cut-off on the next business day; never later than 2 business days after receipt, counting only days that are business days in both the sending and the receiving country (OR 7.8, 7.9, 5.3). Inside that time no compensation for use of the funds is owed (OR 7.8). The Central Component refuses a return after 2 business days (OR 7.9), and SAMA charges SAR 100 per payment message returned late, possibly plus an amount-based charge (CP 4.2, CP Appendix 2)." } ], "applies_to": "AFAQ cross-currency service, under SAMA's rules for Saudi direct participants: a return payment sent by the receiving direct participant for a payment it received through AFAQ and could not credit (OR 7.8), in the exchange period that accepts returns (OR 5.1 item 6)." }, "caveat": "The ISO wording SAMA copied names a SEPA term; that is a leftover of ISO's shared code set, not an AFAQ rule. SAMA's explanation matches ISO's definition of this code apart from spelling (ISO 20022 ExternalReturnReason1Code, 2Q2026). This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "related": [ "gcc-afaq-return:IBIC", "gcc-afaq-return:RC01", "gcc-afaq-return:AC14" ], "basis": { "sources": "SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service (2021-05-05, 24/9/1442 H, In-Force), read in full on rulebook.sama.gov.sa on 2026-09-18: Appendix 2, table of returned payments, entry for RC07; sections 5.1 item 6, 5.3, 7.3, 7.8, 7.9. SAMA circular 43038107, Charging Policy for Cross Currency Payments Using AFAQ Service (2021-12-02), section 4.2 and Appendix 2. ISO 20022 External Code Sets 2Q2026 (2Q2026_externalcodesets_v3.json, downloaded 2026-09-18), compared by script. SAMA gives one line per code and no usage guidance, so triggers and actions beyond that line are inference.", "confidence": "medium" }, "currency": { "effective_since": "2021-05-05", "effective_note": "Date of SAMA circular 42068309 (24/9/1442 H), In-Force when read on 2026-09-18. The portal's Versions block shows date ranges that end before they begin, so no later edition can be read from it. The appendix says returned codes are registered in the AFAQ Central Component dictionary, which may be updated from time to time, so the live list may differ from the published one [Inference].", "source_edition": "SAMA circular 42068309 (2021-05-05), Appendix 2", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://rulebook.sama.gov.sa/en/appendix-2-return-and-rejection-codes", "source_class": "public_primary", "source_title": "Appendix 2 - Return and Rejection Codes (SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-18", "notes": "Appendix 2 of SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service, lists RC07 with the meaning this record states. SAMA's Operating Rules, sections 7.8 and 7.9, confirm the return limits the record gives: an outer limit of 2 business days, counted only on days that both countries work, with an earlier expected deadline; no compensation for holding the funds inside that limit; and refusal by the Central Component of a return that is late, a duplicate, or inconsistent with the original payment. Section 5.1 item 6 confirms the exchange period accepts returns. SAMA's Charging Policy for Cross Currency Payments Using AFAQ Service, circular 43038107, section 4.2, confirms the SAR 100 penalty for a late return." } ] }, "rail_name": "AFAQ Returns (SAMA rules for Saudi participants)", "governing_authority": "Saudi Central Bank (SAMA), for its direct participants; AFAQ is owned by the six GCC central banks and run by the Gulf Payments Company", "snapshot": "2026-09-18", "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "judgement", "label": "your bank's own terms", "needs": "whose terms decide it: the bank's, the participant's or the scheme's", "detail": "This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "from": "caveat" } ] }, { "uid": "gcc-afaq-return:RF01", "id": "RF01", "rail": "gcc-afaq-return", "kind": "reason-code", "name": "Transaction reference not unique", "group": "technical", "summary": "ISO's code for a transaction reference that is repeated within one message. AFAQ carries single payment messages (OR 7.2), so how a reference could repeat within one message is unclear [Inference].", "triggers": [ "The payment's reference clashes with another the receiving side holds [Inference]; each AFAQ payment carries a Unique Message Reference (OR 7.3)" ], "actions": [ "Sending participant: send a new payment with a new Unique Message Reference (OR 7.3)", "Receiving participant: send back the original amounts at the original exchange rate, in both currencies and with nothing taken off, as one message whose field 72 carries the original payment's reference (OR 7.8, 7.9)", "Receiving participant: expect the Central Component to refuse the return if it differs from the original in amount, currency or rate, repeats a return already accepted, comes too late, or points at an original it cannot find (OR 7.9)" ], "retry": { "allowed": true, "rule": "Yes, as a new payment. A returned payment may not be sent again under its original Unique Message Reference; once the cause is fixed the sending participant may send it as a new payment with a new Unique Message Reference, and may keep the same UETR (OR 7.3). That sentence sits in the paragraph on rejections and is read here as covering returns too [Inference]." }, "facts": { "return_windows": [ { "action": "return the payment with this reason", "by": "Receiving direct participant (a Saudi participant under SAMA's rules)", "deadline": "Best on the business day the payment arrived; if not, by that payment type's cut-off on the next business day; never later than 2 business days after receipt, counting only days that are business days in both the sending and the receiving country (OR 7.8, 7.9, 5.3). Inside that time no compensation for use of the funds is owed (OR 7.8). The Central Component refuses a return after 2 business days (OR 7.9), and SAMA charges SAR 100 per payment message returned late, possibly plus an amount-based charge (CP 4.2, CP Appendix 2)." } ], "applies_to": "AFAQ cross-currency service, under SAMA's rules for Saudi direct participants: a return payment sent by the receiving direct participant for a payment it received through AFAQ and could not credit (OR 7.8), in the exchange period that accepts returns (OR 5.1 item 6)." }, "caveat": "SAMA's explanation is ISO's own definition of this code (ISO 20022 ExternalReturnReason1Code, 2Q2026). This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "related": [ "gcc-afaq-return:AM05", "gcc-afaq-return:AM10" ], "basis": { "sources": "SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service (2021-05-05, 24/9/1442 H, In-Force), read in full on rulebook.sama.gov.sa on 2026-09-18: Appendix 2, table of returned payments, entry for RF01; sections 5.1 item 6, 5.3, 7.3, 7.8, 7.9, 7.2. SAMA circular 43038107, Charging Policy for Cross Currency Payments Using AFAQ Service (2021-12-02), section 4.2 and Appendix 2. ISO 20022 External Code Sets 2Q2026 (2Q2026_externalcodesets_v3.json, downloaded 2026-09-18), compared by script. SAMA gives one line per code and no usage guidance, so triggers and actions beyond that line are inference.", "confidence": "low" }, "currency": { "effective_since": "2021-05-05", "effective_note": "Date of SAMA circular 42068309 (24/9/1442 H), In-Force when read on 2026-09-18. The portal's Versions block shows date ranges that end before they begin, so no later edition can be read from it. The appendix says returned codes are registered in the AFAQ Central Component dictionary, which may be updated from time to time, so the live list may differ from the published one [Inference].", "source_edition": "SAMA circular 42068309 (2021-05-05), Appendix 2", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://rulebook.sama.gov.sa/en/appendix-2-return-and-rejection-codes", "source_class": "public_primary", "source_title": "Appendix 2 - Return and Rejection Codes (SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-18", "notes": "Appendix 2 of SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service, lists RF01 with the meaning this record states. SAMA's Operating Rules, sections 7.8 and 7.9, confirm the return limits the record gives: an outer limit of 2 business days, counted only on days that both countries work, with an earlier expected deadline; no compensation for holding the funds inside that limit; and refusal by the Central Component of a return that is late, a duplicate, or inconsistent with the original payment. Section 5.1 item 6 confirms the exchange period accepts returns. SAMA's Charging Policy for Cross Currency Payments Using AFAQ Service, circular 43038107, section 4.2, confirms the SAR 100 penalty for a late return. Section 7.2(a) confirms AFAQ carries single payment messages only, supporting the record's point about how a reference could repeat within one message." } ] }, "rail_name": "AFAQ Returns (SAMA rules for Saudi participants)", "governing_authority": "Saudi Central Bank (SAMA), for its direct participants; AFAQ is owned by the six GCC central banks and run by the Gulf Payments Company", "snapshot": "2026-09-18", "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "judgement", "label": "your bank's own terms", "needs": "whose terms decide it: the bank's, the participant's or the scheme's", "detail": "This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "from": "caveat" } ] }, { "uid": "gcc-afaq-return:RR01", "id": "RR01", "rail": "gcc-afaq-return", "kind": "reason-code", "name": "Payer account or identifier missing (regulatory)", "group": "administrative", "summary": "The payment falls short on who is paying: a rule the receiving side must follow calls for the payer's account or a unique identifier, and what arrived is missing or too thin.", "triggers": [ "The receiving side's anti-money laundering or other regulatory checks need payer identification the payment lacks [Inference]; participants must follow AML and CFT law (OR 7.15)" ], "actions": [ "Sending participant: complete the payer's account and identification and send a new payment", "Receiving participant: send back the original amounts at the original exchange rate, in both currencies and with nothing taken off, as one message whose field 72 carries the original payment's reference (OR 7.8, 7.9)", "Receiving participant: expect the Central Component to refuse the return if it differs from the original in amount, currency or rate, repeats a return already accepted, comes too late, or points at an original it cannot find (OR 7.9)" ], "retry": { "allowed": true, "rule": "Yes, as a new payment. A returned payment may not be sent again under its original Unique Message Reference; once the cause is fixed the sending participant may send it as a new payment with a new Unique Message Reference, and may keep the same UETR (OR 7.3). That sentence sits in the paragraph on rejections and is read here as covering returns too [Inference]." }, "facts": { "return_windows": [ { "action": "return the payment with this reason", "by": "Receiving direct participant (a Saudi participant under SAMA's rules)", "deadline": "Best on the business day the payment arrived; if not, by that payment type's cut-off on the next business day; never later than 2 business days after receipt, counting only days that are business days in both the sending and the receiving country (OR 7.8, 7.9, 5.3). Inside that time no compensation for use of the funds is owed (OR 7.8). The Central Component refuses a return after 2 business days (OR 7.9), and SAMA charges SAR 100 per payment message returned late, possibly plus an amount-based charge (CP 4.2, CP Appendix 2)." } ], "applies_to": "AFAQ cross-currency service, under SAMA's rules for Saudi direct participants: a return payment sent by the receiving direct participant for a payment it received through AFAQ and could not credit (OR 7.8), in the exchange period that accepts returns (OR 5.1 item 6)." }, "caveat": "SAMA's explanation matches ISO's definition of this code apart from spelling (ISO 20022 ExternalReturnReason1Code, 2Q2026). This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "related": [ "gcc-afaq-return:RR02", "gcc-afaq-return:RR03", "gcc-afaq-return:RR04", "sepa-sct:RR01" ], "basis": { "sources": "SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service (2021-05-05, 24/9/1442 H, In-Force), read in full on rulebook.sama.gov.sa on 2026-09-18: Appendix 2, table of returned payments, entry for RR01; sections 5.1 item 6, 5.3, 7.3, 7.8, 7.9, 7.15. SAMA circular 43038107, Charging Policy for Cross Currency Payments Using AFAQ Service (2021-12-02), section 4.2 and Appendix 2. ISO 20022 External Code Sets 2Q2026 (2Q2026_externalcodesets_v3.json, downloaded 2026-09-18), compared by script. SAMA gives one line per code and no usage guidance, so triggers and actions beyond that line are inference.", "confidence": "medium" }, "currency": { "effective_since": "2021-05-05", "effective_note": "Date of SAMA circular 42068309 (24/9/1442 H), In-Force when read on 2026-09-18. The portal's Versions block shows date ranges that end before they begin, so no later edition can be read from it. The appendix says returned codes are registered in the AFAQ Central Component dictionary, which may be updated from time to time, so the live list may differ from the published one [Inference].", "source_edition": "SAMA circular 42068309 (2021-05-05), Appendix 2", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://rulebook.sama.gov.sa/en/appendix-2-return-and-rejection-codes", "source_class": "public_primary", "source_title": "Appendix 2 - Return and Rejection Codes (SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-18", "notes": "Appendix 2 of SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service, lists RR01 with the meaning this record states. SAMA's Operating Rules, sections 7.8 and 7.9, confirm the return limits the record gives: an outer limit of 2 business days, counted only on days that both countries work, with an earlier expected deadline; no compensation for holding the funds inside that limit; and refusal by the Central Component of a return that is late, a duplicate, or inconsistent with the original payment. Section 5.1 item 6 confirms the exchange period accepts returns. SAMA's Charging Policy for Cross Currency Payments Using AFAQ Service, circular 43038107, section 4.2, confirms the SAR 100 penalty for a late return." } ] }, "rail_name": "AFAQ Returns (SAMA rules for Saudi participants)", "governing_authority": "Saudi Central Bank (SAMA), for its direct participants; AFAQ is owned by the six GCC central banks and run by the Gulf Payments Company", "snapshot": "2026-09-18", "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "judgement", "label": "your bank's own terms", "needs": "whose terms decide it: the bank's, the participant's or the scheme's", "detail": "This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "from": "caveat" } ] }, { "uid": "gcc-afaq-return:RR02", "id": "RR02", "rail": "gcc-afaq-return", "kind": "reason-code", "name": "Payer name or address missing (regulatory)", "group": "administrative", "summary": "The payment falls short on the payer's name or address, which a rule binding the receiving side calls for.", "triggers": [ "Regulatory checks at the receiving side need payer name or address details the payment lacks [Inference]; OR 7.15" ], "actions": [ "Sending participant: complete the payer's name and address and send a new payment", "Receiving participant: send back the original amounts at the original exchange rate, in both currencies and with nothing taken off, as one message whose field 72 carries the original payment's reference (OR 7.8, 7.9)", "Receiving participant: expect the Central Component to refuse the return if it differs from the original in amount, currency or rate, repeats a return already accepted, comes too late, or points at an original it cannot find (OR 7.9)" ], "retry": { "allowed": true, "rule": "Yes, as a new payment. A returned payment may not be sent again under its original Unique Message Reference; once the cause is fixed the sending participant may send it as a new payment with a new Unique Message Reference, and may keep the same UETR (OR 7.3). That sentence sits in the paragraph on rejections and is read here as covering returns too [Inference]." }, "facts": { "return_windows": [ { "action": "return the payment with this reason", "by": "Receiving direct participant (a Saudi participant under SAMA's rules)", "deadline": "Best on the business day the payment arrived; if not, by that payment type's cut-off on the next business day; never later than 2 business days after receipt, counting only days that are business days in both the sending and the receiving country (OR 7.8, 7.9, 5.3). Inside that time no compensation for use of the funds is owed (OR 7.8). The Central Component refuses a return after 2 business days (OR 7.9), and SAMA charges SAR 100 per payment message returned late, possibly plus an amount-based charge (CP 4.2, CP Appendix 2)." } ], "applies_to": "AFAQ cross-currency service, under SAMA's rules for Saudi direct participants: a return payment sent by the receiving direct participant for a payment it received through AFAQ and could not credit (OR 7.8), in the exchange period that accepts returns (OR 5.1 item 6)." }, "caveat": "SAMA's explanation matches ISO's definition of this code apart from spelling (ISO 20022 ExternalReturnReason1Code, 2Q2026). This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "related": [ "gcc-afaq-return:RR01", "gcc-afaq-return:RR03", "gcc-afaq-return:BE07", "sepa-sct:RR02" ], "basis": { "sources": "SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service (2021-05-05, 24/9/1442 H, In-Force), read in full on rulebook.sama.gov.sa on 2026-09-18: Appendix 2, table of returned payments, entry for RR02; sections 5.1 item 6, 5.3, 7.3, 7.8, 7.9, 7.15. SAMA circular 43038107, Charging Policy for Cross Currency Payments Using AFAQ Service (2021-12-02), section 4.2 and Appendix 2. ISO 20022 External Code Sets 2Q2026 (2Q2026_externalcodesets_v3.json, downloaded 2026-09-18), compared by script. SAMA gives one line per code and no usage guidance, so triggers and actions beyond that line are inference.", "confidence": "medium" }, "currency": { "effective_since": "2021-05-05", "effective_note": "Date of SAMA circular 42068309 (24/9/1442 H), In-Force when read on 2026-09-18. The portal's Versions block shows date ranges that end before they begin, so no later edition can be read from it. The appendix says returned codes are registered in the AFAQ Central Component dictionary, which may be updated from time to time, so the live list may differ from the published one [Inference].", "source_edition": "SAMA circular 42068309 (2021-05-05), Appendix 2", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://rulebook.sama.gov.sa/en/appendix-2-return-and-rejection-codes", "source_class": "public_primary", "source_title": "Appendix 2 - Return and Rejection Codes (SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-18", "notes": "Appendix 2 of SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service, lists RR02 with the meaning this record states. SAMA's Operating Rules, sections 7.8 and 7.9, confirm the return limits the record gives: an outer limit of 2 business days, counted only on days that both countries work, with an earlier expected deadline; no compensation for holding the funds inside that limit; and refusal by the Central Component of a return that is late, a duplicate, or inconsistent with the original payment. Section 5.1 item 6 confirms the exchange period accepts returns. SAMA's Charging Policy for Cross Currency Payments Using AFAQ Service, circular 43038107, section 4.2, confirms the SAR 100 penalty for a late return." } ] }, "rail_name": "AFAQ Returns (SAMA rules for Saudi participants)", "governing_authority": "Saudi Central Bank (SAMA), for its direct participants; AFAQ is owned by the six GCC central banks and run by the Gulf Payments Company", "snapshot": "2026-09-18", "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "judgement", "label": "your bank's own terms", "needs": "whose terms decide it: the bank's, the participant's or the scheme's", "detail": "This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "from": "caveat" } ] }, { "uid": "gcc-afaq-return:RR03", "id": "RR03", "rail": "gcc-afaq-return", "kind": "reason-code", "name": "Beneficiary name or address missing (regulatory)", "group": "administrative", "summary": "The payment falls short on the beneficiary's name or address, which a rule binding the receiving side calls for.", "triggers": [ "Regulatory checks at the receiving side need beneficiary details the payment lacks [Inference]; OR 7.15" ], "actions": [ "Sending participant: complete the beneficiary's name and address and send a new payment", "Receiving participant: send back the original amounts at the original exchange rate, in both currencies and with nothing taken off, as one message whose field 72 carries the original payment's reference (OR 7.8, 7.9)", "Receiving participant: expect the Central Component to refuse the return if it differs from the original in amount, currency or rate, repeats a return already accepted, comes too late, or points at an original it cannot find (OR 7.9)" ], "retry": { "allowed": true, "rule": "Yes, as a new payment. A returned payment may not be sent again under its original Unique Message Reference; once the cause is fixed the sending participant may send it as a new payment with a new Unique Message Reference, and may keep the same UETR (OR 7.3). That sentence sits in the paragraph on rejections and is read here as covering returns too [Inference]." }, "facts": { "return_windows": [ { "action": "return the payment with this reason", "by": "Receiving direct participant (a Saudi participant under SAMA's rules)", "deadline": "Best on the business day the payment arrived; if not, by that payment type's cut-off on the next business day; never later than 2 business days after receipt, counting only days that are business days in both the sending and the receiving country (OR 7.8, 7.9, 5.3). Inside that time no compensation for use of the funds is owed (OR 7.8). The Central Component refuses a return after 2 business days (OR 7.9), and SAMA charges SAR 100 per payment message returned late, possibly plus an amount-based charge (CP 4.2, CP Appendix 2)." } ], "applies_to": "AFAQ cross-currency service, under SAMA's rules for Saudi direct participants: a return payment sent by the receiving direct participant for a payment it received through AFAQ and could not credit (OR 7.8), in the exchange period that accepts returns (OR 5.1 item 6)." }, "caveat": "SAMA's explanation matches ISO's definition of this code apart from spelling (ISO 20022 ExternalReturnReason1Code, 2Q2026). This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "related": [ "gcc-afaq-return:RR01", "gcc-afaq-return:RR02", "gcc-afaq-return:BE04", "sepa-sct:RR03" ], "basis": { "sources": "SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service (2021-05-05, 24/9/1442 H, In-Force), read in full on rulebook.sama.gov.sa on 2026-09-18: Appendix 2, table of returned payments, entry for RR03; sections 5.1 item 6, 5.3, 7.3, 7.8, 7.9, 7.15. SAMA circular 43038107, Charging Policy for Cross Currency Payments Using AFAQ Service (2021-12-02), section 4.2 and Appendix 2. ISO 20022 External Code Sets 2Q2026 (2Q2026_externalcodesets_v3.json, downloaded 2026-09-18), compared by script. SAMA gives one line per code and no usage guidance, so triggers and actions beyond that line are inference.", "confidence": "medium" }, "currency": { "effective_since": "2021-05-05", "effective_note": "Date of SAMA circular 42068309 (24/9/1442 H), In-Force when read on 2026-09-18. The portal's Versions block shows date ranges that end before they begin, so no later edition can be read from it. The appendix says returned codes are registered in the AFAQ Central Component dictionary, which may be updated from time to time, so the live list may differ from the published one [Inference].", "source_edition": "SAMA circular 42068309 (2021-05-05), Appendix 2", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://rulebook.sama.gov.sa/en/appendix-2-return-and-rejection-codes", "source_class": "public_primary", "source_title": "Appendix 2 - Return and Rejection Codes (SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-18", "notes": "Appendix 2 of SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service, lists RR03 with the meaning this record states. SAMA's Operating Rules, sections 7.8 and 7.9, confirm the return limits the record gives: an outer limit of 2 business days, counted only on days that both countries work, with an earlier expected deadline; no compensation for holding the funds inside that limit; and refusal by the Central Component of a return that is late, a duplicate, or inconsistent with the original payment. Section 5.1 item 6 confirms the exchange period accepts returns. SAMA's Charging Policy for Cross Currency Payments Using AFAQ Service, circular 43038107, section 4.2, confirms the SAR 100 penalty for a late return." } ] }, "rail_name": "AFAQ Returns (SAMA rules for Saudi participants)", "governing_authority": "Saudi Central Bank (SAMA), for its direct participants; AFAQ is owned by the six GCC central banks and run by the Gulf Payments Company", "snapshot": "2026-09-18", "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "judgement", "label": "your bank's own terms", "needs": "whose terms decide it: the bank's, the participant's or the scheme's", "detail": "This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "from": "caveat" } ] }, { "uid": "gcc-afaq-return:RR04", "id": "RR04", "rail": "gcc-afaq-return", "kind": "reason-code", "name": "Regulatory reason", "group": "administrative", "summary": "The payment is returned for a regulatory reason that no more specific code covers.", "triggers": [ "Sanctions screening, anti-money laundering or another legal requirement at the receiving side stops the credit [Inference]; participants must follow AML and CFT law (OR 7.15)" ], "actions": [ "Sending participant: ask the receiving participant what is needed; it may not be able to say, for legal reasons [Inference]", "Receiving participant: send back the original amounts at the original exchange rate, in both currencies and with nothing taken off, as one message whose field 72 carries the original payment's reference (OR 7.8, 7.9)", "Receiving participant: expect the Central Component to refuse the return if it differs from the original in amount, currency or rate, repeats a return already accepted, comes too late, or points at an original it cannot find (OR 7.9)" ], "retry": { "allowed": false, "rule": "Not without knowing the reason. Sending the same payment again would likely meet the same bar [Inference]." }, "facts": { "return_windows": [ { "action": "return the payment with this reason", "by": "Receiving direct participant (a Saudi participant under SAMA's rules)", "deadline": "Best on the business day the payment arrived; if not, by that payment type's cut-off on the next business day; never later than 2 business days after receipt, counting only days that are business days in both the sending and the receiving country (OR 7.8, 7.9, 5.3). Inside that time no compensation for use of the funds is owed (OR 7.8). The Central Component refuses a return after 2 business days (OR 7.9), and SAMA charges SAR 100 per payment message returned late, possibly plus an amount-based charge (CP 4.2, CP Appendix 2)." } ], "applies_to": "AFAQ cross-currency service, under SAMA's rules for Saudi direct participants: a return payment sent by the receiving direct participant for a payment it received through AFAQ and could not credit (OR 7.8), in the exchange period that accepts returns (OR 5.1 item 6)." }, "caveat": "SAMA's explanation is ISO's own definition of this code (ISO 20022 ExternalReturnReason1Code, 2Q2026). This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "related": [ "gcc-afaq-return:RR01", "gcc-afaq-return:NOCM", "gcc-afaq-return:PPCI", "gcc-afaq-return:FR01", "sepa-sct:RR04" ], "basis": { "sources": "SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service (2021-05-05, 24/9/1442 H, In-Force), read in full on rulebook.sama.gov.sa on 2026-09-18: Appendix 2, table of returned payments, entry for RR04; sections 5.1 item 6, 5.3, 7.3, 7.8, 7.9, 7.15. SAMA circular 43038107, Charging Policy for Cross Currency Payments Using AFAQ Service (2021-12-02), section 4.2 and Appendix 2. ISO 20022 External Code Sets 2Q2026 (2Q2026_externalcodesets_v3.json, downloaded 2026-09-18), compared by script. SAMA gives one line per code and no usage guidance, so triggers and actions beyond that line are inference.", "confidence": "medium" }, "currency": { "effective_since": "2021-05-05", "effective_note": "Date of SAMA circular 42068309 (24/9/1442 H), In-Force when read on 2026-09-18. The portal's Versions block shows date ranges that end before they begin, so no later edition can be read from it. The appendix says returned codes are registered in the AFAQ Central Component dictionary, which may be updated from time to time, so the live list may differ from the published one [Inference].", "source_edition": "SAMA circular 42068309 (2021-05-05), Appendix 2", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://rulebook.sama.gov.sa/en/appendix-2-return-and-rejection-codes", "source_class": "public_primary", "source_title": "Appendix 2 - Return and Rejection Codes (SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-18", "notes": "Appendix 2 of SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service, lists RR04 with the meaning this record states. SAMA's Operating Rules, sections 7.8 and 7.9, confirm the return limits the record gives: an outer limit of 2 business days, counted only on days that both countries work, with an earlier expected deadline; no compensation for holding the funds inside that limit; and refusal by the Central Component of a return that is late, a duplicate, or inconsistent with the original payment. Section 5.1 item 6 confirms the exchange period accepts returns. SAMA's Charging Policy for Cross Currency Payments Using AFAQ Service, circular 43038107, section 4.2, confirms the SAR 100 penalty for a late return." } ] }, "rail_name": "AFAQ Returns (SAMA rules for Saudi participants)", "governing_authority": "Saudi Central Bank (SAMA), for its direct participants; AFAQ is owned by the six GCC central banks and run by the Gulf Payments Company", "snapshot": "2026-09-18", "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "judgement", "label": "your bank's own terms", "needs": "whose terms decide it: the bank's, the participant's or the scheme's", "detail": "This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "from": "caveat" } ] }, { "uid": "gcc-afaq-return:RUTA", "id": "RUTA", "rail": "gcc-afaq-return", "kind": "reason-code", "name": "Returned after an investigation found no fix", "group": "administrative", "summary": "Someone queried the payment, the query was looked into, and no remedy turned up, so the money goes back.", "triggers": [ "A query or investigation about the payment ended without a remedy, for example beneficiary details could not be confirmed [Inference]" ], "actions": [ "Sending participant: start again with confirmed details if a payment is still due [Inference]", "Receiving participant: send back the original amounts at the original exchange rate, in both currencies and with nothing taken off, as one message whose field 72 carries the original payment's reference (OR 7.8, 7.9)", "Receiving participant: expect the Central Component to refuse the return if it differs from the original in amount, currency or rate, repeats a return already accepted, comes too late, or points at an original it cannot find (OR 7.9)" ], "retry": { "allowed": true, "rule": "Yes, as a new payment. A returned payment may not be sent again under its original Unique Message Reference; once the cause is fixed the sending participant may send it as a new payment with a new Unique Message Reference, and may keep the same UETR (OR 7.3). That sentence sits in the paragraph on rejections and is read here as covering returns too [Inference]." }, "facts": { "return_windows": [ { "action": "return the payment with this reason", "by": "Receiving direct participant (a Saudi participant under SAMA's rules)", "deadline": "Best on the business day the payment arrived; if not, by that payment type's cut-off on the next business day; never later than 2 business days after receipt, counting only days that are business days in both the sending and the receiving country (OR 7.8, 7.9, 5.3). Inside that time no compensation for use of the funds is owed (OR 7.8). The Central Component refuses a return after 2 business days (OR 7.9), and SAMA charges SAR 100 per payment message returned late, possibly plus an amount-based charge (CP 4.2, CP Appendix 2)." } ], "applies_to": "AFAQ cross-currency service, under SAMA's rules for Saudi direct participants: a return payment sent by the receiving direct participant for a payment it received through AFAQ and could not credit (OR 7.8), in the exchange period that accepts returns (OR 5.1 item 6)." }, "caveat": "How investigations work between AFAQ participants is not described in SAMA's rules; the return time limit still applies (OR 7.9) [Inference]. SAMA's explanation is ISO's own definition of this code (ISO 20022 ExternalReturnReason1Code, 2Q2026). This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "related": [ "gcc-afaq-return:NOAS", "gcc-afaq-return:NARR" ], "basis": { "sources": "SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service (2021-05-05, 24/9/1442 H, In-Force), read in full on rulebook.sama.gov.sa on 2026-09-18: Appendix 2, table of returned payments, entry for RUTA; sections 5.1 item 6, 5.3, 7.3, 7.8, 7.9. SAMA circular 43038107, Charging Policy for Cross Currency Payments Using AFAQ Service (2021-12-02), section 4.2 and Appendix 2. ISO 20022 External Code Sets 2Q2026 (2Q2026_externalcodesets_v3.json, downloaded 2026-09-18), compared by script. SAMA gives one line per code and no usage guidance, so triggers and actions beyond that line are inference.", "confidence": "medium" }, "currency": { "effective_since": "2021-05-05", "effective_note": "Date of SAMA circular 42068309 (24/9/1442 H), In-Force when read on 2026-09-18. The portal's Versions block shows date ranges that end before they begin, so no later edition can be read from it. The appendix says returned codes are registered in the AFAQ Central Component dictionary, which may be updated from time to time, so the live list may differ from the published one [Inference].", "source_edition": "SAMA circular 42068309 (2021-05-05), Appendix 2", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://rulebook.sama.gov.sa/en/appendix-2-return-and-rejection-codes", "source_class": "public_primary", "source_title": "Appendix 2 - Return and Rejection Codes (SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-18", "notes": "Appendix 2 of SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service, lists RUTA with the meaning this record states. SAMA's Operating Rules, sections 7.8 and 7.9, confirm the return limits the record gives: an outer limit of 2 business days, counted only on days that both countries work, with an earlier expected deadline; no compensation for holding the funds inside that limit; and refusal by the Central Component of a return that is late, a duplicate, or inconsistent with the original payment. Section 5.1 item 6 confirms the exchange period accepts returns. SAMA's Charging Policy for Cross Currency Payments Using AFAQ Service, circular 43038107, section 4.2, confirms the SAR 100 penalty for a late return." } ] }, "rail_name": "AFAQ Returns (SAMA rules for Saudi participants)", "governing_authority": "Saudi Central Bank (SAMA), for its direct participants; AFAQ is owned by the six GCC central banks and run by the Gulf Payments Company", "snapshot": "2026-09-18", "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "judgement", "label": "your bank's own terms", "needs": "whose terms decide it: the bank's, the participant's or the scheme's", "detail": "This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "from": "caveat" } ] }, { "uid": "gcc-afaq-return:SL01", "id": "SL01", "rail": "gcc-afaq-return", "kind": "reason-code", "name": "Feature of the payer's bank", "group": "administrative", "summary": "ISO's code tying a return to a feature the payer's (debtor's) bank offers its customer. In an AFAQ credit, the debtor's bank is the sending participant, so a return by the receiving participant with this code does not fit well [Inference].", "triggers": [ "SAMA does not say when this applies on AFAQ [Inference]" ], "actions": [ "Sending participant: ask the receiving participant what it meant [Inference]", "Receiving participant: send back the original amounts at the original exchange rate, in both currencies and with nothing taken off, as one message whose field 72 carries the original payment's reference (OR 7.8, 7.9)", "Receiving participant: expect the Central Component to refuse the return if it differs from the original in amount, currency or rate, repeats a return already accepted, comes too late, or points at an original it cannot find (OR 7.9)" ], "retry": { "allowed": true, "rule": "Not barred. Nothing in SAMA's rules stops a new payment once the cause is dealt with; it goes out with a new Unique Message Reference and may keep the UETR (OR 7.3) [Inference: the OR 7.3 sentence is written for rejections]. Only one successful return is allowed per payment (OR 7.9)." }, "facts": { "return_windows": [ { "action": "return the payment with this reason", "by": "Receiving direct participant (a Saudi participant under SAMA's rules)", "deadline": "Best on the business day the payment arrived; if not, by that payment type's cut-off on the next business day; never later than 2 business days after receipt, counting only days that are business days in both the sending and the receiving country (OR 7.8, 7.9, 5.3). Inside that time no compensation for use of the funds is owed (OR 7.8). The Central Component refuses a return after 2 business days (OR 7.9), and SAMA charges SAR 100 per payment message returned late, possibly plus an amount-based charge (CP 4.2, CP Appendix 2)." } ], "applies_to": "AFAQ cross-currency service, under SAMA's rules for Saudi direct participants: a return payment sent by the receiving direct participant for a payment it received through AFAQ and could not credit (OR 7.8), in the exchange period that accepts returns (OR 5.1 item 6)." }, "caveat": "In ISO use the code serves mainly direct debits, which AFAQ does not carry (OR 7.2) [Inference]. SAMA's explanation is ISO's own definition of this code (ISO 20022 ExternalReturnReason1Code, 2Q2026). This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "related": [ "gcc-afaq-return:SL02", "gcc-afaq-return:SL11" ], "basis": { "sources": "SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service (2021-05-05, 24/9/1442 H, In-Force), read in full on rulebook.sama.gov.sa on 2026-09-18: Appendix 2, table of returned payments, entry for SL01; sections 5.1 item 6, 5.3, 7.3, 7.8, 7.9, 7.2. SAMA circular 43038107, Charging Policy for Cross Currency Payments Using AFAQ Service (2021-12-02), section 4.2 and Appendix 2. ISO 20022 External Code Sets 2Q2026 (2Q2026_externalcodesets_v3.json, downloaded 2026-09-18), compared by script. SAMA gives one line per code and no usage guidance, so triggers and actions beyond that line are inference.", "confidence": "low" }, "currency": { "effective_since": "2021-05-05", "effective_note": "Date of SAMA circular 42068309 (24/9/1442 H), In-Force when read on 2026-09-18. The portal's Versions block shows date ranges that end before they begin, so no later edition can be read from it. The appendix says returned codes are registered in the AFAQ Central Component dictionary, which may be updated from time to time, so the live list may differ from the published one [Inference].", "source_edition": "SAMA circular 42068309 (2021-05-05), Appendix 2", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://rulebook.sama.gov.sa/en/appendix-2-return-and-rejection-codes", "source_class": "public_primary", "source_title": "Appendix 2 - Return and Rejection Codes (SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-18", "notes": "Appendix 2 of SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service, lists SL01 with the meaning this record states. SAMA's Operating Rules, sections 7.8 and 7.9, confirm the return limits the record gives: an outer limit of 2 business days, counted only on days that both countries work, with an earlier expected deadline; no compensation for holding the funds inside that limit; and refusal by the Central Component of a return that is late, a duplicate, or inconsistent with the original payment. Section 5.1 item 6 confirms the exchange period accepts returns. SAMA's Charging Policy for Cross Currency Payments Using AFAQ Service, circular 43038107, section 4.2, confirms the SAR 100 penalty for a late return. Section 7.2 confirms AFAQ carries single credit payments only, with no direct debit, supporting the record's caveat that this code does not fit an AFAQ credit well." } ] }, "rail_name": "AFAQ Returns (SAMA rules for Saudi participants)", "governing_authority": "Saudi Central Bank (SAMA), for its direct participants; AFAQ is owned by the six GCC central banks and run by the Gulf Payments Company", "snapshot": "2026-09-18", "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "judgement", "label": "your bank's own terms", "needs": "whose terms decide it: the bank's, the participant's or the scheme's", "detail": "This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "from": "caveat" } ] }, { "uid": "gcc-afaq-return:SL02", "id": "SL02", "rail": "gcc-afaq-return", "kind": "reason-code", "name": "Feature of the beneficiary's bank", "group": "administrative", "summary": "A feature the receiving participant (the creditor's bank) offers its customer, such as a filter the beneficiary has set, is why the payment goes back [Inference].", "triggers": [ "A customer service at the receiving participant, for example a block on certain payers or payment types, stops the credit [Inference]" ], "actions": [ "Sending participant: tell the payer, who can ask the beneficiary to change the setting [Inference]", "Receiving participant: send back the original amounts at the original exchange rate, in both currencies and with nothing taken off, as one message whose field 72 carries the original payment's reference (OR 7.8, 7.9)", "Receiving participant: expect the Central Component to refuse the return if it differs from the original in amount, currency or rate, repeats a return already accepted, comes too late, or points at an original it cannot find (OR 7.9)" ], "retry": { "allowed": true, "rule": "Not barred. Nothing in SAMA's rules stops a new payment once the cause is dealt with; it goes out with a new Unique Message Reference and may keep the UETR (OR 7.3) [Inference: the OR 7.3 sentence is written for rejections]. Only one successful return is allowed per payment (OR 7.9)." }, "facts": { "return_windows": [ { "action": "return the payment with this reason", "by": "Receiving direct participant (a Saudi participant under SAMA's rules)", "deadline": "Best on the business day the payment arrived; if not, by that payment type's cut-off on the next business day; never later than 2 business days after receipt, counting only days that are business days in both the sending and the receiving country (OR 7.8, 7.9, 5.3). Inside that time no compensation for use of the funds is owed (OR 7.8). The Central Component refuses a return after 2 business days (OR 7.9), and SAMA charges SAR 100 per payment message returned late, possibly plus an amount-based charge (CP 4.2, CP Appendix 2)." } ], "applies_to": "AFAQ cross-currency service, under SAMA's rules for Saudi direct participants: a return payment sent by the receiving direct participant for a payment it received through AFAQ and could not credit (OR 7.8), in the exchange period that accepts returns (OR 5.1 item 6)." }, "caveat": "SAMA's explanation is ISO's own definition of this code (ISO 20022 ExternalReturnReason1Code, 2Q2026). This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "related": [ "gcc-afaq-return:SL01", "gcc-afaq-return:SP01" ], "basis": { "sources": "SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service (2021-05-05, 24/9/1442 H, In-Force), read in full on rulebook.sama.gov.sa on 2026-09-18: Appendix 2, table of returned payments, entry for SL02; sections 5.1 item 6, 5.3, 7.3, 7.8, 7.9. SAMA circular 43038107, Charging Policy for Cross Currency Payments Using AFAQ Service (2021-12-02), section 4.2 and Appendix 2. ISO 20022 External Code Sets 2Q2026 (2Q2026_externalcodesets_v3.json, downloaded 2026-09-18), compared by script. SAMA gives one line per code and no usage guidance, so triggers and actions beyond that line are inference.", "confidence": "medium" }, "currency": { "effective_since": "2021-05-05", "effective_note": "Date of SAMA circular 42068309 (24/9/1442 H), In-Force when read on 2026-09-18. The portal's Versions block shows date ranges that end before they begin, so no later edition can be read from it. The appendix says returned codes are registered in the AFAQ Central Component dictionary, which may be updated from time to time, so the live list may differ from the published one [Inference].", "source_edition": "SAMA circular 42068309 (2021-05-05), Appendix 2", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://rulebook.sama.gov.sa/en/appendix-2-return-and-rejection-codes", "source_class": "public_primary", "source_title": "Appendix 2 - Return and Rejection Codes (SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-18", "notes": "Appendix 2 of SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service, lists SL02 with the meaning this record states. SAMA's Operating Rules, sections 7.8 and 7.9, confirm the return limits the record gives: an outer limit of 2 business days, counted only on days that both countries work, with an earlier expected deadline; no compensation for holding the funds inside that limit; and refusal by the Central Component of a return that is late, a duplicate, or inconsistent with the original payment. Section 5.1 item 6 confirms the exchange period accepts returns. SAMA's Charging Policy for Cross Currency Payments Using AFAQ Service, circular 43038107, section 4.2, confirms the SAR 100 penalty for a late return. Section 7.2 confirms AFAQ carries single credit payments only, with no direct debit, supporting the record's caveat that this code does not fit an AFAQ credit well." } ] }, "rail_name": "AFAQ Returns (SAMA rules for Saudi participants)", "governing_authority": "Saudi Central Bank (SAMA), for its direct participants; AFAQ is owned by the six GCC central banks and run by the Gulf Payments Company", "snapshot": "2026-09-18", "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "judgement", "label": "your bank's own terms", "needs": "whose terms decide it: the bank's, the participant's or the scheme's", "detail": "This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "from": "caveat" } ] }, { "uid": "gcc-afaq-return:SL11", "id": "SL11", "rail": "gcc-afaq-return", "kind": "reason-code", "name": "Creditor not on the payer's whitelist (direct debit code)", "group": "authorization", "summary": "ISO's direct debit code for a debit refused because the payer has not put the collecting creditor on its bank's list of allowed creditors. SAMA copied the ISO wording, whitelist and all; on AFAQ there are no direct debits to refuse.", "triggers": [ "None expected on AFAQ; SAMA lists the code without saying when it applies [Inference]" ], "actions": [ "Sending participant: ask the receiving participant what it meant; the code's direct debit meaning does not fit an AFAQ credit [Inference]", "Receiving participant: send back the original amounts at the original exchange rate, in both currencies and with nothing taken off, as one message whose field 72 carries the original payment's reference (OR 7.8, 7.9)", "Receiving participant: expect the Central Component to refuse the return if it differs from the original in amount, currency or rate, repeats a return already accepted, comes too late, or points at an original it cannot find (OR 7.9)" ], "retry": { "allowed": true, "rule": "Not barred. Nothing in SAMA's rules stops a new payment once the cause is dealt with; it goes out with a new Unique Message Reference and may keep the UETR (OR 7.3) [Inference: the OR 7.3 sentence is written for rejections]. Only one successful return is allowed per payment (OR 7.9)." }, "facts": { "return_windows": [ { "action": "return the payment with this reason", "by": "Receiving direct participant (a Saudi participant under SAMA's rules)", "deadline": "Best on the business day the payment arrived; if not, by that payment type's cut-off on the next business day; never later than 2 business days after receipt, counting only days that are business days in both the sending and the receiving country (OR 7.8, 7.9, 5.3). Inside that time no compensation for use of the funds is owed (OR 7.8). The Central Component refuses a return after 2 business days (OR 7.9), and SAMA charges SAR 100 per payment message returned late, possibly plus an amount-based charge (CP 4.2, CP Appendix 2)." } ], "applies_to": "Listed for the AFAQ cross-currency service under SAMA's rules for Saudi direct participants, although AFAQ carries only single credit payments (OR 7.2); a return by the receiving direct participant (OR 7.8)." }, "caveat": "This is a direct debit code listed on a credit-only system: AFAQ carries single credit payments only (OR 7.2) and has no direct debit, so no ordinary AFAQ payment should draw it [Inference]. SAMA's explanation is ISO's own definition of this code (ISO 20022 ExternalReturnReason1Code, 2Q2026). This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "related": [ "gcc-afaq-return:SL12", "gcc-afaq-return:SL13", "gcc-afaq-return:SL14", "gcc-afaq-return:SL01" ], "basis": { "sources": "SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service (2021-05-05, 24/9/1442 H, In-Force), read in full on rulebook.sama.gov.sa on 2026-09-18: Appendix 2, table of returned payments, entry for SL11; sections 5.1 item 6, 5.3, 7.3, 7.8, 7.9, 7.2. SAMA circular 43038107, Charging Policy for Cross Currency Payments Using AFAQ Service (2021-12-02), section 4.2 and Appendix 2. ISO 20022 External Code Sets 2Q2026 (2Q2026_externalcodesets_v3.json, downloaded 2026-09-18), compared by script. SAMA gives one line per code and no usage guidance, so triggers and actions beyond that line are inference.", "confidence": "low" }, "currency": { "effective_since": "2021-05-05", "effective_note": "Date of SAMA circular 42068309 (24/9/1442 H), In-Force when read on 2026-09-18. The portal's Versions block shows date ranges that end before they begin, so no later edition can be read from it. The appendix says returned codes are registered in the AFAQ Central Component dictionary, which may be updated from time to time, so the live list may differ from the published one [Inference].", "source_edition": "SAMA circular 42068309 (2021-05-05), Appendix 2", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://rulebook.sama.gov.sa/en/appendix-2-return-and-rejection-codes", "source_class": "public_primary", "source_title": "Appendix 2 - Return and Rejection Codes (SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-18", "notes": "Appendix 2 of SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service, lists SL11 with the meaning this record states. SAMA's Operating Rules, sections 7.8 and 7.9, confirm the return limits the record gives: an outer limit of 2 business days, counted only on days that both countries work, with an earlier expected deadline; no compensation for holding the funds inside that limit; and refusal by the Central Component of a return that is late, a duplicate, or inconsistent with the original payment. Section 5.1 item 6 confirms the exchange period accepts returns. SAMA's Charging Policy for Cross Currency Payments Using AFAQ Service, circular 43038107, section 4.2, confirms the SAR 100 penalty for a late return. Section 7.2 confirms AFAQ carries single credit payments only, with no direct debit, supporting the record's caveat that this direct debit code has no ordinary use on AFAQ." } ] }, "rail_name": "AFAQ Returns (SAMA rules for Saudi participants)", "governing_authority": "Saudi Central Bank (SAMA), for its direct participants; AFAQ is owned by the six GCC central banks and run by the Gulf Payments Company", "snapshot": "2026-09-18", "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "judgement", "label": "your bank's own terms", "needs": "whose terms decide it: the bank's, the participant's or the scheme's", "detail": "This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "from": "caveat" } ] }, { "uid": "gcc-afaq-return:SL12", "id": "SL12", "rail": "gcc-afaq-return", "kind": "reason-code", "name": "Creditor on the payer's blacklist (direct debit code)", "group": "authorization", "summary": "ISO's direct debit code for a debit refused because the payer has barred the collecting creditor at its bank. SAMA copied the ISO wording, blacklist and all; on AFAQ there are no direct debits to refuse.", "triggers": [ "None expected on AFAQ; SAMA lists the code without saying when it applies [Inference]" ], "actions": [ "Sending participant: ask the receiving participant what it meant; the code's direct debit meaning does not fit an AFAQ credit [Inference]", "Receiving participant: send back the original amounts at the original exchange rate, in both currencies and with nothing taken off, as one message whose field 72 carries the original payment's reference (OR 7.8, 7.9)", "Receiving participant: expect the Central Component to refuse the return if it differs from the original in amount, currency or rate, repeats a return already accepted, comes too late, or points at an original it cannot find (OR 7.9)" ], "retry": { "allowed": true, "rule": "Not barred. Nothing in SAMA's rules stops a new payment once the cause is dealt with; it goes out with a new Unique Message Reference and may keep the UETR (OR 7.3) [Inference: the OR 7.3 sentence is written for rejections]. Only one successful return is allowed per payment (OR 7.9)." }, "facts": { "return_windows": [ { "action": "return the payment with this reason", "by": "Receiving direct participant (a Saudi participant under SAMA's rules)", "deadline": "Best on the business day the payment arrived; if not, by that payment type's cut-off on the next business day; never later than 2 business days after receipt, counting only days that are business days in both the sending and the receiving country (OR 7.8, 7.9, 5.3). Inside that time no compensation for use of the funds is owed (OR 7.8). The Central Component refuses a return after 2 business days (OR 7.9), and SAMA charges SAR 100 per payment message returned late, possibly plus an amount-based charge (CP 4.2, CP Appendix 2)." } ], "applies_to": "Listed for the AFAQ cross-currency service under SAMA's rules for Saudi direct participants, although AFAQ carries only single credit payments (OR 7.2); a return by the receiving direct participant (OR 7.8)." }, "caveat": "This is a direct debit code listed on a credit-only system: AFAQ carries single credit payments only (OR 7.2) and has no direct debit, so no ordinary AFAQ payment should draw it [Inference]. SAMA's explanation is ISO's own definition of this code (ISO 20022 ExternalReturnReason1Code, 2Q2026). This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "related": [ "gcc-afaq-return:SL11", "gcc-afaq-return:SL13", "gcc-afaq-return:SL14", "gcc-afaq-return:SL01" ], "basis": { "sources": "SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service (2021-05-05, 24/9/1442 H, In-Force), read in full on rulebook.sama.gov.sa on 2026-09-18: Appendix 2, table of returned payments, entry for SL12; sections 5.1 item 6, 5.3, 7.3, 7.8, 7.9, 7.2. SAMA circular 43038107, Charging Policy for Cross Currency Payments Using AFAQ Service (2021-12-02), section 4.2 and Appendix 2. ISO 20022 External Code Sets 2Q2026 (2Q2026_externalcodesets_v3.json, downloaded 2026-09-18), compared by script. SAMA gives one line per code and no usage guidance, so triggers and actions beyond that line are inference.", "confidence": "low" }, "currency": { "effective_since": "2021-05-05", "effective_note": "Date of SAMA circular 42068309 (24/9/1442 H), In-Force when read on 2026-09-18. The portal's Versions block shows date ranges that end before they begin, so no later edition can be read from it. The appendix says returned codes are registered in the AFAQ Central Component dictionary, which may be updated from time to time, so the live list may differ from the published one [Inference].", "source_edition": "SAMA circular 42068309 (2021-05-05), Appendix 2", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://rulebook.sama.gov.sa/en/appendix-2-return-and-rejection-codes", "source_class": "public_primary", "source_title": "Appendix 2 - Return and Rejection Codes (SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-18", "notes": "Appendix 2 of SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service, lists SL12 with the meaning this record states. SAMA's Operating Rules, sections 7.8 and 7.9, confirm the return limits the record gives: an outer limit of 2 business days, counted only on days that both countries work, with an earlier expected deadline; no compensation for holding the funds inside that limit; and refusal by the Central Component of a return that is late, a duplicate, or inconsistent with the original payment. Section 5.1 item 6 confirms the exchange period accepts returns. SAMA's Charging Policy for Cross Currency Payments Using AFAQ Service, circular 43038107, section 4.2, confirms the SAR 100 penalty for a late return. Section 7.2 confirms AFAQ carries single credit payments only, with no direct debit, supporting the record's caveat that this direct debit code has no ordinary use on AFAQ." } ] }, "rail_name": "AFAQ Returns (SAMA rules for Saudi participants)", "governing_authority": "Saudi Central Bank (SAMA), for its direct participants; AFAQ is owned by the six GCC central banks and run by the Gulf Payments Company", "snapshot": "2026-09-18", "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "judgement", "label": "your bank's own terms", "needs": "whose terms decide it: the bank's, the participant's or the scheme's", "detail": "This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "from": "caveat" } ] }, { "uid": "gcc-afaq-return:SL13", "id": "SL13", "rail": "gcc-afaq-return", "kind": "reason-code", "name": "Too many direct debits in the period (direct debit code)", "group": "authorization", "summary": "ISO's direct debit code for a debit refused because it would exceed the number of direct debits the payer's bank allows in a period. On AFAQ there are no direct debits.", "triggers": [ "None expected on AFAQ; SAMA lists the code without saying when it applies [Inference]" ], "actions": [ "Sending participant: ask the receiving participant what it meant; the code's direct debit meaning does not fit an AFAQ credit [Inference]", "Receiving participant: send back the original amounts at the original exchange rate, in both currencies and with nothing taken off, as one message whose field 72 carries the original payment's reference (OR 7.8, 7.9)", "Receiving participant: expect the Central Component to refuse the return if it differs from the original in amount, currency or rate, repeats a return already accepted, comes too late, or points at an original it cannot find (OR 7.9)" ], "retry": { "allowed": true, "rule": "Not barred. Nothing in SAMA's rules stops a new payment once the cause is dealt with; it goes out with a new Unique Message Reference and may keep the UETR (OR 7.3) [Inference: the OR 7.3 sentence is written for rejections]. Only one successful return is allowed per payment (OR 7.9)." }, "facts": { "return_windows": [ { "action": "return the payment with this reason", "by": "Receiving direct participant (a Saudi participant under SAMA's rules)", "deadline": "Best on the business day the payment arrived; if not, by that payment type's cut-off on the next business day; never later than 2 business days after receipt, counting only days that are business days in both the sending and the receiving country (OR 7.8, 7.9, 5.3). Inside that time no compensation for use of the funds is owed (OR 7.8). The Central Component refuses a return after 2 business days (OR 7.9), and SAMA charges SAR 100 per payment message returned late, possibly plus an amount-based charge (CP 4.2, CP Appendix 2)." } ], "applies_to": "Listed for the AFAQ cross-currency service under SAMA's rules for Saudi direct participants, although AFAQ carries only single credit payments (OR 7.2); a return by the receiving direct participant (OR 7.8)." }, "caveat": "This is a direct debit code listed on a credit-only system: AFAQ carries single credit payments only (OR 7.2) and has no direct debit, so no ordinary AFAQ payment should draw it [Inference]. SAMA's explanation is ISO's own definition of this code (ISO 20022 ExternalReturnReason1Code, 2Q2026). This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "related": [ "gcc-afaq-return:SL11", "gcc-afaq-return:SL12", "gcc-afaq-return:SL14" ], "basis": { "sources": "SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service (2021-05-05, 24/9/1442 H, In-Force), read in full on rulebook.sama.gov.sa on 2026-09-18: Appendix 2, table of returned payments, entry for SL13; sections 5.1 item 6, 5.3, 7.3, 7.8, 7.9, 7.2. SAMA circular 43038107, Charging Policy for Cross Currency Payments Using AFAQ Service (2021-12-02), section 4.2 and Appendix 2. ISO 20022 External Code Sets 2Q2026 (2Q2026_externalcodesets_v3.json, downloaded 2026-09-18), compared by script. SAMA gives one line per code and no usage guidance, so triggers and actions beyond that line are inference.", "confidence": "low" }, "currency": { "effective_since": "2021-05-05", "effective_note": "Date of SAMA circular 42068309 (24/9/1442 H), In-Force when read on 2026-09-18. The portal's Versions block shows date ranges that end before they begin, so no later edition can be read from it. The appendix says returned codes are registered in the AFAQ Central Component dictionary, which may be updated from time to time, so the live list may differ from the published one [Inference].", "source_edition": "SAMA circular 42068309 (2021-05-05), Appendix 2", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://rulebook.sama.gov.sa/en/appendix-2-return-and-rejection-codes", "source_class": "public_primary", "source_title": "Appendix 2 - Return and Rejection Codes (SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-18", "notes": "Appendix 2 of SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service, lists SL13 with the meaning this record states. SAMA's Operating Rules, sections 7.8 and 7.9, confirm the return limits the record gives: an outer limit of 2 business days, counted only on days that both countries work, with an earlier expected deadline; no compensation for holding the funds inside that limit; and refusal by the Central Component of a return that is late, a duplicate, or inconsistent with the original payment. Section 5.1 item 6 confirms the exchange period accepts returns. SAMA's Charging Policy for Cross Currency Payments Using AFAQ Service, circular 43038107, section 4.2, confirms the SAR 100 penalty for a late return. Section 7.2 confirms AFAQ carries single credit payments only, with no direct debit, supporting the record's caveat that this direct debit code has no ordinary use on AFAQ." } ] }, "rail_name": "AFAQ Returns (SAMA rules for Saudi participants)", "governing_authority": "Saudi Central Bank (SAMA), for its direct participants; AFAQ is owned by the six GCC central banks and run by the Gulf Payments Company", "snapshot": "2026-09-18", "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "judgement", "label": "your bank's own terms", "needs": "whose terms decide it: the bank's, the participant's or the scheme's", "detail": "This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "from": "caveat" } ] }, { "uid": "gcc-afaq-return:SL14", "id": "SL14", "rail": "gcc-afaq-return", "kind": "reason-code", "name": "Direct debit above the allowed amount (direct debit code)", "group": "authorization", "summary": "ISO's direct debit code for a debit refused because it exceeds the largest direct debit amount the payer's bank allows. On AFAQ there are no direct debits.", "triggers": [ "None expected on AFAQ; SAMA lists the code without saying when it applies [Inference]" ], "actions": [ "Sending participant: ask the receiving participant what it meant; the code's direct debit meaning does not fit an AFAQ credit [Inference]", "Receiving participant: send back the original amounts at the original exchange rate, in both currencies and with nothing taken off, as one message whose field 72 carries the original payment's reference (OR 7.8, 7.9)", "Receiving participant: expect the Central Component to refuse the return if it differs from the original in amount, currency or rate, repeats a return already accepted, comes too late, or points at an original it cannot find (OR 7.9)" ], "retry": { "allowed": true, "rule": "Not barred. Nothing in SAMA's rules stops a new payment once the cause is dealt with; it goes out with a new Unique Message Reference and may keep the UETR (OR 7.3) [Inference: the OR 7.3 sentence is written for rejections]. Only one successful return is allowed per payment (OR 7.9)." }, "facts": { "return_windows": [ { "action": "return the payment with this reason", "by": "Receiving direct participant (a Saudi participant under SAMA's rules)", "deadline": "Best on the business day the payment arrived; if not, by that payment type's cut-off on the next business day; never later than 2 business days after receipt, counting only days that are business days in both the sending and the receiving country (OR 7.8, 7.9, 5.3). Inside that time no compensation for use of the funds is owed (OR 7.8). The Central Component refuses a return after 2 business days (OR 7.9), and SAMA charges SAR 100 per payment message returned late, possibly plus an amount-based charge (CP 4.2, CP Appendix 2)." } ], "applies_to": "Listed for the AFAQ cross-currency service under SAMA's rules for Saudi direct participants, although AFAQ carries only single credit payments (OR 7.2); a return by the receiving direct participant (OR 7.8)." }, "caveat": "This is a direct debit code listed on a credit-only system: AFAQ carries single credit payments only (OR 7.2) and has no direct debit, so no ordinary AFAQ payment should draw it [Inference]. SAMA's explanation is ISO's own definition of this code (ISO 20022 ExternalReturnReason1Code, 2Q2026). This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "related": [ "gcc-afaq-return:SL11", "gcc-afaq-return:SL12", "gcc-afaq-return:SL13" ], "basis": { "sources": "SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service (2021-05-05, 24/9/1442 H, In-Force), read in full on rulebook.sama.gov.sa on 2026-09-18: Appendix 2, table of returned payments, entry for SL14; sections 5.1 item 6, 5.3, 7.3, 7.8, 7.9, 7.2. SAMA circular 43038107, Charging Policy for Cross Currency Payments Using AFAQ Service (2021-12-02), section 4.2 and Appendix 2. ISO 20022 External Code Sets 2Q2026 (2Q2026_externalcodesets_v3.json, downloaded 2026-09-18), compared by script. SAMA gives one line per code and no usage guidance, so triggers and actions beyond that line are inference.", "confidence": "low" }, "currency": { "effective_since": "2021-05-05", "effective_note": "Date of SAMA circular 42068309 (24/9/1442 H), In-Force when read on 2026-09-18. The portal's Versions block shows date ranges that end before they begin, so no later edition can be read from it. The appendix says returned codes are registered in the AFAQ Central Component dictionary, which may be updated from time to time, so the live list may differ from the published one [Inference].", "source_edition": "SAMA circular 42068309 (2021-05-05), Appendix 2", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://rulebook.sama.gov.sa/en/appendix-2-return-and-rejection-codes", "source_class": "public_primary", "source_title": "Appendix 2 - Return and Rejection Codes (SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-18", "notes": "Appendix 2 of SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service, lists SL14 with the meaning this record states. SAMA's Operating Rules, sections 7.8 and 7.9, confirm the return limits the record gives: an outer limit of 2 business days, counted only on days that both countries work, with an earlier expected deadline; no compensation for holding the funds inside that limit; and refusal by the Central Component of a return that is late, a duplicate, or inconsistent with the original payment. Section 5.1 item 6 confirms the exchange period accepts returns. SAMA's Charging Policy for Cross Currency Payments Using AFAQ Service, circular 43038107, section 4.2, confirms the SAR 100 penalty for a late return. Section 7.2 confirms AFAQ carries single credit payments only, with no direct debit, supporting the record's caveat that this direct debit code has no ordinary use on AFAQ." } ] }, "rail_name": "AFAQ Returns (SAMA rules for Saudi participants)", "governing_authority": "Saudi Central Bank (SAMA), for its direct participants; AFAQ is owned by the six GCC central banks and run by the Gulf Payments Company", "snapshot": "2026-09-18", "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "judgement", "label": "your bank's own terms", "needs": "whose terms decide it: the bank's, the participant's or the scheme's", "detail": "This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "from": "caveat" } ] }, { "uid": "gcc-afaq-return:SP01", "id": "SP01", "rail": "gcc-afaq-return", "kind": "reason-code", "name": "Payment stopped by the account holder", "group": "authorization", "summary": "ISO's code for a stop placed by the holder of the account. On a credit, the account holder at the receiving participant is the beneficiary, so read it as the beneficiary refusing this payment [Inference].", "triggers": [ "The beneficiary told its bank not to accept the payment [Inference]" ], "actions": [ "Sending participant: tell the payer [Inference]", "Receiving participant: send back the original amounts at the original exchange rate, in both currencies and with nothing taken off, as one message whose field 72 carries the original payment's reference (OR 7.8, 7.9)", "Receiving participant: expect the Central Component to refuse the return if it differs from the original in amount, currency or rate, repeats a return already accepted, comes too late, or points at an original it cannot find (OR 7.9)" ], "retry": { "allowed": false, "rule": "Not without the beneficiary's agreement [Inference]." }, "facts": { "return_windows": [ { "action": "return the payment with this reason", "by": "Receiving direct participant (a Saudi participant under SAMA's rules)", "deadline": "Best on the business day the payment arrived; if not, by that payment type's cut-off on the next business day; never later than 2 business days after receipt, counting only days that are business days in both the sending and the receiving country (OR 7.8, 7.9, 5.3). Inside that time no compensation for use of the funds is owed (OR 7.8). The Central Component refuses a return after 2 business days (OR 7.9), and SAMA charges SAR 100 per payment message returned late, possibly plus an amount-based charge (CP 4.2, CP Appendix 2)." } ], "applies_to": "AFAQ cross-currency service, under SAMA's rules for Saudi direct participants: a return payment sent by the receiving direct participant for a payment it received through AFAQ and could not credit (OR 7.8), in the exchange period that accepts returns (OR 5.1 item 6)." }, "caveat": "SAMA's explanation is ISO's own definition of this code (ISO 20022 ExternalReturnReason1Code, 2Q2026). This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "related": [ "gcc-afaq-return:SP02", "gcc-afaq-return:MS02", "gcc-afaq-return:CUST" ], "basis": { "sources": "SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service (2021-05-05, 24/9/1442 H, In-Force), read in full on rulebook.sama.gov.sa on 2026-09-18: Appendix 2, table of returned payments, entry for SP01; sections 5.1 item 6, 5.3, 7.3, 7.8, 7.9. SAMA circular 43038107, Charging Policy for Cross Currency Payments Using AFAQ Service (2021-12-02), section 4.2 and Appendix 2. ISO 20022 External Code Sets 2Q2026 (2Q2026_externalcodesets_v3.json, downloaded 2026-09-18), compared by script. SAMA gives one line per code and no usage guidance, so triggers and actions beyond that line are inference.", "confidence": "low" }, "currency": { "effective_since": "2021-05-05", "effective_note": "Date of SAMA circular 42068309 (24/9/1442 H), In-Force when read on 2026-09-18. The portal's Versions block shows date ranges that end before they begin, so no later edition can be read from it. The appendix says returned codes are registered in the AFAQ Central Component dictionary, which may be updated from time to time, so the live list may differ from the published one [Inference].", "source_edition": "SAMA circular 42068309 (2021-05-05), Appendix 2", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://rulebook.sama.gov.sa/en/appendix-2-return-and-rejection-codes", "source_class": "public_primary", "source_title": "Appendix 2 - Return and Rejection Codes (SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-18", "notes": "Appendix 2 of SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service, lists SP01 with the meaning this record states. SAMA's Operating Rules, sections 7.8 and 7.9, confirm the return limits the record gives: an outer limit of 2 business days, counted only on days that both countries work, with an earlier expected deadline; no compensation for holding the funds inside that limit; and refusal by the Central Component of a return that is late, a duplicate, or inconsistent with the original payment. Section 5.1 item 6 confirms the exchange period accepts returns. SAMA's Charging Policy for Cross Currency Payments Using AFAQ Service, circular 43038107, section 4.2, confirms the SAR 100 penalty for a late return." } ] }, "rail_name": "AFAQ Returns (SAMA rules for Saudi participants)", "governing_authority": "Saudi Central Bank (SAMA), for its direct participants; AFAQ is owned by the six GCC central banks and run by the Gulf Payments Company", "snapshot": "2026-09-18", "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "judgement", "label": "your bank's own terms", "needs": "whose terms decide it: the bank's, the participant's or the scheme's", "detail": "This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "from": "caveat" } ] }, { "uid": "gcc-afaq-return:SP02", "id": "SP02", "rail": "gcc-afaq-return", "kind": "reason-code", "name": "Previously stopped", "group": "authorization", "summary": "ISO's code for an item caught by a stop instruction given earlier. How that works for an AFAQ credit is not stated; read it as a standing instruction by the beneficiary to refuse such payments [Speculation].", "triggers": [ "An earlier stop instruction covers this payment [Inference]" ], "actions": [ "Sending participant: tell the payer [Inference]", "Receiving participant: send back the original amounts at the original exchange rate, in both currencies and with nothing taken off, as one message whose field 72 carries the original payment's reference (OR 7.8, 7.9)", "Receiving participant: expect the Central Component to refuse the return if it differs from the original in amount, currency or rate, repeats a return already accepted, comes too late, or points at an original it cannot find (OR 7.9)" ], "retry": { "allowed": false, "rule": "Not while the stop instruction stands [Inference]." }, "facts": { "return_windows": [ { "action": "return the payment with this reason", "by": "Receiving direct participant (a Saudi participant under SAMA's rules)", "deadline": "Best on the business day the payment arrived; if not, by that payment type's cut-off on the next business day; never later than 2 business days after receipt, counting only days that are business days in both the sending and the receiving country (OR 7.8, 7.9, 5.3). Inside that time no compensation for use of the funds is owed (OR 7.8). The Central Component refuses a return after 2 business days (OR 7.9), and SAMA charges SAR 100 per payment message returned late, possibly plus an amount-based charge (CP 4.2, CP Appendix 2)." } ], "applies_to": "AFAQ cross-currency service, under SAMA's rules for Saudi direct participants: a return payment sent by the receiving direct participant for a payment it received through AFAQ and could not credit (OR 7.8), in the exchange period that accepts returns (OR 5.1 item 6)." }, "caveat": "SAMA's explanation is ISO's own definition of this code (ISO 20022 ExternalReturnReason1Code, 2Q2026). This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "related": [ "gcc-afaq-return:SP01", "gcc-afaq-return:MS02" ], "basis": { "sources": "SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service (2021-05-05, 24/9/1442 H, In-Force), read in full on rulebook.sama.gov.sa on 2026-09-18: Appendix 2, table of returned payments, entry for SP02; sections 5.1 item 6, 5.3, 7.3, 7.8, 7.9. SAMA circular 43038107, Charging Policy for Cross Currency Payments Using AFAQ Service (2021-12-02), section 4.2 and Appendix 2. ISO 20022 External Code Sets 2Q2026 (2Q2026_externalcodesets_v3.json, downloaded 2026-09-18), compared by script. SAMA gives one line per code and no usage guidance, so triggers and actions beyond that line are inference.", "confidence": "low" }, "currency": { "effective_since": "2021-05-05", "effective_note": "Date of SAMA circular 42068309 (24/9/1442 H), In-Force when read on 2026-09-18. The portal's Versions block shows date ranges that end before they begin, so no later edition can be read from it. The appendix says returned codes are registered in the AFAQ Central Component dictionary, which may be updated from time to time, so the live list may differ from the published one [Inference].", "source_edition": "SAMA circular 42068309 (2021-05-05), Appendix 2", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://rulebook.sama.gov.sa/en/appendix-2-return-and-rejection-codes", "source_class": "public_primary", "source_title": "Appendix 2 - Return and Rejection Codes (SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-18", "notes": "Appendix 2 of SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service, lists SP02 with the meaning this record states. SAMA's Operating Rules, sections 7.8 and 7.9, confirm the return limits the record gives: an outer limit of 2 business days, counted only on days that both countries work, with an earlier expected deadline; no compensation for holding the funds inside that limit; and refusal by the Central Component of a return that is late, a duplicate, or inconsistent with the original payment. Section 5.1 item 6 confirms the exchange period accepts returns. SAMA's Charging Policy for Cross Currency Payments Using AFAQ Service, circular 43038107, section 4.2, confirms the SAR 100 penalty for a late return." } ] }, "rail_name": "AFAQ Returns (SAMA rules for Saudi participants)", "governing_authority": "Saudi Central Bank (SAMA), for its direct participants; AFAQ is owned by the six GCC central banks and run by the Gulf Payments Company", "snapshot": "2026-09-18", "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "judgement", "label": "your bank's own terms", "needs": "whose terms decide it: the bank's, the participant's or the scheme's", "detail": "This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "from": "caveat" } ] }, { "uid": "gcc-afaq-return:TMO1", "id": "TMO1", "rail": "gcc-afaq-return", "kind": "reason-code", "name": "Received after the cut-off (SAMA spells it with a letter O)", "group": "technical", "summary": "Too late: the receiving side got the message past the processing cut-off agreed for it, so it goes back. SAMA's list spells the code TMO1 with a capital letter O; ISO's code for the same meaning is TM01, with a zero. This record keeps SAMA's spelling.", "triggers": [ "The payment reached the receiving side too late in the day for it to be processed [Inference]" ], "actions": [ "Sending participant: send a new payment in time for a later joint business day [Inference]", "Both participants: the appendix says the Central Component checks returns against its registered code dictionary and replaces an unregistered code with XX00, so the spelling that works is the one registered; which spelling that is was not confirmed [Inference]", "Receiving participant: send back the original amounts at the original exchange rate, in both currencies and with nothing taken off, as one message whose field 72 carries the original payment's reference (OR 7.8, 7.9)", "Receiving participant: expect the Central Component to refuse the return if it differs from the original in amount, currency or rate, repeats a return already accepted, comes too late, or points at an original it cannot find (OR 7.9)" ], "retry": { "allowed": true, "rule": "Yes, as a new payment. A returned payment may not be sent again under its original Unique Message Reference; once the cause is fixed the sending participant may send it as a new payment with a new Unique Message Reference, and may keep the same UETR (OR 7.3). That sentence sits in the paragraph on rejections and is read here as covering returns too [Inference]." }, "facts": { "return_windows": [ { "action": "return the payment with this reason", "by": "Receiving direct participant (a Saudi participant under SAMA's rules)", "deadline": "Best on the business day the payment arrived; if not, by that payment type's cut-off on the next business day; never later than 2 business days after receipt, counting only days that are business days in both the sending and the receiving country (OR 7.8, 7.9, 5.3). Inside that time no compensation for use of the funds is owed (OR 7.8). The Central Component refuses a return after 2 business days (OR 7.9), and SAMA charges SAR 100 per payment message returned late, possibly plus an amount-based charge (CP 4.2, CP Appendix 2)." } ], "applies_to": "AFAQ cross-currency service, under SAMA's rules for Saudi direct participants: a return payment sent by the receiving direct participant for a payment it received through AFAQ and could not credit (OR 7.8), in the exchange period that accepts returns (OR 5.1 item 6)." }, "caveat": "Undelivered payments left at the end of the day are sent back by the Central Component itself, not by the receiving participant, with a rejection code (OR 5.1 item 8) [Inference: that code is RJ13 in the rejection list]. TMO1 as spelled is in no ISO 20022 external code set (2Q2026); ISO's TM01, with a zero, carries the same explanation (ExternalReturnReason1Code, 2Q2026). This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "related": [ "gcc-afaq-return:DT01" ], "basis": { "sources": "SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service (2021-05-05, 24/9/1442 H, In-Force), read in full on rulebook.sama.gov.sa on 2026-09-18: Appendix 2, table of returned payments, entry for TMO1; sections 5.1 item 6, 5.3, 7.3, 7.8, 7.9, 5.1 item 8. SAMA circular 43038107, Charging Policy for Cross Currency Payments Using AFAQ Service (2021-12-02), section 4.2 and Appendix 2. ISO 20022 External Code Sets 2Q2026 (2Q2026_externalcodesets_v3.json, downloaded 2026-09-18), compared by script. SAMA gives one line per code and no usage guidance, so triggers and actions beyond that line are inference.", "confidence": "medium" }, "currency": { "effective_since": "2021-05-05", "effective_note": "Date of SAMA circular 42068309 (24/9/1442 H), In-Force when read on 2026-09-18. The portal's Versions block shows date ranges that end before they begin, so no later edition can be read from it. The appendix says returned codes are registered in the AFAQ Central Component dictionary, which may be updated from time to time, so the live list may differ from the published one [Inference].", "source_edition": "SAMA circular 42068309 (2021-05-05), Appendix 2", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://rulebook.sama.gov.sa/en/appendix-2-return-and-rejection-codes", "source_class": "public_primary", "source_title": "Appendix 2 - Return and Rejection Codes (SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-18", "notes": "Appendix 2 of SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service, lists TMO1 with the meaning this record states. SAMA's Operating Rules, sections 7.8 and 7.9, confirm the return limits the record gives: an outer limit of 2 business days, counted only on days that both countries work, with an earlier expected deadline; no compensation for holding the funds inside that limit; and refusal by the Central Component of a return that is late, a duplicate, or inconsistent with the original payment. Section 5.1 item 6 confirms the exchange period accepts returns. SAMA's Charging Policy for Cross Currency Payments Using AFAQ Service, circular 43038107, section 4.2, confirms the SAR 100 penalty for a late return. Section 5.1 item 8 confirms the Central Component itself automatically returns undelivered payments at end of day, supporting the record's caveat that this is a separate mechanism from a receiving participant's own return; Appendix 2's own listing confirms the code is spelled with a letter O, not a zero." } ] }, "rail_name": "AFAQ Returns (SAMA rules for Saudi participants)", "governing_authority": "Saudi Central Bank (SAMA), for its direct participants; AFAQ is owned by the six GCC central banks and run by the Gulf Payments Company", "snapshot": "2026-09-18", "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "judgement", "label": "your bank's own terms", "needs": "whose terms decide it: the bank's, the participant's or the scheme's", "detail": "This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "from": "caveat" } ] }, { "uid": "gcc-afaq-return:TRAC", "id": "TRAC", "rail": "gcc-afaq-return", "kind": "reason-code", "name": "Removed from tracking (direct debit code)", "group": "administrative", "summary": "ISO's code for a return after a direct debit is taken out of a tracking process. AFAQ carries no direct debits (OR 7.2), so the code has no evident use on it [Inference].", "triggers": [ "None expected on AFAQ; SAMA does not say when it applies [Inference]" ], "actions": [ "Sending participant: ask the receiving participant what it meant [Inference]", "Receiving participant: send back the original amounts at the original exchange rate, in both currencies and with nothing taken off, as one message whose field 72 carries the original payment's reference (OR 7.8, 7.9)", "Receiving participant: expect the Central Component to refuse the return if it differs from the original in amount, currency or rate, repeats a return already accepted, comes too late, or points at an original it cannot find (OR 7.9)" ], "retry": { "allowed": true, "rule": "Not barred. Nothing in SAMA's rules stops a new payment once the cause is dealt with; it goes out with a new Unique Message Reference and may keep the UETR (OR 7.3) [Inference: the OR 7.3 sentence is written for rejections]. Only one successful return is allowed per payment (OR 7.9)." }, "facts": { "return_windows": [ { "action": "return the payment with this reason", "by": "Receiving direct participant (a Saudi participant under SAMA's rules)", "deadline": "Best on the business day the payment arrived; if not, by that payment type's cut-off on the next business day; never later than 2 business days after receipt, counting only days that are business days in both the sending and the receiving country (OR 7.8, 7.9, 5.3). Inside that time no compensation for use of the funds is owed (OR 7.8). The Central Component refuses a return after 2 business days (OR 7.9), and SAMA charges SAR 100 per payment message returned late, possibly plus an amount-based charge (CP 4.2, CP Appendix 2)." } ], "applies_to": "Listed for the AFAQ cross-currency service under SAMA's rules for Saudi direct participants, although AFAQ carries only single credit payments (OR 7.2); a return by the receiving direct participant (OR 7.8)." }, "caveat": "This is a direct debit code listed on a credit-only system: AFAQ carries single credit payments only (OR 7.2) and has no direct debit, so no ordinary AFAQ payment should draw it [Inference]. SAMA's explanation is ISO's own definition of this code (ISO 20022 ExternalReturnReason1Code, 2Q2026). This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "related": [ "gcc-afaq-return:FRTR", "gcc-afaq-return:SL11" ], "basis": { "sources": "SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service (2021-05-05, 24/9/1442 H, In-Force), read in full on rulebook.sama.gov.sa on 2026-09-18: Appendix 2, table of returned payments, entry for TRAC; sections 5.1 item 6, 5.3, 7.3, 7.8, 7.9, 7.2. SAMA circular 43038107, Charging Policy for Cross Currency Payments Using AFAQ Service (2021-12-02), section 4.2 and Appendix 2. ISO 20022 External Code Sets 2Q2026 (2Q2026_externalcodesets_v3.json, downloaded 2026-09-18), compared by script. SAMA gives one line per code and no usage guidance, so triggers and actions beyond that line are inference.", "confidence": "low" }, "currency": { "effective_since": "2021-05-05", "effective_note": "Date of SAMA circular 42068309 (24/9/1442 H), In-Force when read on 2026-09-18. The portal's Versions block shows date ranges that end before they begin, so no later edition can be read from it. The appendix says returned codes are registered in the AFAQ Central Component dictionary, which may be updated from time to time, so the live list may differ from the published one [Inference].", "source_edition": "SAMA circular 42068309 (2021-05-05), Appendix 2", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://rulebook.sama.gov.sa/en/appendix-2-return-and-rejection-codes", "source_class": "public_primary", "source_title": "Appendix 2 - Return and Rejection Codes (SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-18", "notes": "Appendix 2 of SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service, lists TRAC with the meaning this record states. SAMA's Operating Rules, sections 7.8 and 7.9, confirm the return limits the record gives: an outer limit of 2 business days, counted only on days that both countries work, with an earlier expected deadline; no compensation for holding the funds inside that limit; and refusal by the Central Component of a return that is late, a duplicate, or inconsistent with the original payment. Section 5.1 item 6 confirms the exchange period accepts returns. SAMA's Charging Policy for Cross Currency Payments Using AFAQ Service, circular 43038107, section 4.2, confirms the SAR 100 penalty for a late return. Section 7.2 confirms AFAQ carries no direct debit, supporting the record's point that this code has no evident use on AFAQ." } ] }, "rail_name": "AFAQ Returns (SAMA rules for Saudi participants)", "governing_authority": "Saudi Central Bank (SAMA), for its direct participants; AFAQ is owned by the six GCC central banks and run by the Gulf Payments Company", "snapshot": "2026-09-18", "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "judgement", "label": "your bank's own terms", "needs": "whose terms decide it: the bank's, the participant's or the scheme's", "detail": "This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "from": "caveat" } ] }, { "uid": "gcc-afaq-return:ULBA", "id": "ULBA", "rail": "gcc-afaq-return", "kind": "reason-code", "name": "Beneficiary account cannot be located", "group": "account", "summary": "An AFAQ code of its own: the receiving participant cannot find the beneficiary account the payment points to.", "triggers": [ "No account on the receiving bank's books matches the details given [Inference]" ], "actions": [ "Sending participant: tell the payer why the money came back and get beneficiary details that work before sending anything new", "Receiving participant: send back the original amounts at the original exchange rate, in both currencies and with nothing taken off, as one message whose field 72 carries the original payment's reference (OR 7.8, 7.9)", "Receiving participant: expect the Central Component to refuse the return if it differs from the original in amount, currency or rate, repeats a return already accepted, comes too late, or points at an original it cannot find (OR 7.9)" ], "retry": { "allowed": true, "rule": "Yes, as a new payment. A returned payment may not be sent again under its original Unique Message Reference; once the cause is fixed the sending participant may send it as a new payment with a new Unique Message Reference, and may keep the same UETR (OR 7.3). That sentence sits in the paragraph on rejections and is read here as covering returns too [Inference]." }, "facts": { "return_windows": [ { "action": "return the payment with this reason", "by": "Receiving direct participant (a Saudi participant under SAMA's rules)", "deadline": "Best on the business day the payment arrived; if not, by that payment type's cut-off on the next business day; never later than 2 business days after receipt, counting only days that are business days in both the sending and the receiving country (OR 7.8, 7.9, 5.3). Inside that time no compensation for use of the funds is owed (OR 7.8). The Central Component refuses a return after 2 business days (OR 7.9), and SAMA charges SAR 100 per payment message returned late, possibly plus an amount-based charge (CP 4.2, CP Appendix 2)." } ], "applies_to": "AFAQ cross-currency service, under SAMA's rules for Saudi direct participants: a return payment sent by the receiving direct participant for a payment it received through AFAQ and could not credit (OR 7.8), in the exchange period that accepts returns (OR 5.1 item 6)." }, "caveat": "BADE (account does not exist) sits very close to this code; SAMA does not say how they differ. The code is in no ISO 20022 external code set (2Q2026); it is AFAQ's own. This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "related": [ "gcc-afaq-return:BADE", "gcc-afaq-return:IBAN", "gcc-afaq-return:AC01", "gcc-afaq-return:BE06" ], "basis": { "sources": "SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service (2021-05-05, 24/9/1442 H, In-Force), read in full on rulebook.sama.gov.sa on 2026-09-18: Appendix 2, table of returned payments, entry for ULBA; sections 5.1 item 6, 5.3, 7.3, 7.8, 7.9. SAMA circular 43038107, Charging Policy for Cross Currency Payments Using AFAQ Service (2021-12-02), section 4.2 and Appendix 2. ISO 20022 External Code Sets 2Q2026 (2Q2026_externalcodesets_v3.json, downloaded 2026-09-18), compared by script. SAMA gives one line per code and no usage guidance, so triggers and actions beyond that line are inference.", "confidence": "medium" }, "currency": { "effective_since": "2021-05-05", "effective_note": "Date of SAMA circular 42068309 (24/9/1442 H), In-Force when read on 2026-09-18. The portal's Versions block shows date ranges that end before they begin, so no later edition can be read from it. The appendix says returned codes are registered in the AFAQ Central Component dictionary, which may be updated from time to time, so the live list may differ from the published one [Inference].", "source_edition": "SAMA circular 42068309 (2021-05-05), Appendix 2", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://rulebook.sama.gov.sa/en/appendix-2-return-and-rejection-codes", "source_class": "public_primary", "source_title": "Appendix 2 - Return and Rejection Codes (SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-18", "notes": "Appendix 2 of SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service, lists ULBA with the meaning this record states. SAMA's Operating Rules, sections 7.8 and 7.9, confirm the return limits the record gives: an outer limit of 2 business days, counted only on days that both countries work, with an earlier expected deadline; no compensation for holding the funds inside that limit; and refusal by the Central Component of a return that is late, a duplicate, or inconsistent with the original payment. Section 5.1 item 6 confirms the exchange period accepts returns. SAMA's Charging Policy for Cross Currency Payments Using AFAQ Service, circular 43038107, section 4.2, confirms the SAR 100 penalty for a late return." } ] }, "rail_name": "AFAQ Returns (SAMA rules for Saudi participants)", "governing_authority": "Saudi Central Bank (SAMA), for its direct participants; AFAQ is owned by the six GCC central banks and run by the Gulf Payments Company", "snapshot": "2026-09-18", "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "judgement", "label": "your bank's own terms", "needs": "whose terms decide it: the bank's, the participant's or the scheme's", "detail": "This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "from": "caveat" } ] }, { "uid": "gcc-afaq-return:UPAY", "id": "UPAY", "rail": "gcc-afaq-return", "kind": "reason-code", "name": "Payment not justified", "group": "authorization", "summary": "The payment should not have been made, so the receiving participant sends it back.", "triggers": [ "The payment has no valid basis, for example it was sent to the wrong party or twice by mistake [Inference]" ], "actions": [ "Sending participant: confirm with the payer whether any payment is due [Inference]", "Receiving participant: send back the original amounts at the original exchange rate, in both currencies and with nothing taken off, as one message whose field 72 carries the original payment's reference (OR 7.8, 7.9)", "Receiving participant: expect the Central Component to refuse the return if it differs from the original in amount, currency or rate, repeats a return already accepted, comes too late, or points at an original it cannot find (OR 7.9)" ], "retry": { "allowed": false, "rule": "Not the same payment. A new payment only if the payer confirms one is due [Inference]." }, "facts": { "return_windows": [ { "action": "return the payment with this reason", "by": "Receiving direct participant (a Saudi participant under SAMA's rules)", "deadline": "Best on the business day the payment arrived; if not, by that payment type's cut-off on the next business day; never later than 2 business days after receipt, counting only days that are business days in both the sending and the receiving country (OR 7.8, 7.9, 5.3). Inside that time no compensation for use of the funds is owed (OR 7.8). The Central Component refuses a return after 2 business days (OR 7.9), and SAMA charges SAR 100 per payment message returned late, possibly plus an amount-based charge (CP 4.2, CP Appendix 2)." } ], "applies_to": "AFAQ cross-currency service, under SAMA's rules for Saudi direct participants: a return payment sent by the receiving direct participant for a payment it received through AFAQ and could not credit (OR 7.8), in the exchange period that accepts returns (OR 5.1 item 6)." }, "caveat": "SAMA's explanation is ISO's own definition of this code (ISO 20022 ExternalReturnReason1Code, 2Q2026). This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "related": [ "gcc-afaq-return:FR01", "gcc-afaq-return:BE08", "gcc-afaq-return:AM05" ], "basis": { "sources": "SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service (2021-05-05, 24/9/1442 H, In-Force), read in full on rulebook.sama.gov.sa on 2026-09-18: Appendix 2, table of returned payments, entry for UPAY; sections 5.1 item 6, 5.3, 7.3, 7.8, 7.9. SAMA circular 43038107, Charging Policy for Cross Currency Payments Using AFAQ Service (2021-12-02), section 4.2 and Appendix 2. ISO 20022 External Code Sets 2Q2026 (2Q2026_externalcodesets_v3.json, downloaded 2026-09-18), compared by script. SAMA gives one line per code and no usage guidance, so triggers and actions beyond that line are inference.", "confidence": "medium" }, "currency": { "effective_since": "2021-05-05", "effective_note": "Date of SAMA circular 42068309 (24/9/1442 H), In-Force when read on 2026-09-18. The portal's Versions block shows date ranges that end before they begin, so no later edition can be read from it. The appendix says returned codes are registered in the AFAQ Central Component dictionary, which may be updated from time to time, so the live list may differ from the published one [Inference].", "source_edition": "SAMA circular 42068309 (2021-05-05), Appendix 2", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://rulebook.sama.gov.sa/en/appendix-2-return-and-rejection-codes", "source_class": "public_primary", "source_title": "Appendix 2 - Return and Rejection Codes (SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-18", "notes": "Appendix 2 of SAMA circular 42068309, Operating Rules for Cross Currency Payments using AFAQ Service, lists UPAY with the meaning this record states. SAMA's Operating Rules, sections 7.8 and 7.9, confirm the return limits the record gives: an outer limit of 2 business days, counted only on days that both countries work, with an earlier expected deadline; no compensation for holding the funds inside that limit; and refusal by the Central Component of a return that is late, a duplicate, or inconsistent with the original payment. Section 5.1 item 6 confirms the exchange period accepts returns. SAMA's Charging Policy for Cross Currency Payments Using AFAQ Service, circular 43038107, section 4.2, confirms the SAR 100 penalty for a late return." } ] }, "rail_name": "AFAQ Returns (SAMA rules for Saudi participants)", "governing_authority": "Saudi Central Bank (SAMA), for its direct participants; AFAQ is owned by the six GCC central banks and run by the Gulf Payments Company", "snapshot": "2026-09-18", "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "judgement", "label": "your bank's own terms", "needs": "whose terms decide it: the bank's, the participant's or the scheme's", "detail": "This record reports SAMA's AFAQ rules for Saudi direct participants (OR 2.2, 4.2); a participant in another GCC country follows its own central bank's rules, which were not read [Unverified].", "from": "caveat" } ] }, { "uid": "mastercard-decline:01", "id": "01", "rail": "mastercard-decline", "kind": "reason-code", "name": "Refer to card issuer", "group": "authorization", "summary": "Decline in which the issuer asks to be contacted before it will approve. Mastercard treats it as a temporary problem that the cardholder may be able to sort out with the issuer.", "triggers": [ "The issuer wants contact with the cardholder or merchant before approving [Inference from Mastercard's label; the defining text is in technical specifications not public to Orca]" ], "actions": [ "Merchant (merchant-initiated retries): decide whether and when to retry from this code and the Merchant Advice Code together (TPR 3.3.1, p. 124).", "Transit merchant: make at least nine debt recovery attempts within 45 days; this is a situation the cardholder may be able to resolve with the issuer (TPR 4.5.5, p. 165)." ], "retry": { "allowed": true, "rule": "No blanket bar in the rules read. A card-not-present merchant that retries a merchant-initiated transaction must weigh this code together with the Merchant Advice Code: 01 means get updated account data first, 02 means wait 24 hours, 03 or 21 means stop (TPR 3.3.1, Table 20, p. 124). Which advice codes may accompany this code is set in the Dual and Single Message System specifications, which are not public to Orca. A declined cardholder-initiated transaction may not come back as a merchant-initiated one, a declined token cryptogram may not be sent again, and a retry must not alter merchant data: it carries the same merchant name, address, acceptor ID and POS condition values, with either the card data the cardholder first gave, a tokenized stored credential, or data updated through the cardholder or the Automatic Billing Updater (TPR 3.3.1, pp. 124 to 125). For a declined deferred card-present authorization outside transit, resubmission needs Merchant Advice Code 02 or another advice code giving a retry period, and a decline value that does not restrict retries; the rules read do not say whether this code restricts retries. Retries then run every 24 hours for up to 13 consecutive days (TPR 2.7.1, p. 54). Transit debt recovery follows the transit table category, not these rules (TPR 4.5.5)." }, "facts": { "return_windows": [ { "action": "resubmit a declined merchant-initiated authorization", "by": "Merchant", "deadline": "Set by the Merchant Advice Code on the decline: 01 update the account data first, 02 wait 24 hours, 03 or 21 never; with no advice code the rules read set no interval (TPR 3.3.1, Table 20)" }, { "action": "resubmit a declined deferred card-present authorization (not transit)", "by": "Merchant", "deadline": "Only when Merchant Advice Code 02 or another code giving a retry period came with the decline and this code does not restrict retries, which the rules read do not settle: no sooner than 24 hours after it, then at most once every 24 hours for up to 13 consecutive days (TPR 2.7.1)" }, { "action": "transit debt recovery after a declined contactless transit aggregated transaction", "by": "Transit merchant and its acquirer", "deadline": "Temporarily Recoverable: at least nine debt recovery attempts, no more than one per 24 hours, within 45 calendar days of first receiving the code, the last by day 45; once they are used up the debt counts as unrecoverable and a first ride risk claim may follow (TPR 4.5.5, Tables 22 and 23)" } ], "applies_to": "All Mastercard regions for Mastercard, Maestro and Cirrus transactions on Mastercard's network; in the EEA, the UK and Gibraltar many of these rules refer to the registered switch the customer chooses; transit categories differ in Australia (TPR Table 24)" }, "caveat": "The transit categories come from the First Ride Risk framework: they cover contactless transit aggregated transactions sent through the Dual Message System by a transit merchant in a country that has adopted the framework, in general only for cards issued in that country, and they are not a general retry rule (TPR 4.5.5, p. 162). Any valid response code missing from Table 23 counts as Unrecoverable. Table 22 still refers to this table as Table 7, a stale internal reference.", "related": [ "mastercard:messages" ], "basis": { "sources": "Transaction Processing Rules, 9 June 2026 edition, sections 3.3.1, 2.7.1, 4.5.4, 4.5.5 Tables 22 and 23, Asia/Pacific Region 4.5.5 Table 24. Label and category read from Table 23 on pp. 163 to 164, with each entry's column fixed from its position on the page; placed Temporarily Recoverable in Table 24 (pp. 175 to 176). Read from a copy downloaded from Mastercard's public rules page on 2026-09-19. Nothing is quoted. Medium: the label, category and retry rules follow from the cited sections, but what makes an issuer send this code is inferred from the label, and the defining specifications are not public to Orca.", "confidence": "medium" }, "currency": { "effective_since": "Before the current edition; start not stated in it", "effective_note": "Label and category as in the 9 June 2026 edition of the Transaction Processing Rules, whose summary of changes says it updated the Table 23 categories and removed past effective dates, so neither when this code's category began nor what it was before is shown. No dated change to this code was found in the edition. Mastercard reissues the manual on no fixed calendar [Inference].", "source_edition": "Transaction Processing Rules, 9 June 2026 edition (https://www.mastercard.com/content/dam/mccom/shared/business/support/rules-pdfs/transaction-processing-rules.pdf)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.mastercard.com/content/dam/mccom/shared/business/support/rules-pdfs/transaction-processing-rules.pdf", "source_class": "authoritative_primary", "source_title": "Transaction Processing Rules, 9 June 2026 edition", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms Mastercard's label for response value 01 and its Table 23 decline value category (Temporarily Recoverable) in Transaction Processing Rules 4.5.5, read by column position on pages 163 to 165, and the Table 24 Australia category on pages 175 to 176; also confirms the merchant-initiated retry framework in rules 3.3.1 and 2.7.1 (the 04, 14, 15, 41, 43 and 54 no-retry bar, the Merchant Advice Code scenarios, and the 24 hour, 13 day deferred card-present resubmission window)." } ] }, "rail_name": "Mastercard Decline Response Codes (partial)", "governing_authority": "Mastercard", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "mastercard-decline:03", "id": "03", "rail": "mastercard-decline", "kind": "reason-code", "name": "Invalid merchant", "group": "administrative", "summary": "Decline that faults the merchant rather than the card: the issuer or network does not accept the merchant identified in the request.", "triggers": [ "The merchant identified in the request is not one the issuer or network will accept [Inference from Mastercard's label; the defining text is in technical specifications not public to Orca]" ], "actions": [ "Merchant (merchant-initiated retries): decide whether and when to retry from this code and the Merchant Advice Code together (TPR 3.3.1, p. 124).", "Transit acquirer: may claim the first ride debt at once with a First Presentment/1240 carrying no approval, up to the country's first ride risk limit (TPR 4.5.5, pp. 163 to 165)." ], "retry": { "allowed": true, "rule": "No blanket bar in the rules read. A card-not-present merchant that retries a merchant-initiated transaction must weigh this code together with the Merchant Advice Code: 01 means get updated account data first, 02 means wait 24 hours, 03 or 21 means stop (TPR 3.3.1, Table 20, p. 124). Which advice codes may accompany this code is set in the Dual and Single Message System specifications, which are not public to Orca. A declined cardholder-initiated transaction may not come back as a merchant-initiated one, a declined token cryptogram may not be sent again, and a retry must not alter merchant data: it carries the same merchant name, address, acceptor ID and POS condition values, with either the card data the cardholder first gave, a tokenized stored credential, or data updated through the cardholder or the Automatic Billing Updater (TPR 3.3.1, pp. 124 to 125). For a declined deferred card-present authorization outside transit, resubmission needs Merchant Advice Code 02 or another advice code giving a retry period, and a decline value that does not restrict retries; the rules read do not say whether this code restricts retries. Retries then run every 24 hours for up to 13 consecutive days (TPR 2.7.1, p. 54). Transit debt recovery follows the transit table category, not these rules (TPR 4.5.5)." }, "facts": { "return_windows": [ { "action": "resubmit a declined merchant-initiated authorization", "by": "Merchant", "deadline": "Set by the Merchant Advice Code on the decline: 01 update the account data first, 02 wait 24 hours, 03 or 21 never; with no advice code the rules read set no interval (TPR 3.3.1, Table 20)" }, { "action": "resubmit a declined deferred card-present authorization (not transit)", "by": "Merchant", "deadline": "Only when Merchant Advice Code 02 or another code giving a retry period came with the decline and this code does not restrict retries, which the rules read do not settle: no sooner than 24 hours after it, then at most once every 24 hours for up to 13 consecutive days (TPR 2.7.1)" }, { "action": "first ride risk claim after a declined contactless transit aggregated transaction", "by": "Transit acquirer", "deadline": "Unrecoverable: may be sent at once, as a First Presentment/1240 with no approval, for no more than the first ride risk limit of the merchant's country (TPR 4.5.5, Tables 22 and 23)" } ], "applies_to": "All Mastercard regions for Mastercard, Maestro and Cirrus transactions on Mastercard's network; in the EEA, the UK and Gibraltar many of these rules refer to the registered switch the customer chooses; transit categories differ in Australia (TPR Table 24)" }, "caveat": "The transit categories come from the First Ride Risk framework: they cover contactless transit aggregated transactions sent through the Dual Message System by a transit merchant in a country that has adopted the framework, in general only for cards issued in that country, and they are not a general retry rule (TPR 4.5.5, p. 162). Any valid response code missing from Table 23 counts as Unrecoverable. Table 22 still refers to this table as Table 7, a stale internal reference.", "related": [ "mastercard:messages" ], "basis": { "sources": "Transaction Processing Rules, 9 June 2026 edition, sections 3.3.1, 2.7.1, 4.5.4, 4.5.5 Tables 22 and 23, Asia/Pacific Region 4.5.5 Table 24. Label and category read from Table 23 on pp. 163 to 164, with each entry's column fixed from its position on the page; placed Unrecoverable in Table 24 (pp. 175 to 176). Read from a copy downloaded from Mastercard's public rules page on 2026-09-19. Nothing is quoted. Medium: the label, category and retry rules follow from the cited sections, but what makes an issuer send this code is inferred from the label, and the defining specifications are not public to Orca.", "confidence": "medium" }, "currency": { "effective_since": "Before the current edition; start not stated in it", "effective_note": "Label and category as in the 9 June 2026 edition of the Transaction Processing Rules, whose summary of changes says it updated the Table 23 categories and removed past effective dates, so neither when this code's category began nor what it was before is shown. No dated change to this code was found in the edition. Mastercard reissues the manual on no fixed calendar [Inference].", "source_edition": "Transaction Processing Rules, 9 June 2026 edition (https://www.mastercard.com/content/dam/mccom/shared/business/support/rules-pdfs/transaction-processing-rules.pdf)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.mastercard.com/content/dam/mccom/shared/business/support/rules-pdfs/transaction-processing-rules.pdf", "source_class": "authoritative_primary", "source_title": "Transaction Processing Rules, 9 June 2026 edition", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms Mastercard's label for response value 03 and its Table 23 decline value category (Unrecoverable) in Transaction Processing Rules 4.5.5, read by column position on pages 163 to 165, and the Table 24 Australia category on pages 175 to 176; also confirms the merchant-initiated retry framework in rules 3.3.1 and 2.7.1 (the 04, 14, 15, 41, 43 and 54 no-retry bar, the Merchant Advice Code scenarios, and the 24 hour, 13 day deferred card-present resubmission window)." } ] }, "rail_name": "Mastercard Decline Response Codes (partial)", "governing_authority": "Mastercard", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "mastercard-decline:04", "id": "04", "rail": "mastercard-decline", "kind": "reason-code", "name": "Capture card", "group": "authorization", "summary": "Decline with an instruction to take the card out of use. A merchant must not complete the sale, a card-not-present merchant may never retry the same transaction on that card number and expiry date, and in a face-to-face sale the merchant should try to keep the physical card.", "triggers": [ "The issuer wants the card retained, for example because it should no longer be in circulation [Inference from Mastercard's label; the defining text is in technical specifications not public to Orca]" ], "actions": [ "Merchant (card-not-present): stop; send no further authorization request for this transaction with this PAN and expiry date (TPR 3.3.1, pp. 123 to 124).", "Merchant (deferred card-present, not transit): do not resubmit (TPR 2.7.1, p. 54).", "Merchant: do not complete the transaction; face to face, try to keep the card by reasonable and peaceful means (not required when an access device such as a phone was presented), then tell the acquirer and ask what to do next (TPR 3.3.1, Capture Card Response, p. 125).", "ATM: Mastercard's recommended screen and receipt text for a capture response says the card has been retained and to contact the financial institution (TPR Signage, Screen and Receipt Text Standards, p. 355) [Inference: the table names responses by wording, not by code].", "Transit acquirer: may claim the first ride debt at once with a First Presentment/1240 carrying no approval, up to the country's first ride risk limit (TPR 4.5.5, pp. 163 to 165)." ], "retry": { "allowed": false, "rule": "No. After this code a merchant must never send another authorization request for the same card-not-present transaction with the same PAN and expiry date (TPR 3.3.1, pp. 123 to 124), and a declined deferred card-present authorization outside transit must not be resubmitted either (TPR 2.7.1, p. 54). The bar is tied to that PAN and expiry date; the rules read do not bar a request made with different card data [Inference from the wording of the bar]. Transit debt recovery and claims follow the transit table instead (TPR 4.5.5)." }, "facts": { "return_windows": [ { "action": "new authorization request for the same card-not-present transaction with the same PAN and expiry date", "by": "Merchant", "deadline": "Never (TPR 3.3.1)" }, { "action": "resubmit a declined deferred card-present authorization (not transit)", "by": "Merchant", "deadline": "Never (TPR 2.7.1)" }, { "action": "first ride risk claim after a declined contactless transit aggregated transaction", "by": "Transit acquirer", "deadline": "Unrecoverable: may be sent at once, as a First Presentment/1240 with no approval, for no more than the first ride risk limit of the merchant's country (TPR 4.5.5, Tables 22 and 23)" } ], "applies_to": "All Mastercard regions for Mastercard, Maestro and Cirrus transactions on Mastercard's network; in the EEA, the UK and Gibraltar many of these rules refer to the registered switch the customer chooses; transit categories differ in Australia (TPR Table 24)" }, "caveat": "The transit categories come from the First Ride Risk framework: they cover contactless transit aggregated transactions sent through the Dual Message System by a transit merchant in a country that has adopted the framework, in general only for cards issued in that country, and they are not a general retry rule (TPR 4.5.5, p. 162). Any valid response code missing from Table 23 counts as Unrecoverable. Table 22 still refers to this table as Table 7, a stale internal reference.", "related": [ "mastercard-decline:41", "mastercard-decline:43", "mastercard-decline:14", "mastercard-decline:15", "mastercard-decline:54", "mastercard:messages" ], "basis": { "sources": "Transaction Processing Rules, 9 June 2026 edition, sections 3.3.1, 2.7.1, 4.5.4, 4.5.5 Tables 22 and 23, Asia/Pacific Region 4.5.5 Table 24, Signage, Screen and Receipt Text Standards (p. 355). Label and category read from Table 23 on pp. 163 to 164, with each entry's column fixed from its position on the page; placed Unrecoverable in Table 24 (pp. 175 to 176). Read from a copy downloaded from Mastercard's public rules page on 2026-09-19. Nothing is quoted. Medium: the label, category and retry rules follow from the cited sections, but what makes an issuer send this code is inferred from the label, and the defining specifications are not public to Orca.", "confidence": "medium" }, "currency": { "effective_since": "Before the current edition; start not stated in it", "effective_note": "Label and category as in the 9 June 2026 edition of the Transaction Processing Rules, whose summary of changes says it updated the Table 23 categories and removed past effective dates, so neither when this code's category began nor what it was before is shown. No dated change to this code was found in the edition. Mastercard reissues the manual on no fixed calendar [Inference].", "source_edition": "Transaction Processing Rules, 9 June 2026 edition (https://www.mastercard.com/content/dam/mccom/shared/business/support/rules-pdfs/transaction-processing-rules.pdf)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.mastercard.com/content/dam/mccom/shared/business/support/rules-pdfs/transaction-processing-rules.pdf", "source_class": "authoritative_primary", "source_title": "Transaction Processing Rules, 9 June 2026 edition", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms Mastercard's label for response value 04 and its Table 23 decline value category (Unrecoverable) in Transaction Processing Rules 4.5.5, read by column position on pages 163 to 165, and the Table 24 Australia category on pages 175 to 176; also confirms the merchant-initiated retry framework in rules 3.3.1 and 2.7.1 (the 04, 14, 15, 41, 43 and 54 no-retry bar, the Merchant Advice Code scenarios, and the 24 hour, 13 day deferred card-present resubmission window) and confirms the bar on any further card-not-present or deferred card-present retry." } ] }, "rail_name": "Mastercard Decline Response Codes (partial)", "governing_authority": "Mastercard", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "mastercard-decline:05", "id": "05", "rail": "mastercard-decline", "kind": "reason-code", "name": "Do not honor", "group": "authorization", "summary": "General decline with no specific reason given. Mastercard treats it as temporary for transit debt unless the Merchant Advice Code says never to retry.", "triggers": [ "The issuer declines without giving a more specific reason [Inference from Mastercard's label; the defining text is in technical specifications not public to Orca]" ], "actions": [ "Merchant (merchant-initiated retries): decide whether and when to retry from this code and the Merchant Advice Code together (TPR 3.3.1, p. 124).", "Transit merchant: make at least nine debt recovery attempts within 45 days; this is a situation the cardholder may be able to resolve with the issuer (TPR 4.5.5, p. 165)." ], "retry": { "allowed": true, "rule": "No blanket bar in the rules read. A card-not-present merchant that retries a merchant-initiated transaction must weigh this code together with the Merchant Advice Code: 01 means get updated account data first, 02 means wait 24 hours, 03 or 21 means stop (TPR 3.3.1, Table 20, p. 124). Which advice codes may accompany this code is set in the Dual and Single Message System specifications, which are not public to Orca. A declined cardholder-initiated transaction may not come back as a merchant-initiated one, a declined token cryptogram may not be sent again, and a retry must not alter merchant data: it carries the same merchant name, address, acceptor ID and POS condition values, with either the card data the cardholder first gave, a tokenized stored credential, or data updated through the cardholder or the Automatic Billing Updater (TPR 3.3.1, pp. 124 to 125). For a declined deferred card-present authorization outside transit, resubmission needs Merchant Advice Code 02 or another advice code giving a retry period, and a decline value that does not restrict retries; the rules read do not say whether this code restricts retries. Retries then run every 24 hours for up to 13 consecutive days (TPR 2.7.1, p. 54). Transit debt recovery follows the transit table category, not these rules (TPR 4.5.5)." }, "facts": { "return_windows": [ { "action": "resubmit a declined merchant-initiated authorization", "by": "Merchant", "deadline": "Set by the Merchant Advice Code on the decline: 01 update the account data first, 02 wait 24 hours, 03 or 21 never; with no advice code the rules read set no interval (TPR 3.3.1, Table 20)" }, { "action": "resubmit a declined deferred card-present authorization (not transit)", "by": "Merchant", "deadline": "Only when Merchant Advice Code 02 or another code giving a retry period came with the decline and this code does not restrict retries, which the rules read do not settle: no sooner than 24 hours after it, then at most once every 24 hours for up to 13 consecutive days (TPR 2.7.1)" }, { "action": "transit debt recovery when the decline carries Merchant Advice Code 03", "by": "Transit merchant and its acquirer", "deadline": "No recovery attempts: with advice code 03 this code counts as Unrecoverable, so the first ride risk claim may be sent at once (TPR 4.5.5, Table 23 note 5)" }, { "action": "transit debt recovery after a declined contactless transit aggregated transaction", "by": "Transit merchant and its acquirer", "deadline": "Temporarily Recoverable: at least nine debt recovery attempts, no more than one per 24 hours, within 45 calendar days of first receiving the code, the last by day 45; once they are used up the debt counts as unrecoverable and a first ride risk claim may follow (TPR 4.5.5, Tables 22 and 23)" }, { "action": "transit debt recovery or first ride risk claim, Australia", "by": "Transit merchant and its acquirer (Australia)", "deadline": "Table 24 places this code in Recoverable (recover first; claim only after nine failed attempts over 45 days), not the global category (TPR Asia/Pacific Region 4.5.5, pp. 175 to 176)" } ], "applies_to": "All Mastercard regions for Mastercard, Maestro and Cirrus transactions on Mastercard's network; in the EEA, the UK and Gibraltar many of these rules refer to the registered switch the customer chooses; transit categories differ in Australia (TPR Table 24)" }, "caveat": "With Merchant Advice Code 03 (do not try again) the transit category changes from Temporarily Recoverable to Unrecoverable (Table 23 note 5). The transit categories come from the First Ride Risk framework: they cover contactless transit aggregated transactions sent through the Dual Message System by a transit merchant in a country that has adopted the framework, in general only for cards issued in that country, and they are not a general retry rule (TPR 4.5.5, p. 162). Any valid response code missing from Table 23 counts as Unrecoverable. Table 22 still refers to this table as Table 7, a stale internal reference.", "related": [ "mastercard-decline:01", "mastercard-decline:70", "mastercard:messages" ], "basis": { "sources": "Transaction Processing Rules, 9 June 2026 edition, sections 3.3.1, 2.7.1, 4.5.4, 4.5.5 Tables 22 and 23, Asia/Pacific Region 4.5.5 Table 24. Label and category read from Table 23 on pp. 163 to 164, with each entry's column fixed from its position on the page; placed Recoverable in Table 24 (pp. 175 to 176). Read from a copy downloaded from Mastercard's public rules page on 2026-09-19. Nothing is quoted. Medium: the label, category and retry rules follow from the cited sections, but what makes an issuer send this code is inferred from the label, and the defining specifications are not public to Orca.", "confidence": "medium" }, "currency": { "effective_since": "Before the current edition; start not stated in it", "effective_note": "Label and category as in the 9 June 2026 edition of the Transaction Processing Rules, whose summary of changes says it updated the Table 23 categories and removed past effective dates, so neither when this code's category began nor what it was before is shown. No dated change to this code was found in the edition. Mastercard reissues the manual on no fixed calendar [Inference].", "source_edition": "Transaction Processing Rules, 9 June 2026 edition (https://www.mastercard.com/content/dam/mccom/shared/business/support/rules-pdfs/transaction-processing-rules.pdf)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.mastercard.com/content/dam/mccom/shared/business/support/rules-pdfs/transaction-processing-rules.pdf", "source_class": "authoritative_primary", "source_title": "Transaction Processing Rules, 9 June 2026 edition", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms Mastercard's label for response value 05 and its Table 23 decline value category (Temporarily Recoverable, or Unrecoverable when the Merchant Advice Code is 03) in Transaction Processing Rules 4.5.5, read by column position on pages 163 to 165, and the Table 24 Australia category on pages 175 to 176; also confirms the merchant-initiated retry framework in rules 3.3.1 and 2.7.1 (the 04, 14, 15, 41, 43 and 54 no-retry bar, the Merchant Advice Code scenarios, and the 24 hour, 13 day deferred card-present resubmission window)." } ] }, "rail_name": "Mastercard Decline Response Codes (partial)", "governing_authority": "Mastercard", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "mastercard-decline:12", "id": "12", "rail": "mastercard-decline", "kind": "reason-code", "name": "Invalid transaction", "group": "administrative", "summary": "Decline because the type of transaction requested is not valid for this card or account. An issuer must not use it to answer a refund authorization.", "triggers": [ "The issuer does not accept the kind of transaction requested [Inference from Mastercard's label; the defining text is in technical specifications not public to Orca]" ], "actions": [ "Merchant (merchant-initiated retries): decide whether and when to retry from this code and the Merchant Advice Code together (TPR 3.3.1, p. 124).", "Issuer: never answer a refund authorization request with 12 (TPR 2.13.2, p. 66).", "Transit acquirer: may claim the first ride debt at once with a First Presentment/1240 carrying no approval, up to the country's first ride risk limit (TPR 4.5.5, pp. 163 to 165)." ], "retry": { "allowed": true, "rule": "No blanket bar in the rules read. A card-not-present merchant that retries a merchant-initiated transaction must weigh this code together with the Merchant Advice Code: 01 means get updated account data first, 02 means wait 24 hours, 03 or 21 means stop (TPR 3.3.1, Table 20, p. 124). Which advice codes may accompany this code is set in the Dual and Single Message System specifications, which are not public to Orca. A declined cardholder-initiated transaction may not come back as a merchant-initiated one, a declined token cryptogram may not be sent again, and a retry must not alter merchant data: it carries the same merchant name, address, acceptor ID and POS condition values, with either the card data the cardholder first gave, a tokenized stored credential, or data updated through the cardholder or the Automatic Billing Updater (TPR 3.3.1, pp. 124 to 125). For a declined deferred card-present authorization outside transit, resubmission needs Merchant Advice Code 02 or another advice code giving a retry period, and a decline value that does not restrict retries; the rules read do not say whether this code restricts retries. Retries then run every 24 hours for up to 13 consecutive days (TPR 2.7.1, p. 54). Transit debt recovery follows the transit table category, not these rules (TPR 4.5.5)." }, "facts": { "return_windows": [ { "action": "resubmit a declined merchant-initiated authorization", "by": "Merchant", "deadline": "Set by the Merchant Advice Code on the decline: 01 update the account data first, 02 wait 24 hours, 03 or 21 never; with no advice code the rules read set no interval (TPR 3.3.1, Table 20)" }, { "action": "resubmit a declined deferred card-present authorization (not transit)", "by": "Merchant", "deadline": "Only when Merchant Advice Code 02 or another code giving a retry period came with the decline and this code does not restrict retries, which the rules read do not settle: no sooner than 24 hours after it, then at most once every 24 hours for up to 13 consecutive days (TPR 2.7.1)" }, { "action": "answer a refund authorization request with this code", "by": "Issuer", "deadline": "Never (TPR 2.13.2)" }, { "action": "first ride risk claim after a declined contactless transit aggregated transaction", "by": "Transit acquirer", "deadline": "Unrecoverable: may be sent at once, as a First Presentment/1240 with no approval, for no more than the first ride risk limit of the merchant's country (TPR 4.5.5, Tables 22 and 23)" } ], "applies_to": "All Mastercard regions for Mastercard, Maestro and Cirrus transactions on Mastercard's network; in the EEA, the UK and Gibraltar many of these rules refer to the registered switch the customer chooses; transit categories differ in Australia (TPR Table 24)" }, "caveat": "The transit categories come from the First Ride Risk framework: they cover contactless transit aggregated transactions sent through the Dual Message System by a transit merchant in a country that has adopted the framework, in general only for cards issued in that country, and they are not a general retry rule (TPR 4.5.5, p. 162). Any valid response code missing from Table 23 counts as Unrecoverable. Table 22 still refers to this table as Table 7, a stale internal reference.", "related": [ "mastercard:refund", "mastercard-decline:57", "mastercard-decline:58", "mastercard:messages" ], "basis": { "sources": "Transaction Processing Rules, 9 June 2026 edition, sections 3.3.1, 2.7.1, 4.5.4, 4.5.5 Tables 22 and 23, Asia/Pacific Region 4.5.5 Table 24, 2.13.2. Label and category read from Table 23 on pp. 163 to 164, with each entry's column fixed from its position on the page; placed Unrecoverable in Table 24 (pp. 175 to 176). Read from a copy downloaded from Mastercard's public rules page on 2026-09-19. Nothing is quoted. Medium: the label, category and retry rules follow from the cited sections, but what makes an issuer send this code is inferred from the label, and the defining specifications are not public to Orca.", "confidence": "medium" }, "currency": { "effective_since": "Before the current edition; start not stated in it", "effective_note": "Label and category as in the 9 June 2026 edition of the Transaction Processing Rules, whose summary of changes says it updated the Table 23 categories and removed past effective dates, so neither when this code's category began nor what it was before is shown. No dated change to this code was found in the edition. Mastercard reissues the manual on no fixed calendar [Inference].", "source_edition": "Transaction Processing Rules, 9 June 2026 edition (https://www.mastercard.com/content/dam/mccom/shared/business/support/rules-pdfs/transaction-processing-rules.pdf)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.mastercard.com/content/dam/mccom/shared/business/support/rules-pdfs/transaction-processing-rules.pdf", "source_class": "authoritative_primary", "source_title": "Transaction Processing Rules, 9 June 2026 edition", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms Mastercard's label for response value 12 and its Table 23 decline value category (Unrecoverable) in Transaction Processing Rules 4.5.5, read by column position on pages 163 to 165, and the Table 24 Australia category on pages 175 to 176; also confirms the merchant-initiated retry framework in rules 3.3.1 and 2.7.1 (the 04, 14, 15, 41, 43 and 54 no-retry bar, the Merchant Advice Code scenarios, and the 24 hour, 13 day deferred card-present resubmission window) and confirms this code is invalid as an issuer answer to a refund authorization." } ] }, "rail_name": "Mastercard Decline Response Codes (partial)", "governing_authority": "Mastercard", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "mastercard-decline:13", "id": "13", "rail": "mastercard-decline", "kind": "reason-code", "name": "Invalid amount", "group": "administrative", "summary": "Decline because the amount in the request is not acceptable to the issuer.", "triggers": [ "The amount requested is invalid, for example in form or size [Inference from Mastercard's label; the defining text is in technical specifications not public to Orca]" ], "actions": [ "Merchant (merchant-initiated retries): decide whether and when to retry from this code and the Merchant Advice Code together (TPR 3.3.1, p. 124).", "Transit acquirer: may claim the first ride debt at once with a First Presentment/1240 carrying no approval, up to the country's first ride risk limit (TPR 4.5.5, pp. 163 to 165)." ], "retry": { "allowed": true, "rule": "No blanket bar in the rules read. A card-not-present merchant that retries a merchant-initiated transaction must weigh this code together with the Merchant Advice Code: 01 means get updated account data first, 02 means wait 24 hours, 03 or 21 means stop (TPR 3.3.1, Table 20, p. 124). Which advice codes may accompany this code is set in the Dual and Single Message System specifications, which are not public to Orca. A declined cardholder-initiated transaction may not come back as a merchant-initiated one, a declined token cryptogram may not be sent again, and a retry must not alter merchant data: it carries the same merchant name, address, acceptor ID and POS condition values, with either the card data the cardholder first gave, a tokenized stored credential, or data updated through the cardholder or the Automatic Billing Updater (TPR 3.3.1, pp. 124 to 125). For a declined deferred card-present authorization outside transit, resubmission needs Merchant Advice Code 02 or another advice code giving a retry period, and a decline value that does not restrict retries; the rules read do not say whether this code restricts retries. Retries then run every 24 hours for up to 13 consecutive days (TPR 2.7.1, p. 54). Transit debt recovery follows the transit table category, not these rules (TPR 4.5.5)." }, "facts": { "return_windows": [ { "action": "resubmit a declined merchant-initiated authorization", "by": "Merchant", "deadline": "Set by the Merchant Advice Code on the decline: 01 update the account data first, 02 wait 24 hours, 03 or 21 never; with no advice code the rules read set no interval (TPR 3.3.1, Table 20)" }, { "action": "resubmit a declined deferred card-present authorization (not transit)", "by": "Merchant", "deadline": "Only when Merchant Advice Code 02 or another code giving a retry period came with the decline and this code does not restrict retries, which the rules read do not settle: no sooner than 24 hours after it, then at most once every 24 hours for up to 13 consecutive days (TPR 2.7.1)" }, { "action": "first ride risk claim after a declined contactless transit aggregated transaction", "by": "Transit acquirer", "deadline": "Unrecoverable: may be sent at once, as a First Presentment/1240 with no approval, for no more than the first ride risk limit of the merchant's country (TPR 4.5.5, Tables 22 and 23)" } ], "applies_to": "All Mastercard regions for Mastercard, Maestro and Cirrus transactions on Mastercard's network; in the EEA, the UK and Gibraltar many of these rules refer to the registered switch the customer chooses; transit categories differ in Australia (TPR Table 24)" }, "caveat": "An acquirer's failure rate for Maestro POS and ATM transactions counts declines for invalid amount or format error, and a rate above two percent for two months running is substandard (TPR 2.4.1) [Inference: the rule names the reasons in words; that it means codes 13 and 30 is Orca's reading]. The transit categories come from the First Ride Risk framework: they cover contactless transit aggregated transactions sent through the Dual Message System by a transit merchant in a country that has adopted the framework, in general only for cards issued in that country, and they are not a general retry rule (TPR 4.5.5, p. 162). Any valid response code missing from Table 23 counts as Unrecoverable. Table 22 still refers to this table as Table 7, a stale internal reference.", "related": [ "mastercard-decline:12", "mastercard:messages", "mastercard-decline:30" ], "basis": { "sources": "Transaction Processing Rules, 9 June 2026 edition, sections 3.3.1, 2.7.1, 4.5.4, 4.5.5 Tables 22 and 23, Asia/Pacific Region 4.5.5 Table 24, 2.4.1. Label and category read from Table 23 on pp. 163 to 164, with each entry's column fixed from its position on the page; placed Unrecoverable in Table 24 (pp. 175 to 176). Read from a copy downloaded from Mastercard's public rules page on 2026-09-19. Nothing is quoted. Medium: the label, category and retry rules follow from the cited sections, but what makes an issuer send this code is inferred from the label, and the defining specifications are not public to Orca.", "confidence": "medium" }, "currency": { "effective_since": "Before the current edition; start not stated in it", "effective_note": "Label and category as in the 9 June 2026 edition of the Transaction Processing Rules, whose summary of changes says it updated the Table 23 categories and removed past effective dates, so neither when this code's category began nor what it was before is shown. No dated change to this code was found in the edition. Mastercard reissues the manual on no fixed calendar [Inference].", "source_edition": "Transaction Processing Rules, 9 June 2026 edition (https://www.mastercard.com/content/dam/mccom/shared/business/support/rules-pdfs/transaction-processing-rules.pdf)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.mastercard.com/content/dam/mccom/shared/business/support/rules-pdfs/transaction-processing-rules.pdf", "source_class": "authoritative_primary", "source_title": "Transaction Processing Rules, 9 June 2026 edition", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms Mastercard's label for response value 13 and its Table 23 decline value category (Unrecoverable) in Transaction Processing Rules 4.5.5, read by column position on pages 163 to 165, and the Table 24 Australia category on pages 175 to 176; also confirms the merchant-initiated retry framework in rules 3.3.1 and 2.7.1 (the 04, 14, 15, 41, 43 and 54 no-retry bar, the Merchant Advice Code scenarios, and the 24 hour, 13 day deferred card-present resubmission window)." } ] }, "rail_name": "Mastercard Decline Response Codes (partial)", "governing_authority": "Mastercard", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "mastercard-decline:14", "id": "14", "rail": "mastercard-decline", "kind": "reason-code", "name": "Invalid card number", "group": "account", "summary": "Decline because the card number is not valid at the issuer. A card-not-present merchant may never retry the same transaction with that number and expiry date.", "triggers": [ "The primary account number does not match a valid card at the issuer [Inference from Mastercard's label; the defining text is in technical specifications not public to Orca]" ], "actions": [ "Merchant (card-not-present): stop; send no further authorization request for this transaction with this PAN and expiry date (TPR 3.3.1, pp. 123 to 124).", "Merchant (deferred card-present, not transit): do not resubmit (TPR 2.7.1, p. 54).", "Transit acquirer: a first ride risk claim for 14 may be rejected by the Global Clearing Management System with error 2358 when the tap came from a digitized card on a closed account; after that rejection the debt may be claimed with a Fee Collection/1740 message (TPR 4.5.5, p. 165).", "Transit acquirer: may claim the first ride debt at once with a First Presentment/1240 carrying no approval, up to the country's first ride risk limit (TPR 4.5.5, pp. 163 to 165)." ], "retry": { "allowed": false, "rule": "No. After this code a merchant must never send another authorization request for the same card-not-present transaction with the same PAN and expiry date (TPR 3.3.1, pp. 123 to 124), and a declined deferred card-present authorization outside transit must not be resubmitted either (TPR 2.7.1, p. 54). The bar is tied to that PAN and expiry date; the rules read do not bar a request made with different card data [Inference from the wording of the bar]. Transit debt recovery and claims follow the transit table instead (TPR 4.5.5)." }, "facts": { "return_windows": [ { "action": "new authorization request for the same card-not-present transaction with the same PAN and expiry date", "by": "Merchant", "deadline": "Never (TPR 3.3.1)" }, { "action": "resubmit a declined deferred card-present authorization (not transit)", "by": "Merchant", "deadline": "Never (TPR 2.7.1)" }, { "action": "first ride risk claim after a declined contactless transit aggregated transaction", "by": "Transit acquirer", "deadline": "Unrecoverable: may be sent at once, as a First Presentment/1240 with no approval, for no more than the first ride risk limit of the merchant's country (TPR 4.5.5, Tables 22 and 23)" }, { "action": "transit debt recovery or first ride risk claim, Australia", "by": "Transit merchant and its acquirer (Australia)", "deadline": "Table 24 places this code in Not Claimable (no claim), not the global category (TPR Asia/Pacific Region 4.5.5, pp. 175 to 176)" } ], "applies_to": "All Mastercard regions for Mastercard, Maestro and Cirrus transactions on Mastercard's network; in the EEA, the UK and Gibraltar many of these rules refer to the registered switch the customer chooses; transit categories differ in Australia (TPR Table 24)" }, "caveat": "The transit categories come from the First Ride Risk framework: they cover contactless transit aggregated transactions sent through the Dual Message System by a transit merchant in a country that has adopted the framework, in general only for cards issued in that country, and they are not a general retry rule (TPR 4.5.5, p. 162). Any valid response code missing from Table 23 counts as Unrecoverable. Table 22 still refers to this table as Table 7, a stale internal reference.", "related": [ "mastercard-decline:15", "mastercard-decline:46", "mastercard-decline:54", "mastercard:messages" ], "basis": { "sources": "Transaction Processing Rules, 9 June 2026 edition, sections 3.3.1, 2.7.1, 4.5.4, 4.5.5 Tables 22 and 23, Asia/Pacific Region 4.5.5 Table 24. Label and category read from Table 23 on pp. 163 to 164, with each entry's column fixed from its position on the page; placed Not Claimable in Table 24 (pp. 175 to 176). Read from a copy downloaded from Mastercard's public rules page on 2026-09-19. Nothing is quoted. Medium: the label, category and retry rules follow from the cited sections, but what makes an issuer send this code is inferred from the label, and the defining specifications are not public to Orca.", "confidence": "medium" }, "currency": { "effective_since": "Before the current edition; start not stated in it", "effective_note": "Label and category as in the 9 June 2026 edition of the Transaction Processing Rules, whose summary of changes says it updated the Table 23 categories and removed past effective dates, so neither when this code's category began nor what it was before is shown. No dated change to this code was found in the edition. Mastercard reissues the manual on no fixed calendar [Inference].", "source_edition": "Transaction Processing Rules, 9 June 2026 edition (https://www.mastercard.com/content/dam/mccom/shared/business/support/rules-pdfs/transaction-processing-rules.pdf)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.mastercard.com/content/dam/mccom/shared/business/support/rules-pdfs/transaction-processing-rules.pdf", "source_class": "authoritative_primary", "source_title": "Transaction Processing Rules, 9 June 2026 edition", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms Mastercard's label for response value 14 and its Table 23 decline value category (Unrecoverable) in Transaction Processing Rules 4.5.5, read by column position on pages 163 to 165, and the Table 24 Australia category on pages 175 to 176; also confirms the merchant-initiated retry framework in rules 3.3.1 and 2.7.1 (the 04, 14, 15, 41, 43 and 54 no-retry bar, the Merchant Advice Code scenarios, and the 24 hour, 13 day deferred card-present resubmission window) and confirms the bar on any further card-not-present or deferred card-present retry." } ] }, "rail_name": "Mastercard Decline Response Codes (partial)", "governing_authority": "Mastercard", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "mastercard-decline:15", "id": "15", "rail": "mastercard-decline", "kind": "reason-code", "name": "Invalid issuer", "group": "account", "summary": "Decline because the issuer indicated by the card number is not valid. A card-not-present merchant may never retry the same transaction with that card number and expiry date.", "triggers": [ "The card number does not lead to a valid issuer [Inference from Mastercard's label; the defining text is in technical specifications not public to Orca]" ], "actions": [ "Merchant (card-not-present): stop; send no further authorization request for this transaction with this PAN and expiry date (TPR 3.3.1, pp. 123 to 124).", "Merchant (deferred card-present, not transit): do not resubmit (TPR 2.7.1, p. 54).", "Transit merchant: bears the debt; no first ride risk claim is allowed (TPR 4.5.5, pp. 163 to 165)." ], "retry": { "allowed": false, "rule": "No. After this code a merchant must never send another authorization request for the same card-not-present transaction with the same PAN and expiry date (TPR 3.3.1, pp. 123 to 124), and a declined deferred card-present authorization outside transit must not be resubmitted either (TPR 2.7.1, p. 54). The bar is tied to that PAN and expiry date; the rules read do not bar a request made with different card data [Inference from the wording of the bar]. Transit debt recovery and claims follow the transit table instead (TPR 4.5.5)." }, "facts": { "return_windows": [ { "action": "new authorization request for the same card-not-present transaction with the same PAN and expiry date", "by": "Merchant", "deadline": "Never (TPR 3.3.1)" }, { "action": "resubmit a declined deferred card-present authorization (not transit)", "by": "Merchant", "deadline": "Never (TPR 2.7.1)" }, { "action": "first ride risk claim after a declined contactless transit aggregated transaction", "by": "Transit acquirer", "deadline": "Never: Not Claimable (TPR 4.5.5, Table 23)" } ], "applies_to": "All Mastercard regions for Mastercard, Maestro and Cirrus transactions on Mastercard's network; in the EEA, the UK and Gibraltar many of these rules refer to the registered switch the customer chooses; transit categories differ in Australia (TPR Table 24)" }, "caveat": "The transit categories come from the First Ride Risk framework: they cover contactless transit aggregated transactions sent through the Dual Message System by a transit merchant in a country that has adopted the framework, in general only for cards issued in that country, and they are not a general retry rule (TPR 4.5.5, p. 162). Any valid response code missing from Table 23 counts as Unrecoverable. Table 22 still refers to this table as Table 7, a stale internal reference.", "related": [ "mastercard-decline:14", "mastercard-decline:54", "mastercard:messages" ], "basis": { "sources": "Transaction Processing Rules, 9 June 2026 edition, sections 3.3.1, 2.7.1, 4.5.4, 4.5.5 Tables 22 and 23, Asia/Pacific Region 4.5.5 Table 24. Label and category read from Table 23 on pp. 163 to 164, with each entry's column fixed from its position on the page; placed Not Claimable in Table 24 (pp. 175 to 176). Read from a copy downloaded from Mastercard's public rules page on 2026-09-19. Nothing is quoted. Medium: the label, category and retry rules follow from the cited sections, but what makes an issuer send this code is inferred from the label, and the defining specifications are not public to Orca.", "confidence": "medium" }, "currency": { "effective_since": "Before the current edition; start not stated in it", "effective_note": "Label and category as in the 9 June 2026 edition of the Transaction Processing Rules, whose summary of changes says it updated the Table 23 categories and removed past effective dates, so neither when this code's category began nor what it was before is shown. No dated change to this code was found in the edition. Mastercard reissues the manual on no fixed calendar [Inference].", "source_edition": "Transaction Processing Rules, 9 June 2026 edition (https://www.mastercard.com/content/dam/mccom/shared/business/support/rules-pdfs/transaction-processing-rules.pdf)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.mastercard.com/content/dam/mccom/shared/business/support/rules-pdfs/transaction-processing-rules.pdf", "source_class": "authoritative_primary", "source_title": "Transaction Processing Rules, 9 June 2026 edition", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms Mastercard's label for response value 15 and its Table 23 decline value category (Not Claimable) in Transaction Processing Rules 4.5.5, read by column position on pages 163 to 165, and the Table 24 Australia category on pages 175 to 176; also confirms the merchant-initiated retry framework in rules 3.3.1 and 2.7.1 (the 04, 14, 15, 41, 43 and 54 no-retry bar, the Merchant Advice Code scenarios, and the 24 hour, 13 day deferred card-present resubmission window) and confirms the bar on any further card-not-present or deferred card-present retry." } ] }, "rail_name": "Mastercard Decline Response Codes (partial)", "governing_authority": "Mastercard", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "mastercard-decline:30", "id": "30", "rail": "mastercard-decline", "kind": "reason-code", "name": "Format error", "group": "technical", "summary": "Decline because the request message was badly formed. Outside Australia transit merchants cannot claim debt after it, and an issuer may not decline a refund only for a format error.", "triggers": [ "The authorization message does not meet the format the network or issuer requires [Inference from Mastercard's label; the defining text is in technical specifications not public to Orca]" ], "actions": [ "Merchant (merchant-initiated retries): decide whether and when to retry from this code and the Merchant Advice Code together (TPR 3.3.1, p. 124).", "Issuer: must not decline a refund authorization solely because of a message format error (TPR 2.13.2, p. 67).", "Transit merchant: bears the debt; no first ride risk claim is allowed (TPR 4.5.5, pp. 163 to 165)." ], "retry": { "allowed": true, "rule": "No blanket bar in the rules read. A card-not-present merchant that retries a merchant-initiated transaction must weigh this code together with the Merchant Advice Code: 01 means get updated account data first, 02 means wait 24 hours, 03 or 21 means stop (TPR 3.3.1, Table 20, p. 124). Which advice codes may accompany this code is set in the Dual and Single Message System specifications, which are not public to Orca. A declined cardholder-initiated transaction may not come back as a merchant-initiated one, a declined token cryptogram may not be sent again, and a retry must not alter merchant data: it carries the same merchant name, address, acceptor ID and POS condition values, with either the card data the cardholder first gave, a tokenized stored credential, or data updated through the cardholder or the Automatic Billing Updater (TPR 3.3.1, pp. 124 to 125). For a declined deferred card-present authorization outside transit, resubmission needs Merchant Advice Code 02 or another advice code giving a retry period, and a decline value that does not restrict retries; the rules read do not say whether this code restricts retries. Retries then run every 24 hours for up to 13 consecutive days (TPR 2.7.1, p. 54). Transit debt recovery follows the transit table category, not these rules (TPR 4.5.5)." }, "facts": { "return_windows": [ { "action": "resubmit a declined merchant-initiated authorization", "by": "Merchant", "deadline": "Set by the Merchant Advice Code on the decline: 01 update the account data first, 02 wait 24 hours, 03 or 21 never; with no advice code the rules read set no interval (TPR 3.3.1, Table 20)" }, { "action": "resubmit a declined deferred card-present authorization (not transit)", "by": "Merchant", "deadline": "Only when Merchant Advice Code 02 or another code giving a retry period came with the decline and this code does not restrict retries, which the rules read do not settle: no sooner than 24 hours after it, then at most once every 24 hours for up to 13 consecutive days (TPR 2.7.1)" }, { "action": "first ride risk claim after a declined contactless transit aggregated transaction", "by": "Transit acquirer", "deadline": "Never: Not Claimable (TPR 4.5.5, Table 23)" }, { "action": "transit debt recovery or first ride risk claim, Australia", "by": "Transit merchant and its acquirer (Australia)", "deadline": "Table 24 places this code in Recoverable (recover first; claim only after nine failed attempts over 45 days), not the global category (TPR Asia/Pacific Region 4.5.5, pp. 175 to 176)" } ], "applies_to": "All Mastercard regions for Mastercard, Maestro and Cirrus transactions on Mastercard's network; in the EEA, the UK and Gibraltar many of these rules refer to the registered switch the customer chooses; transit categories differ in Australia (TPR Table 24)" }, "caveat": "An acquirer's failure rate for Maestro POS and ATM transactions counts declines for invalid amount or format error, and a rate above two percent for two months running is substandard (TPR 2.4.1) [Inference: the rule names the reasons in words; that it means codes 13 and 30 is Orca's reading]. The transit categories come from the First Ride Risk framework: they cover contactless transit aggregated transactions sent through the Dual Message System by a transit merchant in a country that has adopted the framework, in general only for cards issued in that country, and they are not a general retry rule (TPR 4.5.5, p. 162). Any valid response code missing from Table 23 counts as Unrecoverable. Table 22 still refers to this table as Table 7, a stale internal reference.", "related": [ "mastercard-decline:13", "mastercard-decline:92", "mastercard-decline:94", "mastercard-decline:96", "mastercard:messages" ], "basis": { "sources": "Transaction Processing Rules, 9 June 2026 edition, sections 3.3.1, 2.7.1, 4.5.4, 4.5.5 Tables 22 and 23, Asia/Pacific Region 4.5.5 Table 24, 2.4.1, 2.13.2. Label and category read from Table 23 on pp. 163 to 164, with each entry's column fixed from its position on the page; placed Recoverable in Table 24 (pp. 175 to 176). Read from a copy downloaded from Mastercard's public rules page on 2026-09-19. Nothing is quoted. Medium: the label, category and retry rules follow from the cited sections, but what makes an issuer send this code is inferred from the label, and the defining specifications are not public to Orca.", "confidence": "medium" }, "currency": { "effective_since": "Before the current edition; start not stated in it", "effective_note": "Label and category as in the 9 June 2026 edition of the Transaction Processing Rules, whose summary of changes says it updated the Table 23 categories and removed past effective dates, so neither when this code's category began nor what it was before is shown. No dated change to this code was found in the edition. Mastercard reissues the manual on no fixed calendar [Inference].", "source_edition": "Transaction Processing Rules, 9 June 2026 edition (https://www.mastercard.com/content/dam/mccom/shared/business/support/rules-pdfs/transaction-processing-rules.pdf)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.mastercard.com/content/dam/mccom/shared/business/support/rules-pdfs/transaction-processing-rules.pdf", "source_class": "authoritative_primary", "source_title": "Transaction Processing Rules, 9 June 2026 edition", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms Mastercard's label for response value 30 and its Table 23 decline value category (Not Claimable) in Transaction Processing Rules 4.5.5, read by column position on pages 163 to 165, and the Table 24 Australia category on pages 175 to 176; also confirms the merchant-initiated retry framework in rules 3.3.1 and 2.7.1 (the 04, 14, 15, 41, 43 and 54 no-retry bar, the Merchant Advice Code scenarios, and the 24 hour, 13 day deferred card-present resubmission window) and confirms an issuer must not decline a refund solely for a message format error." } ] }, "rail_name": "Mastercard Decline Response Codes (partial)", "governing_authority": "Mastercard", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "mastercard-decline:41", "id": "41", "rail": "mastercard-decline", "kind": "reason-code", "name": "Lost card", "group": "authorization", "summary": "Decline because the card has been reported lost. A card-not-present merchant may never retry the same transaction on that card number and expiry date.", "triggers": [ "The cardholder or issuer has reported the card lost [Inference from Mastercard's label; the defining text is in technical specifications not public to Orca]" ], "actions": [ "Merchant (card-not-present): stop; send no further authorization request for this transaction with this PAN and expiry date (TPR 3.3.1, pp. 123 to 124).", "Merchant (deferred card-present, not transit): do not resubmit (TPR 2.7.1, p. 54).", "Transit acquirer: may claim the first ride debt at once with a First Presentment/1240 carrying no approval, up to the country's first ride risk limit (TPR 4.5.5, pp. 163 to 165)." ], "retry": { "allowed": false, "rule": "No. After this code a merchant must never send another authorization request for the same card-not-present transaction with the same PAN and expiry date (TPR 3.3.1, pp. 123 to 124), and a declined deferred card-present authorization outside transit must not be resubmitted either (TPR 2.7.1, p. 54). The bar is tied to that PAN and expiry date; the rules read do not bar a request made with different card data [Inference from the wording of the bar]. Transit debt recovery and claims follow the transit table instead (TPR 4.5.5)." }, "facts": { "return_windows": [ { "action": "new authorization request for the same card-not-present transaction with the same PAN and expiry date", "by": "Merchant", "deadline": "Never (TPR 3.3.1)" }, { "action": "resubmit a declined deferred card-present authorization (not transit)", "by": "Merchant", "deadline": "Never (TPR 2.7.1)" }, { "action": "first ride risk claim after a declined contactless transit aggregated transaction", "by": "Transit acquirer", "deadline": "Unrecoverable: may be sent at once, as a First Presentment/1240 with no approval, for no more than the first ride risk limit of the merchant's country (TPR 4.5.5, Tables 22 and 23)" }, { "action": "transit debt recovery or first ride risk claim, Australia", "by": "Transit merchant and its acquirer (Australia)", "deadline": "Table 24 places this code in Not Claimable (no claim), not the global category (TPR Asia/Pacific Region 4.5.5, pp. 175 to 176)" } ], "applies_to": "All Mastercard regions for Mastercard, Maestro and Cirrus transactions on Mastercard's network; in the EEA, the UK and Gibraltar many of these rules refer to the registered switch the customer chooses; transit categories differ in Australia (TPR Table 24)" }, "caveat": "The transit categories come from the First Ride Risk framework: they cover contactless transit aggregated transactions sent through the Dual Message System by a transit merchant in a country that has adopted the framework, in general only for cards issued in that country, and they are not a general retry rule (TPR 4.5.5, p. 162). Any valid response code missing from Table 23 counts as Unrecoverable. Table 22 still refers to this table as Table 7, a stale internal reference.", "related": [ "mastercard-decline:43", "mastercard-decline:04", "mastercard-decline:14", "mastercard:messages" ], "basis": { "sources": "Transaction Processing Rules, 9 June 2026 edition, sections 3.3.1, 2.7.1, 4.5.4, 4.5.5 Tables 22 and 23, Asia/Pacific Region 4.5.5 Table 24. Label and category read from Table 23 on pp. 163 to 164, with each entry's column fixed from its position on the page; placed Not Claimable in Table 24 (pp. 175 to 176). Read from a copy downloaded from Mastercard's public rules page on 2026-09-19. Nothing is quoted. Medium: the label, category and retry rules follow from the cited sections, but what makes an issuer send this code is inferred from the label, and the defining specifications are not public to Orca.", "confidence": "medium" }, "currency": { "effective_since": "Before the current edition; start not stated in it", "effective_note": "Label and category as in the 9 June 2026 edition of the Transaction Processing Rules, whose summary of changes says it updated the Table 23 categories and removed past effective dates, so neither when this code's category began nor what it was before is shown. No dated change to this code was found in the edition. Mastercard reissues the manual on no fixed calendar [Inference].", "source_edition": "Transaction Processing Rules, 9 June 2026 edition (https://www.mastercard.com/content/dam/mccom/shared/business/support/rules-pdfs/transaction-processing-rules.pdf)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.mastercard.com/content/dam/mccom/shared/business/support/rules-pdfs/transaction-processing-rules.pdf", "source_class": "authoritative_primary", "source_title": "Transaction Processing Rules, 9 June 2026 edition", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms Mastercard's label for response value 41 and its Table 23 decline value category (Unrecoverable) in Transaction Processing Rules 4.5.5, read by column position on pages 163 to 165, and the Table 24 Australia category on pages 175 to 176; also confirms the merchant-initiated retry framework in rules 3.3.1 and 2.7.1 (the 04, 14, 15, 41, 43 and 54 no-retry bar, the Merchant Advice Code scenarios, and the 24 hour, 13 day deferred card-present resubmission window) and confirms the bar on any further card-not-present or deferred card-present retry." } ] }, "rail_name": "Mastercard Decline Response Codes (partial)", "governing_authority": "Mastercard", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "mastercard-decline:43", "id": "43", "rail": "mastercard-decline", "kind": "reason-code", "name": "Stolen card", "group": "authorization", "summary": "Decline because the card has been reported stolen. A card-not-present merchant may never retry the same transaction on that card number and expiry date.", "triggers": [ "The cardholder or issuer has reported the card stolen [Inference from Mastercard's label; the defining text is in technical specifications not public to Orca]" ], "actions": [ "Merchant (card-not-present): stop; send no further authorization request for this transaction with this PAN and expiry date (TPR 3.3.1, pp. 123 to 124).", "Merchant (deferred card-present, not transit): do not resubmit (TPR 2.7.1, p. 54).", "Transit acquirer: may claim the first ride debt at once with a First Presentment/1240 carrying no approval, up to the country's first ride risk limit (TPR 4.5.5, pp. 163 to 165)." ], "retry": { "allowed": false, "rule": "No. After this code a merchant must never send another authorization request for the same card-not-present transaction with the same PAN and expiry date (TPR 3.3.1, pp. 123 to 124), and a declined deferred card-present authorization outside transit must not be resubmitted either (TPR 2.7.1, p. 54). The bar is tied to that PAN and expiry date; the rules read do not bar a request made with different card data [Inference from the wording of the bar]. Transit debt recovery and claims follow the transit table instead (TPR 4.5.5)." }, "facts": { "return_windows": [ { "action": "new authorization request for the same card-not-present transaction with the same PAN and expiry date", "by": "Merchant", "deadline": "Never (TPR 3.3.1)" }, { "action": "resubmit a declined deferred card-present authorization (not transit)", "by": "Merchant", "deadline": "Never (TPR 2.7.1)" }, { "action": "first ride risk claim after a declined contactless transit aggregated transaction", "by": "Transit acquirer", "deadline": "Unrecoverable: may be sent at once, as a First Presentment/1240 with no approval, for no more than the first ride risk limit of the merchant's country (TPR 4.5.5, Tables 22 and 23)" }, { "action": "transit debt recovery or first ride risk claim, Australia", "by": "Transit merchant and its acquirer (Australia)", "deadline": "Table 24 places this code in Not Claimable (no claim), not the global category (TPR Asia/Pacific Region 4.5.5, pp. 175 to 176)" } ], "applies_to": "All Mastercard regions for Mastercard, Maestro and Cirrus transactions on Mastercard's network; in the EEA, the UK and Gibraltar many of these rules refer to the registered switch the customer chooses; transit categories differ in Australia (TPR Table 24)" }, "caveat": "The transit categories come from the First Ride Risk framework: they cover contactless transit aggregated transactions sent through the Dual Message System by a transit merchant in a country that has adopted the framework, in general only for cards issued in that country, and they are not a general retry rule (TPR 4.5.5, p. 162). Any valid response code missing from Table 23 counts as Unrecoverable. Table 22 still refers to this table as Table 7, a stale internal reference.", "related": [ "mastercard-decline:41", "mastercard-decline:04", "mastercard-decline:14", "mastercard:messages" ], "basis": { "sources": "Transaction Processing Rules, 9 June 2026 edition, sections 3.3.1, 2.7.1, 4.5.4, 4.5.5 Tables 22 and 23, Asia/Pacific Region 4.5.5 Table 24. Label and category read from Table 23 on pp. 163 to 164, with each entry's column fixed from its position on the page; placed Not Claimable in Table 24 (pp. 175 to 176). Read from a copy downloaded from Mastercard's public rules page on 2026-09-19. Nothing is quoted. Medium: the label, category and retry rules follow from the cited sections, but what makes an issuer send this code is inferred from the label, and the defining specifications are not public to Orca.", "confidence": "medium" }, "currency": { "effective_since": "Before the current edition; start not stated in it", "effective_note": "Label and category as in the 9 June 2026 edition of the Transaction Processing Rules, whose summary of changes says it updated the Table 23 categories and removed past effective dates, so neither when this code's category began nor what it was before is shown. No dated change to this code was found in the edition. Mastercard reissues the manual on no fixed calendar [Inference].", "source_edition": "Transaction Processing Rules, 9 June 2026 edition (https://www.mastercard.com/content/dam/mccom/shared/business/support/rules-pdfs/transaction-processing-rules.pdf)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.mastercard.com/content/dam/mccom/shared/business/support/rules-pdfs/transaction-processing-rules.pdf", "source_class": "authoritative_primary", "source_title": "Transaction Processing Rules, 9 June 2026 edition", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms Mastercard's label for response value 43 and its Table 23 decline value category (Unrecoverable) in Transaction Processing Rules 4.5.5, read by column position on pages 163 to 165, and the Table 24 Australia category on pages 175 to 176; also confirms the merchant-initiated retry framework in rules 3.3.1 and 2.7.1 (the 04, 14, 15, 41, 43 and 54 no-retry bar, the Merchant Advice Code scenarios, and the 24 hour, 13 day deferred card-present resubmission window) and confirms the bar on any further card-not-present or deferred card-present retry." } ] }, "rail_name": "Mastercard Decline Response Codes (partial)", "governing_authority": "Mastercard", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "mastercard-decline:46", "id": "46", "rail": "mastercard-decline", "kind": "reason-code", "name": "Closed account", "group": "account", "summary": "Decline because the account behind the card is closed.", "triggers": [ "The account the card draws on has been closed [Inference from Mastercard's label; the defining text is in technical specifications not public to Orca]" ], "actions": [ "Merchant (merchant-initiated retries): decide whether and when to retry from this code and the Merchant Advice Code together (TPR 3.3.1, p. 124).", "Transit acquirer: may claim the first ride debt at once with a First Presentment/1240 carrying no approval, up to the country's first ride risk limit (TPR 4.5.5, pp. 163 to 165)." ], "retry": { "allowed": true, "rule": "No blanket bar in the rules read. A card-not-present merchant that retries a merchant-initiated transaction must weigh this code together with the Merchant Advice Code: 01 means get updated account data first, 02 means wait 24 hours, 03 or 21 means stop (TPR 3.3.1, Table 20, p. 124). Which advice codes may accompany this code is set in the Dual and Single Message System specifications, which are not public to Orca. A declined cardholder-initiated transaction may not come back as a merchant-initiated one, a declined token cryptogram may not be sent again, and a retry must not alter merchant data: it carries the same merchant name, address, acceptor ID and POS condition values, with either the card data the cardholder first gave, a tokenized stored credential, or data updated through the cardholder or the Automatic Billing Updater (TPR 3.3.1, pp. 124 to 125). For a declined deferred card-present authorization outside transit, resubmission needs Merchant Advice Code 02 or another advice code giving a retry period, and a decline value that does not restrict retries; the rules read do not say whether this code restricts retries. Retries then run every 24 hours for up to 13 consecutive days (TPR 2.7.1, p. 54). Transit debt recovery follows the transit table category, not these rules (TPR 4.5.5)." }, "facts": { "return_windows": [ { "action": "resubmit a declined merchant-initiated authorization", "by": "Merchant", "deadline": "Set by the Merchant Advice Code on the decline: 01 update the account data first, 02 wait 24 hours, 03 or 21 never; with no advice code the rules read set no interval (TPR 3.3.1, Table 20)" }, { "action": "resubmit a declined deferred card-present authorization (not transit)", "by": "Merchant", "deadline": "Only when Merchant Advice Code 02 or another code giving a retry period came with the decline and this code does not restrict retries, which the rules read do not settle: no sooner than 24 hours after it, then at most once every 24 hours for up to 13 consecutive days (TPR 2.7.1)" }, { "action": "first ride risk claim after a declined contactless transit aggregated transaction", "by": "Transit acquirer", "deadline": "Unrecoverable: may be sent at once, as a First Presentment/1240 with no approval, for no more than the first ride risk limit of the merchant's country (TPR 4.5.5, Tables 22 and 23)" } ], "applies_to": "All Mastercard regions for Mastercard, Maestro and Cirrus transactions on Mastercard's network; in the EEA, the UK and Gibraltar many of these rules refer to the registered switch the customer chooses; transit categories differ in Australia (TPR Table 24)" }, "caveat": "The transit categories come from the First Ride Risk framework: they cover contactless transit aggregated transactions sent through the Dual Message System by a transit merchant in a country that has adopted the framework, in general only for cards issued in that country, and they are not a general retry rule (TPR 4.5.5, p. 162). Any valid response code missing from Table 23 counts as Unrecoverable. Table 22 still refers to this table as Table 7, a stale internal reference.", "related": [ "mastercard-decline:14", "mastercard-decline:72", "mastercard:messages" ], "basis": { "sources": "Transaction Processing Rules, 9 June 2026 edition, sections 3.3.1, 2.7.1, 4.5.4, 4.5.5 Tables 22 and 23, Asia/Pacific Region 4.5.5 Table 24. Label and category read from Table 23 on pp. 163 to 164, with each entry's column fixed from its position on the page; placed Unrecoverable in Table 24 (pp. 175 to 176). Read from a copy downloaded from Mastercard's public rules page on 2026-09-19. Nothing is quoted. Medium: the label, category and retry rules follow from the cited sections, but what makes an issuer send this code is inferred from the label, and the defining specifications are not public to Orca.", "confidence": "medium" }, "currency": { "effective_since": "Before the current edition; start not stated in it", "effective_note": "Label and category as in the 9 June 2026 edition of the Transaction Processing Rules, whose summary of changes says it updated the Table 23 categories and removed past effective dates, so neither when this code's category began nor what it was before is shown. No dated change to this code was found in the edition. Mastercard reissues the manual on no fixed calendar [Inference].", "source_edition": "Transaction Processing Rules, 9 June 2026 edition (https://www.mastercard.com/content/dam/mccom/shared/business/support/rules-pdfs/transaction-processing-rules.pdf)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.mastercard.com/content/dam/mccom/shared/business/support/rules-pdfs/transaction-processing-rules.pdf", "source_class": "authoritative_primary", "source_title": "Transaction Processing Rules, 9 June 2026 edition", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms Mastercard's label for response value 46 and its Table 23 decline value category (Unrecoverable) in Transaction Processing Rules 4.5.5, read by column position on pages 163 to 165, and the Table 24 Australia category on pages 175 to 176; also confirms the merchant-initiated retry framework in rules 3.3.1 and 2.7.1 (the 04, 14, 15, 41, 43 and 54 no-retry bar, the Merchant Advice Code scenarios, and the 24 hour, 13 day deferred card-present resubmission window)." } ] }, "rail_name": "Mastercard Decline Response Codes (partial)", "governing_authority": "Mastercard", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "mastercard-decline:51", "id": "51", "rail": "mastercard-decline", "kind": "reason-code", "name": "Insufficient funds/over credit limit", "group": "funds", "summary": "Decline because the account lacks the funds, or the credit line lacks the room, to cover the amount. It is one of three codes the rules name as open to resubmission after a declined deferred card-present authorization.", "triggers": [ "The available balance or credit is below the amount requested [Inference from Mastercard's label; the defining text is in technical specifications not public to Orca]" ], "actions": [ "Merchant (merchant-initiated retries): decide whether and when to retry from this code and the Merchant Advice Code together (TPR 3.3.1, p. 124).", "Issuer: must not answer a refund authorization with 51 (TPR 2.13.2, p. 66).", "Issuer of Mastercard credit cards: denials for insufficient funds may not exceed 10 percent of its ATM transactions (TPR 2.2.3, p. 48).", "ATM: Mastercard's recommended screen and receipt text for insufficient funds tells the cardholder to contact the financial institution (TPR Signage, Screen and Receipt Text Standards, p. 355) [Inference: the table names responses by wording, not by code].", "Transit merchant: pursue the debt with debt recovery authorizations, each no larger than the contactless transit aggregated CVM limit (TPR 4.5.4 and 4.5.5, pp. 161 to 164)." ], "retry": { "allowed": true, "rule": "No blanket bar in the rules read. A card-not-present merchant that retries a merchant-initiated transaction must weigh this code together with the Merchant Advice Code: 01 means get updated account data first, 02 means wait 24 hours, 03 or 21 means stop (TPR 3.3.1, Table 20, p. 124). Which advice codes may accompany this code is set in the Dual and Single Message System specifications, which are not public to Orca. A declined cardholder-initiated transaction may not come back as a merchant-initiated one, a declined token cryptogram may not be sent again, and a retry must not alter merchant data: it carries the same merchant name, address, acceptor ID and POS condition values, with either the card data the cardholder first gave, a tokenized stored credential, or data updated through the cardholder or the Automatic Billing Updater (TPR 3.3.1, pp. 124 to 125). For a declined deferred card-present authorization outside transit, the rules name this code as one that allows resubmission when Merchant Advice Code 02, or another advice code giving a retry period, came with it: first after at least 24 hours, then every 24 hours for up to 13 consecutive days (TPR 2.7.1, p. 54). Transit debt recovery follows the transit table category, not these rules (TPR 4.5.5)." }, "facts": { "return_windows": [ { "action": "resubmit a declined merchant-initiated authorization", "by": "Merchant", "deadline": "Set by the Merchant Advice Code on the decline: 01 update the account data first, 02 wait 24 hours, 03 or 21 never; with no advice code the rules read set no interval (TPR 3.3.1, Table 20)" }, { "action": "resubmit a declined deferred card-present authorization (not transit)", "by": "Merchant", "deadline": "Only when Merchant Advice Code 02 or another code giving a retry period came with the decline: no sooner than 24 hours after it, then at most once every 24 hours for up to 13 consecutive days (TPR 2.7.1)" }, { "action": "answer a refund authorization request with this code", "by": "Issuer", "deadline": "Never (TPR 2.13.2)" }, { "action": "resubmit a declined deferred Maestro authorization, Belgium domestic", "by": "Acquirer (Belgium)", "deadline": "Once every 24 hours until 30 calendar days after the transaction date (TPR Europe Region 2.7.1, p. 92)" }, { "action": "transit debt recovery after a declined contactless transit aggregated transaction", "by": "Transit merchant and its acquirer", "deadline": "Recoverable: pursue the debt with debt recovery authorizations; a first ride risk claim is allowed only after at least nine attempts, no more than one per 24 hours, over the 45 calendar days from the original decline with the last on day 45, each declined for a Recoverable or Temporarily Recoverable reason (TPR 4.5.5, Tables 22 and 23)" }, { "action": "transit debt recovery or first ride risk claim, Australia", "by": "Transit merchant and its acquirer (Australia)", "deadline": "Table 24 places this code in Temporarily Recoverable (at least nine recovery attempts within 45 days, then a claim), not the global category (TPR Asia/Pacific Region 4.5.5, pp. 175 to 176)" } ], "applies_to": "All Mastercard regions for Mastercard, Maestro and Cirrus transactions on Mastercard's network; in the EEA, the UK and Gibraltar many of these rules refer to the registered switch the customer chooses; transit categories differ in Australia (TPR Table 24)" }, "caveat": "The transit categories come from the First Ride Risk framework: they cover contactless transit aggregated transactions sent through the Dual Message System by a transit merchant in a country that has adopted the framework, in general only for cards issued in that country, and they are not a general retry rule (TPR 4.5.5, p. 162). Any valid response code missing from Table 23 counts as Unrecoverable. Table 22 still refers to this table as Table 7, a stale internal reference.", "related": [ "mastercard-decline:61", "mastercard-decline:65", "mastercard:refund", "mastercard:limits", "mastercard:messages" ], "basis": { "sources": "Transaction Processing Rules, 9 June 2026 edition, sections 3.3.1, 2.7.1, 4.5.4, 4.5.5 Tables 22 and 23, Asia/Pacific Region 4.5.5 Table 24, 2.2.3, 2.13.2, Europe Region 2.7.1, Signage, Screen and Receipt Text Standards (p. 355). Label and category read from Table 23 on pp. 163 to 164, with each entry's column fixed from its position on the page; placed Temporarily Recoverable in Table 24 (pp. 175 to 176). Read from a copy downloaded from Mastercard's public rules page on 2026-09-19. Nothing is quoted. Medium: the label, category and retry rules follow from the cited sections, but what makes an issuer send this code is inferred from the label, and the defining specifications are not public to Orca.", "confidence": "medium" }, "currency": { "effective_since": "Before the current edition; start not stated in it", "effective_note": "Label and category as in the 9 June 2026 edition of the Transaction Processing Rules, whose summary of changes says it updated the Table 23 categories and removed past effective dates, so neither when this code's category began nor what it was before is shown. No dated change to this code was found in the edition. Mastercard reissues the manual on no fixed calendar [Inference].", "source_edition": "Transaction Processing Rules, 9 June 2026 edition (https://www.mastercard.com/content/dam/mccom/shared/business/support/rules-pdfs/transaction-processing-rules.pdf)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.mastercard.com/content/dam/mccom/shared/business/support/rules-pdfs/transaction-processing-rules.pdf", "source_class": "authoritative_primary", "source_title": "Transaction Processing Rules, 9 June 2026 edition", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms Mastercard's label for response value 51 and its Table 23 decline value category (Recoverable) in Transaction Processing Rules 4.5.5, read by column position on pages 163 to 165, and the Table 24 Australia category on pages 175 to 176; also confirms the merchant-initiated retry framework in rules 3.3.1 and 2.7.1 (the 04, 14, 15, 41, 43 and 54 no-retry bar, the Merchant Advice Code scenarios, and the 24 hour, 13 day deferred card-present resubmission window) and confirms this code is invalid as an issuer answer to a refund authorization, the 10 percent ATM denial cap for credit card issuers, and the deferred card-present retry allowance." } ] }, "rail_name": "Mastercard Decline Response Codes (partial)", "governing_authority": "Mastercard", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "mastercard-decline:54", "id": "54", "rail": "mastercard-decline", "kind": "reason-code", "name": "Expired card", "group": "account", "summary": "Decline because the card has expired. A card-not-present merchant may never retry the same transaction with that card number and expiry date, and a transit merchant bears the whole loss.", "triggers": [ "The expiry date has passed, or does not match the issuer's record [Inference from Mastercard's label; the defining text is in technical specifications not public to Orca]" ], "actions": [ "Merchant (card-not-present): stop; send no further authorization request for this transaction with this PAN and expiry date (TPR 3.3.1, pp. 123 to 124).", "Merchant (deferred card-present, not transit): do not resubmit (TPR 2.7.1, p. 54).", "Transit merchant: must refuse entry to expired cards at the gate, carries full liability for this decline, and may neither claim the debt nor send a debt recovery authorization (TPR 4.5.5, p. 165).", "Transit merchant: bears the debt; no first ride risk claim is allowed (TPR 4.5.5, pp. 163 to 165)." ], "retry": { "allowed": false, "rule": "No. After this code a merchant must never send another authorization request for the same card-not-present transaction with the same PAN and expiry date (TPR 3.3.1, pp. 123 to 124), and a declined deferred card-present authorization outside transit must not be resubmitted either (TPR 2.7.1, p. 54). The bar is tied to that PAN and expiry date; the rules read do not bar a request made with different card data [Inference from the wording of the bar]. Transit debt recovery and claims follow the transit table instead (TPR 4.5.5)." }, "facts": { "return_windows": [ { "action": "new authorization request for the same card-not-present transaction with the same PAN and expiry date", "by": "Merchant", "deadline": "Never (TPR 3.3.1)" }, { "action": "resubmit a declined deferred card-present authorization (not transit)", "by": "Merchant", "deadline": "Never (TPR 2.7.1)" }, { "action": "first ride risk claim after a declined contactless transit aggregated transaction", "by": "Transit acquirer", "deadline": "Never: Not Claimable (TPR 4.5.5, Table 23)" } ], "applies_to": "All Mastercard regions for Mastercard, Maestro and Cirrus transactions on Mastercard's network; in the EEA, the UK and Gibraltar many of these rules refer to the registered switch the customer chooses; transit categories differ in Australia (TPR Table 24)" }, "caveat": "The transit categories come from the First Ride Risk framework: they cover contactless transit aggregated transactions sent through the Dual Message System by a transit merchant in a country that has adopted the framework, in general only for cards issued in that country, and they are not a general retry rule (TPR 4.5.5, p. 162). Any valid response code missing from Table 23 counts as Unrecoverable. Table 22 still refers to this table as Table 7, a stale internal reference.", "related": [ "mastercard-decline:14", "mastercard-decline:15", "mastercard:liability", "mastercard:messages" ], "basis": { "sources": "Transaction Processing Rules, 9 June 2026 edition, sections 3.3.1, 2.7.1, 4.5.4, 4.5.5 Tables 22 and 23, Asia/Pacific Region 4.5.5 Table 24. Label and category read from Table 23 on pp. 163 to 164, with each entry's column fixed from its position on the page; placed Not Claimable in Table 24 (pp. 175 to 176). Read from a copy downloaded from Mastercard's public rules page on 2026-09-19. Nothing is quoted. Medium: the label, category and retry rules follow from the cited sections, but what makes an issuer send this code is inferred from the label, and the defining specifications are not public to Orca.", "confidence": "medium" }, "currency": { "effective_since": "Before the current edition; start not stated in it", "effective_note": "Label and category as in the 9 June 2026 edition of the Transaction Processing Rules, whose summary of changes says it updated the Table 23 categories and removed past effective dates, so neither when this code's category began nor what it was before is shown. No dated change to this code was found in the edition. Mastercard reissues the manual on no fixed calendar [Inference].", "source_edition": "Transaction Processing Rules, 9 June 2026 edition (https://www.mastercard.com/content/dam/mccom/shared/business/support/rules-pdfs/transaction-processing-rules.pdf)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.mastercard.com/content/dam/mccom/shared/business/support/rules-pdfs/transaction-processing-rules.pdf", "source_class": "authoritative_primary", "source_title": "Transaction Processing Rules, 9 June 2026 edition", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms Mastercard's label for response value 54 and its Table 23 decline value category (Not Claimable) in Transaction Processing Rules 4.5.5, read by column position on pages 163 to 165, and the Table 24 Australia category on pages 175 to 176; also confirms the merchant-initiated retry framework in rules 3.3.1 and 2.7.1 (the 04, 14, 15, 41, 43 and 54 no-retry bar, the Merchant Advice Code scenarios, and the 24 hour, 13 day deferred card-present resubmission window) and confirms the bar on any further card-not-present or deferred card-present retry, and full transit merchant liability." } ] }, "rail_name": "Mastercard Decline Response Codes (partial)", "governing_authority": "Mastercard", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "mastercard-decline:55", "id": "55", "rail": "mastercard-decline", "kind": "reason-code", "name": "Invalid PIN", "group": "authorization", "summary": "Decline because the PIN entered was wrong.", "triggers": [ "The PIN entered does not match the one on record [Inference from Mastercard's label; the defining text is in technical specifications not public to Orca]" ], "actions": [ "Merchant (merchant-initiated retries): decide whether and when to retry from this code and the Merchant Advice Code together (TPR 3.3.1, p. 124).", "Issuer of Mastercard credit cards: denials for invalid PIN may not exceed 13 percent of its ATM transactions (TPR 2.2.3, p. 48).", "ATM: Mastercard's recommended screen text for an invalid PIN offers the cardholder another try (TPR Signage, Screen and Receipt Text Standards, p. 355) [Inference: the table names responses by wording, not by code].", "Transit merchant: pursue the debt with debt recovery authorizations, each no larger than the contactless transit aggregated CVM limit (TPR 4.5.4 and 4.5.5, pp. 161 to 164)." ], "retry": { "allowed": true, "rule": "No blanket bar in the rules read. A card-not-present merchant that retries a merchant-initiated transaction must weigh this code together with the Merchant Advice Code: 01 means get updated account data first, 02 means wait 24 hours, 03 or 21 means stop (TPR 3.3.1, Table 20, p. 124). Which advice codes may accompany this code is set in the Dual and Single Message System specifications, which are not public to Orca. A declined cardholder-initiated transaction may not come back as a merchant-initiated one, a declined token cryptogram may not be sent again, and a retry must not alter merchant data: it carries the same merchant name, address, acceptor ID and POS condition values, with either the card data the cardholder first gave, a tokenized stored credential, or data updated through the cardholder or the Automatic Billing Updater (TPR 3.3.1, pp. 124 to 125). For a declined deferred card-present authorization outside transit, resubmission needs Merchant Advice Code 02 or another advice code giving a retry period, and a decline value that does not restrict retries; the rules read do not say whether this code restricts retries. Retries then run every 24 hours for up to 13 consecutive days (TPR 2.7.1, p. 54). Transit debt recovery follows the transit table category, not these rules (TPR 4.5.5)." }, "facts": { "return_windows": [ { "action": "resubmit a declined merchant-initiated authorization", "by": "Merchant", "deadline": "Set by the Merchant Advice Code on the decline: 01 update the account data first, 02 wait 24 hours, 03 or 21 never; with no advice code the rules read set no interval (TPR 3.3.1, Table 20)" }, { "action": "resubmit a declined deferred card-present authorization (not transit)", "by": "Merchant", "deadline": "Only when Merchant Advice Code 02 or another code giving a retry period came with the decline and this code does not restrict retries, which the rules read do not settle: no sooner than 24 hours after it, then at most once every 24 hours for up to 13 consecutive days (TPR 2.7.1)" }, { "action": "transit debt recovery after a declined contactless transit aggregated transaction", "by": "Transit merchant and its acquirer", "deadline": "Recoverable: pursue the debt with debt recovery authorizations; a first ride risk claim is allowed only after at least nine attempts, no more than one per 24 hours, over the 45 calendar days from the original decline with the last on day 45, each declined for a Recoverable or Temporarily Recoverable reason (TPR 4.5.5, Tables 22 and 23)" } ], "applies_to": "All Mastercard regions for Mastercard, Maestro and Cirrus transactions on Mastercard's network; in the EEA, the UK and Gibraltar many of these rules refer to the registered switch the customer chooses; transit categories differ in Australia (TPR Table 24)" }, "caveat": "The transit categories come from the First Ride Risk framework: they cover contactless transit aggregated transactions sent through the Dual Message System by a transit merchant in a country that has adopted the framework, in general only for cards issued in that country, and they are not a general retry rule (TPR 4.5.5, p. 162). Any valid response code missing from Table 23 counts as Unrecoverable. Table 22 still refers to this table as Table 7, a stale internal reference.", "related": [ "mastercard-decline:75", "mastercard-decline:86", "mastercard:limits", "mastercard:messages" ], "basis": { "sources": "Transaction Processing Rules, 9 June 2026 edition, sections 3.3.1, 2.7.1, 4.5.4, 4.5.5 Tables 22 and 23, Asia/Pacific Region 4.5.5 Table 24, 2.2.3, Signage, Screen and Receipt Text Standards (p. 355). Label and category read from Table 23 on pp. 163 to 164, with each entry's column fixed from its position on the page; placed Recoverable in Table 24 (pp. 175 to 176). Read from a copy downloaded from Mastercard's public rules page on 2026-09-19. Nothing is quoted. Medium: the label, category and retry rules follow from the cited sections, but what makes an issuer send this code is inferred from the label, and the defining specifications are not public to Orca.", "confidence": "medium" }, "currency": { "effective_since": "Before the current edition; start not stated in it", "effective_note": "Label and category as in the 9 June 2026 edition of the Transaction Processing Rules, whose summary of changes says it updated the Table 23 categories and removed past effective dates, so neither when this code's category began nor what it was before is shown. No dated change to this code was found in the edition. Mastercard reissues the manual on no fixed calendar [Inference].", "source_edition": "Transaction Processing Rules, 9 June 2026 edition (https://www.mastercard.com/content/dam/mccom/shared/business/support/rules-pdfs/transaction-processing-rules.pdf)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.mastercard.com/content/dam/mccom/shared/business/support/rules-pdfs/transaction-processing-rules.pdf", "source_class": "authoritative_primary", "source_title": "Transaction Processing Rules, 9 June 2026 edition", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms Mastercard's label for response value 55 and its Table 23 decline value category (Recoverable) in Transaction Processing Rules 4.5.5, read by column position on pages 163 to 165, and the Table 24 Australia category on pages 175 to 176; also confirms the merchant-initiated retry framework in rules 3.3.1 and 2.7.1 (the 04, 14, 15, 41, 43 and 54 no-retry bar, the Merchant Advice Code scenarios, and the 24 hour, 13 day deferred card-present resubmission window) and confirms the 13 percent ATM denial cap for credit card issuers." } ] }, "rail_name": "Mastercard Decline Response Codes (partial)", "governing_authority": "Mastercard", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "mastercard-decline:57", "id": "57", "rail": "mastercard-decline", "kind": "reason-code", "name": "Transaction not permitted to issuer/cardholder", "group": "administrative", "summary": "Decline because this cardholder or card is not allowed this kind of transaction. It is also the prescribed answer when an issuer does not support refund authorization, and an issuer may use it against a refund only on a non-reloadable prepaid card.", "triggers": [ "The card or cardholder is not set up for the transaction type requested [Inference from Mastercard's label; the defining text is in technical specifications not public to Orca]", "An issuer that does not support online refund authorization, allowed only for non-reloadable prepaid ranges, answers refund requests with 57 (TPR 2.2, p. 45)", "In transit, a card that does not support deferred authorization appears to be declined with 57 (TPR 4.5.5, p. 165) [Inference: the rule pairs expired cards with 54 and such cards with 57 without saying so outright]" ], "actions": [ "Merchant (merchant-initiated retries): decide whether and when to retry from this code and the Merchant Advice Code together (TPR 3.3.1, p. 124).", "Issuer: may answer a refund authorization with 57 only for a non-reloadable prepaid program, which Mastercard advises registering first (TPR 2.13.2, pp. 66 to 67).", "Issuer of Mastercard credit cards: denials for invalid transactions (57) may not exceed 14 percent of its ATM transactions (TPR 2.2.3, p. 48).", "Transit merchant: must refuse entry to cards that do not support deferred authorization, carries full liability for this decline, and may neither claim the debt nor send a debt recovery authorization (TPR 4.5.5, p. 165).", "Transit merchant: bears the debt; no first ride risk claim is allowed (TPR 4.5.5, pp. 163 to 165)." ], "retry": { "allowed": true, "rule": "No blanket bar in the rules read. A card-not-present merchant that retries a merchant-initiated transaction must weigh this code together with the Merchant Advice Code: 01 means get updated account data first, 02 means wait 24 hours, 03 or 21 means stop (TPR 3.3.1, Table 20, p. 124). Which advice codes may accompany this code is set in the Dual and Single Message System specifications, which are not public to Orca. A declined cardholder-initiated transaction may not come back as a merchant-initiated one, a declined token cryptogram may not be sent again, and a retry must not alter merchant data: it carries the same merchant name, address, acceptor ID and POS condition values, with either the card data the cardholder first gave, a tokenized stored credential, or data updated through the cardholder or the Automatic Billing Updater (TPR 3.3.1, pp. 124 to 125). For a declined deferred card-present authorization outside transit, resubmission needs Merchant Advice Code 02 or another advice code giving a retry period, and a decline value that does not restrict retries; the rules read do not say whether this code restricts retries. Retries then run every 24 hours for up to 13 consecutive days (TPR 2.7.1, p. 54). Transit debt recovery follows the transit table category, not these rules (TPR 4.5.5)." }, "facts": { "return_windows": [ { "action": "resubmit a declined merchant-initiated authorization", "by": "Merchant", "deadline": "Set by the Merchant Advice Code on the decline: 01 update the account data first, 02 wait 24 hours, 03 or 21 never; with no advice code the rules read set no interval (TPR 3.3.1, Table 20)" }, { "action": "resubmit a declined deferred card-present authorization (not transit)", "by": "Merchant", "deadline": "Only when Merchant Advice Code 02 or another code giving a retry period came with the decline and this code does not restrict retries, which the rules read do not settle: no sooner than 24 hours after it, then at most once every 24 hours for up to 13 consecutive days (TPR 2.7.1)" }, { "action": "answer a refund authorization request with this code", "by": "Issuer", "deadline": "Only for a non-reloadable prepaid card program (TPR 2.13.2)" }, { "action": "first ride risk claim after a declined contactless transit aggregated transaction", "by": "Transit acquirer", "deadline": "Never: Not Claimable (TPR 4.5.5, Table 23)" }, { "action": "transit debt recovery or first ride risk claim, Australia", "by": "Transit merchant and its acquirer (Australia)", "deadline": "Table 24 places this code in Recoverable (recover first; claim only after nine failed attempts over 45 days), not the global category (TPR Asia/Pacific Region 4.5.5, pp. 175 to 176)" } ], "applies_to": "All Mastercard regions for Mastercard, Maestro and Cirrus transactions on Mastercard's network; in the EEA, the UK and Gibraltar many of these rules refer to the registered switch the customer chooses; transit categories differ in Australia (TPR Table 24)" }, "caveat": "China domestic: an issuer that does not offer a transaction type must answer with 57 (TPR Asia/Pacific Region 2.2.1, p. 77). The transit categories come from the First Ride Risk framework: they cover contactless transit aggregated transactions sent through the Dual Message System by a transit merchant in a country that has adopted the framework, in general only for cards issued in that country, and they are not a general retry rule (TPR 4.5.5, p. 162). Any valid response code missing from Table 23 counts as Unrecoverable. Table 22 still refers to this table as Table 7, a stale internal reference.", "related": [ "mastercard-decline:12", "mastercard-decline:58", "mastercard:refund", "mastercard:limits", "mastercard:messages" ], "basis": { "sources": "Transaction Processing Rules, 9 June 2026 edition, sections 3.3.1, 2.7.1, 4.5.4, 4.5.5 Tables 22 and 23, Asia/Pacific Region 4.5.5 Table 24, 2.2, 2.2.3, 2.13.2, Asia/Pacific Region 2.2.1. Label and category read from Table 23 on pp. 163 to 164, with each entry's column fixed from its position on the page; placed Recoverable in Table 24 (pp. 175 to 176). Read from a copy downloaded from Mastercard's public rules page on 2026-09-19. Nothing is quoted. Medium: the label, category and retry rules follow from the cited sections, but what makes an issuer send this code is inferred from the label, and the defining specifications are not public to Orca.", "confidence": "medium" }, "currency": { "effective_since": "Before the current edition; start not stated in it", "effective_note": "Label and category as in the 9 June 2026 edition of the Transaction Processing Rules, whose summary of changes says it updated the Table 23 categories and removed past effective dates, so neither when this code's category began nor what it was before is shown. No dated change to this code was found in the edition. Mastercard reissues the manual on no fixed calendar [Inference].", "source_edition": "Transaction Processing Rules, 9 June 2026 edition (https://www.mastercard.com/content/dam/mccom/shared/business/support/rules-pdfs/transaction-processing-rules.pdf)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.mastercard.com/content/dam/mccom/shared/business/support/rules-pdfs/transaction-processing-rules.pdf", "source_class": "authoritative_primary", "source_title": "Transaction Processing Rules, 9 June 2026 edition", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms Mastercard's label for response value 57 and its Table 23 decline value category (Not Claimable) in Transaction Processing Rules 4.5.5, read by column position on pages 163 to 165, and the Table 24 Australia category on pages 175 to 176; also confirms the merchant-initiated retry framework in rules 3.3.1 and 2.7.1 (the 04, 14, 15, 41, 43 and 54 no-retry bar, the Merchant Advice Code scenarios, and the 24 hour, 13 day deferred card-present resubmission window) and confirms this code is allowed as a refund answer only for a non-reloadable prepaid program, the 14 percent ATM denial cap for credit card issuers, and the China domestic no-transaction-type-offered answer." } ] }, "rail_name": "Mastercard Decline Response Codes (partial)", "governing_authority": "Mastercard", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "mastercard-decline:58", "id": "58", "rail": "mastercard-decline", "kind": "reason-code", "name": "Transaction not permitted to acquirer/terminal", "group": "administrative", "summary": "Decline because the transaction is not allowed for this acquirer or terminal, as opposed to this card.", "triggers": [ "The acquirer or terminal is not permitted to send this transaction [Inference from Mastercard's label; the defining text is in technical specifications not public to Orca]" ], "actions": [ "Merchant (merchant-initiated retries): decide whether and when to retry from this code and the Merchant Advice Code together (TPR 3.3.1, p. 124).", "Transit acquirer: may claim the first ride debt at once with a First Presentment/1240 carrying no approval, up to the country's first ride risk limit (TPR 4.5.5, pp. 163 to 165)." ], "retry": { "allowed": true, "rule": "No blanket bar in the rules read. A card-not-present merchant that retries a merchant-initiated transaction must weigh this code together with the Merchant Advice Code: 01 means get updated account data first, 02 means wait 24 hours, 03 or 21 means stop (TPR 3.3.1, Table 20, p. 124). Which advice codes may accompany this code is set in the Dual and Single Message System specifications, which are not public to Orca. A declined cardholder-initiated transaction may not come back as a merchant-initiated one, a declined token cryptogram may not be sent again, and a retry must not alter merchant data: it carries the same merchant name, address, acceptor ID and POS condition values, with either the card data the cardholder first gave, a tokenized stored credential, or data updated through the cardholder or the Automatic Billing Updater (TPR 3.3.1, pp. 124 to 125). For a declined deferred card-present authorization outside transit, resubmission needs Merchant Advice Code 02 or another advice code giving a retry period, and a decline value that does not restrict retries; the rules read do not say whether this code restricts retries. Retries then run every 24 hours for up to 13 consecutive days (TPR 2.7.1, p. 54). Transit debt recovery follows the transit table category, not these rules (TPR 4.5.5)." }, "facts": { "return_windows": [ { "action": "resubmit a declined merchant-initiated authorization", "by": "Merchant", "deadline": "Set by the Merchant Advice Code on the decline: 01 update the account data first, 02 wait 24 hours, 03 or 21 never; with no advice code the rules read set no interval (TPR 3.3.1, Table 20)" }, { "action": "resubmit a declined deferred card-present authorization (not transit)", "by": "Merchant", "deadline": "Only when Merchant Advice Code 02 or another code giving a retry period came with the decline and this code does not restrict retries, which the rules read do not settle: no sooner than 24 hours after it, then at most once every 24 hours for up to 13 consecutive days (TPR 2.7.1)" }, { "action": "first ride risk claim after a declined contactless transit aggregated transaction", "by": "Transit acquirer", "deadline": "Unrecoverable: may be sent at once, as a First Presentment/1240 with no approval, for no more than the first ride risk limit of the merchant's country (TPR 4.5.5, Tables 22 and 23)" } ], "applies_to": "All Mastercard regions for Mastercard, Maestro and Cirrus transactions on Mastercard's network; in the EEA, the UK and Gibraltar many of these rules refer to the registered switch the customer chooses; transit categories differ in Australia (TPR Table 24)" }, "caveat": "The transit categories come from the First Ride Risk framework: they cover contactless transit aggregated transactions sent through the Dual Message System by a transit merchant in a country that has adopted the framework, in general only for cards issued in that country, and they are not a general retry rule (TPR 4.5.5, p. 162). Any valid response code missing from Table 23 counts as Unrecoverable. Table 22 still refers to this table as Table 7, a stale internal reference.", "related": [ "mastercard-decline:57", "mastercard-decline:03", "mastercard:messages" ], "basis": { "sources": "Transaction Processing Rules, 9 June 2026 edition, sections 3.3.1, 2.7.1, 4.5.4, 4.5.5 Tables 22 and 23, Asia/Pacific Region 4.5.5 Table 24. Label and category read from Table 23 on pp. 163 to 164, with each entry's column fixed from its position on the page; placed Unrecoverable in Table 24 (pp. 175 to 176). Read from a copy downloaded from Mastercard's public rules page on 2026-09-19. Nothing is quoted. Medium: the label, category and retry rules follow from the cited sections, but what makes an issuer send this code is inferred from the label, and the defining specifications are not public to Orca.", "confidence": "medium" }, "currency": { "effective_since": "Before the current edition; start not stated in it", "effective_note": "Label and category as in the 9 June 2026 edition of the Transaction Processing Rules, whose summary of changes says it updated the Table 23 categories and removed past effective dates, so neither when this code's category began nor what it was before is shown. No dated change to this code was found in the edition. Mastercard reissues the manual on no fixed calendar [Inference].", "source_edition": "Transaction Processing Rules, 9 June 2026 edition (https://www.mastercard.com/content/dam/mccom/shared/business/support/rules-pdfs/transaction-processing-rules.pdf)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.mastercard.com/content/dam/mccom/shared/business/support/rules-pdfs/transaction-processing-rules.pdf", "source_class": "authoritative_primary", "source_title": "Transaction Processing Rules, 9 June 2026 edition", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms Mastercard's label for response value 58 and its Table 23 decline value category (Unrecoverable) in Transaction Processing Rules 4.5.5, read by column position on pages 163 to 165, and the Table 24 Australia category on pages 175 to 176; also confirms the merchant-initiated retry framework in rules 3.3.1 and 2.7.1 (the 04, 14, 15, 41, 43 and 54 no-retry bar, the Merchant Advice Code scenarios, and the 24 hour, 13 day deferred card-present resubmission window)." } ] }, "rail_name": "Mastercard Decline Response Codes (partial)", "governing_authority": "Mastercard", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "mastercard-decline:61", "id": "61", "rail": "mastercard-decline", "kind": "reason-code", "name": "Exceeds withdrawal amount limit", "group": "funds", "summary": "Decline because the amount would take the cardholder past a withdrawal or spending amount limit. The rules treat it as retryable within limits.", "triggers": [ "The amount exceeds a limit the issuer applies to the card [Inference from Mastercard's label; the defining text is in technical specifications not public to Orca]" ], "actions": [ "Merchant (merchant-initiated retries): decide whether and when to retry from this code and the Merchant Advice Code together (TPR 3.3.1, p. 124).", "Issuer of Mastercard credit cards: denials for exceeding a limit may not exceed 9 percent of its ATM transactions, and it must allow at least the equivalent of USD 200 a day in withdrawals when credit is available (TPR 2.2.3, p. 48).", "Transit merchant: pursue the debt with debt recovery authorizations, each no larger than the contactless transit aggregated CVM limit (TPR 4.5.4 and 4.5.5, pp. 161 to 164)." ], "retry": { "allowed": true, "rule": "No blanket bar in the rules read. A card-not-present merchant that retries a merchant-initiated transaction must weigh this code together with the Merchant Advice Code: 01 means get updated account data first, 02 means wait 24 hours, 03 or 21 means stop (TPR 3.3.1, Table 20, p. 124). Which advice codes may accompany this code is set in the Dual and Single Message System specifications, which are not public to Orca. A declined cardholder-initiated transaction may not come back as a merchant-initiated one, a declined token cryptogram may not be sent again, and a retry must not alter merchant data: it carries the same merchant name, address, acceptor ID and POS condition values, with either the card data the cardholder first gave, a tokenized stored credential, or data updated through the cardholder or the Automatic Billing Updater (TPR 3.3.1, pp. 124 to 125). For a declined deferred card-present authorization outside transit, the rules name this code as one that allows resubmission when Merchant Advice Code 02, or another advice code giving a retry period, came with it: first after at least 24 hours, then every 24 hours for up to 13 consecutive days (TPR 2.7.1, p. 54). Transit debt recovery follows the transit table category, not these rules (TPR 4.5.5)." }, "facts": { "return_windows": [ { "action": "resubmit a declined merchant-initiated authorization", "by": "Merchant", "deadline": "Set by the Merchant Advice Code on the decline: 01 update the account data first, 02 wait 24 hours, 03 or 21 never; with no advice code the rules read set no interval (TPR 3.3.1, Table 20)" }, { "action": "resubmit a declined deferred card-present authorization (not transit)", "by": "Merchant", "deadline": "Only when Merchant Advice Code 02 or another code giving a retry period came with the decline: no sooner than 24 hours after it, then at most once every 24 hours for up to 13 consecutive days (TPR 2.7.1)" }, { "action": "resubmit a declined deferred Maestro authorization, Belgium domestic", "by": "Acquirer (Belgium)", "deadline": "Once every 24 hours until 30 calendar days after the transaction date (TPR Europe Region 2.7.1, p. 92)" }, { "action": "transit debt recovery after a declined contactless transit aggregated transaction", "by": "Transit merchant and its acquirer", "deadline": "Recoverable: pursue the debt with debt recovery authorizations; a first ride risk claim is allowed only after at least nine attempts, no more than one per 24 hours, over the 45 calendar days from the original decline with the last on day 45, each declined for a Recoverable or Temporarily Recoverable reason (TPR 4.5.5, Tables 22 and 23)" } ], "applies_to": "All Mastercard regions for Mastercard, Maestro and Cirrus transactions on Mastercard's network; in the EEA, the UK and Gibraltar many of these rules refer to the registered switch the customer chooses; transit categories differ in Australia (TPR Table 24)" }, "caveat": "The transit categories come from the First Ride Risk framework: they cover contactless transit aggregated transactions sent through the Dual Message System by a transit merchant in a country that has adopted the framework, in general only for cards issued in that country, and they are not a general retry rule (TPR 4.5.5, p. 162). Any valid response code missing from Table 23 counts as Unrecoverable. Table 22 still refers to this table as Table 7, a stale internal reference.", "related": [ "mastercard-decline:51", "mastercard-decline:65", "mastercard:limits", "mastercard:messages" ], "basis": { "sources": "Transaction Processing Rules, 9 June 2026 edition, sections 3.3.1, 2.7.1, 4.5.4, 4.5.5 Tables 22 and 23, Asia/Pacific Region 4.5.5 Table 24, 2.2.3, Europe Region 2.7.1. Label and category read from Table 23 on pp. 163 to 164, with each entry's column fixed from its position on the page; placed Recoverable in Table 24 (pp. 175 to 176). Read from a copy downloaded from Mastercard's public rules page on 2026-09-19. Nothing is quoted. Medium: the label, category and retry rules follow from the cited sections, but what makes an issuer send this code is inferred from the label, and the defining specifications are not public to Orca.", "confidence": "medium" }, "currency": { "effective_since": "Before the current edition; start not stated in it", "effective_note": "Label and category as in the 9 June 2026 edition of the Transaction Processing Rules, whose summary of changes says it updated the Table 23 categories and removed past effective dates, so neither when this code's category began nor what it was before is shown. No dated change to this code was found in the edition. Mastercard reissues the manual on no fixed calendar [Inference].", "source_edition": "Transaction Processing Rules, 9 June 2026 edition (https://www.mastercard.com/content/dam/mccom/shared/business/support/rules-pdfs/transaction-processing-rules.pdf)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.mastercard.com/content/dam/mccom/shared/business/support/rules-pdfs/transaction-processing-rules.pdf", "source_class": "authoritative_primary", "source_title": "Transaction Processing Rules, 9 June 2026 edition", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms Mastercard's label for response value 61 and its Table 23 decline value category (Recoverable) in Transaction Processing Rules 4.5.5, read by column position on pages 163 to 165, and the Table 24 Australia category on pages 175 to 176; also confirms the merchant-initiated retry framework in rules 3.3.1 and 2.7.1 (the 04, 14, 15, 41, 43 and 54 no-retry bar, the Merchant Advice Code scenarios, and the 24 hour, 13 day deferred card-present resubmission window) and confirms the 9 percent ATM denial cap for credit card issuers and the deferred card-present retry allowance." } ] }, "rail_name": "Mastercard Decline Response Codes (partial)", "governing_authority": "Mastercard", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "mastercard-decline:62", "id": "62", "rail": "mastercard-decline", "kind": "reason-code", "name": "Restricted card", "group": "account", "summary": "Decline because the card carries a restriction that blocks this use.", "triggers": [ "The issuer has restricted the card in a way that covers this transaction [Inference from Mastercard's label; the defining text is in technical specifications not public to Orca]" ], "actions": [ "Merchant (merchant-initiated retries): decide whether and when to retry from this code and the Merchant Advice Code together (TPR 3.3.1, p. 124).", "Issuer of Mastercard credit cards: restricted-card denials may not exceed 4 percent of its ATM transactions (TPR 2.2.3, p. 48).", "Transit acquirer: may claim the first ride debt at once with a First Presentment/1240 carrying no approval, up to the country's first ride risk limit (TPR 4.5.5, pp. 163 to 165)." ], "retry": { "allowed": true, "rule": "No blanket bar in the rules read. A card-not-present merchant that retries a merchant-initiated transaction must weigh this code together with the Merchant Advice Code: 01 means get updated account data first, 02 means wait 24 hours, 03 or 21 means stop (TPR 3.3.1, Table 20, p. 124). Which advice codes may accompany this code is set in the Dual and Single Message System specifications, which are not public to Orca. A declined cardholder-initiated transaction may not come back as a merchant-initiated one, a declined token cryptogram may not be sent again, and a retry must not alter merchant data: it carries the same merchant name, address, acceptor ID and POS condition values, with either the card data the cardholder first gave, a tokenized stored credential, or data updated through the cardholder or the Automatic Billing Updater (TPR 3.3.1, pp. 124 to 125). For a declined deferred card-present authorization outside transit, resubmission needs Merchant Advice Code 02 or another advice code giving a retry period, and a decline value that does not restrict retries; the rules read do not say whether this code restricts retries. Retries then run every 24 hours for up to 13 consecutive days (TPR 2.7.1, p. 54). Transit debt recovery follows the transit table category, not these rules (TPR 4.5.5)." }, "facts": { "return_windows": [ { "action": "resubmit a declined merchant-initiated authorization", "by": "Merchant", "deadline": "Set by the Merchant Advice Code on the decline: 01 update the account data first, 02 wait 24 hours, 03 or 21 never; with no advice code the rules read set no interval (TPR 3.3.1, Table 20)" }, { "action": "resubmit a declined deferred card-present authorization (not transit)", "by": "Merchant", "deadline": "Only when Merchant Advice Code 02 or another code giving a retry period came with the decline and this code does not restrict retries, which the rules read do not settle: no sooner than 24 hours after it, then at most once every 24 hours for up to 13 consecutive days (TPR 2.7.1)" }, { "action": "first ride risk claim after a declined contactless transit aggregated transaction", "by": "Transit acquirer", "deadline": "Unrecoverable: may be sent at once, as a First Presentment/1240 with no approval, for no more than the first ride risk limit of the merchant's country (TPR 4.5.5, Tables 22 and 23)" }, { "action": "transit debt recovery or first ride risk claim, Australia", "by": "Transit merchant and its acquirer (Australia)", "deadline": "Table 24 places this code in Recoverable (recover first; claim only after nine failed attempts over 45 days), not the global category (TPR Asia/Pacific Region 4.5.5, pp. 175 to 176)" } ], "applies_to": "All Mastercard regions for Mastercard, Maestro and Cirrus transactions on Mastercard's network; in the EEA, the UK and Gibraltar many of these rules refer to the registered switch the customer chooses; transit categories differ in Australia (TPR Table 24)" }, "caveat": "The transit categories come from the First Ride Risk framework: they cover contactless transit aggregated transactions sent through the Dual Message System by a transit merchant in a country that has adopted the framework, in general only for cards issued in that country, and they are not a general retry rule (TPR 4.5.5, p. 162). Any valid response code missing from Table 23 counts as Unrecoverable. Table 22 still refers to this table as Table 7, a stale internal reference.", "related": [ "mastercard:limits", "mastercard:messages", "mastercard-decline:57" ], "basis": { "sources": "Transaction Processing Rules, 9 June 2026 edition, sections 3.3.1, 2.7.1, 4.5.4, 4.5.5 Tables 22 and 23, Asia/Pacific Region 4.5.5 Table 24, 2.2.3. Label and category read from Table 23 on pp. 163 to 164, with each entry's column fixed from its position on the page; placed Recoverable in Table 24 (pp. 175 to 176). Read from a copy downloaded from Mastercard's public rules page on 2026-09-19. Nothing is quoted. Medium: the label, category and retry rules follow from the cited sections, but what makes an issuer send this code is inferred from the label, and the defining specifications are not public to Orca.", "confidence": "medium" }, "currency": { "effective_since": "Before the current edition; start not stated in it", "effective_note": "Label and category as in the 9 June 2026 edition of the Transaction Processing Rules, whose summary of changes says it updated the Table 23 categories and removed past effective dates, so neither when this code's category began nor what it was before is shown. No dated change to this code was found in the edition. Mastercard reissues the manual on no fixed calendar [Inference].", "source_edition": "Transaction Processing Rules, 9 June 2026 edition (https://www.mastercard.com/content/dam/mccom/shared/business/support/rules-pdfs/transaction-processing-rules.pdf)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.mastercard.com/content/dam/mccom/shared/business/support/rules-pdfs/transaction-processing-rules.pdf", "source_class": "authoritative_primary", "source_title": "Transaction Processing Rules, 9 June 2026 edition", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms Mastercard's label for response value 62 and its Table 23 decline value category (Recoverable) in Transaction Processing Rules 4.5.5, read by column position on pages 163 to 165, and the Table 24 Australia category on pages 175 to 176; also confirms the merchant-initiated retry framework in rules 3.3.1 and 2.7.1 (the 04, 14, 15, 41, 43 and 54 no-retry bar, the Merchant Advice Code scenarios, and the 24 hour, 13 day deferred card-present resubmission window) and confirms the 4 percent ATM denial cap for credit card issuers." } ] }, "rail_name": "Mastercard Decline Response Codes (partial)", "governing_authority": "Mastercard", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "mastercard-decline:63", "id": "63", "rail": "mastercard-decline", "kind": "reason-code", "name": "Security violation", "group": "authorization", "summary": "Decline because the issuer detected a security problem with the request.", "triggers": [ "A security check on the request failed [Inference from Mastercard's label; the defining text is in technical specifications not public to Orca]" ], "actions": [ "Merchant (merchant-initiated retries): decide whether and when to retry from this code and the Merchant Advice Code together (TPR 3.3.1, p. 124).", "Transit acquirer: may claim the first ride debt at once with a First Presentment/1240 carrying no approval, up to the country's first ride risk limit (TPR 4.5.5, pp. 163 to 165)." ], "retry": { "allowed": true, "rule": "No blanket bar in the rules read. A card-not-present merchant that retries a merchant-initiated transaction must weigh this code together with the Merchant Advice Code: 01 means get updated account data first, 02 means wait 24 hours, 03 or 21 means stop (TPR 3.3.1, Table 20, p. 124). Which advice codes may accompany this code is set in the Dual and Single Message System specifications, which are not public to Orca. A declined cardholder-initiated transaction may not come back as a merchant-initiated one, a declined token cryptogram may not be sent again, and a retry must not alter merchant data: it carries the same merchant name, address, acceptor ID and POS condition values, with either the card data the cardholder first gave, a tokenized stored credential, or data updated through the cardholder or the Automatic Billing Updater (TPR 3.3.1, pp. 124 to 125). For a declined deferred card-present authorization outside transit, resubmission needs Merchant Advice Code 02 or another advice code giving a retry period, and a decline value that does not restrict retries; the rules read do not say whether this code restricts retries. Retries then run every 24 hours for up to 13 consecutive days (TPR 2.7.1, p. 54). Transit debt recovery follows the transit table category, not these rules (TPR 4.5.5)." }, "facts": { "return_windows": [ { "action": "resubmit a declined merchant-initiated authorization", "by": "Merchant", "deadline": "Set by the Merchant Advice Code on the decline: 01 update the account data first, 02 wait 24 hours, 03 or 21 never; with no advice code the rules read set no interval (TPR 3.3.1, Table 20)" }, { "action": "resubmit a declined deferred card-present authorization (not transit)", "by": "Merchant", "deadline": "Only when Merchant Advice Code 02 or another code giving a retry period came with the decline and this code does not restrict retries, which the rules read do not settle: no sooner than 24 hours after it, then at most once every 24 hours for up to 13 consecutive days (TPR 2.7.1)" }, { "action": "first ride risk claim after a declined contactless transit aggregated transaction", "by": "Transit acquirer", "deadline": "Unrecoverable: may be sent at once, as a First Presentment/1240 with no approval, for no more than the first ride risk limit of the merchant's country (TPR 4.5.5, Tables 22 and 23)" }, { "action": "transit debt recovery or first ride risk claim, Australia", "by": "Transit merchant and its acquirer (Australia)", "deadline": "Table 24 places this code in Recoverable (recover first; claim only after nine failed attempts over 45 days), not the global category (TPR Asia/Pacific Region 4.5.5, pp. 175 to 176)" } ], "applies_to": "All Mastercard regions for Mastercard, Maestro and Cirrus transactions on Mastercard's network; in the EEA, the UK and Gibraltar many of these rules refer to the registered switch the customer chooses; transit categories differ in Australia (TPR Table 24)" }, "caveat": "The transit categories come from the First Ride Risk framework: they cover contactless transit aggregated transactions sent through the Dual Message System by a transit merchant in a country that has adopted the framework, in general only for cards issued in that country, and they are not a general retry rule (TPR 4.5.5, p. 162). Any valid response code missing from Table 23 counts as Unrecoverable. Table 22 still refers to this table as Table 7, a stale internal reference.", "related": [ "mastercard-decline:83", "mastercard-decline:88", "mastercard:messages" ], "basis": { "sources": "Transaction Processing Rules, 9 June 2026 edition, sections 3.3.1, 2.7.1, 4.5.4, 4.5.5 Tables 22 and 23, Asia/Pacific Region 4.5.5 Table 24. Label and category read from Table 23 on pp. 163 to 164, with each entry's column fixed from its position on the page; placed Recoverable in Table 24 (pp. 175 to 176). Read from a copy downloaded from Mastercard's public rules page on 2026-09-19. Nothing is quoted. Medium: the label, category and retry rules follow from the cited sections, but what makes an issuer send this code is inferred from the label, and the defining specifications are not public to Orca.", "confidence": "medium" }, "currency": { "effective_since": "Before the current edition; start not stated in it", "effective_note": "Label and category as in the 9 June 2026 edition of the Transaction Processing Rules, whose summary of changes says it updated the Table 23 categories and removed past effective dates, so neither when this code's category began nor what it was before is shown. No dated change to this code was found in the edition. Mastercard reissues the manual on no fixed calendar [Inference].", "source_edition": "Transaction Processing Rules, 9 June 2026 edition (https://www.mastercard.com/content/dam/mccom/shared/business/support/rules-pdfs/transaction-processing-rules.pdf)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.mastercard.com/content/dam/mccom/shared/business/support/rules-pdfs/transaction-processing-rules.pdf", "source_class": "authoritative_primary", "source_title": "Transaction Processing Rules, 9 June 2026 edition", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms Mastercard's label for response value 63 and its Table 23 decline value category (Unrecoverable) in Transaction Processing Rules 4.5.5, read by column position on pages 163 to 165, and the Table 24 Australia category on pages 175 to 176; also confirms the merchant-initiated retry framework in rules 3.3.1 and 2.7.1 (the 04, 14, 15, 41, 43 and 54 no-retry bar, the Merchant Advice Code scenarios, and the 24 hour, 13 day deferred card-present resubmission window)." } ] }, "rail_name": "Mastercard Decline Response Codes (partial)", "governing_authority": "Mastercard", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "mastercard-decline:65", "id": "65", "rail": "mastercard-decline", "kind": "reason-code", "name": "Exceeds withdrawal count limit", "group": "funds", "summary": "Decline because the cardholder has used up the number of withdrawals or transactions allowed in a period. The rules treat it as retryable within limits.", "triggers": [ "The number of transactions allowed in the issuer's period has been reached [Inference from Mastercard's label; the defining text is in technical specifications not public to Orca]" ], "actions": [ "Merchant (merchant-initiated retries): decide whether and when to retry from this code and the Merchant Advice Code together (TPR 3.3.1, p. 124).", "Transit merchant: pursue the debt with debt recovery authorizations, each no larger than the contactless transit aggregated CVM limit (TPR 4.5.4 and 4.5.5, pp. 161 to 164)." ], "retry": { "allowed": true, "rule": "No blanket bar in the rules read. A card-not-present merchant that retries a merchant-initiated transaction must weigh this code together with the Merchant Advice Code: 01 means get updated account data first, 02 means wait 24 hours, 03 or 21 means stop (TPR 3.3.1, Table 20, p. 124). Which advice codes may accompany this code is set in the Dual and Single Message System specifications, which are not public to Orca. A declined cardholder-initiated transaction may not come back as a merchant-initiated one, a declined token cryptogram may not be sent again, and a retry must not alter merchant data: it carries the same merchant name, address, acceptor ID and POS condition values, with either the card data the cardholder first gave, a tokenized stored credential, or data updated through the cardholder or the Automatic Billing Updater (TPR 3.3.1, pp. 124 to 125). For a declined deferred card-present authorization outside transit, the rules name this code as one that allows resubmission when Merchant Advice Code 02, or another advice code giving a retry period, came with it: first after at least 24 hours, then every 24 hours for up to 13 consecutive days (TPR 2.7.1, p. 54). Transit debt recovery follows the transit table category, not these rules (TPR 4.5.5)." }, "facts": { "return_windows": [ { "action": "resubmit a declined merchant-initiated authorization", "by": "Merchant", "deadline": "Set by the Merchant Advice Code on the decline: 01 update the account data first, 02 wait 24 hours, 03 or 21 never; with no advice code the rules read set no interval (TPR 3.3.1, Table 20)" }, { "action": "resubmit a declined deferred card-present authorization (not transit)", "by": "Merchant", "deadline": "Only when Merchant Advice Code 02 or another code giving a retry period came with the decline: no sooner than 24 hours after it, then at most once every 24 hours for up to 13 consecutive days (TPR 2.7.1)" }, { "action": "resubmit a declined deferred Maestro authorization, Belgium domestic", "by": "Acquirer (Belgium)", "deadline": "Once every 24 hours until 30 calendar days after the transaction date (TPR Europe Region 2.7.1, p. 92) [Inference: the Belgian rule speaks of exceeding withdrawal limits, read here as covering a count limit]" }, { "action": "transit debt recovery after a declined contactless transit aggregated transaction", "by": "Transit merchant and its acquirer", "deadline": "Recoverable: pursue the debt with debt recovery authorizations; a first ride risk claim is allowed only after at least nine attempts, no more than one per 24 hours, over the 45 calendar days from the original decline with the last on day 45, each declined for a Recoverable or Temporarily Recoverable reason (TPR 4.5.5, Tables 22 and 23)" } ], "applies_to": "All Mastercard regions for Mastercard, Maestro and Cirrus transactions on Mastercard's network; in the EEA, the UK and Gibraltar many of these rules refer to the registered switch the customer chooses; transit categories differ in Australia (TPR Table 24)" }, "caveat": "The transit categories come from the First Ride Risk framework: they cover contactless transit aggregated transactions sent through the Dual Message System by a transit merchant in a country that has adopted the framework, in general only for cards issued in that country, and they are not a general retry rule (TPR 4.5.5, p. 162). Any valid response code missing from Table 23 counts as Unrecoverable. Table 22 still refers to this table as Table 7, a stale internal reference.", "related": [ "mastercard-decline:51", "mastercard-decline:61", "mastercard:messages" ], "basis": { "sources": "Transaction Processing Rules, 9 June 2026 edition, sections 3.3.1, 2.7.1, 4.5.4, 4.5.5 Tables 22 and 23, Asia/Pacific Region 4.5.5 Table 24, Europe Region 2.7.1. Label and category read from Table 23 on pp. 163 to 164, with each entry's column fixed from its position on the page; placed Recoverable in Table 24 (pp. 175 to 176). Read from a copy downloaded from Mastercard's public rules page on 2026-09-19. Nothing is quoted. Medium: the label, category and retry rules follow from the cited sections, but what makes an issuer send this code is inferred from the label, and the defining specifications are not public to Orca.", "confidence": "medium" }, "currency": { "effective_since": "Before the current edition; start not stated in it", "effective_note": "Label and category as in the 9 June 2026 edition of the Transaction Processing Rules, whose summary of changes says it updated the Table 23 categories and removed past effective dates, so neither when this code's category began nor what it was before is shown. No dated change to this code was found in the edition. Mastercard reissues the manual on no fixed calendar [Inference].", "source_edition": "Transaction Processing Rules, 9 June 2026 edition (https://www.mastercard.com/content/dam/mccom/shared/business/support/rules-pdfs/transaction-processing-rules.pdf)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.mastercard.com/content/dam/mccom/shared/business/support/rules-pdfs/transaction-processing-rules.pdf", "source_class": "authoritative_primary", "source_title": "Transaction Processing Rules, 9 June 2026 edition", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms Mastercard's label for response value 65 and its Table 23 decline value category (Recoverable) in Transaction Processing Rules 4.5.5, read by column position on pages 163 to 165, and the Table 24 Australia category on pages 175 to 176; also confirms the merchant-initiated retry framework in rules 3.3.1 and 2.7.1 (the 04, 14, 15, 41, 43 and 54 no-retry bar, the Merchant Advice Code scenarios, and the 24 hour, 13 day deferred card-present resubmission window) and confirms the deferred card-present retry allowance." } ] }, "rail_name": "Mastercard Decline Response Codes (partial)", "governing_authority": "Mastercard", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "mastercard-decline:70", "id": "70", "rail": "mastercard-decline", "kind": "reason-code", "name": "Contact card issuer", "group": "authorization", "summary": "Decline asking the cardholder or merchant to contact the issuer. Mastercard treats it as a temporary problem the cardholder may be able to resolve.", "triggers": [ "The issuer needs contact before it will approve [Inference from Mastercard's label; the defining text is in technical specifications not public to Orca]" ], "actions": [ "Merchant (merchant-initiated retries): decide whether and when to retry from this code and the Merchant Advice Code together (TPR 3.3.1, p. 124).", "Transit merchant: make at least nine debt recovery attempts within 45 days; this is a situation the cardholder may be able to resolve with the issuer (TPR 4.5.5, p. 165)." ], "retry": { "allowed": true, "rule": "No blanket bar in the rules read. A card-not-present merchant that retries a merchant-initiated transaction must weigh this code together with the Merchant Advice Code: 01 means get updated account data first, 02 means wait 24 hours, 03 or 21 means stop (TPR 3.3.1, Table 20, p. 124). Which advice codes may accompany this code is set in the Dual and Single Message System specifications, which are not public to Orca. A declined cardholder-initiated transaction may not come back as a merchant-initiated one, a declined token cryptogram may not be sent again, and a retry must not alter merchant data: it carries the same merchant name, address, acceptor ID and POS condition values, with either the card data the cardholder first gave, a tokenized stored credential, or data updated through the cardholder or the Automatic Billing Updater (TPR 3.3.1, pp. 124 to 125). For a declined deferred card-present authorization outside transit, resubmission needs Merchant Advice Code 02 or another advice code giving a retry period, and a decline value that does not restrict retries; the rules read do not say whether this code restricts retries. Retries then run every 24 hours for up to 13 consecutive days (TPR 2.7.1, p. 54). Transit debt recovery follows the transit table category, not these rules (TPR 4.5.5)." }, "facts": { "return_windows": [ { "action": "resubmit a declined merchant-initiated authorization", "by": "Merchant", "deadline": "Set by the Merchant Advice Code on the decline: 01 update the account data first, 02 wait 24 hours, 03 or 21 never; with no advice code the rules read set no interval (TPR 3.3.1, Table 20)" }, { "action": "resubmit a declined deferred card-present authorization (not transit)", "by": "Merchant", "deadline": "Only when Merchant Advice Code 02 or another code giving a retry period came with the decline and this code does not restrict retries, which the rules read do not settle: no sooner than 24 hours after it, then at most once every 24 hours for up to 13 consecutive days (TPR 2.7.1)" }, { "action": "transit debt recovery after a declined contactless transit aggregated transaction", "by": "Transit merchant and its acquirer", "deadline": "Temporarily Recoverable: at least nine debt recovery attempts, no more than one per 24 hours, within 45 calendar days of first receiving the code, the last by day 45; once they are used up the debt counts as unrecoverable and a first ride risk claim may follow (TPR 4.5.5, Tables 22 and 23)" } ], "applies_to": "All Mastercard regions for Mastercard, Maestro and Cirrus transactions on Mastercard's network; in the EEA, the UK and Gibraltar many of these rules refer to the registered switch the customer chooses; transit categories differ in Australia (TPR Table 24)" }, "caveat": "The transit categories come from the First Ride Risk framework: they cover contactless transit aggregated transactions sent through the Dual Message System by a transit merchant in a country that has adopted the framework, in general only for cards issued in that country, and they are not a general retry rule (TPR 4.5.5, p. 162). Any valid response code missing from Table 23 counts as Unrecoverable. Table 22 still refers to this table as Table 7, a stale internal reference.", "related": [ "mastercard-decline:01", "mastercard-decline:05", "mastercard:messages" ], "basis": { "sources": "Transaction Processing Rules, 9 June 2026 edition, sections 3.3.1, 2.7.1, 4.5.4, 4.5.5 Tables 22 and 23, Asia/Pacific Region 4.5.5 Table 24. Label and category read from Table 23 on pp. 163 to 164, with each entry's column fixed from its position on the page; placed Temporarily Recoverable in Table 24 (pp. 175 to 176). Read from a copy downloaded from Mastercard's public rules page on 2026-09-19. Nothing is quoted. Medium: the label, category and retry rules follow from the cited sections, but what makes an issuer send this code is inferred from the label, and the defining specifications are not public to Orca.", "confidence": "medium" }, "currency": { "effective_since": "Before the current edition; start not stated in it", "effective_note": "Label and category as in the 9 June 2026 edition of the Transaction Processing Rules, whose summary of changes says it updated the Table 23 categories and removed past effective dates, so neither when this code's category began nor what it was before is shown. No dated change to this code was found in the edition. Mastercard reissues the manual on no fixed calendar [Inference].", "source_edition": "Transaction Processing Rules, 9 June 2026 edition (https://www.mastercard.com/content/dam/mccom/shared/business/support/rules-pdfs/transaction-processing-rules.pdf)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.mastercard.com/content/dam/mccom/shared/business/support/rules-pdfs/transaction-processing-rules.pdf", "source_class": "authoritative_primary", "source_title": "Transaction Processing Rules, 9 June 2026 edition", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms Mastercard's label for response value 70 and its Table 23 decline value category (Temporarily Recoverable) in Transaction Processing Rules 4.5.5, read by column position on pages 163 to 165, and the Table 24 Australia category on pages 175 to 176; also confirms the merchant-initiated retry framework in rules 3.3.1 and 2.7.1 (the 04, 14, 15, 41, 43 and 54 no-retry bar, the Merchant Advice Code scenarios, and the 24 hour, 13 day deferred card-present resubmission window)." } ] }, "rail_name": "Mastercard Decline Response Codes (partial)", "governing_authority": "Mastercard", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "mastercard-decline:71", "id": "71", "rail": "mastercard-decline", "kind": "reason-code", "name": "PIN not changed", "group": "authorization", "summary": "Decline because the cardholder has not yet changed a PIN the issuer requires to be changed.", "triggers": [ "The issuer requires a PIN change before the card can be used this way [Inference from Mastercard's label; the defining text is in technical specifications not public to Orca]" ], "actions": [ "Merchant (merchant-initiated retries): decide whether and when to retry from this code and the Merchant Advice Code together (TPR 3.3.1, p. 124).", "Transit merchant: pursue the debt with debt recovery authorizations, each no larger than the contactless transit aggregated CVM limit (TPR 4.5.4 and 4.5.5, pp. 161 to 164)." ], "retry": { "allowed": true, "rule": "No blanket bar in the rules read. A card-not-present merchant that retries a merchant-initiated transaction must weigh this code together with the Merchant Advice Code: 01 means get updated account data first, 02 means wait 24 hours, 03 or 21 means stop (TPR 3.3.1, Table 20, p. 124). Which advice codes may accompany this code is set in the Dual and Single Message System specifications, which are not public to Orca. A declined cardholder-initiated transaction may not come back as a merchant-initiated one, a declined token cryptogram may not be sent again, and a retry must not alter merchant data: it carries the same merchant name, address, acceptor ID and POS condition values, with either the card data the cardholder first gave, a tokenized stored credential, or data updated through the cardholder or the Automatic Billing Updater (TPR 3.3.1, pp. 124 to 125). For a declined deferred card-present authorization outside transit, resubmission needs Merchant Advice Code 02 or another advice code giving a retry period, and a decline value that does not restrict retries; the rules read do not say whether this code restricts retries. Retries then run every 24 hours for up to 13 consecutive days (TPR 2.7.1, p. 54). Transit debt recovery follows the transit table category, not these rules (TPR 4.5.5)." }, "facts": { "return_windows": [ { "action": "resubmit a declined merchant-initiated authorization", "by": "Merchant", "deadline": "Set by the Merchant Advice Code on the decline: 01 update the account data first, 02 wait 24 hours, 03 or 21 never; with no advice code the rules read set no interval (TPR 3.3.1, Table 20)" }, { "action": "resubmit a declined deferred card-present authorization (not transit)", "by": "Merchant", "deadline": "Only when Merchant Advice Code 02 or another code giving a retry period came with the decline and this code does not restrict retries, which the rules read do not settle: no sooner than 24 hours after it, then at most once every 24 hours for up to 13 consecutive days (TPR 2.7.1)" }, { "action": "transit debt recovery after a declined contactless transit aggregated transaction", "by": "Transit merchant and its acquirer", "deadline": "Recoverable: pursue the debt with debt recovery authorizations; a first ride risk claim is allowed only after at least nine attempts, no more than one per 24 hours, over the 45 calendar days from the original decline with the last on day 45, each declined for a Recoverable or Temporarily Recoverable reason (TPR 4.5.5, Tables 22 and 23)" } ], "applies_to": "All Mastercard regions for Mastercard, Maestro and Cirrus transactions on Mastercard's network; in the EEA, the UK and Gibraltar many of these rules refer to the registered switch the customer chooses; transit categories differ in Australia (TPR Table 24)" }, "caveat": "The transit categories come from the First Ride Risk framework: they cover contactless transit aggregated transactions sent through the Dual Message System by a transit merchant in a country that has adopted the framework, in general only for cards issued in that country, and they are not a general retry rule (TPR 4.5.5, p. 162). Any valid response code missing from Table 23 counts as Unrecoverable. Table 22 still refers to this table as Table 7, a stale internal reference.", "related": [ "mastercard-decline:55", "mastercard-decline:75", "mastercard-decline:86", "mastercard:messages" ], "basis": { "sources": "Transaction Processing Rules, 9 June 2026 edition, sections 3.3.1, 2.7.1, 4.5.4, 4.5.5 Tables 22 and 23, Asia/Pacific Region 4.5.5 Table 24. Label and category read from Table 23 on pp. 163 to 164, with each entry's column fixed from its position on the page; placed Recoverable in Table 24 (pp. 175 to 176). Read from a copy downloaded from Mastercard's public rules page on 2026-09-19. Nothing is quoted. Medium: the label, category and retry rules follow from the cited sections, but what makes an issuer send this code is inferred from the label, and the defining specifications are not public to Orca.", "confidence": "medium" }, "currency": { "effective_since": "Before the current edition; start not stated in it", "effective_note": "Label and category as in the 9 June 2026 edition of the Transaction Processing Rules, whose summary of changes says it updated the Table 23 categories and removed past effective dates, so neither when this code's category began nor what it was before is shown. No dated change to this code was found in the edition. Mastercard reissues the manual on no fixed calendar [Inference].", "source_edition": "Transaction Processing Rules, 9 June 2026 edition (https://www.mastercard.com/content/dam/mccom/shared/business/support/rules-pdfs/transaction-processing-rules.pdf)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.mastercard.com/content/dam/mccom/shared/business/support/rules-pdfs/transaction-processing-rules.pdf", "source_class": "authoritative_primary", "source_title": "Transaction Processing Rules, 9 June 2026 edition", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms Mastercard's label for response value 71 and its Table 23 decline value category (Recoverable) in Transaction Processing Rules 4.5.5, read by column position on pages 163 to 165, and the Table 24 Australia category on pages 175 to 176; also confirms the merchant-initiated retry framework in rules 3.3.1 and 2.7.1 (the 04, 14, 15, 41, 43 and 54 no-retry bar, the Merchant Advice Code scenarios, and the 24 hour, 13 day deferred card-present resubmission window)." } ] }, "rail_name": "Mastercard Decline Response Codes (partial)", "governing_authority": "Mastercard", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "mastercard-decline:72", "id": "72", "rail": "mastercard-decline", "kind": "reason-code", "name": "Account not yet activated", "group": "account", "summary": "Decline because the account has not been activated yet.", "triggers": [ "The card or account is issued but not yet activated [Inference from Mastercard's label; the defining text is in technical specifications not public to Orca]" ], "actions": [ "Merchant (merchant-initiated retries): decide whether and when to retry from this code and the Merchant Advice Code together (TPR 3.3.1, p. 124).", "Transit acquirer: may claim the first ride debt at once with a First Presentment/1240 carrying no approval, up to the country's first ride risk limit (TPR 4.5.5, pp. 163 to 165)." ], "retry": { "allowed": true, "rule": "No blanket bar in the rules read. A card-not-present merchant that retries a merchant-initiated transaction must weigh this code together with the Merchant Advice Code: 01 means get updated account data first, 02 means wait 24 hours, 03 or 21 means stop (TPR 3.3.1, Table 20, p. 124). Which advice codes may accompany this code is set in the Dual and Single Message System specifications, which are not public to Orca. A declined cardholder-initiated transaction may not come back as a merchant-initiated one, a declined token cryptogram may not be sent again, and a retry must not alter merchant data: it carries the same merchant name, address, acceptor ID and POS condition values, with either the card data the cardholder first gave, a tokenized stored credential, or data updated through the cardholder or the Automatic Billing Updater (TPR 3.3.1, pp. 124 to 125). For a declined deferred card-present authorization outside transit, resubmission needs Merchant Advice Code 02 or another advice code giving a retry period, and a decline value that does not restrict retries; the rules read do not say whether this code restricts retries. Retries then run every 24 hours for up to 13 consecutive days (TPR 2.7.1, p. 54). Transit debt recovery follows the transit table category, not these rules (TPR 4.5.5)." }, "facts": { "return_windows": [ { "action": "resubmit a declined merchant-initiated authorization", "by": "Merchant", "deadline": "Set by the Merchant Advice Code on the decline: 01 update the account data first, 02 wait 24 hours, 03 or 21 never; with no advice code the rules read set no interval (TPR 3.3.1, Table 20)" }, { "action": "resubmit a declined deferred card-present authorization (not transit)", "by": "Merchant", "deadline": "Only when Merchant Advice Code 02 or another code giving a retry period came with the decline and this code does not restrict retries, which the rules read do not settle: no sooner than 24 hours after it, then at most once every 24 hours for up to 13 consecutive days (TPR 2.7.1)" }, { "action": "first ride risk claim after a declined contactless transit aggregated transaction", "by": "Transit acquirer", "deadline": "Unrecoverable: may be sent at once, as a First Presentment/1240 with no approval, for no more than the first ride risk limit of the merchant's country (TPR 4.5.5, Tables 22 and 23)" } ], "applies_to": "All Mastercard regions for Mastercard, Maestro and Cirrus transactions on Mastercard's network; in the EEA, the UK and Gibraltar many of these rules refer to the registered switch the customer chooses; transit categories differ in Australia (TPR Table 24)" }, "caveat": "The transit categories come from the First Ride Risk framework: they cover contactless transit aggregated transactions sent through the Dual Message System by a transit merchant in a country that has adopted the framework, in general only for cards issued in that country, and they are not a general retry rule (TPR 4.5.5, p. 162). Any valid response code missing from Table 23 counts as Unrecoverable. Table 22 still refers to this table as Table 7, a stale internal reference.", "related": [ "mastercard-decline:46", "mastercard:messages" ], "basis": { "sources": "Transaction Processing Rules, 9 June 2026 edition, sections 3.3.1, 2.7.1, 4.5.4, 4.5.5 Tables 22 and 23, Asia/Pacific Region 4.5.5 Table 24. Label and category read from Table 23 on pp. 163 to 164, with each entry's column fixed from its position on the page; placed Unrecoverable in Table 24 (pp. 175 to 176). Read from a copy downloaded from Mastercard's public rules page on 2026-09-19. Nothing is quoted. Medium: the label, category and retry rules follow from the cited sections, but what makes an issuer send this code is inferred from the label, and the defining specifications are not public to Orca.", "confidence": "medium" }, "currency": { "effective_since": "Before the current edition; start not stated in it", "effective_note": "Label and category as in the 9 June 2026 edition of the Transaction Processing Rules, whose summary of changes says it updated the Table 23 categories and removed past effective dates, so neither when this code's category began nor what it was before is shown. No dated change to this code was found in the edition. Mastercard reissues the manual on no fixed calendar [Inference].", "source_edition": "Transaction Processing Rules, 9 June 2026 edition (https://www.mastercard.com/content/dam/mccom/shared/business/support/rules-pdfs/transaction-processing-rules.pdf)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.mastercard.com/content/dam/mccom/shared/business/support/rules-pdfs/transaction-processing-rules.pdf", "source_class": "authoritative_primary", "source_title": "Transaction Processing Rules, 9 June 2026 edition", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms Mastercard's label for response value 72 and its Table 23 decline value category (Unrecoverable) in Transaction Processing Rules 4.5.5, read by column position on pages 163 to 165, and the Table 24 Australia category on pages 175 to 176; also confirms the merchant-initiated retry framework in rules 3.3.1 and 2.7.1 (the 04, 14, 15, 41, 43 and 54 no-retry bar, the Merchant Advice Code scenarios, and the 24 hour, 13 day deferred card-present resubmission window)." } ] }, "rail_name": "Mastercard Decline Response Codes (partial)", "governing_authority": "Mastercard", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "mastercard-decline:75", "id": "75", "rail": "mastercard-decline", "kind": "reason-code", "name": "Allowable number of PIN tries exceeded", "group": "authorization", "summary": "Decline because the cardholder has entered a wrong PIN too many times.", "triggers": [ "The permitted number of PIN attempts has been used up [Inference from Mastercard's label; the defining text is in technical specifications not public to Orca]" ], "actions": [ "Merchant (merchant-initiated retries): decide whether and when to retry from this code and the Merchant Advice Code together (TPR 3.3.1, p. 124).", "ATM: Mastercard's recommended screen text for exceeded PIN attempts tells the cardholder to contact the financial institution (TPR Signage, Screen and Receipt Text Standards, p. 355) [Inference: the table names responses by wording, not by code].", "Transit merchant: pursue the debt with debt recovery authorizations, each no larger than the contactless transit aggregated CVM limit (TPR 4.5.4 and 4.5.5, pp. 161 to 164)." ], "retry": { "allowed": true, "rule": "No blanket bar in the rules read. A card-not-present merchant that retries a merchant-initiated transaction must weigh this code together with the Merchant Advice Code: 01 means get updated account data first, 02 means wait 24 hours, 03 or 21 means stop (TPR 3.3.1, Table 20, p. 124). Which advice codes may accompany this code is set in the Dual and Single Message System specifications, which are not public to Orca. A declined cardholder-initiated transaction may not come back as a merchant-initiated one, a declined token cryptogram may not be sent again, and a retry must not alter merchant data: it carries the same merchant name, address, acceptor ID and POS condition values, with either the card data the cardholder first gave, a tokenized stored credential, or data updated through the cardholder or the Automatic Billing Updater (TPR 3.3.1, pp. 124 to 125). For a declined deferred card-present authorization outside transit, resubmission needs Merchant Advice Code 02 or another advice code giving a retry period, and a decline value that does not restrict retries; the rules read do not say whether this code restricts retries. Retries then run every 24 hours for up to 13 consecutive days (TPR 2.7.1, p. 54). Transit debt recovery follows the transit table category, not these rules (TPR 4.5.5)." }, "facts": { "return_windows": [ { "action": "resubmit a declined merchant-initiated authorization", "by": "Merchant", "deadline": "Set by the Merchant Advice Code on the decline: 01 update the account data first, 02 wait 24 hours, 03 or 21 never; with no advice code the rules read set no interval (TPR 3.3.1, Table 20)" }, { "action": "resubmit a declined deferred card-present authorization (not transit)", "by": "Merchant", "deadline": "Only when Merchant Advice Code 02 or another code giving a retry period came with the decline and this code does not restrict retries, which the rules read do not settle: no sooner than 24 hours after it, then at most once every 24 hours for up to 13 consecutive days (TPR 2.7.1)" }, { "action": "transit debt recovery after a declined contactless transit aggregated transaction", "by": "Transit merchant and its acquirer", "deadline": "Recoverable: pursue the debt with debt recovery authorizations; a first ride risk claim is allowed only after at least nine attempts, no more than one per 24 hours, over the 45 calendar days from the original decline with the last on day 45, each declined for a Recoverable or Temporarily Recoverable reason (TPR 4.5.5, Tables 22 and 23)" } ], "applies_to": "All Mastercard regions for Mastercard, Maestro and Cirrus transactions on Mastercard's network; in the EEA, the UK and Gibraltar many of these rules refer to the registered switch the customer chooses; transit categories differ in Australia (TPR Table 24)" }, "caveat": "The transit categories come from the First Ride Risk framework: they cover contactless transit aggregated transactions sent through the Dual Message System by a transit merchant in a country that has adopted the framework, in general only for cards issued in that country, and they are not a general retry rule (TPR 4.5.5, p. 162). Any valid response code missing from Table 23 counts as Unrecoverable. Table 22 still refers to this table as Table 7, a stale internal reference.", "related": [ "mastercard-decline:55", "mastercard-decline:71", "mastercard-decline:86", "mastercard:messages" ], "basis": { "sources": "Transaction Processing Rules, 9 June 2026 edition, sections 3.3.1, 2.7.1, 4.5.4, 4.5.5 Tables 22 and 23, Asia/Pacific Region 4.5.5 Table 24, Signage, Screen and Receipt Text Standards (p. 355). Label and category read from Table 23 on pp. 163 to 164, with each entry's column fixed from its position on the page; placed Recoverable in Table 24 (pp. 175 to 176). Read from a copy downloaded from Mastercard's public rules page on 2026-09-19. Nothing is quoted. Medium: the label, category and retry rules follow from the cited sections, but what makes an issuer send this code is inferred from the label, and the defining specifications are not public to Orca.", "confidence": "medium" }, "currency": { "effective_since": "Before the current edition; start not stated in it", "effective_note": "Label and category as in the 9 June 2026 edition of the Transaction Processing Rules, whose summary of changes says it updated the Table 23 categories and removed past effective dates, so neither when this code's category began nor what it was before is shown. No dated change to this code was found in the edition. Mastercard reissues the manual on no fixed calendar [Inference].", "source_edition": "Transaction Processing Rules, 9 June 2026 edition (https://www.mastercard.com/content/dam/mccom/shared/business/support/rules-pdfs/transaction-processing-rules.pdf)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.mastercard.com/content/dam/mccom/shared/business/support/rules-pdfs/transaction-processing-rules.pdf", "source_class": "authoritative_primary", "source_title": "Transaction Processing Rules, 9 June 2026 edition", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms Mastercard's label for response value 75 and its Table 23 decline value category (Recoverable) in Transaction Processing Rules 4.5.5, read by column position on pages 163 to 165, and the Table 24 Australia category on pages 175 to 176; also confirms the merchant-initiated retry framework in rules 3.3.1 and 2.7.1 (the 04, 14, 15, 41, 43 and 54 no-retry bar, the Merchant Advice Code scenarios, and the 24 hour, 13 day deferred card-present resubmission window)." } ] }, "rail_name": "Mastercard Decline Response Codes (partial)", "governing_authority": "Mastercard", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "mastercard-decline:76", "id": "76", "rail": "mastercard-decline", "kind": "reason-code", "name": "Invalid/nonexistent To Account specified", "group": "account", "summary": "Decline because the account to be credited, as specified in the request, is invalid or does not exist.", "triggers": [ "The destination account named in the request, for example in a transfer between accounts, is not valid [Inference from Mastercard's label; the defining text is in technical specifications not public to Orca]" ], "actions": [ "Merchant (merchant-initiated retries): decide whether and when to retry from this code and the Merchant Advice Code together (TPR 3.3.1, p. 124).", "Transit merchant: pursue the debt with debt recovery authorizations, each no larger than the contactless transit aggregated CVM limit (TPR 4.5.4 and 4.5.5, pp. 161 to 164)." ], "retry": { "allowed": true, "rule": "No blanket bar in the rules read. A card-not-present merchant that retries a merchant-initiated transaction must weigh this code together with the Merchant Advice Code: 01 means get updated account data first, 02 means wait 24 hours, 03 or 21 means stop (TPR 3.3.1, Table 20, p. 124). Which advice codes may accompany this code is set in the Dual and Single Message System specifications, which are not public to Orca. A declined cardholder-initiated transaction may not come back as a merchant-initiated one, a declined token cryptogram may not be sent again, and a retry must not alter merchant data: it carries the same merchant name, address, acceptor ID and POS condition values, with either the card data the cardholder first gave, a tokenized stored credential, or data updated through the cardholder or the Automatic Billing Updater (TPR 3.3.1, pp. 124 to 125). For a declined deferred card-present authorization outside transit, resubmission needs Merchant Advice Code 02 or another advice code giving a retry period, and a decline value that does not restrict retries; the rules read do not say whether this code restricts retries. Retries then run every 24 hours for up to 13 consecutive days (TPR 2.7.1, p. 54). Transit debt recovery follows the transit table category, not these rules (TPR 4.5.5)." }, "facts": { "return_windows": [ { "action": "resubmit a declined merchant-initiated authorization", "by": "Merchant", "deadline": "Set by the Merchant Advice Code on the decline: 01 update the account data first, 02 wait 24 hours, 03 or 21 never; with no advice code the rules read set no interval (TPR 3.3.1, Table 20)" }, { "action": "resubmit a declined deferred card-present authorization (not transit)", "by": "Merchant", "deadline": "Only when Merchant Advice Code 02 or another code giving a retry period came with the decline and this code does not restrict retries, which the rules read do not settle: no sooner than 24 hours after it, then at most once every 24 hours for up to 13 consecutive days (TPR 2.7.1)" }, { "action": "transit debt recovery after a declined contactless transit aggregated transaction", "by": "Transit merchant and its acquirer", "deadline": "Recoverable: pursue the debt with debt recovery authorizations; a first ride risk claim is allowed only after at least nine attempts, no more than one per 24 hours, over the 45 calendar days from the original decline with the last on day 45, each declined for a Recoverable or Temporarily Recoverable reason (TPR 4.5.5, Tables 22 and 23)" } ], "applies_to": "All Mastercard regions for Mastercard, Maestro and Cirrus transactions on Mastercard's network; in the EEA, the UK and Gibraltar many of these rules refer to the registered switch the customer chooses; transit categories differ in Australia (TPR Table 24)" }, "caveat": "The transit categories come from the First Ride Risk framework: they cover contactless transit aggregated transactions sent through the Dual Message System by a transit merchant in a country that has adopted the framework, in general only for cards issued in that country, and they are not a general retry rule (TPR 4.5.5, p. 162). Any valid response code missing from Table 23 counts as Unrecoverable. Table 22 still refers to this table as Table 7, a stale internal reference.", "related": [ "mastercard-decline:77", "mastercard-decline:78", "mastercard:messages" ], "basis": { "sources": "Transaction Processing Rules, 9 June 2026 edition, sections 3.3.1, 2.7.1, 4.5.4, 4.5.5 Tables 22 and 23, Asia/Pacific Region 4.5.5 Table 24. Label and category read from Table 23 on pp. 163 to 164, with each entry's column fixed from its position on the page; placed Recoverable in Table 24 (pp. 175 to 176). Read from a copy downloaded from Mastercard's public rules page on 2026-09-19. Nothing is quoted. Medium: the label, category and retry rules follow from the cited sections, but what makes an issuer send this code is inferred from the label, and the defining specifications are not public to Orca.", "confidence": "medium" }, "currency": { "effective_since": "Before the current edition; start not stated in it", "effective_note": "Label and category as in the 9 June 2026 edition of the Transaction Processing Rules, whose summary of changes says it updated the Table 23 categories and removed past effective dates, so neither when this code's category began nor what it was before is shown. No dated change to this code was found in the edition. Mastercard reissues the manual on no fixed calendar [Inference].", "source_edition": "Transaction Processing Rules, 9 June 2026 edition (https://www.mastercard.com/content/dam/mccom/shared/business/support/rules-pdfs/transaction-processing-rules.pdf)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.mastercard.com/content/dam/mccom/shared/business/support/rules-pdfs/transaction-processing-rules.pdf", "source_class": "authoritative_primary", "source_title": "Transaction Processing Rules, 9 June 2026 edition", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms Mastercard's label for response value 76 and its Table 23 decline value category (Recoverable) in Transaction Processing Rules 4.5.5, read by column position on pages 163 to 165, and the Table 24 Australia category on pages 175 to 176; also confirms the merchant-initiated retry framework in rules 3.3.1 and 2.7.1 (the 04, 14, 15, 41, 43 and 54 no-retry bar, the Merchant Advice Code scenarios, and the 24 hour, 13 day deferred card-present resubmission window)." } ] }, "rail_name": "Mastercard Decline Response Codes (partial)", "governing_authority": "Mastercard", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "mastercard-decline:77", "id": "77", "rail": "mastercard-decline", "kind": "reason-code", "name": "Invalid/nonexistent From Account specified", "group": "account", "summary": "Decline because the account to be debited, as specified in the request, is invalid or does not exist.", "triggers": [ "The source account named in the request, for example a checking or savings selection at an ATM, is not valid [Inference from Mastercard's label; the defining text is in technical specifications not public to Orca]" ], "actions": [ "Merchant (merchant-initiated retries): decide whether and when to retry from this code and the Merchant Advice Code together (TPR 3.3.1, p. 124).", "Transit merchant: pursue the debt with debt recovery authorizations, each no larger than the contactless transit aggregated CVM limit (TPR 4.5.4 and 4.5.5, pp. 161 to 164)." ], "retry": { "allowed": true, "rule": "No blanket bar in the rules read. A card-not-present merchant that retries a merchant-initiated transaction must weigh this code together with the Merchant Advice Code: 01 means get updated account data first, 02 means wait 24 hours, 03 or 21 means stop (TPR 3.3.1, Table 20, p. 124). Which advice codes may accompany this code is set in the Dual and Single Message System specifications, which are not public to Orca. A declined cardholder-initiated transaction may not come back as a merchant-initiated one, a declined token cryptogram may not be sent again, and a retry must not alter merchant data: it carries the same merchant name, address, acceptor ID and POS condition values, with either the card data the cardholder first gave, a tokenized stored credential, or data updated through the cardholder or the Automatic Billing Updater (TPR 3.3.1, pp. 124 to 125). For a declined deferred card-present authorization outside transit, resubmission needs Merchant Advice Code 02 or another advice code giving a retry period, and a decline value that does not restrict retries; the rules read do not say whether this code restricts retries. Retries then run every 24 hours for up to 13 consecutive days (TPR 2.7.1, p. 54). Transit debt recovery follows the transit table category, not these rules (TPR 4.5.5)." }, "facts": { "return_windows": [ { "action": "resubmit a declined merchant-initiated authorization", "by": "Merchant", "deadline": "Set by the Merchant Advice Code on the decline: 01 update the account data first, 02 wait 24 hours, 03 or 21 never; with no advice code the rules read set no interval (TPR 3.3.1, Table 20)" }, { "action": "resubmit a declined deferred card-present authorization (not transit)", "by": "Merchant", "deadline": "Only when Merchant Advice Code 02 or another code giving a retry period came with the decline and this code does not restrict retries, which the rules read do not settle: no sooner than 24 hours after it, then at most once every 24 hours for up to 13 consecutive days (TPR 2.7.1)" }, { "action": "transit debt recovery after a declined contactless transit aggregated transaction", "by": "Transit merchant and its acquirer", "deadline": "Recoverable: pursue the debt with debt recovery authorizations; a first ride risk claim is allowed only after at least nine attempts, no more than one per 24 hours, over the 45 calendar days from the original decline with the last on day 45, each declined for a Recoverable or Temporarily Recoverable reason (TPR 4.5.5, Tables 22 and 23)" } ], "applies_to": "All Mastercard regions for Mastercard, Maestro and Cirrus transactions on Mastercard's network; in the EEA, the UK and Gibraltar many of these rules refer to the registered switch the customer chooses; transit categories differ in Australia (TPR Table 24)" }, "caveat": "The transit categories come from the First Ride Risk framework: they cover contactless transit aggregated transactions sent through the Dual Message System by a transit merchant in a country that has adopted the framework, in general only for cards issued in that country, and they are not a general retry rule (TPR 4.5.5, p. 162). Any valid response code missing from Table 23 counts as Unrecoverable. Table 22 still refers to this table as Table 7, a stale internal reference.", "related": [ "mastercard-decline:76", "mastercard-decline:78", "mastercard:messages" ], "basis": { "sources": "Transaction Processing Rules, 9 June 2026 edition, sections 3.3.1, 2.7.1, 4.5.4, 4.5.5 Tables 22 and 23, Asia/Pacific Region 4.5.5 Table 24. Label and category read from Table 23 on pp. 163 to 164, with each entry's column fixed from its position on the page; placed Recoverable in Table 24 (pp. 175 to 176). Read from a copy downloaded from Mastercard's public rules page on 2026-09-19. Nothing is quoted. Medium: the label, category and retry rules follow from the cited sections, but what makes an issuer send this code is inferred from the label, and the defining specifications are not public to Orca.", "confidence": "medium" }, "currency": { "effective_since": "Before the current edition; start not stated in it", "effective_note": "Label and category as in the 9 June 2026 edition of the Transaction Processing Rules, whose summary of changes says it updated the Table 23 categories and removed past effective dates, so neither when this code's category began nor what it was before is shown. No dated change to this code was found in the edition. Mastercard reissues the manual on no fixed calendar [Inference].", "source_edition": "Transaction Processing Rules, 9 June 2026 edition (https://www.mastercard.com/content/dam/mccom/shared/business/support/rules-pdfs/transaction-processing-rules.pdf)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.mastercard.com/content/dam/mccom/shared/business/support/rules-pdfs/transaction-processing-rules.pdf", "source_class": "authoritative_primary", "source_title": "Transaction Processing Rules, 9 June 2026 edition", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms Mastercard's label for response value 77 and its Table 23 decline value category (Recoverable) in Transaction Processing Rules 4.5.5, read by column position on pages 163 to 165, and the Table 24 Australia category on pages 175 to 176; also confirms the merchant-initiated retry framework in rules 3.3.1 and 2.7.1 (the 04, 14, 15, 41, 43 and 54 no-retry bar, the Merchant Advice Code scenarios, and the 24 hour, 13 day deferred card-present resubmission window)." } ] }, "rail_name": "Mastercard Decline Response Codes (partial)", "governing_authority": "Mastercard", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "mastercard-decline:78", "id": "78", "rail": "mastercard-decline", "kind": "reason-code", "name": "Invalid/Nonexistent account specified", "group": "account", "summary": "Decline because the account specified in the request is invalid or does not exist.", "triggers": [ "The account named in the request is not valid for the card [Inference from Mastercard's label; the defining text is in technical specifications not public to Orca]" ], "actions": [ "Merchant (merchant-initiated retries): decide whether and when to retry from this code and the Merchant Advice Code together (TPR 3.3.1, p. 124).", "Transit merchant: pursue the debt with debt recovery authorizations, each no larger than the contactless transit aggregated CVM limit (TPR 4.5.4 and 4.5.5, pp. 161 to 164)." ], "retry": { "allowed": true, "rule": "No blanket bar in the rules read. A card-not-present merchant that retries a merchant-initiated transaction must weigh this code together with the Merchant Advice Code: 01 means get updated account data first, 02 means wait 24 hours, 03 or 21 means stop (TPR 3.3.1, Table 20, p. 124). Which advice codes may accompany this code is set in the Dual and Single Message System specifications, which are not public to Orca. A declined cardholder-initiated transaction may not come back as a merchant-initiated one, a declined token cryptogram may not be sent again, and a retry must not alter merchant data: it carries the same merchant name, address, acceptor ID and POS condition values, with either the card data the cardholder first gave, a tokenized stored credential, or data updated through the cardholder or the Automatic Billing Updater (TPR 3.3.1, pp. 124 to 125). For a declined deferred card-present authorization outside transit, resubmission needs Merchant Advice Code 02 or another advice code giving a retry period, and a decline value that does not restrict retries; the rules read do not say whether this code restricts retries. Retries then run every 24 hours for up to 13 consecutive days (TPR 2.7.1, p. 54). Transit debt recovery follows the transit table category, not these rules (TPR 4.5.5)." }, "facts": { "return_windows": [ { "action": "resubmit a declined merchant-initiated authorization", "by": "Merchant", "deadline": "Set by the Merchant Advice Code on the decline: 01 update the account data first, 02 wait 24 hours, 03 or 21 never; with no advice code the rules read set no interval (TPR 3.3.1, Table 20)" }, { "action": "resubmit a declined deferred card-present authorization (not transit)", "by": "Merchant", "deadline": "Only when Merchant Advice Code 02 or another code giving a retry period came with the decline and this code does not restrict retries, which the rules read do not settle: no sooner than 24 hours after it, then at most once every 24 hours for up to 13 consecutive days (TPR 2.7.1)" }, { "action": "transit debt recovery after a declined contactless transit aggregated transaction", "by": "Transit merchant and its acquirer", "deadline": "Recoverable: pursue the debt with debt recovery authorizations; a first ride risk claim is allowed only after at least nine attempts, no more than one per 24 hours, over the 45 calendar days from the original decline with the last on day 45, each declined for a Recoverable or Temporarily Recoverable reason (TPR 4.5.5, Tables 22 and 23)" } ], "applies_to": "All Mastercard regions for Mastercard, Maestro and Cirrus transactions on Mastercard's network; in the EEA, the UK and Gibraltar many of these rules refer to the registered switch the customer chooses; transit categories differ in Australia (TPR Table 24)" }, "caveat": "The transit categories come from the First Ride Risk framework: they cover contactless transit aggregated transactions sent through the Dual Message System by a transit merchant in a country that has adopted the framework, in general only for cards issued in that country, and they are not a general retry rule (TPR 4.5.5, p. 162). Any valid response code missing from Table 23 counts as Unrecoverable. Table 22 still refers to this table as Table 7, a stale internal reference.", "related": [ "mastercard-decline:76", "mastercard-decline:77", "mastercard-decline:46", "mastercard:messages" ], "basis": { "sources": "Transaction Processing Rules, 9 June 2026 edition, sections 3.3.1, 2.7.1, 4.5.4, 4.5.5 Tables 22 and 23, Asia/Pacific Region 4.5.5 Table 24. Label and category read from Table 23 on pp. 163 to 164, with each entry's column fixed from its position on the page; placed Recoverable in Table 24 (pp. 175 to 176). Read from a copy downloaded from Mastercard's public rules page on 2026-09-19. Nothing is quoted. Medium: the label, category and retry rules follow from the cited sections, but what makes an issuer send this code is inferred from the label, and the defining specifications are not public to Orca.", "confidence": "medium" }, "currency": { "effective_since": "Before the current edition; start not stated in it", "effective_note": "Label and category as in the 9 June 2026 edition of the Transaction Processing Rules, whose summary of changes says it updated the Table 23 categories and removed past effective dates, so neither when this code's category began nor what it was before is shown. No dated change to this code was found in the edition. Mastercard reissues the manual on no fixed calendar [Inference].", "source_edition": "Transaction Processing Rules, 9 June 2026 edition (https://www.mastercard.com/content/dam/mccom/shared/business/support/rules-pdfs/transaction-processing-rules.pdf)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.mastercard.com/content/dam/mccom/shared/business/support/rules-pdfs/transaction-processing-rules.pdf", "source_class": "authoritative_primary", "source_title": "Transaction Processing Rules, 9 June 2026 edition", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms Mastercard's label for response value 78 and its Table 23 decline value category (Recoverable) in Transaction Processing Rules 4.5.5, read by column position on pages 163 to 165, and the Table 24 Australia category on pages 175 to 176; also confirms the merchant-initiated retry framework in rules 3.3.1 and 2.7.1 (the 04, 14, 15, 41, 43 and 54 no-retry bar, the Merchant Advice Code scenarios, and the 24 hour, 13 day deferred card-present resubmission window)." } ] }, "rail_name": "Mastercard Decline Response Codes (partial)", "governing_authority": "Mastercard", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "mastercard-decline:79", "id": "79", "rail": "mastercard-decline", "kind": "reason-code", "name": "Life cycle (Mastercard use only)", "group": "authorization", "summary": "Decline set by Mastercard, not the issuer, for a life-cycle reason.", "triggers": [ "Mastercard declines for a life-cycle reason [Inference from Mastercard's label; the defining text is in technical specifications not public to Orca]" ], "actions": [ "Merchant (merchant-initiated retries): decide whether and when to retry from this code and the Merchant Advice Code together (TPR 3.3.1, p. 124).", "Transit acquirer: may claim the first ride debt at once with a First Presentment/1240 carrying no approval, up to the country's first ride risk limit (TPR 4.5.5, pp. 163 to 165)." ], "retry": { "allowed": true, "rule": "No blanket bar in the rules read. A card-not-present merchant that retries a merchant-initiated transaction must weigh this code together with the Merchant Advice Code: 01 means get updated account data first, 02 means wait 24 hours, 03 or 21 means stop (TPR 3.3.1, Table 20, p. 124). Which advice codes may accompany this code is set in the Dual and Single Message System specifications, which are not public to Orca. A declined cardholder-initiated transaction may not come back as a merchant-initiated one, a declined token cryptogram may not be sent again, and a retry must not alter merchant data: it carries the same merchant name, address, acceptor ID and POS condition values, with either the card data the cardholder first gave, a tokenized stored credential, or data updated through the cardholder or the Automatic Billing Updater (TPR 3.3.1, pp. 124 to 125). For a declined deferred card-present authorization outside transit, resubmission needs Merchant Advice Code 02 or another advice code giving a retry period, and a decline value that does not restrict retries; the rules read do not say whether this code restricts retries. Retries then run every 24 hours for up to 13 consecutive days (TPR 2.7.1, p. 54). Transit debt recovery follows the transit table category, not these rules (TPR 4.5.5)." }, "facts": { "return_windows": [ { "action": "resubmit a declined merchant-initiated authorization", "by": "Merchant", "deadline": "Set by the Merchant Advice Code on the decline: 01 update the account data first, 02 wait 24 hours, 03 or 21 never; with no advice code the rules read set no interval (TPR 3.3.1, Table 20)" }, { "action": "resubmit a declined deferred card-present authorization (not transit)", "by": "Merchant", "deadline": "Only when Merchant Advice Code 02 or another code giving a retry period came with the decline and this code does not restrict retries, which the rules read do not settle: no sooner than 24 hours after it, then at most once every 24 hours for up to 13 consecutive days (TPR 2.7.1)" }, { "action": "first ride risk claim after a declined contactless transit aggregated transaction", "by": "Transit acquirer", "deadline": "Unrecoverable: may be sent at once, as a First Presentment/1240 with no approval, for no more than the first ride risk limit of the merchant's country (TPR 4.5.5, Tables 22 and 23)" }, { "action": "transit debt recovery or first ride risk claim, Australia", "by": "Transit merchant and its acquirer (Australia)", "deadline": "Not listed in Table 24, which replaces Table 23 in Australia; whether the global rule that unlisted codes count as Unrecoverable carries over is not stated (TPR Asia/Pacific Region 4.5.5, p. 175) [Inference]" } ], "applies_to": "All Mastercard regions for Mastercard, Maestro and Cirrus transactions on Mastercard's network; in the EEA, the UK and Gibraltar many of these rules refer to the registered switch the customer chooses; transit categories differ in Australia (TPR Table 24)" }, "caveat": "Table 23 marks this code as for Mastercard use only, so it comes from Mastercard, not from an issuer. The transit categories come from the First Ride Risk framework: they cover contactless transit aggregated transactions sent through the Dual Message System by a transit merchant in a country that has adopted the framework, in general only for cards issued in that country, and they are not a general retry rule (TPR 4.5.5, p. 162). Any valid response code missing from Table 23 counts as Unrecoverable. Table 22 still refers to this table as Table 7, a stale internal reference.", "related": [ "mastercard-decline:82", "mastercard-decline:83", "mastercard:messages" ], "basis": { "sources": "Transaction Processing Rules, 9 June 2026 edition, sections 3.3.1, 2.7.1, 4.5.4, 4.5.5 Tables 22 and 23, Asia/Pacific Region 4.5.5 Table 24. Label and category read from Table 23 on pp. 163 to 164, with each entry's column fixed from its position on the page; absent from Table 24 (pp. 175 to 176). Read from a copy downloaded from Mastercard's public rules page on 2026-09-19. Nothing is quoted. Medium: the label, category and retry rules follow from the cited sections, but what makes an issuer send this code is inferred from the label, and the defining specifications are not public to Orca.", "confidence": "medium" }, "currency": { "effective_since": "Before the current edition; start not stated in it", "effective_note": "Label and category as in the 9 June 2026 edition of the Transaction Processing Rules, whose summary of changes says it updated the Table 23 categories and removed past effective dates, so neither when this code's category began nor what it was before is shown. No dated change to this code was found in the edition. Mastercard reissues the manual on no fixed calendar [Inference].", "source_edition": "Transaction Processing Rules, 9 June 2026 edition (https://www.mastercard.com/content/dam/mccom/shared/business/support/rules-pdfs/transaction-processing-rules.pdf)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.mastercard.com/content/dam/mccom/shared/business/support/rules-pdfs/transaction-processing-rules.pdf", "source_class": "authoritative_primary", "source_title": "Transaction Processing Rules, 9 June 2026 edition", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms Mastercard's label for response value 79 and its Table 23 decline value category (Unrecoverable, absent from the Australia Table 24) in Transaction Processing Rules 4.5.5, read by column position on pages 163 to 165, and the Table 24 Australia category on pages 175 to 176; also confirms the merchant-initiated retry framework in rules 3.3.1 and 2.7.1 (the 04, 14, 15, 41, 43 and 54 no-retry bar, the Merchant Advice Code scenarios, and the 24 hour, 13 day deferred card-present resubmission window) as a Mastercard-use-only value." } ] }, "rail_name": "Mastercard Decline Response Codes (partial)", "governing_authority": "Mastercard", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "mastercard-decline:82", "id": "82", "rail": "mastercard-decline", "kind": "reason-code", "name": "Policy (Mastercard use only)", "group": "authorization", "summary": "Decline set by Mastercard, not the issuer, on policy grounds. In the Europe issuer failure-rate rule the same number stands for a time-out at the issuer host.", "triggers": [ "Mastercard declines on policy grounds [Inference from Mastercard's label; the defining text is in technical specifications not public to Orca]" ], "actions": [ "Merchant (merchant-initiated retries): decide whether and when to retry from this code and the Merchant Advice Code together (TPR 3.3.1, p. 124).", "Transit acquirer: may claim the first ride debt at once with a First Presentment/1240 carrying no approval, up to the country's first ride risk limit (TPR 4.5.5, pp. 163 to 165)." ], "retry": { "allowed": true, "rule": "No blanket bar in the rules read. A card-not-present merchant that retries a merchant-initiated transaction must weigh this code together with the Merchant Advice Code: 01 means get updated account data first, 02 means wait 24 hours, 03 or 21 means stop (TPR 3.3.1, Table 20, p. 124). Which advice codes may accompany this code is set in the Dual and Single Message System specifications, which are not public to Orca. A declined cardholder-initiated transaction may not come back as a merchant-initiated one, a declined token cryptogram may not be sent again, and a retry must not alter merchant data: it carries the same merchant name, address, acceptor ID and POS condition values, with either the card data the cardholder first gave, a tokenized stored credential, or data updated through the cardholder or the Automatic Billing Updater (TPR 3.3.1, pp. 124 to 125). For a declined deferred card-present authorization outside transit, resubmission needs Merchant Advice Code 02 or another advice code giving a retry period, and a decline value that does not restrict retries; the rules read do not say whether this code restricts retries. Retries then run every 24 hours for up to 13 consecutive days (TPR 2.7.1, p. 54). Transit debt recovery follows the transit table category, not these rules (TPR 4.5.5)." }, "facts": { "return_windows": [ { "action": "resubmit a declined merchant-initiated authorization", "by": "Merchant", "deadline": "Set by the Merchant Advice Code on the decline: 01 update the account data first, 02 wait 24 hours, 03 or 21 never; with no advice code the rules read set no interval (TPR 3.3.1, Table 20)" }, { "action": "resubmit a declined deferred card-present authorization (not transit)", "by": "Merchant", "deadline": "Only when Merchant Advice Code 02 or another code giving a retry period came with the decline and this code does not restrict retries, which the rules read do not settle: no sooner than 24 hours after it, then at most once every 24 hours for up to 13 consecutive days (TPR 2.7.1)" }, { "action": "first ride risk claim after a declined contactless transit aggregated transaction", "by": "Transit acquirer", "deadline": "Unrecoverable: may be sent at once, as a First Presentment/1240 with no approval, for no more than the first ride risk limit of the merchant's country (TPR 4.5.5, Tables 22 and 23)" }, { "action": "transit debt recovery or first ride risk claim, Australia", "by": "Transit merchant and its acquirer (Australia)", "deadline": "Not listed in Table 24, which replaces Table 23 in Australia; whether the global rule that unlisted codes count as Unrecoverable carries over is not stated (TPR Asia/Pacific Region 4.5.5, p. 175) [Inference]" } ], "applies_to": "All Mastercard regions for Mastercard, Maestro and Cirrus transactions on Mastercard's network; in the EEA, the UK and Gibraltar many of these rules refer to the registered switch the customer chooses; transit categories differ in Australia (TPR Table 24)" }, "caveat": "Table 23 marks this code as for Mastercard use only. Europe Region: the issuer failure-rate rule counts ISO 8583 code 82 as a time-out at the issuer host, a different meaning (TPR Europe Region 2.4.2, p. 89). The transit categories come from the First Ride Risk framework: they cover contactless transit aggregated transactions sent through the Dual Message System by a transit merchant in a country that has adopted the framework, in general only for cards issued in that country, and they are not a general retry rule (TPR 4.5.5, p. 162). Any valid response code missing from Table 23 counts as Unrecoverable. Table 22 still refers to this table as Table 7, a stale internal reference.", "related": [ "mastercard-decline:79", "mastercard-decline:83", "mastercard:messages", "mastercard-decline:96" ], "basis": { "sources": "Transaction Processing Rules, 9 June 2026 edition, sections 3.3.1, 2.7.1, 4.5.4, 4.5.5 Tables 22 and 23, Asia/Pacific Region 4.5.5 Table 24, Europe Region 2.4.2. Label and category read from Table 23 on pp. 163 to 164, with each entry's column fixed from its position on the page; absent from Table 24 (pp. 175 to 176). Read from a copy downloaded from Mastercard's public rules page on 2026-09-19. Nothing is quoted. Medium: the label, category and retry rules follow from the cited sections, but what makes an issuer send this code is inferred from the label, and the defining specifications are not public to Orca.", "confidence": "medium" }, "currency": { "effective_since": "Before the current edition; start not stated in it", "effective_note": "Label and category as in the 9 June 2026 edition of the Transaction Processing Rules, whose summary of changes says it updated the Table 23 categories and removed past effective dates, so neither when this code's category began nor what it was before is shown. No dated change to this code was found in the edition. Mastercard reissues the manual on no fixed calendar [Inference].", "source_edition": "Transaction Processing Rules, 9 June 2026 edition (https://www.mastercard.com/content/dam/mccom/shared/business/support/rules-pdfs/transaction-processing-rules.pdf)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.mastercard.com/content/dam/mccom/shared/business/support/rules-pdfs/transaction-processing-rules.pdf", "source_class": "authoritative_primary", "source_title": "Transaction Processing Rules, 9 June 2026 edition", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms Mastercard's label for response value 82 and its Table 23 decline value category (Unrecoverable, absent from the Australia Table 24) in Transaction Processing Rules 4.5.5, read by column position on pages 163 to 165, and the Table 24 Australia category on pages 175 to 176; also confirms the merchant-initiated retry framework in rules 3.3.1 and 2.7.1 (the 04, 14, 15, 41, 43 and 54 no-retry bar, the Merchant Advice Code scenarios, and the 24 hour, 13 day deferred card-present resubmission window) as a Mastercard-use-only value in Table 23, and confirms the separate meaning of ISO 8583 code 82 as an issuer host time-out in the Europe issuer failure-rate rule." } ] }, "rail_name": "Mastercard Decline Response Codes (partial)", "governing_authority": "Mastercard", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "mastercard-decline:83", "id": "83", "rail": "mastercard-decline", "kind": "reason-code", "name": "Fraud/Security (Mastercard use only)", "group": "authorization", "summary": "Decline set by Mastercard, not the issuer, for fraud or security reasons.", "triggers": [ "Mastercard declines for fraud or security reasons [Inference from Mastercard's label; the defining text is in technical specifications not public to Orca]" ], "actions": [ "Merchant (merchant-initiated retries): decide whether and when to retry from this code and the Merchant Advice Code together (TPR 3.3.1, p. 124).", "Transit acquirer: may claim the first ride debt at once with a First Presentment/1240 carrying no approval, up to the country's first ride risk limit (TPR 4.5.5, pp. 163 to 165)." ], "retry": { "allowed": true, "rule": "No blanket bar in the rules read. A card-not-present merchant that retries a merchant-initiated transaction must weigh this code together with the Merchant Advice Code: 01 means get updated account data first, 02 means wait 24 hours, 03 or 21 means stop (TPR 3.3.1, Table 20, p. 124). Which advice codes may accompany this code is set in the Dual and Single Message System specifications, which are not public to Orca. A declined cardholder-initiated transaction may not come back as a merchant-initiated one, a declined token cryptogram may not be sent again, and a retry must not alter merchant data: it carries the same merchant name, address, acceptor ID and POS condition values, with either the card data the cardholder first gave, a tokenized stored credential, or data updated through the cardholder or the Automatic Billing Updater (TPR 3.3.1, pp. 124 to 125). For a declined deferred card-present authorization outside transit, resubmission needs Merchant Advice Code 02 or another advice code giving a retry period, and a decline value that does not restrict retries; the rules read do not say whether this code restricts retries. Retries then run every 24 hours for up to 13 consecutive days (TPR 2.7.1, p. 54). Transit debt recovery follows the transit table category, not these rules (TPR 4.5.5)." }, "facts": { "return_windows": [ { "action": "resubmit a declined merchant-initiated authorization", "by": "Merchant", "deadline": "Set by the Merchant Advice Code on the decline: 01 update the account data first, 02 wait 24 hours, 03 or 21 never; with no advice code the rules read set no interval (TPR 3.3.1, Table 20)" }, { "action": "resubmit a declined deferred card-present authorization (not transit)", "by": "Merchant", "deadline": "Only when Merchant Advice Code 02 or another code giving a retry period came with the decline and this code does not restrict retries, which the rules read do not settle: no sooner than 24 hours after it, then at most once every 24 hours for up to 13 consecutive days (TPR 2.7.1)" }, { "action": "first ride risk claim after a declined contactless transit aggregated transaction", "by": "Transit acquirer", "deadline": "Unrecoverable: may be sent at once, as a First Presentment/1240 with no approval, for no more than the first ride risk limit of the merchant's country (TPR 4.5.5, Tables 22 and 23)" }, { "action": "transit debt recovery or first ride risk claim, Australia", "by": "Transit merchant and its acquirer (Australia)", "deadline": "Not listed in Table 24, which replaces Table 23 in Australia; whether the global rule that unlisted codes count as Unrecoverable carries over is not stated (TPR Asia/Pacific Region 4.5.5, p. 175) [Inference]" } ], "applies_to": "All Mastercard regions for Mastercard, Maestro and Cirrus transactions on Mastercard's network; in the EEA, the UK and Gibraltar many of these rules refer to the registered switch the customer chooses; transit categories differ in Australia (TPR Table 24)" }, "caveat": "Table 23 marks this code as for Mastercard use only, so it comes from Mastercard, not from an issuer. The transit categories come from the First Ride Risk framework: they cover contactless transit aggregated transactions sent through the Dual Message System by a transit merchant in a country that has adopted the framework, in general only for cards issued in that country, and they are not a general retry rule (TPR 4.5.5, p. 162). Any valid response code missing from Table 23 counts as Unrecoverable. Table 22 still refers to this table as Table 7, a stale internal reference.", "related": [ "mastercard-decline:79", "mastercard-decline:82", "mastercard-decline:63", "mastercard:messages" ], "basis": { "sources": "Transaction Processing Rules, 9 June 2026 edition, sections 3.3.1, 2.7.1, 4.5.4, 4.5.5 Tables 22 and 23, Asia/Pacific Region 4.5.5 Table 24. Label and category read from Table 23 on pp. 163 to 164, with each entry's column fixed from its position on the page; absent from Table 24 (pp. 175 to 176). Read from a copy downloaded from Mastercard's public rules page on 2026-09-19. Nothing is quoted. Medium: the label, category and retry rules follow from the cited sections, but what makes an issuer send this code is inferred from the label, and the defining specifications are not public to Orca.", "confidence": "medium" }, "currency": { "effective_since": "Before the current edition; start not stated in it", "effective_note": "Label and category as in the 9 June 2026 edition of the Transaction Processing Rules, whose summary of changes says it updated the Table 23 categories and removed past effective dates, so neither when this code's category began nor what it was before is shown. No dated change to this code was found in the edition. Mastercard reissues the manual on no fixed calendar [Inference].", "source_edition": "Transaction Processing Rules, 9 June 2026 edition (https://www.mastercard.com/content/dam/mccom/shared/business/support/rules-pdfs/transaction-processing-rules.pdf)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.mastercard.com/content/dam/mccom/shared/business/support/rules-pdfs/transaction-processing-rules.pdf", "source_class": "authoritative_primary", "source_title": "Transaction Processing Rules, 9 June 2026 edition", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms Mastercard's label for response value 83 and its Table 23 decline value category (Unrecoverable, absent from the Australia Table 24) in Transaction Processing Rules 4.5.5, read by column position on pages 163 to 165, and the Table 24 Australia category on pages 175 to 176; also confirms the merchant-initiated retry framework in rules 3.3.1 and 2.7.1 (the 04, 14, 15, 41, 43 and 54 no-retry bar, the Merchant Advice Code scenarios, and the 24 hour, 13 day deferred card-present resubmission window) as a Mastercard-use-only value." } ] }, "rail_name": "Mastercard Decline Response Codes (partial)", "governing_authority": "Mastercard", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "mastercard-decline:86", "id": "86", "rail": "mastercard-decline", "kind": "reason-code", "name": "PIN validation not possible", "group": "authorization", "summary": "Decline because the PIN could not be checked at the time, as opposed to being wrong.", "triggers": [ "PIN validation was not possible when the request arrived [Inference from Mastercard's label; the defining text is in technical specifications not public to Orca]" ], "actions": [ "Merchant (merchant-initiated retries): decide whether and when to retry from this code and the Merchant Advice Code together (TPR 3.3.1, p. 124).", "Transit merchant: make at least nine debt recovery attempts within 45 days; this is a situation the cardholder may be able to resolve with the issuer (TPR 4.5.5, p. 165)." ], "retry": { "allowed": true, "rule": "No blanket bar in the rules read. A card-not-present merchant that retries a merchant-initiated transaction must weigh this code together with the Merchant Advice Code: 01 means get updated account data first, 02 means wait 24 hours, 03 or 21 means stop (TPR 3.3.1, Table 20, p. 124). Which advice codes may accompany this code is set in the Dual and Single Message System specifications, which are not public to Orca. A declined cardholder-initiated transaction may not come back as a merchant-initiated one, a declined token cryptogram may not be sent again, and a retry must not alter merchant data: it carries the same merchant name, address, acceptor ID and POS condition values, with either the card data the cardholder first gave, a tokenized stored credential, or data updated through the cardholder or the Automatic Billing Updater (TPR 3.3.1, pp. 124 to 125). For a declined deferred card-present authorization outside transit, resubmission needs Merchant Advice Code 02 or another advice code giving a retry period, and a decline value that does not restrict retries; the rules read do not say whether this code restricts retries. Retries then run every 24 hours for up to 13 consecutive days (TPR 2.7.1, p. 54). Transit debt recovery follows the transit table category, not these rules (TPR 4.5.5)." }, "facts": { "return_windows": [ { "action": "resubmit a declined merchant-initiated authorization", "by": "Merchant", "deadline": "Set by the Merchant Advice Code on the decline: 01 update the account data first, 02 wait 24 hours, 03 or 21 never; with no advice code the rules read set no interval (TPR 3.3.1, Table 20)" }, { "action": "resubmit a declined deferred card-present authorization (not transit)", "by": "Merchant", "deadline": "Only when Merchant Advice Code 02 or another code giving a retry period came with the decline and this code does not restrict retries, which the rules read do not settle: no sooner than 24 hours after it, then at most once every 24 hours for up to 13 consecutive days (TPR 2.7.1)" }, { "action": "transit debt recovery after a declined contactless transit aggregated transaction", "by": "Transit merchant and its acquirer", "deadline": "Temporarily Recoverable: at least nine debt recovery attempts, no more than one per 24 hours, within 45 calendar days of first receiving the code, the last by day 45; once they are used up the debt counts as unrecoverable and a first ride risk claim may follow (TPR 4.5.5, Tables 22 and 23)" } ], "applies_to": "All Mastercard regions for Mastercard, Maestro and Cirrus transactions on Mastercard's network; in the EEA, the UK and Gibraltar many of these rules refer to the registered switch the customer chooses; transit categories differ in Australia (TPR Table 24)" }, "caveat": "The transit categories come from the First Ride Risk framework: they cover contactless transit aggregated transactions sent through the Dual Message System by a transit merchant in a country that has adopted the framework, in general only for cards issued in that country, and they are not a general retry rule (TPR 4.5.5, p. 162). Any valid response code missing from Table 23 counts as Unrecoverable. Table 22 still refers to this table as Table 7, a stale internal reference.", "related": [ "mastercard-decline:55", "mastercard-decline:75", "mastercard:messages", "mastercard-decline:91" ], "basis": { "sources": "Transaction Processing Rules, 9 June 2026 edition, sections 3.3.1, 2.7.1, 4.5.4, 4.5.5 Tables 22 and 23, Asia/Pacific Region 4.5.5 Table 24. Label and category read from Table 23 on pp. 163 to 164, with each entry's column fixed from its position on the page; placed Temporarily Recoverable in Table 24 (pp. 175 to 176). Read from a copy downloaded from Mastercard's public rules page on 2026-09-19. Nothing is quoted. Medium: the label, category and retry rules follow from the cited sections, but what makes an issuer send this code is inferred from the label, and the defining specifications are not public to Orca.", "confidence": "medium" }, "currency": { "effective_since": "Before the current edition; start not stated in it", "effective_note": "Label and category as in the 9 June 2026 edition of the Transaction Processing Rules, whose summary of changes says it updated the Table 23 categories and removed past effective dates, so neither when this code's category began nor what it was before is shown. No dated change to this code was found in the edition. Mastercard reissues the manual on no fixed calendar [Inference].", "source_edition": "Transaction Processing Rules, 9 June 2026 edition (https://www.mastercard.com/content/dam/mccom/shared/business/support/rules-pdfs/transaction-processing-rules.pdf)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.mastercard.com/content/dam/mccom/shared/business/support/rules-pdfs/transaction-processing-rules.pdf", "source_class": "authoritative_primary", "source_title": "Transaction Processing Rules, 9 June 2026 edition", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms Mastercard's label for response value 86 and its Table 23 decline value category (Temporarily Recoverable) in Transaction Processing Rules 4.5.5, read by column position on pages 163 to 165, and the Table 24 Australia category on pages 175 to 176; also confirms the merchant-initiated retry framework in rules 3.3.1 and 2.7.1 (the 04, 14, 15, 41, 43 and 54 no-retry bar, the Merchant Advice Code scenarios, and the 24 hour, 13 day deferred card-present resubmission window)." } ] }, "rail_name": "Mastercard Decline Response Codes (partial)", "governing_authority": "Mastercard", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "mastercard-decline:87", "id": "87", "rail": "mastercard-decline", "kind": "reason-code", "name": "Purchase amount only; no cash back allowed", "group": "administrative", "summary": "Partial decline of a purchase with cash back: the purchase is approved but the cash back is not. Issuers that do not offer cash back to some cardholders must be able to send it.", "triggers": [ "A purchase with cash back was requested and the issuer approves only the purchase amount [Inference from Mastercard's label; the defining text is in technical specifications not public to Orca]", "An issuer that chooses not to offer cash back to a cardholder in good standing with enough funds uses 87 where the terminal supports purchase-only approvals (TPR 4.9, issuer item 3, p. 168)" ], "actions": [ "Merchant (merchant-initiated retries): decide whether and when to retry from this code and the Merchant Advice Code together (TPR 3.3.1, p. 124).", "Issuer: must be able to send 87 for an account in good standing with sufficient funds when it does not offer cash back to that cardholder and the terminal can take a purchase-only approval (TPR 4.9, p. 168).", "Merchant: complete the purchase without the cash back, or decline it; support for purchase-only approval is optional for the acquirer (TPR 4.9, acquirer item 4, p. 168).", "Transit merchant: make at least nine debt recovery attempts within 45 days; this is a situation the cardholder may be able to resolve with the issuer (TPR 4.5.5, p. 165)." ], "retry": { "allowed": true, "rule": "No blanket bar in the rules read. A card-not-present merchant that retries a merchant-initiated transaction must weigh this code together with the Merchant Advice Code: 01 means get updated account data first, 02 means wait 24 hours, 03 or 21 means stop (TPR 3.3.1, Table 20, p. 124). Which advice codes may accompany this code is set in the Dual and Single Message System specifications, which are not public to Orca. A declined cardholder-initiated transaction may not come back as a merchant-initiated one, a declined token cryptogram may not be sent again, and a retry must not alter merchant data: it carries the same merchant name, address, acceptor ID and POS condition values, with either the card data the cardholder first gave, a tokenized stored credential, or data updated through the cardholder or the Automatic Billing Updater (TPR 3.3.1, pp. 124 to 125). For a declined deferred card-present authorization outside transit, resubmission needs Merchant Advice Code 02 or another advice code giving a retry period, and a decline value that does not restrict retries; the rules read do not say whether this code restricts retries. Retries then run every 24 hours for up to 13 consecutive days (TPR 2.7.1, p. 54). Transit debt recovery follows the transit table category, not these rules (TPR 4.5.5)." }, "facts": { "return_windows": [ { "action": "resubmit a declined merchant-initiated authorization", "by": "Merchant", "deadline": "Set by the Merchant Advice Code on the decline: 01 update the account data first, 02 wait 24 hours, 03 or 21 never; with no advice code the rules read set no interval (TPR 3.3.1, Table 20)" }, { "action": "resubmit a declined deferred card-present authorization (not transit)", "by": "Merchant", "deadline": "Only when Merchant Advice Code 02 or another code giving a retry period came with the decline and this code does not restrict retries, which the rules read do not settle: no sooner than 24 hours after it, then at most once every 24 hours for up to 13 consecutive days (TPR 2.7.1)" }, { "action": "transit debt recovery after a declined contactless transit aggregated transaction", "by": "Transit merchant and its acquirer", "deadline": "Temporarily Recoverable: at least nine debt recovery attempts, no more than one per 24 hours, within 45 calendar days of first receiving the code, the last by day 45; once they are used up the debt counts as unrecoverable and a first ride risk claim may follow (TPR 4.5.5, Tables 22 and 23)" } ], "applies_to": "All Mastercard regions for Mastercard, Maestro and Cirrus transactions on Mastercard's network; in the EEA, the UK and Gibraltar many of these rules refer to the registered switch the customer chooses; transit categories differ in Australia (TPR Table 24)" }, "caveat": "The transit categories come from the First Ride Risk framework: they cover contactless transit aggregated transactions sent through the Dual Message System by a transit merchant in a country that has adopted the framework, in general only for cards issued in that country, and they are not a general retry rule (TPR 4.5.5, p. 162). Any valid response code missing from Table 23 counts as Unrecoverable. Table 22 still refers to this table as Table 7, a stale internal reference.", "related": [ "mastercard-decline:57", "mastercard:messages" ], "basis": { "sources": "Transaction Processing Rules, 9 June 2026 edition, sections 3.3.1, 2.7.1, 4.5.4, 4.5.5 Tables 22 and 23, Asia/Pacific Region 4.5.5 Table 24, 4.9. Label and category read from Table 23 on pp. 163 to 164, with each entry's column fixed from its position on the page; placed Temporarily Recoverable in Table 24 (pp. 175 to 176). Read from a copy downloaded from Mastercard's public rules page on 2026-09-19. Nothing is quoted. Medium: the label, category and retry rules follow from the cited sections, but what makes an issuer send this code is inferred from the label, and the defining specifications are not public to Orca.", "confidence": "medium" }, "currency": { "effective_since": "Before the current edition; start not stated in it", "effective_note": "Label and category as in the 9 June 2026 edition of the Transaction Processing Rules, whose summary of changes says it updated the Table 23 categories and removed past effective dates, so neither when this code's category began nor what it was before is shown. No dated change to this code was found in the edition. Mastercard reissues the manual on no fixed calendar [Inference].", "source_edition": "Transaction Processing Rules, 9 June 2026 edition (https://www.mastercard.com/content/dam/mccom/shared/business/support/rules-pdfs/transaction-processing-rules.pdf)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.mastercard.com/content/dam/mccom/shared/business/support/rules-pdfs/transaction-processing-rules.pdf", "source_class": "authoritative_primary", "source_title": "Transaction Processing Rules, 9 June 2026 edition", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms Mastercard's label for response value 87 and its Table 23 decline value category (Temporarily Recoverable) in Transaction Processing Rules 4.5.5, read by column position on pages 163 to 165, and the Table 24 Australia category on pages 175 to 176; also confirms the merchant-initiated retry framework in rules 3.3.1 and 2.7.1 (the 04, 14, 15, 41, 43 and 54 no-retry bar, the Merchant Advice Code scenarios, and the 24 hour, 13 day deferred card-present resubmission window) and confirms this is the required response for an issuer that opts an account out of cash back on a purchase-with-cash-back transaction." } ] }, "rail_name": "Mastercard Decline Response Codes (partial)", "governing_authority": "Mastercard", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "mastercard-decline:88", "id": "88", "rail": "mastercard-decline", "kind": "reason-code", "name": "Cryptographic failure", "group": "authorization", "summary": "Decline because a cryptographic check, such as on a chip cryptogram, failed.", "triggers": [ "A cryptographic validation on the request failed [Inference from Mastercard's label; the defining text is in technical specifications not public to Orca]" ], "actions": [ "Merchant (merchant-initiated retries): decide whether and when to retry from this code and the Merchant Advice Code together (TPR 3.3.1, p. 124).", "Transit acquirer: may claim the first ride debt at once with a First Presentment/1240 carrying no approval, up to the country's first ride risk limit (TPR 4.5.5, pp. 163 to 165)." ], "retry": { "allowed": true, "rule": "No blanket bar in the rules read. A card-not-present merchant that retries a merchant-initiated transaction must weigh this code together with the Merchant Advice Code: 01 means get updated account data first, 02 means wait 24 hours, 03 or 21 means stop (TPR 3.3.1, Table 20, p. 124). Which advice codes may accompany this code is set in the Dual and Single Message System specifications, which are not public to Orca. A declined cardholder-initiated transaction may not come back as a merchant-initiated one, a declined token cryptogram may not be sent again, and a retry must not alter merchant data: it carries the same merchant name, address, acceptor ID and POS condition values, with either the card data the cardholder first gave, a tokenized stored credential, or data updated through the cardholder or the Automatic Billing Updater (TPR 3.3.1, pp. 124 to 125). For a declined deferred card-present authorization outside transit, resubmission needs Merchant Advice Code 02 or another advice code giving a retry period, and a decline value that does not restrict retries; the rules read do not say whether this code restricts retries. Retries then run every 24 hours for up to 13 consecutive days (TPR 2.7.1, p. 54). Transit debt recovery follows the transit table category, not these rules (TPR 4.5.5)." }, "facts": { "return_windows": [ { "action": "resubmit a declined merchant-initiated authorization", "by": "Merchant", "deadline": "Set by the Merchant Advice Code on the decline: 01 update the account data first, 02 wait 24 hours, 03 or 21 never; with no advice code the rules read set no interval (TPR 3.3.1, Table 20)" }, { "action": "resubmit a declined deferred card-present authorization (not transit)", "by": "Merchant", "deadline": "Only when Merchant Advice Code 02 or another code giving a retry period came with the decline and this code does not restrict retries, which the rules read do not settle: no sooner than 24 hours after it, then at most once every 24 hours for up to 13 consecutive days (TPR 2.7.1)" }, { "action": "first ride risk claim after a declined contactless transit aggregated transaction", "by": "Transit acquirer", "deadline": "Unrecoverable: may be sent at once, as a First Presentment/1240 with no approval, for no more than the first ride risk limit of the merchant's country (TPR 4.5.5, Tables 22 and 23)" } ], "applies_to": "All Mastercard regions for Mastercard, Maestro and Cirrus transactions on Mastercard's network; in the EEA, the UK and Gibraltar many of these rules refer to the registered switch the customer chooses; transit categories differ in Australia (TPR Table 24)" }, "caveat": "The transit categories come from the First Ride Risk framework: they cover contactless transit aggregated transactions sent through the Dual Message System by a transit merchant in a country that has adopted the framework, in general only for cards issued in that country, and they are not a general retry rule (TPR 4.5.5, p. 162). Any valid response code missing from Table 23 counts as Unrecoverable. Table 22 still refers to this table as Table 7, a stale internal reference.", "related": [ "mastercard-decline:63", "mastercard:messages" ], "basis": { "sources": "Transaction Processing Rules, 9 June 2026 edition, sections 3.3.1, 2.7.1, 4.5.4, 4.5.5 Tables 22 and 23, Asia/Pacific Region 4.5.5 Table 24. Label and category read from Table 23 on pp. 163 to 164, with each entry's column fixed from its position on the page; placed Unrecoverable in Table 24 (pp. 175 to 176). Read from a copy downloaded from Mastercard's public rules page on 2026-09-19. Nothing is quoted. Medium: the label, category and retry rules follow from the cited sections, but what makes an issuer send this code is inferred from the label, and the defining specifications are not public to Orca.", "confidence": "medium" }, "currency": { "effective_since": "Before the current edition; start not stated in it", "effective_note": "Label and category as in the 9 June 2026 edition of the Transaction Processing Rules, whose summary of changes says it updated the Table 23 categories and removed past effective dates, so neither when this code's category began nor what it was before is shown. No dated change to this code was found in the edition. Mastercard reissues the manual on no fixed calendar [Inference].", "source_edition": "Transaction Processing Rules, 9 June 2026 edition (https://www.mastercard.com/content/dam/mccom/shared/business/support/rules-pdfs/transaction-processing-rules.pdf)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.mastercard.com/content/dam/mccom/shared/business/support/rules-pdfs/transaction-processing-rules.pdf", "source_class": "authoritative_primary", "source_title": "Transaction Processing Rules, 9 June 2026 edition", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms Mastercard's label for response value 88 and its Table 23 decline value category (Unrecoverable) in Transaction Processing Rules 4.5.5, read by column position on pages 163 to 165, and the Table 24 Australia category on pages 175 to 176; also confirms the merchant-initiated retry framework in rules 3.3.1 and 2.7.1 (the 04, 14, 15, 41, 43 and 54 no-retry bar, the Merchant Advice Code scenarios, and the 24 hour, 13 day deferred card-present resubmission window)." } ] }, "rail_name": "Mastercard Decline Response Codes (partial)", "governing_authority": "Mastercard", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "mastercard-decline:91", "id": "91", "rail": "mastercard-decline", "kind": "reason-code", "name": "Authorization system or issuer system inoperative", "group": "technical", "summary": "Decline because the issuer's authorization system, or the issuer itself, could not be reached or was not working.", "triggers": [ "The issuer or its authorization system is unavailable [Inference from Mastercard's label; the defining text is in technical specifications not public to Orca]" ], "actions": [ "Merchant (merchant-initiated retries): decide whether and when to retry from this code and the Merchant Advice Code together (TPR 3.3.1, p. 124).", "Transit merchant: make at least nine debt recovery attempts within 45 days; this is a situation the cardholder may be able to resolve with the issuer (TPR 4.5.5, p. 165)." ], "retry": { "allowed": true, "rule": "No blanket bar in the rules read. A card-not-present merchant that retries a merchant-initiated transaction must weigh this code together with the Merchant Advice Code: 01 means get updated account data first, 02 means wait 24 hours, 03 or 21 means stop (TPR 3.3.1, Table 20, p. 124). Which advice codes may accompany this code is set in the Dual and Single Message System specifications, which are not public to Orca. A declined cardholder-initiated transaction may not come back as a merchant-initiated one, a declined token cryptogram may not be sent again, and a retry must not alter merchant data: it carries the same merchant name, address, acceptor ID and POS condition values, with either the card data the cardholder first gave, a tokenized stored credential, or data updated through the cardholder or the Automatic Billing Updater (TPR 3.3.1, pp. 124 to 125). For a declined deferred card-present authorization outside transit, resubmission needs Merchant Advice Code 02 or another advice code giving a retry period, and a decline value that does not restrict retries; the rules read do not say whether this code restricts retries. Retries then run every 24 hours for up to 13 consecutive days (TPR 2.7.1, p. 54). Transit debt recovery follows the transit table category, not these rules (TPR 4.5.5)." }, "facts": { "return_windows": [ { "action": "resubmit a declined merchant-initiated authorization", "by": "Merchant", "deadline": "Set by the Merchant Advice Code on the decline: 01 update the account data first, 02 wait 24 hours, 03 or 21 never; with no advice code the rules read set no interval (TPR 3.3.1, Table 20)" }, { "action": "resubmit a declined deferred card-present authorization (not transit)", "by": "Merchant", "deadline": "Only when Merchant Advice Code 02 or another code giving a retry period came with the decline and this code does not restrict retries, which the rules read do not settle: no sooner than 24 hours after it, then at most once every 24 hours for up to 13 consecutive days (TPR 2.7.1)" }, { "action": "transit debt recovery after a declined contactless transit aggregated transaction", "by": "Transit merchant and its acquirer", "deadline": "Temporarily Recoverable: at least nine debt recovery attempts, no more than one per 24 hours, within 45 calendar days of first receiving the code, the last by day 45; once they are used up the debt counts as unrecoverable and a first ride risk claim may follow (TPR 4.5.5, Tables 22 and 23)" }, { "action": "transit debt recovery or first ride risk claim, Australia", "by": "Transit merchant and its acquirer (Australia)", "deadline": "Table 24 places this code in Recoverable (recover first; claim only after nine failed attempts over 45 days), not the global category (TPR Asia/Pacific Region 4.5.5, pp. 175 to 176)" } ], "applies_to": "All Mastercard regions for Mastercard, Maestro and Cirrus transactions on Mastercard's network; in the EEA, the UK and Gibraltar many of these rules refer to the registered switch the customer chooses; transit categories differ in Australia (TPR Table 24)" }, "caveat": "An issuer's failure rate for Maestro POS and ATM transactions counts declines caused by issuer unavailability, malfunction or time-out; above two percent for two months running is substandard level 1, above three percent level 2 (TPR 2.4.2) [Inference: the rule names reasons in words; that it covers 91 is Orca's reading]. When the issuer does not answer in time the transaction normally goes to Stand-In or the issuer's alternate provider instead (TPR 2.3). The transit categories come from the First Ride Risk framework: they cover contactless transit aggregated transactions sent through the Dual Message System by a transit merchant in a country that has adopted the framework, in general only for cards issued in that country, and they are not a general retry rule (TPR 4.5.5, p. 162). Any valid response code missing from Table 23 counts as Unrecoverable. Table 22 still refers to this table as Table 7, a stale internal reference.", "related": [ "mastercard-decline:96", "mastercard-decline:92", "mastercard:hours", "mastercard:messages" ], "basis": { "sources": "Transaction Processing Rules, 9 June 2026 edition, sections 3.3.1, 2.7.1, 4.5.4, 4.5.5 Tables 22 and 23, Asia/Pacific Region 4.5.5 Table 24, 2.3, 2.4.2. Label and category read from Table 23 on pp. 163 to 164, with each entry's column fixed from its position on the page; placed Recoverable in Table 24 (pp. 175 to 176). Read from a copy downloaded from Mastercard's public rules page on 2026-09-19. Nothing is quoted. Medium: the label, category and retry rules follow from the cited sections, but what makes an issuer send this code is inferred from the label, and the defining specifications are not public to Orca.", "confidence": "medium" }, "currency": { "effective_since": "Before the current edition; start not stated in it", "effective_note": "Label and category as in the 9 June 2026 edition of the Transaction Processing Rules, whose summary of changes says it updated the Table 23 categories and removed past effective dates, so neither when this code's category began nor what it was before is shown. No dated change to this code was found in the edition. Mastercard reissues the manual on no fixed calendar [Inference].", "source_edition": "Transaction Processing Rules, 9 June 2026 edition (https://www.mastercard.com/content/dam/mccom/shared/business/support/rules-pdfs/transaction-processing-rules.pdf)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.mastercard.com/content/dam/mccom/shared/business/support/rules-pdfs/transaction-processing-rules.pdf", "source_class": "authoritative_primary", "source_title": "Transaction Processing Rules, 9 June 2026 edition", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms Mastercard's label for response value 91 and its Table 23 decline value category (Temporarily Recoverable) in Transaction Processing Rules 4.5.5, read by column position on pages 163 to 165, and the Table 24 Australia category on pages 175 to 176; also confirms the merchant-initiated retry framework in rules 3.3.1 and 2.7.1 (the 04, 14, 15, 41, 43 and 54 no-retry bar, the Merchant Advice Code scenarios, and the 24 hour, 13 day deferred card-present resubmission window)." } ] }, "rail_name": "Mastercard Decline Response Codes (partial)", "governing_authority": "Mastercard", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "mastercard-decline:92", "id": "92", "rail": "mastercard-decline", "kind": "reason-code", "name": "Unable to route transaction", "group": "technical", "summary": "Decline because the network could not route the request to the issuer.", "triggers": [ "The request could not be routed to a destination [Inference from Mastercard's label; the defining text is in technical specifications not public to Orca]" ], "actions": [ "Merchant (merchant-initiated retries): decide whether and when to retry from this code and the Merchant Advice Code together (TPR 3.3.1, p. 124).", "Transit merchant: bears the debt; no first ride risk claim is allowed (TPR 4.5.5, pp. 163 to 165)." ], "retry": { "allowed": true, "rule": "No blanket bar in the rules read. A card-not-present merchant that retries a merchant-initiated transaction must weigh this code together with the Merchant Advice Code: 01 means get updated account data first, 02 means wait 24 hours, 03 or 21 means stop (TPR 3.3.1, Table 20, p. 124). Which advice codes may accompany this code is set in the Dual and Single Message System specifications, which are not public to Orca. A declined cardholder-initiated transaction may not come back as a merchant-initiated one, a declined token cryptogram may not be sent again, and a retry must not alter merchant data: it carries the same merchant name, address, acceptor ID and POS condition values, with either the card data the cardholder first gave, a tokenized stored credential, or data updated through the cardholder or the Automatic Billing Updater (TPR 3.3.1, pp. 124 to 125). For a declined deferred card-present authorization outside transit, resubmission needs Merchant Advice Code 02 or another advice code giving a retry period, and a decline value that does not restrict retries; the rules read do not say whether this code restricts retries. Retries then run every 24 hours for up to 13 consecutive days (TPR 2.7.1, p. 54). Transit debt recovery follows the transit table category, not these rules (TPR 4.5.5)." }, "facts": { "return_windows": [ { "action": "resubmit a declined merchant-initiated authorization", "by": "Merchant", "deadline": "Set by the Merchant Advice Code on the decline: 01 update the account data first, 02 wait 24 hours, 03 or 21 never; with no advice code the rules read set no interval (TPR 3.3.1, Table 20)" }, { "action": "resubmit a declined deferred card-present authorization (not transit)", "by": "Merchant", "deadline": "Only when Merchant Advice Code 02 or another code giving a retry period came with the decline and this code does not restrict retries, which the rules read do not settle: no sooner than 24 hours after it, then at most once every 24 hours for up to 13 consecutive days (TPR 2.7.1)" }, { "action": "first ride risk claim after a declined contactless transit aggregated transaction", "by": "Transit acquirer", "deadline": "Never: Not Claimable (TPR 4.5.5, Table 23)" } ], "applies_to": "All Mastercard regions for Mastercard, Maestro and Cirrus transactions on Mastercard's network; in the EEA, the UK and Gibraltar many of these rules refer to the registered switch the customer chooses; transit categories differ in Australia (TPR Table 24)" }, "caveat": "The transit categories come from the First Ride Risk framework: they cover contactless transit aggregated transactions sent through the Dual Message System by a transit merchant in a country that has adopted the framework, in general only for cards issued in that country, and they are not a general retry rule (TPR 4.5.5, p. 162). Any valid response code missing from Table 23 counts as Unrecoverable. Table 22 still refers to this table as Table 7, a stale internal reference.", "related": [ "mastercard-decline:91", "mastercard-decline:96", "mastercard:messages" ], "basis": { "sources": "Transaction Processing Rules, 9 June 2026 edition, sections 3.3.1, 2.7.1, 4.5.4, 4.5.5 Tables 22 and 23, Asia/Pacific Region 4.5.5 Table 24. Label and category read from Table 23 on pp. 163 to 164, with each entry's column fixed from its position on the page; placed Not Claimable in Table 24 (pp. 175 to 176). Read from a copy downloaded from Mastercard's public rules page on 2026-09-19. Nothing is quoted. Medium: the label, category and retry rules follow from the cited sections, but what makes an issuer send this code is inferred from the label, and the defining specifications are not public to Orca.", "confidence": "medium" }, "currency": { "effective_since": "Before the current edition; start not stated in it", "effective_note": "Label and category as in the 9 June 2026 edition of the Transaction Processing Rules, whose summary of changes says it updated the Table 23 categories and removed past effective dates, so neither when this code's category began nor what it was before is shown. No dated change to this code was found in the edition. Mastercard reissues the manual on no fixed calendar [Inference].", "source_edition": "Transaction Processing Rules, 9 June 2026 edition (https://www.mastercard.com/content/dam/mccom/shared/business/support/rules-pdfs/transaction-processing-rules.pdf)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.mastercard.com/content/dam/mccom/shared/business/support/rules-pdfs/transaction-processing-rules.pdf", "source_class": "authoritative_primary", "source_title": "Transaction Processing Rules, 9 June 2026 edition", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms Mastercard's label for response value 92 and its Table 23 decline value category (Not Claimable) in Transaction Processing Rules 4.5.5, read by column position on pages 163 to 165, and the Table 24 Australia category on pages 175 to 176; also confirms the merchant-initiated retry framework in rules 3.3.1 and 2.7.1 (the 04, 14, 15, 41, 43 and 54 no-retry bar, the Merchant Advice Code scenarios, and the 24 hour, 13 day deferred card-present resubmission window)." } ] }, "rail_name": "Mastercard Decline Response Codes (partial)", "governing_authority": "Mastercard", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "mastercard-decline:94", "id": "94", "rail": "mastercard-decline", "kind": "reason-code", "name": "Duplicate transmission detected", "group": "technical", "summary": "Decline because the request duplicates one already received.", "triggers": [ "A duplicate of an earlier transmission was detected [Inference from Mastercard's label; the defining text is in technical specifications not public to Orca]" ], "actions": [ "Merchant (merchant-initiated retries): decide whether and when to retry from this code and the Merchant Advice Code together (TPR 3.3.1, p. 124).", "Transit merchant: bears the debt; no first ride risk claim is allowed (TPR 4.5.5, pp. 163 to 165)." ], "retry": { "allowed": true, "rule": "No blanket bar in the rules read. A card-not-present merchant that retries a merchant-initiated transaction must weigh this code together with the Merchant Advice Code: 01 means get updated account data first, 02 means wait 24 hours, 03 or 21 means stop (TPR 3.3.1, Table 20, p. 124). Which advice codes may accompany this code is set in the Dual and Single Message System specifications, which are not public to Orca. A declined cardholder-initiated transaction may not come back as a merchant-initiated one, a declined token cryptogram may not be sent again, and a retry must not alter merchant data: it carries the same merchant name, address, acceptor ID and POS condition values, with either the card data the cardholder first gave, a tokenized stored credential, or data updated through the cardholder or the Automatic Billing Updater (TPR 3.3.1, pp. 124 to 125). For a declined deferred card-present authorization outside transit, resubmission needs Merchant Advice Code 02 or another advice code giving a retry period, and a decline value that does not restrict retries; the rules read do not say whether this code restricts retries. Retries then run every 24 hours for up to 13 consecutive days (TPR 2.7.1, p. 54). Transit debt recovery follows the transit table category, not these rules (TPR 4.5.5)." }, "facts": { "return_windows": [ { "action": "resubmit a declined merchant-initiated authorization", "by": "Merchant", "deadline": "Set by the Merchant Advice Code on the decline: 01 update the account data first, 02 wait 24 hours, 03 or 21 never; with no advice code the rules read set no interval (TPR 3.3.1, Table 20)" }, { "action": "resubmit a declined deferred card-present authorization (not transit)", "by": "Merchant", "deadline": "Only when Merchant Advice Code 02 or another code giving a retry period came with the decline and this code does not restrict retries, which the rules read do not settle: no sooner than 24 hours after it, then at most once every 24 hours for up to 13 consecutive days (TPR 2.7.1)" }, { "action": "first ride risk claim after a declined contactless transit aggregated transaction", "by": "Transit acquirer", "deadline": "Never: Not Claimable (TPR 4.5.5, Table 23)" } ], "applies_to": "All Mastercard regions for Mastercard, Maestro and Cirrus transactions on Mastercard's network; in the EEA, the UK and Gibraltar many of these rules refer to the registered switch the customer chooses; transit categories differ in Australia (TPR Table 24)" }, "caveat": "The transit categories come from the First Ride Risk framework: they cover contactless transit aggregated transactions sent through the Dual Message System by a transit merchant in a country that has adopted the framework, in general only for cards issued in that country, and they are not a general retry rule (TPR 4.5.5, p. 162). Any valid response code missing from Table 23 counts as Unrecoverable. Table 22 still refers to this table as Table 7, a stale internal reference.", "related": [ "mastercard-decline:92", "mastercard-decline:96", "mastercard:messages" ], "basis": { "sources": "Transaction Processing Rules, 9 June 2026 edition, sections 3.3.1, 2.7.1, 4.5.4, 4.5.5 Tables 22 and 23, Asia/Pacific Region 4.5.5 Table 24. Label and category read from Table 23 on pp. 163 to 164, with each entry's column fixed from its position on the page; placed Not Claimable in Table 24 (pp. 175 to 176). Read from a copy downloaded from Mastercard's public rules page on 2026-09-19. Nothing is quoted. Medium: the label, category and retry rules follow from the cited sections, but what makes an issuer send this code is inferred from the label, and the defining specifications are not public to Orca.", "confidence": "medium" }, "currency": { "effective_since": "Before the current edition; start not stated in it", "effective_note": "Label and category as in the 9 June 2026 edition of the Transaction Processing Rules, whose summary of changes says it updated the Table 23 categories and removed past effective dates, so neither when this code's category began nor what it was before is shown. No dated change to this code was found in the edition. Mastercard reissues the manual on no fixed calendar [Inference].", "source_edition": "Transaction Processing Rules, 9 June 2026 edition (https://www.mastercard.com/content/dam/mccom/shared/business/support/rules-pdfs/transaction-processing-rules.pdf)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.mastercard.com/content/dam/mccom/shared/business/support/rules-pdfs/transaction-processing-rules.pdf", "source_class": "authoritative_primary", "source_title": "Transaction Processing Rules, 9 June 2026 edition", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms Mastercard's label for response value 94 and its Table 23 decline value category (Not Claimable) in Transaction Processing Rules 4.5.5, read by column position on pages 163 to 165, and the Table 24 Australia category on pages 175 to 176; also confirms the merchant-initiated retry framework in rules 3.3.1 and 2.7.1 (the 04, 14, 15, 41, 43 and 54 no-retry bar, the Merchant Advice Code scenarios, and the 24 hour, 13 day deferred card-present resubmission window)." } ] }, "rail_name": "Mastercard Decline Response Codes (partial)", "governing_authority": "Mastercard", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "mastercard-decline:96", "id": "96", "rail": "mastercard-decline", "kind": "reason-code", "name": "System error", "group": "technical", "summary": "Decline because of a system error. Transit merchants cannot claim debt after it outside Australia, and Europe counts it in the issuer failure rate.", "triggers": [ "A system malfunction prevented a normal answer [Inference from Mastercard's label; the defining text is in technical specifications not public to Orca]" ], "actions": [ "Merchant (merchant-initiated retries): decide whether and when to retry from this code and the Merchant Advice Code together (TPR 3.3.1, p. 124).", "Transit merchant: bears the debt; no first ride risk claim is allowed (TPR 4.5.5, pp. 163 to 165)." ], "retry": { "allowed": true, "rule": "No blanket bar in the rules read. A card-not-present merchant that retries a merchant-initiated transaction must weigh this code together with the Merchant Advice Code: 01 means get updated account data first, 02 means wait 24 hours, 03 or 21 means stop (TPR 3.3.1, Table 20, p. 124). Which advice codes may accompany this code is set in the Dual and Single Message System specifications, which are not public to Orca. A declined cardholder-initiated transaction may not come back as a merchant-initiated one, a declined token cryptogram may not be sent again, and a retry must not alter merchant data: it carries the same merchant name, address, acceptor ID and POS condition values, with either the card data the cardholder first gave, a tokenized stored credential, or data updated through the cardholder or the Automatic Billing Updater (TPR 3.3.1, pp. 124 to 125). For a declined deferred card-present authorization outside transit, resubmission needs Merchant Advice Code 02 or another advice code giving a retry period, and a decline value that does not restrict retries; the rules read do not say whether this code restricts retries. Retries then run every 24 hours for up to 13 consecutive days (TPR 2.7.1, p. 54). Transit debt recovery follows the transit table category, not these rules (TPR 4.5.5)." }, "facts": { "return_windows": [ { "action": "resubmit a declined merchant-initiated authorization", "by": "Merchant", "deadline": "Set by the Merchant Advice Code on the decline: 01 update the account data first, 02 wait 24 hours, 03 or 21 never; with no advice code the rules read set no interval (TPR 3.3.1, Table 20)" }, { "action": "resubmit a declined deferred card-present authorization (not transit)", "by": "Merchant", "deadline": "Only when Merchant Advice Code 02 or another code giving a retry period came with the decline and this code does not restrict retries, which the rules read do not settle: no sooner than 24 hours after it, then at most once every 24 hours for up to 13 consecutive days (TPR 2.7.1)" }, { "action": "first ride risk claim after a declined contactless transit aggregated transaction", "by": "Transit acquirer", "deadline": "Never: Not Claimable (TPR 4.5.5, Table 23)" }, { "action": "transit debt recovery or first ride risk claim, Australia", "by": "Transit merchant and its acquirer (Australia)", "deadline": "Table 24 places this code in Recoverable (recover first; claim only after nine failed attempts over 45 days), not the global category (TPR Asia/Pacific Region 4.5.5, pp. 175 to 176)" } ], "applies_to": "All Mastercard regions for Mastercard, Maestro and Cirrus transactions on Mastercard's network; in the EEA, the UK and Gibraltar many of these rules refer to the registered switch the customer chooses; transit categories differ in Australia (TPR Table 24)" }, "caveat": "Europe Region: the issuer failure rate adds codes 31, 82 and 96 and divides by all transactions; above one percent in two months of any six is substandard (TPR Europe Region 2.4.2, p. 89). The transit categories come from the First Ride Risk framework: they cover contactless transit aggregated transactions sent through the Dual Message System by a transit merchant in a country that has adopted the framework, in general only for cards issued in that country, and they are not a general retry rule (TPR 4.5.5, p. 162). Any valid response code missing from Table 23 counts as Unrecoverable. Table 22 still refers to this table as Table 7, a stale internal reference.", "related": [ "mastercard-decline:91", "mastercard-decline:92", "mastercard-decline:94", "mastercard:messages" ], "basis": { "sources": "Transaction Processing Rules, 9 June 2026 edition, sections 3.3.1, 2.7.1, 4.5.4, 4.5.5 Tables 22 and 23, Asia/Pacific Region 4.5.5 Table 24, 2.4.2, Europe Region 2.4.2. Label and category read from Table 23 on pp. 163 to 164, with each entry's column fixed from its position on the page; placed Recoverable in Table 24 (pp. 175 to 176). Read from a copy downloaded from Mastercard's public rules page on 2026-09-19. Nothing is quoted. Medium: the label, category and retry rules follow from the cited sections, but what makes an issuer send this code is inferred from the label, and the defining specifications are not public to Orca.", "confidence": "medium" }, "currency": { "effective_since": "Before the current edition; start not stated in it", "effective_note": "Label and category as in the 9 June 2026 edition of the Transaction Processing Rules, whose summary of changes says it updated the Table 23 categories and removed past effective dates, so neither when this code's category began nor what it was before is shown. No dated change to this code was found in the edition. Mastercard reissues the manual on no fixed calendar [Inference].", "source_edition": "Transaction Processing Rules, 9 June 2026 edition (https://www.mastercard.com/content/dam/mccom/shared/business/support/rules-pdfs/transaction-processing-rules.pdf)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.mastercard.com/content/dam/mccom/shared/business/support/rules-pdfs/transaction-processing-rules.pdf", "source_class": "authoritative_primary", "source_title": "Transaction Processing Rules, 9 June 2026 edition", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms Mastercard's label for response value 96 and its Table 23 decline value category (Not Claimable in this edition, moved from Temporarily Recoverable) in Transaction Processing Rules 4.5.5, read by column position on pages 163 to 165, and the Table 24 Australia category on pages 175 to 176; also confirms the merchant-initiated retry framework in rules 3.3.1 and 2.7.1 (the 04, 14, 15, 41, 43 and 54 no-retry bar, the Merchant Advice Code scenarios, and the 24 hour, 13 day deferred card-present resubmission window)." } ] }, "rail_name": "Mastercard Decline Response Codes (partial)", "governing_authority": "Mastercard", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "nct-inst:AB05", "id": "AB05", "rail": "nct-inst", "kind": "reason-code", "name": "Time-out at the Beneficiary PSP", "group": "technical", "summary": "The Beneficiary PSP turns the transaction away because it arrived after the scheme time-out (or a shorter agreed one). Nothing was credited and nothing settled.", "triggers": [ "The initial NCT Inst transaction reaches the Beneficiary PSP only after the time-out deadline has passed", "Any delay in connection, processing or validation between the Originator PSP, the CSMs and the Beneficiary PSP" ], "actions": [ "Originator PSP: lift the reservation on the Originator's account and tell the Originator at once", "Originator PSP: propose a later attempt, or another instrument such as the NPC's non-instant NCT", "Originator: agree another way to pay with the Beneficiary if instant keeps failing" ], "retry": { "allowed": true, "rule": "Nothing settled, so nothing is re-presented. The Originator may start a new NCT Inst instruction once the cause is dealt with. The scheme sets no retry limit [Unverified]. The guidance itself suggests trying again later." }, "facts": { "return_windows": [ { "action": "reject (negative confirmation)", "by": "Beneficiary PSP", "deadline": "Instantly. Its negative confirmation must reach its CSM within 7 seconds of the Originator PSP's Time Stamp (or a shorter agreed time-out), and the answer must reach the Originator PSP by the 9th second; the target for any answer at the Originator PSP is 5 seconds" } ], "applies_to": "NCT Inst, in any NPC Scheme Currency" }, "caveat": "Towards the Originator PSP the time-out is reported as AB05 or AB06; TM01 is kept for the leg between the Beneficiary PSP and its CSM (NPC012-01 2025 v1.1 section 2.2.1 A; NPC020-01 v3.1, TM01). If no confirmation of any kind reaches the Originator PSP within 10 seconds, it keeps the reservation and settlement certainty and may start a status investigation; it may not treat the payment as failed until a negative confirmation arrives (NPC010-01 2025 v1.1 section 4.2.3 D).", "related": [ "nct-inst:AB06", "nct-inst:TM01", "nct-inst:AG09" ], "basis": { "sources": "NPC020-01 v3.1 section 3, AB05; NPC010-01 2025 v1.1 sections 4.2.3 B to D (5-second target, 7-second time-out, 9th-second relay, no unilateral reject by the Originator side) and 4.3.2.1 (CT-01.05R, CT-01.06R, CT-01.08R); NPC010-01 2025 v1.1 section 4.6.1 AT-R002 and AT-R004 (who may reject, and the reasons open to each); NPC012-01 2025 v1.1 section 2.2.2 (pacs.002 reject reason codes) and 2.2.1 A (TM01 not sent to the Originator PSP).", "confidence": "high" }, "currency": { "effective_since": "2025-11-21", "effective_note": "NPC010-01 2025 v1.1 and NPC012-01 2025 v1.1 were issued and took effect on 2025-11-21; the 2025 rulebook first took effect on 2025-10-05 as v1.0. NPC020-01 v3.1 was published and took effect on 2026-07-03 as a clarification and correction release and states that it applies to the rulebook effective 5 October 2025. The NPC plans to publish the 2027 rulebook in November 2026 [Unverified: its effective date].", "source_edition": "NPC020-01 v3.1; NPC010-01 2025 v1.1; NPC012-01 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.nordicpaymentscouncil.org/media/bjfjylnq/guidance-on-reason-codes-for-nct-inst-r-transaction-v31.pdf", "source_class": "authoritative_primary", "source_title": "NPC020-01 Guidance on Reason Codes for NCT Inst R-transactions v3.1; NPC010-01 NCT Instant Rulebook 2025 v1.1; NPC012-01 NCT Inst Inter-PSP Implementation Guidelines 2025 v1.1", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the name and ISO meaning, timeout at the Creditor Agent, and the reject classification against NPC020-01 v3.1 section 3, AB05. Confirms the reject window, the 5 second target, the 7 second hard time out and the 9th second relay to the Originator PSP, against NPC010-01 2025 v1.1 section 4.2.3. Confirms that AB05 or AB06 go to the Originator PSP while TM01 is kept for the Beneficiary PSP to CSM leg, against NPC012-01 2025 v1.1 section 2.2.1 A. Confirms the Beneficiary PSP as the sender against the rulebook reject reason table in section 4.6.1, attribute AT-R004." } ] }, "rail_name": "Nordic Credit Transfer Instant (NCT Inst)", "governing_authority": "Nordic Payments Council", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "nct-inst:AB06", "id": "AB06", "rail": "nct-inst", "kind": "reason-code", "name": "Time-out at a CSM (instructed agent)", "group": "technical", "summary": "A CSM stops the transaction on time-out: either it received the payment too late, or, as the Beneficiary PSP's CSM, it heard nothing back from the Beneficiary PSP before the deadline.", "triggers": [ "The Beneficiary PSP's CSM gets no confirmation at all from the Beneficiary PSP before the time-out deadline", "A CSM between the two PSPs receives the initial transaction only after the time-out deadline (or a shorter agreed one)", "Connection, processing or validation trouble anywhere on the path to the Beneficiary PSP and back to its CSM" ], "actions": [ "Originator PSP: lift the reservation and tell the Originator at once", "Originator PSP: propose a later attempt, or another instrument such as NCT", "Originator: settle with the Beneficiary another way if the problem persists" ], "retry": { "allowed": true, "rule": "Nothing settled, so nothing is re-presented. The Originator may start a new NCT Inst instruction once the cause is dealt with. The scheme sets no retry limit [Unverified]." }, "facts": { "return_windows": [ { "action": "reject (negative confirmation) on time-out", "by": "CSM of the Beneficiary PSP, or another CSM on the path", "deadline": "Instantly once 7 seconds from the Time Stamp pass without a confirmation from the Beneficiary PSP (or a shorter agreed time-out); the Beneficiary PSP's CSM sends the reject to the Beneficiary PSP as well, and it must reach the Originator PSP by the 9th second" } ], "applies_to": "NCT Inst, in any NPC Scheme Currency" }, "caveat": "Neither the Originator PSP nor its CSM may reject on its own after the time-out; they must wait for a confirmation from the Beneficiary PSP's side (NPC010-01 2025 v1.1 section 4.2.3 C). When the Beneficiary PSP gets this reject from its CSM it must not credit the Beneficiary [Inference from section 4.2.3 B and C].", "related": [ "nct-inst:AB05", "nct-inst:TM01", "nct-inst:AB10" ], "basis": { "sources": "NPC020-01 v3.1 section 3, AB06; NPC010-01 2025 v1.1 sections 4.2.3 B to D (5-second target, 7-second time-out, 9th-second relay, no unilateral reject by the Originator side) and 4.3.2.1 (CT-01.05R, CT-01.06R, CT-01.08R); NPC010-01 2025 v1.1 section 4.6.1 AT-R002 and AT-R004 (who may reject, and the reasons open to each); NPC012-01 2025 v1.1 section 2.2.2 (pacs.002 reject reason codes).", "confidence": "high" }, "currency": { "effective_since": "2025-11-21", "effective_note": "NPC010-01 2025 v1.1 and NPC012-01 2025 v1.1 were issued and took effect on 2025-11-21; the 2025 rulebook first took effect on 2025-10-05 as v1.0. NPC020-01 v3.1 was published and took effect on 2026-07-03 as a clarification and correction release and states that it applies to the rulebook effective 5 October 2025. The NPC plans to publish the 2027 rulebook in November 2026 [Unverified: its effective date].", "source_edition": "NPC020-01 v3.1; NPC010-01 2025 v1.1; NPC012-01 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.nordicpaymentscouncil.org/media/bjfjylnq/guidance-on-reason-codes-for-nct-inst-r-transaction-v31.pdf", "source_class": "authoritative_primary", "source_title": "NPC020-01 Guidance on Reason Codes for NCT Inst R-transactions v3.1; NPC010-01 NCT Instant Rulebook 2025 v1.1; NPC012-01 NCT Inst Inter-PSP Implementation Guidelines 2025 v1.1", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the name and ISO meaning, timeout at the Instructed Agent, and the reject classification against NPC020-01 v3.1 section 3, AB06. Confirms the reject window against NPC010-01 2025 v1.1 section 4.2.3, including that the Originator side cannot reject unilaterally before a confirmation arrives. Confirms a CSM as the sender against the rulebook reject reason table in section 4.6.1, attribute AT-R004." } ] }, "rail_name": "Nordic Credit Transfer Instant (NCT Inst)", "governing_authority": "Nordic Payments Council", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "nct-inst:AB07", "id": "AB07", "rail": "nct-inst", "kind": "reason-code", "name": "Agent offline", "group": "technical", "summary": "Some agent on the path is not reachable and it cannot be told which one. The guidance ties it to a CSM whose connection cannot carry any NCT Inst message.", "triggers": [ "A CSM between the Originator PSP and the Beneficiary PSP has no working connection for scheme messages of any kind", "The failing party on the path cannot be pinned down" ], "actions": [ "Originator PSP: propose a later attempt, or another instrument such as NCT", "Originator: agree another way to pay with the Beneficiary" ], "retry": { "allowed": true, "rule": "Nothing settled, so nothing is re-presented. The Originator may start a new NCT Inst instruction once the cause is dealt with. The scheme sets no retry limit [Unverified]." }, "facts": { "return_windows": [ { "action": "reject (negative confirmation)", "by": "CSM", "deadline": "Instantly, inside the execution time: the target for any answer at the Originator PSP is 5 seconds from its Time Stamp, and an answer after the 7-second time-out must reach it by the 9th second" } ], "applies_to": "NCT Inst, in any NPC Scheme Currency" }, "caveat": "Where the Beneficiary PSP itself is known to be offline, AB08 is the more precise code. The rulebook's list of reject reasons (section 4.6.1 AT-R004) has no reason that plainly matches this code [Inference from reading the list].", "related": [ "nct-inst:AB08", "nct-inst:AG10" ], "basis": { "sources": "NPC020-01 v3.1 section 3, AB07; NPC012-01 2025 v1.1 section 2.2.2 (pacs.002 reject reason codes); NPC010-01 2025 v1.1 sections 4.2.3 B to D (5-second target, 7-second time-out, 9th-second relay, no unilateral reject by the Originator side) and 4.3.2.1 (CT-01.05R, CT-01.06R, CT-01.08R); NPC010-01 2025 v1.1 section 4.6.1 AT-R002 and AT-R004 (who may reject, and the reasons open to each).", "confidence": "high" }, "currency": { "effective_since": "2025-11-21", "effective_note": "NPC010-01 2025 v1.1 and NPC012-01 2025 v1.1 were issued and took effect on 2025-11-21; the 2025 rulebook first took effect on 2025-10-05 as v1.0. NPC020-01 v3.1 was published and took effect on 2026-07-03 as a clarification and correction release and states that it applies to the rulebook effective 5 October 2025. The NPC plans to publish the 2027 rulebook in November 2026 [Unverified: its effective date].", "source_edition": "NPC020-01 v3.1; NPC010-01 2025 v1.1; NPC012-01 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.nordicpaymentscouncil.org/media/bjfjylnq/guidance-on-reason-codes-for-nct-inst-r-transaction-v31.pdf", "source_class": "authoritative_primary", "source_title": "NPC020-01 Guidance on Reason Codes for NCT Inst R-transactions v3.1; NPC010-01 NCT Instant Rulebook 2025 v1.1; NPC012-01 NCT Inst Inter-PSP Implementation Guidelines 2025 v1.1", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the name and ISO meaning, an unidentifiable offline agent, and the reject classification against NPC020-01 v3.1 section 3, AB07. Confirms the reject window against NPC010-01 2025 v1.1 section 4.2.3. Confirms that no reason in the rulebook's reject reason table, section 4.6.1 AT-R004, plainly matches this code, so the record is right to leave the sender as inference." } ] }, "rail_name": "Nordic Credit Transfer Instant (NCT Inst)", "governing_authority": "Nordic Payments Council", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "nct-inst:AB08", "id": "AB08", "rail": "nct-inst", "kind": "reason-code", "name": "Beneficiary PSP offline", "group": "technical", "summary": "The Beneficiary PSP is unreachable, with its link down for NCT Inst messages both inbound and outbound.", "triggers": [ "No scheme message of any kind can get through to or from the Beneficiary PSP" ], "actions": [ "Originator PSP: propose a later attempt, or another instrument such as NCT", "Originator: agree another way to pay with the Beneficiary" ], "retry": { "allowed": true, "rule": "Nothing settled, so nothing is re-presented. The Originator may start a new NCT Inst instruction once the cause is dealt with. The scheme sets no retry limit [Unverified]." }, "facts": { "return_windows": [ { "action": "reject (negative confirmation)", "by": "CSM", "deadline": "Instantly, inside the execution time: the target for any answer at the Originator PSP is 5 seconds from its Time Stamp, and an answer after the 7-second time-out must reach it by the 9th second" } ], "applies_to": "NCT Inst, in any NPC Scheme Currency" }, "caveat": "Since the Beneficiary PSP is unreachable, the reject in practice comes from a CSM [Inference: the guidance does not name the sender]. The rulebook's list of reject reasons (section 4.6.1 AT-R004) has no reason that plainly matches this code [Inference from reading the list].", "related": [ "nct-inst:AB07", "nct-inst:AB09", "nct-inst:AG11" ], "basis": { "sources": "NPC020-01 v3.1 section 3, AB08; NPC012-01 2025 v1.1 section 2.2.2 (pacs.002 reject reason codes); NPC010-01 2025 v1.1 sections 4.2.3 B to D (5-second target, 7-second time-out, 9th-second relay, no unilateral reject by the Originator side) and 4.3.2.1 (CT-01.05R, CT-01.06R, CT-01.08R); NPC010-01 2025 v1.1 section 4.6.1 AT-R002 and AT-R004 (who may reject, and the reasons open to each).", "confidence": "high" }, "currency": { "effective_since": "2025-11-21", "effective_note": "NPC010-01 2025 v1.1 and NPC012-01 2025 v1.1 were issued and took effect on 2025-11-21; the 2025 rulebook first took effect on 2025-10-05 as v1.0. NPC020-01 v3.1 was published and took effect on 2026-07-03 as a clarification and correction release and states that it applies to the rulebook effective 5 October 2025. The NPC plans to publish the 2027 rulebook in November 2026 [Unverified: its effective date].", "source_edition": "NPC020-01 v3.1; NPC010-01 2025 v1.1; NPC012-01 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.nordicpaymentscouncil.org/media/bjfjylnq/guidance-on-reason-codes-for-nct-inst-r-transaction-v31.pdf", "source_class": "authoritative_primary", "source_title": "NPC020-01 Guidance on Reason Codes for NCT Inst R-transactions v3.1; NPC010-01 NCT Instant Rulebook 2025 v1.1; NPC012-01 NCT Inst Inter-PSP Implementation Guidelines 2025 v1.1", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the name and ISO meaning, Beneficiary PSP unreachable, and the reject classification against NPC020-01 v3.1 section 3, AB08. Confirms the reject window against NPC010-01 2025 v1.1 section 4.2.3. Confirms that no reason in the rulebook's reject reason table, section 4.6.1 AT-R004, plainly matches this code, so the record is right to treat a CSM sender as inference." } ] }, "rail_name": "Nordic Credit Transfer Instant (NCT Inst)", "governing_authority": "Nordic Payments Council", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "nct-inst:AB09", "id": "AB09", "rail": "nct-inst", "kind": "reason-code", "name": "Error at the Beneficiary PSP", "group": "technical", "summary": "Processing broke off because of a fault at the Beneficiary PSP, typically because part of its NCT Inst service is down.", "triggers": [ "Part or all of the Beneficiary PSP's NCT Inst service is unavailable and the transaction aborts there" ], "actions": [ "Originator: agree another way to pay with the Beneficiary", "Originator PSP: suggest sending again or using another payment instrument" ], "retry": { "allowed": true, "rule": "Nothing settled, so nothing is re-presented. The Originator may start a new NCT Inst instruction once the cause is dealt with. The scheme sets no retry limit [Unverified]. The guidance names resubmission as one option." }, "facts": { "return_windows": [ { "action": "reject (negative confirmation)", "by": "Beneficiary PSP", "deadline": "Instantly. Its negative confirmation must reach its CSM within 7 seconds of the Originator PSP's Time Stamp (or a shorter agreed time-out), and the answer must reach the Originator PSP by the 9th second; the target for any answer at the Originator PSP is 5 seconds" } ], "applies_to": "NCT Inst, in any NPC Scheme Currency" }, "caveat": "The rulebook's list of reject reasons (section 4.6.1 AT-R004) has no reason that plainly matches this code [Inference from reading the list]. Whether the Beneficiary PSP or its CSM sends the reject is not stated in the guidance [Inference: the Beneficiary PSP, if it can still answer].", "related": [ "nct-inst:AB08", "nct-inst:AB10" ], "basis": { "sources": "NPC020-01 v3.1 section 3, AB09; NPC012-01 2025 v1.1 section 2.2.2 (pacs.002 reject reason codes); NPC010-01 2025 v1.1 sections 4.2.3 B to D (5-second target, 7-second time-out, 9th-second relay, no unilateral reject by the Originator side) and 4.3.2.1 (CT-01.05R, CT-01.06R, CT-01.08R); NPC010-01 2025 v1.1 section 4.6.1 AT-R002 and AT-R004 (who may reject, and the reasons open to each).", "confidence": "high" }, "currency": { "effective_since": "2025-11-21", "effective_note": "NPC010-01 2025 v1.1 and NPC012-01 2025 v1.1 were issued and took effect on 2025-11-21; the 2025 rulebook first took effect on 2025-10-05 as v1.0. NPC020-01 v3.1 was published and took effect on 2026-07-03 as a clarification and correction release and states that it applies to the rulebook effective 5 October 2025. The NPC plans to publish the 2027 rulebook in November 2026 [Unverified: its effective date].", "source_edition": "NPC020-01 v3.1; NPC010-01 2025 v1.1; NPC012-01 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.nordicpaymentscouncil.org/media/bjfjylnq/guidance-on-reason-codes-for-nct-inst-r-transaction-v31.pdf", "source_class": "authoritative_primary", "source_title": "NPC020-01 Guidance on Reason Codes for NCT Inst R-transactions v3.1; NPC010-01 NCT Instant Rulebook 2025 v1.1; NPC012-01 NCT Inst Inter-PSP Implementation Guidelines 2025 v1.1", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the name and ISO meaning, error at the Creditor Agent, and the reject classification against NPC020-01 v3.1 section 3, AB09. Confirms the reject window against NPC010-01 2025 v1.1 section 4.2.3. Confirms that no reason in the rulebook's reject reason table, section 4.6.1 AT-R004, plainly matches this code, so the record is right to leave the sender as inference." } ] }, "rail_name": "Nordic Credit Transfer Instant (NCT Inst)", "governing_authority": "Nordic Payments Council", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "nct-inst:AB10", "id": "AB10", "rail": "nct-inst", "kind": "reason-code", "name": "Error at a CSM (instructed agent)", "group": "technical", "summary": "Processing broke off because of a fault at a CSM, where part of the NCT Inst service is unavailable.", "triggers": [ "Part or all of a CSM's NCT Inst service is down and the transaction aborts there" ], "actions": [ "Originator: agree another way to pay with the Beneficiary", "Originator PSP: suggest sending again or using another payment instrument" ], "retry": { "allowed": true, "rule": "Nothing settled, so nothing is re-presented. The Originator may start a new NCT Inst instruction once the cause is dealt with. The scheme sets no retry limit [Unverified]. The guidance names resubmission as one option." }, "facts": { "return_windows": [ { "action": "reject (negative confirmation)", "by": "CSM", "deadline": "Instantly, inside the execution time: the target for any answer at the Originator PSP is 5 seconds from its Time Stamp, and an answer after the 7-second time-out must reach it by the 9th second" } ], "applies_to": "NCT Inst, in any NPC Scheme Currency" }, "caveat": "The rulebook's list of reject reasons (section 4.6.1 AT-R004) has no reason that plainly matches this code [Inference from reading the list].", "related": [ "nct-inst:AB09", "nct-inst:AB06", "nct-inst:AB07" ], "basis": { "sources": "NPC020-01 v3.1 section 3, AB10; NPC012-01 2025 v1.1 section 2.2.2 (pacs.002 reject reason codes); NPC010-01 2025 v1.1 sections 4.2.3 B to D (5-second target, 7-second time-out, 9th-second relay, no unilateral reject by the Originator side) and 4.3.2.1 (CT-01.05R, CT-01.06R, CT-01.08R); NPC010-01 2025 v1.1 section 4.6.1 AT-R002 and AT-R004 (who may reject, and the reasons open to each).", "confidence": "high" }, "currency": { "effective_since": "2025-11-21", "effective_note": "NPC010-01 2025 v1.1 and NPC012-01 2025 v1.1 were issued and took effect on 2025-11-21; the 2025 rulebook first took effect on 2025-10-05 as v1.0. NPC020-01 v3.1 was published and took effect on 2026-07-03 as a clarification and correction release and states that it applies to the rulebook effective 5 October 2025. The NPC plans to publish the 2027 rulebook in November 2026 [Unverified: its effective date].", "source_edition": "NPC020-01 v3.1; NPC010-01 2025 v1.1; NPC012-01 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.nordicpaymentscouncil.org/media/bjfjylnq/guidance-on-reason-codes-for-nct-inst-r-transaction-v31.pdf", "source_class": "authoritative_primary", "source_title": "NPC020-01 Guidance on Reason Codes for NCT Inst R-transactions v3.1; NPC010-01 NCT Instant Rulebook 2025 v1.1; NPC012-01 NCT Inst Inter-PSP Implementation Guidelines 2025 v1.1", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the name and ISO meaning, error at the Instructed Agent, and the reject classification against NPC020-01 v3.1 section 3, AB10. Confirms the reject window against NPC010-01 2025 v1.1 section 4.2.3. Confirms that no reason in the rulebook's reject reason table, section 4.6.1 AT-R004, plainly matches this code, so the record is right to leave the sender as inference." } ] }, "rail_name": "Nordic Credit Transfer Instant (NCT Inst)", "governing_authority": "Nordic Payments Council", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "nct-inst:AC01", "id": "AC01", "rail": "nct-inst", "kind": "reason-code", "name": "Account identifier incorrect (invalid IBAN)", "group": "account", "summary": "The Beneficiary's IBAN is malformed or does not exist at the Beneficiary PSP. A CSM or the Beneficiary PSP may reject for it; the Originator PSP may refuse the instruction for the same reason.", "triggers": [ "The IBAN fails format checks", "The IBAN is well formed but no such account exists at the Beneficiary PSP", "Root causes include a wrong IBAN supplied by the Beneficiary, stale data at the Originator, or a technical fault when the instruction was built" ], "actions": [ "Originator: get the correct IBAN from the Beneficiary before paying again" ], "retry": { "allowed": true, "rule": "Only with corrected account details. Nothing settled, so nothing is re-presented. The Originator may start a new NCT Inst instruction once the cause is dealt with. The scheme sets no retry limit [Unverified]." }, "facts": { "return_windows": [ { "action": "reject (negative confirmation)", "by": "CSM or Beneficiary PSP", "deadline": "Instantly, inside the execution time: the target for any answer at the Originator PSP is 5 seconds from its Time Stamp; the Beneficiary PSP's confirmation must reach its CSM within 7 seconds, and the answer must reach the Originator PSP by the 9th second" } ], "applies_to": "NCT Inst, in any NPC Scheme Currency" }, "caveat": "The Originator PSP checks IBAN format and plausibility before sending (NPC010-01 2025 v1.1 CT-01.02), so an invalid-format reject further down the chain should be rare [Inference].", "related": [ "nct-inst:AC03", "nct-inst:RC01", "nct-inst:AC04" ], "basis": { "sources": "NPC020-01 v3.1 section 3, AC01; NPC012-01 2025 v1.1 section 2.2.2 (pacs.002 reject reason codes); NPC010-01 2025 v1.1 sections 4.2.3 B to D (5-second target, 7-second time-out, 9th-second relay, no unilateral reject by the Originator side) and 4.3.2.1 (CT-01.05R, CT-01.06R, CT-01.08R); NPC010-01 2025 v1.1 section 4.6.1 AT-R002 and AT-R004 (who may reject, and the reasons open to each); NPC010-01 2025 v1.1 section 4.3.1 CT-01.02 (Originator PSP checks).", "confidence": "high" }, "currency": { "effective_since": "2025-11-21", "effective_note": "NPC010-01 2025 v1.1 and NPC012-01 2025 v1.1 were issued and took effect on 2025-11-21; the 2025 rulebook first took effect on 2025-10-05 as v1.0. NPC020-01 v3.1 was published and took effect on 2026-07-03 as a clarification and correction release and states that it applies to the rulebook effective 5 October 2025. The NPC plans to publish the 2027 rulebook in November 2026 [Unverified: its effective date].", "source_edition": "NPC020-01 v3.1; NPC010-01 2025 v1.1; NPC012-01 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.nordicpaymentscouncil.org/media/bjfjylnq/guidance-on-reason-codes-for-nct-inst-r-transaction-v31.pdf", "source_class": "authoritative_primary", "source_title": "NPC020-01 Guidance on Reason Codes for NCT Inst R-transactions v3.1; NPC010-01 NCT Instant Rulebook 2025 v1.1; NPC012-01 NCT Inst Inter-PSP Implementation Guidelines 2025 v1.1", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the name and meaning, an invalid or non-existent IBAN, and the reject classification against NPC020-01 v3.1 section 3, AC01. Confirms the reject window against NPC010-01 2025 v1.1 section 4.2.3. Confirms the CSM and Beneficiary PSP as inter-PSP senders, and the Originator PSP's own IBAN format and plausibility check before sending, against the rulebook reject reason table in section 4.6.1 AT-R004 and step CT-01.02." } ] }, "rail_name": "Nordic Credit Transfer Instant (NCT Inst)", "governing_authority": "Nordic Payments Council", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "nct-inst:AC03", "id": "AC03", "rail": "nct-inst", "kind": "reason-code", "name": "Wrong beneficiary IBAN (RFRO reason)", "group": "account", "summary": "The Originator sent a settled payment to the wrong IBAN by its own mistake and asks, through an RFRO, for the money back. The Beneficiary decides.", "triggers": [ "The Originator picked or typed the wrong Beneficiary IBAN and the payment settled to that account" ], "actions": [ "Originator PSP: send the RFRO with this reason and tell the Originator that return is not guaranteed", "Originator: tighten how it selects and enters beneficiary IBANs" ], "retry": { "allowed": false, "rule": "One RFRO per transaction; after a response, or after 15 Banking Business Days without one, only a request for status update is allowed (NPC010-01 2025 v1.1 section 4.3.2.3)." }, "facts": { "return_windows": [ { "action": "request for recall by the originator (RFRO)", "by": "Originator PSP, at the Originator's request", "deadline": "The debit date of the original transaction must lie within the 13 months before the Originator PSP received the Originator's request; one RFRO per transaction, sent instantly or not as the Originator PSP chooses" }, { "action": "response to an RFRO", "by": "Beneficiary PSP", "deadline": "No later than 15 Banking Business Days after it receives the RFRO, or fewer where local law or community practice requires; a late response breaches the rulebook. A Banking Business Day is a day on which the participant concerned is open for business, so there is no single scheme calendar." } ], "applies_to": "NCT Inst, in any NPC Scheme Currency" }, "caveat": "For this reason only, a negative response may carry up to ten entries of information the Originator can use to bring a legal claim for the funds (NPC010-01 2025 v1.1 section 4.6.1 AT-R078; NPC012-01 2025 v1.1 section 2.9.1). The attribute is optional and subject to the data protection law that binds the Beneficiary PSP.", "related": [ "nct-inst:AC01", "nct-inst:CUST", "nct-inst:AM09" ], "basis": { "sources": "NPC020-01 v3.1 section 3, AC03; NPC012-01 2025 v1.1 sections 2.8.1 (camt.056 RFRO codes) and 2.9.2 (camt.029 negative response codes) and 2.9.1 (AT-R078 entries); NPC010-01 2025 v1.1 section 4.3.2.3 and its steps 1 to 5 (13 months, one RFRO, 15 Banking Business Day response), 4.6.1 AT-R071 and AT-R077; chapter 7 (Banking Business Day).", "confidence": "high" }, "currency": { "effective_since": "2025-11-21", "effective_note": "NPC010-01 2025 v1.1 and NPC012-01 2025 v1.1 were issued and took effect on 2025-11-21; the 2025 rulebook first took effect on 2025-10-05 as v1.0. NPC020-01 v3.1 was published and took effect on 2026-07-03 as a clarification and correction release and states that it applies to the rulebook effective 5 October 2025. The NPC plans to publish the 2027 rulebook in November 2026 [Unverified: its effective date].", "source_edition": "NPC020-01 v3.1; NPC010-01 2025 v1.1; NPC012-01 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.nordicpaymentscouncil.org/media/bjfjylnq/guidance-on-reason-codes-for-nct-inst-r-transaction-v31.pdf", "source_class": "authoritative_primary", "source_title": "NPC020-01 Guidance on Reason Codes for NCT Inst R-transactions v3.1; NPC010-01 NCT Instant Rulebook 2025 v1.1; NPC012-01 NCT Inst Inter-PSP Implementation Guidelines 2025 v1.1", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the name, meaning and RFRO classification, an Originator sending to a wrong IBAN, against NPC020-01 v3.1 section 3, AC03. Confirms the RFRO window, 13 months from the debit date and a 15 Banking Business Day response, against NPC010-01 2025 v1.1 section 4.3.2.3. Confirms the up to ten optional AT-R078 legal claim information entries tied to this reason code against NPC012-01 2025 v1.1 section 2.9, index 4.21." } ] }, "rail_name": "Nordic Credit Transfer Instant (NCT Inst)", "governing_authority": "Nordic Payments Council", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "nct-inst:AC04", "id": "AC04", "rail": "nct-inst", "kind": "reason-code", "name": "Account closed", "group": "account", "summary": "The Beneficiary's account is closed. Used by the Beneficiary PSP to reject a payment, and as a negative response to a recall or RFRO.", "triggers": [ "Reject: the Beneficiary has closed the account since the Originator last paid it", "Response: a recall or RFRO arrives for money credited to an account that has since been closed" ], "actions": [ "Originator: ask the Beneficiary for its new account", "After a negative response: recover the funds from the Beneficiary directly [Inference: the guidance gives no response-side action for this code]" ], "retry": { "allowed": false, "rule": "Not to the same account. A new instruction needs new account details. After a negative response, no further recall or RFRO on the same transaction is allowed." }, "facts": { "return_windows": [ { "action": "reject (negative confirmation)", "by": "Beneficiary PSP", "deadline": "Instantly. Its negative confirmation must reach its CSM within 7 seconds of the Originator PSP's Time Stamp (or a shorter agreed time-out), and the answer must reach the Originator PSP by the 9th second; the target for any answer at the Originator PSP is 5 seconds" }, { "action": "response to a recall", "by": "Beneficiary PSP", "deadline": "No later than 15 Banking Business Days after it receives the recall, or fewer where local law or community practice requires; a late response breaches the rulebook. A Banking Business Day is a day on which the participant concerned is open for business, so there is no single scheme calendar." }, { "action": "response to an RFRO", "by": "Beneficiary PSP", "deadline": "No later than 15 Banking Business Days after it receives the RFRO, or fewer where local law or community practice requires; a late response breaches the rulebook. A Banking Business Day is a day on which the participant concerned is open for business, so there is no single scheme calendar." } ], "applies_to": "NCT Inst, in any NPC Scheme Currency" }, "caveat": "Data protection rules in some countries forbid this code; MS03 is the named substitute (NPC020-01 v3.1, AC04 and MS03). The guidance does not say which countries. A negative response ends the recall or RFRO; the Originator PSP may not send another for the same transaction.", "related": [ "nct-inst:AC06", "nct-inst:MS03", "nct-inst:AM04", "nct-inst:CUST" ], "basis": { "sources": "NPC020-01 v3.1 section 3, AC04 and MS03; NPC012-01 2025 v1.1 section 2.2.2 (pacs.002 reject reason codes); NPC012-01 2025 v1.1 sections 2.4.2 and 2.9.2 (camt.029 negative response codes for a recall and for an RFRO); NPC010-01 2025 v1.1 sections 4.2.3 B to D (5-second target, 7-second time-out, 9th-second relay, no unilateral reject by the Originator side) and 4.3.2.1 (CT-01.05R, CT-01.06R, CT-01.08R); NPC010-01 2025 v1.1 section 4.6.1 AT-R002 and AT-R004 (who may reject, and the reasons open to each); NPC010-01 2025 v1.1 section 4.3.2.2 and CT-02.01 to CT-02.07 (three recall reasons, 10 Banking Business Days or 13 months, one recall, 15 Banking Business Day response), 4.6.1 AT-R051 and AT-R057; chapter 7 (Banking Business Day); NPC010-01 2025 v1.1 section 4.3.2.3 and its steps 1 to 5 (13 months, one RFRO, 15 Banking Business Day response), 4.6.1 AT-R071 and AT-R077; chapter 7 (Banking Business Day).", "confidence": "high" }, "currency": { "effective_since": "2025-11-21", "effective_note": "NPC010-01 2025 v1.1 and NPC012-01 2025 v1.1 were issued and took effect on 2025-11-21; the 2025 rulebook first took effect on 2025-10-05 as v1.0. NPC020-01 v3.1 was published and took effect on 2026-07-03 as a clarification and correction release and states that it applies to the rulebook effective 5 October 2025. The NPC plans to publish the 2027 rulebook in November 2026 [Unverified: its effective date].", "source_edition": "NPC020-01 v3.1; NPC010-01 2025 v1.1; NPC012-01 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.nordicpaymentscouncil.org/media/bjfjylnq/guidance-on-reason-codes-for-nct-inst-r-transaction-v31.pdf", "source_class": "authoritative_primary", "source_title": "NPC020-01 Guidance on Reason Codes for NCT Inst R-transactions v3.1; NPC010-01 NCT Instant Rulebook 2025 v1.1; NPC012-01 NCT Inst Inter-PSP Implementation Guidelines 2025 v1.1", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the name, meaning and dual reject and negative response classification, an account closed at the Beneficiary PSP, against NPC020-01 v3.1 section 3, AC04. Confirms the reject window and the 15 Banking Business Day recall and RFRO response windows against NPC010-01 2025 v1.1 sections 4.2.3, 4.3.2.2 and 4.3.2.3. Confirms the Beneficiary PSP as the reject sender against the rulebook reject reason table in section 4.6.1 AT-R004." } ] }, "rail_name": "Nordic Credit Transfer Instant (NCT Inst)", "governing_authority": "Nordic Payments Council", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "nct-inst:AC06", "id": "AC06", "rail": "nct-inst", "kind": "reason-code", "name": "Account blocked", "group": "account", "summary": "The Beneficiary PSP rejects because the account is blocked for all financial transactions.", "triggers": [ "A court order has led the Beneficiary PSP to block the account", "The Beneficiary PSP blocked it on its own grounds, such as suspected misuse, or at the Beneficiary's request" ], "actions": [ "Originator: ask the Beneficiary for another account or another way to pay" ], "retry": { "allowed": false, "rule": "Not to the same account while the block lasts. Nothing settled, so nothing is re-presented. The Originator may start a new NCT Inst instruction once the cause is dealt with. The scheme sets no retry limit [Unverified]." }, "facts": { "return_windows": [ { "action": "reject (negative confirmation)", "by": "Beneficiary PSP", "deadline": "Instantly. Its negative confirmation must reach its CSM within 7 seconds of the Originator PSP's Time Stamp (or a shorter agreed time-out), and the answer must reach the Originator PSP by the 9th second; the target for any answer at the Originator PSP is 5 seconds" } ], "applies_to": "NCT Inst, in any NPC Scheme Currency" }, "caveat": "The rulebook's reason is worded as a block with no reason given, so the Originator side should not expect to learn why [Inference from NPC010-01 2025 v1.1 section 4.6.1 AT-R004].", "related": [ "nct-inst:AC04", "nct-inst:AG01" ], "basis": { "sources": "NPC020-01 v3.1 section 3, AC06; NPC012-01 2025 v1.1 section 2.2.2 (pacs.002 reject reason codes); NPC010-01 2025 v1.1 sections 4.2.3 B to D (5-second target, 7-second time-out, 9th-second relay, no unilateral reject by the Originator side) and 4.3.2.1 (CT-01.05R, CT-01.06R, CT-01.08R); NPC010-01 2025 v1.1 section 4.6.1 AT-R002 and AT-R004 (who may reject, and the reasons open to each).", "confidence": "high" }, "currency": { "effective_since": "2025-11-21", "effective_note": "NPC010-01 2025 v1.1 and NPC012-01 2025 v1.1 were issued and took effect on 2025-11-21; the 2025 rulebook first took effect on 2025-10-05 as v1.0. NPC020-01 v3.1 was published and took effect on 2026-07-03 as a clarification and correction release and states that it applies to the rulebook effective 5 October 2025. The NPC plans to publish the 2027 rulebook in November 2026 [Unverified: its effective date].", "source_edition": "NPC020-01 v3.1; NPC010-01 2025 v1.1; NPC012-01 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.nordicpaymentscouncil.org/media/bjfjylnq/guidance-on-reason-codes-for-nct-inst-r-transaction-v31.pdf", "source_class": "authoritative_primary", "source_title": "NPC020-01 Guidance on Reason Codes for NCT Inst R-transactions v3.1; NPC010-01 NCT Instant Rulebook 2025 v1.1; NPC012-01 NCT Inst Inter-PSP Implementation Guidelines 2025 v1.1", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the name, meaning and reject classification, an account blocked for any financial transaction, against NPC020-01 v3.1 section 3, AC06. Confirms the reject window against NPC010-01 2025 v1.1 section 4.2.3. Confirms the Beneficiary PSP as the sender, with no reason given, against the rulebook reject reason table in section 4.6.1 AT-R004." } ] }, "rail_name": "Nordic Credit Transfer Instant (NCT Inst)", "governing_authority": "Nordic Payments Council", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "nct-inst:AG01", "id": "AG01", "rail": "nct-inst", "kind": "reason-code", "name": "Credit transfer forbidden on this account", "group": "account", "summary": "The Beneficiary PSP rejects because the account type cannot take NCT Inst credits, a savings account being the stock example.", "triggers": [ "The Beneficiary gave details of an account that cannot be credited by NCT Inst" ], "actions": [ "Originator: agree another instrument or account with the Beneficiary", "Originator PSP: re-send by another credit transfer route if the Originator agreed to that in advance" ], "retry": { "allowed": true, "rule": "Not as NCT Inst to the same account. Another instrument may work. Nothing settled, so nothing is re-presented. The Originator may start a new NCT Inst instruction once the cause is dealt with. The scheme sets no retry limit [Unverified]." }, "facts": { "return_windows": [ { "action": "reject (negative confirmation)", "by": "Beneficiary PSP", "deadline": "Instantly. Its negative confirmation must reach its CSM within 7 seconds of the Originator PSP's Time Stamp (or a shorter agreed time-out), and the answer must reach the Originator PSP by the 9th second; the target for any answer at the Originator PSP is 5 seconds" } ], "applies_to": "NCT Inst, in any NPC Scheme Currency" }, "caveat": "The guidance's re-send option names an 'SCT' transaction, a euro scheme outside NCT Inst; read it as a drafting leftover from the EPC original and as meaning another non-instant route [Inference]. The rulebook also lists, for the Beneficiary PSP, a currency that the account does not accept; which code carries that reason is not stated (NPC010-01 2025 v1.1 section 4.6.1 AT-R004).", "related": [ "nct-inst:AC06", "nct-inst:AM03" ], "basis": { "sources": "NPC020-01 v3.1 section 3, AG01; NPC012-01 2025 v1.1 section 2.2.2 (pacs.002 reject reason codes); NPC010-01 2025 v1.1 sections 4.2.3 B to D (5-second target, 7-second time-out, 9th-second relay, no unilateral reject by the Originator side) and 4.3.2.1 (CT-01.05R, CT-01.06R, CT-01.08R); NPC010-01 2025 v1.1 section 4.6.1 AT-R002 and AT-R004 (who may reject, and the reasons open to each).", "confidence": "high" }, "currency": { "effective_since": "2025-11-21", "effective_note": "NPC010-01 2025 v1.1 and NPC012-01 2025 v1.1 were issued and took effect on 2025-11-21; the 2025 rulebook first took effect on 2025-10-05 as v1.0. NPC020-01 v3.1 was published and took effect on 2026-07-03 as a clarification and correction release and states that it applies to the rulebook effective 5 October 2025. The NPC plans to publish the 2027 rulebook in November 2026 [Unverified: its effective date].", "source_edition": "NPC020-01 v3.1; NPC010-01 2025 v1.1; NPC012-01 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.nordicpaymentscouncil.org/media/bjfjylnq/guidance-on-reason-codes-for-nct-inst-r-transaction-v31.pdf", "source_class": "authoritative_primary", "source_title": "NPC020-01 Guidance on Reason Codes for NCT Inst R-transactions v3.1; NPC010-01 NCT Instant Rulebook 2025 v1.1; NPC012-01 NCT Inst Inter-PSP Implementation Guidelines 2025 v1.1", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the name, meaning and reject classification, an account type that cannot take NCT Inst credits, against NPC020-01 v3.1 section 3, AG01. Confirms the reject window against NPC010-01 2025 v1.1 section 4.2.3. Confirms the Beneficiary PSP as the sender against the rulebook reject reason table in section 4.6.1 AT-R004, and that the same table separately lists a Beneficiary PSP currency-not-accepted reason with no code assigned to it. Does not confirm the guidance's SCT re-send wording as an NCT Inst fact; the record is right to read it as a drafting leftover." } ] }, "rail_name": "Nordic Credit Transfer Instant (NCT Inst)", "governing_authority": "Nordic Payments Council", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "nct-inst:AG02", "id": "AG02", "rail": "nct-inst", "kind": "reason-code", "name": "Operation or transaction code incorrect", "group": "technical", "summary": "The scheme identifier in the message, its service level or local instrument, is wrong. The Originator side must correct it.", "triggers": [ "The service level or local instrument code in the transaction is not what NCT Inst requires", "A technical or processing error at the Originator when building the transaction or the file" ], "actions": [ "Originator: correct the scheme identification and send a new instruction" ], "retry": { "allowed": true, "rule": "Only after the code is corrected. Nothing settled, so nothing is re-presented. The Originator may start a new NCT Inst instruction once the cause is dealt with. The scheme sets no retry limit [Unverified]." }, "facts": { "return_windows": [ { "action": "reject (negative confirmation)", "by": "CSM or Beneficiary PSP", "deadline": "Instantly, inside the execution time: the target for any answer at the Originator PSP is 5 seconds from its Time Stamp; the Beneficiary PSP's confirmation must reach its CSM within 7 seconds, and the answer must reach the Originator PSP by the 9th second" } ], "applies_to": "NCT Inst, in any NPC Scheme Currency" }, "caveat": "The IG limits AG02 to a wrong operation or transaction code; a broken file is FF01 (NPC012-01 2025 v1.1 section 2.2.2). In the payment message the IG allows only the service level NPCA and the local instrument INST (NPC012-01 2025 v1.1 section 2.1, indexes 1.24 and following).", "related": [ "nct-inst:FF01", "nct-inst:AM11" ], "basis": { "sources": "NPC020-01 v3.1 section 3, AG02; NPC012-01 2025 v1.1 section 2.2.2 (pacs.002 reject reason codes); NPC010-01 2025 v1.1 sections 4.2.3 B to D (5-second target, 7-second time-out, 9th-second relay, no unilateral reject by the Originator side) and 4.3.2.1 (CT-01.05R, CT-01.06R, CT-01.08R); NPC010-01 2025 v1.1 section 4.6.1 AT-R002 and AT-R004 (who may reject, and the reasons open to each).", "confidence": "high" }, "currency": { "effective_since": "2025-11-21", "effective_note": "NPC010-01 2025 v1.1 and NPC012-01 2025 v1.1 were issued and took effect on 2025-11-21; the 2025 rulebook first took effect on 2025-10-05 as v1.0. NPC020-01 v3.1 was published and took effect on 2026-07-03 as a clarification and correction release and states that it applies to the rulebook effective 5 October 2025. The NPC plans to publish the 2027 rulebook in November 2026 [Unverified: its effective date].", "source_edition": "NPC020-01 v3.1; NPC010-01 2025 v1.1; NPC012-01 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.nordicpaymentscouncil.org/media/bjfjylnq/guidance-on-reason-codes-for-nct-inst-r-transaction-v31.pdf", "source_class": "authoritative_primary", "source_title": "NPC020-01 Guidance on Reason Codes for NCT Inst R-transactions v3.1; NPC010-01 NCT Instant Rulebook 2025 v1.1; NPC012-01 NCT Inst Inter-PSP Implementation Guidelines 2025 v1.1", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the name and meaning, a wrong service level or local instrument code, and the reject classification against NPC020-01 v3.1 section 3, AG02. Confirms the reject window against NPC010-01 2025 v1.1 section 4.2.3. Confirms the IG's restriction of AG02 to the operation or transaction code, with a broken file handled as FF01 instead, against NPC012-01 2025 v1.1 section 2.2.2." } ] }, "rail_name": "Nordic Credit Transfer Instant (NCT Inst)", "governing_authority": "Nordic Payments Council", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "nct-inst:AG09", "id": "AG09", "rail": "nct-inst", "kind": "reason-code", "name": "Original payment never received", "group": "technical", "summary": "Answer to a status investigation: the CSM or Beneficiary PSP asked about the payment never received it, so the Originator PSP can treat it as failed.", "triggers": [ "A status investigation reaches a Beneficiary PSP that is not the intended one, sent there by the Originator PSP or a CSM", "The intended Beneficiary PSP or a CSM never received the payment because of a connection or processing failure" ], "actions": [ "Originator PSP or CSM: if the inquiry went to the wrong place, send it to the right Beneficiary PSP", "Originator PSP: if the payment was really lost, investigate, reject the instruction, lift the reservation and tell the Originator" ], "retry": { "allowed": true, "rule": "The payment failed and nothing settled. The Originator may send a new instruction. The scheme sets no retry limit [Unverified]." }, "facts": { "return_windows": [ { "action": "negative confirmation in answer to a status investigation", "by": "CSM or Beneficiary PSP", "deadline": "Instantly. The scheme sets no time limit on the investigation as a whole, but obliges every party to act on it at once and answer as soon as possible" } ], "applies_to": "NCT Inst, in any NPC Scheme Currency" }, "caveat": "The guidance types this code as a reject, but it only arises inside the optional status investigation, which the Originator PSP may start when no confirmation has reached it after the time-out (NPC010-01 2025 v1.1 sections 4.2.3 D and 4.4). The IG says to send the investigation if nothing has arrived 5 seconds after the time-out deadline (NPC012-01 2025 v1.1 section 2.7.1); the rulebook speaks of the 9th and 10th seconds. The rulebook's list of reject reasons (section 4.6.1 AT-R004) has no reason that plainly matches this code [Inference from reading the list].", "related": [ "nct-inst:AB05", "nct-inst:AB06", "nct-inst:NOOR" ], "basis": { "sources": "NPC020-01 v3.1 section 3, AG09; NPC012-01 2025 v1.1 section 2.2.2 (pacs.002 reject reason codes); NPC012-01 2025 v1.1 section 2.7.1 (status investigation); NPC010-01 2025 v1.1 sections 4.2.3 D and 4.4 (CT-03.01 to CT-03.06).", "confidence": "high" }, "currency": { "effective_since": "2025-11-21", "effective_note": "NPC010-01 2025 v1.1 and NPC012-01 2025 v1.1 were issued and took effect on 2025-11-21; the 2025 rulebook first took effect on 2025-10-05 as v1.0. NPC020-01 v3.1 was published and took effect on 2026-07-03 as a clarification and correction release and states that it applies to the rulebook effective 5 October 2025. The NPC plans to publish the 2027 rulebook in November 2026 [Unverified: its effective date].", "source_edition": "NPC020-01 v3.1; NPC010-01 2025 v1.1; NPC012-01 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.nordicpaymentscouncil.org/media/bjfjylnq/guidance-on-reason-codes-for-nct-inst-r-transaction-v31.pdf", "source_class": "authoritative_primary", "source_title": "NPC020-01 Guidance on Reason Codes for NCT Inst R-transactions v3.1; NPC010-01 NCT Instant Rulebook 2025 v1.1; NPC012-01 NCT Inst Inter-PSP Implementation Guidelines 2025 v1.1", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the name and meaning, a payment the addressed party never received, and its use inside the status investigation procedure against NPC020-01 v3.1 section 3, AG09. Confirms the IG's trigger of a status investigation five seconds after the time-out deadline against NPC012-01 2025 v1.1 section 2.7.1, and the rulebook's 9th and 10th second figures for the same juncture against NPC010-01 2025 v1.1 section 4.2.3 D; the two documents anchor the same event to different seconds, and the record is right to flag this rather than resolve it. Confirms that no reason in the rulebook's reject reason table, section 4.6.1 AT-R004, plainly matches this code." } ] }, "rail_name": "Nordic Credit Transfer Instant (NCT Inst)", "governing_authority": "Nordic Payments Council", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "nct-inst:AG10", "id": "AG10", "rail": "nct-inst", "kind": "reason-code", "name": "Agent suspended", "group": "network", "summary": "An agent somewhere after the Originator PSP is suspended from the instant payment system, and it cannot be told whether it is the Beneficiary PSP or another party.", "triggers": [ "The overseer of an agent on the path has suspended it, perhaps only for a time", "The suspended party cannot be identified as the Beneficiary PSP or another agent" ], "actions": [ "Originator PSP: look for another route to the Beneficiary PSP", "Originator PSP: propose a later attempt, or another instrument such as NCT" ], "retry": { "allowed": true, "rule": "By another route, or later once the suspension ends. Nothing settled, so nothing is re-presented. The Originator may start a new NCT Inst instruction once the cause is dealt with. The scheme sets no retry limit [Unverified]." }, "facts": { "return_windows": [ { "action": "reject (negative confirmation)", "by": "CSM", "deadline": "Instantly, inside the execution time: the target for any answer at the Originator PSP is 5 seconds from its Time Stamp, and an answer after the 7-second time-out must reach it by the 9th second" } ], "applies_to": "NCT Inst, in any NPC Scheme Currency" }, "caveat": "The guidance makes this code mandatory where the suspended party cannot be identified; if it is known to be the Beneficiary PSP, AG11 applies. The rulebook's list of reject reasons (section 4.6.1 AT-R004) has no reason that plainly matches this code [Inference from reading the list].", "related": [ "nct-inst:AG11", "nct-inst:AB07" ], "basis": { "sources": "NPC020-01 v3.1 section 3, AG10; NPC012-01 2025 v1.1 section 2.2.2 (pacs.002 reject reason codes); NPC010-01 2025 v1.1 sections 4.2.3 B to D (5-second target, 7-second time-out, 9th-second relay, no unilateral reject by the Originator side) and 4.3.2.1 (CT-01.05R, CT-01.06R, CT-01.08R); NPC010-01 2025 v1.1 section 4.6.1 AT-R002 and AT-R004 (who may reject, and the reasons open to each).", "confidence": "high" }, "currency": { "effective_since": "2025-11-21", "effective_note": "NPC010-01 2025 v1.1 and NPC012-01 2025 v1.1 were issued and took effect on 2025-11-21; the 2025 rulebook first took effect on 2025-10-05 as v1.0. NPC020-01 v3.1 was published and took effect on 2026-07-03 as a clarification and correction release and states that it applies to the rulebook effective 5 October 2025. The NPC plans to publish the 2027 rulebook in November 2026 [Unverified: its effective date].", "source_edition": "NPC020-01 v3.1; NPC010-01 2025 v1.1; NPC012-01 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.nordicpaymentscouncil.org/media/bjfjylnq/guidance-on-reason-codes-for-nct-inst-r-transaction-v31.pdf", "source_class": "authoritative_primary", "source_title": "NPC020-01 Guidance on Reason Codes for NCT Inst R-transactions v3.1; NPC010-01 NCT Instant Rulebook 2025 v1.1; NPC012-01 NCT Inst Inter-PSP Implementation Guidelines 2025 v1.1", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the name and meaning, an unidentified suspended agent, and the reject classification against NPC020-01 v3.1 section 3, AG10. Confirms the reject window against NPC010-01 2025 v1.1 section 4.2.3. Confirms that no reason in the rulebook's reject reason table, section 4.6.1 AT-R004, plainly matches this code, so the record is right to leave the sender as inference." } ] }, "rail_name": "Nordic Credit Transfer Instant (NCT Inst)", "governing_authority": "Nordic Payments Council", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "nct-inst:AG11", "id": "AG11", "rail": "nct-inst", "kind": "reason-code", "name": "Beneficiary PSP suspended", "group": "network", "summary": "The Beneficiary PSP the payment was sent to is suspended from the instant payment system, possibly only for a time.", "triggers": [ "The Beneficiary PSP's overseer or its CSM has suspended it" ], "actions": [ "Originator: ask the Beneficiary for an account at another PSP" ], "retry": { "allowed": false, "rule": "Not to that PSP while it is suspended. Nothing settled, so nothing is re-presented. The Originator may start a new NCT Inst instruction once the cause is dealt with. The scheme sets no retry limit [Unverified]." }, "facts": { "return_windows": [ { "action": "reject (negative confirmation)", "by": "CSM", "deadline": "Instantly, inside the execution time: the target for any answer at the Originator PSP is 5 seconds from its Time Stamp, and an answer after the 7-second time-out must reach it by the 9th second" } ], "applies_to": "NCT Inst, in any NPC Scheme Currency" }, "caveat": "The rulebook's list of reject reasons (section 4.6.1 AT-R004) has no reason that plainly matches this code [Inference from reading the list]. A suspended PSP cannot answer for itself, so the reject comes from a CSM [Inference].", "related": [ "nct-inst:AG10", "nct-inst:CNOR", "nct-inst:AB08" ], "basis": { "sources": "NPC020-01 v3.1 section 3, AG11; NPC012-01 2025 v1.1 section 2.2.2 (pacs.002 reject reason codes); NPC010-01 2025 v1.1 sections 4.2.3 B to D (5-second target, 7-second time-out, 9th-second relay, no unilateral reject by the Originator side) and 4.3.2.1 (CT-01.05R, CT-01.06R, CT-01.08R); NPC010-01 2025 v1.1 section 4.6.1 AT-R002 and AT-R004 (who may reject, and the reasons open to each).", "confidence": "high" }, "currency": { "effective_since": "2025-11-21", "effective_note": "NPC010-01 2025 v1.1 and NPC012-01 2025 v1.1 were issued and took effect on 2025-11-21; the 2025 rulebook first took effect on 2025-10-05 as v1.0. NPC020-01 v3.1 was published and took effect on 2026-07-03 as a clarification and correction release and states that it applies to the rulebook effective 5 October 2025. The NPC plans to publish the 2027 rulebook in November 2026 [Unverified: its effective date].", "source_edition": "NPC020-01 v3.1; NPC010-01 2025 v1.1; NPC012-01 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.nordicpaymentscouncil.org/media/bjfjylnq/guidance-on-reason-codes-for-nct-inst-r-transaction-v31.pdf", "source_class": "authoritative_primary", "source_title": "NPC020-01 Guidance on Reason Codes for NCT Inst R-transactions v3.1; NPC010-01 NCT Instant Rulebook 2025 v1.1; NPC012-01 NCT Inst Inter-PSP Implementation Guidelines 2025 v1.1", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the name and meaning, a suspended Beneficiary PSP, and the reject classification against NPC020-01 v3.1 section 3, AG11. Confirms the reject window against NPC010-01 2025 v1.1 section 4.2.3. Confirms that no reason in the rulebook's reject reason table, section 4.6.1 AT-R004, plainly matches this code, so the record is right to treat a CSM sender as inference." } ] }, "rail_name": "Nordic Credit Transfer Instant (NCT Inst)", "governing_authority": "Nordic Payments Council", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "nct-inst:AM02", "id": "AM02", "rail": "nct-inst", "kind": "reason-code", "name": "Amount above the NCT Inst maximum", "group": "administrative", "summary": "The amount is above the scheme maximum for the currency, or above a higher limit the PSPs agreed between themselves. The maximum differs by Scheme Currency: DKK 500,000 (must reject), SEK 1,000,000 (may reject unless agreed otherwise), NOK none for now.", "triggers": [ "The amount exceeds the scheme maximum for its currency and the PSPs have no agreement on a higher one", "The amount exceeds a higher limit that the Originator PSP and the Beneficiary PSP did agree" ], "actions": [ "Originator PSP: suggest splitting the payment into amounts under the applicable maximum", "Originator PSP: suggest the non-instant NCT scheme instead" ], "retry": { "allowed": true, "rule": "As smaller payments under the maximum, or by another instrument. Nothing settled, so nothing is re-presented. The Originator may start a new NCT Inst instruction once the cause is dealt with. The scheme sets no retry limit [Unverified]." }, "facts": { "return_windows": [ { "action": "reject (negative confirmation)", "by": "CSM or Beneficiary PSP", "deadline": "Instantly, inside the execution time: the target for any answer at the Originator PSP is 5 seconds from its Time Stamp; the Beneficiary PSP's confirmation must reach its CSM within 7 seconds, and the answer must reach the Originator PSP by the 9th second" } ], "applies_to": "NCT Inst, in any NPC Scheme Currency" }, "caveat": "The maximum sits in NPC014-01 v2.0, a binding supplement that can change outside the rulebook cycle with at least 90 calendar days' notice, or at once in an emergency (sections 3 and 4). DKK is a hard limit every participant must enforce; SEK is a ceiling participants may enforce unless they agreed otherwise; for NOK the document sets no scheme maximum until Bits says otherwise. An Originator PSP may set lower limits for its own customers. The Originator PSP may also refuse an over-limit instruction before it is sent (NPC010-01 2025 v1.1 section 4.6.1 AT-R004). The guidance's option to use NCT assumes NCT is live; the NPC reported no NCT participants yet [Unverified].", "related": [ "nct-inst:AM23" ], "basis": { "sources": "NPC020-01 v3.1 section 3, AM02; NPC014-01 v2.0 sections 2.1 to 2.3, 3 and 4; NPC012-01 2025 v1.1 section 2.2.2 (pacs.002 reject reason codes); NPC010-01 2025 v1.1 sections 4.2.3 B to D (5-second target, 7-second time-out, 9th-second relay, no unilateral reject by the Originator side) and 4.3.2.1 (CT-01.05R, CT-01.06R, CT-01.08R); NPC010-01 2025 v1.1 section 4.6.1 AT-R002 and AT-R004 (who may reject, and the reasons open to each).", "confidence": "high" }, "currency": { "effective_since": "2025-11-21", "effective_note": "NPC010-01 2025 v1.1 and NPC012-01 2025 v1.1 were issued and took effect on 2025-11-21; the 2025 rulebook first took effect on 2025-10-05 as v1.0. NPC020-01 v3.1 was published and took effect on 2026-07-03 as a clarification and correction release and states that it applies to the rulebook effective 5 October 2025. The NPC plans to publish the 2027 rulebook in November 2026 [Unverified: its effective date].", "source_edition": "NPC020-01 v3.1; NPC010-01 2025 v1.1; NPC012-01 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.nordicpaymentscouncil.org/media/bjfjylnq/guidance-on-reason-codes-for-nct-inst-r-transaction-v31.pdf", "source_class": "authoritative_primary", "source_title": "NPC020-01 Guidance on Reason Codes for NCT Inst R-transactions v3.1; NPC010-01 NCT Instant Rulebook 2025 v1.1; NPC014-01 Maximum Amount for Instructions under the NCT Inst Scheme Rulebook v2.0", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the name, meaning and reject classification, an amount above the scheme or a bilaterally agreed maximum, against NPC020-01 v3.1 section 3, AM02. Confirms the DKK 500,000 must-reject limit, the SEK 1,000,000 may-reject limit unless otherwise agreed, and the absence of a scheme maximum for NOK until Bits says otherwise, against NPC014-01 v2.0 sections 2.1 to 2.3, and the at-least-90-calendar-day or emergency notice period against sections 3 and 4. Confirms the CSM and Beneficiary PSP as inter-PSP senders, and a separate Originator PSP pre-send refusal, against the rulebook reject reason table in section 4.6.1 AT-R004." } ] }, "rail_name": "Nordic Credit Transfer Instant (NCT Inst)", "governing_authority": "Nordic Payments Council", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "nct-inst:AM03", "id": "AM03", "rail": "nct-inst", "kind": "reason-code", "name": "Currency not reachable at the Beneficiary PSP", "group": "network", "summary": "The payment's currency is one the Beneficiary PSP does not receive in NCT Inst, although it is a Scheme Currency; the guidance's example is a PSP reachable only in SEK getting DKK or NOK.", "triggers": [ "The Beneficiary PSP is not registered to receive NCT Inst in the currency of the transaction" ], "actions": [ "Originator PSP: see whether the payment can go again in another Scheme Currency the Beneficiary PSP does accept" ], "retry": { "allowed": true, "rule": "Possibly in another Scheme Currency, as the guidance suggests. Nothing settled, so nothing is re-presented. The Originator may start a new NCT Inst instruction once the cause is dealt with. The scheme sets no retry limit [Unverified]." }, "facts": { "return_windows": [ { "action": "reject (negative confirmation)", "by": "CSM", "deadline": "Instantly, inside the execution time: the target for any answer at the Originator PSP is 5 seconds from its Time Stamp, and an answer after the 7-second time-out must reach it by the 9th second" } ], "applies_to": "NCT Inst, in any NPC Scheme Currency" }, "caveat": "No SEPA counterpart: SCT Inst runs in one currency, NCT Inst in three. The rulebook lists this reason for a CSM reject (NPC010-01 2025 v1.1 section 4.6.1 AT-R004). It separately lists, for the Beneficiary PSP, a currency not accepted for the account, and neither the guidance nor the IG says whether AM03 carries that too [Unverified]. Changing currency means a new payment in that currency; the texts read do not address conversion.", "related": [ "nct-inst:AM11", "nct-inst:AG01" ], "basis": { "sources": "NPC020-01 v3.1 section 3, AM03; NPC012-01 2025 v1.1 section 2.2.2 (pacs.002 reject reason codes) (AM03 usage rule); NPC010-01 2025 v1.1 sections 4.2.3 B to D (5-second target, 7-second time-out, 9th-second relay, no unilateral reject by the Originator side) and 4.3.2.1 (CT-01.05R, CT-01.06R, CT-01.08R); NPC010-01 2025 v1.1 section 4.6.1 AT-R002 and AT-R004 (who may reject, and the reasons open to each).", "confidence": "high" }, "currency": { "effective_since": "2025-11-21", "effective_note": "NPC010-01 2025 v1.1 and NPC012-01 2025 v1.1 were issued and took effect on 2025-11-21; the 2025 rulebook first took effect on 2025-10-05 as v1.0. NPC020-01 v3.1 was published and took effect on 2026-07-03 as a clarification and correction release and states that it applies to the rulebook effective 5 October 2025. The NPC plans to publish the 2027 rulebook in November 2026 [Unverified: its effective date]. This code first appeared in NPC020-01 in v3.1, added to match the Inter-PSP Implementation Guidelines, which already listed it.", "source_edition": "NPC020-01 v3.1; NPC010-01 2025 v1.1; NPC012-01 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.nordicpaymentscouncil.org/media/bjfjylnq/guidance-on-reason-codes-for-nct-inst-r-transaction-v31.pdf", "source_class": "authoritative_primary", "source_title": "NPC020-01 Guidance on Reason Codes for NCT Inst R-transactions v3.1; NPC010-01 NCT Instant Rulebook 2025 v1.1; NPC012-01 NCT Inst Inter-PSP Implementation Guidelines 2025 v1.1", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the name, meaning and reject classification, a Beneficiary PSP not reachable in the sent currency, against NPC020-01 v3.1 section 3, AM03, and the matching usage rule against NPC012-01 2025 v1.1 section 2.2.2. Confirms the CSM as the sender against the rulebook reject reason table in section 4.6.1 AT-R004, which lists this reason for the CSM only. Does not confirm whether AM03 also covers the table's separate Beneficiary PSP currency-not-accepted reason; the record is right to leave that unverified." } ] }, "rail_name": "Nordic Credit Transfer Instant (NCT Inst)", "governing_authority": "Nordic Payments Council", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "nct-inst:AM04", "id": "AM04", "rail": "nct-inst", "kind": "reason-code", "name": "Insufficient funds (response to a recall or RFRO)", "group": "funds", "summary": "The Beneficiary's account cannot cover the full recall or RFRO amount, so the Beneficiary PSP answers no. Not a reject reason in NCT Inst.", "triggers": [ "A recall or RFRO arrives and the Beneficiary's balance falls short of the full amount" ], "actions": [ "Originator: pursue the Beneficiary directly, outside the scheme", "Originator PSP: do the same where the recall was for its own error" ], "retry": { "allowed": false, "rule": "No. After the Beneficiary PSP responds, the Originator PSP may not send another recall or RFRO for the same transaction (NPC010-01 2025 v1.1 sections 4.3.2.2 and 4.3.2.3). Any further recovery is between Originator and Beneficiary, outside the scheme." }, "facts": { "return_windows": [ { "action": "response to a recall", "by": "Beneficiary PSP", "deadline": "No later than 15 Banking Business Days after it receives the recall, or fewer where local law or community practice requires; a late response breaches the rulebook. A Banking Business Day is a day on which the participant concerned is open for business, so there is no single scheme calendar." }, { "action": "response to an RFRO", "by": "Beneficiary PSP", "deadline": "No later than 15 Banking Business Days after it receives the RFRO, or fewer where local law or community practice requires; a late response breaches the rulebook. A Banking Business Day is a day on which the participant concerned is open for business, so there is no single scheme calendar." } ], "applies_to": "NCT Inst, in any NPC Scheme Currency" }, "caveat": "In some countries data protection law or national agreements rule this code out and CUST is used instead (NPC020-01 v3.1, AM04); the guidance does not name the countries. The Originator PSP checks the Originator's funds before sending (NPC010-01 2025 v1.1 section 4.2.1), so the scheme has no insufficient-funds reject. A negative response ends the recall or RFRO; the Originator PSP may not send another for the same transaction.", "related": [ "nct-inst:CUST", "nct-inst:LEGL", "nct-inst:NOAS", "nct-inst:FOCR" ], "basis": { "sources": "NPC020-01 v3.1 section 3, AM04; NPC012-01 2025 v1.1 sections 2.4.2 and 2.9.2 (camt.029 negative response codes for a recall and for an RFRO); NPC010-01 2025 v1.1 section 4.3.2.2 and CT-02.01 to CT-02.07 (three recall reasons, 10 Banking Business Days or 13 months, one recall, 15 Banking Business Day response), 4.6.1 AT-R051 and AT-R057; chapter 7 (Banking Business Day); NPC010-01 2025 v1.1 section 4.3.2.3 and its steps 1 to 5 (13 months, one RFRO, 15 Banking Business Day response), 4.6.1 AT-R071 and AT-R077; chapter 7 (Banking Business Day); NPC010-01 2025 v1.1 section 4.2.1 (funds check before sending).", "confidence": "high" }, "currency": { "effective_since": "2025-11-21", "effective_note": "NPC010-01 2025 v1.1 and NPC012-01 2025 v1.1 were issued and took effect on 2025-11-21; the 2025 rulebook first took effect on 2025-10-05 as v1.0. NPC020-01 v3.1 was published and took effect on 2026-07-03 as a clarification and correction release and states that it applies to the rulebook effective 5 October 2025. The NPC plans to publish the 2027 rulebook in November 2026 [Unverified: its effective date].", "source_edition": "NPC020-01 v3.1; NPC010-01 2025 v1.1; NPC012-01 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.nordicpaymentscouncil.org/media/bjfjylnq/guidance-on-reason-codes-for-nct-inst-r-transaction-v31.pdf", "source_class": "authoritative_primary", "source_title": "NPC020-01 Guidance on Reason Codes for NCT Inst R-transactions v3.1; NPC010-01 NCT Instant Rulebook 2025 v1.1; NPC012-01 NCT Inst Inter-PSP Implementation Guidelines 2025 v1.1", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the name and meaning, insufficient funds to cover a recall or RFRO, and that it is a negative response only, never a reject, against NPC020-01 v3.1 section 3, AM04. Confirms the 15 Banking Business Day recall and RFRO response windows against NPC010-01 2025 v1.1 sections 4.3.2.2 and 4.3.2.3, and that the Originator PSP checks the Originator's funds before sending, so there is no insufficient-funds reject, against section 4.2.1." } ] }, "rail_name": "Nordic Credit Transfer Instant (NCT Inst)", "governing_authority": "Nordic Payments Council", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "jurisdiction", "label": "the country", "needs": "which country the payment or the account is in", "detail": "In some countries data protection law or national agreements rule this code out and CUST is used instead (NPC020-01 v3.1, AM04); the guidance does not name the countries.", "from": "caveat" } ] }, { "uid": "nct-inst:AM05", "id": "AM05", "rail": "nct-inst", "kind": "reason-code", "name": "Duplicate payment (reject)", "group": "administrative", "summary": "A CSM or the Beneficiary PSP judges the transaction to be a copy of one sent or processed very recently and rejects it.", "triggers": [ "An identical transaction passed through very shortly before", "A technical or human error at the Originator or the Originator PSP" ], "actions": [ "Originator or Originator PSP: check whether the payment really was a duplicate before sending anything again" ], "retry": { "allowed": false, "rule": "Not the same payment. If the check shows it was not a duplicate, a new instruction may be sent. The scheme sets no retry limit [Unverified]." }, "facts": { "return_windows": [ { "action": "reject (negative confirmation)", "by": "CSM or Beneficiary PSP", "deadline": "Instantly, inside the execution time: the target for any answer at the Originator PSP is 5 seconds from its Time Stamp; the Beneficiary PSP's confirmation must reach its CSM within 7 seconds, and the answer must reach the Originator PSP by the 9th second" } ], "applies_to": "NCT Inst, in any NPC Scheme Currency" }, "caveat": "A duplicate that has already settled is recovered by a recall with DUPL, not by this reject. The texts read do not define how recent 'very recently' is [Unverified].", "related": [ "nct-inst:DUPL" ], "basis": { "sources": "NPC020-01 v3.1 section 3, AM05; NPC012-01 2025 v1.1 section 2.2.2 (pacs.002 reject reason codes); NPC010-01 2025 v1.1 sections 4.2.3 B to D (5-second target, 7-second time-out, 9th-second relay, no unilateral reject by the Originator side) and 4.3.2.1 (CT-01.05R, CT-01.06R, CT-01.08R); NPC010-01 2025 v1.1 section 4.6.1 AT-R002 and AT-R004 (who may reject, and the reasons open to each).", "confidence": "high" }, "currency": { "effective_since": "2025-11-21", "effective_note": "NPC010-01 2025 v1.1 and NPC012-01 2025 v1.1 were issued and took effect on 2025-11-21; the 2025 rulebook first took effect on 2025-10-05 as v1.0. NPC020-01 v3.1 was published and took effect on 2026-07-03 as a clarification and correction release and states that it applies to the rulebook effective 5 October 2025. The NPC plans to publish the 2027 rulebook in November 2026 [Unverified: its effective date].", "source_edition": "NPC020-01 v3.1; NPC010-01 2025 v1.1; NPC012-01 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.nordicpaymentscouncil.org/media/bjfjylnq/guidance-on-reason-codes-for-nct-inst-r-transaction-v31.pdf", "source_class": "authoritative_primary", "source_title": "NPC020-01 Guidance on Reason Codes for NCT Inst R-transactions v3.1; NPC010-01 NCT Instant Rulebook 2025 v1.1; NPC012-01 NCT Inst Inter-PSP Implementation Guidelines 2025 v1.1", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the name, meaning and reject classification, a transaction judged to duplicate one sent or processed very recently, against NPC020-01 v3.1 section 3, AM05. Confirms the reject window against NPC010-01 2025 v1.1 section 4.2.3. Confirms the CSM and Beneficiary PSP as inter-PSP senders against the rulebook reject reason table in section 4.6.1 AT-R004." } ] }, "rail_name": "Nordic Credit Transfer Instant (NCT Inst)", "governing_authority": "Nordic Payments Council", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "nct-inst:AM09", "id": "AM09", "rail": "nct-inst", "kind": "reason-code", "name": "Wrong amount (RFRO reason)", "group": "administrative", "summary": "The Originator paid more than it meant to and asks, through an RFRO, for the money back. The Beneficiary decides.", "triggers": [ "A technical or human error at the Originator produced a higher amount than intended" ], "actions": [ "Originator PSP: send the RFRO and tell the Originator that return is not guaranteed", "Originator: fix the process that produced the wrong amount" ], "retry": { "allowed": false, "rule": "One RFRO per transaction; after a response, or after 15 Banking Business Days without one, only a request for status update is allowed (NPC010-01 2025 v1.1 section 4.3.2.3)." }, "facts": { "return_windows": [ { "action": "request for recall by the originator (RFRO)", "by": "Originator PSP, at the Originator's request", "deadline": "The debit date of the original transaction must lie within the 13 months before the Originator PSP received the Originator's request; one RFRO per transaction, sent instantly or not as the Originator PSP chooses" }, { "action": "response to an RFRO", "by": "Beneficiary PSP", "deadline": "No later than 15 Banking Business Days after it receives the RFRO, or fewer where local law or community practice requires; a late response breaches the rulebook. A Banking Business Day is a day on which the participant concerned is open for business, so there is no single scheme calendar." } ], "applies_to": "NCT Inst, in any NPC Scheme Currency" }, "caveat": "The guidance speaks only of an amount higher than intended. The texts read do not say whether the RFRO seeks the whole amount or only the excess [Unverified]; a positive response states the returned amount, which may be less than the original (NPC010-01 2025 v1.1 section 4.6.1 AT-R074 and AT-R075).", "related": [ "nct-inst:AC03", "nct-inst:CUST" ], "basis": { "sources": "NPC020-01 v3.1 section 3, AM09; NPC012-01 2025 v1.1 sections 2.8.1 (camt.056 RFRO codes) and 2.9.2 (camt.029 negative response codes); NPC010-01 2025 v1.1 section 4.3.2.3 and its steps 1 to 5 (13 months, one RFRO, 15 Banking Business Day response), 4.6.1 AT-R071 and AT-R077; chapter 7 (Banking Business Day).", "confidence": "high" }, "currency": { "effective_since": "2025-11-21", "effective_note": "NPC010-01 2025 v1.1 and NPC012-01 2025 v1.1 were issued and took effect on 2025-11-21; the 2025 rulebook first took effect on 2025-10-05 as v1.0. NPC020-01 v3.1 was published and took effect on 2026-07-03 as a clarification and correction release and states that it applies to the rulebook effective 5 October 2025. The NPC plans to publish the 2027 rulebook in November 2026 [Unverified: its effective date].", "source_edition": "NPC020-01 v3.1; NPC010-01 2025 v1.1; NPC012-01 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.nordicpaymentscouncil.org/media/bjfjylnq/guidance-on-reason-codes-for-nct-inst-r-transaction-v31.pdf", "source_class": "authoritative_primary", "source_title": "NPC020-01 Guidance on Reason Codes for NCT Inst R-transactions v3.1; NPC010-01 NCT Instant Rulebook 2025 v1.1; NPC012-01 NCT Inst Inter-PSP Implementation Guidelines 2025 v1.1", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the name, meaning and RFRO classification, an Originator paying more than intended, against NPC020-01 v3.1 section 3, AM09. Confirms the RFRO window, 13 months from the debit date and a 15 Banking Business Day response, against NPC010-01 2025 v1.1 section 4.3.2.3, and that the positive response's returned amount field, AT-R074, can be less than the original against section 4.6.1." } ] }, "rail_name": "Nordic Credit Transfer Instant (NCT Inst)", "governing_authority": "Nordic Payments Council", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "nct-inst:AM11", "id": "AM11", "rail": "nct-inst", "kind": "reason-code", "name": "Transaction currency invalid, or cross-border not accepted", "group": "network", "summary": "The currency is missing or not an NPC Scheme Currency, or the payment crosses a border to a Beneficiary PSP that does not accept cross-border NCT Inst.", "triggers": [ "The currency field is missing or holds a currency outside the NPC Scheme Currencies", "A cross-border payment went to a Beneficiary PSP that has not opted in to cross-border receipt" ], "actions": [ "Originator PSP: send only in Scheme Currencies", "Originator PSP: send cross-border payments only to Beneficiary PSPs that accept them" ], "retry": { "allowed": false, "rule": "Not as sent. A corrected currency, or another route for a cross-border payment, would be a new instruction. The scheme sets no retry limit [Unverified]." }, "facts": { "return_windows": [ { "action": "reject (negative confirmation)", "by": "CSM", "deadline": "Instantly, inside the execution time: the target for any answer at the Originator PSP is 5 seconds from its Time Stamp, and an answer after the 7-second time-out must reach it by the 9th second" } ], "applies_to": "NCT Inst, in any NPC Scheme Currency" }, "caveat": "No SEPA counterpart. The rulebook gives this reason to a CSM and ties it to a Beneficiary PSP not reachable for cross-border payments (NPC010-01 2025 v1.1 section 4.6.1 AT-R004). Every participant must be reachable domestically in at least one Scheme Currency, and accepting cross-border payments is an option (NPC010-01 2025 v1.1 sections 1.2, 2.4 and 2.6); the Originator PSP must check that the Beneficiary PSP accepts cross-border payments before sending one (section 5.7 item 15).", "related": [ "nct-inst:AM03", "nct-inst:AG02" ], "basis": { "sources": "NPC020-01 v3.1 section 3, AM11; NPC012-01 2025 v1.1 section 2.2.2 (pacs.002 reject reason codes) (AM11 usage rule); NPC010-01 2025 v1.1 sections 4.2.3 B to D (5-second target, 7-second time-out, 9th-second relay, no unilateral reject by the Originator side) and 4.3.2.1 (CT-01.05R, CT-01.06R, CT-01.08R); NPC010-01 2025 v1.1 section 4.6.1 AT-R002 and AT-R004 (who may reject, and the reasons open to each); NPC010-01 2025 v1.1 sections 1.2, 2.4, 2.6 and 5.7 item 15 (cross-border option and check).", "confidence": "high" }, "currency": { "effective_since": "2025-11-21", "effective_note": "NPC010-01 2025 v1.1 and NPC012-01 2025 v1.1 were issued and took effect on 2025-11-21; the 2025 rulebook first took effect on 2025-10-05 as v1.0. NPC020-01 v3.1 was published and took effect on 2026-07-03 as a clarification and correction release and states that it applies to the rulebook effective 5 October 2025. The NPC plans to publish the 2027 rulebook in November 2026 [Unverified: its effective date]. This code first appeared in NPC020-01 in v3.1, added to match the Inter-PSP Implementation Guidelines, which already listed it.", "source_edition": "NPC020-01 v3.1; NPC010-01 2025 v1.1; NPC012-01 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.nordicpaymentscouncil.org/media/bjfjylnq/guidance-on-reason-codes-for-nct-inst-r-transaction-v31.pdf", "source_class": "authoritative_primary", "source_title": "NPC020-01 Guidance on Reason Codes for NCT Inst R-transactions v3.1; NPC010-01 NCT Instant Rulebook 2025 v1.1; NPC012-01 NCT Inst Inter-PSP Implementation Guidelines 2025 v1.1", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the name and meaning, a missing or non-scheme currency or an unaccepted cross-border payment, and the reject classification against NPC020-01 v3.1 section 3, AM11, and the matching usage rule against NPC012-01 2025 v1.1 section 2.2.2. Confirms the CSM as the sender against the rulebook reject reason table in section 4.6.1 AT-R004, which lists this reason for the CSM only, and that this reason has no SEPA counterpart since SCT Inst runs in a single currency." } ] }, "rail_name": "Nordic Credit Transfer Instant (NCT Inst)", "governing_authority": "Nordic Payments Council", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "nct-inst:AM23", "id": "AM23", "rail": "nct-inst", "kind": "reason-code", "name": "Amount exceeds settlement limit", "group": "network", "summary": "The CSM rejects because the Originator PSP lacks enough prefunded settlement cover for this transaction.", "triggers": [ "A sudden peak in the Originator PSP's outgoing NCT Inst volume", "The Originator PSP cannot top up its settlement cover in time", "The Originator PSP's monitoring of remaining cover fails unnoticed" ], "actions": [ "Originator PSP: replenish its settlement cover as soon as possible", "Originator PSP: suggest a later attempt or another instrument such as NCT", "Originator: agree another way to pay with the Beneficiary" ], "retry": { "allowed": true, "rule": "Once the Originator PSP has restored its cover. Nothing settled, so nothing is re-presented. The Originator may start a new NCT Inst instruction once the cause is dealt with. The scheme sets no retry limit [Unverified]." }, "facts": { "return_windows": [ { "action": "reject (negative confirmation)", "by": "CSM", "deadline": "Instantly, inside the execution time: the target for any answer at the Originator PSP is 5 seconds from its Time Stamp, and an answer after the 7-second time-out must reach it by the 9th second" } ], "applies_to": "NCT Inst, in any NPC Scheme Currency" }, "caveat": "The guidance speaks of the Originator suffering the top-up failure; read it as the Originator PSP [Inference]. How much cover a CSM requires is a matter for the CSM, not the scheme; the rulebook only requires the Originator PSP's CSM to reserve cover before passing the payment on (NPC010-01 2025 v1.1 section 4.3 principle 1).", "related": [ "nct-inst:AM02" ], "basis": { "sources": "NPC020-01 v3.1 section 3, AM23; NPC012-01 2025 v1.1 section 2.2.2 (pacs.002 reject reason codes); NPC010-01 2025 v1.1 sections 4.2.3 B to D (5-second target, 7-second time-out, 9th-second relay, no unilateral reject by the Originator side) and 4.3.2.1 (CT-01.05R, CT-01.06R, CT-01.08R); NPC010-01 2025 v1.1 section 4.6.1 AT-R002 and AT-R004 (who may reject, and the reasons open to each); NPC010-01 2025 v1.1 section 4.3 principle 1.", "confidence": "high" }, "currency": { "effective_since": "2025-11-21", "effective_note": "NPC010-01 2025 v1.1 and NPC012-01 2025 v1.1 were issued and took effect on 2025-11-21; the 2025 rulebook first took effect on 2025-10-05 as v1.0. NPC020-01 v3.1 was published and took effect on 2026-07-03 as a clarification and correction release and states that it applies to the rulebook effective 5 October 2025. The NPC plans to publish the 2027 rulebook in November 2026 [Unverified: its effective date].", "source_edition": "NPC020-01 v3.1; NPC010-01 2025 v1.1; NPC012-01 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.nordicpaymentscouncil.org/media/bjfjylnq/guidance-on-reason-codes-for-nct-inst-r-transaction-v31.pdf", "source_class": "authoritative_primary", "source_title": "NPC020-01 Guidance on Reason Codes for NCT Inst R-transactions v3.1; NPC010-01 NCT Instant Rulebook 2025 v1.1; NPC012-01 NCT Inst Inter-PSP Implementation Guidelines 2025 v1.1", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the name, meaning and reject classification, insufficient prefunded settlement cover at the Originator PSP, against NPC020-01 v3.1 section 3, AM23. Confirms the reject window against NPC010-01 2025 v1.1 section 4.2.3. Confirms the CSM as the sender against the rulebook reject reason table in section 4.6.1 AT-R004, which lists this reason for the CSM only, and the CSM's upfront reservation of funds against section 4.3 principle 1." } ] }, "rail_name": "Nordic Credit Transfer Instant (NCT Inst)", "governing_authority": "Nordic Payments Council", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "nct-inst:ARDT", "id": "ARDT", "rail": "nct-inst", "kind": "reason-code", "name": "Already returned (response to a recall or RFRO)", "group": "administrative", "summary": "The Beneficiary PSP answers no because the Beneficiary has already sent the money back to the Originator by some other means.", "triggers": [ "Before the recall or RFRO arrived, the Beneficiary repaid the Originator by another payment" ], "actions": [ "No action: the Originator should already hold the funds" ], "retry": { "allowed": false, "rule": "No. After the Beneficiary PSP responds, the Originator PSP may not send another recall or RFRO for the same transaction (NPC010-01 2025 v1.1 sections 4.3.2.2 and 4.3.2.3). Any further recovery is between Originator and Beneficiary, outside the scheme." }, "facts": { "return_windows": [ { "action": "response to a recall", "by": "Beneficiary PSP", "deadline": "No later than 15 Banking Business Days after it receives the recall, or fewer where local law or community practice requires; a late response breaches the rulebook. A Banking Business Day is a day on which the participant concerned is open for business, so there is no single scheme calendar." }, { "action": "response to an RFRO", "by": "Beneficiary PSP", "deadline": "No later than 15 Banking Business Days after it receives the RFRO, or fewer where local law or community practice requires; a late response breaches the rulebook. A Banking Business Day is a day on which the participant concerned is open for business, so there is no single scheme calendar." } ], "applies_to": "NCT Inst, in any NPC Scheme Currency" }, "caveat": "The guidance's example lists 'SCT' among the ways the funds may have gone back, an EPC leftover [Inference]. A Beneficiary who wants to repay has no scheme R-transaction of its own and must use a new payment (NPC010-01 2025 v1.1 section 4.3.2.4). A negative response ends the recall or RFRO; the Originator PSP may not send another for the same transaction.", "related": [ "nct-inst:FOCR", "nct-inst:CUST" ], "basis": { "sources": "NPC020-01 v3.1 section 3, ARDT; NPC012-01 2025 v1.1 sections 2.4.2 and 2.9.2 (camt.029 negative response codes for a recall and for an RFRO); NPC010-01 2025 v1.1 section 4.3.2.2 and CT-02.01 to CT-02.07 (three recall reasons, 10 Banking Business Days or 13 months, one recall, 15 Banking Business Day response), 4.6.1 AT-R051 and AT-R057; chapter 7 (Banking Business Day); NPC010-01 2025 v1.1 section 4.3.2.3 and its steps 1 to 5 (13 months, one RFRO, 15 Banking Business Day response), 4.6.1 AT-R071 and AT-R077; chapter 7 (Banking Business Day); NPC010-01 2025 v1.1 section 4.3.2.4.", "confidence": "high" }, "currency": { "effective_since": "2025-11-21", "effective_note": "NPC010-01 2025 v1.1 and NPC012-01 2025 v1.1 were issued and took effect on 2025-11-21; the 2025 rulebook first took effect on 2025-10-05 as v1.0. NPC020-01 v3.1 was published and took effect on 2026-07-03 as a clarification and correction release and states that it applies to the rulebook effective 5 October 2025. The NPC plans to publish the 2027 rulebook in November 2026 [Unverified: its effective date].", "source_edition": "NPC020-01 v3.1; NPC010-01 2025 v1.1; NPC012-01 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.nordicpaymentscouncil.org/media/bjfjylnq/guidance-on-reason-codes-for-nct-inst-r-transaction-v31.pdf", "source_class": "authoritative_primary", "source_title": "NPC020-01 Guidance on Reason Codes for NCT Inst R-transactions v3.1; NPC010-01 NCT Instant Rulebook 2025 v1.1; NPC012-01 NCT Inst Inter-PSP Implementation Guidelines 2025 v1.1", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the name and meaning, funds already sent back outside the recall or RFRO, and that it is a negative response only against NPC020-01 v3.1 section 3, ARDT. Confirms the 15 Banking Business Day recall and RFRO response windows against NPC010-01 2025 v1.1 sections 4.3.2.2 and 4.3.2.3, and that a Beneficiary wishing to repay has no scheme R-transaction and must use a new payment, against section 4.3.2.4. Does not confirm the guidance's SCT example as an NCT Inst fact; the record is right to read it as a drafting leftover." } ] }, "rail_name": "Nordic Credit Transfer Instant (NCT Inst)", "governing_authority": "Nordic Payments Council", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "nct-inst:BE04", "id": "BE04", "rail": "nct-inst", "kind": "reason-code", "name": "Beneficiary address missing or invalid", "group": "administrative", "summary": "The Beneficiary PSP rejects because the Beneficiary's address is absent or invalid where it needs one to process the payment.", "triggers": [ "The transaction carries no Beneficiary address and the Beneficiary PSP needs it for further processing", "The address given is invalid" ], "actions": [ "Originator PSP: ask the Originator for the Beneficiary's address and send a new instruction" ], "retry": { "allowed": true, "rule": "With the address supplied. Nothing settled, so nothing is re-presented. The Originator may start a new NCT Inst instruction once the cause is dealt with. The scheme sets no retry limit [Unverified]." }, "facts": { "return_windows": [ { "action": "reject (negative confirmation)", "by": "Beneficiary PSP", "deadline": "Instantly. Its negative confirmation must reach its CSM within 7 seconds of the Originator PSP's Time Stamp (or a shorter agreed time-out), and the answer must reach the Originator PSP by the 9th second; the target for any answer at the Originator PSP is 5 seconds" } ], "applies_to": "NCT Inst, in any NPC Scheme Currency" }, "caveat": "The rulebook gives this reason to the Beneficiary PSP only (NPC010-01 2025 v1.1 section 4.6.1 AT-R004). The guidance says Beneficiary address is optional for RR03 purposes, so when an address becomes necessary is left to the Beneficiary PSP [Inference].", "related": [ "nct-inst:RR03" ], "basis": { "sources": "NPC020-01 v3.1 section 3, BE04 and RR03; NPC012-01 2025 v1.1 section 2.2.2 (pacs.002 reject reason codes); NPC010-01 2025 v1.1 sections 4.2.3 B to D (5-second target, 7-second time-out, 9th-second relay, no unilateral reject by the Originator side) and 4.3.2.1 (CT-01.05R, CT-01.06R, CT-01.08R); NPC010-01 2025 v1.1 section 4.6.1 AT-R002 and AT-R004 (who may reject, and the reasons open to each).", "confidence": "high" }, "currency": { "effective_since": "2025-11-21", "effective_note": "NPC010-01 2025 v1.1 and NPC012-01 2025 v1.1 were issued and took effect on 2025-11-21; the 2025 rulebook first took effect on 2025-10-05 as v1.0. NPC020-01 v3.1 was published and took effect on 2026-07-03 as a clarification and correction release and states that it applies to the rulebook effective 5 October 2025. The NPC plans to publish the 2027 rulebook in November 2026 [Unverified: its effective date].", "source_edition": "NPC020-01 v3.1; NPC010-01 2025 v1.1; NPC012-01 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.nordicpaymentscouncil.org/media/bjfjylnq/guidance-on-reason-codes-for-nct-inst-r-transaction-v31.pdf", "source_class": "authoritative_primary", "source_title": "NPC020-01 Guidance on Reason Codes for NCT Inst R-transactions v3.1; NPC010-01 NCT Instant Rulebook 2025 v1.1; NPC012-01 NCT Inst Inter-PSP Implementation Guidelines 2025 v1.1", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the name, meaning and reject classification, a missing or invalid Beneficiary address, against NPC020-01 v3.1 section 3, BE04. Confirms the reject window against NPC010-01 2025 v1.1 section 4.2.3. Confirms the Beneficiary PSP as the sender against the rulebook reject reason table in section 4.6.1 AT-R004, which lists this reason for the Beneficiary PSP only." } ] }, "rail_name": "Nordic Credit Transfer Instant (NCT Inst)", "governing_authority": "Nordic Payments Council", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "nct-inst:CNOR", "id": "CNOR", "rail": "nct-inst", "kind": "reason-code", "name": "Beneficiary PSP not registered under this BIC in the CSM", "group": "network", "summary": "The CSM rejects because the Beneficiary PSP is not, or no longer, an NCT Inst participant under that BIC at this CSM.", "triggers": [ "The Beneficiary PSP has not been declared, or is no longer declared, as a direct or indirect participant at the CSM" ], "actions": [ "Originator: ask the Beneficiary how it can receive NCT Inst through another PSP" ], "retry": { "allowed": false, "rule": "Not to that BIC through that CSM. Nothing settled, so nothing is re-presented. The Originator may start a new NCT Inst instruction once the cause is dealt with. The scheme sets no retry limit [Unverified]." }, "facts": { "return_windows": [ { "action": "reject (negative confirmation)", "by": "CSM", "deadline": "Instantly, inside the execution time: the target for any answer at the Originator PSP is 5 seconds from its Time Stamp, and an answer after the 7-second time-out must reach it by the 9th second" } ], "applies_to": "NCT Inst, in any NPC Scheme Currency" }, "caveat": "The rulebook gives this reason to the CSM only (NPC010-01 2025 v1.1 section 4.6.1 AT-R004).", "related": [ "nct-inst:DNOR", "nct-inst:AG11" ], "basis": { "sources": "NPC020-01 v3.1 section 3, CNOR; NPC012-01 2025 v1.1 section 2.2.2 (pacs.002 reject reason codes); NPC010-01 2025 v1.1 sections 4.2.3 B to D (5-second target, 7-second time-out, 9th-second relay, no unilateral reject by the Originator side) and 4.3.2.1 (CT-01.05R, CT-01.06R, CT-01.08R); NPC010-01 2025 v1.1 section 4.6.1 AT-R002 and AT-R004 (who may reject, and the reasons open to each).", "confidence": "high" }, "currency": { "effective_since": "2025-11-21", "effective_note": "NPC010-01 2025 v1.1 and NPC012-01 2025 v1.1 were issued and took effect on 2025-11-21; the 2025 rulebook first took effect on 2025-10-05 as v1.0. NPC020-01 v3.1 was published and took effect on 2026-07-03 as a clarification and correction release and states that it applies to the rulebook effective 5 October 2025. The NPC plans to publish the 2027 rulebook in November 2026 [Unverified: its effective date].", "source_edition": "NPC020-01 v3.1; NPC010-01 2025 v1.1; NPC012-01 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.nordicpaymentscouncil.org/media/bjfjylnq/guidance-on-reason-codes-for-nct-inst-r-transaction-v31.pdf", "source_class": "authoritative_primary", "source_title": "NPC020-01 Guidance on Reason Codes for NCT Inst R-transactions v3.1; NPC010-01 NCT Instant Rulebook 2025 v1.1; NPC012-01 NCT Inst Inter-PSP Implementation Guidelines 2025 v1.1", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the name, meaning and reject classification, a Beneficiary PSP not or no longer registered under this BIC at the CSM, against NPC020-01 v3.1 section 3, CNOR. Confirms the reject window against NPC010-01 2025 v1.1 section 4.2.3. Confirms the CSM as the sender against the rulebook reject reason table in section 4.6.1 AT-R004, which lists this reason for the CSM only." } ] }, "rail_name": "Nordic Credit Transfer Instant (NCT Inst)", "governing_authority": "Nordic Payments Council", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "nct-inst:CUST", "id": "CUST", "rail": "nct-inst", "kind": "reason-code", "name": "Requested by customer (RFRO reason, or Beneficiary refusal)", "group": "authorization", "summary": "Two uses. As an RFRO reason, the Originator wants a settled payment back without giving a reason. As a negative response to a recall or RFRO, the Beneficiary refuses.", "triggers": [ "RFRO: the Originator asks for the funds of a settled payment and gives no specific reason", "Response: the Beneficiary maintains that it is entitled to keep the funds" ], "actions": [ "RFRO: no action is suggested; the Originator PSP sends the request and warns that return is not guaranteed", "Refusal: the Originator, and the Originator PSP where a recall was for its own error, pursue the Beneficiary directly outside the scheme" ], "retry": { "allowed": false, "rule": "No. After the Beneficiary PSP responds, the Originator PSP may not send another recall or RFRO for the same transaction (NPC010-01 2025 v1.1 sections 4.3.2.2 and 4.3.2.3). Any further recovery is between Originator and Beneficiary, outside the scheme. One RFRO per transaction." }, "facts": { "return_windows": [ { "action": "request for recall by the originator (RFRO)", "by": "Originator PSP, at the Originator's request", "deadline": "The debit date of the original transaction must lie within the 13 months before the Originator PSP received the Originator's request; one RFRO per transaction, sent instantly or not as the Originator PSP chooses" }, { "action": "response to a recall", "by": "Beneficiary PSP", "deadline": "No later than 15 Banking Business Days after it receives the recall, or fewer where local law or community practice requires; a late response breaches the rulebook. A Banking Business Day is a day on which the participant concerned is open for business, so there is no single scheme calendar." }, { "action": "response to an RFRO", "by": "Beneficiary PSP", "deadline": "No later than 15 Banking Business Days after it receives the RFRO, or fewer where local law or community practice requires; a late response breaches the rulebook. A Banking Business Day is a day on which the participant concerned is open for business, so there is no single scheme calendar." } ], "applies_to": "NCT Inst, in any NPC Scheme Currency" }, "caveat": "In countries where AM04 is barred, CUST is the named substitute, so a CUST refusal may hide insufficient funds (NPC020-01 v3.1, AM04). The guidance's suggested action for a refusal refers to the procedures of 'the NCT scheme', which reads as a slip for NCT Inst [Inference]. A negative response ends the recall or RFRO; the Originator PSP may not send another for the same transaction.", "related": [ "nct-inst:MS02", "nct-inst:NOAS", "nct-inst:LEGL", "nct-inst:AM09", "nct-inst:AC03" ], "basis": { "sources": "NPC020-01 v3.1 section 3, CUST and AM04; NPC012-01 2025 v1.1 sections 2.8.1 (camt.056 RFRO codes) and 2.9.2 (camt.029 negative response codes); NPC012-01 2025 v1.1 sections 2.4.2 and 2.9.2 (camt.029 negative response codes for a recall and for an RFRO); NPC010-01 2025 v1.1 section 4.3.2.2 and CT-02.01 to CT-02.07 (three recall reasons, 10 Banking Business Days or 13 months, one recall, 15 Banking Business Day response), 4.6.1 AT-R051 and AT-R057; chapter 7 (Banking Business Day); NPC010-01 2025 v1.1 section 4.3.2.3 and its steps 1 to 5 (13 months, one RFRO, 15 Banking Business Day response), 4.6.1 AT-R071 and AT-R077; chapter 7 (Banking Business Day).", "confidence": "high" }, "currency": { "effective_since": "2025-11-21", "effective_note": "NPC010-01 2025 v1.1 and NPC012-01 2025 v1.1 were issued and took effect on 2025-11-21; the 2025 rulebook first took effect on 2025-10-05 as v1.0. NPC020-01 v3.1 was published and took effect on 2026-07-03 as a clarification and correction release and states that it applies to the rulebook effective 5 October 2025. The NPC plans to publish the 2027 rulebook in November 2026 [Unverified: its effective date].", "source_edition": "NPC020-01 v3.1; NPC010-01 2025 v1.1; NPC012-01 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.nordicpaymentscouncil.org/media/bjfjylnq/guidance-on-reason-codes-for-nct-inst-r-transaction-v31.pdf", "source_class": "authoritative_primary", "source_title": "NPC020-01 Guidance on Reason Codes for NCT Inst R-transactions v3.1; NPC010-01 NCT Instant Rulebook 2025 v1.1; NPC012-01 NCT Inst Inter-PSP Implementation Guidelines 2025 v1.1", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms both uses, an RFRO with no stated reason and a negative response for a Beneficiary refusal, against NPC020-01 v3.1 section 3, CUST. Confirms the RFRO window and the 15 Banking Business Day recall and RFRO response windows against NPC010-01 2025 v1.1 sections 4.3.2.2 and 4.3.2.3. Does not confirm which countries bar AM04 in favour of CUST; the record is right to leave that unverified." } ] }, "rail_name": "Nordic Credit Transfer Instant (NCT Inst)", "governing_authority": "Nordic Payments Council", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "nct-inst:DNOR", "id": "DNOR", "rail": "nct-inst", "kind": "reason-code", "name": "Originator PSP not registered under this BIC in the CSM", "group": "network", "summary": "The CSM rejects because the Originator PSP is not, or no longer, an NCT Inst participant under that BIC at this CSM, typically after sending to a former CSM by mistake.", "triggers": [ "The Originator PSP routed the payment to a CSM it no longer uses" ], "actions": [ "Originator PSP: route through its current CSM", "Originator PSP: contact the Originator to agree another means of payment, such as NCT" ], "retry": { "allowed": true, "rule": "Through the correct CSM. Nothing settled, so nothing is re-presented. The Originator may start a new NCT Inst instruction once the cause is dealt with. The scheme sets no retry limit [Unverified]." }, "facts": { "return_windows": [ { "action": "reject (negative confirmation)", "by": "CSM", "deadline": "Instantly, inside the execution time: the target for any answer at the Originator PSP is 5 seconds from its Time Stamp, and an answer after the 7-second time-out must reach it by the 9th second" } ], "applies_to": "NCT Inst, in any NPC Scheme Currency" }, "caveat": "The rulebook gives this reason to the CSM only (NPC010-01 2025 v1.1 section 4.6.1 AT-R004).", "related": [ "nct-inst:CNOR" ], "basis": { "sources": "NPC020-01 v3.1 section 3, DNOR; NPC012-01 2025 v1.1 section 2.2.2 (pacs.002 reject reason codes); NPC010-01 2025 v1.1 sections 4.2.3 B to D (5-second target, 7-second time-out, 9th-second relay, no unilateral reject by the Originator side) and 4.3.2.1 (CT-01.05R, CT-01.06R, CT-01.08R); NPC010-01 2025 v1.1 section 4.6.1 AT-R002 and AT-R004 (who may reject, and the reasons open to each).", "confidence": "high" }, "currency": { "effective_since": "2025-11-21", "effective_note": "NPC010-01 2025 v1.1 and NPC012-01 2025 v1.1 were issued and took effect on 2025-11-21; the 2025 rulebook first took effect on 2025-10-05 as v1.0. NPC020-01 v3.1 was published and took effect on 2026-07-03 as a clarification and correction release and states that it applies to the rulebook effective 5 October 2025. The NPC plans to publish the 2027 rulebook in November 2026 [Unverified: its effective date].", "source_edition": "NPC020-01 v3.1; NPC010-01 2025 v1.1; NPC012-01 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.nordicpaymentscouncil.org/media/bjfjylnq/guidance-on-reason-codes-for-nct-inst-r-transaction-v31.pdf", "source_class": "authoritative_primary", "source_title": "NPC020-01 Guidance on Reason Codes for NCT Inst R-transactions v3.1; NPC010-01 NCT Instant Rulebook 2025 v1.1; NPC012-01 NCT Inst Inter-PSP Implementation Guidelines 2025 v1.1", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the name, meaning and reject classification, an Originator PSP not or no longer registered under this BIC at the CSM, against NPC020-01 v3.1 section 3, DNOR. Confirms the reject window against NPC010-01 2025 v1.1 section 4.2.3. Confirms the CSM as the sender against the rulebook reject reason table in section 4.6.1 AT-R004, which lists this reason for the CSM only." } ] }, "rail_name": "Nordic Credit Transfer Instant (NCT Inst)", "governing_authority": "Nordic Payments Council", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "nct-inst:DS24", "id": "DS24", "rail": "nct-inst", "kind": "reason-code", "name": "Waiting time expired (incomplete order)", "group": "technical", "summary": "An ISO code the Inter-PSP IG lists among its example reject reasons, meaning the waiting time ran out because the order was incomplete. No NPC text says when NCT Inst uses it.", "triggers": [ "The IG gives only the ISO meaning: time to complete the order ran out [Unverified: no NCT Inst use case is published]" ], "actions": [ "Originator PSP: ask the rejecting party what was missing [Inference: the texts give no action]" ], "retry": { "allowed": true, "rule": "Nothing settled. Nothing settled, so nothing is re-presented. The Originator may start a new NCT Inst instruction once the cause is dealt with. The scheme sets no retry limit [Unverified]." }, "facts": { "return_windows": [ { "action": "reject (negative confirmation)", "by": "Not stated; the IG list does not say which party uses this code", "deadline": "As for any reject: instantly, inside the execution time, with the 7-second time-out and the 9th-second relay limit as outer bounds" } ], "applies_to": "NCT Inst, in any NPC Scheme Currency" }, "caveat": "NPC020-01 v3.1 does not describe DS24, while it calls its own use cases an exhaustive list; the IG calls its pacs.002 list examples and points to the full ISO set (NPC012-01 2025 v1.1 section 2.2.2). Which of the two bounds the reject codes is not settled. The rulebook's list of reject reasons (section 4.6.1 AT-R004) has no reason that plainly matches this code [Inference from reading the list].", "related": [ "nct-inst:AB05", "nct-inst:AB06" ], "basis": { "sources": "NPC012-01 2025 v1.1 section 2.2.2 (pacs.002 reject reason codes); NPC010-01 2025 v1.1 sections 4.2.3 B to D (5-second target, 7-second time-out, 9th-second relay, no unilateral reject by the Originator side) and 4.3.2.1 (CT-01.05R, CT-01.06R, CT-01.08R); NPC010-01 2025 v1.1 section 4.6.1 AT-R002 and AT-R004 (who may reject, and the reasons open to each).", "confidence": "medium" }, "currency": { "effective_since": "2025-11-21", "effective_note": "NPC012-01 2025 v1.1 was issued and took effect on 2025-11-21, together with NPC010-01 2025 v1.1. NPC020-01 v3.1 (effective 2026-07-03) does not describe this code. The NPC plans to publish the 2027 rulebook in November 2026 [Unverified: its effective date].", "source_edition": "NPC012-01 2025 v1.1; NPC010-01 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.nordicpaymentscouncil.org/media/5ukhpf0y/2025-nct-inst-documents.zip", "source_class": "authoritative_primary", "source_title": "NPC012-01 NCT Inst Inter-PSP Implementation Guidelines 2025 v1.1 (in the 2025 NCT Inst documents archive); NPC020-01 Guidance on Reason Codes for NCT Inst R-transactions v3.1", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms that NPC012-01 2025 v1.1 section 2.2.2 lists DS24 only among its example pacs.002 reject reasons, with no stated NCT Inst use case and no stated sender, and that NPC020-01 v3.1 does not describe DS24 anywhere in its own, stated-exhaustive, use case table. Confirms the reject window as the general case against NPC010-01 2025 v1.1 section 4.2.3." } ] }, "rail_name": "Nordic Credit Transfer Instant (NCT Inst)", "governing_authority": "Nordic Payments Council", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "nct-inst:DUPL", "id": "DUPL", "rail": "nct-inst", "kind": "reason-code", "name": "Duplicate sending (recall reason)", "group": "administrative", "summary": "The Originator or the Originator PSP finds that a payment was sent twice and recalls the copy.", "triggers": [ "A technical or human error at the Originator or the Originator PSP sent the same payment more than once" ], "actions": [ "Originator PSP: send the recall within 10 Banking Business Days of execution", "Originator and Originator PSP: put in controls so duplicates are not created or exchanged again" ], "retry": { "allowed": false, "rule": "One recall per transaction; after a response, or after 15 Banking Business Days without one, only a request for status update is allowed (NPC010-01 2025 v1.1 section 4.3.2.2)." }, "facts": { "return_windows": [ { "action": "recall", "by": "Originator PSP, on its own initiative or at the Originator's request", "deadline": "Sent no later than 10 Banking Business Days after the execution date of the original transaction, or fewer where local law or community practice requires; one recall per transaction. A Banking Business Day is a day on which the participant concerned is open for business, so there is no single scheme calendar." }, { "action": "response to a recall", "by": "Beneficiary PSP", "deadline": "No later than 15 Banking Business Days after it receives the recall, or fewer where local law or community practice requires; a late response breaches the rulebook. A Banking Business Day is a day on which the participant concerned is open for business, so there is no single scheme calendar." } ], "applies_to": "NCT Inst, in any NPC Scheme Currency" }, "caveat": "A recall is a request; the Beneficiary PSP may answer no. The Originator PSP may refuse an Originator's recall request that falls outside the three reasons or the time limit (NPC010-01 2025 v1.1 CT-02.01R). The returned amount may be less than the original, as the Beneficiary PSP may take a fee.", "related": [ "nct-inst:AM05", "nct-inst:TECH", "nct-inst:FRAD" ], "basis": { "sources": "NPC020-01 v3.1 section 3, DUPL; NPC012-01 2025 v1.1 sections 2.3.1 (camt.056 recall codes) and 2.4.2 (camt.029 negative response codes); NPC010-01 2025 v1.1 section 4.3.2.2 and CT-02.01 to CT-02.07 (three recall reasons, 10 Banking Business Days or 13 months, one recall, 15 Banking Business Day response), 4.6.1 AT-R051 and AT-R057; chapter 7 (Banking Business Day).", "confidence": "high" }, "currency": { "effective_since": "2025-11-21", "effective_note": "NPC010-01 2025 v1.1 and NPC012-01 2025 v1.1 were issued and took effect on 2025-11-21; the 2025 rulebook first took effect on 2025-10-05 as v1.0. NPC020-01 v3.1 was published and took effect on 2026-07-03 as a clarification and correction release and states that it applies to the rulebook effective 5 October 2025. The NPC plans to publish the 2027 rulebook in November 2026 [Unverified: its effective date].", "source_edition": "NPC020-01 v3.1; NPC010-01 2025 v1.1; NPC012-01 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.nordicpaymentscouncil.org/media/bjfjylnq/guidance-on-reason-codes-for-nct-inst-r-transaction-v31.pdf", "source_class": "authoritative_primary", "source_title": "NPC020-01 Guidance on Reason Codes for NCT Inst R-transactions v3.1; NPC010-01 NCT Instant Rulebook 2025 v1.1; NPC012-01 NCT Inst Inter-PSP Implementation Guidelines 2025 v1.1", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the name, meaning and recall classification, a payment sent more than once by mistake, against NPC020-01 v3.1 section 3, DUPL. Confirms the recall window, 10 Banking Business Days from execution, and the 15 Banking Business Day response window, against NPC010-01 2025 v1.1 section 4.3.2.2, and that a fee may reduce the returned amount against the same section." } ] }, "rail_name": "Nordic Credit Transfer Instant (NCT Inst)", "governing_authority": "Nordic Payments Council", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "nct-inst:FF01", "id": "FF01", "rail": "nct-inst", "kind": "reason-code", "name": "Invalid file format", "group": "technical", "summary": "The whole message is rejected at group level because the XML is incomplete, wrong or has a syntax error. It is the only code allowed at group level in the pacs.002.", "triggers": [ "The XML was not properly filled in or has content errors", "The file has a syntax error", "The Originator PSP or its CSM skipped the XSD check before sending" ], "actions": [ "Whoever built the file (Originator, Originator PSP or CSM): repair the XML and send again" ], "retry": { "allowed": true, "rule": "After the file is repaired. Nothing settled, so nothing is re-presented. The Originator may start a new NCT Inst instruction once the cause is dealt with. The scheme sets no retry limit [Unverified]." }, "facts": { "return_windows": [ { "action": "reject (negative confirmation)", "by": "CSM or Beneficiary PSP", "deadline": "Instantly, inside the execution time: the target for any answer at the Originator PSP is 5 seconds from its Time Stamp; the Beneficiary PSP's confirmation must reach its CSM within 7 seconds, and the answer must reach the Originator PSP by the 9th second" } ], "applies_to": "NCT Inst, in any NPC Scheme Currency" }, "caveat": "The IG allows FF01, and only FF01, as the group-level reason in the negative confirmation (NPC012-01 2025 v1.1 section 2.2, index 2.10); transaction-level rejects use the other codes. A wrong scheme code in an otherwise valid file is AG02.", "related": [ "nct-inst:AG02" ], "basis": { "sources": "NPC020-01 v3.1 section 3, FF01; NPC012-01 2025 v1.1 section 2.2 (group status reason, only FF01); NPC010-01 2025 v1.1 sections 4.2.3 B to D (5-second target, 7-second time-out, 9th-second relay, no unilateral reject by the Originator side) and 4.3.2.1 (CT-01.05R, CT-01.06R, CT-01.08R); NPC010-01 2025 v1.1 section 4.6.1 AT-R002 and AT-R004 (who may reject, and the reasons open to each).", "confidence": "high" }, "currency": { "effective_since": "2025-11-21", "effective_note": "NPC010-01 2025 v1.1 and NPC012-01 2025 v1.1 were issued and took effect on 2025-11-21; the 2025 rulebook first took effect on 2025-10-05 as v1.0. NPC020-01 v3.1 was published and took effect on 2026-07-03 as a clarification and correction release and states that it applies to the rulebook effective 5 October 2025. The NPC plans to publish the 2027 rulebook in November 2026 [Unverified: its effective date].", "source_edition": "NPC020-01 v3.1; NPC010-01 2025 v1.1; NPC012-01 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.nordicpaymentscouncil.org/media/bjfjylnq/guidance-on-reason-codes-for-nct-inst-r-transaction-v31.pdf", "source_class": "authoritative_primary", "source_title": "NPC020-01 Guidance on Reason Codes for NCT Inst R-transactions v3.1; NPC010-01 NCT Instant Rulebook 2025 v1.1; NPC012-01 NCT Inst Inter-PSP Implementation Guidelines 2025 v1.1", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the name, meaning and reject classification, an incomplete or invalid XML file, against NPC020-01 v3.1 section 3, FF01. Confirms the reject window against NPC010-01 2025 v1.1 section 4.2.3. Confirms that FF01 is the only reason allowed at group level in the negative confirmation against NPC012-01 2025 v1.1 section 2.2.2, index 2.10." } ] }, "rail_name": "Nordic Credit Transfer Instant (NCT Inst)", "governing_authority": "Nordic Payments Council", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "nct-inst:FOCR", "id": "FOCR", "rail": "nct-inst", "kind": "reason-code", "name": "Positive response to a recall or RFRO", "group": "administrative", "summary": "The recall or RFRO succeeds: the Beneficiary PSP, with the Beneficiary's consent where needed, agrees and sends the funds back to the Originator PSP.", "triggers": [ "The Beneficiary PSP or the Beneficiary agrees to return the funds" ], "actions": [ "Beneficiary PSP: return the funds in the scheme's positive response message, never as a new payment", "Originator PSP: credit the Originator with the amount returned" ], "retry": { "allowed": false, "rule": "The recall or RFRO has succeeded; nothing further is sent." }, "facts": { "return_windows": [ { "action": "response to a recall", "by": "Beneficiary PSP", "deadline": "No later than 15 Banking Business Days after it receives the recall, or fewer where local law or community practice requires; a late response breaches the rulebook. A Banking Business Day is a day on which the participant concerned is open for business, so there is no single scheme calendar." }, { "action": "response to an RFRO", "by": "Beneficiary PSP", "deadline": "No later than 15 Banking Business Days after it receives the RFRO, or fewer where local law or community practice requires; a late response breaches the rulebook. A Banking Business Day is a day on which the participant concerned is open for business, so there is no single scheme calendar." } ], "applies_to": "NCT Inst, in any NPC Scheme Currency" }, "caveat": "The amount returned may be less than the original: the Beneficiary PSP may deduct a fee, and currency conversion losses, but must return in the original currency (NPC010-01 2025 v1.1 sections 4.3.2.2 and 4.6.1 AT-R054 to AT-R056 and AT-R074 to AT-R076). FOCR is the only reason allowed in the pacs.004 used for these responses (NPC012-01 2025 v1.1 sections 2.5 and 2.10).", "related": [ "nct-inst:ARDT", "nct-inst:CUST" ], "basis": { "sources": "NPC020-01 v3.1 section 3, FOCR; NPC012-01 2025 v1.1 sections 2.5.1 and 2.10.1 (pacs.004, FOCR only); NPC010-01 2025 v1.1 section 4.3.2.2 and CT-02.01 to CT-02.07 (three recall reasons, 10 Banking Business Days or 13 months, one recall, 15 Banking Business Day response), 4.6.1 AT-R051 and AT-R057; chapter 7 (Banking Business Day); NPC010-01 2025 v1.1 section 4.3.2.3 and its steps 1 to 5 (13 months, one RFRO, 15 Banking Business Day response), 4.6.1 AT-R071 and AT-R077; chapter 7 (Banking Business Day).", "confidence": "high" }, "currency": { "effective_since": "2025-11-21", "effective_note": "NPC010-01 2025 v1.1 and NPC012-01 2025 v1.1 were issued and took effect on 2025-11-21; the 2025 rulebook first took effect on 2025-10-05 as v1.0. NPC020-01 v3.1 was published and took effect on 2026-07-03 as a clarification and correction release and states that it applies to the rulebook effective 5 October 2025. The NPC plans to publish the 2027 rulebook in November 2026 [Unverified: its effective date].", "source_edition": "NPC020-01 v3.1; NPC010-01 2025 v1.1; NPC012-01 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.nordicpaymentscouncil.org/media/bjfjylnq/guidance-on-reason-codes-for-nct-inst-r-transaction-v31.pdf", "source_class": "authoritative_primary", "source_title": "NPC020-01 Guidance on Reason Codes for NCT Inst R-transactions v3.1; NPC010-01 NCT Instant Rulebook 2025 v1.1; NPC012-01 NCT Inst Inter-PSP Implementation Guidelines 2025 v1.1", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the name and meaning, the Beneficiary PSP or Beneficiary agreeing to return the funds, and its use as the positive response to a recall or RFRO against NPC020-01 v3.1 section 3, FOCR. Confirms that FOCR is the only reason used in the pacs.004 for these responses against NPC012-01 2025 v1.1 sections 2.5 and 2.10, and the 15 Banking Business Day response windows and possible fee or conversion deduction against NPC010-01 2025 v1.1 sections 4.3.2.2, 4.3.2.3 and 4.6.1." } ] }, "rail_name": "Nordic Credit Transfer Instant (NCT Inst)", "governing_authority": "Nordic Payments Council", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "nct-inst:FRAD", "id": "FRAD", "rail": "nct-inst", "kind": "reason-code", "name": "Fraudulently originated (recall reason)", "group": "authorization", "summary": "The Originator or the Originator PSP finds a fraudulent payment and recalls it, up to 13 months after execution.", "triggers": [ "The Originator says it fell victim to a fraudulently executed payment", "Fraudsters tampered with the Originator PSP's NCT Inst systems to send payments" ], "actions": [ "Originator PSP: send the recall within 13 months of execution, adding fraud details for the Beneficiary PSP if useful", "Originator and Originator PSP: put controls in place against such fraud" ], "retry": { "allowed": false, "rule": "One recall per transaction; after a response, or after 15 Banking Business Days without one, only a request for status update is allowed (NPC010-01 2025 v1.1 section 4.3.2.2)." }, "facts": { "return_windows": [ { "action": "recall", "by": "Originator PSP, on its own initiative or at the Originator's request", "deadline": "Sent no later than 13 months after the execution date of the original transaction; one recall per transaction" }, { "action": "response to a recall", "by": "Beneficiary PSP", "deadline": "No later than 15 Banking Business Days after it receives the recall, or fewer where local law or community practice requires; a late response breaches the rulebook. A Banking Business Day is a day on which the participant concerned is open for business, so there is no single scheme calendar." } ], "applies_to": "NCT Inst, in any NPC Scheme Currency" }, "caveat": "A recall is a request; the Beneficiary PSP may answer no. Free-text fraud information is allowed only with this reason, and the Beneficiary PSP need not act on it (NPC010-01 2025 v1.1 section 4.6.1 AT-R052; NPC012-01 2025 v1.1 section 2.3.1). Whether authorised push payment scams count as fraudulently originated is not stated [Unverified].", "related": [ "nct-inst:DUPL", "nct-inst:TECH", "nct-inst:LEGL" ], "basis": { "sources": "NPC020-01 v3.1 section 3, FRAD; NPC012-01 2025 v1.1 sections 2.3.1 (camt.056 recall codes) and 2.4.2 (camt.029 negative response codes); NPC010-01 2025 v1.1 section 4.3.2.2 and CT-02.01 to CT-02.07 (three recall reasons, 10 Banking Business Days or 13 months, one recall, 15 Banking Business Day response), 4.6.1 AT-R051 and AT-R057; chapter 7 (Banking Business Day); NPC010-01 2025 v1.1 section 4.6.1 AT-R052.", "confidence": "high" }, "currency": { "effective_since": "2025-11-21", "effective_note": "NPC010-01 2025 v1.1 and NPC012-01 2025 v1.1 were issued and took effect on 2025-11-21; the 2025 rulebook first took effect on 2025-10-05 as v1.0. NPC020-01 v3.1 was published and took effect on 2026-07-03 as a clarification and correction release and states that it applies to the rulebook effective 5 October 2025. The NPC plans to publish the 2027 rulebook in November 2026 [Unverified: its effective date].", "source_edition": "NPC020-01 v3.1; NPC010-01 2025 v1.1; NPC012-01 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.nordicpaymentscouncil.org/media/bjfjylnq/guidance-on-reason-codes-for-nct-inst-r-transaction-v31.pdf", "source_class": "authoritative_primary", "source_title": "NPC020-01 Guidance on Reason Codes for NCT Inst R-transactions v3.1; NPC010-01 NCT Instant Rulebook 2025 v1.1; NPC012-01 NCT Inst Inter-PSP Implementation Guidelines 2025 v1.1", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the name, meaning and recall classification, a fraudulently executed payment, against NPC020-01 v3.1 section 3, FRAD. Confirms the 13 month recall window for this reason and the 15 Banking Business Day response window against NPC010-01 2025 v1.1 section 4.3.2.2, and the free-text fraud information field limited to this reason against NPC012-01 2025 v1.1 section 2.3.1." } ] }, "rail_name": "Nordic Credit Transfer Instant (NCT Inst)", "governing_authority": "Nordic Payments Council", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "nct-inst:LEGL", "id": "LEGL", "rail": "nct-inst", "kind": "reason-code", "name": "Legal reasons (response to a recall or RFRO)", "group": "administrative", "summary": "The Beneficiary PSP answers no because it is not permitted, for legal reasons, to return the funds.", "triggers": [ "A legal constraint stops the Beneficiary PSP from reimbursing after the recall or RFRO" ], "actions": [ "Originator, and the Originator PSP where a recall was for its own error: pursue the Beneficiary directly, outside the scheme" ], "retry": { "allowed": false, "rule": "No. After the Beneficiary PSP responds, the Originator PSP may not send another recall or RFRO for the same transaction (NPC010-01 2025 v1.1 sections 4.3.2.2 and 4.3.2.3). Any further recovery is between Originator and Beneficiary, outside the scheme." }, "facts": { "return_windows": [ { "action": "response to a recall", "by": "Beneficiary PSP", "deadline": "No later than 15 Banking Business Days after it receives the recall, or fewer where local law or community practice requires; a late response breaches the rulebook. A Banking Business Day is a day on which the participant concerned is open for business, so there is no single scheme calendar." }, { "action": "response to an RFRO", "by": "Beneficiary PSP", "deadline": "No later than 15 Banking Business Days after it receives the RFRO, or fewer where local law or community practice requires; a late response breaches the rulebook. A Banking Business Day is a day on which the participant concerned is open for business, so there is no single scheme calendar." } ], "applies_to": "NCT Inst, in any NPC Scheme Currency" }, "caveat": "The rulebook asks for the legal reason to be explained in clear text in a recall refusal (NPC010-01 2025 v1.1 CT-02.03R). The guidance does not say what legal grounds count. A negative response ends the recall or RFRO; the Originator PSP may not send another for the same transaction.", "related": [ "nct-inst:CUST", "nct-inst:AM04" ], "basis": { "sources": "NPC020-01 v3.1 section 3, LEGL; NPC012-01 2025 v1.1 sections 2.4.2 and 2.9.2 (camt.029 negative response codes for a recall and for an RFRO); NPC010-01 2025 v1.1 section 4.3.2.2 and CT-02.01 to CT-02.07 (three recall reasons, 10 Banking Business Days or 13 months, one recall, 15 Banking Business Day response), 4.6.1 AT-R051 and AT-R057; chapter 7 (Banking Business Day); NPC010-01 2025 v1.1 section 4.3.2.3 and its steps 1 to 5 (13 months, one RFRO, 15 Banking Business Day response), 4.6.1 AT-R071 and AT-R077; chapter 7 (Banking Business Day).", "confidence": "high" }, "currency": { "effective_since": "2025-11-21", "effective_note": "NPC010-01 2025 v1.1 and NPC012-01 2025 v1.1 were issued and took effect on 2025-11-21; the 2025 rulebook first took effect on 2025-10-05 as v1.0. NPC020-01 v3.1 was published and took effect on 2026-07-03 as a clarification and correction release and states that it applies to the rulebook effective 5 October 2025. The NPC plans to publish the 2027 rulebook in November 2026 [Unverified: its effective date].", "source_edition": "NPC020-01 v3.1; NPC010-01 2025 v1.1; NPC012-01 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.nordicpaymentscouncil.org/media/bjfjylnq/guidance-on-reason-codes-for-nct-inst-r-transaction-v31.pdf", "source_class": "authoritative_primary", "source_title": "NPC020-01 Guidance on Reason Codes for NCT Inst R-transactions v3.1; NPC010-01 NCT Instant Rulebook 2025 v1.1; NPC012-01 NCT Inst Inter-PSP Implementation Guidelines 2025 v1.1", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the name and meaning, a legal bar on reimbursing a recall or RFRO, and that it is a negative response only against NPC020-01 v3.1 section 3, LEGL. Confirms the 15 Banking Business Day recall and RFRO response windows against NPC010-01 2025 v1.1 sections 4.3.2.2 and 4.3.2.3, and the clear-text legal reason requirement against step CT-02.03R." } ] }, "rail_name": "Nordic Credit Transfer Instant (NCT Inst)", "governing_authority": "Nordic Payments Council", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "nct-inst:MD07", "id": "MD07", "rail": "nct-inst", "kind": "reason-code", "name": "Beneficiary deceased", "group": "account", "summary": "The Beneficiary PSP rejects because the Beneficiary has died.", "triggers": [ "The Beneficiary is deceased" ], "actions": [ "No action is suggested by the guidance" ], "retry": { "allowed": false, "rule": "Not to this Beneficiary's account. Nothing settled, so nothing is re-presented. The Originator may start a new NCT Inst instruction once the cause is dealt with. The scheme sets no retry limit [Unverified]." }, "facts": { "return_windows": [ { "action": "reject (negative confirmation)", "by": "Beneficiary PSP", "deadline": "Instantly. Its negative confirmation must reach its CSM within 7 seconds of the Originator PSP's Time Stamp (or a shorter agreed time-out), and the answer must reach the Originator PSP by the 9th second; the target for any answer at the Originator PSP is 5 seconds" } ], "applies_to": "NCT Inst, in any NPC Scheme Currency" }, "caveat": "Data protection rules in some countries forbid this code; MS03 is the named substitute (NPC020-01 v3.1, MD07). The guidance does not say which countries. How to pay an estate is outside the scheme.", "related": [ "nct-inst:MS03", "nct-inst:AC04" ], "basis": { "sources": "NPC020-01 v3.1 section 3, MD07; NPC012-01 2025 v1.1 section 2.2.2 (pacs.002 reject reason codes); NPC010-01 2025 v1.1 sections 4.2.3 B to D (5-second target, 7-second time-out, 9th-second relay, no unilateral reject by the Originator side) and 4.3.2.1 (CT-01.05R, CT-01.06R, CT-01.08R); NPC010-01 2025 v1.1 section 4.6.1 AT-R002 and AT-R004 (who may reject, and the reasons open to each).", "confidence": "high" }, "currency": { "effective_since": "2025-11-21", "effective_note": "NPC010-01 2025 v1.1 and NPC012-01 2025 v1.1 were issued and took effect on 2025-11-21; the 2025 rulebook first took effect on 2025-10-05 as v1.0. NPC020-01 v3.1 was published and took effect on 2026-07-03 as a clarification and correction release and states that it applies to the rulebook effective 5 October 2025. The NPC plans to publish the 2027 rulebook in November 2026 [Unverified: its effective date].", "source_edition": "NPC020-01 v3.1; NPC010-01 2025 v1.1; NPC012-01 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.nordicpaymentscouncil.org/media/bjfjylnq/guidance-on-reason-codes-for-nct-inst-r-transaction-v31.pdf", "source_class": "authoritative_primary", "source_title": "NPC020-01 Guidance on Reason Codes for NCT Inst R-transactions v3.1; NPC010-01 NCT Instant Rulebook 2025 v1.1; NPC012-01 NCT Inst Inter-PSP Implementation Guidelines 2025 v1.1", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the name, meaning and reject classification, a deceased Beneficiary, against NPC020-01 v3.1 section 3, MD07. Confirms the reject window against NPC010-01 2025 v1.1 section 4.2.3. Confirms the Beneficiary PSP as the sender against the rulebook reject reason table in section 4.6.1 AT-R004, which lists this reason for the Beneficiary PSP only." } ] }, "rail_name": "Nordic Credit Transfer Instant (NCT Inst)", "governing_authority": "Nordic Payments Council", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "nct-inst:MS02", "id": "MS02", "rail": "nct-inst", "kind": "reason-code", "name": "Refusal by the Beneficiary", "group": "authorization", "summary": "The Beneficiary PSP rejects on the Beneficiary's own instruction, for example not to accept funds from a given account, Originator or scheme.", "triggers": [ "The Beneficiary told its PSP to refuse payments from a particular account, Originator or payment scheme" ], "actions": [ "Originator: contact the Beneficiary about how to settle what is owed" ], "retry": { "allowed": false, "rule": "Not by the same route while the Beneficiary's instruction stands. Nothing settled, so nothing is re-presented. The Originator may start a new NCT Inst instruction once the cause is dealt with. The scheme sets no retry limit [Unverified]." }, "facts": { "return_windows": [ { "action": "reject (negative confirmation)", "by": "Beneficiary PSP", "deadline": "Instantly. Its negative confirmation must reach its CSM within 7 seconds of the Originator PSP's Time Stamp (or a shorter agreed time-out), and the answer must reach the Originator PSP by the 9th second; the target for any answer at the Originator PSP is 5 seconds" } ], "applies_to": "NCT Inst, in any NPC Scheme Currency" }, "caveat": "A refusal of a recall or RFRO by the Beneficiary uses CUST, not MS02.", "related": [ "nct-inst:CUST" ], "basis": { "sources": "NPC020-01 v3.1 section 3, MS02; NPC012-01 2025 v1.1 section 2.2.2 (pacs.002 reject reason codes); NPC010-01 2025 v1.1 sections 4.2.3 B to D (5-second target, 7-second time-out, 9th-second relay, no unilateral reject by the Originator side) and 4.3.2.1 (CT-01.05R, CT-01.06R, CT-01.08R); NPC010-01 2025 v1.1 section 4.6.1 AT-R002 and AT-R004 (who may reject, and the reasons open to each).", "confidence": "high" }, "currency": { "effective_since": "2025-11-21", "effective_note": "NPC010-01 2025 v1.1 and NPC012-01 2025 v1.1 were issued and took effect on 2025-11-21; the 2025 rulebook first took effect on 2025-10-05 as v1.0. NPC020-01 v3.1 was published and took effect on 2026-07-03 as a clarification and correction release and states that it applies to the rulebook effective 5 October 2025. The NPC plans to publish the 2027 rulebook in November 2026 [Unverified: its effective date].", "source_edition": "NPC020-01 v3.1; NPC010-01 2025 v1.1; NPC012-01 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.nordicpaymentscouncil.org/media/bjfjylnq/guidance-on-reason-codes-for-nct-inst-r-transaction-v31.pdf", "source_class": "authoritative_primary", "source_title": "NPC020-01 Guidance on Reason Codes for NCT Inst R-transactions v3.1; NPC010-01 NCT Instant Rulebook 2025 v1.1; NPC012-01 NCT Inst Inter-PSP Implementation Guidelines 2025 v1.1", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the name, meaning and reject classification, a refusal on the Beneficiary's own instruction, against NPC020-01 v3.1 section 3, MS02. Confirms the reject window against NPC010-01 2025 v1.1 section 4.2.3. Confirms the Beneficiary PSP as the sender against the rulebook reject reason table in section 4.6.1 AT-R004, which lists this reason for the Beneficiary PSP only, and that a recall or RFRO refusal instead uses CUST, by the separate RCG entries for MS02 and CUST." } ] }, "rail_name": "Nordic Credit Transfer Instant (NCT Inst)", "governing_authority": "Nordic Payments Council", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "nct-inst:MS03", "id": "MS03", "rail": "nct-inst", "kind": "reason-code", "name": "Reason not specified", "group": "administrative", "summary": "A reject with no stated reason. The guidance allows it only where national law, such as data protection law, forbids AC04 or the RR codes, and asks that it be kept to a minimum.", "triggers": [ "National law bars the Beneficiary PSP from giving the precise reason, such as an account closure or a regulatory ground" ], "actions": [ "Originator: contact the Beneficiary about how to settle what is owed" ], "retry": { "allowed": false, "rule": "The cause is unknown to the Originator side, so a blind repeat is unlikely to succeed [Inference]. Nothing settled, so nothing is re-presented. The Originator may start a new NCT Inst instruction once the cause is dealt with. The scheme sets no retry limit [Unverified]." }, "facts": { "return_windows": [ { "action": "reject (negative confirmation)", "by": "CSM or Beneficiary PSP", "deadline": "Instantly, inside the execution time: the target for any answer at the Originator PSP is 5 seconds from its Time Stamp; the Beneficiary PSP's confirmation must reach its CSM within 7 seconds, and the answer must reach the Originator PSP by the 9th second" } ], "applies_to": "NCT Inst, in any NPC Scheme Currency" }, "caveat": "MS03 is also the named substitute for MD07 where MD07 is barred (NPC020-01 v3.1, MD07). The rulebook lets the Originator PSP, a CSM and the Beneficiary PSP all use a reason-not-specified reject (NPC010-01 2025 v1.1 section 4.6.1 AT-R004), which is wider than the guidance's framing [Inference].", "related": [ "nct-inst:AC04", "nct-inst:RR01", "nct-inst:RR02", "nct-inst:RR03", "nct-inst:RR04", "nct-inst:MD07" ], "basis": { "sources": "NPC020-01 v3.1 section 3, MS03 and MD07; NPC012-01 2025 v1.1 section 2.2.2 (pacs.002 reject reason codes); NPC010-01 2025 v1.1 sections 4.2.3 B to D (5-second target, 7-second time-out, 9th-second relay, no unilateral reject by the Originator side) and 4.3.2.1 (CT-01.05R, CT-01.06R, CT-01.08R); NPC010-01 2025 v1.1 section 4.6.1 AT-R002 and AT-R004 (who may reject, and the reasons open to each).", "confidence": "high" }, "currency": { "effective_since": "2025-11-21", "effective_note": "NPC010-01 2025 v1.1 and NPC012-01 2025 v1.1 were issued and took effect on 2025-11-21; the 2025 rulebook first took effect on 2025-10-05 as v1.0. NPC020-01 v3.1 was published and took effect on 2026-07-03 as a clarification and correction release and states that it applies to the rulebook effective 5 October 2025. The NPC plans to publish the 2027 rulebook in November 2026 [Unverified: its effective date].", "source_edition": "NPC020-01 v3.1; NPC010-01 2025 v1.1; NPC012-01 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.nordicpaymentscouncil.org/media/bjfjylnq/guidance-on-reason-codes-for-nct-inst-r-transaction-v31.pdf", "source_class": "authoritative_primary", "source_title": "NPC020-01 Guidance on Reason Codes for NCT Inst R-transactions v3.1; NPC010-01 NCT Instant Rulebook 2025 v1.1; NPC012-01 NCT Inst Inter-PSP Implementation Guidelines 2025 v1.1", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the name, meaning and reject classification, a reason withheld where national law bars a named code, against NPC020-01 v3.1 section 3, MS03. Confirms the reject window against NPC010-01 2025 v1.1 section 4.2.3. Confirms that the rulebook's reject reason table, section 4.6.1 AT-R004, allows a reason-not-specified reject from the Originator PSP, a CSM and the Beneficiary PSP, wider than the guidance's substitute-code framing, as the record notes." } ] }, "rail_name": "Nordic Credit Transfer Instant (NCT Inst)", "governing_authority": "Nordic Payments Council", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "nct-inst:NOAS", "id": "NOAS", "rail": "nct-inst", "kind": "reason-code", "name": "No answer from the Beneficiary", "group": "authorization", "summary": "The Beneficiary PSP answers no because it could not reach the Beneficiary, or the Beneficiary did not reply to its request to authorise the debit.", "triggers": [ "The Beneficiary PSP cannot contact the Beneficiary", "The Beneficiary ignores the Beneficiary PSP's request to authorise returning the funds" ], "actions": [ "Originator, and the Originator PSP where a recall was for its own error: pursue the Beneficiary directly, outside the scheme" ], "retry": { "allowed": false, "rule": "No. After the Beneficiary PSP responds, the Originator PSP may not send another recall or RFRO for the same transaction (NPC010-01 2025 v1.1 sections 4.3.2.2 and 4.3.2.3). Any further recovery is between Originator and Beneficiary, outside the scheme." }, "facts": { "return_windows": [ { "action": "response to a recall", "by": "Beneficiary PSP", "deadline": "No later than 15 Banking Business Days after it receives the recall, or fewer where local law or community practice requires; a late response breaches the rulebook. A Banking Business Day is a day on which the participant concerned is open for business, so there is no single scheme calendar." }, { "action": "response to an RFRO", "by": "Beneficiary PSP", "deadline": "No later than 15 Banking Business Days after it receives the RFRO, or fewer where local law or community practice requires; a late response breaches the rulebook. A Banking Business Day is a day on which the participant concerned is open for business, so there is no single scheme calendar." } ], "applies_to": "NCT Inst, in any NPC Scheme Currency" }, "caveat": "If the Beneficiary has not answered by the end of the 15 Banking Business Days, the rulebook requires the Beneficiary PSP to send this negative response rather than stay silent (NPC010-01 2025 v1.1 sections 4.3.2.2 and 4.3.2.3 step 3). A negative response ends the recall or RFRO; the Originator PSP may not send another for the same transaction.", "related": [ "nct-inst:CUST" ], "basis": { "sources": "NPC020-01 v3.1 section 3, NOAS; NPC012-01 2025 v1.1 sections 2.4.2 and 2.9.2 (camt.029 negative response codes for a recall and for an RFRO); NPC010-01 2025 v1.1 section 4.3.2.2 and CT-02.01 to CT-02.07 (three recall reasons, 10 Banking Business Days or 13 months, one recall, 15 Banking Business Day response), 4.6.1 AT-R051 and AT-R057; chapter 7 (Banking Business Day); NPC010-01 2025 v1.1 section 4.3.2.3 and its steps 1 to 5 (13 months, one RFRO, 15 Banking Business Day response), 4.6.1 AT-R071 and AT-R077; chapter 7 (Banking Business Day).", "confidence": "high" }, "currency": { "effective_since": "2025-11-21", "effective_note": "NPC010-01 2025 v1.1 and NPC012-01 2025 v1.1 were issued and took effect on 2025-11-21; the 2025 rulebook first took effect on 2025-10-05 as v1.0. NPC020-01 v3.1 was published and took effect on 2026-07-03 as a clarification and correction release and states that it applies to the rulebook effective 5 October 2025. The NPC plans to publish the 2027 rulebook in November 2026 [Unverified: its effective date].", "source_edition": "NPC020-01 v3.1; NPC010-01 2025 v1.1; NPC012-01 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.nordicpaymentscouncil.org/media/bjfjylnq/guidance-on-reason-codes-for-nct-inst-r-transaction-v31.pdf", "source_class": "authoritative_primary", "source_title": "NPC020-01 Guidance on Reason Codes for NCT Inst R-transactions v3.1; NPC010-01 NCT Instant Rulebook 2025 v1.1; NPC012-01 NCT Inst Inter-PSP Implementation Guidelines 2025 v1.1", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the name and meaning, no answer reaching the Beneficiary or from the Beneficiary, and that it is a negative response only against NPC020-01 v3.1 section 3, NOAS. Confirms the 15 Banking Business Day recall and RFRO response windows against NPC010-01 2025 v1.1 sections 4.3.2.2 and 4.3.2.3, and that the rulebook requires this response, rather than silence, once that period runs out, against the same sections." } ] }, "rail_name": "Nordic Credit Transfer Instant (NCT Inst)", "governing_authority": "Nordic Payments Council", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "nct-inst:NOOR", "id": "NOOR", "rail": "nct-inst", "kind": "reason-code", "name": "Original transaction never received (response to a recall or RFRO)", "group": "administrative", "summary": "The Beneficiary PSP, or the Beneficiary, says it never received the payment that the recall or RFRO concerns.", "triggers": [ "The recall or RFRO was sent to the wrong Beneficiary PSP" ], "actions": [ "Originator PSP: find the right Beneficiary PSP and direct the request there" ], "retry": { "allowed": false, "rule": "Not to the same Beneficiary PSP. The rulebook allows one recall or RFRO per transaction, and the texts read do not say whether a request sent to the wrong PSP uses up that one chance [Unverified]." }, "facts": { "return_windows": [ { "action": "response to a recall", "by": "Beneficiary PSP", "deadline": "No later than 15 Banking Business Days after it receives the recall, or fewer where local law or community practice requires; a late response breaches the rulebook. A Banking Business Day is a day on which the participant concerned is open for business, so there is no single scheme calendar." }, { "action": "response to an RFRO", "by": "Beneficiary PSP", "deadline": "No later than 15 Banking Business Days after it receives the RFRO, or fewer where local law or community practice requires; a late response breaches the rulebook. A Banking Business Day is a day on which the participant concerned is open for business, so there is no single scheme calendar." } ], "applies_to": "NCT Inst, in any NPC Scheme Currency" }, "caveat": "The guidance's advice to redirect sits uneasily with the one-recall and one-RFRO limits (NPC010-01 2025 v1.1 sections 4.3.2.2 and 4.3.2.3) [Inference].", "related": [ "nct-inst:AG09", "nct-inst:RC01" ], "basis": { "sources": "NPC020-01 v3.1 section 3, NOOR; NPC012-01 2025 v1.1 sections 2.4.2 and 2.9.2 (camt.029 negative response codes for a recall and for an RFRO); NPC010-01 2025 v1.1 section 4.3.2.2 and CT-02.01 to CT-02.07 (three recall reasons, 10 Banking Business Days or 13 months, one recall, 15 Banking Business Day response), 4.6.1 AT-R051 and AT-R057; chapter 7 (Banking Business Day); NPC010-01 2025 v1.1 section 4.3.2.3 and its steps 1 to 5 (13 months, one RFRO, 15 Banking Business Day response), 4.6.1 AT-R071 and AT-R077; chapter 7 (Banking Business Day).", "confidence": "high" }, "currency": { "effective_since": "2025-11-21", "effective_note": "NPC010-01 2025 v1.1 and NPC012-01 2025 v1.1 were issued and took effect on 2025-11-21; the 2025 rulebook first took effect on 2025-10-05 as v1.0. NPC020-01 v3.1 was published and took effect on 2026-07-03 as a clarification and correction release and states that it applies to the rulebook effective 5 October 2025. The NPC plans to publish the 2027 rulebook in November 2026 [Unverified: its effective date].", "source_edition": "NPC020-01 v3.1; NPC010-01 2025 v1.1; NPC012-01 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.nordicpaymentscouncil.org/media/bjfjylnq/guidance-on-reason-codes-for-nct-inst-r-transaction-v31.pdf", "source_class": "authoritative_primary", "source_title": "NPC020-01 Guidance on Reason Codes for NCT Inst R-transactions v3.1; NPC010-01 NCT Instant Rulebook 2025 v1.1; NPC012-01 NCT Inst Inter-PSP Implementation Guidelines 2025 v1.1", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the name and meaning, a recall or RFRO addressed to the wrong Beneficiary PSP, and that it is a negative response only against NPC020-01 v3.1 section 3, NOOR. Confirms the 15 Banking Business Day recall and RFRO response windows against NPC010-01 2025 v1.1 sections 4.3.2.2 and 4.3.2.3, and the one-recall and one-RFRO limit per transaction against the same sections." } ] }, "rail_name": "Nordic Credit Transfer Instant (NCT Inst)", "governing_authority": "Nordic Payments Council", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "nct-inst:RC01", "id": "RC01", "rail": "nct-inst", "kind": "reason-code", "name": "PSP identifier incorrect (invalid BIC)", "group": "technical", "summary": "The BIC in the message is wrong or unknown. The Originator PSP, a CSM or the Beneficiary PSP may reject for it.", "triggers": [ "For a non-EEA payment the Originator gave an eight-character BIC where the full eleven characters were needed", "A CSM or the Beneficiary PSP cannot find the BIC in the inter-PSP message in its BIC directory" ], "actions": [ "Originator: get the full BIC from the Beneficiary for a non-EEA payment", "Originator PSP: put the correct and complete Beneficiary PSP BIC in the message" ], "retry": { "allowed": true, "rule": "With a corrected BIC. Nothing settled, so nothing is re-presented. The Originator may start a new NCT Inst instruction once the cause is dealt with. The scheme sets no retry limit [Unverified]." }, "facts": { "return_windows": [ { "action": "reject (negative confirmation)", "by": "CSM or Beneficiary PSP", "deadline": "Instantly, inside the execution time: the target for any answer at the Originator PSP is 5 seconds from its Time Stamp; the Beneficiary PSP's confirmation must reach its CSM within 7 seconds, and the answer must reach the Originator PSP by the 9th second" } ], "applies_to": "NCT Inst, in any NPC Scheme Currency" }, "caveat": "The guidance's mention of non-EEA payments reflects participants in the Faroe Islands and Greenland and other non-EEA SEPA territories [Inference: the rulebook lets participants be established in those places, NPC010-01 2025 v1.1 section 5.4, not re-read in full].", "related": [ "nct-inst:AC01", "nct-inst:CNOR" ], "basis": { "sources": "NPC020-01 v3.1 section 3, RC01; NPC012-01 2025 v1.1 section 2.2.2 (pacs.002 reject reason codes); NPC010-01 2025 v1.1 sections 4.2.3 B to D (5-second target, 7-second time-out, 9th-second relay, no unilateral reject by the Originator side) and 4.3.2.1 (CT-01.05R, CT-01.06R, CT-01.08R); NPC010-01 2025 v1.1 section 4.6.1 AT-R002 and AT-R004 (who may reject, and the reasons open to each).", "confidence": "high" }, "currency": { "effective_since": "2025-11-21", "effective_note": "NPC010-01 2025 v1.1 and NPC012-01 2025 v1.1 were issued and took effect on 2025-11-21; the 2025 rulebook first took effect on 2025-10-05 as v1.0. NPC020-01 v3.1 was published and took effect on 2026-07-03 as a clarification and correction release and states that it applies to the rulebook effective 5 October 2025. The NPC plans to publish the 2027 rulebook in November 2026 [Unverified: its effective date].", "source_edition": "NPC020-01 v3.1; NPC010-01 2025 v1.1; NPC012-01 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.nordicpaymentscouncil.org/media/bjfjylnq/guidance-on-reason-codes-for-nct-inst-r-transaction-v31.pdf", "source_class": "authoritative_primary", "source_title": "NPC020-01 Guidance on Reason Codes for NCT Inst R-transactions v3.1; NPC010-01 NCT Instant Rulebook 2025 v1.1; NPC012-01 NCT Inst Inter-PSP Implementation Guidelines 2025 v1.1", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the name, meaning and reject classification, an incorrect or unknown BIC, against NPC020-01 v3.1 section 3, RC01. Confirms the reject window against NPC010-01 2025 v1.1 section 4.2.3. Confirms the CSM and Beneficiary PSP as inter-PSP senders against the rulebook reject reason table in section 4.6.1 AT-R004." } ] }, "rail_name": "Nordic Credit Transfer Instant (NCT Inst)", "governing_authority": "Nordic Payments Council", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "nct-inst:RR01", "id": "RR01", "rail": "nct-inst", "kind": "reason-code", "name": "Regulatory reason: Originator account or identification missing", "group": "administrative", "summary": "Rejected on regulatory grounds: the transaction lacks, or gives too little of, the Originator's account or identifier.", "triggers": [ "The Originator's account details or identifier in the transaction do not satisfy regulatory requirements" ], "actions": [ "Originator PSP: check the transaction and, if needed, complete the Originator account before sending again" ], "retry": { "allowed": true, "rule": "Once the Originator details are complete. Nothing settled, so nothing is re-presented. The Originator may start a new NCT Inst instruction once the cause is dealt with. The scheme sets no retry limit [Unverified]." }, "facts": { "return_windows": [ { "action": "reject (negative confirmation)", "by": "CSM or Beneficiary PSP", "deadline": "Instantly, inside the execution time: the target for any answer at the Originator PSP is 5 seconds from its Time Stamp; the Beneficiary PSP's confirmation must reach its CSM within 7 seconds, and the answer must reach the Originator PSP by the 9th second" } ], "applies_to": "NCT Inst, in any NPC Scheme Currency" }, "caveat": "Where national law forbids this code, MS03 is used instead (NPC020-01 v3.1, MS03). The guidance does not name the countries or the regulations.", "related": [ "nct-inst:RR02", "nct-inst:RR04", "nct-inst:MS03" ], "basis": { "sources": "NPC020-01 v3.1 section 3, RR01 and MS03; NPC012-01 2025 v1.1 section 2.2.2 (pacs.002 reject reason codes); NPC010-01 2025 v1.1 sections 4.2.3 B to D (5-second target, 7-second time-out, 9th-second relay, no unilateral reject by the Originator side) and 4.3.2.1 (CT-01.05R, CT-01.06R, CT-01.08R); NPC010-01 2025 v1.1 section 4.6.1 AT-R002 and AT-R004 (who may reject, and the reasons open to each).", "confidence": "high" }, "currency": { "effective_since": "2025-11-21", "effective_note": "NPC010-01 2025 v1.1 and NPC012-01 2025 v1.1 were issued and took effect on 2025-11-21; the 2025 rulebook first took effect on 2025-10-05 as v1.0. NPC020-01 v3.1 was published and took effect on 2026-07-03 as a clarification and correction release and states that it applies to the rulebook effective 5 October 2025. The NPC plans to publish the 2027 rulebook in November 2026 [Unverified: its effective date].", "source_edition": "NPC020-01 v3.1; NPC010-01 2025 v1.1; NPC012-01 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.nordicpaymentscouncil.org/media/bjfjylnq/guidance-on-reason-codes-for-nct-inst-r-transaction-v31.pdf", "source_class": "authoritative_primary", "source_title": "NPC020-01 Guidance on Reason Codes for NCT Inst R-transactions v3.1; NPC010-01 NCT Instant Rulebook 2025 v1.1; NPC012-01 NCT Inst Inter-PSP Implementation Guidelines 2025 v1.1", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the name, meaning and reject classification, missing Originator account details for a regulatory requirement, against NPC020-01 v3.1 section 3, RR01. Confirms the reject window against NPC010-01 2025 v1.1 section 4.2.3. Confirms the CSM and Beneficiary PSP as inter-PSP senders against the rulebook reject reason table in section 4.6.1 AT-R004." } ] }, "rail_name": "Nordic Credit Transfer Instant (NCT Inst)", "governing_authority": "Nordic Payments Council", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "nct-inst:RR02", "id": "RR02", "rail": "nct-inst", "kind": "reason-code", "name": "Regulatory reason: Originator name or address missing or invalid", "group": "administrative", "summary": "Rejected because the Originator's name, or an address where one is required, is missing, or the address format is invalid or no longer allowed.", "triggers": [ "No Originator name in the transaction", "No Originator address on a non-EEA payment, where an address is required", "The Originator address is in a format that is invalid or has been phased out, such as an unstructured address after the November 2026 cut-off" ], "actions": [ "Originator PSP: complete the Originator's name and address and send again" ], "retry": { "allowed": true, "rule": "With a complete and valid name and address. Nothing settled, so nothing is re-presented. The Originator may start a new NCT Inst instruction once the cause is dealt with. The scheme sets no retry limit [Unverified]." }, "facts": { "return_windows": [ { "action": "reject (negative confirmation)", "by": "CSM or Beneficiary PSP", "deadline": "Instantly, inside the execution time: the target for any answer at the Originator PSP is 5 seconds from its Time Stamp; the Beneficiary PSP's confirmation must reach its CSM within 7 seconds, and the answer must reach the Originator PSP by the 9th second" } ], "applies_to": "NCT Inst, in any NPC Scheme Currency" }, "caveat": "For payments within the EEA the Originator address is optional. The guidance cites a November 2026 end for unstructured addresses but no exact day [Unverified: the date is not confirmed in the NPC texts read]. Where national data protection law forbids this code, MS03 is used instead.", "related": [ "nct-inst:RR01", "nct-inst:RR03", "nct-inst:MS03" ], "basis": { "sources": "NPC020-01 v3.1 section 3, RR02 and MS03; NPC012-01 2025 v1.1 section 2.2.2 (pacs.002 reject reason codes); NPC010-01 2025 v1.1 sections 4.2.3 B to D (5-second target, 7-second time-out, 9th-second relay, no unilateral reject by the Originator side) and 4.3.2.1 (CT-01.05R, CT-01.06R, CT-01.08R); NPC010-01 2025 v1.1 section 4.6.1 AT-R002 and AT-R004 (who may reject, and the reasons open to each).", "confidence": "high" }, "currency": { "effective_since": "2025-11-21", "effective_note": "NPC010-01 2025 v1.1 and NPC012-01 2025 v1.1 were issued and took effect on 2025-11-21; the 2025 rulebook first took effect on 2025-10-05 as v1.0. NPC020-01 v3.1 was published and took effect on 2026-07-03 as a clarification and correction release and states that it applies to the rulebook effective 5 October 2025. The NPC plans to publish the 2027 rulebook in November 2026 [Unverified: its effective date].", "source_edition": "NPC020-01 v3.1; NPC010-01 2025 v1.1; NPC012-01 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.nordicpaymentscouncil.org/media/bjfjylnq/guidance-on-reason-codes-for-nct-inst-r-transaction-v31.pdf", "source_class": "authoritative_primary", "source_title": "NPC020-01 Guidance on Reason Codes for NCT Inst R-transactions v3.1; NPC010-01 NCT Instant Rulebook 2025 v1.1; NPC012-01 NCT Inst Inter-PSP Implementation Guidelines 2025 v1.1", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the name, meaning and reject classification, a missing or invalid Originator name or address for a regulatory requirement, against NPC020-01 v3.1 section 3, RR02. Confirms the reject window against NPC010-01 2025 v1.1 section 4.2.3. Confirms the CSM and Beneficiary PSP as inter-PSP senders against the rulebook reject reason table in section 4.6.1 AT-R004. Does not confirm the exact day of the November 2026 unstructured address phase-out; the record is right to leave that unverified." } ] }, "rail_name": "Nordic Credit Transfer Instant (NCT Inst)", "governing_authority": "Nordic Payments Council", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "nct-inst:RR03", "id": "RR03", "rail": "nct-inst", "kind": "reason-code", "name": "Regulatory reason: Beneficiary name or address missing or invalid", "group": "administrative", "summary": "Rejected because the Beneficiary's name is missing, or the Beneficiary address is in an invalid or phased-out format.", "triggers": [ "No Beneficiary name in the transaction", "The Beneficiary address is invalid or in a format no longer allowed, such as an unstructured address after the November 2026 cut-off" ], "actions": [ "Originator PSP: complete the Beneficiary's name and send again" ], "retry": { "allowed": true, "rule": "With a complete name and a valid address format. Nothing settled, so nothing is re-presented. The Originator may start a new NCT Inst instruction once the cause is dealt with. The scheme sets no retry limit [Unverified]." }, "facts": { "return_windows": [ { "action": "reject (negative confirmation)", "by": "CSM or Beneficiary PSP", "deadline": "Instantly, inside the execution time: the target for any answer at the Originator PSP is 5 seconds from its Time Stamp; the Beneficiary PSP's confirmation must reach its CSM within 7 seconds, and the answer must reach the Originator PSP by the 9th second" } ], "applies_to": "NCT Inst, in any NPC Scheme Currency" }, "caveat": "The Beneficiary address itself is optional; a missing address the Beneficiary PSP needs is BE04. The November 2026 phase-out date is not confirmed to the day [Unverified]. Where national data protection law forbids this code, MS03 is used instead.", "related": [ "nct-inst:RR02", "nct-inst:BE04", "nct-inst:MS03" ], "basis": { "sources": "NPC020-01 v3.1 section 3, RR03 and MS03; NPC012-01 2025 v1.1 section 2.2.2 (pacs.002 reject reason codes); NPC010-01 2025 v1.1 sections 4.2.3 B to D (5-second target, 7-second time-out, 9th-second relay, no unilateral reject by the Originator side) and 4.3.2.1 (CT-01.05R, CT-01.06R, CT-01.08R); NPC010-01 2025 v1.1 section 4.6.1 AT-R002 and AT-R004 (who may reject, and the reasons open to each).", "confidence": "high" }, "currency": { "effective_since": "2025-11-21", "effective_note": "NPC010-01 2025 v1.1 and NPC012-01 2025 v1.1 were issued and took effect on 2025-11-21; the 2025 rulebook first took effect on 2025-10-05 as v1.0. NPC020-01 v3.1 was published and took effect on 2026-07-03 as a clarification and correction release and states that it applies to the rulebook effective 5 October 2025. The NPC plans to publish the 2027 rulebook in November 2026 [Unverified: its effective date].", "source_edition": "NPC020-01 v3.1; NPC010-01 2025 v1.1; NPC012-01 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.nordicpaymentscouncil.org/media/bjfjylnq/guidance-on-reason-codes-for-nct-inst-r-transaction-v31.pdf", "source_class": "authoritative_primary", "source_title": "NPC020-01 Guidance on Reason Codes for NCT Inst R-transactions v3.1; NPC010-01 NCT Instant Rulebook 2025 v1.1; NPC012-01 NCT Inst Inter-PSP Implementation Guidelines 2025 v1.1", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the name, meaning and reject classification, a missing Beneficiary name or an invalid or phased-out Beneficiary address format, against NPC020-01 v3.1 section 3, RR03. Confirms the reject window against NPC010-01 2025 v1.1 section 4.2.3. Confirms the CSM and Beneficiary PSP as inter-PSP senders against the rulebook reject reason table in section 4.6.1 AT-R004. Does not confirm the exact day of the November 2026 unstructured address phase-out; the record is right to leave that unverified." } ] }, "rail_name": "Nordic Credit Transfer Instant (NCT Inst)", "governing_authority": "Nordic Payments Council", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "nct-inst:RR04", "id": "RR04", "rail": "nct-inst", "kind": "reason-code", "name": "Regulatory reason", "group": "administrative", "summary": "Rejected for a regulatory reason other than those covered by RR01 to RR03, typically a possible anti-money-laundering, sanctions or terrorist-financing hit.", "triggers": [ "A possible match in anti-money-laundering, sanctions or terrorist-financing screening" ], "actions": [ "Originator: contact the Originator PSP" ], "retry": { "allowed": false, "rule": "Not until the regulatory issue is resolved; the Originator PSP may also be restricted in what it can say [Inference]. Nothing settled, so nothing is re-presented. The Originator may start a new NCT Inst instruction once the cause is dealt with. The scheme sets no retry limit [Unverified]." }, "facts": { "return_windows": [ { "action": "reject (negative confirmation)", "by": "CSM or Beneficiary PSP", "deadline": "Instantly, inside the execution time: the target for any answer at the Originator PSP is 5 seconds from its Time Stamp; the Beneficiary PSP's confirmation must reach its CSM within 7 seconds, and the answer must reach the Originator PSP by the 9th second" } ], "applies_to": "NCT Inst, in any NPC Scheme Currency" }, "caveat": "Where national data protection law forbids this code, MS03 is used instead (NPC020-01 v3.1, RR04). The Originator PSP need not tell the Originator at once when an instruction is rejected on regulatory grounds (NPC010-01 2025 v1.1 section 4.2.3 B).", "related": [ "nct-inst:RR01", "nct-inst:MS03" ], "basis": { "sources": "NPC020-01 v3.1 section 3, RR04; NPC012-01 2025 v1.1 section 2.2.2 (pacs.002 reject reason codes); NPC010-01 2025 v1.1 sections 4.2.3 B to D (5-second target, 7-second time-out, 9th-second relay, no unilateral reject by the Originator side) and 4.3.2.1 (CT-01.05R, CT-01.06R, CT-01.08R); NPC010-01 2025 v1.1 section 4.6.1 AT-R002 and AT-R004 (who may reject, and the reasons open to each).", "confidence": "high" }, "currency": { "effective_since": "2025-11-21", "effective_note": "NPC010-01 2025 v1.1 and NPC012-01 2025 v1.1 were issued and took effect on 2025-11-21; the 2025 rulebook first took effect on 2025-10-05 as v1.0. NPC020-01 v3.1 was published and took effect on 2026-07-03 as a clarification and correction release and states that it applies to the rulebook effective 5 October 2025. The NPC plans to publish the 2027 rulebook in November 2026 [Unverified: its effective date].", "source_edition": "NPC020-01 v3.1; NPC010-01 2025 v1.1; NPC012-01 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.nordicpaymentscouncil.org/media/bjfjylnq/guidance-on-reason-codes-for-nct-inst-r-transaction-v31.pdf", "source_class": "authoritative_primary", "source_title": "NPC020-01 Guidance on Reason Codes for NCT Inst R-transactions v3.1; NPC010-01 NCT Instant Rulebook 2025 v1.1; NPC012-01 NCT Inst Inter-PSP Implementation Guidelines 2025 v1.1", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the name, meaning and reject classification, a regulatory reason other than RR01 through RR03, against NPC020-01 v3.1 section 3, RR04. Confirms the reject window against NPC010-01 2025 v1.1 section 4.2.3. Confirms the CSM and Beneficiary PSP as inter-PSP senders against the rulebook reject reason table in section 4.6.1 AT-R004, and that a regulatory-grounds reject need not be reported to the Originator at once against section 4.2.3 B." } ] }, "rail_name": "Nordic Credit Transfer Instant (NCT Inst)", "governing_authority": "Nordic Payments Council", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "nct-inst:RR09", "id": "RR09", "rail": "nct-inst", "kind": "reason-code", "name": "Structured creditor reference invalid or missing", "group": "administrative", "summary": "A code the Inter-PSP IG lists among its example reject reasons, for a structured creditor reference that is invalid or missing. The IG calls it a proprietary code. NPC020-01 does not describe it.", "triggers": [ "The structured creditor reference in the remittance information is invalid", "A structured reference was expected but is missing" ], "actions": [ "Originator: check the reference with the Beneficiary and send a new instruction [Inference: the texts give no action]" ], "retry": { "allowed": true, "rule": "With a valid reference. Nothing settled, so nothing is re-presented. The Originator may start a new NCT Inst instruction once the cause is dealt with. The scheme sets no retry limit [Unverified]." }, "facts": { "return_windows": [ { "action": "reject (negative confirmation)", "by": "Not stated; the IG list does not say which party uses this code", "deadline": "As for any reject: instantly, inside the execution time, with the 7-second time-out and the 9th-second relay limit as outer bounds" } ], "applies_to": "NCT Inst, in any NPC Scheme Currency" }, "caveat": "The IG allows only a valid OCR or KID reference, or an ISO 11649 RF reference, as a structured creditor reference, and puts the duty to validate it on the Debtor PSP (NPC012-01 2025 v1.1 section 2.1, index 2.192); so the Originator PSP may catch the error before sending [Inference]. Whether RR09 is in the ISO external code set, as opposed to proprietary, is [Unverified]. NPC020-01 v3.1 calls its use cases exhaustive and does not list RR09. The rulebook's list of reject reasons (section 4.6.1 AT-R004) has no reason that plainly matches this code [Inference from reading the list].", "related": [ "nct-inst:AG02", "nct-inst:FF01" ], "basis": { "sources": "NPC012-01 2025 v1.1 section 2.2.2 (pacs.002 reject reason codes); NPC012-01 2025 v1.1 section 2.1.2, indexes 2.191 and 2.192 (structured creditor reference rules); NPC010-01 2025 v1.1 sections 4.2.3 B to D (5-second target, 7-second time-out, 9th-second relay, no unilateral reject by the Originator side) and 4.3.2.1 (CT-01.05R, CT-01.06R, CT-01.08R); NPC010-01 2025 v1.1 section 4.6.1 AT-R002 and AT-R004 (who may reject, and the reasons open to each).", "confidence": "medium" }, "currency": { "effective_since": "2025-11-21", "effective_note": "NPC012-01 2025 v1.1 was issued and took effect on 2025-11-21, together with NPC010-01 2025 v1.1. NPC020-01 v3.1 (effective 2026-07-03) does not describe this code. The NPC plans to publish the 2027 rulebook in November 2026 [Unverified: its effective date].", "source_edition": "NPC012-01 2025 v1.1; NPC010-01 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.nordicpaymentscouncil.org/media/5ukhpf0y/2025-nct-inst-documents.zip", "source_class": "authoritative_primary", "source_title": "NPC012-01 NCT Inst Inter-PSP Implementation Guidelines 2025 v1.1 (in the 2025 NCT Inst documents archive); NPC020-01 Guidance on Reason Codes for NCT Inst R-transactions v3.1", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms that NPC012-01 2025 v1.1 section 2.2.2 lists RR09 as a proprietary code for an invalid or missing structured creditor reference, with a usage rule but no stated sender, and that NPC020-01 v3.1's own, stated-exhaustive, use case table does not list RR09. Confirms the Debtor PSP's duty to validate a structured creditor reference against NPC012-01 2025 v1.1 section 2.1, index 2.192." } ] }, "rail_name": "Nordic Credit Transfer Instant (NCT Inst)", "governing_authority": "Nordic Payments Council", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "nct-inst:TECH", "id": "TECH", "rail": "nct-inst", "kind": "reason-code", "name": "Technical problem (recall reason)", "group": "technical", "summary": "The Originator or the Originator PSP finds that a technical fault produced erroneous payments and recalls them.", "triggers": [ "A fault in the Originator's own systems while creating instructions or files", "A fault in the Originator PSP's NCT Inst systems while handling instructions or turning them into inter-PSP transactions" ], "actions": [ "Originator PSP: send the recall within 10 Banking Business Days of execution", "Originator and Originator PSP: put in measures so the fault does not recur" ], "retry": { "allowed": false, "rule": "One recall per transaction; after a response, or after 15 Banking Business Days without one, only a request for status update is allowed (NPC010-01 2025 v1.1 section 4.3.2.2)." }, "facts": { "return_windows": [ { "action": "recall", "by": "Originator PSP, on its own initiative or at the Originator's request", "deadline": "Sent no later than 10 Banking Business Days after the execution date of the original transaction, or fewer where local law or community practice requires; one recall per transaction. A Banking Business Day is a day on which the participant concerned is open for business, so there is no single scheme calendar." }, { "action": "response to a recall", "by": "Beneficiary PSP", "deadline": "No later than 15 Banking Business Days after it receives the recall, or fewer where local law or community practice requires; a late response breaches the rulebook. A Banking Business Day is a day on which the participant concerned is open for business, so there is no single scheme calendar." } ], "applies_to": "NCT Inst, in any NPC Scheme Currency" }, "caveat": "A recall is a request; the Beneficiary PSP may answer no. The returned amount may be less than the original, as the Beneficiary PSP may take a fee.", "related": [ "nct-inst:DUPL", "nct-inst:FRAD" ], "basis": { "sources": "NPC020-01 v3.1 section 3, TECH; NPC012-01 2025 v1.1 sections 2.3.1 (camt.056 recall codes) and 2.4.2 (camt.029 negative response codes); NPC010-01 2025 v1.1 section 4.3.2.2 and CT-02.01 to CT-02.07 (three recall reasons, 10 Banking Business Days or 13 months, one recall, 15 Banking Business Day response), 4.6.1 AT-R051 and AT-R057; chapter 7 (Banking Business Day).", "confidence": "high" }, "currency": { "effective_since": "2025-11-21", "effective_note": "NPC010-01 2025 v1.1 and NPC012-01 2025 v1.1 were issued and took effect on 2025-11-21; the 2025 rulebook first took effect on 2025-10-05 as v1.0. NPC020-01 v3.1 was published and took effect on 2026-07-03 as a clarification and correction release and states that it applies to the rulebook effective 5 October 2025. The NPC plans to publish the 2027 rulebook in November 2026 [Unverified: its effective date].", "source_edition": "NPC020-01 v3.1; NPC010-01 2025 v1.1; NPC012-01 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.nordicpaymentscouncil.org/media/bjfjylnq/guidance-on-reason-codes-for-nct-inst-r-transaction-v31.pdf", "source_class": "authoritative_primary", "source_title": "NPC020-01 Guidance on Reason Codes for NCT Inst R-transactions v3.1; NPC010-01 NCT Instant Rulebook 2025 v1.1; NPC012-01 NCT Inst Inter-PSP Implementation Guidelines 2025 v1.1", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the name, meaning and recall classification, erroneous payments from a technical fault, against NPC020-01 v3.1 section 3, TECH. Confirms the recall window, 10 Banking Business Days from execution, and the 15 Banking Business Day response window, against NPC010-01 2025 v1.1 section 4.3.2.2, and that a fee may reduce the returned amount against the same section." } ] }, "rail_name": "Nordic Credit Transfer Instant (NCT Inst)", "governing_authority": "Nordic Payments Council", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "nct-inst:TM01", "id": "TM01", "rail": "nct-inst", "kind": "reason-code", "name": "Time-out between the Beneficiary PSP and its CSM", "group": "technical", "summary": "The CSM tells the Beneficiary PSP that its positive confirmation arrived too late. Used only on that leg and never sent to the Originator PSP.", "triggers": [ "The Beneficiary PSP's positive confirmation did not reach its CSM within the maximum execution time", "Connection, processing or validation trouble between the Beneficiary PSP and the CSM" ], "actions": [ "Beneficiary PSP: do not make the funds available to the Beneficiary", "Originator side: it receives AB05 or AB06 for the same event, not TM01" ], "retry": { "allowed": true, "rule": "Nothing settled. The Originator may send a new instruction. The scheme sets no retry limit [Unverified]." }, "facts": { "return_windows": [ { "action": "negative confirmation to the Beneficiary PSP", "by": "CSM of the Beneficiary PSP", "deadline": "Instantly once the 7-second time-out passes without a confirmation from the Beneficiary PSP; the matching reject to the Originator PSP must reach it by the 9th second" } ], "applies_to": "NCT Inst, in any NPC Scheme Currency" }, "caveat": "The IG makes TM01 the only code the CSM may use in a negative confirmation to the Beneficiary PSP (NPC012-01 2025 v1.1 section 2.2.1 A and 2.2.2). The guidance's ISO wording speaks of a cut-off time and its suggested action speaks of resubmitting before the next cut-off, but NCT Inst runs every day around the clock with no cut-off (NPC010-01 2025 v1.1 section 4.2.2); read the action as an EPC leftover [Inference].", "related": [ "nct-inst:AB05", "nct-inst:AB06" ], "basis": { "sources": "NPC020-01 v3.1 section 3, TM01; NPC012-01 2025 v1.1 section 2.2.2 (pacs.002 reject reason codes) and 2.2.1 A; NPC010-01 2025 v1.1 sections 4.2.3 B to D (5-second target, 7-second time-out, 9th-second relay, no unilateral reject by the Originator side) and 4.3.2.1 (CT-01.05R, CT-01.06R, CT-01.08R); NPC010-01 2025 v1.1 section 4.2.2 (no cut-off).", "confidence": "high" }, "currency": { "effective_since": "2025-11-21", "effective_note": "NPC010-01 2025 v1.1 and NPC012-01 2025 v1.1 were issued and took effect on 2025-11-21; the 2025 rulebook first took effect on 2025-10-05 as v1.0. NPC020-01 v3.1 was published and took effect on 2026-07-03 as a clarification and correction release and states that it applies to the rulebook effective 5 October 2025. The NPC plans to publish the 2027 rulebook in November 2026 [Unverified: its effective date].", "source_edition": "NPC020-01 v3.1; NPC010-01 2025 v1.1; NPC012-01 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.nordicpaymentscouncil.org/media/bjfjylnq/guidance-on-reason-codes-for-nct-inst-r-transaction-v31.pdf", "source_class": "authoritative_primary", "source_title": "NPC020-01 Guidance on Reason Codes for NCT Inst R-transactions v3.1; NPC010-01 NCT Instant Rulebook 2025 v1.1; NPC012-01 NCT Inst Inter-PSP Implementation Guidelines 2025 v1.1", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the name and meaning, a late positive confirmation on the Beneficiary PSP to CSM leg, and its restriction to that leg, never sent to the Originator PSP, against NPC020-01 v3.1 section 3, TM01 and NPC012-01 2025 v1.1 section 2.2.1 A. Confirms the reject window against NPC010-01 2025 v1.1 section 4.2.3, and that NCT Inst has no cut-off time, so the guidance's cut-off wording is an EPC leftover, against section 4.2.2." } ] }, "rail_name": "Nordic Credit Transfer Instant (NCT Inst)", "governing_authority": "Nordic Payments Council", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "paypal-dispute:CANCELED_RECURRING_BILLING", "id": "CANCELED_RECURRING_BILLING", "rail": "paypal-dispute", "kind": "reason-code", "name": "Canceled recurring billing", "group": "consumer-dispute", "summary": "The buyer says they were charged under a subscription or other recurring payment after cancelling it. PayPal spells the value the American way. The US agreement gives the buyer a stop right on recurring automatic payments and puts duties on sellers that take them, so this reason usually turns on whether and when the buyer cancelled. Filed with PayPal (channel INTERNAL) it is decided by PayPal; the value also labels a card chargeback or bank reversal for the same complaint (channel EXTERNAL), which the issuer or bank decides.", "triggers": [ "A recurring charge arrived after the buyer cancelled the billing agreement or subscription in PayPal or with the seller", "Seller restarted a stopped recurring payment without new written authorisation", "Buyer asked the card issuer to charge back a recurring card-funded PayPal payment (arrives as EXTERNAL)" ], "actions": [ "Check dispute_channel first: INTERNAL is decided by PayPal, EXTERNAL by the card issuer or bank", "Check the cancellation date against the charge date: a personal account holder's stop is due at least 3 Business Days before the payment", "If the charge was wrong, refund it through PayPal and give the refund identifier as PROOF_OF_REFUND evidence", "If it was owed, give the subscription or billing agreement terms and the cancellation record as OTHER evidence", "Keep the seller duties in view: prior authorisation for amount, frequency and duration; an easy online cancellation route for online sign-ups; no restart without written authorisation; and 10 days' notice when amounts vary", "Answer by the seller_response_due_date; a seller that misses it loses the case to the buyer" ], "retry": { "allowed": true, "rule": "INTERNAL: a seller that loses PayPal's decision may appeal through PRE_ARBITRATION and then ARBITRATION within the appeal period PayPal sets. EXTERNAL: any further round follows the card network's or bank rail's process. Do not charge the buyer again under the cancelled agreement without new written authorisation." }, "facts": { "return_windows": [ { "action": "buyer stops a recurring automatic payment", "by": "buyer (personal account)", "deadline": "At least 3 Business Days before the scheduled payment; PayPal is liable if it fails to stop a payment so ordered" }, { "action": "buyer opens a dispute with PayPal (INTERNAL)", "by": "buyer", "deadline": "No window stated in the US agreement or Purchase Protection page for this reason; PayPal's developer guide gives 180 days from payment for internal disputes generally (guidance)" }, { "action": "seller responds", "by": "seller", "deadline": "By the seller_response_due_date PayPal sets on the dispute" }, { "action": "chargeback or bank reversal (EXTERNAL)", "by": "card issuer or buyer's bank", "deadline": "Set by the card network's or bank rail's rules, not by PayPal" } ], "applies_to": "Recurring and automatic payments under the US User Agreement; channel INTERNAL and EXTERNAL" }, "caveat": "Cancelling stops future payments only; the buyer may still owe the seller for goods or services received or already authorised. UK and Irish accounts treat an unexpected billing agreement payment as a problem to raise within eight weeks, with PayPal answering within ten Business Days (PayPal User Agreement (UK), 2026-07-15, and (Ireland), 2026-01-22, Resolving Problems).", "related": [ "paypal-dispute:CREDIT_NOT_PROCESSED", "paypal-dispute:INCORRECT_AMOUNT", "paypal:recall", "paypal:consumer-law", "paypal:return", "visa-dispute:13.2" ], "basis": { "sources": "Read 2026-09-19: PayPal Disputes OpenAPI specification customer_disputes_v1.json, Disputes 1.11 (https://raw.githubusercontent.com/paypal/paypal-rest-api-specifications/main/openapi/customer_disputes_v1.json, Apache License 2.0), schemas dispute_reason, dispute_channel, dispute (seller_response_due_date); PayPal User Agreement (US), last updated 2026-09-14 (https://www.paypal.com/us/legalhub/paypal/useragreement-full), Automatic payments (buying part) and Accepting preauthorized payments; PayPal developer guide, Dispute reasons and evidence and Disputes Overview (undated); PayPal User Agreement (UK), 2026-07-15, and (Ireland), 2026-01-22, Resolving Problems. Nothing is quoted. Medium because PayPal's agreements do not say how this reason is handled when filed with PayPal; the stop right and seller duties are stated directly.", "confidence": "medium" }, "currency": { "effective_since": "2026-09-14", "effective_note": "Stop right and seller duties dated from the US User Agreement edition read (last updated 2026-09-14). The value is in Disputes 1.11 (repository last pushed 2026-04-07) and unchanged in the served 1.12. The date the value first took effect is unknown.", "source_edition": "Disputes 1.11 (1.12 served); PayPal User Agreement (US) 2026-09-14; developer guide as read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://raw.githubusercontent.com/paypal/paypal-rest-api-specifications/main/openapi/customer_disputes_v1.json", "source_class": "authoritative_primary", "source_title": "PayPal Disputes OpenAPI specification, customer_disputes_v1.json, Disputes 1.11", "checked_on": "2026-09-19", "checked_by": "validator session 2026-09-19", "notes": "Confirms the reason value and its one line meaning, the dispute_channel values INTERNAL and EXTERNAL, and the seller_response_due_date field on the dispute object." }, { "source_url": "https://www.paypal.com/us/legalhub/paypal/useragreement-full", "source_class": "authoritative_primary", "source_title": "PayPal User Agreement (US), last updated 2026-09-14", "checked_on": "2026-09-19", "checked_by": "validator session 2026-09-19", "notes": "Confirms the buyer's 3 Business Day stop right, PayPal's liability if it fails to act on a timely stop order, the seller's duties on prior authorisation, easy cancellation and no restart without written authority, and the 10 day advance notice for a varying amount." } ] }, "rail_name": "PayPal Dispute Reasons", "governing_authority": "PayPal (regional entities; US: PayPal, Inc.)", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "paypal-dispute:CREDIT_NOT_PROCESSED", "id": "CREDIT_NOT_PROCESSED", "rail": "paypal-dispute", "kind": "reason-code", "name": "Credit not processed", "group": "consumer-dispute", "summary": "The buyer says a refund or credit they were due never reached them, typically after returning goods or cancelling. It is not one of the two claim types PayPal's Purchase Protection program names (Item Not Received and Significantly Not as Described), and neither the US agreement nor the program page sets a window or process for it when filed with PayPal (channel INTERNAL). The value also labels a card chargeback or bank reversal for a missing credit (channel EXTERNAL), which the card issuer or bank decides. Either way the seller's answer is the same: show the refund, or show why none is owed.", "triggers": [ "Buyer sent goods back or cancelled an order or service and saw no refund", "Seller promised a credit or partial refund that was not issued", "Buyer asked the card issuer to charge back a card-funded PayPal payment for a missing credit (arrives as EXTERNAL)" ], "actions": [ "Check dispute_channel first: INTERNAL is decided by PayPal, EXTERNAL by the card issuer or bank", "If the refund was made, give its refund identifier as PROOF_OF_REFUND evidence; a refund made through PayPal is the evidence PayPal can match", "If no credit is owed, explain why as OTHER evidence with documents, for example the return policy or proof the item never came back", "Refund through PayPal where the credit is owed; a refund made outside PayPal settles a PayPal case only if PayPal accepts proof the buyer agreed to it", "Answer by the seller_response_due_date; a seller that misses it loses the case to the buyer" ], "retry": { "allowed": true, "rule": "INTERNAL: a seller that loses PayPal's decision may appeal through PRE_ARBITRATION and then ARBITRATION within the appeal period PayPal sets. EXTERNAL: any further round follows the card network's or bank rail's process, not PayPal's." }, "facts": { "return_windows": [ { "action": "buyer opens a dispute with PayPal (INTERNAL)", "by": "buyer", "deadline": "No window stated in the US agreement or Purchase Protection page for this reason; PayPal's developer guide gives 180 days from payment for internal disputes generally (guidance)" }, { "action": "seller responds", "by": "seller", "deadline": "By the seller_response_due_date PayPal sets on the dispute" }, { "action": "chargeback or bank reversal (EXTERNAL)", "by": "card issuer or buyer's bank", "deadline": "Set by the card network's or bank rail's rules, not by PayPal" } ], "applies_to": "PayPal accounts under the US User Agreement; channel INTERNAL and EXTERNAL" }, "caveat": "Which of PayPal's processes handles this reason when the buyer files with PayPal is not stated in the agreements read; PayPal's developer guide says billing errors and duplicate charges go straight to the claim stage but does not say where a missing credit goes. Seller Protection does not list this reason.", "related": [ "paypal-dispute:CANCELED_RECURRING_BILLING", "paypal-dispute:MERCHANDISE_OR_SERVICE_NOT_AS_DESCRIBED", "paypal:refund", "paypal:return", "paypal:liability", "visa-dispute:13.6" ], "basis": { "sources": "Read 2026-09-19: PayPal Disputes OpenAPI specification customer_disputes_v1.json, Disputes 1.11 (https://raw.githubusercontent.com/paypal/paypal-rest-api-specifications/main/openapi/customer_disputes_v1.json, Apache License 2.0), schemas dispute_reason, dispute_channel, dispute (seller_response_due_date); PayPal developer guide, Dispute reasons and evidence and Disputes Overview (https://developer.paypal.com/disputes/reasons-evidence.md and /overview.md, undated); PayPal's Purchase Protection Program (US), last updated 2026-01-26; PayPal User Agreement (US), last updated 2026-09-14, Impact of various purchase protection processes on sellers; PayPal's Seller Protection Program (US), 2026-01-26. Nothing is quoted. Medium because PayPal's agreements do not say how this reason is handled when filed with PayPal; the process lines rest on the developer guide.", "confidence": "medium" }, "currency": { "effective_since": "2026-04-07", "effective_note": "Dated from the last push to PayPal's specification repository (2026-04-07), which holds Disputes 1.11; the served 1.12 has the same value. The US User Agreement read was last updated 2026-09-14 and the protection pages 2026-01-26. The date the value first took effect is unknown.", "source_edition": "Disputes 1.11 (1.12 served); developer guide as read 2026-09-19; PayPal User Agreement (US) 2026-09-14", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://raw.githubusercontent.com/paypal/paypal-rest-api-specifications/main/openapi/customer_disputes_v1.json", "source_class": "authoritative_primary", "source_title": "PayPal Disputes OpenAPI specification, customer_disputes_v1.json, Disputes 1.11", "checked_on": "2026-09-19", "checked_by": "validator session 2026-09-19", "notes": "Confirms the reason value and its one line meaning, that it is one of the dispute_channel values INTERNAL or EXTERNAL, and the seller_response_due_date field on the dispute object." }, { "source_url": "https://developer.paypal.com/disputes/overview.md", "source_class": "public_primary", "source_title": "PayPal developer guide, Overview", "checked_on": "2026-09-19", "checked_by": "validator session 2026-09-19", "notes": "Confirms the general 180 day internal dispute window and that PayPal decides an internal case while the card issuer or bank decides an external one; the guide does not single out this reason by name, matching the record's own caveat that no dedicated process is stated for it." } ] }, "rail_name": "PayPal Dispute Reasons", "governing_authority": "PayPal (regional entities; US: PayPal, Inc.)", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "paypal-dispute:DUPLICATE_TRANSACTION", "id": "DUPLICATE_TRANSACTION", "rail": "paypal-dispute", "kind": "reason-code", "name": "Duplicate transaction", "group": "administrative", "summary": "The buyer says one purchase was charged more than once. It is a processing error, not a complaint about the goods. PayPal's developer guide says duplicate charges go straight to the claim stage, with no inquiry between buyer and seller. Filed with PayPal (channel INTERNAL) PayPal decides it; the value also labels a card chargeback or bank reversal for a duplicate (channel EXTERNAL), which the issuer or bank decides. The seller's answer is to show that the second charge was refunded or that the charges were for separate purchases.", "triggers": [ "The same order was charged twice, for example after a repeated checkout submission [Inference]", "Buyer sees two identical PayPal payments to the same seller and recognises only one purchase", "Buyer asked the card issuer to charge back a duplicated card-funded PayPal payment (arrives as EXTERNAL)" ], "actions": [ "Check dispute_channel first: INTERNAL is decided by PayPal, EXTERNAL by the card issuer or bank", "If the charge was duplicated, refund it through PayPal and give the refund identifier as PROOF_OF_REFUND evidence", "If each charge was a separate purchase, show it with OTHER evidence such as separate orders, invoices or delivery records", "Answer by the seller_response_due_date; a seller that misses it loses the case to the buyer" ], "retry": { "allowed": true, "rule": "INTERNAL: a seller that loses PayPal's decision may appeal through PRE_ARBITRATION and then ARBITRATION within the appeal period PayPal sets. EXTERNAL: any further round follows the card network's or bank rail's process, not PayPal's." }, "facts": { "return_windows": [ { "action": "buyer opens a dispute with PayPal (INTERNAL)", "by": "buyer", "deadline": "No window stated in the US agreement or Purchase Protection page for this reason; PayPal's developer guide gives 180 days from payment for internal disputes generally (guidance)" }, { "action": "seller responds", "by": "seller", "deadline": "By the seller_response_due_date PayPal sets on the dispute" }, { "action": "chargeback or bank reversal (EXTERNAL)", "by": "card issuer or buyer's bank", "deadline": "Set by the card network's or bank rail's rules, not by PayPal" } ], "applies_to": "PayPal accounts under the US User Agreement; channel INTERNAL and EXTERNAL" }, "caveat": "Where PayPal itself recorded or took a payment twice, the US agreement's error resolution rules give the account holder a separate route: report within 60 days of the statement, with PayPal deciding within 10 Business Days or crediting provisionally (PayPal User Agreement (US), 2026-09-14, Error Resolution). Which route PayPal uses for a buyer-filed duplicate is not stated in the agreement.", "related": [ "paypal-dispute:INCORRECT_AMOUNT", "paypal-dispute:PAYMENT_BY_OTHER_MEANS", "paypal:return", "paypal:consumer-law", "paypal:liability", "visa-dispute:12.6" ], "basis": { "sources": "Read 2026-09-19: PayPal Disputes OpenAPI specification customer_disputes_v1.json, Disputes 1.11 (https://raw.githubusercontent.com/paypal/paypal-rest-api-specifications/main/openapi/customer_disputes_v1.json, Apache License 2.0), schemas dispute_reason, dispute_channel, dispute (seller_response_due_date); PayPal developer guide, Dispute reasons and evidence and Disputes Overview (https://developer.paypal.com/disputes/reasons-evidence.md and /overview.md, undated); PayPal User Agreement (US), last updated 2026-09-14, Error Resolution. Nothing is quoted. Medium because PayPal's agreements do not say how this reason is handled when filed with PayPal; the process lines rest on the developer guide.", "confidence": "medium" }, "currency": { "effective_since": "2026-04-07", "effective_note": "Dated from the last push to PayPal's specification repository (2026-04-07), which holds Disputes 1.11; the served 1.12 has the same value. The US User Agreement read was last updated 2026-09-14. The date the value first took effect is unknown.", "source_edition": "Disputes 1.11 (1.12 served); developer guide as read 2026-09-19; PayPal User Agreement (US) 2026-09-14", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://raw.githubusercontent.com/paypal/paypal-rest-api-specifications/main/openapi/customer_disputes_v1.json", "source_class": "authoritative_primary", "source_title": "PayPal Disputes OpenAPI specification, customer_disputes_v1.json, Disputes 1.11", "checked_on": "2026-09-19", "checked_by": "validator session 2026-09-19", "notes": "Confirms the reason value and its one line meaning, the dispute_channel values INTERNAL and EXTERNAL, and the seller_response_due_date field on the dispute object." }, { "source_url": "https://developer.paypal.com/disputes/overview.md", "source_class": "public_primary", "source_title": "PayPal developer guide, Overview", "checked_on": "2026-09-19", "checked_by": "validator session 2026-09-19", "notes": "Confirms that billing or subscription errors such as duplicate charges are handled directly as claims rather than starting in the inquiry stage, and the general 180 day internal dispute window." } ] }, "rail_name": "PayPal Dispute Reasons", "governing_authority": "PayPal (regional entities; US: PayPal, Inc.)", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "paypal-dispute:INCORRECT_AMOUNT", "id": "INCORRECT_AMOUNT", "rail": "paypal-dispute", "kind": "reason-code", "name": "Incorrect amount", "group": "administrative", "summary": "The buyer says they were charged a different amount from the one agreed. It is a billing error, not a complaint about the goods; PayPal's developer guide says billing errors go straight to the claim stage. Filed with PayPal (channel INTERNAL) PayPal decides it; the value also labels a card chargeback or bank reversal for a wrong amount (channel EXTERNAL), which the issuer or bank decides. The seller either refunds the difference or shows why the amount charged was right.", "triggers": [ "The amount taken differs from the price shown at checkout or on the invoice", "A post-checkout change to the order (added shipping, partial cancellation) left the buyer charged more than they expected", "Buyer asked the card issuer to charge back a card-funded PayPal payment for a wrong amount (arrives as EXTERNAL)" ], "actions": [ "Check dispute_channel first: INTERNAL is decided by PayPal, EXTERNAL by the card issuer or bank", "If the buyer was overcharged, refund the difference through PayPal and give the refund identifier as PROOF_OF_REFUND evidence", "If the amount was right, explain the difference as OTHER evidence, for example taxes, shipping or an order change the buyer accepted", "Where PayPal converted currency, note that the buyer authorised PayPal's rate including its spread, so an exchange-rate difference alone is not an overcharge [Inference]", "Answer by the seller_response_due_date; a seller that misses it loses the case to the buyer" ], "retry": { "allowed": true, "rule": "INTERNAL: a seller that loses PayPal's decision may appeal through PRE_ARBITRATION and then ARBITRATION within the appeal period PayPal sets. EXTERNAL: any further round follows the card network's or bank rail's process, not PayPal's." }, "facts": { "return_windows": [ { "action": "buyer opens a dispute with PayPal (INTERNAL)", "by": "buyer", "deadline": "No window stated in the US agreement or Purchase Protection page for this reason; PayPal's developer guide gives 180 days from payment for internal disputes generally (guidance)" }, { "action": "seller responds", "by": "seller", "deadline": "By the seller_response_due_date PayPal sets on the dispute" }, { "action": "chargeback or bank reversal (EXTERNAL)", "by": "card issuer or buyer's bank", "deadline": "Set by the card network's or bank rail's rules, not by PayPal" } ], "applies_to": "PayPal accounts under the US User Agreement; channel INTERNAL and EXTERNAL" }, "caveat": "The US agreement lets a seller charge a revised amount after checkout when the order changes, under the buyer's original authorisation; whether that authorisation covers a given increase is a question for the case. Separately, where PayPal itself debited the wrong amount, the agreement's error resolution rules apply: report within 60 days of the statement, PayPal decides within 10 Business Days or credits provisionally (PayPal User Agreement (US), 2026-09-14, Authorization of specific transactions; Error Resolution).", "related": [ "paypal-dispute:DUPLICATE_TRANSACTION", "paypal-dispute:CANCELED_RECURRING_BILLING", "paypal:return", "paypal:consumer-law", "paypal:refund", "visa-dispute:12.5" ], "basis": { "sources": "Read 2026-09-19: PayPal Disputes OpenAPI specification customer_disputes_v1.json, Disputes 1.11 (https://raw.githubusercontent.com/paypal/paypal-rest-api-specifications/main/openapi/customer_disputes_v1.json, Apache License 2.0), schemas dispute_reason, dispute_channel, dispute (seller_response_due_date); PayPal developer guide, Dispute reasons and evidence and Disputes Overview (https://developer.paypal.com/disputes/reasons-evidence.md and /overview.md, undated); PayPal User Agreement (US), last updated 2026-09-14, Authorization of specific transactions, How we convert currency, Error Resolution. Nothing is quoted. Medium because PayPal's agreements do not say how this reason is handled when filed with PayPal; the process lines rest on the developer guide.", "confidence": "medium" }, "currency": { "effective_since": "2026-04-07", "effective_note": "Dated from the last push to PayPal's specification repository (2026-04-07), which holds Disputes 1.11; the served 1.12 has the same value. The US User Agreement read was last updated 2026-09-14. The date the value first took effect is unknown.", "source_edition": "Disputes 1.11 (1.12 served); developer guide as read 2026-09-19; PayPal User Agreement (US) 2026-09-14", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://raw.githubusercontent.com/paypal/paypal-rest-api-specifications/main/openapi/customer_disputes_v1.json", "source_class": "authoritative_primary", "source_title": "PayPal Disputes OpenAPI specification, customer_disputes_v1.json, Disputes 1.11", "checked_on": "2026-09-19", "checked_by": "validator session 2026-09-19", "notes": "Confirms the reason value and its one line meaning, the dispute_channel values INTERNAL and EXTERNAL, and the seller_response_due_date field on the dispute object." }, { "source_url": "https://developer.paypal.com/disputes/overview.md", "source_class": "public_primary", "source_title": "PayPal developer guide, Overview", "checked_on": "2026-09-19", "checked_by": "validator session 2026-09-19", "notes": "Confirms that billing errors are handled directly as claims rather than starting in the inquiry stage, and the general 180 day internal dispute window." } ] }, "rail_name": "PayPal Dispute Reasons", "governing_authority": "PayPal (regional entities; US: PayPal, Inc.)", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "paypal-dispute:MERCHANDISE_OR_SERVICE_NOT_AS_DESCRIBED", "id": "MERCHANDISE_OR_SERVICE_NOT_AS_DESCRIBED", "rail": "paypal-dispute", "kind": "reason-code", "name": "Merchandise or service not as described", "group": "consumer-dispute", "summary": "The buyer says what arrived differs materially from the seller's description. Filed with PayPal (channel INTERNAL) this is a Significantly Not as Described case under PayPal's buyer protection program, which PayPal decides and may settle by having the buyer send the item back. The same value also labels a card chargeback or bank reversal (channel EXTERNAL), decided by the issuer or bank. The specification lets the product details of a dispute carry sub-reasons DAMAGED, DIFFERENT, MISSING_PARTS or OTHER, and the service details DAMAGED, DIFFERENT, INCOMPLETE or OTHER [Inference: the specification does not tie them to this reason, but they describe its cases]. Seller Protection never covers this reason, whichever channel it arrives on.", "triggers": [ "The item arrived broken by shipping, or cannot be used and the listing did not say so", "The listing misled the buyer: fewer units than bought, major parts missing, a counterfeit sold as genuine, used sold as new, or simply a different thing", "A service not delivered as agreed (sub-reasons for services include INCOMPLETE)", "Buyer took a card-funded PayPal payment to the card issuer for goods not as described (arrives as EXTERNAL)" ], "actions": [ "Check dispute_channel first: INTERNAL follows PayPal's rules and deadlines, EXTERNAL the card network's or bank's", "Offer a refund, a refund on return, or a replacement in the inquiry stage; the API supports these offer types", "If contesting, give the listing or product description, item link, return policy or contract as OTHER evidence; if already refunded, give the refund identifier as PROOF_OF_REFUND", "Expect no Seller Protection: a loss on this reason stays with the seller, who may not get the item back, may have to take it back and pay return shipping, and must refund in full for a counterfeit", "Answer by the seller_response_due_date; a seller that misses it loses the case to the buyer" ], "retry": { "allowed": true, "rule": "INTERNAL: a seller that loses PayPal's decision may appeal it, first in the PRE_ARBITRATION stage and then in ARBITRATION, each within the appeal period PayPal sets; unappealed cases close. A buyer who loses may still dispute a card-funded payment with the card issuer, whose rights for unsatisfactory items can be wider than PayPal's. EXTERNAL: the seller answers once through PayPal, and any further round is the card network's or bank's process." }, "facts": { "return_windows": [ { "action": "buyer opens a dispute with PayPal (INTERNAL)", "by": "buyer", "deadline": "Within 30 days after delivery or fulfilment, or within 180 days after sending the payment, whichever comes first" }, { "action": "escalate the dispute to a claim", "by": "buyer, seller or PayPal", "deadline": "Within 20 days after the dispute is opened, or PayPal closes it" }, { "action": "buyer returns the item when PayPal requires it", "by": "buyer", "deadline": "In the time PayPal sets, at the buyer's cost, with proof of delivery showing at least city and state or zip, the date and the carrier" }, { "action": "seller responds to the claim", "by": "seller", "deadline": "By the seller_response_due_date PayPal sets on the dispute; PayPal's business guidance describes this as 10 days (guidance, not in the agreement)" }, { "action": "chargeback or bank reversal (EXTERNAL)", "by": "card issuer or buyer's bank", "deadline": "Set by the card network's or bank rail's rules, not by PayPal" } ], "applies_to": "PayPal accounts under the US User Agreement; channel INTERNAL (Purchase Protection, Significantly Not as Described) and EXTERNAL (card chargeback or bank reversal)" }, "caveat": "Buyer's remorse is not enough: PayPal may refuse to treat as misdescribed a used item showing light scratches, a flaw the listing disclosed, or an accurately listed item that disappointed the buyer or that the buyer no longer wants. Custom-made items are excluded from this claim type. UK and Irish buyers have the same 30, 180 and 20-day figures (PayPal's Buyer Protection Program (UK), 2026-09-07; (Ireland), 2024-05-28).", "related": [ "paypal-dispute:MERCHANDISE_OR_SERVICE_NOT_RECEIVED", "paypal-dispute:CREDIT_NOT_PROCESSED", "paypal:return", "paypal:liability", "paypal:refund", "visa-dispute:13.3" ], "basis": { "sources": "Read 2026-09-19: PayPal Disputes OpenAPI specification customer_disputes_v1.json, Disputes 1.11 (https://raw.githubusercontent.com/paypal/paypal-rest-api-specifications/main/openapi/customer_disputes_v1.json, Apache License 2.0), schemas dispute_reason, sub_reasons, definitions-sub_reasons, offer_type, dispute_channel, dispute (seller_response_due_date); PayPal's Purchase Protection Program (US), last updated 2026-01-26 (https://www.paypal.com/us/legalhub/paypal/buyer-protection), Significantly Not as Described Claims, Ineligible Items and Transactions, Online Dispute Resolution Process Step 4, Opening Disputes: Timeframes, Dispute with PayPal or Your Card Issuer; PayPal's Seller Protection Program (US), 2026-01-26, Ineligible Items and Transactions; PayPal User Agreement (US), last updated 2026-09-14, Impact of various purchase protection processes on sellers; PayPal developer guide, Dispute reasons and evidence (undated); PayPal Business Resource Center article on dispute transactions (2026-07-17), for the 10-day response only; UK and Ireland Buyer Protection pages. Nothing is quoted. High because the value, windows and deciders come from PayPal's own specification and agreements; the 10-day line is marked guidance.", "confidence": "high" }, "currency": { "effective_since": "2026-01-26", "effective_note": "Windows dated from the US Purchase Protection and Seller Protection pages (last updated 2026-01-26); seller consequences from the US User Agreement (last updated 2026-09-14). The value is in Disputes 1.11 (repository last pushed 2026-04-07) and unchanged in the served 1.12. The date the value first took effect is unknown. The US Policy Updates page (last updated 2026-08-06) listed no notice touching buyer disputes on 2026-09-19.", "source_edition": "Disputes 1.11 (1.12 served); Purchase Protection and Seller Protection (US) 2026-01-26; PayPal User Agreement (US) 2026-09-14", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.paypal.com/us/legalhub/paypal/buyer-protection", "source_class": "authoritative_primary", "source_title": "PayPal's Purchase Protection Program (US), last updated 2026-01-26", "checked_on": "2026-09-19", "checked_by": "validator session 2026-09-19", "notes": "Confirms the Significantly Not as Described claim type, its 30 and 180 day filing window, the buyer return step, the custom made item exclusion, and the disclosed defect and buyer's remorse exclusions listed on the page." } ] }, "rail_name": "PayPal Dispute Reasons", "governing_authority": "PayPal (regional entities; US: PayPal, Inc.)", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "paypal-dispute:MERCHANDISE_OR_SERVICE_NOT_RECEIVED", "id": "MERCHANDISE_OR_SERVICE_NOT_RECEIVED", "rail": "paypal-dispute", "kind": "reason-code", "name": "Merchandise or service not received", "group": "consumer-dispute", "summary": "The buyer says the goods or service paid for never arrived. Filed with PayPal (channel INTERNAL) this is an Item Not Received case under PayPal's buyer protection program: it starts as an inquiry between buyer and seller, can be escalated to a claim, and PayPal decides it. The same value also labels a chargeback or bank reversal the buyer took to the card issuer or bank (channel EXTERNAL), which the issuer or bank decides under its own rules; PayPal only relays evidence. It is the one buyer claim type, with Unauthorized Transaction, that Seller Protection can cover.", "triggers": [ "No delivery of a physical item the buyer paid for from their PayPal account, or no performance of a paid service", "Seller cannot show tracking with a delivered status at the address on the transaction", "Buyer asked the card issuer to charge back a card-funded PayPal payment for non-receipt (arrives as EXTERNAL)" ], "actions": [ "Check dispute_channel first: INTERNAL follows PayPal's rules and deadlines, EXTERNAL follows the card network's or bank's", "Answer in the inquiry stage: message the buyer, send tracking, or offer a refund before the case is escalated", "If the item was delivered, give proof of fulfilment (carrier name and tracking number, or a delivery signature or receipt) as PROOF_OF_FULFILLMENT evidence; if already refunded, give the refund identifier as PROOF_OF_REFUND", "For Seller Protection, the seller must have a US primary address, have shipped to the address on the transaction, and hold proof of delivery; an item picked up in person, or a claim the buyer took to the card issuer, is not covered", "Answer by the seller_response_due_date; a seller that misses it loses the case to the buyer" ], "retry": { "allowed": true, "rule": "INTERNAL: a seller that loses PayPal's decision may appeal it, first in the PRE_ARBITRATION stage and then in ARBITRATION, each within the appeal period PayPal sets; unappealed cases close. A buyer who loses may still dispute a card-funded payment with the card issuer. EXTERNAL: the seller answers once through PayPal, and any further round is the card network's or bank's process, not PayPal's." }, "facts": { "return_windows": [ { "action": "buyer opens a dispute with PayPal (INTERNAL)", "by": "buyer", "deadline": "Within 180 days after sending the payment to the seller" }, { "action": "escalate the dispute to a claim", "by": "buyer, seller or PayPal", "deadline": "Within 20 days after the dispute is opened, or PayPal closes it; PayPal may make the buyer wait until at least 7 days after the transaction before escalating" }, { "action": "seller responds to the claim", "by": "seller", "deadline": "By the seller_response_due_date PayPal sets on the dispute; PayPal's business guidance describes this as 10 days (guidance, not in the agreement)" }, { "action": "chargeback or bank reversal (EXTERNAL)", "by": "card issuer or buyer's bank", "deadline": "Set by the card network's or bank rail's rules, not by PayPal" } ], "applies_to": "PayPal accounts under the US User Agreement; channel INTERNAL (Purchase Protection, Item Not Received) and EXTERNAL (card chargeback or bank reversal)" }, "caveat": "PayPal's own lifecycle stage named CHARGEBACK is its claim stage for INTERNAL cases, not a card chargeback. No Item Not Received claim lies for items collected in person (other than in-store PayPal QR code payments), friends and family payments, or excluded categories. UK and Irish buyers have the same 180-day and 20-day figures under their Buyer Protection pages (PayPal's Buyer Protection Program (UK), 2026-09-07; (Ireland), 2024-05-28).", "related": [ "paypal-dispute:MERCHANDISE_OR_SERVICE_NOT_AS_DESCRIBED", "paypal-dispute:UNAUTHORISED", "paypal:return", "paypal:liability", "paypal:decision-points", "visa-dispute:13.1" ], "basis": { "sources": "Read 2026-09-19: PayPal Disputes OpenAPI specification customer_disputes_v1.json, Disputes 1.11 (https://raw.githubusercontent.com/paypal/paypal-rest-api-specifications/main/openapi/customer_disputes_v1.json, Apache License 2.0), schemas dispute_reason, dispute_channel, dispute_lifecycle_stage, dispute (seller_response_due_date); PayPal's Purchase Protection Program (US), last updated 2026-01-26 (https://www.paypal.com/us/legalhub/paypal/buyer-protection), Item Not Received Claims, Ineligible Items and Transactions, Online Dispute Resolution Process, Opening Disputes: Timeframes, Dispute with PayPal or Your Card Issuer; PayPal's Seller Protection Program (US), last updated 2026-01-26, What's Eligible, Basic Requirements, Item Not Received Additional Requirement; PayPal User Agreement (US), last updated 2026-09-14, Payments that are invalidated and reversed; PayPal developer guide, Dispute reasons and evidence and Disputes Overview (undated); PayPal Business Resource Center article on dispute transactions (2026-07-17), for the 10-day response only; UK and Ireland Buyer Protection pages. Nothing is quoted. High because the value, windows and deciders come from PayPal's own specification and agreements; the 10-day line is marked guidance.", "confidence": "high" }, "currency": { "effective_since": "2026-01-26", "effective_note": "Windows dated from the US Purchase Protection and Seller Protection pages (last updated 2026-01-26); reversal rules from the US User Agreement (last updated 2026-09-14). The value is in Disputes 1.11 (repository last pushed 2026-04-07) and unchanged in the served 1.12. The date the value first took effect is unknown. The US Policy Updates page (last updated 2026-08-06) listed no notice touching buyer disputes on 2026-09-19.", "source_edition": "Disputes 1.11 (1.12 served); Purchase Protection and Seller Protection (US) 2026-01-26; PayPal User Agreement (US) 2026-09-14", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.paypal.com/us/legalhub/paypal/buyer-protection", "source_class": "authoritative_primary", "source_title": "PayPal's Purchase Protection Program (US), last updated 2026-01-26", "checked_on": "2026-09-19", "checked_by": "validator session 2026-09-19", "notes": "Confirms the Item Not Received claim type and its 180 day filing window, the 20 day escalation step, the proof of shipment or delivery exclusion, and the Seller Protection conditions on a US address, shipment to the transaction address and proof of delivery read on the Seller Protection page." } ] }, "rail_name": "PayPal Dispute Reasons", "governing_authority": "PayPal (regional entities; US: PayPal, Inc.)", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "paypal-dispute:OTHER", "id": "OTHER", "rail": "paypal-dispute", "kind": "reason-code", "name": "Other", "group": "consumer-dispute", "summary": "The catch-all among PayPal's ten dispute reasons, used when the buyer's complaint fits none of the named ones. PayPal gives it no meaning beyond that. Filed with PayPal (channel INTERNAL) PayPal decides it; the value can also label a card chargeback or bank reversal whose reason PayPal does not map to a named value (channel EXTERNAL), decided by the issuer or bank [Inference: PayPal does not say how it maps issuer reasons]. For a card case, the issuer's own code, where PayPal passes it, is in external_reason_code.", "triggers": [ "A buyer complaint that matches no named reason [Inference: PayPal gives no examples]", "A card chargeback whose issuer reason has no PayPal equivalent (arrives as EXTERNAL) [Inference]" ], "actions": [ "Check dispute_channel first: INTERNAL is decided by PayPal, EXTERNAL by the card issuer or bank", "On a card case, read external_reason_code for the issuer's own reason, available only for unbranded card transactions", "If already refunded, give the refund identifier as PROOF_OF_REFUND evidence; otherwise answer with notes and documents as OTHER evidence", "Answer by the seller_response_due_date; a seller that misses it loses the case to the buyer" ], "retry": { "allowed": true, "rule": "INTERNAL: a seller that loses PayPal's decision may appeal through PRE_ARBITRATION and then ARBITRATION within the appeal period PayPal sets. EXTERNAL: any further round follows the card network's or bank rail's process, not PayPal's." }, "facts": { "return_windows": [ { "action": "buyer opens a dispute with PayPal (INTERNAL)", "by": "buyer", "deadline": "No window stated in the US agreement or Purchase Protection page for this reason; PayPal's developer guide gives 180 days from payment for internal disputes generally (guidance)" }, { "action": "seller responds", "by": "seller", "deadline": "By the seller_response_due_date PayPal sets on the dispute" }, { "action": "chargeback or bank reversal (EXTERNAL)", "by": "card issuer or buyer's bank", "deadline": "Set by the card network's or bank rail's rules, not by PayPal" } ], "applies_to": "PayPal accounts under the US User Agreement; channel INTERNAL and EXTERNAL" }, "caveat": "The consumer-dispute group is an inference: PayPal does not say who uses this value or for what. A buyer may change the reason on an open dispute, so a case filed as OTHER can later carry a named reason (PayPal developer guide, Disputes lifecycle stages reference).", "related": [ "paypal-dispute:PROBLEM_WITH_REMITTANCE", "paypal:return", "paypal:messages", "paypal:liability" ], "basis": { "sources": "Read 2026-09-19: PayPal Disputes OpenAPI specification customer_disputes_v1.json, Disputes 1.11 (https://raw.githubusercontent.com/paypal/paypal-rest-api-specifications/main/openapi/customer_disputes_v1.json, Apache License 2.0), schemas dispute_reason, dispute_channel, dispute (external_reason_code, seller_response_due_date); PayPal developer guide, Dispute reasons and evidence, Disputes lifecycle stages reference and Disputes Overview (https://developer.paypal.com/disputes/reasons-evidence.md, /disputes/disputes-lifecycle.md and /disputes/overview.md, undated). Nothing is quoted. Medium because PayPal defines the value only as a catch-all and its use is inferred.", "confidence": "medium" }, "currency": { "effective_since": "2026-04-07", "effective_note": "Dated from the last push to PayPal's specification repository (2026-04-07), which holds Disputes 1.11; the served 1.12 has the same value. The date the value first took effect is unknown.", "source_edition": "Disputes 1.11 (1.12 served); developer guide as read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://raw.githubusercontent.com/paypal/paypal-rest-api-specifications/main/openapi/customer_disputes_v1.json", "source_class": "authoritative_primary", "source_title": "PayPal Disputes OpenAPI specification, customer_disputes_v1.json, Disputes 1.11", "checked_on": "2026-09-19", "checked_by": "validator session 2026-09-19", "notes": "Confirms the catch-all reason value, the dispute_channel values INTERNAL and EXTERNAL, the external_reason_code field limited to unbranded card transactions, and the seller_response_due_date field on the dispute object." }, { "source_url": "https://developer.paypal.com/disputes/disputes-lifecycle.md", "source_class": "public_primary", "source_title": "PayPal developer guide, Disputes lifecycle stages reference", "checked_on": "2026-09-19", "checked_by": "validator session 2026-09-19", "notes": "Confirms that a buyer can change the reason on an open dispute, supporting the record's note that a case filed as this catch-all value can later carry a named reason." } ] }, "rail_name": "PayPal Dispute Reasons", "governing_authority": "PayPal (regional entities; US: PayPal, Inc.)", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "paypal-dispute:PAYMENT_BY_OTHER_MEANS", "id": "PAYMENT_BY_OTHER_MEANS", "rail": "paypal-dispute", "kind": "reason-code", "name": "Payment by other means", "group": "administrative", "summary": "The buyer says the purchase was already paid some other way, so the PayPal payment was charged for nothing. It is a processing problem, not a complaint about the goods. PayPal gives the value only a one-line meaning. Filed with PayPal (channel INTERNAL) PayPal decides it; the value also labels a card chargeback or bank reversal for the same complaint (channel EXTERNAL), which the issuer or bank decides. The seller either refunds the PayPal payment or shows that the other payment was for something else or never completed.", "triggers": [ "Buyer paid the seller by card, bank transfer or cash and was also charged through PayPal for the same order [Inference: PayPal gives no examples]", "A failed checkout was retried with another method while the PayPal payment also went through [Inference]", "Buyer asked the card issuer to charge back a card-funded PayPal payment as paid by other means (arrives as EXTERNAL)" ], "actions": [ "Check dispute_channel first: INTERNAL is decided by PayPal, EXTERNAL by the card issuer or bank", "If the order was paid twice, refund the PayPal payment through PayPal and give the refund identifier as PROOF_OF_REFUND evidence", "If the other payment was for a different order or failed, show it with OTHER evidence such as order records or the other payment's status", "Answer by the seller_response_due_date; a seller that misses it loses the case to the buyer" ], "retry": { "allowed": true, "rule": "INTERNAL: a seller that loses PayPal's decision may appeal through PRE_ARBITRATION and then ARBITRATION within the appeal period PayPal sets. EXTERNAL: any further round follows the card network's or bank rail's process, not PayPal's." }, "facts": { "return_windows": [ { "action": "buyer opens a dispute with PayPal (INTERNAL)", "by": "buyer", "deadline": "No window stated in the US agreement or Purchase Protection page for this reason; PayPal's developer guide gives 180 days from payment for internal disputes generally (guidance)" }, { "action": "seller responds", "by": "seller", "deadline": "By the seller_response_due_date PayPal sets on the dispute" }, { "action": "chargeback or bank reversal (EXTERNAL)", "by": "card issuer or buyer's bank", "deadline": "Set by the card network's or bank rail's rules, not by PayPal" } ], "applies_to": "PayPal accounts under the US User Agreement; channel INTERNAL and EXTERNAL" }, "caveat": "The group follows the processing-error category card schemes use for a purchase paid by other means [Inference until a card network brief confirms it]. Seeking to be paid back twice for one transaction, once by PayPal and again by the seller, the bank or the card issuer, is a restricted activity under the US agreement (PayPal User Agreement (US), 2026-09-14, Restricted Activities).", "related": [ "paypal-dispute:DUPLICATE_TRANSACTION", "paypal-dispute:INCORRECT_AMOUNT", "paypal:return", "paypal:refund", "paypal:liability", "visa-dispute:12.6" ], "basis": { "sources": "Read 2026-09-19: PayPal Disputes OpenAPI specification customer_disputes_v1.json, Disputes 1.11 (https://raw.githubusercontent.com/paypal/paypal-rest-api-specifications/main/openapi/customer_disputes_v1.json, Apache License 2.0), schemas dispute_reason, dispute_channel, dispute (seller_response_due_date); PayPal developer guide, Dispute reasons and evidence and Disputes Overview (https://developer.paypal.com/disputes/reasons-evidence.md and /overview.md, undated); PayPal User Agreement (US), last updated 2026-09-14, Restricted Activities. Nothing is quoted. Medium because PayPal gives the value only a one-line meaning and its agreements do not say how it is handled; triggers are inferred and marked.", "confidence": "medium" }, "currency": { "effective_since": "2026-04-07", "effective_note": "Dated from the last push to PayPal's specification repository (2026-04-07), which holds Disputes 1.11; the served 1.12 has the same value. The US User Agreement read was last updated 2026-09-14. The date the value first took effect is unknown.", "source_edition": "Disputes 1.11 (1.12 served); developer guide as read 2026-09-19; PayPal User Agreement (US) 2026-09-14", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://raw.githubusercontent.com/paypal/paypal-rest-api-specifications/main/openapi/customer_disputes_v1.json", "source_class": "authoritative_primary", "source_title": "PayPal Disputes OpenAPI specification, customer_disputes_v1.json, Disputes 1.11", "checked_on": "2026-09-19", "checked_by": "validator session 2026-09-19", "notes": "Confirms the reason value and its one line meaning, the dispute_channel values INTERNAL and EXTERNAL, and the seller_response_due_date field on the dispute object." }, { "source_url": "https://developer.paypal.com/disputes/overview.md", "source_class": "public_primary", "source_title": "PayPal developer guide, Overview", "checked_on": "2026-09-19", "checked_by": "validator session 2026-09-19", "notes": "Confirms the general 180 day internal dispute window and that PayPal decides an internal case while the card issuer or bank decides an external one; the guide names no dedicated process for this reason, matching the record's own caveat." } ] }, "rail_name": "PayPal Dispute Reasons", "governing_authority": "PayPal (regional entities; US: PayPal, Inc.)", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "paypal-dispute:PROBLEM_WITH_REMITTANCE", "id": "PROBLEM_WITH_REMITTANCE", "rail": "paypal-dispute", "kind": "reason-code", "name": "Problem with remittance", "group": "administrative", "summary": "PayPal's specification defines this value only as a problem with the remittance, and its developer guide on dispute reasons leaves it out entirely. The most likely meaning is a Remittance Transfer Error under the US agreement: a consumer's personal cross-border Send Money payment of 15 US dollars or more, received in a PayPal account abroad, where the sender was overcharged, the recipient got less than the receipt showed, the money arrived late or not at all, or PayPal made a calculation error [Inference: PayPal does not link the value to that section]. If so, the case sits between the sender and PayPal, with PayPal investigating, rather than between a buyer and a merchant.", "triggers": [ "Sender of a personal cross-border payment says the recipient received less than the receipt promised [Inference]", "Funds reached the recipient after the availability date on the receipt, or never arrived [Inference]", "Sender was charged more than the receipt total, or PayPal miscalculated the amount received [Inference]" ], "actions": [ "Treat any meaning beyond PayPal's one-line definition as unconfirmed", "Check dispute_channel and the transaction type: a checkout payment to a merchant is not a Remittance Transfer under the US agreement", "Where evidence is asked for, the evidence types PayPal accepts generally (a refund identifier as PROOF_OF_REFUND, or notes and documents as OTHER) are the fallback; the guide gives none for this reason [Inference]", "Answer by any response due date PayPal sets on the dispute" ], "retry": { "allowed": true, "rule": "If the case runs as a Remittance Transfer Error, PayPal investigates and corrects; the sender may ask for the documents PayPal relied on [Inference on the mapping]. If it runs as a merchant dispute, a seller that loses PayPal's decision may appeal through PRE_ARBITRATION and then ARBITRATION within the appeal period PayPal sets." }, "facts": { "return_windows": [ { "action": "sender reports a Remittance Transfer Error [Inference on the mapping]", "by": "sender (personal account)", "deadline": "Within 180 days of the date PayPal said the funds would be available to the recipient" }, { "action": "PayPal decides whether an error occurred and corrects it", "by": "PayPal", "deadline": "Within 90 days after the sender's report; results within 3 Business Days after the investigation ends" } ], "applies_to": "Uncertain. If the inferred mapping holds: personal PayPal accounts under the US User Agreement sending money abroad by Send Money for personal purposes" }, "caveat": "Low confidence. PayPal gives this value a one-line meaning in the specification and no section in its developer guide on dispute reasons, and no agreement read names it. The link to the US agreement's Remittance Transfer Errors section and the administrative group are both inferences. Errors caused by extraordinary circumstances, fraud screening or sanctions requirements, and changes the recipient asked for, are outside the remittance error right.", "related": [ "paypal-dispute:OTHER", "paypal:consumer-law", "paypal:messages" ], "basis": { "sources": "Read 2026-09-19: PayPal Disputes OpenAPI specification customer_disputes_v1.json, Disputes 1.11 (https://raw.githubusercontent.com/paypal/paypal-rest-api-specifications/main/openapi/customer_disputes_v1.json, Apache License 2.0), schema dispute_reason and its one-line description; Disputes v1 schema served at developer.paypal.com, Disputes 1.12, same value; PayPal developer guide, Dispute reasons and evidence (https://developer.paypal.com/disputes/reasons-evidence.md, undated), which has sections for nine values and none for this one; PayPal User Agreement (US), last updated 2026-09-14 (https://www.paypal.com/us/legalhub/paypal/useragreement-full), Remittance Transfer Errors. Nothing is quoted. Low because the meaning beyond PayPal's one line and the mapping to the remittance section are inferred.", "confidence": "low" }, "currency": { "effective_since": "2026-04-07", "effective_note": "Dated from the last push to PayPal's specification repository (2026-04-07), which holds Disputes 1.11; the served 1.12 has the same value. The remittance rules come from the US User Agreement last updated 2026-09-14. The date the value first took effect is unknown.", "source_edition": "Disputes 1.11 (1.12 served); PayPal User Agreement (US) 2026-09-14; developer guide as read 2026-09-19", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "rail_name": "PayPal Dispute Reasons", "governing_authority": "PayPal (regional entities; US: PayPal, Inc.)", "snapshot": "2026-09-19", "source_class": null, "effective_status": "draft", "effective_status_reason": null, "boundaries": [ { "kind": "judgement", "label": "a fraud call", "needs": "how the bank judged this payment for fraud", "detail": "Errors caused by extraordinary circumstances, fraud screening or sanctions requirements, and changes the recipient asked for, are outside the remittance error right.", "from": "caveat" }, { "kind": "judgement", "label": "a sanctions check", "needs": "the outcome of sanctions, AML or KYC screening", "detail": "Errors caused by extraordinary circumstances, fraud screening or sanctions requirements, and changes the recipient asked for, are outside the remittance error right.", "from": "caveat" } ] }, { "uid": "paypal-dispute:UNAUTHORISED", "id": "UNAUTHORISED", "rail": "paypal-dispute", "kind": "reason-code", "name": "Unauthorised", "group": "authorization", "summary": "The payer says they did not authorise the purchase. PayPal spells the value the British way. Filed with PayPal (channel INTERNAL) it is an Unauthorized Transaction under the user agreement's liability rules, not a buyer protection claim: money left the payer's PayPal account without their authority and without benefit to them, for example after a stolen login. PayPal's developer guide says such cases go straight to the claim stage, with no inquiry between buyer and seller. The same value also labels a fraud chargeback on a card-funded payment or a bank's reversal of an unauthorised debit (channel EXTERNAL), decided by the issuer or bank. For the seller, Seller Protection can cover this reason on eligible transactions.", "triggers": [ "Someone used the payer's PayPal login without permission and sent a payment", "The cardholder told the card issuer they did not authorise a card-funded PayPal payment (arrives as EXTERNAL)", "The account holder's bank reversed a PayPal debit as unauthorised (arrives as EXTERNAL)" ], "actions": [ "Check dispute_channel first: INTERNAL follows PayPal's liability rules, EXTERNAL the card network's or bank's", "Check whether the transaction page marks the payment eligible or partially eligible for Seller Protection", "Give proof of fulfilment (carrier and tracking number) as PROOF_OF_FULFILLMENT evidence, or a delivery signature or receipt as OTHER; if already refunded, give the refund identifier as PROOF_OF_REFUND", "For Seller Protection the item must have shipped to the address on the transaction no later than two days after PayPal's notice, and the payment must have been made in an environment PayPal hosts; integrated sellers must run the current PayPal Checkout version and pass session data", "Answer by the seller_response_due_date; a seller that misses it loses the case to the buyer" ], "retry": { "allowed": true, "rule": "INTERNAL: a seller that loses PayPal's decision may appeal through PRE_ARBITRATION and then ARBITRATION within the appeal period PayPal sets. EXTERNAL: the answer to a fraud chargeback or bank reversal follows the card network's or bank rail's process. Do not send a new charge for the same order without fresh authority from the account holder [Inference]." }, "facts": { "return_windows": [ { "action": "payer reports an unauthorised transfer to PayPal (INTERNAL)", "by": "payer", "deadline": "At once; a report later than 60 days after the statement showing the transfer may leave the payer bearing later losses PayPal could have stopped" }, { "action": "PayPal decides whether an error occurred", "by": "PayPal", "deadline": "Within 10 Business Days, or up to 45 days (90 for new accounts, point-of-sale and foreign-initiated transfers) with a provisional credit within 10 Business Days" }, { "action": "seller shows shipment for Seller Protection", "by": "seller", "deadline": "Item shipped no later than two days after PayPal notified the seller of the dispute or reversal" }, { "action": "fraud chargeback or bank reversal (EXTERNAL)", "by": "card issuer or buyer's bank", "deadline": "Set by the card network's or bank rail's rules, not by PayPal" } ], "applies_to": "PayPal accounts under the US User Agreement; channel INTERNAL (Unauthorized Transaction under the agreement) and EXTERNAL (fraud chargeback or bank reversal)" }, "caveat": "Sharing one's login with someone who then oversteps is not unauthorised under the agreement. UK and Irish payers have 13 months to report and lose cover for gross negligence (PayPal User Agreement (UK), 2026-07-15, and (Ireland), 2026-01-22, Resolving Problems). Unauthorised claims filed with PayPal carry no dispute fee and are left out of the dispute ratio. Seller Protection excludes travel tickets sold by a carrier when the unauthorised claim was filed more than 24 hours before travel.", "related": [ "paypal-dispute:MERCHANDISE_OR_SERVICE_NOT_RECEIVED", "paypal:liability", "paypal:return", "paypal:consumer-law", "us-ach:R10", "sepa-sdd-core:MD01", "visa-dispute:10.4" ], "basis": { "sources": "Read 2026-09-19: PayPal Disputes OpenAPI specification customer_disputes_v1.json, Disputes 1.11 (https://raw.githubusercontent.com/paypal/paypal-rest-api-specifications/main/openapi/customer_disputes_v1.json, Apache License 2.0), schemas dispute_reason, dispute_channel, dispute (seller_response_due_date); PayPal User Agreement (US), last updated 2026-09-14 (https://www.paypal.com/us/legalhub/paypal/useragreement-full), Liability for Unauthorized Transactions and Other Errors, Dispute fees; PayPal's Purchase Protection Program (US), 2026-01-26, opening paragraphs; PayPal's Seller Protection Program (US), last updated 2026-01-26, What's Eligible, Basic Requirements, Ineligible Items and Transactions; PayPal developer guide, Disputes Overview and Dispute reasons and evidence (undated); PayPal User Agreement (UK), 2026-07-15, and (Ireland), 2026-01-22, Resolving Problems. Nothing is quoted. High because the value, the reporting rule and Seller Protection terms come from PayPal's own specification and agreements.", "confidence": "high" }, "currency": { "effective_since": "2026-09-14", "effective_note": "Reporting and error rules dated from the US User Agreement edition read (last updated 2026-09-14); Seller Protection terms from the page last updated 2026-01-26. The value is in Disputes 1.11 (repository last pushed 2026-04-07) and unchanged in the served 1.12. The date the value first took effect is unknown. The US Policy Updates page (last updated 2026-08-06) listed no notice touching buyer disputes on 2026-09-19.", "source_edition": "Disputes 1.11 (1.12 served); PayPal User Agreement (US) 2026-09-14; Seller Protection (US) 2026-01-26", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.paypal.com/us/legalhub/paypal/useragreement-full", "source_class": "authoritative_primary", "source_title": "PayPal User Agreement (US), last updated 2026-09-14", "checked_on": "2026-09-19", "checked_by": "validator session 2026-09-19", "notes": "Confirms the at-once reporting duty with its 60 day cutoff, the login sharing exclusion, the error resolution decision windows, and, on the Seller Protection page, the two day shipment rule after notice and the travel ticket exclusion tied to the 24 hour cutoff." } ] }, "rail_name": "PayPal Dispute Reasons", "governing_authority": "PayPal (regional entities; US: PayPal, Inc.)", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "pix-reject:AB03", "id": "AB03", "rail": "pix-reject", "kind": "reason-code", "name": "Aborted Settlement Timeout", "group": "technical", "summary": "The SPI stops settlement because the Pix ran out of time. BCB describes it as settlement interrupted by a timeout in the SPI. The SPI raises it.", "triggers": [ "The Pix is not settled within 40 seconds on the primary message channel (Manual de Tempos do Pix 7.0, section 1.1)", "A scheduled Pix Agendado or Pix Cobrança order on the secondary channel is not settled within 45 minutes (section 1.2)", "The receiving participant does not answer the pacs.008 in time [Inference: the catalog comment names only a timeout in the SPI]" ], "actions": [ "Payer's participant: release the amount held for the order and tell the payer the Pix did not go through [Inference]", "Payer's participant: pay again only as a new order with a new EndToEndId", "Receiving participant: review its answer times; its service level indicator leaves out settlements stopped by an SPI timeout (Manual de Tempos do Pix 7.0, section 4.1.1.2)" ], "retry": { "allowed": true, "rule": "Allowed once the cause is fixed. The rejected order itself is final. Resending the same operation (same EndToEndId, or same return id) within the 24-hour idempotency window only returns the earlier answer (SPI catalog 5.12, Idempotência, pp.15 to 16, and p.18), so a corrected payment goes as a new order with a new identifier [Inference]. The catalog sets no retry limit [Unverified]." }, "facts": { "return_windows": [ { "action": "reject (pacs.002 with status RJCT and this reason code)", "by": "SPI, as the catalog domain table states; once the SPI has received the order, a time-limit reject is always made by the SPI and sent to the participants (Manual de Tempos do Pix 7.0, sections 1.1 and 1.2)", "deadline": "When the limit passes: 40 seconds on the primary channel, counted from the moment the payer's participant receives the payer's order (t0') to settlement (t4), or from SPI receipt (t1') for an order held as suspected fraud; 45 minutes on the secondary channel, counted from SPI receipt (t1') (Manual de Tempos do Pix 7.0, sections 1.1 and 1.2)" } ], "applies_to": "Pix payment orders (pacs.008) settled in the SPI" }, "caveat": "A Pix settled outside the SPI (inside one participant, or under one settling participant) has the same 40-second and 45-minute limits, and the participant responsible for settlement must reject it (Manual de Tempos do Pix 7.0, section 1.3); the texts read do not say which code it uses. AB11 is the SPI's code for a timeout at the payer's participant.", "related": [ "pix-reject:AB11", "pix-reject:AB09", "pix-reject:ED05" ], "basis": { "sources": "SPI message catalog 5.12.1 (spi.5.12.1.zip), PACS002.xlsx, Tabela de Domínios, entry AB03 (ISO name and definition, BCB comment, raising participant); Manual de Tempos do Pix 7.0, sections 1.1, 1.2, 1.3 and 4.1.1.2; Catálogo de Serviços do SFN Volume VI (SPI catalog) 5.12, Canais de Transmissão (pp.13 to 14) and Idempotência (pp.15 to 16).", "confidence": "high" }, "currency": { "effective_since": "Since the 2020 catalogs", "effective_note": "The code is in the pacs.002 domain table from the pre-launch catalogs of 2020; the cumulative release notes record no later addition. Catalog 5.12.1 (published 2026-03-27) has been in SPI production since 2026-06-28 (BCB Comunicação eletrônica de dados page, Comunicado 44.424). Catalog 5.13.1 (SPI production 2026-10-25) keeps this code with the same comment.", "source_edition": "SPI message catalog 5.12.1 (spi.5.12.1.zip, PACS002.xlsx, pacs.002 v1.16, 2026-03-27); Manual de Tempos do Pix 7.0", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.bcb.gov.br/content/estabilidadefinanceira/cedsfn/Catalogos/spi.5.12.1.zip", "source_class": "authoritative_primary", "source_title": "SPI message catalog 5.12.1 (spi.5.12.1.zip), PACS002.xlsx Tabela de Dominios; Manual de Tempos do Pix 7.0", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms code AB03, ISO name AbortedSettlementTimeout, and the BCB comment naming the SPI as the raising participant. Confirms the reject falls inside the 40-second primary and 45-minute secondary channel limit and the section 4.1.1.2 service-level figures cited. Does not address the section 1.3 outside-SPI code question raised in the caveat." } ] }, "rail_name": "Pix Payment Rejects", "governing_authority": "Banco Central do Brasil", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "pix-reject:AB09", "id": "AB09", "rail": "pix-reject", "kind": "reason-code", "name": "Error Creditor Agent", "group": "technical", "summary": "The receiving participant stops the transaction because of an error on its side. BCB describes it as a transaction interrupted by an error at the receiving user's participant. The receiving participant raises it.", "triggers": [ "The receiving participant cannot process the incoming pacs.008 because of an internal failure [Inference: the catalog gives no examples]" ], "actions": [ "Payer's participant: tell the payer the Pix failed on the receiving side and that it may be sent again later [Inference]", "Receiving participant: fix the failure; use a more specific code when the cause is known [Inference]" ], "retry": { "allowed": true, "rule": "Allowed once the cause is fixed. The rejected order itself is final. Resending the same operation (same EndToEndId, or same return id) within the 24-hour idempotency window only returns the earlier answer (SPI catalog 5.12, Idempotência, pp.15 to 16, and p.18), so a corrected payment goes as a new order with a new identifier [Inference]. The catalog sets no retry limit [Unverified]." }, "facts": { "return_windows": [ { "action": "reject (pacs.002 with status RJCT and this reason code)", "by": "Receiving participant (PSP of the receiving user), as the catalog domain table states", "deadline": "Inside the Pix time limit: the SPI rejects any Pix not settled within 40 seconds on the primary message channel or 45 minutes on the secondary channel, which carries only scheduled Pix Agendado and Pix Cobrança orders (Manual de Tempos do Pix 7.0, sections 1.1 and 1.2). On the primary channel the receiving side's answer (t3' minus t2) has a service level of 1.4 seconds at the 50th percentile and 2.3 seconds at the 95th (section 4.1.1.2)." } ], "applies_to": "Pix payment orders (pacs.008) and returns (devolução, pacs.004) settled in the SPI [Inference: the table does not limit the code to payments]" }, "caveat": "The catalog comment is generic. ED05 is the other generic processing error and may come from either the SPI or the receiving participant.", "related": [ "pix-reject:ED05", "pix-reject:DS04", "pix-reject:AB03" ], "basis": { "sources": "SPI message catalog 5.12.1 (spi.5.12.1.zip), PACS002.xlsx, Tabela de Domínios, entry AB09 (ISO name and definition, BCB comment, raising participant); Manual de Tempos do Pix 7.0, sections 1.1, 1.2 and 4.1.1.2.", "confidence": "medium" }, "currency": { "effective_since": "Since the 2020 catalogs", "effective_note": "The code is in the pacs.002 domain table from the pre-launch catalogs of 2020; the cumulative release notes record no later addition. Catalog 5.12.1 (published 2026-03-27) has been in SPI production since 2026-06-28 (BCB Comunicação eletrônica de dados page, Comunicado 44.424). Catalog 5.13.1 (SPI production 2026-10-25) keeps this code with the same comment.", "source_edition": "SPI message catalog 5.12.1 (spi.5.12.1.zip, PACS002.xlsx, pacs.002 v1.16, 2026-03-27); Manual de Tempos do Pix 7.0", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.bcb.gov.br/content/estabilidadefinanceira/cedsfn/Catalogos/spi.5.12.1.zip", "source_class": "authoritative_primary", "source_title": "SPI message catalog 5.12.1 (spi.5.12.1.zip), PACS002.xlsx Tabela de Dominios; Manual de Tempos do Pix 7.0", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms code AB09, ISO name ErrorCreditorAgent, and the BCB comment naming the receiving participant as the raising side. Confirms the reject falls inside the same 40-second or 45-minute channel deadline. Does not give causes for the receiving participant error, matching the caveat." } ] }, "rail_name": "Pix Payment Rejects", "governing_authority": "Banco Central do Brasil", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "pix-reject:AB11", "id": "AB11", "rail": "pix-reject", "kind": "reason-code", "name": "Timeout Debtor Agent", "group": "technical", "summary": "The SPI rejects because the participant that sent the payment order took too long. BCB describes it as a timeout of the participant sending the order. The SPI raises it.", "triggers": [ "The payer's participant exceeds the time allowed on its side of the flow [Inference: the catalog does not say which step is timed]", "Time from the payer's order (t0') to settlement passes the 40-second or 45-minute limit because of delay at the payer's participant [Inference]" ], "actions": [ "Payer's participant: release the held amount and tell the payer the Pix did not go through [Inference]", "Payer's participant: check its initiation times; its service level for t1 minus t0' is 0.9 seconds at the 50th percentile and 1.5 seconds at the 95th (Manual de Tempos do Pix 7.0, section 4.1.1.1)" ], "retry": { "allowed": true, "rule": "Allowed once the cause is fixed. The rejected order itself is final. Resending the same operation (same EndToEndId, or same return id) within the 24-hour idempotency window only returns the earlier answer (SPI catalog 5.12, Idempotência, pp.15 to 16, and p.18), so a corrected payment goes as a new order with a new identifier [Inference]. The catalog sets no retry limit [Unverified]." }, "facts": { "return_windows": [ { "action": "reject (pacs.002 with status RJCT and this reason code)", "by": "SPI (the settlement system operated by the BCB), as the catalog domain table states", "deadline": "During SPI processing, inside the Pix time limit of 40 seconds on the primary message channel or 45 minutes on the secondary channel, which carries only scheduled Pix Agendado and Pix Cobrança orders (Manual de Tempos do Pix 7.0, sections 1.1 and 1.2). The pacs.002 goes out on the channel of the pacs.008 that started the payment (SPI catalog 5.12, Canais de Transmissão, pp.13 to 14). [Inference: a validation reject is sent at once; the Manual sets no separate time for it.]" } ], "applies_to": "Pix payment orders (pacs.008) settled in the SPI" }, "caveat": "AB03 covers a timeout in the SPI itself. The catalog does not explain how the SPI measures the payer side's delay [Unverified].", "related": [ "pix-reject:AB03", "pix-reject:ED05" ], "basis": { "sources": "SPI message catalog 5.12.1 (spi.5.12.1.zip), PACS002.xlsx, Tabela de Domínios, entry AB11 (ISO name and definition, BCB comment, raising participant); Manual de Tempos do Pix 7.0, sections 1.1, 1.2 and 4.1.1.1.", "confidence": "medium" }, "currency": { "effective_since": "Catalog 5.02.1", "effective_note": "Added to the pacs.002 domain table in catalog 5.02.1, published 2021-03-19 (Notas de Versão in spi.5.13.1.zip (cumulative release notes)). Release note dates are publication dates; the SPI production date of that catalog was not read [Unverified]. Catalog 5.12.1 (published 2026-03-27) has been in SPI production since 2026-06-28 (BCB Comunicação eletrônica de dados page, Comunicado 44.424). Catalog 5.13.1 (SPI production 2026-10-25) keeps this code with the same comment.", "source_edition": "SPI message catalog 5.12.1 (spi.5.12.1.zip, PACS002.xlsx, pacs.002 v1.16, 2026-03-27); Manual de Tempos do Pix 7.0", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.bcb.gov.br/content/estabilidadefinanceira/cedsfn/Catalogos/spi.5.12.1.zip", "source_class": "authoritative_primary", "source_title": "SPI message catalog 5.12.1 (spi.5.12.1.zip), PACS002.xlsx Tabela de Dominios; Manual de Tempos do Pix 7.0", "checked_on": "2026-09-21", "checked_by": "validator-sonnet-2026-09-21", "notes": "Confirms code AB11, ISO name TimeoutDebtorAgent, and the BCB comment naming a timeout of the participant that sent the payment order, raised by the SPI. Confirms the reject falls inside the 40 second primary and 45 minute secondary channel limits and the section 4.1.1.1 service level figures of 0.9 seconds at the 50th percentile and 1.5 seconds at the 95th for the payer side of Pix initiation." } ] }, "rail_name": "Pix Payment Rejects", "governing_authority": "Banco Central do Brasil", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "pix-reject:AC03", "id": "AC03", "rail": "pix-reject", "kind": "reason-code", "name": "Invalid Creditor Account Number", "group": "account", "summary": "The receiving participant cannot find the account. BCB describes it as a branch or transactional account number of the receiving user that does not exist or is invalid. The receiving participant raises it.", "triggers": [ "The branch number or account number in the pacs.008 does not exist at the receiving participant", "The account number is malformed or missing" ], "actions": [ "Payer's participant: tell the payer to check the account details, or to pay with a Pix key or QR code instead of manual entry [Inference]", "Payer: confirm the details with the receiver before sending again" ], "retry": { "allowed": true, "rule": "Allowed once the cause is fixed. The rejected order itself is final. Resending the same operation (same EndToEndId, or same return id) within the 24-hour idempotency window only returns the earlier answer (SPI catalog 5.12, Idempotência, pp.15 to 16, and p.18), so a corrected payment goes as a new order with a new identifier [Inference]. The catalog sets no retry limit [Unverified]." }, "facts": { "return_windows": [ { "action": "reject (pacs.002 with status RJCT and this reason code)", "by": "Receiving participant (PSP of the receiving user), as the catalog domain table states", "deadline": "Inside the Pix time limit: the SPI rejects any Pix not settled within 40 seconds on the primary message channel or 45 minutes on the secondary channel, which carries only scheduled Pix Agendado and Pix Cobrança orders (Manual de Tempos do Pix 7.0, sections 1.1 and 1.2). On the primary channel the receiving side's answer (t3' minus t2) has a service level of 1.4 seconds at the 50th percentile and 2.3 seconds at the 95th (section 4.1.1.2)." } ], "applies_to": "Pix payment orders (pacs.008) settled in the SPI" }, "caveat": "The Regulamento requires the receiving participant to reject when there are problems identifying the receiving user (art. 39, II); the catalog does not tie this code to that article [Inference].", "related": [ "pix-reject:AC07", "pix-reject:AC14", "pix-reject:BE01", "pix-reject:CH11" ], "basis": { "sources": "SPI message catalog 5.12.1 (spi.5.12.1.zip), PACS002.xlsx, Tabela de Domínios, entry AC03 (ISO name and definition, BCB comment, raising participant); Notas de Versão in spi.5.13.1.zip (cumulative release notes), version 5.04.1 (comment changed); Regulamento annexed to Resolução BCB nº 1/2020 (consolidated, version 41), art. 39, II; Manual de Tempos do Pix 7.0, sections 1.1, 1.2 and 4.1.1.2.", "confidence": "high" }, "currency": { "effective_since": "Since the 2020 catalogs", "effective_note": "The code is in the pacs.002 domain table from the pre-launch catalogs of 2020; the cumulative release notes record no later addition. Catalog 5.12.1 (published 2026-03-27) has been in SPI production since 2026-06-28 (BCB Comunicação eletrônica de dados page, Comunicado 44.424). Catalog 5.13.1 (SPI production 2026-10-25) keeps this code with the same comment. The comment was reworded in catalog 5.04.1 (published 2022-04-01).", "source_edition": "SPI message catalog 5.12.1 (spi.5.12.1.zip, PACS002.xlsx, pacs.002 v1.16, 2026-03-27); Manual de Tempos do Pix 7.0", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.bcb.gov.br/content/estabilidadefinanceira/cedsfn/Catalogos/spi.5.12.1.zip", "source_class": "authoritative_primary", "source_title": "SPI message catalog 5.12.1 (spi.5.12.1.zip), PACS002.xlsx Tabela de Dominios; Manual de Tempos do Pix 7.0", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms code AC03, ISO name InvalidCreditorAccountNumber, and the BCB comment describing a missing or invalid receiving account number, raised by the receiving participant. Confirms the reject deadline. Does not tie the code to Regulamento art. 39, II, matching the caveat." } ] }, "rail_name": "Pix Payment Rejects", "governing_authority": "Banco Central do Brasil", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "pix-reject:AC06", "id": "AC06", "rail": "pix-reject", "kind": "reason-code", "name": "Blocked Account", "group": "account", "summary": "The receiving user's account is blocked, so the credit cannot be posted. BCB describes it as the receiving user's transactional account being blocked. The receiving participant raises it.", "triggers": [ "The receiving user's transactional account is blocked at the receiving participant" ], "actions": [ "Payer: contact the receiver and agree another account or another way to pay", "Receiving participant: tell its user why incoming Pix are refused, where rules allow [Inference]" ], "retry": { "allowed": true, "rule": "Allowed only once the block is lifted or another account is given. Resending the same operation (same EndToEndId, or same return id) within the 24-hour idempotency window only returns the earlier answer (SPI catalog 5.12, Idempotência, pp.15 to 16, and p.18), so a corrected payment goes as a new order with a new identifier [Inference]. The catalog sets no retry limit [Unverified]." }, "facts": { "return_windows": [ { "action": "reject (pacs.002 with status RJCT and this reason code)", "by": "Receiving participant (PSP of the receiving user), as the catalog domain table states", "deadline": "Inside the Pix time limit: the SPI rejects any Pix not settled within 40 seconds on the primary message channel or 45 minutes on the secondary channel, which carries only scheduled Pix Agendado and Pix Cobrança orders (Manual de Tempos do Pix 7.0, sections 1.1 and 1.2). On the primary channel the receiving side's answer (t3' minus t2) has a service level of 1.4 seconds at the 50th percentile and 2.3 seconds at the 95th (section 4.1.1.2)." } ], "applies_to": "Pix payment orders (pacs.008) and returns (devolução, pacs.004) settled in the SPI [Inference: the table does not limit the code to payments]" }, "caveat": "A block of the account is different from the precautionary hold (bloqueio cautelar) of Regulamento art. 39-B, which is applied at the same time as the credit and does not reject the Pix.", "related": [ "pix-reject:AC07", "pix-reject:AC03", "pix-reject:FRAD" ], "basis": { "sources": "SPI message catalog 5.12.1 (spi.5.12.1.zip), PACS002.xlsx, Tabela de Domínios, entry AC06 (ISO name and definition, BCB comment, raising participant); Regulamento annexed to Resolução BCB nº 1/2020 (consolidated, version 41), art. 39-B; Manual de Tempos do Pix 7.0, sections 1.1, 1.2 and 4.1.1.2.", "confidence": "high" }, "currency": { "effective_since": "Since the 2020 catalogs", "effective_note": "The code is in the pacs.002 domain table from the pre-launch catalogs of 2020; the cumulative release notes record no later addition. Catalog 5.12.1 (published 2026-03-27) has been in SPI production since 2026-06-28 (BCB Comunicação eletrônica de dados page, Comunicado 44.424). Catalog 5.13.1 (SPI production 2026-10-25) keeps this code with the same comment.", "source_edition": "SPI message catalog 5.12.1 (spi.5.12.1.zip, PACS002.xlsx, pacs.002 v1.16, 2026-03-27); Manual de Tempos do Pix 7.0", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.bcb.gov.br/content/estabilidadefinanceira/cedsfn/Catalogos/spi.5.12.1.zip", "source_class": "authoritative_primary", "source_title": "SPI message catalog 5.12.1 (spi.5.12.1.zip), PACS002.xlsx Tabela de Dominios; Manual de Tempos do Pix 7.0", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms code AC06, ISO name BlockedAccount, and the BCB comment describing a blocked receiving account, raised by the receiving participant. Confirms the reject deadline." } ] }, "rail_name": "Pix Payment Rejects", "governing_authority": "Banco Central do Brasil", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "pix-reject:AC07", "id": "AC07", "rail": "pix-reject", "kind": "reason-code", "name": "Closed Creditor Account Number", "group": "account", "summary": "The receiving user's account is closed. BCB describes it as a closed transactional account number of the receiving user. The receiving participant raises it.", "triggers": [ "The account named in the pacs.008 has been closed", "A Pix key still points to a closed account [Inference]" ], "actions": [ "Payer: get current account details from the receiver", "Payer's participant: tell the payer the account is closed" ], "retry": { "allowed": false, "rule": "Not for the same reason. A closed account will not accept the credit; pay to another account. Resending the same operation (same EndToEndId, or same return id) within the 24-hour idempotency window only returns the earlier answer (SPI catalog 5.12, Idempotência, pp.15 to 16, and p.18), so a corrected payment goes as a new order with a new identifier [Inference]. The catalog sets no retry limit [Unverified]." }, "facts": { "return_windows": [ { "action": "reject (pacs.002 with status RJCT and this reason code)", "by": "Receiving participant (PSP of the receiving user), as the catalog domain table states", "deadline": "Inside the Pix time limit: the SPI rejects any Pix not settled within 40 seconds on the primary message channel or 45 minutes on the secondary channel, which carries only scheduled Pix Agendado and Pix Cobrança orders (Manual de Tempos do Pix 7.0, sections 1.1 and 1.2). On the primary channel the receiving side's answer (t3' minus t2) has a service level of 1.4 seconds at the 50th percentile and 2.3 seconds at the 95th (section 4.1.1.2)." } ], "applies_to": "Pix payment orders (pacs.008) and returns (devolução, pacs.004) settled in the SPI [Inference: the table does not limit the code to payments]" }, "caveat": null, "related": [ "pix-reject:AC03", "pix-reject:AC06" ], "basis": { "sources": "SPI message catalog 5.12.1 (spi.5.12.1.zip), PACS002.xlsx, Tabela de Domínios, entry AC07 (ISO name and definition, BCB comment, raising participant); Manual de Tempos do Pix 7.0, sections 1.1, 1.2 and 4.1.1.2.", "confidence": "high" }, "currency": { "effective_since": "Since the 2020 catalogs", "effective_note": "The code is in the pacs.002 domain table from the pre-launch catalogs of 2020; the cumulative release notes record no later addition. Catalog 5.12.1 (published 2026-03-27) has been in SPI production since 2026-06-28 (BCB Comunicação eletrônica de dados page, Comunicado 44.424). Catalog 5.13.1 (SPI production 2026-10-25) keeps this code with the same comment.", "source_edition": "SPI message catalog 5.12.1 (spi.5.12.1.zip, PACS002.xlsx, pacs.002 v1.16, 2026-03-27); Manual de Tempos do Pix 7.0", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.bcb.gov.br/content/estabilidadefinanceira/cedsfn/Catalogos/spi.5.12.1.zip", "source_class": "authoritative_primary", "source_title": "SPI message catalog 5.12.1 (spi.5.12.1.zip), PACS002.xlsx Tabela de Dominios; Manual de Tempos do Pix 7.0", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms code AC07, ISO name ClosedCreditorAccountNumber, and the BCB comment describing a closed receiving account, raised by the receiving participant. Confirms the reject deadline." } ] }, "rail_name": "Pix Payment Rejects", "governing_authority": "Banco Central do Brasil", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "pix-reject:AC14", "id": "AC14", "rail": "pix-reject", "kind": "reason-code", "name": "Invalid Creditor Account Type", "group": "account", "summary": "The account type given for the receiving user is wrong. BCB describes it as an incorrect type for the receiving user's transactional account. The receiving participant raises it.", "triggers": [ "The account type in the pacs.008 does not match the receiving user's account, for example a payment account given as a checking account [Inference: the catalog gives no example]" ], "actions": [ "Payer: check the account type with the receiver and send again", "Payer's participant: prefer key or QR code initiation, which carry the account data from the source [Inference]" ], "retry": { "allowed": true, "rule": "Allowed once the cause is fixed. The rejected order itself is final. Resending the same operation (same EndToEndId, or same return id) within the 24-hour idempotency window only returns the earlier answer (SPI catalog 5.12, Idempotência, pp.15 to 16, and p.18), so a corrected payment goes as a new order with a new identifier [Inference]. The catalog sets no retry limit [Unverified]." }, "facts": { "return_windows": [ { "action": "reject (pacs.002 with status RJCT and this reason code)", "by": "Receiving participant (PSP of the receiving user), as the catalog domain table states", "deadline": "Inside the Pix time limit: the SPI rejects any Pix not settled within 40 seconds on the primary message channel or 45 minutes on the secondary channel, which carries only scheduled Pix Agendado and Pix Cobrança orders (Manual de Tempos do Pix 7.0, sections 1.1 and 1.2). On the primary channel the receiving side's answer (t3' minus t2) has a service level of 1.4 seconds at the 50th percentile and 2.3 seconds at the 95th (section 4.1.1.2)." } ], "applies_to": "Pix payment orders (pacs.008) settled in the SPI" }, "caveat": null, "related": [ "pix-reject:AC03", "pix-reject:AG03" ], "basis": { "sources": "SPI message catalog 5.12.1 (spi.5.12.1.zip), PACS002.xlsx, Tabela de Domínios, entry AC14 (ISO name and definition, BCB comment, raising participant); Manual de Tempos do Pix 7.0, sections 1.1, 1.2 and 4.1.1.2.", "confidence": "high" }, "currency": { "effective_since": "Since the 2020 catalogs", "effective_note": "The code is in the pacs.002 domain table from the pre-launch catalogs of 2020; the cumulative release notes record no later addition. Catalog 5.12.1 (published 2026-03-27) has been in SPI production since 2026-06-28 (BCB Comunicação eletrônica de dados page, Comunicado 44.424). Catalog 5.13.1 (SPI production 2026-10-25) keeps this code with the same comment.", "source_edition": "SPI message catalog 5.12.1 (spi.5.12.1.zip, PACS002.xlsx, pacs.002 v1.16, 2026-03-27); Manual de Tempos do Pix 7.0", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.bcb.gov.br/content/estabilidadefinanceira/cedsfn/Catalogos/spi.5.12.1.zip", "source_class": "authoritative_primary", "source_title": "SPI message catalog 5.12.1 (spi.5.12.1.zip), PACS002.xlsx Tabela de Dominios; Manual de Tempos do Pix 7.0", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms code AC14, ISO name InvalidCreditorAccountType, and the BCB comment describing a missing or wrong receiving account type, raised by the receiving participant. Confirms the reject deadline. Does not give an account type example, matching the caveat." } ] }, "rail_name": "Pix Payment Rejects", "governing_authority": "Banco Central do Brasil", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "pix-reject:AG03", "id": "AG03", "rail": "pix-reject", "kind": "reason-code", "name": "Transaction Not Supported", "group": "account", "summary": "The receiving account does not accept this type of transaction. BCB describes it as a transaction type not supported or not authorised on the receiving user's account, giving a transfer into a salary account (conta salário) as the example. The receiving participant raises it.", "triggers": [ "A Pix is sent to a salary account (conta salário), as the catalog's example", "Another account type that cannot take this kind of credit [Inference]" ], "actions": [ "Payer: ask the receiver for an account that can take Pix credits", "Receiving participant: tell its user which account types can receive Pix [Inference]" ], "retry": { "allowed": false, "rule": "Not for the same reason. The same account will refuse the same kind of transaction. Resending the same operation (same EndToEndId, or same return id) within the 24-hour idempotency window only returns the earlier answer (SPI catalog 5.12, Idempotência, pp.15 to 16, and p.18), so a corrected payment goes as a new order with a new identifier [Inference]. The catalog sets no retry limit [Unverified]." }, "facts": { "return_windows": [ { "action": "reject (pacs.002 with status RJCT and this reason code)", "by": "Receiving participant (PSP of the receiving user), as the catalog domain table states", "deadline": "Inside the Pix time limit: the SPI rejects any Pix not settled within 40 seconds on the primary message channel or 45 minutes on the secondary channel, which carries only scheduled Pix Agendado and Pix Cobrança orders (Manual de Tempos do Pix 7.0, sections 1.1 and 1.2). On the primary channel the receiving side's answer (t3' minus t2) has a service level of 1.4 seconds at the 50th percentile and 2.3 seconds at the 95th (section 4.1.1.2)." } ], "applies_to": "Pix payment orders (pacs.008) settled in the SPI" }, "caveat": "Which account types refuse which transactions is not listed in the catalog [Unverified]. Catalog 5.13.1 only moves the example onto its own line; the meaning is unchanged.", "related": [ "pix-reject:AC14", "pix-reject:AM02" ], "basis": { "sources": "SPI message catalog 5.12.1 (spi.5.12.1.zip), PACS002.xlsx, Tabela de Domínios, entry AG03 (ISO name and definition, BCB comment, raising participant); SPI message catalog 5.13.1 (spi.5.13.1.zip), PACS002.xlsx, Tabela de Domínios, entry AG03 (formatting only); Manual de Tempos do Pix 7.0, sections 1.1, 1.2 and 4.1.1.2.", "confidence": "medium" }, "currency": { "effective_since": "Since the 2020 catalogs", "effective_note": "The code is in the pacs.002 domain table from the pre-launch catalogs of 2020; the cumulative release notes record no later addition. Catalog 5.12.1 (published 2026-03-27) has been in SPI production since 2026-06-28 (BCB Comunicação eletrônica de dados page, Comunicado 44.424). Catalog 5.13.1 (SPI production 2026-10-25) keeps this code with the same comment.", "source_edition": "SPI message catalog 5.12.1 (spi.5.12.1.zip, PACS002.xlsx, pacs.002 v1.16, 2026-03-27); Manual de Tempos do Pix 7.0", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.bcb.gov.br/content/estabilidadefinanceira/cedsfn/Catalogos/spi.5.12.1.zip", "source_class": "authoritative_primary", "source_title": "SPI message catalog 5.12.1 (spi.5.12.1.zip), PACS002.xlsx Tabela de Dominios; Manual de Tempos do Pix 7.0", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms code AG03, ISO name TransactionNotSupported, and the BCB comment naming the salary account (conta salario) as the example, raised by the receiving participant. Confirms the reject deadline. Does not list other account types, matching the caveat." } ] }, "rail_name": "Pix Payment Rejects", "governing_authority": "Banco Central do Brasil", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "pix-reject:AG12", "id": "AG12", "rail": "pix-reject", "kind": "reason-code", "name": "Not Allowed Book Transfer", "group": "network", "summary": "The SPI refuses a transfer that should have settled inside a participant. BCB describes it as a payment or return in the SPI whose funds move between accounts of the same participant, or between participants that use the same settling participant (book transfer). The SPI raises it.", "triggers": [ "Payer and receiver hold accounts at the same participant", "Payer's and receiver's participants both settle through the same settling participant in the SPI" ], "actions": [ "Participant: settle the Pix in its own systems, as the Regulamento requires (art. 33, sole paragraph; art. 34)", "Participant: report the Pix settled outside the SPI to the BCB within 30 days of settlement (Manual de Tempos do Pix 7.0, section 1.4)" ], "retry": { "allowed": false, "rule": "Not for the same reason. The SPI will refuse the same routing again; settle the transfer internally. Resending the same operation (same EndToEndId, or same return id) within the 24-hour idempotency window only returns the earlier answer (SPI catalog 5.12, Idempotência, pp.15 to 16, and p.18), so a corrected payment goes as a new order with a new identifier [Inference]. The catalog sets no retry limit [Unverified]." }, "facts": { "return_windows": [ { "action": "reject (pacs.002 with status RJCT and this reason code)", "by": "SPI (the settlement system operated by the BCB), as the catalog domain table states", "deadline": "During SPI processing, inside the Pix time limit of 40 seconds on the primary message channel or 45 minutes on the secondary channel, which carries only scheduled Pix Agendado and Pix Cobrança orders (Manual de Tempos do Pix 7.0, sections 1.1 and 1.2). The pacs.002 goes out on the channel of the pacs.008 that started the payment (SPI catalog 5.12, Canais de Transmissão, pp.13 to 14). [Inference: a validation reject is sent at once; the Manual sets no separate time for it.]" } ], "applies_to": "Pix payment orders (pacs.008) and returns (devolução, pacs.004) settled in the SPI" }, "caveat": "A Pix settled inside a participant is still a Pix, with the same 40-second and 45-minute limits (Manual de Tempos do Pix 7.0, section 1.3).", "related": [ "pix-reject:AGNT", "pix-reject:DS0G" ], "basis": { "sources": "SPI message catalog 5.12.1 (spi.5.12.1.zip), PACS002.xlsx, Tabela de Domínios, entry AG12 (ISO name and definition, BCB comment, raising participant); Regulamento annexed to Resolução BCB nº 1/2020 (consolidated, version 41), arts. 33 and 34; Manual de Tempos do Pix 7.0, sections 1.3 and 1.4; Catálogo de Serviços do SFN Volume VI (SPI catalog) 5.12, Canais de Transmissão (pp.13 to 14).", "confidence": "high" }, "currency": { "effective_since": "Catalog 5.02.1", "effective_note": "Added to the pacs.002 domain table in catalog 5.02.1, published 2021-03-19 (Notas de Versão in spi.5.13.1.zip (cumulative release notes)). Release note dates are publication dates; the SPI production date of that catalog was not read [Unverified]. Catalog 5.12.1 (published 2026-03-27) has been in SPI production since 2026-06-28 (BCB Comunicação eletrônica de dados page, Comunicado 44.424). Catalog 5.13.1 (SPI production 2026-10-25) keeps this code with the same comment.", "source_edition": "SPI message catalog 5.12.1 (spi.5.12.1.zip, PACS002.xlsx, pacs.002 v1.16, 2026-03-27); Manual de Tempos do Pix 7.0", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.bcb.gov.br/content/estabilidadefinanceira/cedsfn/Catalogos/spi.5.12.1.zip", "source_class": "authoritative_primary", "source_title": "SPI message catalog 5.12.1 (spi.5.12.1.zip), PACS002.xlsx Tabela de Dominios; Regulamento Pix anexo a Resolucao BCB no. 1/2020 consolidated version 41; Manual de Tempos do Pix 7.0; Catalogo de Servicos do SFN Volume VI 5.12", "checked_on": "2026-09-21", "checked_by": "validator-sonnet-2026-09-21", "notes": "Confirms code AG12, ISO name NotAllowedBookTransfer, and the BCB comment naming the SPI as the raising participant for a payment or return whose funds move between accounts of the same participant or between participants that settle through the same settling participant. Confirms the participant duty to settle such a Pix in its own systems under Regulamento arts. 33 sole paragraph and 34, and the 30 day deadline to report a Pix settled outside the SPI to the BCB under Manual de Tempos do Pix 7.0 section 1.4. Confirms the 40 second primary channel and 45 minute secondary channel time limits from Manual de Tempos do Pix 7.0 sections 1.1 and 1.2, and the 24 hour idempotency window covering both payment and return cycles from the Catalogo de Servicos do SFN Volume VI 5.12 idempotency chapter." } ] }, "rail_name": "Pix Payment Rejects", "governing_authority": "Banco Central do Brasil", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "pix-reject:AG13", "id": "AG13", "rail": "pix-reject", "kind": "reason-code", "name": "Forbidden Return Payment", "group": "administrative", "summary": "A return of a return is not allowed. BCB describes it as a return of the return of an instant payment. The SPI raises it.", "triggers": [ "A participant sends a pacs.004 that returns funds which themselves arrived as a Pix return" ], "actions": [ "Participant: do not return a return; if funds must move back, the user makes a new Pix [Inference]", "Participant: check whether the case falls under the special return mechanism (MED) in the DICT instead [Inference]" ], "retry": { "allowed": false, "rule": "Not for the same reason. The SPI will refuse any return of a return. Resending the same operation (same EndToEndId, or same return id) within the 24-hour idempotency window only returns the earlier answer (SPI catalog 5.12, Idempotência, pp.15 to 16, and p.18), so a corrected payment goes as a new order with a new identifier [Inference]. The catalog sets no retry limit [Unverified]." }, "facts": { "return_windows": [ { "action": "reject (pacs.002 with status RJCT and this reason code)", "by": "SPI (the settlement system operated by the BCB), as the catalog domain table states", "deadline": "During SPI processing of the return. A return (pacs.004) and the pacs.002 answering it always use the primary channel (SPI catalog 5.12, p.14). [Unverified: the Manual de Tempos do Pix 7.0 states its 40-second limit for Pix payment orders and does not name returns.]" } ], "applies_to": "Pix returns (devolução, pacs.004) settled in the SPI" }, "caveat": "Under MED 2.0, a contested return is refunded by a new pacs.008 with the parties reversed, not by a pacs.004 (Orca's Pix rail brief, docs/rails/pix.md, Known traps; not re-read for this record).", "related": [ "pix-reject:AM09", "pix-reject:DT05", "pix-reject:SL02" ], "basis": { "sources": "SPI message catalog 5.12.1 (spi.5.12.1.zip), PACS002.xlsx, Tabela de Domínios, entry AG13 (ISO name and definition, BCB comment, raising participant); Catálogo de Serviços do SFN Volume VI (SPI catalog) 5.12, pp.14 and 18 (returns use pacs.004 and pacs.002 on the primary channel).", "confidence": "high" }, "currency": { "effective_since": "Catalog 5.02.1", "effective_note": "Added to the pacs.002 domain table in catalog 5.02.1, published 2021-03-19 (Notas de Versão in spi.5.13.1.zip (cumulative release notes)). Release note dates are publication dates; the SPI production date of that catalog was not read [Unverified]. Catalog 5.12.1 (published 2026-03-27) has been in SPI production since 2026-06-28 (BCB Comunicação eletrônica de dados page, Comunicado 44.424). Catalog 5.13.1 (SPI production 2026-10-25) keeps this code with the same comment.", "source_edition": "SPI message catalog 5.12.1 (spi.5.12.1.zip, PACS002.xlsx, pacs.002 v1.16, 2026-03-27); Manual de Tempos do Pix 7.0", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.bcb.gov.br/content/estabilidadefinanceira/cedsfn/Catalogos/spi.5.12.1.zip", "source_class": "authoritative_primary", "source_title": "SPI message catalog 5.12.1 (spi.5.12.1.zip), PACS002.xlsx Tabela de Dominios; Catalogo de Servicos do SFN Volume VI 5.12", "checked_on": "2026-09-21", "checked_by": "validator-sonnet-2026-09-21", "notes": "Confirms code AG13, ISO name ForbiddenReturnPayment, and the BCB comment naming a return of the return of an instant payment as not allowed, raised by the SPI. Confirms a return and its answering reject always travel on the primary message channel." } ] }, "rail_name": "Pix Payment Rejects", "governing_authority": "Banco Central do Brasil", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "pix-reject:AGNT", "id": "AGNT", "rail": "pix-reject", "kind": "reason-code", "name": "Incorrect Agent", "group": "network", "summary": "The direct participant that sent the order does not settle for the payer's participant. BCB describes it as a direct participant that is not the settling participant of the payer's participant. The SPI raises it.", "triggers": [ "A direct participant sends a payment for an indirect participant it does not settle for", "The settlement relationship was ended or never registered (reda.014, reda.031) [Inference]" ], "actions": [ "Sending participant: check the settling participant on record for the payer's participant", "Indirect participant: route through its registered settling participant" ], "retry": { "allowed": true, "rule": "Allowed once the cause is fixed. The rejected order itself is final. Resending the same operation (same EndToEndId, or same return id) within the 24-hour idempotency window only returns the earlier answer (SPI catalog 5.12, Idempotência, pp.15 to 16, and p.18), so a corrected payment goes as a new order with a new identifier [Inference]. The catalog sets no retry limit [Unverified]." }, "facts": { "return_windows": [ { "action": "reject (pacs.002 with status RJCT and this reason code)", "by": "SPI (the settlement system operated by the BCB), as the catalog domain table states", "deadline": "During SPI processing, inside the Pix time limit of 40 seconds on the primary message channel or 45 minutes on the secondary channel, which carries only scheduled Pix Agendado and Pix Cobrança orders (Manual de Tempos do Pix 7.0, sections 1.1 and 1.2). The pacs.002 goes out on the channel of the pacs.008 that started the payment (SPI catalog 5.12, Canais de Transmissão, pp.13 to 14). [Inference: a validation reject is sent at once; the Manual sets no separate time for it.]" } ], "applies_to": "Pix payment orders (pacs.008) and returns (devolução, pacs.004) settled in the SPI [Inference: the table does not limit the code to payments]" }, "caveat": null, "related": [ "pix-reject:DS0G", "pix-reject:RC09", "pix-reject:DS27" ], "basis": { "sources": "SPI message catalog 5.12.1 (spi.5.12.1.zip), PACS002.xlsx, Tabela de Domínios, entry AGNT (ISO name and definition, BCB comment, raising participant); Notas de Versão in spi.5.13.1.zip (cumulative release notes), versions 1.2 (added) and 5.03.1 (comment changed); Catálogo de Serviços do SFN Volume VI (SPI catalog) 5.12, p.21 (reda.014, reda.031) [Unverified: page not re-read for this record].", "confidence": "high" }, "currency": { "effective_since": "Catalog 1.2", "effective_note": "Added to the pacs.002 domain table in catalog 1.2, published 2020-02-18, before Pix launched; comment changed in catalog 5.03.1 (published 2021-09-03). Catalog 5.12.1 (published 2026-03-27) has been in SPI production since 2026-06-28 (BCB Comunicação eletrônica de dados page, Comunicado 44.424). Catalog 5.13.1 (SPI production 2026-10-25) keeps this code with the same comment.", "source_edition": "SPI message catalog 5.12.1 (spi.5.12.1.zip, PACS002.xlsx, pacs.002 v1.16, 2026-03-27); Manual de Tempos do Pix 7.0", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.bcb.gov.br/content/estabilidadefinanceira/cedsfn/Catalogos/spi.5.12.1.zip", "source_class": "authoritative_primary", "source_title": "SPI message catalog 5.12.1 (spi.5.12.1.zip), PACS002.xlsx Tabela de Dominios; Manual de Tempos do Pix 7.0", "checked_on": "2026-09-21", "checked_by": "validator-sonnet-2026-09-21", "notes": "Confirms code AGNT, ISO name IncorrectAgent, and the BCB comment naming a direct participant that is not the settling participant of the payer participant, raised by the SPI. Confirms the reject falls inside the 40 second primary and 45 minute secondary channel limits." } ] }, "rail_name": "Pix Payment Rejects", "governing_authority": "Banco Central do Brasil", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "pix-reject:AM01", "id": "AM01", "rail": "pix-reject", "kind": "reason-code", "name": "Zero Amount", "group": "technical", "summary": "The payment amount is zero. BCB describes it as an instant payment order with a zero value. The SPI raises it.", "triggers": [ "The amount field of the pacs.008 is zero" ], "actions": [ "Payer's participant: validate amounts before sending", "Payer: enter a positive amount" ], "retry": { "allowed": true, "rule": "Allowed once the cause is fixed. The rejected order itself is final. Resending the same operation (same EndToEndId, or same return id) within the 24-hour idempotency window only returns the earlier answer (SPI catalog 5.12, Idempotência, pp.15 to 16, and p.18), so a corrected payment goes as a new order with a new identifier [Inference]. The catalog sets no retry limit [Unverified]." }, "facts": { "return_windows": [ { "action": "reject (pacs.002 with status RJCT and this reason code)", "by": "SPI (the settlement system operated by the BCB), as the catalog domain table states", "deadline": "During SPI processing, inside the Pix time limit of 40 seconds on the primary message channel or 45 minutes on the secondary channel, which carries only scheduled Pix Agendado and Pix Cobrança orders (Manual de Tempos do Pix 7.0, sections 1.1 and 1.2). The pacs.002 goes out on the channel of the pacs.008 that started the payment (SPI catalog 5.12, Canais de Transmissão, pp.13 to 14). [Inference: a validation reject is sent at once; the Manual sets no separate time for it.]" } ], "applies_to": "Pix payment orders (pacs.008) settled in the SPI" }, "caveat": null, "related": [ "pix-reject:AM12", "pix-reject:CH16" ], "basis": { "sources": "SPI message catalog 5.12.1 (spi.5.12.1.zip), PACS002.xlsx, Tabela de Domínios, entry AM01 (ISO name and definition, BCB comment, raising participant); Manual de Tempos do Pix 7.0, sections 1.1 and 1.2.", "confidence": "high" }, "currency": { "effective_since": "Since the 2020 catalogs", "effective_note": "The code is in the pacs.002 domain table from the pre-launch catalogs of 2020; the cumulative release notes record no later addition. Catalog 5.12.1 (published 2026-03-27) has been in SPI production since 2026-06-28 (BCB Comunicação eletrônica de dados page, Comunicado 44.424). Catalog 5.13.1 (SPI production 2026-10-25) keeps this code with the same comment.", "source_edition": "SPI message catalog 5.12.1 (spi.5.12.1.zip, PACS002.xlsx, pacs.002 v1.16, 2026-03-27); Manual de Tempos do Pix 7.0", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.bcb.gov.br/content/estabilidadefinanceira/cedsfn/Catalogos/spi.5.12.1.zip", "source_class": "authoritative_primary", "source_title": "SPI message catalog 5.12.1 (spi.5.12.1.zip), PACS002.xlsx Tabela de Dominios; Manual de Tempos do Pix 7.0", "checked_on": "2026-09-21", "checked_by": "validator-sonnet-2026-09-21", "notes": "Confirms code AM01, ISO name ZeroAmount, and the BCB comment naming an instant payment order with a zero value, raised by the SPI. Confirms the reject falls inside the 40 second primary and 45 minute secondary channel limits." } ] }, "rail_name": "Pix Payment Rejects", "governing_authority": "Banco Central do Brasil", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "pix-reject:AM02", "id": "AM02", "rail": "pix-reject", "kind": "reason-code", "name": "Not Allowed Amount", "group": "account", "summary": "The credit would push the receiving account past the limit allowed for its type. BCB describes it as a payment or return whose value exceeds the limit permitted for the type of transactional account credited. The receiving participant raises it.", "triggers": [ "The credited account type has a balance or value limit that this Pix would exceed [Unverified: the catalog does not name the limits]" ], "actions": [ "Payer: send a smaller amount or pay into another account [Inference]", "Receiving participant: tell its user the account limit blocks the credit [Inference]" ], "retry": { "allowed": true, "rule": "Allowed with a lower amount or to another account. Resending the same operation (same EndToEndId, or same return id) within the 24-hour idempotency window only returns the earlier answer (SPI catalog 5.12, Idempotência, pp.15 to 16, and p.18), so a corrected payment goes as a new order with a new identifier [Inference]. The catalog sets no retry limit [Unverified]." }, "facts": { "return_windows": [ { "action": "reject (pacs.002 with status RJCT and this reason code)", "by": "Receiving participant (PSP of the receiving user), as the catalog domain table states", "deadline": "Inside the Pix time limit: the SPI rejects any Pix not settled within 40 seconds on the primary message channel or 45 minutes on the secondary channel, which carries only scheduled Pix Agendado and Pix Cobrança orders (Manual de Tempos do Pix 7.0, sections 1.1 and 1.2). On the primary channel the receiving side's answer (t3' minus t2) has a service level of 1.4 seconds at the 50th percentile and 2.3 seconds at the 95th (section 4.1.1.2)." } ], "applies_to": "Pix payment orders (pacs.008) and returns (devolução, pacs.004) settled in the SPI" }, "caveat": "This is the receiving account's limit, not a value limit set by the payer's participant under Regulamento art. 37 [Inference].", "related": [ "pix-reject:AG03", "pix-reject:AM09" ], "basis": { "sources": "SPI message catalog 5.12.1 (spi.5.12.1.zip), PACS002.xlsx, Tabela de Domínios, entry AM02 (ISO name and definition, BCB comment, raising participant); Regulamento annexed to Resolução BCB nº 1/2020 (consolidated, version 41), art. 37; Manual de Tempos do Pix 7.0, sections 1.1, 1.2 and 4.1.1.2.", "confidence": "medium" }, "currency": { "effective_since": "Catalog 5.02.1", "effective_note": "Added to the pacs.002 domain table in catalog 5.02.1, published 2021-03-19 (Notas de Versão in spi.5.13.1.zip (cumulative release notes)). Release note dates are publication dates; the SPI production date of that catalog was not read [Unverified]. Catalog 5.12.1 (published 2026-03-27) has been in SPI production since 2026-06-28 (BCB Comunicação eletrônica de dados page, Comunicado 44.424). Catalog 5.13.1 (SPI production 2026-10-25) keeps this code with the same comment.", "source_edition": "SPI message catalog 5.12.1 (spi.5.12.1.zip, PACS002.xlsx, pacs.002 v1.16, 2026-03-27); Manual de Tempos do Pix 7.0", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.bcb.gov.br/content/estabilidadefinanceira/cedsfn/Catalogos/spi.5.12.1.zip", "source_class": "authoritative_primary", "source_title": "SPI message catalog 5.12.1 (spi.5.12.1.zip), PACS002.xlsx Tabela de Dominios; Manual de Tempos do Pix 7.0", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms code AM02, ISO name NotAllowedAmount, and the BCB comment describing a value that exceeds the limit for the receiving account type, raised by the receiving participant. Confirms the reject deadline. Does not name the account limits, matching the caveat." } ] }, "rail_name": "Pix Payment Rejects", "governing_authority": "Banco Central do Brasil", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "pix-reject:AM04", "id": "AM04", "rail": "pix-reject", "kind": "reason-code", "name": "Insufficient Funds", "group": "funds", "summary": "The payer's participant has too little money in its settlement account at the BCB. BCB describes it as insufficient balance in the Conta PI of the payer's participant. The SPI raises it. It is not the customer's balance.", "triggers": [ "The Conta PI of the payer's participant (or of its settling participant) lacks the balance to settle the order" ], "actions": [ "Payer's participant or its settling participant: fund the Conta PI", "Payer's participant: tell the payer the Pix failed for a reason on the institution's side [Inference]" ], "retry": { "allowed": true, "rule": "Allowed once the Conta PI is funded. Resending the same operation (same EndToEndId, or same return id) within the 24-hour idempotency window only returns the earlier answer (SPI catalog 5.12, Idempotência, pp.15 to 16, and p.18), so a corrected payment goes as a new order with a new identifier [Inference]. The catalog sets no retry limit [Unverified]." }, "facts": { "return_windows": [ { "action": "reject (pacs.002 with status RJCT and this reason code)", "by": "SPI (the settlement system operated by the BCB), as the catalog domain table states", "deadline": "During SPI processing, inside the Pix time limit of 40 seconds on the primary message channel or 45 minutes on the secondary channel, which carries only scheduled Pix Agendado and Pix Cobrança orders (Manual de Tempos do Pix 7.0, sections 1.1 and 1.2). The pacs.002 goes out on the channel of the pacs.008 that started the payment (SPI catalog 5.12, Canais de Transmissão, pp.13 to 14). [Inference: a validation reject is sent at once; the Manual sets no separate time for it.]" } ], "applies_to": "Pix payment orders (pacs.008) and returns (devolução, pacs.004) settled in the SPI [Inference: a return also debits the returning participant's Conta PI]" }, "caveat": "The customer's own balance is checked by the payer's participant before it starts the Pix (Regulamento art. 36), so a customer's lack of funds is not reported with this code [Inference]. Rejects for a participant's lack of liquidity do not count against its availability index (Manual de Tempos do Pix 7.0, section 4.3, item f).", "related": [ "pix-reject:DS0G", "pix-reject:AGNT" ], "basis": { "sources": "SPI message catalog 5.12.1 (spi.5.12.1.zip), PACS002.xlsx, Tabela de Domínios, entry AM04 (ISO name and definition, BCB comment, raising participant); Regulamento annexed to Resolução BCB nº 1/2020 (consolidated, version 41), art. 36; Manual de Tempos do Pix 7.0, section 4.3.", "confidence": "high" }, "currency": { "effective_since": "Since the 2020 catalogs", "effective_note": "The code is in the pacs.002 domain table from the pre-launch catalogs of 2020; the cumulative release notes record no later addition. Catalog 5.12.1 (published 2026-03-27) has been in SPI production since 2026-06-28 (BCB Comunicação eletrônica de dados page, Comunicado 44.424). Catalog 5.13.1 (SPI production 2026-10-25) keeps this code with the same comment.", "source_edition": "SPI message catalog 5.12.1 (spi.5.12.1.zip, PACS002.xlsx, pacs.002 v1.16, 2026-03-27); Manual de Tempos do Pix 7.0", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.bcb.gov.br/content/estabilidadefinanceira/cedsfn/Catalogos/spi.5.12.1.zip", "source_class": "authoritative_primary", "source_title": "SPI message catalog 5.12.1 (spi.5.12.1.zip), PACS002.xlsx Tabela de Dominios; Regulamento Pix anexo a Resolucao BCB no. 1/2020 consolidated version 41; Manual de Tempos do Pix 7.0", "checked_on": "2026-09-21", "checked_by": "validator-sonnet-2026-09-21", "notes": "Confirms code AM04, ISO name InsufficientFunds, and the BCB comment naming insufficient balance in the payer participant's Conta PI, raised by the SPI. Confirms the payer's own balance is checked and blocked by the payer's participant before initiation under Regulamento art. 36, and that a reject for a participant's own lack of liquidity is excluded from its availability index under Manual de Tempos do Pix 7.0 section 4.3 item f." } ] }, "rail_name": "Pix Payment Rejects", "governing_authority": "Banco Central do Brasil", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "pix-reject:AM09", "id": "AM09", "rail": "pix-reject", "kind": "reason-code", "name": "Wrong Amount", "group": "administrative", "summary": "A return would give back more than the original Pix. BCB describes it as a return whose value exceeds the value of the corresponding instant payment order. The catalog names the receiving participant as the one that raises it.", "triggers": [ "A single return is larger than the original Pix", "Several partial returns together would exceed the original amount [Inference]" ], "actions": [ "Returning participant: return only up to the amount not yet returned; the Regulamento allows several partial returns up to the total (art. 40, §2)", "Returning participant: track amounts already returned per original EndToEndId [Inference]" ], "retry": { "allowed": true, "rule": "Allowed with an amount within what is left to return. Resending the same operation (same EndToEndId, or same return id) within the 24-hour idempotency window only returns the earlier answer (SPI catalog 5.12, Idempotência, pp.15 to 16, and p.18), so a corrected payment goes as a new order with a new identifier [Inference]. The catalog sets no retry limit [Unverified]." }, "facts": { "return_windows": [ { "action": "reject (pacs.002 with status RJCT and this reason code)", "by": "Receiving participant, as the catalog domain table states [Inference: for a return (pacs.004) this is the participant receiving the return, which is the original payer's participant; the table does not say so]", "deadline": "When the receiving participant processes the return. A return (pacs.004) and the pacs.002 answering it always use the primary channel (SPI catalog 5.12, p.14). [Unverified: the Manual de Tempos do Pix 7.0 states its 40-second limit for Pix payment orders and does not name returns.]" } ], "applies_to": "Pix returns (devolução, pacs.004) settled in the SPI" }, "caveat": "Returns also need enough funds in the returning user's account (Regulamento art. 41-A, I).", "related": [ "pix-reject:AG13", "pix-reject:DT05", "pix-reject:AM02" ], "basis": { "sources": "SPI message catalog 5.12.1 (spi.5.12.1.zip), PACS002.xlsx, Tabela de Domínios, entry AM09 (ISO name and definition, BCB comment, raising participant); Notas de Versão in spi.5.13.1.zip (cumulative release notes), version 1.2 (added); Regulamento annexed to Resolução BCB nº 1/2020 (consolidated, version 41), arts. 40 §2 and 41-A; Catálogo de Serviços do SFN Volume VI (SPI catalog) 5.12, p.14.", "confidence": "high" }, "currency": { "effective_since": "Catalog 1.2", "effective_note": "Added to the pacs.002 domain table in catalog 1.2, published 2020-02-18, before Pix launched. Catalog 5.12.1 (published 2026-03-27) has been in SPI production since 2026-06-28 (BCB Comunicação eletrônica de dados page, Comunicado 44.424). Catalog 5.13.1 (SPI production 2026-10-25) keeps this code with the same comment.", "source_edition": "SPI message catalog 5.12.1 (spi.5.12.1.zip, PACS002.xlsx, pacs.002 v1.16, 2026-03-27); Manual de Tempos do Pix 7.0", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.bcb.gov.br/content/estabilidadefinanceira/cedsfn/Catalogos/spi.5.12.1.zip", "source_class": "authoritative_primary", "source_title": "SPI message catalog 5.12.1 (spi.5.12.1.zip), PACS002.xlsx Tabela de Dominios; Regulamento Pix anexo a Resolucao BCB no. 1/2020 consolidated version 41; Catalogo de Servicos do SFN Volume VI 5.12", "checked_on": "2026-09-21", "checked_by": "validator-sonnet-2026-09-21", "notes": "Confirms code AM09, ISO name WrongAmount, and the BCB comment naming a return whose value exceeds the corresponding instant payment order, raised by the receiving participant as the table states. Confirms the Regulamento allows multiple partial returns of the same transaction up to the full amount under art. 40 paragraph 2, and that a return needs sufficient funds in the returning user's account under art. 41-A inciso I. Confirms a return and its answering reject always travel on the primary message channel." } ] }, "rail_name": "Pix Payment Rejects", "governing_authority": "Banco Central do Brasil", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "pix-reject:AM12", "id": "AM12", "rail": "pix-reject", "kind": "reason-code", "name": "Invalid Amount", "group": "technical", "summary": "The amounts in the message do not add up. BCB describes it as a mismatch between the sum of the values in the valorDoDinheiroOuCompra block and the valor field. The SPI raises it.", "triggers": [ "In a Pix Saque or Pix Troco order, the cash and purchase amounts do not sum to the total [Inference: the block carries those amounts]" ], "actions": [ "Payer's participant: validate that the detail amounts equal the total before sending" ], "retry": { "allowed": true, "rule": "Allowed once the cause is fixed. The rejected order itself is final. Resending the same operation (same EndToEndId, or same return id) within the 24-hour idempotency window only returns the earlier answer (SPI catalog 5.12, Idempotência, pp.15 to 16, and p.18), so a corrected payment goes as a new order with a new identifier [Inference]. The catalog sets no retry limit [Unverified]." }, "facts": { "return_windows": [ { "action": "reject (pacs.002 with status RJCT and this reason code)", "by": "SPI (the settlement system operated by the BCB), as the catalog domain table states", "deadline": "During SPI processing, inside the Pix time limit of 40 seconds on the primary message channel or 45 minutes on the secondary channel, which carries only scheduled Pix Agendado and Pix Cobrança orders (Manual de Tempos do Pix 7.0, sections 1.1 and 1.2). The pacs.002 goes out on the channel of the pacs.008 that started the payment (SPI catalog 5.12, Canais de Transmissão, pp.13 to 14). [Inference: a validation reject is sent at once; the Manual sets no separate time for it.]" } ], "applies_to": "Pix payment orders (pacs.008) settled in the SPI" }, "caveat": "When the code was added in 5.02.1, the release note named the block valorDaTarifaOuDinheiroOuCompra; the 5.12.1 table names it valorDoDinheiroOuCompra.", "related": [ "pix-reject:AM01", "pix-reject:AM23", "pix-reject:MD01" ], "basis": { "sources": "SPI message catalog 5.12.1 (spi.5.12.1.zip), PACS002.xlsx, Tabela de Domínios, entry AM12 (ISO name and definition, BCB comment, raising participant); Notas de Versão in spi.5.13.1.zip (cumulative release notes), version 5.02.1.", "confidence": "high" }, "currency": { "effective_since": "Catalog 5.02.1", "effective_note": "Added to the pacs.002 domain table in catalog 5.02.1, published 2021-03-19 (Notas de Versão in spi.5.13.1.zip (cumulative release notes)). Release note dates are publication dates; the SPI production date of that catalog was not read [Unverified]. Catalog 5.12.1 (published 2026-03-27) has been in SPI production since 2026-06-28 (BCB Comunicação eletrônica de dados page, Comunicado 44.424). Catalog 5.13.1 (SPI production 2026-10-25) keeps this code with the same comment.", "source_edition": "SPI message catalog 5.12.1 (spi.5.12.1.zip, PACS002.xlsx, pacs.002 v1.16, 2026-03-27); Manual de Tempos do Pix 7.0", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.bcb.gov.br/content/estabilidadefinanceira/cedsfn/Catalogos/spi.5.12.1.zip", "source_class": "authoritative_primary", "source_title": "SPI message catalog 5.12.1 (spi.5.12.1.zip), PACS002.xlsx Tabela de Dominios", "checked_on": "2026-09-21", "checked_by": "validator-sonnet-2026-09-21", "notes": "Confirms code AM12, ISO name InvalidAmount, and the BCB comment naming a mismatch between the sum of the valorDoDinheiroOuCompra block and the valor field, raised by the SPI." } ] }, "rail_name": "Pix Payment Rejects", "governing_authority": "Banco Central do Brasil", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "pix-reject:AM18", "id": "AM18", "rail": "pix-reject", "kind": "reason-code", "name": "Invalid Number Of Transactions", "group": "technical", "summary": "The count of transactions in the message is wrong. BCB describes it as an invalid number of transactions. The SPI raises it.", "triggers": [ "The number of transactions stated in the message does not match the transactions it carries [Inference]", "The message carries more transactions than allowed [Unverified]" ], "actions": [ "Sending participant: check the message's transaction count before sending" ], "retry": { "allowed": true, "rule": "Allowed once the cause is fixed. The rejected order itself is final. Resending the same operation (same EndToEndId, or same return id) within the 24-hour idempotency window only returns the earlier answer (SPI catalog 5.12, Idempotência, pp.15 to 16, and p.18), so a corrected payment goes as a new order with a new identifier [Inference]. The catalog sets no retry limit [Unverified]." }, "facts": { "return_windows": [ { "action": "reject (pacs.002 with status RJCT and this reason code)", "by": "SPI (the settlement system operated by the BCB), as the catalog domain table states", "deadline": "During SPI processing, inside the Pix time limit of 40 seconds on the primary message channel or 45 minutes on the secondary channel, which carries only scheduled Pix Agendado and Pix Cobrança orders (Manual de Tempos do Pix 7.0, sections 1.1 and 1.2). The pacs.002 goes out on the channel of the pacs.008 that started the payment (SPI catalog 5.12, Canais de Transmissão, pp.13 to 14). [Inference: a validation reject is sent at once; the Manual sets no separate time for it.]" } ], "applies_to": "Pix payment orders (pacs.008) and returns (devolução, pacs.004) settled in the SPI [Inference]" }, "caveat": "The SPI controls idempotency per operation, not per message, when one message carries several operations (SPI catalog 5.12, p.15).", "related": [ "pix-reject:CH16", "pix-reject:FF08" ], "basis": { "sources": "SPI message catalog 5.12.1 (spi.5.12.1.zip), PACS002.xlsx, Tabela de Domínios, entry AM18 (ISO name and definition, BCB comment, raising participant); Catálogo de Serviços do SFN Volume VI (SPI catalog) 5.12, Idempotência (p.15).", "confidence": "medium" }, "currency": { "effective_since": "Since the 2020 catalogs", "effective_note": "The code is in the pacs.002 domain table from the pre-launch catalogs of 2020; the cumulative release notes record no later addition. Catalog 5.12.1 (published 2026-03-27) has been in SPI production since 2026-06-28 (BCB Comunicação eletrônica de dados page, Comunicado 44.424). Catalog 5.13.1 (SPI production 2026-10-25) keeps this code with the same comment.", "source_edition": "SPI message catalog 5.12.1 (spi.5.12.1.zip, PACS002.xlsx, pacs.002 v1.16, 2026-03-27); Manual de Tempos do Pix 7.0", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.bcb.gov.br/content/estabilidadefinanceira/cedsfn/Catalogos/spi.5.12.1.zip", "source_class": "authoritative_primary", "source_title": "SPI message catalog 5.12.1 (spi.5.12.1.zip), PACS002.xlsx Tabela de Dominios", "checked_on": "2026-09-21", "checked_by": "validator-sonnet-2026-09-21", "notes": "Confirms code AM18, ISO name InvalidNumberOfTransactions, and the BCB comment naming an invalid transaction count, raised by the SPI." } ] }, "rail_name": "Pix Payment Rejects", "governing_authority": "Banco Central do Brasil", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "pix-reject:AM23", "id": "AM23", "rail": "pix-reject", "kind": "reason-code", "name": "Amount Exceeds Settlement Limit", "group": "technical", "summary": "The taxes stated in the payment add up to more than the payment. BCB describes it as a sum of the reported taxes (tributos) that is invalid because it is above the transaction value. The SPI raises it. The Pix meaning differs from the ISO name.", "triggers": [ "The tax amounts in the pacs.008 sum to more than the transaction amount" ], "actions": [ "Payer's participant: check that reported tax amounts do not exceed the payment amount before sending" ], "retry": { "allowed": true, "rule": "Allowed once the cause is fixed. The rejected order itself is final. Resending the same operation (same EndToEndId, or same return id) within the 24-hour idempotency window only returns the earlier answer (SPI catalog 5.12, Idempotência, pp.15 to 16, and p.18), so a corrected payment goes as a new order with a new identifier [Inference]. The catalog sets no retry limit [Unverified]." }, "facts": { "return_windows": [ { "action": "reject (pacs.002 with status RJCT and this reason code)", "by": "SPI (the settlement system operated by the BCB), as the catalog domain table states", "deadline": "During SPI processing, inside the Pix time limit of 40 seconds on the primary message channel or 45 minutes on the secondary channel, which carries only scheduled Pix Agendado and Pix Cobrança orders (Manual de Tempos do Pix 7.0, sections 1.1 and 1.2). The pacs.002 goes out on the channel of the pacs.008 that started the payment (SPI catalog 5.12, Canais de Transmissão, pp.13 to 14). [Inference: a validation reject is sent at once; the Manual sets no separate time for it.]" } ], "applies_to": "Pix payment orders (pacs.008) settled in the SPI" }, "caveat": "Despite the ISO name, this is not a settlement or value limit. RR06 covers when the tax block may be filled at all.", "related": [ "pix-reject:RR06", "pix-reject:AM12" ], "basis": { "sources": "SPI message catalog 5.12.1 (spi.5.12.1.zip), PACS002.xlsx, Tabela de Domínios, entry AM23 (ISO name and definition, BCB comment, raising participant); Notas de Versão in spi.5.13.1.zip (cumulative release notes), version 5.12.1.", "confidence": "high" }, "currency": { "effective_since": "2026-06-28", "effective_note": "Added in catalog 5.12.1, published 2026-03-27 (release notes); SPI production 2026-06-28 (BCB Comunicação eletrônica de dados page, Comunicado 44.424). Catalog 5.13.1 (SPI production 2026-10-25) keeps this code with the same comment.", "source_edition": "SPI message catalog 5.12.1 (spi.5.12.1.zip, PACS002.xlsx, pacs.002 v1.16, 2026-03-27); Manual de Tempos do Pix 7.0", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.bcb.gov.br/content/estabilidadefinanceira/cedsfn/Catalogos/spi.5.12.1.zip", "source_class": "authoritative_primary", "source_title": "SPI message catalog 5.12.1 (spi.5.12.1.zip), PACS002.xlsx Tabela de Dominios", "checked_on": "2026-09-21", "checked_by": "validator-sonnet-2026-09-21", "notes": "Confirms code AM23, ISO name AmountExceedsSettlementLimit, and the BCB comment naming a sum of reported taxes that results in a value above the transaction amount, raised by the SPI." } ] }, "rail_name": "Pix Payment Rejects", "governing_authority": "Banco Central do Brasil", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "pix-reject:BE01", "id": "BE01", "rail": "pix-reject", "kind": "reason-code", "name": "Inconsisten With End Customer", "group": "account", "summary": "The receiving user's tax id does not match the account holder. BCB describes it as a CPF or CNPJ of the receiving user that is not consistent with the holder of the account given. The receiving participant raises it.", "triggers": [ "The CPF or CNPJ in the pacs.008 belongs to someone other than the holder of the account given" ], "actions": [ "Payer: check the receiver's CPF or CNPJ and account with the receiver", "Payer's participant: prefer key or QR code initiation, which bring matched data [Inference]" ], "retry": { "allowed": true, "rule": "Allowed once the cause is fixed. The rejected order itself is final. Resending the same operation (same EndToEndId, or same return id) within the 24-hour idempotency window only returns the earlier answer (SPI catalog 5.12, Idempotência, pp.15 to 16, and p.18), so a corrected payment goes as a new order with a new identifier [Inference]. The catalog sets no retry limit [Unverified]." }, "facts": { "return_windows": [ { "action": "reject (pacs.002 with status RJCT and this reason code)", "by": "Receiving participant (PSP of the receiving user), as the catalog domain table states", "deadline": "Inside the Pix time limit: the SPI rejects any Pix not settled within 40 seconds on the primary message channel or 45 minutes on the secondary channel, which carries only scheduled Pix Agendado and Pix Cobrança orders (Manual de Tempos do Pix 7.0, sections 1.1 and 1.2). On the primary channel the receiving side's answer (t3' minus t2) has a service level of 1.4 seconds at the 50th percentile and 2.3 seconds at the 95th (section 4.1.1.2)." } ], "applies_to": "Pix payment orders (pacs.008) settled in the SPI" }, "caveat": "The name is spelled as the catalog writes it (Inconsisten). The Regulamento requires the receiving participant to reject when there are problems identifying the receiving user (art. 39, II) [Inference: the catalog does not tie the code to that article]. CH11 is the code for an incorrect CPF or CNPJ.", "related": [ "pix-reject:CH11", "pix-reject:AC03" ], "basis": { "sources": "SPI message catalog 5.12.1 (spi.5.12.1.zip), PACS002.xlsx, Tabela de Domínios, entry BE01 (ISO name and definition, BCB comment, raising participant); Regulamento annexed to Resolução BCB nº 1/2020 (consolidated, version 41), art. 39, II; Manual de Tempos do Pix 7.0, sections 1.1, 1.2 and 4.1.1.2.", "confidence": "high" }, "currency": { "effective_since": "Since the 2020 catalogs", "effective_note": "The code is in the pacs.002 domain table from the pre-launch catalogs of 2020; the cumulative release notes record no later addition. Catalog 5.12.1 (published 2026-03-27) has been in SPI production since 2026-06-28 (BCB Comunicação eletrônica de dados page, Comunicado 44.424). Catalog 5.13.1 (SPI production 2026-10-25) keeps this code with the same comment.", "source_edition": "SPI message catalog 5.12.1 (spi.5.12.1.zip, PACS002.xlsx, pacs.002 v1.16, 2026-03-27); Manual de Tempos do Pix 7.0", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.bcb.gov.br/content/estabilidadefinanceira/cedsfn/Catalogos/spi.5.12.1.zip", "source_class": "authoritative_primary", "source_title": "SPI message catalog 5.12.1 (spi.5.12.1.zip), PACS002.xlsx Tabela de Dominios; Manual de Tempos do Pix 7.0", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms code BE01, the catalog's own spelling InconsistenWithEndCustomer, and the BCB comment describing a tax id mismatch on the receiving side, raised by the receiving participant. Confirms the reject deadline." } ] }, "rail_name": "Pix Payment Rejects", "governing_authority": "Banco Central do Brasil", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "pix-reject:BE05", "id": "BE05", "rail": "pix-reject", "kind": "reason-code", "name": "Unrecognised Initiating Party", "group": "network", "summary": "The payment initiator is not a registered Pix participant. BCB describes it as a payment initiator whose CNPJ is not registered in the Pix arrangement. The SPI raises it.", "triggers": [ "A Pix started through a payment initiation service carries an initiator CNPJ the Pix arrangement does not know" ], "actions": [ "Payer's participant: check the initiator's CNPJ against the Pix participant list", "Payment initiator: complete its registration in Pix before starting payments [Inference]" ], "retry": { "allowed": true, "rule": "Allowed once the initiator is registered or the CNPJ is corrected. Resending the same operation (same EndToEndId, or same return id) within the 24-hour idempotency window only returns the earlier answer (SPI catalog 5.12, Idempotência, pp.15 to 16, and p.18), so a corrected payment goes as a new order with a new identifier [Inference]. The catalog sets no retry limit [Unverified]." }, "facts": { "return_windows": [ { "action": "reject (pacs.002 with status RJCT and this reason code)", "by": "SPI (the settlement system operated by the BCB), as the catalog domain table states", "deadline": "During SPI processing, inside the Pix time limit of 40 seconds on the primary message channel or 45 minutes on the secondary channel, which carries only scheduled Pix Agendado and Pix Cobrança orders (Manual de Tempos do Pix 7.0, sections 1.1 and 1.2). The pacs.002 goes out on the channel of the pacs.008 that started the payment (SPI catalog 5.12, Canais de Transmissão, pp.13 to 14). [Inference: a validation reject is sent at once; the Manual sets no separate time for it.]" } ], "applies_to": "Pix payment orders (pacs.008) settled in the SPI" }, "caveat": "The BCB participant list (https://www.bcb.gov.br/estabilidadefinanceira/participantespix) was not opened for this record [Unverified].", "related": [ "pix-reject:DS27", "pix-reject:RC09" ], "basis": { "sources": "SPI message catalog 5.12.1 (spi.5.12.1.zip), PACS002.xlsx, Tabela de Domínios, entry BE05 (ISO name and definition, BCB comment, raising participant); Notas de Versão in spi.5.13.1.zip (cumulative release notes), version 5.02.4.", "confidence": "medium" }, "currency": { "effective_since": "Catalog 5.02.4", "effective_note": "Added to the pacs.002 domain table in catalog 5.02.4, published 2021-07-07 (updated 2021-08-19) (Notas de Versão in spi.5.13.1.zip (cumulative release notes)). Release note dates are publication dates; the SPI production date of that catalog was not read [Unverified]. Catalog 5.12.1 (published 2026-03-27) has been in SPI production since 2026-06-28 (BCB Comunicação eletrônica de dados page, Comunicado 44.424). Catalog 5.13.1 (SPI production 2026-10-25) keeps this code with the same comment.", "source_edition": "SPI message catalog 5.12.1 (spi.5.12.1.zip, PACS002.xlsx, pacs.002 v1.16, 2026-03-27); Manual de Tempos do Pix 7.0", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.bcb.gov.br/content/estabilidadefinanceira/cedsfn/Catalogos/spi.5.12.1.zip", "source_class": "authoritative_primary", "source_title": "SPI message catalog 5.12.1 (spi.5.12.1.zip), PACS002.xlsx Tabela de Dominios", "checked_on": "2026-09-21", "checked_by": "validator-sonnet-2026-09-21", "notes": "Confirms code BE05, ISO name UnrecognisedInitiatingParty, and the BCB comment naming a payment initiator CNPJ not registered in the Pix arrangement, raised by the SPI." } ] }, "rail_name": "Pix Payment Rejects", "governing_authority": "Banco Central do Brasil", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "pix-reject:BE15", "id": "BE15", "rail": "pix-reject", "kind": "reason-code", "name": "Invalid Identification Code", "group": "technical", "summary": "The receiver's reconciliation id is missing or wrong. BCB describes it as the idConciliacaoRecebedor field left empty when it should be filled, or filled incorrectly. The receiving participant raises it.", "triggers": [ "A payment that needs the receiver's reconciliation id (for example from a dynamic QR code) arrives without it [Inference]", "The reconciliation id does not match what the receiving participant expects" ], "actions": [ "Payer's participant: copy the reconciliation id exactly from the QR code or charge", "Payer: scan the QR code again rather than typing details [Inference]" ], "retry": { "allowed": true, "rule": "Allowed once the cause is fixed. The rejected order itself is final. Resending the same operation (same EndToEndId, or same return id) within the 24-hour idempotency window only returns the earlier answer (SPI catalog 5.12, Idempotência, pp.15 to 16, and p.18), so a corrected payment goes as a new order with a new identifier [Inference]. The catalog sets no retry limit [Unverified]." }, "facts": { "return_windows": [ { "action": "reject (pacs.002 with status RJCT and this reason code)", "by": "Receiving participant (PSP of the receiving user), as the catalog domain table states", "deadline": "Inside the Pix time limit: the SPI rejects any Pix not settled within 40 seconds on the primary message channel or 45 minutes on the secondary channel, which carries only scheduled Pix Agendado and Pix Cobrança orders (Manual de Tempos do Pix 7.0, sections 1.1 and 1.2). On the primary channel the receiving side's answer (t3' minus t2) has a service level of 1.4 seconds at the 50th percentile and 2.3 seconds at the 95th (section 4.1.1.2)." } ], "applies_to": "Pix payment orders (pacs.008) settled in the SPI" }, "caveat": "BE15 had a different meaning when first added in 5.02.1 (an invalid payment status or error code); it was removed in 5.03.1, added again in 5.09.1, and given its present description in 5.11.1.", "related": [ "pix-reject:DUPL", "pix-reject:INDT", "pix-reject:BE17" ], "basis": { "sources": "SPI message catalog 5.12.1 (spi.5.12.1.zip), PACS002.xlsx, Tabela de Domínios, entry BE15 (ISO name and definition, BCB comment, raising participant); Notas de Versão in spi.5.13.1.zip (cumulative release notes), versions 5.02.1, 5.03.1, 5.09.1 and 5.11.1.", "confidence": "high" }, "currency": { "effective_since": "Catalog 5.11.1", "effective_note": "Current description from catalog 5.11.1, published 2025-09-12; the code was re-added in 5.09.1 (published 2024-08-30) (release notes). Release note dates are publication dates; the SPI production date of that catalog was not read [Unverified]. Catalog 5.12.1 (published 2026-03-27) has been in SPI production since 2026-06-28 (BCB Comunicação eletrônica de dados page, Comunicado 44.424). Catalog 5.13.1 (SPI production 2026-10-25) keeps this code with the same comment.", "source_edition": "SPI message catalog 5.12.1 (spi.5.12.1.zip, PACS002.xlsx, pacs.002 v1.16, 2026-03-27); Manual de Tempos do Pix 7.0", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.bcb.gov.br/content/estabilidadefinanceira/cedsfn/Catalogos/spi.5.12.1.zip", "source_class": "authoritative_primary", "source_title": "SPI message catalog 5.12.1 (spi.5.12.1.zip), PACS002.xlsx Tabela de Dominios; Manual de Tempos do Pix 7.0", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms code BE15, ISO name InvalidIdentificationCode, and the current BCB comment on the receiver reconciliation id field, raised by the receiving participant. Confirms the reject deadline. Does not confirm the prior-version history in the caveat, which comes from the release notes rather than this domain table." } ] }, "rail_name": "Pix Payment Rejects", "governing_authority": "Banco Central do Brasil", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "pix-reject:BE17", "id": "BE17", "rail": "pix-reject", "kind": "reason-code", "name": "Invalid Creditor Identification Code", "group": "administrative", "summary": "The receiving participant refuses the QR code the payment came from. BCB describes it as a QR code rejected by the receiving user's participant. The receiving participant raises it.", "triggers": [ "The QR code behind the payment is expired, already used, or unknown to the receiving participant [Inference: the catalog gives no causes]" ], "actions": [ "Payer: ask the receiver for a new QR code", "Receiving participant: tell its user the QR code is no longer valid [Inference]" ], "retry": { "allowed": true, "rule": "Allowed with a valid QR code. Resending the same operation (same EndToEndId, or same return id) within the 24-hour idempotency window only returns the earlier answer (SPI catalog 5.12, Idempotência, pp.15 to 16, and p.18), so a corrected payment goes as a new order with a new identifier [Inference]. The catalog sets no retry limit [Unverified]." }, "facts": { "return_windows": [ { "action": "reject (pacs.002 with status RJCT and this reason code)", "by": "Receiving participant (PSP of the receiving user), as the catalog domain table states", "deadline": "Inside the Pix time limit: the SPI rejects any Pix not settled within 40 seconds on the primary message channel or 45 minutes on the secondary channel, which carries only scheduled Pix Agendado and Pix Cobrança orders (Manual de Tempos do Pix 7.0, sections 1.1 and 1.2). On the primary channel the receiving side's answer (t3' minus t2) has a service level of 1.4 seconds at the 50th percentile and 2.3 seconds at the 95th (section 4.1.1.2)." } ], "applies_to": "Pix payment orders (pacs.008) settled in the SPI" }, "caveat": "The Regulamento lets the receiving participant reject a Pix Cobrança payment that does not match the charge's parameters (art. 39-A) [Inference: the catalog does not tie the code to that article]. INDT covers content that does not match the QR code's parameters.", "related": [ "pix-reject:INDT", "pix-reject:BE15", "pix-reject:DU03" ], "basis": { "sources": "SPI message catalog 5.12.1 (spi.5.12.1.zip), PACS002.xlsx, Tabela de Domínios, entry BE17 (ISO name and definition, BCB comment, raising participant); Notas de Versão in spi.5.13.1.zip (cumulative release notes), version 5.02.2; Regulamento annexed to Resolução BCB nº 1/2020 (consolidated, version 41), art. 39-A.", "confidence": "medium" }, "currency": { "effective_since": "Catalog 5.02.2", "effective_note": "Added to the pacs.002 domain table in catalog 5.02.2, published 2021-04-20 (Notas de Versão in spi.5.13.1.zip (cumulative release notes)). Release note dates are publication dates; the SPI production date of that catalog was not read [Unverified]. Catalog 5.12.1 (published 2026-03-27) has been in SPI production since 2026-06-28 (BCB Comunicação eletrônica de dados page, Comunicado 44.424). Catalog 5.13.1 (SPI production 2026-10-25) keeps this code with the same comment.", "source_edition": "SPI message catalog 5.12.1 (spi.5.12.1.zip, PACS002.xlsx, pacs.002 v1.16, 2026-03-27); Manual de Tempos do Pix 7.0", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.bcb.gov.br/content/estabilidadefinanceira/cedsfn/Catalogos/spi.5.12.1.zip", "source_class": "authoritative_primary", "source_title": "SPI message catalog 5.12.1 (spi.5.12.1.zip), PACS002.xlsx Tabela de Dominios; Manual de Tempos do Pix 7.0", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms code BE17, ISO name InvalidCreditorIdentificationCode, and the BCB comment describing a QR code rejected by the receiving participant. Confirms the reject deadline. Does not tie the code to Regulamento art. 39-A, matching the caveat." } ] }, "rail_name": "Pix Payment Rejects", "governing_authority": "Banco Central do Brasil", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "pix-reject:CH11", "id": "CH11", "rail": "pix-reject", "kind": "reason-code", "name": "Creditor Identifier Incorrect", "group": "account", "summary": "The receiving user's tax id is wrong. BCB describes it as an incorrect CPF or CNPJ of the receiving user. The receiving participant raises it.", "triggers": [ "The CPF or CNPJ given for the receiver is wrong or badly formed [Inference: the catalog does not say how it differs from BE01]" ], "actions": [ "Payer: confirm the receiver's CPF or CNPJ", "Payer's participant: validate tax id check digits before sending [Inference]" ], "retry": { "allowed": true, "rule": "Allowed once the cause is fixed. The rejected order itself is final. Resending the same operation (same EndToEndId, or same return id) within the 24-hour idempotency window only returns the earlier answer (SPI catalog 5.12, Idempotência, pp.15 to 16, and p.18), so a corrected payment goes as a new order with a new identifier [Inference]. The catalog sets no retry limit [Unverified]." }, "facts": { "return_windows": [ { "action": "reject (pacs.002 with status RJCT and this reason code)", "by": "Receiving participant (PSP of the receiving user), as the catalog domain table states", "deadline": "Inside the Pix time limit: the SPI rejects any Pix not settled within 40 seconds on the primary message channel or 45 minutes on the secondary channel, which carries only scheduled Pix Agendado and Pix Cobrança orders (Manual de Tempos do Pix 7.0, sections 1.1 and 1.2). On the primary channel the receiving side's answer (t3' minus t2) has a service level of 1.4 seconds at the 50th percentile and 2.3 seconds at the 95th (section 4.1.1.2)." } ], "applies_to": "Pix payment orders (pacs.008) settled in the SPI" }, "caveat": "BE01 is the code for a tax id that does not match the account holder.", "related": [ "pix-reject:BE01", "pix-reject:AC03" ], "basis": { "sources": "SPI message catalog 5.12.1 (spi.5.12.1.zip), PACS002.xlsx, Tabela de Domínios, entry CH11 (ISO name and definition, BCB comment, raising participant); Regulamento annexed to Resolução BCB nº 1/2020 (consolidated, version 41), art. 39, II; Manual de Tempos do Pix 7.0, sections 1.1, 1.2 and 4.1.1.2.", "confidence": "medium" }, "currency": { "effective_since": "Since the 2020 catalogs", "effective_note": "The code is in the pacs.002 domain table from the pre-launch catalogs of 2020; the cumulative release notes record no later addition. Catalog 5.12.1 (published 2026-03-27) has been in SPI production since 2026-06-28 (BCB Comunicação eletrônica de dados page, Comunicado 44.424). Catalog 5.13.1 (SPI production 2026-10-25) keeps this code with the same comment.", "source_edition": "SPI message catalog 5.12.1 (spi.5.12.1.zip, PACS002.xlsx, pacs.002 v1.16, 2026-03-27); Manual de Tempos do Pix 7.0", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.bcb.gov.br/content/estabilidadefinanceira/cedsfn/Catalogos/spi.5.12.1.zip", "source_class": "authoritative_primary", "source_title": "SPI message catalog 5.12.1 (spi.5.12.1.zip), PACS002.xlsx Tabela de Dominios; Manual de Tempos do Pix 7.0", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms code CH11, ISO name CreditorIdentifierIncorrect, and the BCB comment describing a wrong receiving-user tax id, raised by the receiving participant. Confirms the reject deadline." } ] }, "rail_name": "Pix Payment Rejects", "governing_authority": "Banco Central do Brasil", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "pix-reject:CH16", "id": "CH16", "rail": "pix-reject", "kind": "reason-code", "name": "Element Content Formally Incorrect", "group": "technical", "summary": "The message content is wrong or breaks a business rule. BCB describes it as incorrect message content, or content incompatible with business rules. The SPI raises it.", "triggers": [ "A field holds a value the business rules of the catalog do not allow", "Fields are inconsistent with each other in a way no more specific code covers [Inference]" ], "actions": [ "Sending participant: check the message against the catalog's rules for Brazil (Regra para o Brasil) in the message spreadsheet", "Sending participant: use the free-text detail in AdditionalInformation, if present, to find the field [Inference]" ], "retry": { "allowed": true, "rule": "Allowed once the cause is fixed. The rejected order itself is final. Resending the same operation (same EndToEndId, or same return id) within the 24-hour idempotency window only returns the earlier answer (SPI catalog 5.12, Idempotência, pp.15 to 16, and p.18), so a corrected payment goes as a new order with a new identifier [Inference]. The catalog sets no retry limit [Unverified]." }, "facts": { "return_windows": [ { "action": "reject (pacs.002 with status RJCT and this reason code)", "by": "SPI (the settlement system operated by the BCB), as the catalog domain table states", "deadline": "During SPI processing, inside the Pix time limit of 40 seconds on the primary message channel or 45 minutes on the secondary channel, which carries only scheduled Pix Agendado and Pix Cobrança orders (Manual de Tempos do Pix 7.0, sections 1.1 and 1.2). The pacs.002 goes out on the channel of the pacs.008 that started the payment (SPI catalog 5.12, Canais de Transmissão, pp.13 to 14). [Inference: a validation reject is sent at once; the Manual sets no separate time for it.]" } ], "applies_to": "Pix payment orders (pacs.008) and returns (devolução, pacs.004) settled in the SPI" }, "caveat": "Schema, signature and sender errors are reported with admi.002, not pacs.002 (SPI catalog 5.12, p.17).", "related": [ "pix-reject:AM18", "pix-reject:DT02", "pix-reject:FF07", "pix-reject:FF08" ], "basis": { "sources": "SPI message catalog 5.12.1 (spi.5.12.1.zip), PACS002.xlsx, Tabela de Domínios, entry CH16 (ISO name and definition, BCB comment, raising participant); Notas de Versão in spi.5.13.1.zip (cumulative release notes), version 5.03.1 (comment changed); Catálogo de Serviços do SFN Volume VI (SPI catalog) 5.12, p.17; PACS002.xlsx layout, AdditionalInformation.", "confidence": "high" }, "currency": { "effective_since": "Since the 2020 catalogs", "effective_note": "The code is in the pacs.002 domain table from the pre-launch catalogs of 2020; the cumulative release notes record no later addition. Catalog 5.12.1 (published 2026-03-27) has been in SPI production since 2026-06-28 (BCB Comunicação eletrônica de dados page, Comunicado 44.424). Catalog 5.13.1 (SPI production 2026-10-25) keeps this code with the same comment.", "source_edition": "SPI message catalog 5.12.1 (spi.5.12.1.zip, PACS002.xlsx, pacs.002 v1.16, 2026-03-27); Manual de Tempos do Pix 7.0", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.bcb.gov.br/content/estabilidadefinanceira/cedsfn/Catalogos/spi.5.12.1.zip", "source_class": "authoritative_primary", "source_title": "SPI message catalog 5.12.1 (spi.5.12.1.zip), PACS002.xlsx Tabela de Dominios; Catalogo de Servicos do SFN Volume VI 5.12", "checked_on": "2026-09-21", "checked_by": "validator-sonnet-2026-09-21", "notes": "Confirms code CH16, ISO name ElementContentFormallyIncorrect, and the BCB comment naming message content filled incorrectly or incompatible with the business rules, raised by the SPI. Confirms non terminal processing errors are reported with admi.002 rather than a pacs.002 reject." } ] }, "rail_name": "Pix Payment Rejects", "governing_authority": "Banco Central do Brasil", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "pix-reject:CN01", "id": "CN01", "rail": "pix-reject", "kind": "reason-code", "name": "Authorisation Cancelled", "group": "authorization", "summary": "The recurring payment was cancelled before it ran. BCB describes it as a scheduled recurring payment cancelled with cancellation status ACCR (confirmed). The receiving participant raises it.", "triggers": [ "A Pix Automático or scheduled recurring debit arrives after its cancellation was confirmed (status ACCR) [Inference: ACCR is the camt.029 confirmation of a camt.055 cancellation]" ], "actions": [ "Payer's participant: stop sending payments for a schedule whose cancellation is confirmed", "Payer's participant: keep cancellation status in step with the receiving participant [Inference]" ], "retry": { "allowed": false, "rule": "Not for the same reason. The schedule is cancelled. Resending the same operation (same EndToEndId, or same return id) within the 24-hour idempotency window only returns the earlier answer (SPI catalog 5.12, Idempotência, pp.15 to 16, and p.18), so a corrected payment goes as a new order with a new identifier [Inference]. The catalog sets no retry limit [Unverified]." }, "facts": { "return_windows": [ { "action": "reject (pacs.002 with status RJCT and this reason code)", "by": "Receiving participant (PSP of the receiving user), as the catalog domain table states", "deadline": "Inside the Pix time limit: the SPI rejects any Pix not settled within 40 seconds on the primary message channel or 45 minutes on the secondary channel, which carries only scheduled Pix Agendado and Pix Cobrança orders (Manual de Tempos do Pix 7.0, sections 1.1 and 1.2). On the primary channel the receiving side's answer (t3' minus t2) has a service level of 1.4 seconds at the 50th percentile and 2.3 seconds at the 95th (section 4.1.1.2). Scheduled orders use the secondary channel (Manual de Tempos do Pix 7.0, section 1.2)." } ], "applies_to": "Pix payment orders (pacs.008) settled in the SPI, for scheduled recurring payments" }, "caveat": "The camt.055 and camt.029 flow is described in the Manual de Fluxos do Processo de Efetivação do Pix, which was not read [Unverified]. The Manual de Tempos gives 12 hours for the camt.029 answer to a cancellation (section 3.4).", "related": [ "pix-reject:UPAY", "pix-reject:INDT" ], "basis": { "sources": "SPI message catalog 5.12.1 (spi.5.12.1.zip), PACS002.xlsx, Tabela de Domínios, entry CN01 (ISO name and definition, BCB comment, raising participant); Notas de Versão in spi.5.13.1.zip (cumulative release notes), version 5.09.1; Manual de Tempos do Pix 7.0, sections 1.2 and 3.4.", "confidence": "medium" }, "currency": { "effective_since": "Catalog 5.09.1", "effective_note": "Added to the pacs.002 domain table in catalog 5.09.1, published 2024-08-30 (Notas de Versão in spi.5.13.1.zip (cumulative release notes)). Release note dates are publication dates; the SPI production date of that catalog was not read [Unverified]. Catalog 5.12.1 (published 2026-03-27) has been in SPI production since 2026-06-28 (BCB Comunicação eletrônica de dados page, Comunicado 44.424). Catalog 5.13.1 (SPI production 2026-10-25) keeps this code with the same comment.", "source_edition": "SPI message catalog 5.12.1 (spi.5.12.1.zip, PACS002.xlsx, pacs.002 v1.16, 2026-03-27); Manual de Tempos do Pix 7.0", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.bcb.gov.br/content/estabilidadefinanceira/cedsfn/Catalogos/spi.5.12.1.zip", "source_class": "authoritative_primary", "source_title": "SPI message catalog 5.12.1 (spi.5.12.1.zip), PACS002.xlsx Tabela de Dominios; Manual de Tempos do Pix 7.0", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms code CN01, ISO name AuthorisationCancelled, and the BCB comment describing a recurring payment cancelled with status ACCR, raised by the receiving participant. Confirms the reject deadline. Does not describe the camt.055 and camt.029 flow, matching the caveat." } ] }, "rail_name": "Pix Payment Rejects", "governing_authority": "Banco Central do Brasil", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "pix-reject:DS02", "id": "DS02", "rail": "pix-reject", "kind": "reason-code", "name": "Order Cancelled", "group": "network", "summary": "The SPI refuses the order because of limits the sending institution set for itself. BCB describes it as a payment order rejected under settings the institution's operators made in SPI-Web: a manual block on sending Pix, an automatic block on sending Pix, or reaching the Conta PI minimum operating balance. The SPI raises it. Valid from 2026-10-25.", "triggers": [ "The institution's operators have manually blocked outgoing Pix in SPI-Web", "An automatic block on outgoing Pix configured in SPI-Web is active", "The Conta PI has reached the minimum operating limit configured in SPI-Web" ], "actions": [ "Payer's participant: check its SPI-Web settings and Conta PI balance, then lift the block or fund the account [Inference]", "Payer's participant: tell the payer the Pix failed for a reason on the institution's side [Inference]" ], "retry": { "allowed": true, "rule": "Allowed once the block is lifted or the balance is above the configured floor. Resending the same operation (same EndToEndId, or same return id) within the 24-hour idempotency window only returns the earlier answer (SPI catalog 5.12, Idempotência, pp.15 to 16, and p.18), so a corrected payment goes as a new order with a new identifier [Inference]. The catalog sets no retry limit [Unverified]." }, "facts": { "return_windows": [ { "action": "reject (pacs.002 with status RJCT and this reason code)", "by": "SPI (the settlement system operated by the BCB), as the catalog domain table states", "deadline": "During SPI processing, inside the Pix time limit of 40 seconds on the primary message channel or 45 minutes on the secondary channel, which carries only scheduled Pix Agendado and Pix Cobrança orders (Manual de Tempos do Pix 7.0, sections 1.1 and 1.2). The pacs.002 goes out on the channel of the pacs.008 that started the payment (SPI catalog 5.12, Canais de Transmissão, pp.13 to 14). [Inference: a validation reject is sent at once; the Manual sets no separate time for it.]" } ], "applies_to": "Pix payment orders (pacs.008) settled in the SPI" }, "caveat": "Not valid before 2026-10-25. SPI-Web is the BCB's web interface for participants [Unverified: not described in the texts read]. AM04 covers a Conta PI balance too low to settle.", "related": [ "pix-reject:AM04", "pix-reject:DS0G" ], "basis": { "sources": "SPI message catalog 5.13.1 (spi.5.13.1.zip), PACS002.xlsx, Tabela de Domínios, entry DS02 (ISO name and definition, BCB comment, raising participant); Notas de Versão in spi.5.13.1.zip (cumulative release notes), version 5.13.1; BCB Comunicação eletrônica de dados page (SPI production date).", "confidence": "medium" }, "currency": { "effective_since": "2026-10-25", "effective_note": "Added in catalog 5.13.1; in force 2026-10-25; pending at snapshot 2026-09-17", "source_edition": "SPI message catalog 5.13.1 (spi.5.13.1.zip, PACS002.xlsx, pacs.002 v1.17, 2026-07-24); Manual de Tempos do Pix 7.0", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.bcb.gov.br/content/estabilidadefinanceira/cedsfn/Catalogos/spi.5.13.1.zip", "source_class": "authoritative_primary", "source_title": "SPI message catalog 5.13.1 (spi.5.13.1.zip), PACS002.xlsx Tabela de Dominios; BCB Comunicacao eletronica de dados page", "checked_on": "2026-09-21", "checked_by": "validator-sonnet-2026-09-21", "notes": "Confirms code DS02, ISO name OrderCancelled, and the BCB comment naming a reject under settings the sending institution's own operators configured in SPI-Web, a manual block on sending Pix, an automatic block on sending Pix, or reaching the Conta PI minimum operating balance, raised by the SPI. Confirms catalog 5.13.1 enters SPI production on 2026-10-25 under Comunicado 45.630." } ] }, "rail_name": "Pix Payment Rejects", "governing_authority": "Banco Central do Brasil", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "window", "label": "the payment date", "needs": "the date of the payment you are asking about", "detail": "This code takes effect 2026-10-25, after the corpus snapshot 2026-09-20, so it does not state the rule in force at that snapshot.", "from": "currency.effective_since" } ] }, { "uid": "pix-reject:DS04", "id": "DS04", "rail": "pix-reject", "kind": "reason-code", "name": "Order Rejected", "group": "administrative", "summary": "The receiving participant rejects the order without a more specific reason. BCB describes it as an order rejected by the receiving user's participant. The receiving participant raises it.", "triggers": [ "The receiving participant refuses the order for a reason no other code covers [Inference]" ], "actions": [ "Payer: contact the receiver to find out why", "Receiving participant: use a specific code where one fits [Inference]" ], "retry": { "allowed": false, "rule": "Not for the same reason. The cause is not stated, so sending the same order again is likely to fail the same way [Inference]. Resending the same operation (same EndToEndId, or same return id) within the 24-hour idempotency window only returns the earlier answer (SPI catalog 5.12, Idempotência, pp.15 to 16, and p.18), so a corrected payment goes as a new order with a new identifier [Inference]. The catalog sets no retry limit [Unverified]." }, "facts": { "return_windows": [ { "action": "reject (pacs.002 with status RJCT and this reason code)", "by": "Receiving participant (PSP of the receiving user), as the catalog domain table states", "deadline": "Inside the Pix time limit: the SPI rejects any Pix not settled within 40 seconds on the primary message channel or 45 minutes on the secondary channel, which carries only scheduled Pix Agendado and Pix Cobrança orders (Manual de Tempos do Pix 7.0, sections 1.1 and 1.2). On the primary channel the receiving side's answer (t3' minus t2) has a service level of 1.4 seconds at the 50th percentile and 2.3 seconds at the 95th (section 4.1.1.2)." } ], "applies_to": "Pix payment orders (pacs.008) and returns (devolução, pacs.004) settled in the SPI [Inference: the table does not limit the code to payments]" }, "caveat": "The catalog comment is generic.", "related": [ "pix-reject:AB09", "pix-reject:ED05", "pix-reject:FRAD" ], "basis": { "sources": "SPI message catalog 5.12.1 (spi.5.12.1.zip), PACS002.xlsx, Tabela de Domínios, entry DS04 (ISO name and definition, BCB comment, raising participant); Manual de Tempos do Pix 7.0, sections 1.1, 1.2 and 4.1.1.2.", "confidence": "medium" }, "currency": { "effective_since": "Since the 2020 catalogs", "effective_note": "The code is in the pacs.002 domain table from the pre-launch catalogs of 2020; the cumulative release notes record no later addition. Catalog 5.12.1 (published 2026-03-27) has been in SPI production since 2026-06-28 (BCB Comunicação eletrônica de dados page, Comunicado 44.424). Catalog 5.13.1 (SPI production 2026-10-25) keeps this code with the same comment.", "source_edition": "SPI message catalog 5.12.1 (spi.5.12.1.zip, PACS002.xlsx, pacs.002 v1.16, 2026-03-27); Manual de Tempos do Pix 7.0", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.bcb.gov.br/content/estabilidadefinanceira/cedsfn/Catalogos/spi.5.12.1.zip", "source_class": "authoritative_primary", "source_title": "SPI message catalog 5.12.1 (spi.5.12.1.zip), PACS002.xlsx Tabela de Dominios; Manual de Tempos do Pix 7.0", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms code DS04, ISO name OrderRejected, and the generic BCB comment for a receiving participant content reject. Confirms the reject deadline." } ] }, "rail_name": "Pix Payment Rejects", "governing_authority": "Banco Central do Brasil", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "pix-reject:DS0G", "id": "DS0G", "rail": "pix-reject", "kind": "reason-code", "name": "Not Allowed Payment", "group": "network", "summary": "The participant that signed the message may not move money from the debited settlement account. BCB describes it as a signer that holds neither the debited Conta PI nor the SPI settlement role for the payer's participant. The SPI raises it.", "triggers": [ "A message is signed by a participant that neither holds the debited Conta PI nor settles in the SPI for the payer's participant" ], "actions": [ "Sending participant: sign with the certificate of the Conta PI holder or of the settling participant", "Indirect participant: send through its settling participant [Inference]" ], "retry": { "allowed": true, "rule": "Allowed once the cause is fixed. The rejected order itself is final. Resending the same operation (same EndToEndId, or same return id) within the 24-hour idempotency window only returns the earlier answer (SPI catalog 5.12, Idempotência, pp.15 to 16, and p.18), so a corrected payment goes as a new order with a new identifier [Inference]. The catalog sets no retry limit [Unverified]." }, "facts": { "return_windows": [ { "action": "reject (pacs.002 with status RJCT and this reason code)", "by": "SPI (the settlement system operated by the BCB), as the catalog domain table states", "deadline": "During SPI processing, inside the Pix time limit of 40 seconds on the primary message channel or 45 minutes on the secondary channel, which carries only scheduled Pix Agendado and Pix Cobrança orders (Manual de Tempos do Pix 7.0, sections 1.1 and 1.2). The pacs.002 goes out on the channel of the pacs.008 that started the payment (SPI catalog 5.12, Canais de Transmissão, pp.13 to 14). [Inference: a validation reject is sent at once; the Manual sets no separate time for it.]" } ], "applies_to": "Pix payment orders (pacs.008) and returns (devolução, pacs.004) settled in the SPI" }, "caveat": null, "related": [ "pix-reject:AGNT", "pix-reject:AM04", "pix-reject:DS27" ], "basis": { "sources": "SPI message catalog 5.12.1 (spi.5.12.1.zip), PACS002.xlsx, Tabela de Domínios, entry DS0G (ISO name and definition, BCB comment, raising participant).", "confidence": "high" }, "currency": { "effective_since": "Since the 2020 catalogs", "effective_note": "The code is in the pacs.002 domain table from the pre-launch catalogs of 2020; the cumulative release notes record no later addition. Catalog 5.12.1 (published 2026-03-27) has been in SPI production since 2026-06-28 (BCB Comunicação eletrônica de dados page, Comunicado 44.424). Catalog 5.13.1 (SPI production 2026-10-25) keeps this code with the same comment.", "source_edition": "SPI message catalog 5.12.1 (spi.5.12.1.zip, PACS002.xlsx, pacs.002 v1.16, 2026-03-27); Manual de Tempos do Pix 7.0", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.bcb.gov.br/content/estabilidadefinanceira/cedsfn/Catalogos/spi.5.12.1.zip", "source_class": "authoritative_primary", "source_title": "SPI message catalog 5.12.1 (spi.5.12.1.zip), PACS002.xlsx Tabela de Dominios", "checked_on": "2026-09-21", "checked_by": "validator-sonnet-2026-09-21", "notes": "Confirms code DS0G, ISO name NotAllowedPayment, and the BCB comment naming a signer that holds neither the debited Conta PI nor the settling role in the SPI for the payer participant, raised by the SPI." } ] }, "rail_name": "Pix Payment Rejects", "governing_authority": "Banco Central do Brasil", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "pix-reject:DS27", "id": "DS27", "rail": "pix-reject", "kind": "reason-code", "name": "User Not Yet Activated", "group": "network", "summary": "A participant in the payment is not yet live in the SPI. BCB describes it as a participant not registered or not yet operating in the SPI. The SPI raises it.", "triggers": [ "The payment names a participant that is not registered in the SPI", "The participant is registered but has not started operating" ], "actions": [ "Sending participant: check the participant list and start date [Inference]", "Payer: use another receiving account until the participant is live [Inference]" ], "retry": { "allowed": true, "rule": "Allowed once the participant is operating. Resending the same operation (same EndToEndId, or same return id) within the 24-hour idempotency window only returns the earlier answer (SPI catalog 5.12, Idempotência, pp.15 to 16, and p.18), so a corrected payment goes as a new order with a new identifier [Inference]. The catalog sets no retry limit [Unverified]." }, "facts": { "return_windows": [ { "action": "reject (pacs.002 with status RJCT and this reason code)", "by": "SPI (the settlement system operated by the BCB), as the catalog domain table states", "deadline": "During SPI processing, inside the Pix time limit of 40 seconds on the primary message channel or 45 minutes on the secondary channel, which carries only scheduled Pix Agendado and Pix Cobrança orders (Manual de Tempos do Pix 7.0, sections 1.1 and 1.2). The pacs.002 goes out on the channel of the pacs.008 that started the payment (SPI catalog 5.12, Canais de Transmissão, pp.13 to 14). [Inference: a validation reject is sent at once; the Manual sets no separate time for it.]" } ], "applies_to": "Pix payment orders (pacs.008) and returns (devolução, pacs.004) settled in the SPI" }, "caveat": null, "related": [ "pix-reject:RC09", "pix-reject:RC10", "pix-reject:BE05", "pix-reject:AGNT" ], "basis": { "sources": "SPI message catalog 5.12.1 (spi.5.12.1.zip), PACS002.xlsx, Tabela de Domínios, entry DS27 (ISO name and definition, BCB comment, raising participant); Notas de Versão in spi.5.13.1.zip (cumulative release notes), version 5.02.1.", "confidence": "high" }, "currency": { "effective_since": "Catalog 5.02.1", "effective_note": "Added to the pacs.002 domain table in catalog 5.02.1, published 2021-03-19 (Notas de Versão in spi.5.13.1.zip (cumulative release notes)). Release note dates are publication dates; the SPI production date of that catalog was not read [Unverified]. Catalog 5.12.1 (published 2026-03-27) has been in SPI production since 2026-06-28 (BCB Comunicação eletrônica de dados page, Comunicado 44.424). Catalog 5.13.1 (SPI production 2026-10-25) keeps this code with the same comment.", "source_edition": "SPI message catalog 5.12.1 (spi.5.12.1.zip, PACS002.xlsx, pacs.002 v1.16, 2026-03-27); Manual de Tempos do Pix 7.0", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.bcb.gov.br/content/estabilidadefinanceira/cedsfn/Catalogos/spi.5.12.1.zip", "source_class": "authoritative_primary", "source_title": "SPI message catalog 5.12.1 (spi.5.12.1.zip), PACS002.xlsx Tabela de Dominios", "checked_on": "2026-09-21", "checked_by": "validator-sonnet-2026-09-21", "notes": "Confirms code DS27, ISO name UserNotYetActivated, and the BCB comment naming a participant not registered or not yet operating in the SPI, raised by the SPI." } ] }, "rail_name": "Pix Payment Rejects", "governing_authority": "Banco Central do Brasil", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "pix-reject:DT02", "id": "DT02", "rail": "pix-reject", "kind": "reason-code", "name": "Invalid Creation Date", "group": "technical", "summary": "The message's send date and time are invalid. BCB describes it as an invalid date and time of message sending. The SPI raises it.", "triggers": [ "The creation date and time of the message is malformed, not in UTC, or implausible, such as a past date [Inference from the ISO definition]" ], "actions": [ "Sending participant: fill creation times in UTC in the catalog's format (YYYY-MM-DDThh:mm:ss.sssZ)", "Sending participant: keep server clocks synchronised (Manual de Tempos do Pix 7.0, section 4.1) [Inference]" ], "retry": { "allowed": true, "rule": "Allowed once the cause is fixed. The rejected order itself is final. Resending the same operation (same EndToEndId, or same return id) within the 24-hour idempotency window only returns the earlier answer (SPI catalog 5.12, Idempotência, pp.15 to 16, and p.18), so a corrected payment goes as a new order with a new identifier [Inference]. The catalog sets no retry limit [Unverified]." }, "facts": { "return_windows": [ { "action": "reject (pacs.002 with status RJCT and this reason code)", "by": "SPI (the settlement system operated by the BCB), as the catalog domain table states", "deadline": "During SPI processing, inside the Pix time limit of 40 seconds on the primary message channel or 45 minutes on the secondary channel, which carries only scheduled Pix Agendado and Pix Cobrança orders (Manual de Tempos do Pix 7.0, sections 1.1 and 1.2). The pacs.002 goes out on the channel of the pacs.008 that started the payment (SPI catalog 5.12, Canais de Transmissão, pp.13 to 14). [Inference: a validation reject is sent at once; the Manual sets no separate time for it.]" } ], "applies_to": "Pix payment orders (pacs.008) and returns (devolução, pacs.004) settled in the SPI" }, "caveat": "All message times are in UTC, while Pix rules use Brasília time (SPI catalog 5.12, p.12 [Unverified: not re-read for this record]).", "related": [ "pix-reject:CH16", "pix-reject:FF08" ], "basis": { "sources": "SPI message catalog 5.12.1 (spi.5.12.1.zip), PACS002.xlsx, Tabela de Domínios, entry DT02 (ISO name and definition, BCB comment, raising participant); PACS002.xlsx layout, CreationDateTime rule; Manual de Tempos do Pix 7.0, section 4.1.", "confidence": "medium" }, "currency": { "effective_since": "Since the 2020 catalogs", "effective_note": "The code is in the pacs.002 domain table from the pre-launch catalogs of 2020; the cumulative release notes record no later addition. Catalog 5.12.1 (published 2026-03-27) has been in SPI production since 2026-06-28 (BCB Comunicação eletrônica de dados page, Comunicado 44.424). Catalog 5.13.1 (SPI production 2026-10-25) keeps this code with the same comment.", "source_edition": "SPI message catalog 5.12.1 (spi.5.12.1.zip, PACS002.xlsx, pacs.002 v1.16, 2026-03-27); Manual de Tempos do Pix 7.0", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.bcb.gov.br/content/estabilidadefinanceira/cedsfn/Catalogos/spi.5.12.1.zip", "source_class": "authoritative_primary", "source_title": "SPI message catalog 5.12.1 (spi.5.12.1.zip), PACS002.xlsx Tabela de Dominios; Manual de Tempos do Pix 7.0", "checked_on": "2026-09-21", "checked_by": "validator-sonnet-2026-09-21", "notes": "Confirms code DT02, ISO name InvalidCreationDate, and the BCB comment naming an invalid message send date and time, raised by the SPI. Confirms each Pix participant institution is responsible for keeping its own servers' clocks synchronised, under Manual de Tempos do Pix 7.0 section 4.1." } ] }, "rail_name": "Pix Payment Rejects", "governing_authority": "Banco Central do Brasil", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "pix-reject:DT05", "id": "DT05", "rail": "pix-reject", "kind": "reason-code", "name": "Invalid Cut Off Date", "group": "administrative", "summary": "The return comes too late. BCB describes it as a transaction past the maximum period the Pix arrangement sets for returning an instant payment. The SPI raises it.", "triggers": [ "A return (pacs.004) is started more than 90 days after the original Pix (Regulamento art. 41-A, II)" ], "actions": [ "Receiving user and participant: start ordinary returns within 90 days of the original Pix", "After that, any refund is a new Pix agreed between the users [Inference]" ], "retry": { "allowed": false, "rule": "Not for the same reason. The period has passed. Resending the same operation (same EndToEndId, or same return id) within the 24-hour idempotency window only returns the earlier answer (SPI catalog 5.12, Idempotência, pp.15 to 16, and p.18), so a corrected payment goes as a new order with a new identifier [Inference]. The catalog sets no retry limit [Unverified]." }, "facts": { "return_windows": [ { "action": "reject (pacs.002 with status RJCT and this reason code)", "by": "SPI (the settlement system operated by the BCB), as the catalog domain table states; the catalog changed the raising participant column in 5.07.1", "deadline": "During SPI processing of the return. A return (pacs.004) and the pacs.002 answering it always use the primary channel (SPI catalog 5.12, p.14). [Unverified: the Manual de Tempos do Pix 7.0 states its 40-second limit for Pix payment orders and does not name returns.]" }, { "action": "start a return (pacs.004), the limit this code enforces", "by": "Receiving user's participant, at its user's request (Regulamento arts. 40 §1 and 41)", "deadline": "Within 90 days of the date of the original Pix, except a Pix Saque and the cash part of a Pix Troco (Regulamento art. 41-A, II)" } ], "applies_to": "Pix returns (devolução, pacs.004) settled in the SPI" }, "caveat": "Pix Saque and the cash part of Pix Troco are outside the 90-day rule; the withdrawal facilitator or agent must start their return within 1 hour of finding it due (Regulamento art. 41, §§2 and 4). Returns under the special return mechanism (MED) have their own deadlines in the Manual Operacional do DICT, not read for this record.", "related": [ "pix-reject:AG13", "pix-reject:AM09", "pix-reject:SL02" ], "basis": { "sources": "SPI message catalog 5.12.1 (spi.5.12.1.zip), PACS002.xlsx, Tabela de Domínios, entry DT05 (ISO name and definition, BCB comment, raising participant); Notas de Versão in spi.5.13.1.zip (cumulative release notes), versions 1.10 (added), 5.03.1 and 5.07.1; Regulamento annexed to Resolução BCB nº 1/2020 (consolidated, version 41), arts. 40, 41 and 41-A.", "confidence": "high" }, "currency": { "effective_since": "Catalog 1.10", "effective_note": "Added to the pacs.002 domain table in catalog 1.10, published 2020-07-22, before Pix launched; raising participant column changed in 5.07.1 (published 2023-08-18). The 90-day rule in Regulamento art. 41-A was included by Resolução BCB nº 103/2021, effective 2021-11-16. Catalog 5.12.1 (published 2026-03-27) has been in SPI production since 2026-06-28 (BCB Comunicação eletrônica de dados page, Comunicado 44.424). Catalog 5.13.1 (SPI production 2026-10-25) keeps this code with the same comment.", "source_edition": "SPI message catalog 5.12.1 (spi.5.12.1.zip, PACS002.xlsx, pacs.002 v1.16, 2026-03-27); Manual de Tempos do Pix 7.0", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.bcb.gov.br/content/estabilidadefinanceira/cedsfn/Catalogos/spi.5.12.1.zip", "source_class": "authoritative_primary", "source_title": "SPI message catalog 5.12.1 (spi.5.12.1.zip), PACS002.xlsx Tabela de Dominios; Regulamento Pix anexo a Resolucao BCB no. 1/2020 consolidated version 41", "checked_on": "2026-09-21", "checked_by": "validator-sonnet-2026-09-21", "notes": "Confirms code DT05, ISO name InvalidCutOffDate, and the BCB comment naming a transaction past the maximum period the Pix arrangement sets for returning an instant payment, raised by the SPI. Confirms the 90 day return window from Regulamento art. 41-A inciso II, that an ordinary return is started by the receiving user's participant at its own initiative or the payer's request under art. 40 paragraph 1, and that a Pix Saque or the cash part of a Pix Troco return must instead be started within 1 hour under art. 41 paragraphs 2 and 4." } ] }, "rail_name": "Pix Payment Rejects", "governing_authority": "Banco Central do Brasil", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "pix-reject:DU03", "id": "DU03", "rail": "pix-reject", "kind": "reason-code", "name": "Duplicate Transaction", "group": "administrative", "summary": "The receiving participant refuses a Pix for a charge already paid another way. BCB describes it as a payment order rejected to avoid a duplicate payment when the charge was already settled through another payment arrangement, for example a boleto. The receiving participant raises it. Valid from 2026-10-25.", "triggers": [ "A charge that can be paid by Pix or by boleto was already paid by boleto, and a Pix for it arrives" ], "actions": [ "Payer: check whether the bill was already paid before paying by Pix", "Receiving participant: keep charge status current across arrangements [Inference]" ], "retry": { "allowed": false, "rule": "Not for the same reason. The charge is already paid. Resending the same operation (same EndToEndId, or same return id) within the 24-hour idempotency window only returns the earlier answer (SPI catalog 5.12, Idempotência, pp.15 to 16, and p.18), so a corrected payment goes as a new order with a new identifier [Inference]. The catalog sets no retry limit [Unverified]." }, "facts": { "return_windows": [ { "action": "reject (pacs.002 with status RJCT and this reason code)", "by": "Receiving participant (PSP of the receiving user), as the catalog domain table states", "deadline": "Inside the Pix time limit: the SPI rejects any Pix not settled within 40 seconds on the primary message channel or 45 minutes on the secondary channel, which carries only scheduled Pix Agendado and Pix Cobrança orders (Manual de Tempos do Pix 7.0, sections 1.1 and 1.2). On the primary channel the receiving side's answer (t3' minus t2) has a service level of 1.4 seconds at the 50th percentile and 2.3 seconds at the 95th (section 4.1.1.2)." } ], "applies_to": "Pix payment orders (pacs.008) settled in the SPI" }, "caveat": "Not valid before 2026-10-25. DUPL covers two Pix with the same receiver reconciliation id.", "related": [ "pix-reject:DUPL", "pix-reject:BE17", "pix-reject:INDT" ], "basis": { "sources": "SPI message catalog 5.13.1 (spi.5.13.1.zip), PACS002.xlsx, Tabela de Domínios, entry DU03 (ISO name and definition, BCB comment, raising participant); Notas de Versão in spi.5.13.1.zip (cumulative release notes), version 5.13.1; BCB Comunicação eletrônica de dados page (SPI production date).", "confidence": "high" }, "currency": { "effective_since": "2026-10-25", "effective_note": "Added in catalog 5.13.1; in force 2026-10-25; pending at snapshot 2026-09-17", "source_edition": "SPI message catalog 5.13.1 (spi.5.13.1.zip, PACS002.xlsx, pacs.002 v1.17, 2026-07-24); Manual de Tempos do Pix 7.0", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.bcb.gov.br/content/estabilidadefinanceira/cedsfn/Catalogos/spi.5.13.1.zip", "source_class": "authoritative_primary", "source_title": "SPI message catalog 5.13.1 (spi.5.13.1.zip), PACS002.xlsx Tabela de Dominios; Manual de Tempos do Pix 7.0", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms code DU03 is new in catalog 5.13.1 PACS002 v1.17, with ISO name DuplicateTransaction and a BCB comment describing a Pix rejected to avoid a duplicate payment already settled by another arrangement such as a boleto, raised by the receiving participant. Confirms the SPI production date 2026-10-25 against the comunicacaodados page listing for catalog 5.13. Confirms the reject deadline." } ] }, "rail_name": "Pix Payment Rejects", "governing_authority": "Banco Central do Brasil", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "window", "label": "the payment date", "needs": "the date of the payment you are asking about", "detail": "This code takes effect 2026-10-25, after the corpus snapshot 2026-09-20, so it does not state the rule in force at that snapshot.", "from": "currency.effective_since" } ] }, { "uid": "pix-reject:DUPL", "id": "DUPL", "rail": "pix-reject", "kind": "reason-code", "name": "Duplicate Payment", "group": "administrative", "summary": "The payment repeats one already made. BCB describes it as a duplicate payment where orders share the same receiver reconciliation id (IdConciliacaoDoRecebedor) for the same receiving user; two charges may share an id only if their receivers differ. The receiving participant raises it.", "triggers": [ "A second payment arrives with the same receiver reconciliation id for the same receiving user, for example a charge paid twice [Inference]" ], "actions": [ "Payer: check whether the charge was already paid before paying again", "Receiving participant: keep reconciliation ids unique per receiving user" ], "retry": { "allowed": false, "rule": "Not for the same reason. The charge is already paid. Resending the same operation (same EndToEndId, or same return id) within the 24-hour idempotency window only returns the earlier answer (SPI catalog 5.12, Idempotência, pp.15 to 16, and p.18), so a corrected payment goes as a new order with a new identifier [Inference]. The catalog sets no retry limit [Unverified]." }, "facts": { "return_windows": [ { "action": "reject (pacs.002 with status RJCT and this reason code)", "by": "Receiving participant (PSP of the receiving user), as the catalog domain table states", "deadline": "Inside the Pix time limit: the SPI rejects any Pix not settled within 40 seconds on the primary message channel or 45 minutes on the secondary channel, which carries only scheduled Pix Agendado and Pix Cobrança orders (Manual de Tempos do Pix 7.0, sections 1.1 and 1.2). On the primary channel the receiving side's answer (t3' minus t2) has a service level of 1.4 seconds at the 50th percentile and 2.3 seconds at the 95th (section 4.1.1.2)." } ], "applies_to": "Pix payment orders (pacs.008) settled in the SPI" }, "caveat": "DUPL here is about the receiver's reconciliation id, not an ISO-style duplicate message. From 2026-10-25, DU03 covers a charge already paid through another arrangement such as a boleto.", "related": [ "pix-reject:DU03", "pix-reject:BE15", "pix-reject:INDT" ], "basis": { "sources": "SPI message catalog 5.12.1 (spi.5.12.1.zip), PACS002.xlsx, Tabela de Domínios, entry DUPL (ISO name and definition, BCB comment, raising participant); Notas de Versão in spi.5.13.1.zip (cumulative release notes), version 5.09.1.", "confidence": "high" }, "currency": { "effective_since": "Catalog 5.09.1", "effective_note": "Added to the pacs.002 domain table in catalog 5.09.1, published 2024-08-30 (Notas de Versão in spi.5.13.1.zip (cumulative release notes)). Release note dates are publication dates; the SPI production date of that catalog was not read [Unverified]. Catalog 5.12.1 (published 2026-03-27) has been in SPI production since 2026-06-28 (BCB Comunicação eletrônica de dados page, Comunicado 44.424). Catalog 5.13.1 (SPI production 2026-10-25) keeps this code with the same comment.", "source_edition": "SPI message catalog 5.12.1 (spi.5.12.1.zip, PACS002.xlsx, pacs.002 v1.16, 2026-03-27); Manual de Tempos do Pix 7.0", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.bcb.gov.br/content/estabilidadefinanceira/cedsfn/Catalogos/spi.5.12.1.zip", "source_class": "authoritative_primary", "source_title": "SPI message catalog 5.12.1 (spi.5.12.1.zip), PACS002.xlsx Tabela de Dominios; Manual de Tempos do Pix 7.0", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms code DUPL, ISO name DuplicatePayment, and the BCB comment describing matching receiver reconciliation ids for the same receiving user, raised by the receiving participant. Confirms the reject deadline." } ] }, "rail_name": "Pix Payment Rejects", "governing_authority": "Banco Central do Brasil", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "pix-reject:ED05", "id": "ED05", "rail": "pix-reject", "kind": "reason-code", "name": "Settlement Failed", "group": "technical", "summary": "A generic processing error stopped the payment. BCB describes it as an error in processing the instant payment (generic error). The catalog lists both the SPI and the receiving participant as raising it.", "triggers": [ "A processing failure in the SPI or at the receiving participant that no specific code covers [Inference]" ], "actions": [ "Payer's participant: tell the payer the Pix failed and may be sent again [Inference]", "Sending participant: check the free-text detail, if any, and contact the other side if the error repeats [Inference]" ], "retry": { "allowed": true, "rule": "Allowed once the cause is fixed. The rejected order itself is final. Resending the same operation (same EndToEndId, or same return id) within the 24-hour idempotency window only returns the earlier answer (SPI catalog 5.12, Idempotência, pp.15 to 16, and p.18), so a corrected payment goes as a new order with a new identifier [Inference]. The catalog sets no retry limit [Unverified]." }, "facts": { "return_windows": [ { "action": "reject (pacs.002 with status RJCT and this reason code)", "by": "SPI (the settlement system operated by the BCB), as the catalog domain table states", "deadline": "During SPI processing, inside the Pix time limit of 40 seconds on the primary message channel or 45 minutes on the secondary channel, which carries only scheduled Pix Agendado and Pix Cobrança orders (Manual de Tempos do Pix 7.0, sections 1.1 and 1.2). The pacs.002 goes out on the channel of the pacs.008 that started the payment (SPI catalog 5.12, Canais de Transmissão, pp.13 to 14). [Inference: a validation reject is sent at once; the Manual sets no separate time for it.]" }, { "action": "reject (pacs.002 with status RJCT and this reason code)", "by": "Receiving participant (PSP of the receiving user), as the catalog domain table states", "deadline": "Inside the Pix time limit: the SPI rejects any Pix not settled within 40 seconds on the primary message channel or 45 minutes on the secondary channel, which carries only scheduled Pix Agendado and Pix Cobrança orders (Manual de Tempos do Pix 7.0, sections 1.1 and 1.2). On the primary channel the receiving side's answer (t3' minus t2) has a service level of 1.4 seconds at the 50th percentile and 2.3 seconds at the 95th (section 4.1.1.2)." } ], "applies_to": "Pix payment orders (pacs.008) and returns (devolução, pacs.004) settled in the SPI" }, "caveat": "Non-terminal processing errors go by admi.002 and do not reject the operation (SPI catalog 5.12, p.17).", "related": [ "pix-reject:AB09", "pix-reject:AB03", "pix-reject:DS04" ], "basis": { "sources": "SPI message catalog 5.12.1 (spi.5.12.1.zip), PACS002.xlsx, Tabela de Domínios, entry ED05 (ISO name and definition, BCB comment, raising participant); Catálogo de Serviços do SFN Volume VI (SPI catalog) 5.12, p.17; Manual de Tempos do Pix 7.0, sections 1.1, 1.2 and 4.1.1.2.", "confidence": "medium" }, "currency": { "effective_since": "Since the 2020 catalogs", "effective_note": "The code is in the pacs.002 domain table from the pre-launch catalogs of 2020; the cumulative release notes record no later addition. Catalog 5.12.1 (published 2026-03-27) has been in SPI production since 2026-06-28 (BCB Comunicação eletrônica de dados page, Comunicado 44.424). Catalog 5.13.1 (SPI production 2026-10-25) keeps this code with the same comment.", "source_edition": "SPI message catalog 5.12.1 (spi.5.12.1.zip, PACS002.xlsx, pacs.002 v1.16, 2026-03-27); Manual de Tempos do Pix 7.0", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.bcb.gov.br/content/estabilidadefinanceira/cedsfn/Catalogos/spi.5.12.1.zip", "source_class": "authoritative_primary", "source_title": "SPI message catalog 5.12.1 (spi.5.12.1.zip), PACS002.xlsx Tabela de Dominios; Manual de Tempos do Pix 7.0; Catalogo de Servicos do SFN Volume VI 5.12", "checked_on": "2026-09-21", "checked_by": "validator-sonnet-2026-09-21", "notes": "Confirms code ED05, ISO name SettlementFailed, and the BCB comment naming a generic instant payment processing error, raised by either the SPI or the receiving participant as the table states. Confirms the section 4.1.1.2 service level figures of 1.4 seconds at the 50th percentile and 2.3 seconds at the 95th for the receiving side of Pix authorization, and that non terminal processing errors are reported with admi.002 rather than a pacs.002 reject." } ] }, "rail_name": "Pix Payment Rejects", "governing_authority": "Banco Central do Brasil", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "pix-reject:FF07", "id": "FF07", "rail": "pix-reject", "kind": "reason-code", "name": "Invalid Purpose", "group": "technical", "summary": "The payment's purpose does not match its structured data. BCB describes it as an inconsistency between the transaction purpose and the filling of the Structured (Strd) elements. The SPI raises it.", "triggers": [ "The purpose code in the pacs.008 calls for structured data that is missing, or the structured data does not fit the purpose [Inference]" ], "actions": [ "Payer's participant: fill the structured block as the pacs.008 rules require for the chosen purpose" ], "retry": { "allowed": true, "rule": "Allowed once the cause is fixed. The rejected order itself is final. Resending the same operation (same EndToEndId, or same return id) within the 24-hour idempotency window only returns the earlier answer (SPI catalog 5.12, Idempotência, pp.15 to 16, and p.18), so a corrected payment goes as a new order with a new identifier [Inference]. The catalog sets no retry limit [Unverified]." }, "facts": { "return_windows": [ { "action": "reject (pacs.002 with status RJCT and this reason code)", "by": "SPI (the settlement system operated by the BCB), as the catalog domain table states", "deadline": "During SPI processing, inside the Pix time limit of 40 seconds on the primary message channel or 45 minutes on the secondary channel, which carries only scheduled Pix Agendado and Pix Cobrança orders (Manual de Tempos do Pix 7.0, sections 1.1 and 1.2). The pacs.002 goes out on the channel of the pacs.008 that started the payment (SPI catalog 5.12, Canais de Transmissão, pp.13 to 14). [Inference: a validation reject is sent at once; the Manual sets no separate time for it.]" } ], "applies_to": "Pix payment orders (pacs.008) settled in the SPI" }, "caveat": "The pacs.008 purpose codes and their rules (IPAY, IPRT, GSCB, OTHR, REFU) are in PACS008.xlsx, not read for this record [Unverified].", "related": [ "pix-reject:MD01", "pix-reject:AM12", "pix-reject:CH16" ], "basis": { "sources": "SPI message catalog 5.12.1 (spi.5.12.1.zip), PACS002.xlsx, Tabela de Domínios, entry FF07 (ISO name and definition, BCB comment, raising participant); Notas de Versão in spi.5.13.1.zip (cumulative release notes), version 5.02.1.", "confidence": "medium" }, "currency": { "effective_since": "Catalog 5.02.1", "effective_note": "Added to the pacs.002 domain table in catalog 5.02.1, published 2021-03-19 (Notas de Versão in spi.5.13.1.zip (cumulative release notes)). Release note dates are publication dates; the SPI production date of that catalog was not read [Unverified]. Catalog 5.12.1 (published 2026-03-27) has been in SPI production since 2026-06-28 (BCB Comunicação eletrônica de dados page, Comunicado 44.424). Catalog 5.13.1 (SPI production 2026-10-25) keeps this code with the same comment.", "source_edition": "SPI message catalog 5.12.1 (spi.5.12.1.zip, PACS002.xlsx, pacs.002 v1.16, 2026-03-27); Manual de Tempos do Pix 7.0", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.bcb.gov.br/content/estabilidadefinanceira/cedsfn/Catalogos/spi.5.12.1.zip", "source_class": "authoritative_primary", "source_title": "SPI message catalog 5.12.1 (spi.5.12.1.zip), PACS002.xlsx Tabela de Dominios", "checked_on": "2026-09-21", "checked_by": "validator-sonnet-2026-09-21", "notes": "Confirms code FF07, ISO name InvalidPurpose, and the BCB comment naming an inconsistency between the transaction purpose and the filling of the Structured element block, raised by the SPI." } ] }, "rail_name": "Pix Payment Rejects", "governing_authority": "Banco Central do Brasil", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "pix-reject:FF08", "id": "FF08", "rail": "pix-reject", "kind": "reason-code", "name": "Invalid End To End Id", "group": "technical", "summary": "The operation id is badly formed. BCB describes it as a malformed operation identifier. The SPI raises it.", "triggers": [ "The EndToEndId (or return id) does not follow the catalog's format" ], "actions": [ "Sending participant: build identifiers in the format the message spreadsheet sets, including the alphanumeric CNPJ changes of 5.10.1 [Inference]" ], "retry": { "allowed": true, "rule": "Allowed once the cause is fixed. The rejected order itself is final. Resending the same operation (same EndToEndId, or same return id) within the 24-hour idempotency window only returns the earlier answer (SPI catalog 5.12, Idempotência, pp.15 to 16, and p.18), so a corrected payment goes as a new order with a new identifier [Inference]. The catalog sets no retry limit [Unverified]." }, "facts": { "return_windows": [ { "action": "reject (pacs.002 with status RJCT and this reason code)", "by": "SPI (the settlement system operated by the BCB), as the catalog domain table states", "deadline": "During SPI processing, inside the Pix time limit of 40 seconds on the primary message channel or 45 minutes on the secondary channel, which carries only scheduled Pix Agendado and Pix Cobrança orders (Manual de Tempos do Pix 7.0, sections 1.1 and 1.2). The pacs.002 goes out on the channel of the pacs.008 that started the payment (SPI catalog 5.12, Canais de Transmissão, pp.13 to 14). [Inference: a validation reject is sent at once; the Manual sets no separate time for it.]" } ], "applies_to": "Pix payment orders (pacs.008) and returns (devolução, pacs.004) settled in the SPI" }, "caveat": "The EndToEndId is also the idempotency key for pacs.008 (SPI catalog 5.12, p.16).", "related": [ "pix-reject:CH16", "pix-reject:DT02" ], "basis": { "sources": "SPI message catalog 5.12.1 (spi.5.12.1.zip), PACS002.xlsx, Tabela de Domínios, entry FF08 (ISO name and definition, BCB comment, raising participant); Catálogo de Serviços do SFN Volume VI (SPI catalog) 5.12, Idempotência (p.16); Notas de Versão in spi.5.13.1.zip (cumulative release notes), version 5.10.1.", "confidence": "high" }, "currency": { "effective_since": "Since the 2020 catalogs", "effective_note": "The code is in the pacs.002 domain table from the pre-launch catalogs of 2020; the cumulative release notes record no later addition. Catalog 5.12.1 (published 2026-03-27) has been in SPI production since 2026-06-28 (BCB Comunicação eletrônica de dados page, Comunicado 44.424). Catalog 5.13.1 (SPI production 2026-10-25) keeps this code with the same comment.", "source_edition": "SPI message catalog 5.12.1 (spi.5.12.1.zip, PACS002.xlsx, pacs.002 v1.16, 2026-03-27); Manual de Tempos do Pix 7.0", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.bcb.gov.br/content/estabilidadefinanceira/cedsfn/Catalogos/spi.5.12.1.zip", "source_class": "authoritative_primary", "source_title": "SPI message catalog 5.12.1 (spi.5.12.1.zip), PACS002.xlsx Tabela de Dominios; Catalogo de Servicos do SFN Volume VI 5.12", "checked_on": "2026-09-21", "checked_by": "validator-sonnet-2026-09-21", "notes": "Confirms code FF08, ISO name InvalidEndToEndId, and the BCB comment naming a malformed operation identifier, raised by the SPI. Confirms the EndToEndId is the idempotency key used for a pacs.008 operation." } ] }, "rail_name": "Pix Payment Rejects", "governing_authority": "Banco Central do Brasil", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "pix-reject:FRAD", "id": "FRAD", "rail": "pix-reject", "kind": "reason-code", "name": "Fraudulent Origin", "group": "authorization", "summary": "The receiving participant refuses the payment because it has well-founded suspicion of fraud. BCB describes it as a payment order rejected for well-founded suspicion of fraud (fundada suspeita de fraude). The receiving participant raises it. On Pix this is a reject, not a recall or return request.", "triggers": [ "The receiving participant's fraud assessment finds well-founded suspicion of fraud before the credit (Regulamento art. 39, I)" ], "actions": [ "Receiving participant: reject when suspicion is well founded, using at least the criteria the BCB publishes (Regulamento arts. 39, I and 39-C)", "Receiving participant: for suspicion that is not well founded, credit the funds with a precautionary hold of up to 72 hours instead (art. 39-B)", "Payer's participant: tell the payer the Pix was refused [Inference]" ], "retry": { "allowed": false, "rule": "Not for the same reason. A fraud reject should not be worked around by sending again. Resending the same operation (same EndToEndId, or same return id) within the 24-hour idempotency window only returns the earlier answer (SPI catalog 5.12, Idempotência, pp.15 to 16, and p.18), so a corrected payment goes as a new order with a new identifier [Inference]. The catalog sets no retry limit [Unverified]." }, "facts": { "return_windows": [ { "action": "reject (pacs.002 with status RJCT and this reason code)", "by": "Receiving participant (PSP of the receiving user), as the catalog domain table states", "deadline": "Inside the Pix time limit: the SPI rejects any Pix not settled within 40 seconds on the primary message channel or 45 minutes on the secondary channel, which carries only scheduled Pix Agendado and Pix Cobrança orders (Manual de Tempos do Pix 7.0, sections 1.1 and 1.2). On the primary channel the receiving side's answer (t3' minus t2) has a service level of 1.4 seconds at the 50th percentile and 2.3 seconds at the 95th (section 4.1.1.2). For an order the payer's participant held as suspected fraud (up to 30 minutes from 8h to 20h Brasília time on business days, 60 minutes otherwise), the 40-second clock starts when the SPI receives the order (sections 1.1 and 2)." } ], "applies_to": "Pix payment orders (pacs.008) settled in the SPI" }, "caveat": "The ISO definition describes a cancellation for fraud; on Pix the receiving participant uses it to reject. The payer's participant must also reject on well-founded suspicion (Regulamento art. 38, II), before the order reaches the SPI. Fraud refunds after settlement run through the special return mechanism (MED) in the DICT, not through this code.", "related": [ "pix-reject:RR04", "pix-reject:DS04", "pix-reject:AC06" ], "basis": { "sources": "SPI message catalog 5.12.1 (spi.5.12.1.zip), PACS002.xlsx, Tabela de Domínios, entry FRAD (ISO name and definition, BCB comment, raising participant); Notas de Versão in spi.5.13.1.zip (cumulative release notes), version 5.09.1; Regulamento annexed to Resolução BCB nº 1/2020 (consolidated, version 41), arts. 38, 39, 39-B and 39-C; Manual de Tempos do Pix 7.0, sections 1.1, 2 and 4.1.1.2.", "confidence": "high" }, "currency": { "effective_since": "Catalog 5.09.1", "effective_note": "Added to the pacs.002 domain table in catalog 5.09.1, published 2024-08-30 (Notas de Versão in spi.5.13.1.zip (cumulative release notes)). Release note dates are publication dates; the SPI production date of that catalog was not read [Unverified]. Catalog 5.12.1 (published 2026-03-27) has been in SPI production since 2026-06-28 (BCB Comunicação eletrônica de dados page, Comunicado 44.424). Catalog 5.13.1 (SPI production 2026-10-25) keeps this code with the same comment.", "source_edition": "SPI message catalog 5.12.1 (spi.5.12.1.zip, PACS002.xlsx, pacs.002 v1.16, 2026-03-27); Manual de Tempos do Pix 7.0", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.bcb.gov.br/content/estabilidadefinanceira/cedsfn/Catalogos/spi.5.12.1.zip", "source_class": "authoritative_primary", "source_title": "SPI message catalog 5.12.1 (spi.5.12.1.zip), PACS002.xlsx Tabela de Dominios; Manual de Tempos do Pix 7.0", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms code FRAD, ISO name FraudulentOrigin, and the BCB comment describing a reject for well-founded suspicion of fraud, raised by the receiving participant. Confirms the reject deadline." } ] }, "rail_name": "Pix Payment Rejects", "governing_authority": "Banco Central do Brasil", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "pix-reject:INDT", "id": "INDT", "rail": "pix-reject", "kind": "reason-code", "name": "Invalid Details", "group": "administrative", "summary": "The payment does not match the charge or instruction it came from. BCB describes it as message content incompatible with the parameters of the charge (QR code) or of the payment instruction (pain.013) that originated it. The receiving participant raises it.", "triggers": [ "Amount, due date or other data in the pacs.008 differ from the QR code charge [Inference: the catalog does not list fields]", "A Pix Automático payment differs from the pain.013 instruction behind it" ], "actions": [ "Payer's participant: carry the charge's or instruction's parameters into the payment unchanged", "Receiving participant: reject a Pix Automático payment that does not match its charge (Regulamento art. 39, IV); for Pix Cobrança the reject is optional (art. 39-A)" ], "retry": { "allowed": true, "rule": "Allowed once the cause is fixed. The rejected order itself is final. Resending the same operation (same EndToEndId, or same return id) within the 24-hour idempotency window only returns the earlier answer (SPI catalog 5.12, Idempotência, pp.15 to 16, and p.18), so a corrected payment goes as a new order with a new identifier [Inference]. The catalog sets no retry limit [Unverified]." }, "facts": { "return_windows": [ { "action": "reject (pacs.002 with status RJCT and this reason code)", "by": "Receiving participant (PSP of the receiving user), as the catalog domain table states", "deadline": "Inside the Pix time limit: the SPI rejects any Pix not settled within 40 seconds on the primary message channel or 45 minutes on the secondary channel, which carries only scheduled Pix Agendado and Pix Cobrança orders (Manual de Tempos do Pix 7.0, sections 1.1 and 1.2). On the primary channel the receiving side's answer (t3' minus t2) has a service level of 1.4 seconds at the 50th percentile and 2.3 seconds at the 95th (section 4.1.1.2)." } ], "applies_to": "Pix payment orders (pacs.008) settled in the SPI" }, "caveat": "The Pix Automático reject duty does not apply when the payment was started through a payment initiation service (Regulamento art. 39, IV, as amended by Resolução BCB nº 425/2024) [Inference: the catalog does not say whether INDT is then used].", "related": [ "pix-reject:BE17", "pix-reject:UPAY", "pix-reject:CN01", "pix-reject:BE15" ], "basis": { "sources": "SPI message catalog 5.12.1 (spi.5.12.1.zip), PACS002.xlsx, Tabela de Domínios, entry INDT (ISO name and definition, BCB comment, raising participant); Notas de Versão in spi.5.13.1.zip (cumulative release notes), version 5.11.1; Regulamento annexed to Resolução BCB nº 1/2020 (consolidated, version 41), arts. 39, IV and 39-A.", "confidence": "medium" }, "currency": { "effective_since": "Catalog 5.11.1", "effective_note": "Added to the pacs.002 domain table in catalog 5.11.1, published 2025-09-12 (Notas de Versão in spi.5.13.1.zip (cumulative release notes)). Release note dates are publication dates; the SPI production date of that catalog was not read [Unverified]. Catalog 5.12.1 (published 2026-03-27) has been in SPI production since 2026-06-28 (BCB Comunicação eletrônica de dados page, Comunicado 44.424). Catalog 5.13.1 (SPI production 2026-10-25) keeps this code with the same comment.", "source_edition": "SPI message catalog 5.12.1 (spi.5.12.1.zip, PACS002.xlsx, pacs.002 v1.16, 2026-03-27); Manual de Tempos do Pix 7.0", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.bcb.gov.br/content/estabilidadefinanceira/cedsfn/Catalogos/spi.5.12.1.zip", "source_class": "authoritative_primary", "source_title": "SPI message catalog 5.12.1 (spi.5.12.1.zip), PACS002.xlsx Tabela de Dominios; Manual de Tempos do Pix 7.0", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms code INDT, ISO name InvalidDetails, and the BCB comment describing content that does not match the QR code or pain.013 instruction, raised by the receiving participant. Confirms the reject deadline. Does not address the payment initiation service exception, matching the caveat." } ] }, "rail_name": "Pix Payment Rejects", "governing_authority": "Banco Central do Brasil", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "pix-reject:MD01", "id": "MD01", "rail": "pix-reject", "kind": "reason-code", "name": "No Mandate", "group": "administrative", "summary": "The withdrawal facilitator named in the payment does not exist. BCB describes it as a nonexistent ISPB for the Pix Saque or Pix Troco facilitator. The SPI raises it. It has nothing to do with a mandate.", "triggers": [ "A Pix Saque or Pix Troco order names a facilitator ISPB the SPI does not know" ], "actions": [ "Payer's participant: check the facilitator ISPB taken from the withdrawal QR code or point of service [Inference]" ], "retry": { "allowed": true, "rule": "Allowed once the cause is fixed. The rejected order itself is final. Resending the same operation (same EndToEndId, or same return id) within the 24-hour idempotency window only returns the earlier answer (SPI catalog 5.12, Idempotência, pp.15 to 16, and p.18), so a corrected payment goes as a new order with a new identifier [Inference]. The catalog sets no retry limit [Unverified]." }, "facts": { "return_windows": [ { "action": "reject (pacs.002 with status RJCT and this reason code)", "by": "SPI (the settlement system operated by the BCB), as the catalog domain table states", "deadline": "During SPI processing, inside the Pix time limit of 40 seconds on the primary message channel or 45 minutes on the secondary channel, which carries only scheduled Pix Agendado and Pix Cobrança orders (Manual de Tempos do Pix 7.0, sections 1.1 and 1.2). The pacs.002 goes out on the channel of the pacs.008 that started the payment (SPI catalog 5.12, Canais de Transmissão, pp.13 to 14). [Inference: a validation reject is sent at once; the Manual sets no separate time for it.]" } ], "applies_to": "Pix payment orders (pacs.008) settled in the SPI, Pix Saque and Pix Troco" }, "caveat": "Despite the ISO name, this is not a missing mandate. The receiving participant must separately reject when the withdrawal agent is not enabled (Regulamento art. 39, III); the catalog read does not give that case a code.", "related": [ "pix-reject:SL02", "pix-reject:AM12", "pix-reject:FF07" ], "basis": { "sources": "SPI message catalog 5.12.1 (spi.5.12.1.zip), PACS002.xlsx, Tabela de Domínios, entry MD01 (ISO name and definition, BCB comment, raising participant); Notas de Versão in spi.5.13.1.zip (cumulative release notes), versions 5.03.2 and 5.03.3; Regulamento annexed to Resolução BCB nº 1/2020 (consolidated, version 41), art. 39, III.", "confidence": "high" }, "currency": { "effective_since": "Catalog 5.03.2", "effective_note": "Added in catalog 5.03.2, published 2021-11-19; comment changed from provider to facilitator in 5.03.3 (published 2022-02-07) (release notes). Release note dates are publication dates; the SPI production date of that catalog was not read [Unverified]. Catalog 5.12.1 (published 2026-03-27) has been in SPI production since 2026-06-28 (BCB Comunicação eletrônica de dados page, Comunicado 44.424). Catalog 5.13.1 (SPI production 2026-10-25) keeps this code with the same comment.", "source_edition": "SPI message catalog 5.12.1 (spi.5.12.1.zip, PACS002.xlsx, pacs.002 v1.16, 2026-03-27); Manual de Tempos do Pix 7.0", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.bcb.gov.br/content/estabilidadefinanceira/cedsfn/Catalogos/spi.5.12.1.zip", "source_class": "authoritative_primary", "source_title": "SPI message catalog 5.12.1 (spi.5.12.1.zip), PACS002.xlsx Tabela de Dominios; Regulamento Pix anexo a Resolucao BCB no. 1/2020 consolidated version 41", "checked_on": "2026-09-21", "checked_by": "validator-sonnet-2026-09-21", "notes": "Confirms code MD01, ISO name NoMandate, and the BCB comment naming a nonexistent ISPB for the Pix Saque or Pix Troco facilitator, raised by the SPI. Confirms the receiving participant must separately reject a Pix Saque or Pix Troco where the withdrawal agent has not been enabled, under Regulamento art. 39 inciso III." } ] }, "rail_name": "Pix Payment Rejects", "governing_authority": "Banco Central do Brasil", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "pix-reject:RC09", "id": "RC09", "rail": "pix-reject", "kind": "reason-code", "name": "Invalid Debtor Clearing System Member Identifier", "group": "network", "summary": "The payer's participant id is wrong. BCB describes it as an invalid or nonexistent ISPB for the payer's participant. The SPI raises it.", "triggers": [ "The payer's participant ISPB is malformed or not known to the SPI" ], "actions": [ "Sending participant: fill the payer's participant ISPB (8 characters) correctly" ], "retry": { "allowed": true, "rule": "Allowed once the cause is fixed. The rejected order itself is final. Resending the same operation (same EndToEndId, or same return id) within the 24-hour idempotency window only returns the earlier answer (SPI catalog 5.12, Idempotência, pp.15 to 16, and p.18), so a corrected payment goes as a new order with a new identifier [Inference]. The catalog sets no retry limit [Unverified]." }, "facts": { "return_windows": [ { "action": "reject (pacs.002 with status RJCT and this reason code)", "by": "SPI (the settlement system operated by the BCB), as the catalog domain table states", "deadline": "During SPI processing, inside the Pix time limit of 40 seconds on the primary message channel or 45 minutes on the secondary channel, which carries only scheduled Pix Agendado and Pix Cobrança orders (Manual de Tempos do Pix 7.0, sections 1.1 and 1.2). The pacs.002 goes out on the channel of the pacs.008 that started the payment (SPI catalog 5.12, Canais de Transmissão, pp.13 to 14). [Inference: a validation reject is sent at once; the Manual sets no separate time for it.]" } ], "applies_to": "Pix payment orders (pacs.008) and returns (devolução, pacs.004) settled in the SPI" }, "caveat": "Pix identifies participants by ISPB, not by routing numbers.", "related": [ "pix-reject:RC10", "pix-reject:DS27", "pix-reject:AGNT" ], "basis": { "sources": "SPI message catalog 5.12.1 (spi.5.12.1.zip), PACS002.xlsx, Tabela de Domínios, entry RC09 (ISO name and definition, BCB comment, raising participant).", "confidence": "high" }, "currency": { "effective_since": "Since the 2020 catalogs", "effective_note": "The code is in the pacs.002 domain table from the pre-launch catalogs of 2020; the cumulative release notes record no later addition. Catalog 5.12.1 (published 2026-03-27) has been in SPI production since 2026-06-28 (BCB Comunicação eletrônica de dados page, Comunicado 44.424). Catalog 5.13.1 (SPI production 2026-10-25) keeps this code with the same comment.", "source_edition": "SPI message catalog 5.12.1 (spi.5.12.1.zip, PACS002.xlsx, pacs.002 v1.16, 2026-03-27); Manual de Tempos do Pix 7.0", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.bcb.gov.br/content/estabilidadefinanceira/cedsfn/Catalogos/spi.5.12.1.zip", "source_class": "authoritative_primary", "source_title": "SPI message catalog 5.12.1 (spi.5.12.1.zip), PACS002.xlsx Tabela de Dominios", "checked_on": "2026-09-21", "checked_by": "validator-sonnet-2026-09-21", "notes": "Confirms code RC09, ISO name InvalidDebtorClearingSystemMemberIdentifier, and the BCB comment naming an invalid or nonexistent ISPB for the payer participant, raised by the SPI." } ] }, "rail_name": "Pix Payment Rejects", "governing_authority": "Banco Central do Brasil", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "pix-reject:RC10", "id": "RC10", "rail": "pix-reject", "kind": "reason-code", "name": "Invalid Creditor Clearing System Member Identifier", "group": "network", "summary": "The receiving participant's id is wrong. BCB describes it as an invalid or nonexistent ISPB for the receiving user's participant. The SPI raises it.", "triggers": [ "The receiving participant ISPB is malformed or not known to the SPI", "A stale key lookup gives an ISPB that no longer exists [Inference]" ], "actions": [ "Payer's participant: check the receiving participant ISPB, for example by a fresh DICT key lookup [Inference]" ], "retry": { "allowed": true, "rule": "Allowed once the cause is fixed. The rejected order itself is final. Resending the same operation (same EndToEndId, or same return id) within the 24-hour idempotency window only returns the earlier answer (SPI catalog 5.12, Idempotência, pp.15 to 16, and p.18), so a corrected payment goes as a new order with a new identifier [Inference]. The catalog sets no retry limit [Unverified]." }, "facts": { "return_windows": [ { "action": "reject (pacs.002 with status RJCT and this reason code)", "by": "SPI (the settlement system operated by the BCB), as the catalog domain table states", "deadline": "During SPI processing, inside the Pix time limit of 40 seconds on the primary message channel or 45 minutes on the secondary channel, which carries only scheduled Pix Agendado and Pix Cobrança orders (Manual de Tempos do Pix 7.0, sections 1.1 and 1.2). The pacs.002 goes out on the channel of the pacs.008 that started the payment (SPI catalog 5.12, Canais de Transmissão, pp.13 to 14). [Inference: a validation reject is sent at once; the Manual sets no separate time for it.]" } ], "applies_to": "Pix payment orders (pacs.008) and returns (devolução, pacs.004) settled in the SPI" }, "caveat": null, "related": [ "pix-reject:RC09", "pix-reject:DS27" ], "basis": { "sources": "SPI message catalog 5.12.1 (spi.5.12.1.zip), PACS002.xlsx, Tabela de Domínios, entry RC10 (ISO name and definition, BCB comment, raising participant).", "confidence": "high" }, "currency": { "effective_since": "Since the 2020 catalogs", "effective_note": "The code is in the pacs.002 domain table from the pre-launch catalogs of 2020; the cumulative release notes record no later addition. Catalog 5.12.1 (published 2026-03-27) has been in SPI production since 2026-06-28 (BCB Comunicação eletrônica de dados page, Comunicado 44.424). Catalog 5.13.1 (SPI production 2026-10-25) keeps this code with the same comment.", "source_edition": "SPI message catalog 5.12.1 (spi.5.12.1.zip, PACS002.xlsx, pacs.002 v1.16, 2026-03-27); Manual de Tempos do Pix 7.0", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.bcb.gov.br/content/estabilidadefinanceira/cedsfn/Catalogos/spi.5.12.1.zip", "source_class": "authoritative_primary", "source_title": "SPI message catalog 5.12.1 (spi.5.12.1.zip), PACS002.xlsx Tabela de Dominios", "checked_on": "2026-09-21", "checked_by": "validator-sonnet-2026-09-21", "notes": "Confirms code RC10, ISO name InvalidCreditorClearingSystemMemberIdentifier, and the BCB comment naming an invalid or nonexistent ISPB for the receiving participant, raised by the SPI." } ] }, "rail_name": "Pix Payment Rejects", "governing_authority": "Banco Central do Brasil", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "pix-reject:RR04", "id": "RR04", "rail": "pix-reject", "kind": "reason-code", "name": "Regulatory Reason", "group": "administrative", "summary": "The payment is refused because the payer is under UN sanctions. BCB describes it as a payment order whose payer is sanctioned by a UN Security Council resolution; when the receiver is the sanctioned party, the order must not be rejected. The catalog names the receiving participant as raising it.", "triggers": [ "The payer is a person or entity sanctioned by a UN Security Council resolution" ], "actions": [ "Participant: screen payers against UN Security Council sanctions as Lei 13.810/2019 and BCB rules require (Regulamento art. 38, V)", "Receiving participant: do not reject when the sanctioned party is the receiver, as the catalog states; handle that case under the sanctions rules instead [Inference]" ], "retry": { "allowed": false, "rule": "Not for the same reason. The sanction applies to the payer. Resending the same operation (same EndToEndId, or same return id) within the 24-hour idempotency window only returns the earlier answer (SPI catalog 5.12, Idempotência, pp.15 to 16, and p.18), so a corrected payment goes as a new order with a new identifier [Inference]. The catalog sets no retry limit [Unverified]." }, "facts": { "return_windows": [ { "action": "reject (pacs.002 with status RJCT and this reason code)", "by": "Receiving participant (PSP of the receiving user), as the catalog domain table states", "deadline": "Inside the Pix time limit: the SPI rejects any Pix not settled within 40 seconds on the primary message channel or 45 minutes on the secondary channel, which carries only scheduled Pix Agendado and Pix Cobrança orders (Manual de Tempos do Pix 7.0, sections 1.1 and 1.2). On the primary channel the receiving side's answer (t3' minus t2) has a service level of 1.4 seconds at the 50th percentile and 2.3 seconds at the 95th (section 4.1.1.2)." } ], "applies_to": "Pix payment orders (pacs.008) settled in the SPI" }, "caveat": "The Regulamento places the duty to reject sanctioned payers' Pix on the payer's participant (art. 38, V), while the catalog lists the receiving participant as raising RR04; the texts read do not reconcile the two. All operations, including rejected ones, stay subject to anti-money-laundering monitoring (art. 38, sole paragraph).", "related": [ "pix-reject:FRAD", "pix-reject:DS04" ], "basis": { "sources": "SPI message catalog 5.12.1 (spi.5.12.1.zip), PACS002.xlsx, Tabela de Domínios, entry RR04 (ISO name and definition, BCB comment, raising participant); Notas de Versão in spi.5.13.1.zip (cumulative release notes), versions 5.02.1 (added as RR4) and 5.02.3 (renamed RR04); Regulamento annexed to Resolução BCB nº 1/2020 (consolidated, version 41), art. 38, V and sole paragraph.", "confidence": "medium" }, "currency": { "effective_since": "Catalog 5.02.1", "effective_note": "Added as RR4 in catalog 5.02.1 (published 2021-03-19) and corrected to RR04 in 5.02.3 (published 2021-05-24) (release notes). Release note dates are publication dates; the SPI production date of that catalog was not read [Unverified]. Catalog 5.12.1 (published 2026-03-27) has been in SPI production since 2026-06-28 (BCB Comunicação eletrônica de dados page, Comunicado 44.424). Catalog 5.13.1 (SPI production 2026-10-25) keeps this code with the same comment.", "source_edition": "SPI message catalog 5.12.1 (spi.5.12.1.zip, PACS002.xlsx, pacs.002 v1.16, 2026-03-27); Manual de Tempos do Pix 7.0", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.bcb.gov.br/content/estabilidadefinanceira/cedsfn/Catalogos/spi.5.12.1.zip", "source_class": "authoritative_primary", "source_title": "SPI message catalog 5.12.1 (spi.5.12.1.zip), PACS002.xlsx Tabela de Dominios; Manual de Tempos do Pix 7.0", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms code RR04, name Regulatory Reason, and the BCB comment describing a UN Security Council sanctioned payer, raised by the receiving participant per the catalog. Confirms the reject deadline. Does not reconcile the conflict with Regulamento art. 38, V naming the payer's participant, which the caveat already states accurately." } ] }, "rail_name": "Pix Payment Rejects", "governing_authority": "Banco Central do Brasil", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "pix-reject:RR06", "id": "RR06", "rail": "pix-reject", "kind": "reason-code", "name": "Tax Information Invalid", "group": "technical", "summary": "Tax data is present where it may not be. BCB describes it as a tax block filled when payer and receiver are not both legal entities, that is, not both identified by a 14-character CNPJ. The SPI raises it.", "triggers": [ "The pacs.008 carries the tax block while the payer's or the receiver's tax id is a CPF (11 characters)" ], "actions": [ "Payer's participant: fill the tax block only when both CPF/CNPJ fields are CNPJs", "Payer's participant: from 2026-10-25, also check the initiation form (see caveat)" ], "retry": { "allowed": true, "rule": "Allowed once the cause is fixed. The rejected order itself is final. Resending the same operation (same EndToEndId, or same return id) within the 24-hour idempotency window only returns the earlier answer (SPI catalog 5.12, Idempotência, pp.15 to 16, and p.18), so a corrected payment goes as a new order with a new identifier [Inference]. The catalog sets no retry limit [Unverified]." }, "facts": { "return_windows": [ { "action": "reject (pacs.002 with status RJCT and this reason code)", "by": "SPI (the settlement system operated by the BCB), as the catalog domain table states", "deadline": "During SPI processing, inside the Pix time limit of 40 seconds on the primary message channel or 45 minutes on the secondary channel, which carries only scheduled Pix Agendado and Pix Cobrança orders (Manual de Tempos do Pix 7.0, sections 1.1 and 1.2). The pacs.002 goes out on the channel of the pacs.008 that started the payment (SPI catalog 5.12, Canais de Transmissão, pp.13 to 14). [Inference: a validation reject is sent at once; the Manual sets no separate time for it.]" } ], "applies_to": "Pix payment orders (pacs.008) settled in the SPI" }, "caveat": "Catalog 5.13.1, in SPI production from 2026-10-25, narrows the rule: the block may be filled only when both parties are legal entities and the initiation form (formaDeIniciacao) is QRES, APES, MANU or DICT. This record states the 5.12.1 rule in force at the snapshot. AM23 covers tax amounts that exceed the payment.", "related": [ "pix-reject:AM23", "pix-reject:FF07" ], "basis": { "sources": "SPI message catalog 5.12.1 (spi.5.12.1.zip), PACS002.xlsx, Tabela de Domínios, entry RR06 (ISO name and definition, BCB comment, raising participant); Notas de Versão in spi.5.13.1.zip (cumulative release notes), versions 5.12.1 (added) and 5.13.1 (comment changed); SPI message catalog 5.13.1 (spi.5.13.1.zip), PACS002.xlsx, Tabela de Domínios, entry RR06.", "confidence": "high" }, "currency": { "effective_since": "2026-06-28", "effective_note": "Added in catalog 5.12.1, published 2026-03-27 (release notes); SPI production 2026-06-28 (BCB Comunicação eletrônica de dados page, Comunicado 44.424). Catalog 5.13.1 changes the comment from 2026-10-25 (see caveat); supersession is due on or after that date.", "source_edition": "SPI message catalog 5.12.1 (spi.5.12.1.zip, PACS002.xlsx, pacs.002 v1.16, 2026-03-27); Manual de Tempos do Pix 7.0", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.bcb.gov.br/content/estabilidadefinanceira/cedsfn/Catalogos/spi.5.12.1.zip", "source_class": "authoritative_primary", "source_title": "SPI message catalog 5.12.1 (spi.5.12.1.zip), PACS002.xlsx Tabela de Dominios; SPI message catalog 5.13.1 (spi.5.13.1.zip), PACS002.xlsx Tabela de Dominios", "checked_on": "2026-09-21", "checked_by": "validator-sonnet-2026-09-21", "notes": "Confirms code RR06 in catalog 5.12.1, ISO name TaxInformationInvalid, and the BCB comment naming a tax element block that may only be filled when both the payer and the receiver are identified by a 14 character CNPJ, raised by the SPI. Confirms the 5.13.1 domain table narrows the same code from 2026-10-25 to also require the initiation form field to be QRES, APES, MANU or DICT." } ] }, "rail_name": "Pix Payment Rejects", "governing_authority": "Banco Central do Brasil", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "pix-reject:SL02", "id": "SL02", "rail": "pix-reject", "kind": "reason-code", "name": "Specific Service Offered By Creditor Agent", "group": "administrative", "summary": "A return uses the withdrawal reason for a Pix that was not a withdrawal. BCB describes it as a return (pacs.004) whose referenced transaction is not related to Pix Saque or Pix Troco. The receiving participant raises it.", "triggers": [ "A pacs.004 with return reason SL02 refers to an original Pix that was neither a Pix Saque nor a Pix Troco [Inference: SL02 is also the pacs.004 return reason for Saque and Troco]" ], "actions": [ "Returning participant: use SL02 as the return reason only for Pix Saque and the cash part of Pix Troco; use the ordinary return reason otherwise (Orca's Pix rail brief, docs/rails/pix.md, pacs.004 codes)", "Returning participant: send the purchase part and the cash part of a Pix Troco as separate returns (Regulamento art. 41, §3)" ], "retry": { "allowed": true, "rule": "Allowed as a new return with the right return reason. Resending the same operation (same EndToEndId, or same return id) within the 24-hour idempotency window only returns the earlier answer (SPI catalog 5.12, Idempotência, pp.15 to 16, and p.18), so a corrected payment goes as a new order with a new identifier [Inference]. The catalog sets no retry limit [Unverified]." }, "facts": { "return_windows": [ { "action": "reject (pacs.002 with status RJCT and this reason code)", "by": "Receiving participant, as the catalog domain table states [Inference: for a return (pacs.004) this is the participant receiving the return, which is the original payer's participant; the table does not say so]", "deadline": "When the receiving participant processes the return. A return (pacs.004) and the pacs.002 answering it always use the primary channel (SPI catalog 5.12, p.14). [Unverified: the Manual de Tempos do Pix 7.0 states its 40-second limit for Pix payment orders and does not name returns.]" } ], "applies_to": "Pix returns (devolução, pacs.004) settled in the SPI" }, "caveat": "SL02 is also a pacs.004 return reason; that meaning belongs to the Pix return codes, not this directory. Saque and Troco returns are started by the withdrawal facilitator or agent within 1 hour of finding them due (Regulamento arts. 40-A and 41, §§2 and 4).", "related": [ "pix-reject:MD01", "pix-reject:DT05", "pix-reject:AG13" ], "basis": { "sources": "SPI message catalog 5.12.1 (spi.5.12.1.zip), PACS002.xlsx, Tabela de Domínios, entry SL02 (ISO name and definition, BCB comment, raising participant); Notas de Versão in spi.5.13.1.zip (cumulative release notes), versions 5.02.1, 5.02.3 and 5.07.1; Regulamento annexed to Resolução BCB nº 1/2020 (consolidated, version 41), arts. 40-A and 41; Catálogo de Serviços do SFN Volume VI (SPI catalog) 5.12, p.14.", "confidence": "medium" }, "currency": { "effective_since": "Catalog 5.02.1", "effective_note": "Added to the pacs.002 domain table in catalog 5.02.1, published 2021-03-19 (Notas de Versão in spi.5.13.1.zip (cumulative release notes)). The comment was changed in 5.02.3 and 5.07.1. Release note dates are publication dates; the SPI production date of that catalog was not read [Unverified]. Catalog 5.12.1 (published 2026-03-27) has been in SPI production since 2026-06-28 (BCB Comunicação eletrônica de dados page, Comunicado 44.424). Catalog 5.13.1 (SPI production 2026-10-25) keeps this code with the same comment.", "source_edition": "SPI message catalog 5.12.1 (spi.5.12.1.zip, PACS002.xlsx, pacs.002 v1.16, 2026-03-27); Manual de Tempos do Pix 7.0", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.bcb.gov.br/content/estabilidadefinanceira/cedsfn/Catalogos/spi.5.12.1.zip", "source_class": "authoritative_primary", "source_title": "SPI message catalog 5.12.1 (spi.5.12.1.zip), PACS002.xlsx Tabela de Dominios; Regulamento Pix anexo a Resolucao BCB no. 1/2020 consolidated version 41", "checked_on": "2026-09-21", "checked_by": "validator-sonnet-2026-09-21", "notes": "Confirms code SL02, ISO name SpecificServiceOfferedByCreditorAgent, and the BCB comment naming a return whose original transaction is not related to Pix Saque or Pix Troco, raised by the receiving participant as the table states. Confirms a Pix Saque or Pix Troco return must be started by the withdrawal facilitator or agent under Regulamento art. 40-A, within 1 hour under art. 41 paragraphs 2 and 4." } ] }, "rail_name": "Pix Payment Rejects", "governing_authority": "Banco Central do Brasil", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "pix-reject:UPAY", "id": "UPAY", "rail": "pix-reject", "kind": "reason-code", "name": "Undue Payment", "group": "authorization", "summary": "The payment has no valid recurring authorization behind it. BCB describes it as an undue payment because there is no valid or active recurrence. The receiving participant raises it.", "triggers": [ "A Pix Automático payment arrives for a recurrence that is not active or not valid [Inference: the catalog does not list causes]" ], "actions": [ "Payer's participant: send Pix Automático payments only under an active authorization", "Receiving participant: reject payments that do not match the charge behind them (Regulamento art. 39, IV) [Inference]" ], "retry": { "allowed": false, "rule": "Not for the same reason. Without an active recurrence the payment stays undue. Resending the same operation (same EndToEndId, or same return id) within the 24-hour idempotency window only returns the earlier answer (SPI catalog 5.12, Idempotência, pp.15 to 16, and p.18), so a corrected payment goes as a new order with a new identifier [Inference]. The catalog sets no retry limit [Unverified]." }, "facts": { "return_windows": [ { "action": "reject (pacs.002 with status RJCT and this reason code)", "by": "Receiving participant (PSP of the receiving user), as the catalog domain table states", "deadline": "Inside the Pix time limit: the SPI rejects any Pix not settled within 40 seconds on the primary message channel or 45 minutes on the secondary channel, which carries only scheduled Pix Agendado and Pix Cobrança orders (Manual de Tempos do Pix 7.0, sections 1.1 and 1.2). On the primary channel the receiving side's answer (t3' minus t2) has a service level of 1.4 seconds at the 50th percentile and 2.3 seconds at the 95th (section 4.1.1.2)." } ], "applies_to": "Pix payment orders (pacs.008) settled in the SPI, Pix Automático" }, "caveat": "UPAY on Pix is a reject reason, not the RTP warranty claim reason of the same letters.", "related": [ "pix-reject:CN01", "pix-reject:INDT" ], "basis": { "sources": "SPI message catalog 5.12.1 (spi.5.12.1.zip), PACS002.xlsx, Tabela de Domínios, entry UPAY (ISO name and definition, BCB comment, raising participant); Notas de Versão in spi.5.13.1.zip (cumulative release notes), version 5.09.2; Regulamento annexed to Resolução BCB nº 1/2020 (consolidated, version 41), art. 39, IV.", "confidence": "medium" }, "currency": { "effective_since": "Catalog 5.09.2", "effective_note": "Added to the pacs.002 domain table in catalog 5.09.2, published 2024-12-09 (Notas de Versão in spi.5.13.1.zip (cumulative release notes)). Release note dates are publication dates; the SPI production date of that catalog was not read [Unverified]. Catalog 5.12.1 (published 2026-03-27) has been in SPI production since 2026-06-28 (BCB Comunicação eletrônica de dados page, Comunicado 44.424). Catalog 5.13.1 (SPI production 2026-10-25) keeps this code with the same comment.", "source_edition": "SPI message catalog 5.12.1 (spi.5.12.1.zip, PACS002.xlsx, pacs.002 v1.16, 2026-03-27); Manual de Tempos do Pix 7.0", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.bcb.gov.br/content/estabilidadefinanceira/cedsfn/Catalogos/spi.5.12.1.zip", "source_class": "authoritative_primary", "source_title": "SPI message catalog 5.12.1 (spi.5.12.1.zip), PACS002.xlsx Tabela de Dominios; Manual de Tempos do Pix 7.0", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms code UPAY, ISO name UnduePayment, and the BCB comment describing a payment with no valid or active recurrence, raised by the receiving participant. Confirms the reject deadline." } ] }, "rail_name": "Pix Payment Rejects", "governing_authority": "Banco Central do Brasil", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "pix-return:BE08", "id": "BE08", "rail": "pix-return", "kind": "reason-code", "name": "BankError", "group": "technical", "summary": "A return under the Special Return Mechanism (MED) for an operational failure in a participant's IT systems. The BCB comment on the code says, in Portuguese, that the payee's participant starts this return within the MED, either because the payer's participant asked for it on the ground of its own operational failure, or because the failure happened in the payee's participant's own systems. It is a pacs.004 from the payee's participant, never a pull by the payer's side.", "triggers": [ "The payer's participant sent a Pix in error, for example a duplicate, an amount different from the payer's instruction, or funds sent without the payer's confirmation (DICT 8.5 section 17.1)", "The payee's participant finds an operational failure in its own systems that affected the Pix (Reg. art. 41-C, I)" ], "actions": [ "Payer's participant: open a refund request in the DICT with reason operational_flaw, the amount (up to the original) and details that let the payee's participant confirm the failure; no infraction notice is needed (DICT 8.5 sections 17, 17.1, 17.1.1 steps 1 and 2)", "Payer's participant: do not use this path when the payer chose the wrong key or account, sent two orders on purpose, or when the Pix was correctly started and credited; those are not operational failures (Reg. art. 41-B section 3; DICT 8.5 section 17.1)", "Payer's participant: for fraud or scams open a Recuperacao de Valores instead (FR01); for a faulty Pix Automatico payment use reason pix_automatico, which is refunded by a pacs.008 with purpose REFU, not by BE08 (DICT 8.5 sections 17.1 and 17.3)", "Payee's participant: check that the case is an operational failure and that the payee's account holds funds; if both, send the pacs.004 with BE08 at once, tell the payee, and close the request as totally or partially accepted (DICT 8.5 section 17.1.1 steps 5 to 9; Reg. art. 41-F)", "Payee's participant: otherwise close the request as rejected with reason invalid_request (not an operational failure, with an explanation), no_balance, account_closure or other; no later monitoring of the account is required (DICT 8.5 sections 17 and 17.1)" ], "retry": { "allowed": false, "rule": "The texts read give no path to reopen a refund request after the payee's participant closes it; a request can be cancelled by the payer's participant only while it is still open (DICT 8.5 section 17). A BE08 return cannot be contested through a Recuperacao de Valores (DICT 8.5 sections 20.1.1 and 20.1.9)." }, "facts": { "return_windows": [ { "action": "refund request in the DICT, reason operational_flaw", "by": "Paying participant (payer's PSP)", "deadline": "Only for a Pix made in the last 90 days (DICT 8.5 section 17.1.1 step 2; Reg. art. 41-A, II)" }, { "action": "analysis and closing of the refund request", "by": "Receiving participant (payee's PSP)", "deadline": "95 percent of requests closed within 48 hours of opening, a service level indicator for participants with direct DICT access (Manual de Tempos 7.0 section 4.2.1.9)" }, { "action": "return (pacs.004 with BE08) after accepting the request", "by": "Receiving participant (payee's PSP)", "deadline": "Immediately after confirming the failure and the available balance (DICT 8.5 section 17.1.1 step 6)" }, { "action": "return (pacs.004 with BE08) for a failure in its own systems", "by": "Receiving participant (payee's PSP), on its own initiative", "deadline": "Initiated within 90 days of the original Pix (Reg. art. 41-A, II)" } ], "applies_to": "a Pix affected by an operational failure in the IT systems of the payer's or the payee's participant, other than a Pix Automatico payment error, a Pix Saque withdrawal or the cash part of a Pix Troco" }, "caveat": "MED returns need a prominent clause in the payee's account contract allowing blocks and returns (Reg. art. 41-C section 1), and they depend on funds in the payee's account (Reg. art. 41-A, I). The participant that asked for a MED return is responsible for it (Reg. art. 41-H). The 48 hour figure is a percentile service level, not a per-case deadline. For an indirect DICT participant the request and answer pass through its direct-access participant, which sends the pacs.004 (DICT 8.5 section 17.1.2). The DICT enumeration value is operational_flaw; BE08 is the ISO code on the pacs.004 that results. The payee's own-failure path is taken from the catalog comment and Reg. art. 41-C, I; the DICT manual read describes only the payer-side request flow.", "related": [ "pix-return:FR01", "pix-return:MD06" ], "basis": { "sources": "BCB SPI message catalog 5.12.1 (spi.5.12.1.zip), PACS004.xlsx Tabela de Dominios entry for BE08 (ISO name and BCB comment); catalog 5.13.1 PACS004.xlsx checked, unchanged. Regulamento Pix annexed to Resolucao BCB n. 1/2020, consolidated text version 41, arts. 41-A (I, II), 41-B (II and section 3, Res. BCB 402/2024 and 403/2024), 41-C (I, II b, section 1), 41-F, 41-H. Manual Operacional do DICT version 8.5 (in force from 2026-09-01, published under versoes_futuras), sections 17, 17.1, 17.1.1, 17.1.2, 17.3, 20.1.1, 20.1.9. Manual de Tempos do Pix version 7.0, section 4.2.1.9.", "confidence": "high" }, "currency": { "effective_since": "2026-09-01", "effective_note": "Date DICT manual 8.5, the MED text used here, took effect; its revision history lists no change to section 17.1 against 8.4 [Inference: section 17.1 is unchanged]. The operational failure exclusion in Reg. art. 41-B section 3 dates from Res. BCB 403/2024; the MED itself took effect on 2021-11-16 (Res. BCB 103/2021). The 48 hour indicator was added to the Manual de Tempos in the 2026-02-02 revision of version 7.0. Code list per SPI catalog 5.12.1; 5.13.1 leaves the pacs.004 codes unchanged. A further 8.5 change on 2026-10-26 touches infraction notices only.", "source_edition": "SPI catalog 5.12.1 (2026-03-27); Regulamento Pix consolidated version 41; Manual Operacional do DICT 8.5; Manual de Tempos do Pix 7.0", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.bcb.gov.br/content/estabilidadefinanceira/pix/Regulamento_Pix/versoes_futuras/X_ManualOperacionaldoDICT-versao8-5.pdf", "source_class": "authoritative_primary", "source_title": "Manual Operacional do DICT versao 8.5 (in force since 2026-09-01), sections 17 and 20; Regulamento Pix consolidated version 41; Manual de Tempos do Pix 7.0; SPI catalog 5.12.1 and 5.13.1 PACS004 domain table", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms the operational failure refund request flow end to end: the 90 day window to open a request (DICT 8.5 section 17.1.1 step 2, matching Reg. art. 41-A section II), the rejection reasons invalid_request, no_balance, account_closure and other (DICT 8.5 section 17), the indirect participant flow routed through a direct access participant (section 17.1.2), and that section 17.1 is textually identical to DICT 8.4. Confirms the 95th percentile 48 hour closing indicator is a service level, not a per case deadline (Manual de Tempos 7.0 section 4.2.1.9). Confirms a devolucao from operational failure cannot be contested through Recuperacao de Valores (DICT 8.5 sections 20.1.1 and 20.1.9). Confirms the MED contract clause and the responsibility rule for the requesting participant (Reg. arts. 41-C section 1, 41-H). Does not confirm any deadline for the payee participant's own initiative return beyond the general 90 day rule in Reg. art. 41-A section II; that stays an open check." } ] }, "rail_name": "Pix Returns (Devolucao)", "governing_authority": "Banco Central do Brasil", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "pix-return:FR01", "id": "FR01", "rail": "pix-return", "kind": "reason-code", "name": "Fraud", "group": "authorization", "summary": "A return under the Special Return Mechanism (MED) on well-founded suspicion of fraud. The BCB comment on the code says, in Portuguese, that the payee's participant starts this return within the MED, either because the payer's participant asked for it on that ground or because the payee's participant itself found such a suspicion. Payer-side cases now run in the DICT as a Recuperacao de Valores (funds recovery, MED 2.0), which traces and blocks funds across later hops; FR01 is used only for the return from the account that received the original Pix.", "triggers": [ "The payer was scammed, including social engineering, into starting or authorizing the Pix (DICT 8.5 section 10, note 7; situation type scam)", "The Pix was started without the payer's digital authentication, or by a third party who got into the payer's channel and is not recognized by the payer (account_takeover, fraudulent_access)", "The payer acted under coercion or extortion (coercion)", "The payee's participant holds the funds under a precautionary block and finds well-founded suspicion of fraud, or finds the fraud itself (Reg. arts. 39-B section 6, I and 41-C, I)" ], "actions": [ "Payer's participant (the recovering participant): open a Recuperacao de Valores in the DICT at once after the suspicion or the payer's complaint, and analyse the merits afterwards; cancel it if the case is not fraud, which bars any new case for that Pix (DICT 8.5 sections 20, 20.1.5, 20.1.10)", "Every notified payee participant: block the requested amount immediately, up to the balance, and block again as new funds arrive until the amount is reached or the notice closes (Reg. art. 41-D section 1; DICT 8.5 section 20.1.4)", "Every notified payee participant: accept or reject the infraction notice with a fraud type; accept even with no balance if the account took part in moving the funds, since acceptance lets later hops be refunded and marks the payee for fraud (DICT 8.5 sections 10.1, 20.1.5)", "Payee's participant of the original Pix: on the DICT refund request, debit the blocked funds and send a pacs.004 with FR01 immediately, then close the request with the amount actually returned (DICT 8.5 sections 17, 20.1.6, 20.4 step 13)", "Payee participants of later hops: do not use FR01; return with a pacs.008 in the participant's own name with purpose IPRT to the account in the request (Reg. art. 41-D section 4; DICT 8.5 section 20.1.6)", "Payee's participant: release blocked funds only after rejecting the notice, after closing the refund request, or when the case is cancelled or ends, and tell the payee (DICT 8.5 section 20.1.7; Reg. art. 41-F)" ], "retry": { "allowed": false, "rule": "Only one Recuperacao de Valores may be opened per transaction, even after a cancellation, and none for a Pix already contested directly by an infraction notice (DICT 8.5 section 20.1.1). A payee who disputes the FR01 return itself may contest it once, as a new case with that pacs.004 as root (DICT 8.5 section 20.1.9)." }, "facts": { "return_windows": [ { "action": "open a Recuperacao de Valores (funds recovery) for the original Pix", "by": "Paying participant (payer's PSP), as recovering participant", "deadline": "Immediately after the suspicion or the payer's complaint (DICT 8.5 section 20); the original Pix must be no more than 80 calendar days old (DICT 8.5 sections 20.1.1 and 20.2 step 5); service level: 95 percent opened within 1,800 seconds of the payer's complaint (Manual de Tempos 7.0 section 4.2.2.7)" }, { "action": "block the funds on receiving the infraction notice", "by": "Receiving participant (payee's PSP) of each prioritized transaction", "deadline": "Immediately on receipt, topped up as funds arrive until the requested amount is reached or the notice closes (Reg. art. 41-D section 1, wording in force from 2026-07-01; DICT 8.5 sections 20.1.4 and 20.3 step 4)" }, { "action": "analyse and close the infraction notice (accept or reject)", "by": "Receiving participant (payee's PSP)", "deadline": "7 days after the notice is available as open (DICT 8.5 section 20.3 step 5, citing the Manual de Tempos); measured at the 95th percentile (Manual de Tempos 7.0 section 4.2.1.6)" }, { "action": "start the refund stage", "by": "Paying participant (payer's PSP), as recovering participant", "deadline": "Within 72 hours after the analysis stage ends; otherwise the DICT closes the case as completed with no refund (DICT 8.5 section 20.1.6)" }, { "action": "return (pacs.004 with FR01) from the account that received the original Pix", "by": "Receiving participant (payee's PSP)", "deadline": "Immediately on the DICT refund request (DICT 8.5 section 20.4 step 13); service level: 99 percent of fraud refund requests closed within 6 hours of opening (Manual de Tempos 7.0 section 4.2.1.8); in any case within 90 days of the original Pix (Reg. art. 41-A, II)" }, { "action": "return (pacs.004 with FR01) on its own initiative after a precautionary block", "by": "Receiving participant (payee's PSP)", "deadline": "The precautionary block lasts at most 72 hours, within which the participant decides (Reg. art. 39-B sections 4 to 6); the return must start within 90 days of the original Pix (Reg. art. 41-A, II)" }, { "action": "contest the FR01 return as fraud (new Recuperacao de Valores with the pacs.004 as root)", "by": "Payee's participant, for the payee of the original Pix", "deadline": "Within 80 days of the return (DICT 8.5 sections 20.1.1 and 20.1.9; 30 days under DICT 8.4 until 2026-08-31); a successful contest is refunded by a pacs.008 with the parties reversed (DICT 8.5 section 20.1.6)" } ], "applies_to": "a Pix with well-founded suspicion of fraud where the funds did not go to a good-faith third party, other than a Pix Saque withdrawal or the cash part of a Pix Troco" }, "caveat": "The MED excludes disputes about the underlying deal and fraud whose funds went to a good-faith third party's account (Reg. art. 41-B section 1). A payee's right to ask for cancellation of a MED return within 30 days (Reg. art. 41-G) was revoked from 2026-07-01 (Res. BCB 559/2026); the fraud contest in DICT 8.5 section 20.1.9 is the route now. If the recovering participant cancels a case after funds came back, it must send them back to each participant that returned them, as far as the payer's balance allows (DICT 8.5 section 20.1.10). A rejected refund request still leaves the fraud mark in place when the notice was accepted (DICT 8.5 section 17). The 6 hour, 7 day and 1,800 second figures are percentile service levels in the Manual de Tempos, not per-case limits, though DICT 8.5 section 20.3 phrases the 7 days as a time allowed. The DICT manual in force since 2026-09-01 is version 8.5, published under versoes_futuras while 8.4 still sits at the main URL; a further 8.5 change on 2026-10-26 adds the graph depth to infraction notices. The payee participant's own-initiative return is taken from the catalog comment and Reg. arts. 39-B and 41-C, I; the DICT manual read covers the payer-side flow. The schema has no fraud group; authorization is used as on the RTP and SEPA rails.", "related": [ "pix-return:BE08", "pix-return:MD06" ], "basis": { "sources": "BCB SPI message catalog 5.12.1 (spi.5.12.1.zip), PACS004.xlsx Tabela de Dominios entry for FR01 (ISO name and BCB comment); catalog 5.13.1 PACS004.xlsx checked, unchanged. Regulamento Pix annexed to Resolucao BCB n. 1/2020, consolidated text version 41, arts. 39-B (sections 4 to 6), 41-A (II), 41-B (I, section 1), 41-C (I, II a), 41-D (section 1 as worded by Res. BCB 559/2026 from 2026-07-01; section 4, Res. BCB 493/2025), 41-E, 41-F, 41-G (revoked by Res. BCB 559/2026 from 2026-07-01). Manual Operacional do DICT version 8.5 (in force from 2026-09-01, published under versoes_futuras), sections 10, 10.1, 17, 20, 20.1.1, 20.1.4 to 20.1.7, 20.1.9, 20.1.10, 20.2 step 5, 20.3 steps 4 and 5, 20.4 step 13, revision history; version 8.4 sections 20.1.1 and 20.1.9 for the earlier 30 day contest limit. Manual de Tempos do Pix version 7.0, sections 4.2.1.6, 4.2.1.8, 4.2.2.7.", "confidence": "high" }, "currency": { "effective_since": "2026-09-01", "effective_note": "DICT manual 8.5 took effect on 2026-09-01 and raised the limit to contest a return from 30 to 80 days. Reg. art. 41-D section 1 took its current wording and art. 41-G was revoked on 2026-07-01 (Res. BCB 559/2026). The MED took effect on 2021-11-16 (Res. BCB 103/2021); the funds recovery rules in arts. 41-D section 4 and 41-E come from Res. BCB 493/2025. Code list per SPI catalog 5.12.1; 5.13.1 leaves the pacs.004 codes unchanged. When a DICT 8.6 or later is published, recheck the windows.", "source_edition": "SPI catalog 5.12.1 (2026-03-27); Regulamento Pix consolidated version 41; Manual Operacional do DICT 8.5; Manual de Tempos do Pix 7.0", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.bcb.gov.br/content/estabilidadefinanceira/pix/Regulamento_Pix/versoes_futuras/X_ManualOperacionaldoDICT-versao8-5.pdf", "source_class": "authoritative_primary", "source_title": "Manual Operacional do DICT versao 8.5 (in force since 2026-09-01), section 20; Regulamento Pix consolidated version 41; Manual de Tempos do Pix 7.0; SPI catalog 5.12.1 and 5.13.1 PACS004 domain table", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the Recuperacao de Valores flow: the 80 day window to open a case (DICT 8.5 sections 20.1.1 and 20.2 step 5), the immediate and topped up blocking rule in its wording in force since 2026-07-01 (Reg. art. 41-D section 1, Res. BCB 559/2026), the 72 hour window to start the refund stage after analysis closes or the case auto completes otherwise (DICT 8.5 section 20.1.6), the single case per transaction rule that survives cancellation (DICT 8.5 section 20.1.1), the window to contest a devolucao raised from 30 to 80 days effective 2026-09-01 (DICT 8.5 section 20.1.9 and revision history, against DICT 8.4 wording), the pacs.008 IPRT purpose for later hop refunds (section 20.1.6), and the revocation of art. 41-G's 30 day cancellation right effective 2026-07-01 (Res. BCB 559/2026). Confirms the 95th percentile 7 day analysis indicator, that DICT 8.5 section 20.3 step 5 itself phrases the 7 days as time allowed to the participant, and the 99 percent 6 hour and 95 percent 1800 second indicators (Manual de Tempos 7.0 sections 4.2.1.6, 4.2.1.8, 4.2.2.7). Does not confirm any deadlines from the Manual de Resolucao de Disputas or the fraud criteria document under art. 39-C, neither of which was read." } ] }, "rail_name": "Pix Returns (Devolucao)", "governing_authority": "Banco Central do Brasil", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "pix-return:MD06", "id": "MD06", "rail": "pix-return", "kind": "reason-code", "name": "RefundRequestByEndCustomer", "group": "administrative", "summary": "An ordinary Pix return (devolucao) that the payee asked its own participant to send. The BCB comment on the code says, in Portuguese, that the return was requested by the receiving user. The payee starts it, on its own or because the payer asked; the payer and the payer's participant cannot force it. It travels as a pacs.004, a new value message back to the payer, not a debit pulled by the payer's side.", "triggers": [ "The payee received a Pix it does not want to keep, for example a payment sent by mistake or a purchase that is being refunded", "The payer asked the payee for the money back and the payee agreed (Reg. art. 40 section 1)", "The purchase part of a Pix Troco is being returned, sent as a separate return from the cash part [Inference: the regulation requires separate returns (art. 41 section 3) and reserves SL02 for Saque and Troco returns; the texts read do not name the code for the purchase part]" ], "actions": [ "Receiving participant: take the amount from the payee and debit the payee's account only after the payee authorizes it, then send the pacs.004 with MD06 to the payer's participant (Reg. art. 41 and section 1)", "Receiving participant: send the return only if the payee's account holds enough funds (Reg. art. 41-A, I)", "Receiving participant: fill the pacs.004 with the end-to-end id of the original pacs.008, priority HIGH when the payee wants the return sent at once, or NORM when the payee asks to defer it or the participant has a justified fraud-prevention reason to delay it (Cat. 5.12.1 PACS004 layout and domain table)", "Payer's participant: credit the payer, or reject a return whose amount would take the returns above the original Pix (pacs.002 AM09, raised by the payer's participant); the SPI itself rejects a return of a return (pacs.002 AG13) (Cat. 5.12.1 PACS002 domain table)", "Payer: if the case is fraud or an operational failure of a participant, ask your participant to use the Special Return Mechanism (MED) instead; MD06 depends on the payee's goodwill" ], "retry": { "allowed": true, "rule": "Several partial returns of the same Pix are allowed until the original amount is reached (Reg. art. 40 section 2). A return of a return is not allowed (Cat. 5.12.1 PACS002, AG13). Resending the same operation within 24 hours returns the earlier answer under the SPI idempotency rule (Cat. 5.12 p. 18)." }, "facts": { "return_windows": [ { "action": "request for a return", "by": "Payer, to the payee (optional; the payee decides)", "deadline": "No deadline of its own; the return it leads to must still start within 90 days of the original Pix (Reg. art. 40 section 1, art. 41-A, II)" }, { "action": "return (pacs.004 with MD06), total or partial", "by": "Receiving participant (payee's PSP), on the payee's instruction", "deadline": "Initiated within 90 days of the date of the original Pix (Reg. art. 41-A, II); the SPI rejects a return past the regulated limit with pacs.002 DT05 (Cat. 5.12.1 PACS002 domain table)" } ], "applies_to": "a Pix credited to the payee's transactional account, other than the withdrawal of a Pix Saque or the cash part of a Pix Troco" }, "caveat": "Devolucao is not an ACH-style return: nothing obliges the payee to return funds, and the payer's participant has no MD06 claim. Fraud and participant operational failures go through the MED (Reg. arts. 41-B to 41-I) with codes FR01 and BE08. The pacs.004 must use the SPI primary channel (Cat. 5.12 p. 14); whether the 40 second settlement limit for a Pix on that channel (Manual de Tempos 7.0 section 1.1) also applies to a pacs.004 is not stated in the texts read [Inference: likely]. SPI messages carry UTC; rules use Brasilia time. Days in the regulation are taken as calendar days [Inference]. The payer's participant may also reject a return that would exceed the limit for the credited account type (pacs.002 AM02).", "related": [ "pix-return:SL02", "pix-return:BE08", "pix-return:FR01" ], "basis": { "sources": "BCB SPI message catalog 5.12.1 (spi.5.12.1.zip), PACS004.xlsx layout and Tabela de Dominios entry for MD06 (ISO name and BCB comment), PACS002.xlsx Tabela de Dominios entries AG13, AM02, AM09, DT05; catalog 5.13.1 PACS004.xlsx checked, unchanged. Catalogo de Servicos do SFN Volume VI version 5.12, pp. 14 and 18. Regulamento Pix annexed to Resolucao BCB n. 1/2020, consolidated text version 41, arts. 40 (sections 1 and 2, wording of Res. BCB 103/2021), 41 (section 1, Res. BCB 135/2021) and 41-A (I and II, wording of Res. BCB 167/2021). Manual de Tempos do Pix version 7.0, section 1.1 (for the caveat only).", "confidence": "high" }, "currency": { "effective_since": "2021-11-16", "effective_note": "The current wording of Reg. arts. 40 section 1 and 41-A took effect on 2021-11-16 (Res. BCB 103/2021); the 90 day limit was already in the original art. 42, since revoked. Code list per SPI catalog 5.12.1, in SPI production since 2026-06-28; 5.13.1 (production 2026-10-25) leaves the pacs.004 codes unchanged. Regulamento read as consolidated version 41 (latest listed amendment Res. BCB 559/2026).", "source_edition": "SPI catalog 5.12.1 (2026-03-27); Regulamento Pix consolidated version 41; Catalogo de Servicos do SFN Vol. VI 5.12", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.bcb.gov.br/estabilidadefinanceira/exibenormativo?tipo=Resolução%20BCB&numero=1", "source_class": "authoritative_primary", "source_title": "Regulamento Pix anexo a Resolucao BCB no. 1/2020, consolidated version 41; SPI message catalog 5.12.1 and 5.13.1 PACS004 and PACS002 domain tables", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms return is initiated by the receiving user, on its own or at the payer's request, with the 90 day window for return initiation (Reg. arts. 40 section 1, 41-A section II). Confirms the AG13 (return of a return, raised by SPI), AM02, AM09 and DT05 pacs.002 codes and which participant raises each. Confirms multiple partial returns are allowed until the original amount is reached (Reg. art. 40 section 2). Confirms the 24 hour idempotency window (catalog 5.12 idempotency chapter). Confirms the pacs.004 catalog comment for MD06 matches the record's paraphrase and that catalog 5.13.1 leaves the pacs.004 codes unchanged. Does not confirm the 40 second settlement limit applying to a pacs.004, or which code the purchase part of a Pix Troco return uses; both stay open checks." } ] }, "rail_name": "Pix Returns (Devolucao)", "governing_authority": "Banco Central do Brasil", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "pix-return:SL02", "id": "SL02", "rail": "pix-return", "kind": "reason-code", "name": "SpecificServiceOfferedByCreditorAgent", "group": "administrative", "summary": "A return of a Pix Saque (cash withdrawal) or of the cash part of a Pix Troco (purchase with cash back). The BCB comment on the code says, in Portuguese, that the receiving user asked for the return because of an error in the transaction or a disagreement between the parties over Pix Saque or Pix Troco. The withdrawal facilitator or the withdrawal agent starts it, and the payer must speak up at once.", "triggers": [ "The withdrawal facilitator or the withdrawal agent made an error in the transaction (Reg. art. 40-A, I)", "The payer and the facilitator or agent disagree before any cash is handed over (Reg. art. 40-A, II)" ], "actions": [ "Payer: ask the withdrawal facilitator (if it provides the service directly) or the withdrawal agent for the return immediately; on electronic channels they must offer a way to do this (Reg. art. 40-A sections 1 and 2)", "Withdrawal facilitator or agent: once you find the return is due, start it within 1 hour (Reg. art. 41 sections 2 and 4)", "For Pix Troco: return the cash part in its own transaction, separate from any return of the purchase amount (Reg. art. 41 section 3)", "Receiving participant: send the pacs.004 with SL02 only for a Pix Saque or Pix Troco; the payer's participant rejects an SL02 return that does not refer to one with pacs.002 SL02 (Cat. 5.12.1 PACS002 domain table)", "Do not use the MED for these amounts; it does not cover the withdrawal or the cash part of Troco (Reg. art. 41-B section 2)" ], "retry": { "allowed": true, "rule": "Partial returns of the same Pix may be repeated until the original amount is reached (Reg. art. 40 section 2, which art. 40-A builds on) [Inference: the texts read do not restate this for Saque and Troco]. A return of a return is not allowed (Cat. 5.12.1 PACS002, AG13)." }, "facts": { "return_windows": [ { "action": "request for a return", "by": "Payer, to the withdrawal facilitator or withdrawal agent", "deadline": "Immediately (Reg. art. 40-A section 1)" }, { "action": "return of a Pix Saque (pacs.004 with SL02)", "by": "Withdrawal facilitator or withdrawal agent, through the receiving participant", "deadline": "Initiated within 1 hour of finding that the return is due (Reg. art. 41 section 2); the 90 day limit does not apply (Reg. art. 41-A, II)" }, { "action": "return of the cash part of a Pix Troco (pacs.004 with SL02), separate from the purchase part", "by": "Withdrawal facilitator or withdrawal agent, through the receiving participant", "deadline": "Initiated within 1 hour of finding that the return is due (Reg. art. 41 sections 3 and 4); the 90 day limit does not apply to the cash part (Reg. art. 41-A, II)" } ], "applies_to": "a Pix with the purpose of Saque, or the cash part of a Pix with the purpose of Troco" }, "caveat": "Only two grounds are admitted: an error by the facilitator or agent, or a disagreement before the cash is delivered (Reg. art. 40-A). The purchase part of a Troco is returned separately and stays subject to the 90 day limit [Inference: which code it takes is not stated in the texts read]. The same letters SL02 on a pacs.002 mean something else: a reject of an SL02 return that does not refer to a Saque or Troco. The 1 hour clock runs from when the facilitator or agent finds the return due, not from the original Pix. The 90 day exception covers the withdrawal and the cash part only.", "related": [ "pix-return:MD06" ], "basis": { "sources": "BCB SPI message catalog 5.12.1 (spi.5.12.1.zip), PACS004.xlsx Tabela de Dominios entry for SL02 (ISO name and BCB comment), PACS002.xlsx Tabela de Dominios entries SL02 and AG13; catalog 5.13.1 PACS004.xlsx checked, unchanged; 5.13.1 release notes, version 5.02.1 entry (SL02 added as a return reason). Regulamento Pix annexed to Resolucao BCB n. 1/2020, consolidated text version 41, arts. 40 section 2, 40-A (I, II, sections 1 and 2, wording of Res. BCB 172/2021), 41 sections 2 to 4 (wording of Res. BCB 135/2021, 167/2021 and 172/2021), 41-A, II (wording of Res. BCB 167/2021) and 41-B section 2 (Res. BCB 167/2021).", "confidence": "high" }, "currency": { "effective_since": "2021-12-09", "effective_note": "Date of Res. BCB 172/2021, which gave arts. 40-A and 41 sections 2 and 4 their current wording; the consolidated text tags no later effective date for it [Inference: effective on that date]. SL02 was added to the pacs.004 code list in catalog 5.02.1 (2021-03-19). Code list per SPI catalog 5.12.1; 5.13.1 leaves the pacs.004 codes unchanged. Regulamento read as consolidated version 41.", "source_edition": "SPI catalog 5.12.1 (2026-03-27); Regulamento Pix consolidated version 41", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.bcb.gov.br/estabilidadefinanceira/exibenormativo?tipo=Resolução%20BCB&numero=1", "source_class": "authoritative_primary", "source_title": "Regulamento Pix anexo a Resolucao BCB no. 1/2020, consolidated version 41; SPI message catalog 5.12.1 and 5.13.1 PACS004 and PACS002 domain tables", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms art. 40-A grounds (facilitator or agent error, or disagreement before cash delivery), the immediate request duty and electronic channel mechanism (art. 40-A sections 1 and 2), the 1 hour window to initiate a Saque or Troco cash return once due (Reg. art. 41 sections 2 to 4), the separate transaction requirement for the Troco cash part (art. 41 section 3), the MED exclusion for Saque and Troco cash (art. 41-B section 2), and the 90 day exception for Saque and Troco cash (art. 41-A section II). Confirms the pacs.002 SL02 reject meaning, a return not tied to Saque or Troco, and AG13. Does not confirm the code used for the purchase part of a Troco return, or anything about the effective date of Res. BCB 172/2021 beyond the resolution carrying no later deferred date in the consolidated text; both stay open checks." } ] }, "rail_name": "Pix Returns (Devolucao)", "governing_authority": "Banco Central do Brasil", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "rtp-reject:1100", "id": "1100", "rail": "rtp-reject", "kind": "reason-code", "name": "Other reason, set out in the additional information", "group": "technical", "summary": "Any reason no ISO code covers, explained in the additional information. Not an ISO 20022 code: it is absent from ISO's status reason list, and Cross River Bank lists it among the codes TCH defines for RTP outside ISO. No public source read says whether the receiving participant or the RTP System sends it, so both are linked [Inference]; Cross River Bank places TCH's own codes at the network level, but a catch-all code may come from either side.", "triggers": [ "No specific code fits the reason for rejection" ], "actions": [ "Sending participant: read the additional information and act on what it says" ], "retry": { "allowed": true, "rule": "Depends on the reason given; the rejected payment never settled." }, "facts": { "return_windows": [ { "action": "reject", "by": "Receiving Participant", "deadline": "Within the response time the RTP Technical Specifications set; the figure is not in the public Operating Rules. If the receiving participant has not answered by then, TCH cancels the payment and tells both participants." }, { "action": "reject", "by": "RTP System", "deadline": "On receipt, before the RTP System releases the payment message to the receiving participant." } ], "applies_to": "an RTP credit transfer" }, "caveat": "Same code, different rail: FedNow, SEPA and other ISO 20022 rails use their own lists and meanings, so never carry a meaning over from them.", "related": [ "rtp-reject:NARR" ], "basis": { "sources": "Listed as an RTP reject code by the Cross River Bank request and response codes page (family A); the Cross River Bank error codes page, section on TCH's own RTP codes (family A); the Trice RTP system codes page (family B), all read 2026-09-19; the families agree on the meaning. ISO 20022 External Code Sets 2Q2026: not in ExternalStatusReason1Code. Reject mechanics from the TCH RTP Operating Rules effective 2026-06-01, Rules IV.A, V.C and V.E.3. No TCH code list was consulted: the permitted list sits in the RTP Technical Specifications, under terms Orca has not accepted.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: no public source dates it", "effective_to": null, "effective_note": "No public source read says when this code became permitted on RTP [Unverified]. The pages it rests on were published or updated between 2023 and 2026.", "source_edition": "RTP Message Specifications not consulted (terms not accepted); the record rests on public bank and processor pages read 2026-09-19, and on the RTP Operating Rules effective 2026-06-01 for how a reject works", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "primary_not_public": true, "corroboration": [ { "source_url": "https://docs.crossriver.com/apis/payments/instant-payments/error-codes-instant-payments", "source_class": "secondary", "source_title": "Error codes: Instant payments (Cross River Bank)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms 1100 is listed as an RTP reject code meaning any other reject reason given in the additional information." }, { "source_url": "https://triceapi.readme.io/reference/rtp-system-codes", "source_class": "secondary", "source_title": "RTP / FedNOW / ACH System Codes (Trice)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms 1100 is listed as an RTP reject code meaning any other reject reason given in the additional information." } ] }, "rail_name": "RTP Payment Rejects", "governing_authority": "The Clearing House", "snapshot": "2026-09-19", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for RTP credit transfer (pacs.008). Its own scope line reads: an RTP credit transfer.", "from": "applies_to" }, { "kind": "not_public", "label": "the operator's own text", "needs": "what the operator's own text says, which Orca has not read", "detail": "The Clearing House's own text is not the source for this code: it is not public, or not under terms Orca can use. It rests on 2 named public sources, so a term set by agreement rather than by a published rule is not Orca's to state.", "from": "currency.primary_not_public" } ] }, { "uid": "rtp-reject:9912", "id": "9912", "rail": "rtp-reject", "kind": "reason-code", "name": "Receiving participant unavailable", "group": "network", "summary": "The receiving participant cannot be reached. Not an ISO 20022 code: it is absent from ISO's status reason list, and Cross River Bank lists it among the codes TCH defines for RTP outside ISO. The RTP System sends it when it rejects at the network level; Cross River Bank says TCH's own codes come back from the network in a pacs.002, or an admi.002 for a technical rejection.", "triggers": [ "The receiving participant's connection to the network is down [Inference]" ], "actions": [ "Sender: wait and send a new payment later, or pay by another rail" ], "retry": { "allowed": true, "rule": "Only as a new payment message, and only once the participant or service is available again [Inference]; the rejected payment never settled." }, "facts": { "return_windows": [ { "action": "reject", "by": "RTP System", "deadline": "On receipt, before the RTP System releases the payment message to the receiving participant." } ], "applies_to": "an RTP credit transfer" }, "caveat": "Same code, different rail: FedNow, SEPA and other ISO 20022 rails use their own lists and meanings, so never carry a meaning over from them.", "related": [], "basis": { "sources": "Listed as an RTP reject code by the Cross River Bank request and response codes page (family A); the Cross River Bank error codes page, section on TCH's own RTP codes (family A); the Trice RTP system codes page (family B), all read 2026-09-19; the families agree on the meaning. ISO 20022 External Code Sets 2Q2026: not in ExternalStatusReason1Code. Reject mechanics from the TCH RTP Operating Rules effective 2026-06-01, Rules IV.A, V.C and V.E.3. No TCH code list was consulted: the permitted list sits in the RTP Technical Specifications, under terms Orca has not accepted.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: no public source dates it", "effective_to": null, "effective_note": "No public source read says when this code became permitted on RTP [Unverified]. The pages it rests on were published or updated between 2023 and 2026.", "source_edition": "RTP Message Specifications not consulted (terms not accepted); the record rests on public bank and processor pages read 2026-09-19, and on the RTP Operating Rules effective 2026-06-01 for how a reject works", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "primary_not_public": true, "corroboration": [ { "source_url": "https://docs.crossriver.com/apis/payments/instant-payments/error-codes-instant-payments", "source_class": "secondary", "source_title": "Error codes: Instant payments (Cross River Bank)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms 9912 is listed as an RTP reject code meaning the receiving participant is unavailable." }, { "source_url": "https://triceapi.readme.io/reference/rtp-system-codes", "source_class": "secondary", "source_title": "RTP / FedNOW / ACH System Codes (Trice)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms 9912 is listed as an RTP reject code meaning the receiving participant is unavailable." } ] }, "rail_name": "RTP Payment Rejects", "governing_authority": "The Clearing House", "snapshot": "2026-09-19", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for RTP credit transfer (pacs.008). Its own scope line reads: an RTP credit transfer.", "from": "applies_to" }, { "kind": "not_public", "label": "the operator's own text", "needs": "what the operator's own text says, which Orca has not read", "detail": "The Clearing House's own text is not the source for this code: it is not public, or not under terms Orca can use. It rests on 2 named public sources, so a term set by agreement rather than by a published rule is not Orca's to state.", "from": "currency.primary_not_public" } ] }, { "uid": "rtp-reject:9914", "id": "9914", "rail": "rtp-reject", "kind": "reason-code", "name": "Element required for Zelle payments missing", "group": "technical", "summary": "A message element that is mandatory when the payment is marked as a Zelle payment is missing. Not an ISO 20022 code: it is absent from ISO's status reason list, and Cross River Bank lists it among the codes TCH defines for RTP outside ISO. The RTP System sends it when it rejects at the network level; Cross River Bank says TCH's own codes come back from the network in a pacs.002, or an admi.002 for a technical rejection.", "triggers": [ "A payment marked for Zelle left out an element Zelle payments must carry" ], "actions": [ "Sending participant: complete the element and send a new payment" ], "retry": { "allowed": true, "rule": "Send a new payment message once the fault is fixed; the rejected payment never settled, so there is nothing to reverse or return." }, "facts": { "return_windows": [ { "action": "reject", "by": "RTP System", "deadline": "On receipt, before the RTP System releases the payment message to the receiving participant." } ], "applies_to": "an RTP credit transfer" }, "caveat": "Same code, different rail: FedNow, SEPA and other ISO 20022 rails use their own lists and meanings, so never carry a meaning over from them.", "related": [], "basis": { "sources": "Listed as an RTP reject code by the Cross River Bank error codes page, section on TCH's own RTP codes (family A); the Trice RTP system codes page (family B), all read 2026-09-19; the families agree on the meaning. ISO 20022 External Code Sets 2Q2026: not in ExternalStatusReason1Code. Reject mechanics from the TCH RTP Operating Rules effective 2026-06-01, Rules IV.A, V.C and V.E.3. No TCH code list was consulted: the permitted list sits in the RTP Technical Specifications, under terms Orca has not accepted.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: no public source dates it", "effective_to": null, "effective_note": "No public source read says when this code became permitted on RTP [Unverified]. The pages it rests on were published or updated between 2023 and 2026.", "source_edition": "RTP Message Specifications not consulted (terms not accepted); the record rests on public bank and processor pages read 2026-09-19, and on the RTP Operating Rules effective 2026-06-01 for how a reject works", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "primary_not_public": true, "corroboration": [ { "source_url": "https://docs.crossriver.com/apis/payments/instant-payments/error-codes-instant-payments", "source_class": "secondary", "source_title": "Error codes: Instant payments (Cross River Bank)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms 9914 is listed as an RTP reject code meaning an element required for Zelle payments is missing." }, { "source_url": "https://triceapi.readme.io/reference/rtp-system-codes", "source_class": "secondary", "source_title": "RTP / FedNOW / ACH System Codes (Trice)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms 9914 is listed as an RTP reject code meaning an element required for Zelle payments is missing." } ] }, "rail_name": "RTP Payment Rejects", "governing_authority": "The Clearing House", "snapshot": "2026-09-19", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for RTP credit transfer (pacs.008). Its own scope line reads: an RTP credit transfer.", "from": "applies_to" }, { "kind": "not_public", "label": "the operator's own text", "needs": "what the operator's own text says, which Orca has not read", "detail": "The Clearing House's own text is not the source for this code: it is not public, or not under terms Orca can use. It rests on 2 named public sources, so a term set by agreement rather than by a published rule is not Orca's to state.", "from": "currency.primary_not_public" } ] }, { "uid": "rtp-reject:9934", "id": "9934", "rail": "rtp-reject", "kind": "reason-code", "name": "Instructing agent signed off", "group": "network", "summary": "The instructing agent, the participant that sent the message into the network, is signed off. Not an ISO 20022 code: it is absent from ISO's status reason list, and Cross River Bank lists it among the codes TCH defines for RTP outside ISO. The RTP System sends it when it rejects at the network level; Cross River Bank says TCH's own codes come back from the network in a pacs.002, or an admi.002 for a technical rejection.", "triggers": [ "The sending participant or its service provider has signed off from the network [Inference]" ], "actions": [ "Sending participant: sign back on before sending a new payment" ], "retry": { "allowed": true, "rule": "Only as a new payment message, and only once the participant or service is available again [Inference]; the rejected payment never settled." }, "facts": { "return_windows": [ { "action": "reject", "by": "RTP System", "deadline": "On receipt, before the RTP System releases the payment message to the receiving participant." } ], "applies_to": "an RTP credit transfer" }, "caveat": "Same code, different rail: FedNow, SEPA and other ISO 20022 rails use their own lists and meanings, so never carry a meaning over from them.", "related": [], "basis": { "sources": "Listed as an RTP reject code by the Cross River Bank request and response codes page (family A); the Cross River Bank error codes page, section on TCH's own RTP codes (family A); the Trice RTP system codes page (family B), all read 2026-09-19; the families agree on the meaning. ISO 20022 External Code Sets 2Q2026: not in ExternalStatusReason1Code. Reject mechanics from the TCH RTP Operating Rules effective 2026-06-01, Rules IV.A, V.C and V.E.3. No TCH code list was consulted: the permitted list sits in the RTP Technical Specifications, under terms Orca has not accepted.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: no public source dates it", "effective_to": null, "effective_note": "No public source read says when this code became permitted on RTP [Unverified]. The pages it rests on were published or updated between 2023 and 2026.", "source_edition": "RTP Message Specifications not consulted (terms not accepted); the record rests on public bank and processor pages read 2026-09-19, and on the RTP Operating Rules effective 2026-06-01 for how a reject works", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "primary_not_public": true, "corroboration": [ { "source_url": "https://docs.crossriver.com/apis/payments/instant-payments/error-codes-instant-payments", "source_class": "secondary", "source_title": "Error codes: Instant payments (Cross River Bank)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms 9934 is listed as an RTP reject code meaning the instructing agent has signed off." }, { "source_url": "https://triceapi.readme.io/reference/rtp-system-codes", "source_class": "secondary", "source_title": "RTP / FedNOW / ACH System Codes (Trice)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms 9934 is listed as an RTP reject code meaning the instructing agent has signed off." } ] }, "rail_name": "RTP Payment Rejects", "governing_authority": "The Clearing House", "snapshot": "2026-09-19", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for RTP credit transfer (pacs.008). Its own scope line reads: an RTP credit transfer.", "from": "applies_to" }, { "kind": "not_public", "label": "the operator's own text", "needs": "what the operator's own text says, which Orca has not read", "detail": "The Clearing House's own text is not the source for this code: it is not public, or not under terms Orca can use. It rests on 2 named public sources, so a term set by agreement rather than by a published rule is not Orca's to state.", "from": "currency.primary_not_public" } ] }, { "uid": "rtp-reject:9946", "id": "9946", "rail": "rtp-reject", "kind": "reason-code", "name": "Instructing agent suspended", "group": "network", "summary": "The instructing agent, the participant that sent the message, is suspended. Not an ISO 20022 code: it is absent from ISO's status reason list, and Cross River Bank lists it among the codes TCH defines for RTP outside ISO. The RTP System sends it when it rejects at the network level; Cross River Bank says TCH's own codes come back from the network in a pacs.002, or an admi.002 for a technical rejection.", "triggers": [ "TCH has suspended the sending participant [Inference]" ], "actions": [ "Sending participant: resolve the suspension with TCH before sending again" ], "retry": { "allowed": true, "rule": "Only as a new payment message, and only once the participant or service is available again [Inference]; the rejected payment never settled." }, "facts": { "return_windows": [ { "action": "reject", "by": "RTP System", "deadline": "On receipt, before the RTP System releases the payment message to the receiving participant." } ], "applies_to": "an RTP credit transfer" }, "caveat": "Same code, different rail: FedNow, SEPA and other ISO 20022 rails use their own lists and meanings, so never carry a meaning over from them.", "related": [ "rtp-reject:9947" ], "basis": { "sources": "Listed as an RTP reject code by the Cross River Bank request and response codes page (family A); the Cross River Bank error codes page, section on TCH's own RTP codes (family A); the Trice RTP system codes page (family B), all read 2026-09-19; the families agree on the meaning. ISO 20022 External Code Sets 2Q2026: not in ExternalStatusReason1Code. Reject mechanics from the TCH RTP Operating Rules effective 2026-06-01, Rules IV.A, V.C and V.E.3. No TCH code list was consulted: the permitted list sits in the RTP Technical Specifications, under terms Orca has not accepted.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: no public source dates it", "effective_to": null, "effective_note": "No public source read says when this code became permitted on RTP [Unverified]. The pages it rests on were published or updated between 2023 and 2026.", "source_edition": "RTP Message Specifications not consulted (terms not accepted); the record rests on public bank and processor pages read 2026-09-19, and on the RTP Operating Rules effective 2026-06-01 for how a reject works", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "primary_not_public": true, "corroboration": [ { "source_url": "https://docs.crossriver.com/apis/payments/instant-payments/error-codes-instant-payments", "source_class": "secondary", "source_title": "Error codes: Instant payments (Cross River Bank)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms 9946 is listed as an RTP reject code meaning the instructing agent is suspended." }, { "source_url": "https://triceapi.readme.io/reference/rtp-system-codes", "source_class": "secondary", "source_title": "RTP / FedNOW / ACH System Codes (Trice)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms 9946 is listed as an RTP reject code meaning the instructing agent is suspended." } ] }, "rail_name": "RTP Payment Rejects", "governing_authority": "The Clearing House", "snapshot": "2026-09-19", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for RTP credit transfer (pacs.008). Its own scope line reads: an RTP credit transfer.", "from": "applies_to" }, { "kind": "not_public", "label": "the operator's own text", "needs": "what the operator's own text says, which Orca has not read", "detail": "The Clearing House's own text is not the source for this code: it is not public, or not under terms Orca can use. It rests on 2 named public sources, so a term set by agreement rather than by a published rule is not Orca's to state.", "from": "currency.primary_not_public" } ] }, { "uid": "rtp-reject:9947", "id": "9947", "rail": "rtp-reject", "kind": "reason-code", "name": "Instructed agent suspended", "group": "network", "summary": "The instructed agent, the participant the message is going to, is suspended. Not an ISO 20022 code: it is absent from ISO's status reason list, and Cross River Bank lists it among the codes TCH defines for RTP outside ISO. The RTP System sends it when it rejects at the network level; Cross River Bank says TCH's own codes come back from the network in a pacs.002, or an admi.002 for a technical rejection.", "triggers": [ "TCH has suspended the receiving participant [Inference]" ], "actions": [ "Sender: pay by another rail until the receiving participant is reinstated" ], "retry": { "allowed": true, "rule": "Only as a new payment message, and only once the participant or service is available again [Inference]; the rejected payment never settled." }, "facts": { "return_windows": [ { "action": "reject", "by": "RTP System", "deadline": "On receipt, before the RTP System releases the payment message to the receiving participant." } ], "applies_to": "an RTP credit transfer" }, "caveat": "Same code, different rail: FedNow, SEPA and other ISO 20022 rails use their own lists and meanings, so never carry a meaning over from them.", "related": [ "rtp-reject:9946" ], "basis": { "sources": "Listed as an RTP reject code by the Cross River Bank request and response codes page (family A); the Cross River Bank error codes page, section on TCH's own RTP codes (family A); the Trice RTP system codes page (family B), all read 2026-09-19; the families agree on the meaning. ISO 20022 External Code Sets 2Q2026: not in ExternalStatusReason1Code. Reject mechanics from the TCH RTP Operating Rules effective 2026-06-01, Rules IV.A, V.C and V.E.3. No TCH code list was consulted: the permitted list sits in the RTP Technical Specifications, under terms Orca has not accepted.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: no public source dates it", "effective_to": null, "effective_note": "No public source read says when this code became permitted on RTP [Unverified]. The pages it rests on were published or updated between 2023 and 2026.", "source_edition": "RTP Message Specifications not consulted (terms not accepted); the record rests on public bank and processor pages read 2026-09-19, and on the RTP Operating Rules effective 2026-06-01 for how a reject works", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "primary_not_public": true, "corroboration": [ { "source_url": "https://docs.crossriver.com/apis/payments/instant-payments/error-codes-instant-payments", "source_class": "secondary", "source_title": "Error codes: Instant payments (Cross River Bank)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms 9947 is listed as an RTP reject code meaning the instructed agent is suspended." }, { "source_url": "https://triceapi.readme.io/reference/rtp-system-codes", "source_class": "secondary", "source_title": "RTP / FedNOW / ACH System Codes (Trice)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms 9947 is listed as an RTP reject code meaning the instructed agent is suspended." } ] }, "rail_name": "RTP Payment Rejects", "governing_authority": "The Clearing House", "snapshot": "2026-09-19", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for RTP credit transfer (pacs.008). Its own scope line reads: an RTP credit transfer.", "from": "applies_to" }, { "kind": "not_public", "label": "the operator's own text", "needs": "what the operator's own text says, which Orca has not read", "detail": "The Clearing House's own text is not the source for this code: it is not public, or not under terms Orca can use. It rests on 2 named public sources, so a term set by agreement rather than by a published rule is not Orca's to state.", "from": "currency.primary_not_public" } ] }, { "uid": "rtp-reject:9948", "id": "9948", "rail": "rtp-reject", "kind": "reason-code", "name": "Service suspended", "group": "network", "summary": "The service is suspended; Cross River Bank says it is the RTP central switch's service. Not an ISO 20022 code: it is absent from ISO's status reason list, and Cross River Bank lists it among the codes TCH defines for RTP outside ISO. The RTP System sends it when it rejects at the network level; Cross River Bank says TCH's own codes come back from the network in a pacs.002, or an admi.002 for a technical rejection.", "triggers": [ "TCH has suspended the service, for example in an emergency [Inference]" ], "actions": [ "Sender: pay by another rail or wait until the service is back" ], "retry": { "allowed": true, "rule": "Only as a new payment message, and only once the participant or service is available again [Inference]; the rejected payment never settled." }, "facts": { "return_windows": [ { "action": "reject", "by": "RTP System", "deadline": "On receipt, before the RTP System releases the payment message to the receiving participant." } ], "applies_to": "an RTP credit transfer" }, "caveat": "Same code, different rail: FedNow, SEPA and other ISO 20022 rails use their own lists and meanings, so never carry a meaning over from them.", "related": [], "basis": { "sources": "Listed as an RTP reject code by the Cross River Bank request and response codes page (family A); the Cross River Bank error codes page, section on TCH's own RTP codes (family A); the Trice RTP system codes page (family B), all read 2026-09-19; the families agree on the meaning. ISO 20022 External Code Sets 2Q2026: not in ExternalStatusReason1Code. Reject mechanics from the TCH RTP Operating Rules effective 2026-06-01, Rules IV.A, V.C and V.E.3. No TCH code list was consulted: the permitted list sits in the RTP Technical Specifications, under terms Orca has not accepted.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: no public source dates it", "effective_to": null, "effective_note": "No public source read says when this code became permitted on RTP [Unverified]. The pages it rests on were published or updated between 2023 and 2026.", "source_edition": "RTP Message Specifications not consulted (terms not accepted); the record rests on public bank and processor pages read 2026-09-19, and on the RTP Operating Rules effective 2026-06-01 for how a reject works", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "primary_not_public": true, "corroboration": [ { "source_url": "https://docs.crossriver.com/apis/payments/instant-payments/error-codes-instant-payments", "source_class": "secondary", "source_title": "Error codes: Instant payments (Cross River Bank)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms 9948 is listed as an RTP reject code meaning the service is suspended." }, { "source_url": "https://triceapi.readme.io/reference/rtp-system-codes", "source_class": "secondary", "source_title": "RTP / FedNOW / ACH System Codes (Trice)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms 9948 is listed as an RTP reject code meaning the service is suspended." } ] }, "rail_name": "RTP Payment Rejects", "governing_authority": "The Clearing House", "snapshot": "2026-09-19", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for RTP credit transfer (pacs.008). Its own scope line reads: an RTP credit transfer.", "from": "applies_to" }, { "kind": "not_public", "label": "the operator's own text", "needs": "what the operator's own text says, which Orca has not read", "detail": "The Clearing House's own text is not the source for this code: it is not public, or not under terms Orca can use. It rests on 2 named public sources, so a term set by agreement rather than by a published rule is not Orca's to state.", "from": "currency.primary_not_public" } ] }, { "uid": "rtp-reject:9952", "id": "9952", "rail": "rtp-reject", "kind": "reason-code", "name": "Message versions incompatible", "group": "technical", "summary": "The message versions used by the two sides cannot be mapped to each other. Not an ISO 20022 code: it is absent from ISO's status reason list, and Cross River Bank lists it among the codes TCH defines for RTP outside ISO. The RTP System sends it when it rejects at the network level; Cross River Bank says TCH's own codes come back from the network in a pacs.002, or an admi.002 for a technical rejection.", "triggers": [ "The sending and receiving sides use message versions the network cannot translate between [Inference]" ], "actions": [ "Sending participant: check which message version it sends and send a new payment" ], "retry": { "allowed": true, "rule": "Send a new payment message once the fault is fixed; the rejected payment never settled, so there is nothing to reverse or return." }, "facts": { "return_windows": [ { "action": "reject", "by": "RTP System", "deadline": "On receipt, before the RTP System releases the payment message to the receiving participant." } ], "applies_to": "an RTP credit transfer" }, "caveat": "Same code, different rail: FedNow, SEPA and other ISO 20022 rails use their own lists and meanings, so never carry a meaning over from them.", "related": [], "basis": { "sources": "Listed as an RTP reject code by the Cross River Bank error codes page, section on TCH's own RTP codes (family A); the Trice RTP system codes page (family B), all read 2026-09-19; the families agree on the meaning. ISO 20022 External Code Sets 2Q2026: not in ExternalStatusReason1Code. Reject mechanics from the TCH RTP Operating Rules effective 2026-06-01, Rules IV.A, V.C and V.E.3. No TCH code list was consulted: the permitted list sits in the RTP Technical Specifications, under terms Orca has not accepted.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: no public source dates it", "effective_to": null, "effective_note": "No public source read says when this code became permitted on RTP [Unverified]. The pages it rests on were published or updated between 2023 and 2026.", "source_edition": "RTP Message Specifications not consulted (terms not accepted); the record rests on public bank and processor pages read 2026-09-19, and on the RTP Operating Rules effective 2026-06-01 for how a reject works", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "primary_not_public": true, "corroboration": [ { "source_url": "https://docs.crossriver.com/apis/payments/instant-payments/error-codes-instant-payments", "source_class": "secondary", "source_title": "Error codes: Instant payments (Cross River Bank)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms 9952 is listed as an RTP reject code meaning message versions are incompatible." }, { "source_url": "https://triceapi.readme.io/reference/rtp-system-codes", "source_class": "secondary", "source_title": "RTP / FedNOW / ACH System Codes (Trice)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms 9952 is listed as an RTP reject code meaning message versions are incompatible." } ] }, "rail_name": "RTP Payment Rejects", "governing_authority": "The Clearing House", "snapshot": "2026-09-19", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for RTP credit transfer (pacs.008). Its own scope line reads: an RTP credit transfer.", "from": "applies_to" }, { "kind": "not_public", "label": "the operator's own text", "needs": "what the operator's own text says, which Orca has not read", "detail": "The Clearing House's own text is not the source for this code: it is not public, or not under terms Orca can use. It rests on 2 named public sources, so a term set by agreement rather than by a published rule is not Orca's to state.", "from": "currency.primary_not_public" } ] }, { "uid": "rtp-reject:9953", "id": "9953", "rail": "rtp-reject", "kind": "reason-code", "name": "Code for the full invoiced amount missing", "group": "technical", "summary": "The code that marks a full invoiced amount (FULL) is missing. Not an ISO 20022 code: it is absent from ISO's status reason list, and Cross River Bank lists it among the codes TCH defines for RTP outside ISO. The RTP System sends it when it rejects at the network level; Cross River Bank says TCH's own codes come back from the network in a pacs.002, or an admi.002 for a technical rejection.", "triggers": [ "A payment tied to an invoice or a request for payment left out the full amount code [Inference]" ], "actions": [ "Sending participant: add the code and send a new payment" ], "retry": { "allowed": true, "rule": "Send a new payment message once the fault is fixed; the rejected payment never settled, so there is nothing to reverse or return." }, "facts": { "return_windows": [ { "action": "reject", "by": "RTP System", "deadline": "On receipt, before the RTP System releases the payment message to the receiving participant." } ], "applies_to": "an RTP credit transfer" }, "caveat": "Same code, different rail: FedNow, SEPA and other ISO 20022 rails use their own lists and meanings, so never carry a meaning over from them.", "related": [], "basis": { "sources": "Listed as an RTP reject code by the Cross River Bank error codes page, section on TCH's own RTP codes (family A); the Trice RTP system codes page (family B), all read 2026-09-19; the families agree on the meaning. ISO 20022 External Code Sets 2Q2026: not in ExternalStatusReason1Code. Reject mechanics from the TCH RTP Operating Rules effective 2026-06-01, Rules IV.A, V.C and V.E.3. No TCH code list was consulted: the permitted list sits in the RTP Technical Specifications, under terms Orca has not accepted.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: no public source dates it", "effective_to": null, "effective_note": "No public source read says when this code became permitted on RTP [Unverified]. The pages it rests on were published or updated between 2023 and 2026.", "source_edition": "RTP Message Specifications not consulted (terms not accepted); the record rests on public bank and processor pages read 2026-09-19, and on the RTP Operating Rules effective 2026-06-01 for how a reject works", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "primary_not_public": true, "corroboration": [ { "source_url": "https://docs.crossriver.com/apis/payments/instant-payments/error-codes-instant-payments", "source_class": "secondary", "source_title": "Error codes: Instant payments (Cross River Bank)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms 9953 is listed as an RTP reject code meaning the code for the full invoiced amount is missing." }, { "source_url": "https://triceapi.readme.io/reference/rtp-system-codes", "source_class": "secondary", "source_title": "RTP / FedNOW / ACH System Codes (Trice)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms 9953 is listed as an RTP reject code meaning the code for the full invoiced amount is missing." } ] }, "rail_name": "RTP Payment Rejects", "governing_authority": "The Clearing House", "snapshot": "2026-09-19", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for RTP credit transfer (pacs.008). Its own scope line reads: an RTP credit transfer.", "from": "applies_to" }, { "kind": "not_public", "label": "the operator's own text", "needs": "what the operator's own text says, which Orca has not read", "detail": "The Clearing House's own text is not the source for this code: it is not public, or not under terms Orca can use. It rests on 2 named public sources, so a term set by agreement rather than by a published rule is not Orca's to state.", "from": "currency.primary_not_public" } ] }, { "uid": "rtp-reject:9956", "id": "9956", "rail": "rtp-reject", "kind": "reason-code", "name": "Instructing agent's funding account suspended", "group": "network", "summary": "The funding account of the instructing agent, the participant that sent the message, is suspended. Not an ISO 20022 code: it is absent from ISO's status reason list, and Cross River Bank lists it among the codes TCH defines for RTP outside ISO. The RTP System sends it when it rejects at the network level; Cross River Bank says TCH's own codes come back from the network in a pacs.002, or an admi.002 for a technical rejection.", "triggers": [ "The sending participant's funding arrangement is suspended [Inference]" ], "actions": [ "Sending participant: sort out its funding arrangement with TCH before sending again [Inference]" ], "retry": { "allowed": true, "rule": "Only as a new payment message, and only once the participant or service is available again [Inference]; the rejected payment never settled." }, "facts": { "return_windows": [ { "action": "reject", "by": "RTP System", "deadline": "On receipt, before the RTP System releases the payment message to the receiving participant." } ], "applies_to": "an RTP credit transfer" }, "caveat": "Same code, different rail: FedNow, SEPA and other ISO 20022 rails use their own lists and meanings, so never carry a meaning over from them.", "related": [ "rtp-reject:9946" ], "basis": { "sources": "Listed as an RTP reject code by the Cross River Bank error codes page, section on TCH's own RTP codes (family A); the Trice RTP system codes page (family B), all read 2026-09-19; the families agree on the meaning. ISO 20022 External Code Sets 2Q2026: not in ExternalStatusReason1Code. Reject mechanics from the TCH RTP Operating Rules effective 2026-06-01, Rules IV.A, V.C and V.E.3. No TCH code list was consulted: the permitted list sits in the RTP Technical Specifications, under terms Orca has not accepted.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: no public source dates it", "effective_to": null, "effective_note": "No public source read says when this code became permitted on RTP [Unverified]. The pages it rests on were published or updated between 2023 and 2026.", "source_edition": "RTP Message Specifications not consulted (terms not accepted); the record rests on public bank and processor pages read 2026-09-19, and on the RTP Operating Rules effective 2026-06-01 for how a reject works", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "primary_not_public": true, "corroboration": [ { "source_url": "https://docs.crossriver.com/apis/payments/instant-payments/error-codes-instant-payments", "source_class": "secondary", "source_title": "Error codes: Instant payments (Cross River Bank)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms 9956 is listed as an RTP reject code meaning the instructing agent's funding account is suspended." }, { "source_url": "https://triceapi.readme.io/reference/rtp-system-codes", "source_class": "secondary", "source_title": "RTP / FedNOW / ACH System Codes (Trice)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms 9956 is listed as an RTP reject code meaning the instructing agent's funding account is suspended." } ] }, "rail_name": "RTP Payment Rejects", "governing_authority": "The Clearing House", "snapshot": "2026-09-19", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for RTP credit transfer (pacs.008). Its own scope line reads: an RTP credit transfer.", "from": "applies_to" }, { "kind": "not_public", "label": "the operator's own text", "needs": "what the operator's own text says, which Orca has not read", "detail": "The Clearing House's own text is not the source for this code: it is not public, or not under terms Orca can use. It rests on 2 named public sources, so a term set by agreement rather than by a published rule is not Orca's to state.", "from": "currency.primary_not_public" } ] }, { "uid": "rtp-reject:9957", "id": "9957", "rail": "rtp-reject", "kind": "reason-code", "name": "Instructed agent's funding account suspended", "group": "network", "summary": "The funding account of the instructed agent, the participant the message is going to, is suspended. Not an ISO 20022 code: it is absent from ISO's status reason list, and Cross River Bank lists it among the codes TCH defines for RTP outside ISO. The RTP System sends it when it rejects at the network level; Cross River Bank says TCH's own codes come back from the network in a pacs.002, or an admi.002 for a technical rejection.", "triggers": [ "The receiving participant's funding arrangement is suspended [Inference]" ], "actions": [ "Sender: pay by another rail until the receiving participant's funding is restored" ], "retry": { "allowed": true, "rule": "Only as a new payment message, and only once the participant or service is available again [Inference]; the rejected payment never settled." }, "facts": { "return_windows": [ { "action": "reject", "by": "RTP System", "deadline": "On receipt, before the RTP System releases the payment message to the receiving participant." } ], "applies_to": "an RTP credit transfer" }, "caveat": "Same code, different rail: FedNow, SEPA and other ISO 20022 rails use their own lists and meanings, so never carry a meaning over from them.", "related": [ "rtp-reject:9946" ], "basis": { "sources": "Listed as an RTP reject code by the Cross River Bank error codes page, section on TCH's own RTP codes (family A); the Trice RTP system codes page (family B), all read 2026-09-19; the families agree on the meaning. ISO 20022 External Code Sets 2Q2026: not in ExternalStatusReason1Code. Reject mechanics from the TCH RTP Operating Rules effective 2026-06-01, Rules IV.A, V.C and V.E.3. No TCH code list was consulted: the permitted list sits in the RTP Technical Specifications, under terms Orca has not accepted.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: no public source dates it", "effective_to": null, "effective_note": "No public source read says when this code became permitted on RTP [Unverified]. The pages it rests on were published or updated between 2023 and 2026.", "source_edition": "RTP Message Specifications not consulted (terms not accepted); the record rests on public bank and processor pages read 2026-09-19, and on the RTP Operating Rules effective 2026-06-01 for how a reject works", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "primary_not_public": true, "corroboration": [ { "source_url": "https://docs.crossriver.com/apis/payments/instant-payments/error-codes-instant-payments", "source_class": "secondary", "source_title": "Error codes: Instant payments (Cross River Bank)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms 9957 is listed as an RTP reject code meaning the instructed agent's funding account is suspended." }, { "source_url": "https://triceapi.readme.io/reference/rtp-system-codes", "source_class": "secondary", "source_title": "RTP / FedNOW / ACH System Codes (Trice)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms 9957 is listed as an RTP reject code meaning the instructed agent's funding account is suspended." } ] }, "rail_name": "RTP Payment Rejects", "governing_authority": "The Clearing House", "snapshot": "2026-09-19", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for RTP credit transfer (pacs.008). Its own scope line reads: an RTP credit transfer.", "from": "applies_to" }, { "kind": "not_public", "label": "the operator's own text", "needs": "what the operator's own text says, which Orca has not read", "detail": "The Clearing House's own text is not the source for this code: it is not public, or not under terms Orca can use. It rests on 2 named public sources, so a term set by agreement rather than by a published rule is not Orca's to state.", "from": "currency.primary_not_public" } ] }, { "uid": "rtp-reject:9964", "id": "9964", "rail": "rtp-reject", "kind": "reason-code", "name": "Participant identification invalid", "group": "technical", "summary": "A participant identification in the message is invalid. Not an ISO 20022 code: it is absent from ISO's status reason list, and Cross River Bank lists it among the codes TCH defines for RTP outside ISO. The RTP System sends it when it rejects at the network level; Cross River Bank says TCH's own codes come back from the network in a pacs.002, or an admi.002 for a technical rejection.", "triggers": [ "A participant identifier is wrong or not registered with the network [Inference]" ], "actions": [ "Sending participant: correct the participant identification and send a new payment" ], "retry": { "allowed": true, "rule": "Send a new payment message once the fault is fixed; the rejected payment never settled, so there is nothing to reverse or return." }, "facts": { "return_windows": [ { "action": "reject", "by": "RTP System", "deadline": "On receipt, before the RTP System releases the payment message to the receiving participant." } ], "applies_to": "an RTP credit transfer" }, "caveat": "Same code, different rail: FedNow, SEPA and other ISO 20022 rails use their own lists and meanings, so never carry a meaning over from them.", "related": [], "basis": { "sources": "Listed as an RTP reject code by the Cross River Bank error codes page, section on TCH's own RTP codes (family A); the Trice RTP system codes page (family B), all read 2026-09-19; the families agree on the meaning. ISO 20022 External Code Sets 2Q2026: not in ExternalStatusReason1Code. Reject mechanics from the TCH RTP Operating Rules effective 2026-06-01, Rules IV.A, V.C and V.E.3. No TCH code list was consulted: the permitted list sits in the RTP Technical Specifications, under terms Orca has not accepted.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: no public source dates it", "effective_to": null, "effective_note": "No public source read says when this code became permitted on RTP [Unverified]. The pages it rests on were published or updated between 2023 and 2026.", "source_edition": "RTP Message Specifications not consulted (terms not accepted); the record rests on public bank and processor pages read 2026-09-19, and on the RTP Operating Rules effective 2026-06-01 for how a reject works", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "primary_not_public": true, "corroboration": [ { "source_url": "https://docs.crossriver.com/apis/payments/instant-payments/error-codes-instant-payments", "source_class": "secondary", "source_title": "Error codes: Instant payments (Cross River Bank)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms 9964 is listed as an RTP reject code meaning the participant identification is invalid." }, { "source_url": "https://triceapi.readme.io/reference/rtp-system-codes", "source_class": "secondary", "source_title": "RTP / FedNOW / ACH System Codes (Trice)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms 9964 is listed as an RTP reject code meaning the participant identification is invalid." } ] }, "rail_name": "RTP Payment Rejects", "governing_authority": "The Clearing House", "snapshot": "2026-09-19", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for RTP credit transfer (pacs.008). Its own scope line reads: an RTP credit transfer.", "from": "applies_to" }, { "kind": "not_public", "label": "the operator's own text", "needs": "what the operator's own text says, which Orca has not read", "detail": "The Clearing House's own text is not the source for this code: it is not public, or not under terms Orca can use. It rests on 2 named public sources, so a term set by agreement rather than by a published rule is not Orca's to state.", "from": "currency.primary_not_public" } ] }, { "uid": "rtp-reject:AC02", "id": "AC02", "rail": "rtp-reject", "kind": "reason-code", "name": "Sender's account number wrong or missing", "group": "account", "summary": "The account number given for the sender (the debtor, in ISO terms) is wrong or missing. An ISO 20022 status reason code (ExternalStatusReason1Code). The meaning given is the one the public bank and processor pages agree on for RTP; ISO's generic definition is a fallback only where they say nothing more. No public source read says whether the receiving participant or the RTP System sends it, so both are linked [Inference]; a receiving participant has little reason to check the sender's account, so a sending side or network check is more likely.", "triggers": [ "The sender's account number was mistyped or left out when the message was built", "The sending participant's system mapped the account field wrongly [Inference]" ], "actions": [ "Sending participant: check the sender's account number in the message against its own records, correct it and send a new payment" ], "retry": { "allowed": true, "rule": "Send a new payment message once the fault is fixed; the rejected payment never settled, so there is nothing to reverse or return." }, "facts": { "return_windows": [ { "action": "reject", "by": "Receiving Participant", "deadline": "Within the response time the RTP Technical Specifications set; the figure is not in the public Operating Rules. If the receiving participant has not answered by then, TCH cancels the payment and tells both participants." }, { "action": "reject", "by": "RTP System", "deadline": "On receipt, before the RTP System releases the payment message to the receiving participant." } ], "applies_to": "an RTP credit transfer" }, "caveat": "Same code, different rail: FedNow, SEPA and other ISO 20022 rails use their own lists and meanings, so never carry a meaning over from them.", "related": [ "rtp-reject:AC13", "rtp-reject:AC03" ], "basis": { "sources": "Listed as an RTP reject code by the Cross River Bank request and response codes page (family A); the Trice RTP system codes page (family B); the CU*Answers RTP Return Codes PDF, Appendix B (family C), all read 2026-09-19; the families agree on the meaning. ISO 20022 External Code Sets 2Q2026: in ExternalStatusReason1Code. Reject mechanics from the TCH RTP Operating Rules effective 2026-06-01, Rules IV.A, V.C and V.E.3. No TCH code list was consulted: the permitted list sits in the RTP Technical Specifications, under terms Orca has not accepted.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: no public source dates it", "effective_to": null, "effective_note": "No public source read says when this code became permitted on RTP [Unverified]. The pages it rests on were published or updated between 2023 and 2026.", "source_edition": "RTP Message Specifications not consulted (terms not accepted); the record rests on public bank and processor pages read 2026-09-19, and on the RTP Operating Rules effective 2026-06-01 for how a reject works", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "primary_not_public": true, "corroboration": [ { "source_url": "https://triceapi.readme.io/reference/rtp-system-codes", "source_class": "secondary", "source_title": "RTP / FedNOW / ACH System Codes (Trice)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms AC02 is listed as an RTP reject code meaning the sender's account number is wrong or missing." }, { "source_url": "https://www.cuanswers.com/wp-content/uploads/Return-Codes.pdf", "source_class": "secondary", "source_title": "RTP Return Codes (CU*Answers)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms AC02 is listed as an RTP reject code meaning the sender's account number is wrong or missing." } ] }, "rail_name": "RTP Payment Rejects", "governing_authority": "The Clearing House", "snapshot": "2026-09-19", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for RTP credit transfer (pacs.008). Its own scope line reads: an RTP credit transfer.", "from": "applies_to" }, { "kind": "not_public", "label": "the operator's own text", "needs": "what the operator's own text says, which Orca has not read", "detail": "The Clearing House's own text is not the source for this code: it is not public, or not under terms Orca can use. It rests on 2 named public sources, so a term set by agreement rather than by a published rule is not Orca's to state.", "from": "currency.primary_not_public" } ] }, { "uid": "rtp-reject:AC03", "id": "AC03", "rail": "rtp-reject", "kind": "reason-code", "name": "Receiver's account number wrong or missing", "group": "account", "summary": "The account number given for the receiver (the creditor, in ISO terms) is wrong, missing, or matches no account at the receiving participant. An ISO 20022 status reason code (ExternalStatusReason1Code). The meaning given is the one the public bank and processor pages agree on for RTP; ISO's generic definition is a fallback only where they say nothing more. The receiving participant sends it in its reject response [Inference: the Oracle page marks it as used by the FI only, and Rule V.C lets the receiving participant reject for reasons tied to the receiver's account].", "triggers": [ "A digit was mistyped or dropped in the receiver's account number", "An alias or directory lookup returned stale account details [Inference]", "The account number belongs to another bank than the routing number named" ], "actions": [ "Sender: confirm the account number with the receiver before sending again", "Sending participant: if the number came from a directory keyed on email, phone or another alias, check that entry, since Rule III.F expects risk management over such directories" ], "retry": { "allowed": true, "rule": "Send a new payment message once the fault is fixed; the rejected payment never settled, so there is nothing to reverse or return." }, "facts": { "return_windows": [ { "action": "reject", "by": "Receiving Participant", "deadline": "Within the response time the RTP Technical Specifications set; the figure is not in the public Operating Rules. If the receiving participant has not answered by then, TCH cancels the payment and tells both participants." } ], "applies_to": "an RTP credit transfer" }, "caveat": "Do not use payment messages to test whether account numbers are valid: the Operating Rules allow that only for a number the intended receiver gave the sender (II.E.1). Same code, different rail: FedNow, SEPA and other ISO 20022 rails use their own lists and meanings, so never carry a meaning over from them.", "related": [ "rtp-reject:AC04", "rtp-reject:AC07", "rtp-reject:AC14", "rtp-reject:BE06", "rtp-reject:AC02" ], "basis": { "sources": "Listed as an RTP reject code by the Cross River Bank request and response codes page (family A); the Trice RTP system codes page (family B); the CU*Answers RTP Return Codes PDF, Appendix B (family C); the Oracle US RTP reason code mapping page (family D), all read 2026-09-19; the families agree on the meaning. ISO 20022 External Code Sets 2Q2026: in ExternalStatusReason1Code. Reject mechanics from the TCH RTP Operating Rules effective 2026-06-01, Rules IV.A, V.C and V.E.3. No TCH code list was consulted: the permitted list sits in the RTP Technical Specifications, under terms Orca has not accepted.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: no public source dates it", "effective_to": null, "effective_note": "No public source read says when this code became permitted on RTP [Unverified]. The pages it rests on were published or updated between 2023 and 2026.", "source_edition": "RTP Message Specifications not consulted (terms not accepted); the record rests on public bank and processor pages read 2026-09-19, and on the RTP Operating Rules effective 2026-06-01 for how a reject works", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "primary_not_public": true, "corroboration": [ { "source_url": "https://triceapi.readme.io/reference/rtp-system-codes", "source_class": "secondary", "source_title": "RTP / FedNOW / ACH System Codes (Trice)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms AC03 is listed as an RTP reject code meaning the receiver's account number is wrong or missing." }, { "source_url": "https://www.cuanswers.com/wp-content/uploads/Return-Codes.pdf", "source_class": "secondary", "source_title": "RTP Return Codes (CU*Answers)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms AC03 is listed as an RTP reject code meaning the receiver's account number is wrong or missing." } ] }, "rail_name": "RTP Payment Rejects", "governing_authority": "The Clearing House", "snapshot": "2026-09-19", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for RTP credit transfer (pacs.008). Its own scope line reads: an RTP credit transfer.", "from": "applies_to" }, { "kind": "not_public", "label": "the operator's own text", "needs": "what the operator's own text says, which Orca has not read", "detail": "The Clearing House's own text is not the source for this code: it is not public, or not under terms Orca can use. It rests on 2 named public sources, so a term set by agreement rather than by a published rule is not Orca's to state.", "from": "currency.primary_not_public" } ] }, { "uid": "rtp-reject:AC04", "id": "AC04", "rail": "rtp-reject", "kind": "reason-code", "name": "Receiver's account closed", "group": "account", "summary": "The receiver's account at the receiving participant is closed. An ISO 20022 status reason code (ExternalStatusReason1Code). The meaning given is the one the public bank and processor pages agree on for RTP; ISO's generic definition is a fallback only where they say nothing more. The receiving participant sends it in its reject response [Inference: Rule V.C.1 lets the receiving participant reject when the receiver's account is closed].", "triggers": [ "The receiver closed the account and the sender still holds the old details", "The receiving participant closed the account, for example after unauthorized activity [Inference]" ], "actions": [ "Sender: get current account details from the receiver", "Receiving participant: reject a new payment to a closed account rather than accepting it without posting; accepting without posting is kept for money coming back to a closed account after a request for return (Rule V.E.2.a.ii)" ], "retry": { "allowed": false, "rule": "Do not send again to the same account. Get new account details from the receiver and send a new payment." }, "facts": { "return_windows": [ { "action": "reject", "by": "Receiving Participant", "deadline": "Within the response time the RTP Technical Specifications set; the figure is not in the public Operating Rules. If the receiving participant has not answered by then, TCH cancels the payment and tells both participants." } ], "applies_to": "an RTP credit transfer" }, "caveat": "The sources list both AC04 and AC07 for a closed account on RTP; none says when a participant should pick one over the other [Unverified]. Same code, different rail: FedNow, SEPA and other ISO 20022 rails use their own lists and meanings, so never carry a meaning over from them.", "related": [ "rtp-reject:AC07", "rtp-reject:AC03" ], "basis": { "sources": "Listed as an RTP reject code by the Cross River Bank request and response codes page (family A); the Trice RTP system codes page (family B); the CU*Answers RTP Return Codes PDF, Appendix B (family C), all read 2026-09-19; the families agree on the meaning. ISO 20022 External Code Sets 2Q2026: in ExternalStatusReason1Code. Reject mechanics from the TCH RTP Operating Rules effective 2026-06-01, Rules IV.A, V.C and V.E.3. No TCH code list was consulted: the permitted list sits in the RTP Technical Specifications, under terms Orca has not accepted.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: no public source dates it", "effective_to": null, "effective_note": "No public source read says when this code became permitted on RTP [Unverified]. The pages it rests on were published or updated between 2023 and 2026.", "source_edition": "RTP Message Specifications not consulted (terms not accepted); the record rests on public bank and processor pages read 2026-09-19, and on the RTP Operating Rules effective 2026-06-01 for how a reject works", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "primary_not_public": true, "corroboration": [ { "source_url": "https://triceapi.readme.io/reference/rtp-system-codes", "source_class": "secondary", "source_title": "RTP / FedNOW / ACH System Codes (Trice)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms AC04 is listed as an RTP reject code meaning the receiver's account is closed." }, { "source_url": "https://www.cuanswers.com/wp-content/uploads/Return-Codes.pdf", "source_class": "secondary", "source_title": "RTP Return Codes (CU*Answers)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms AC04 is listed as an RTP reject code meaning the receiver's account is closed." } ] }, "rail_name": "RTP Payment Rejects", "governing_authority": "The Clearing House", "snapshot": "2026-09-19", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for RTP credit transfer (pacs.008). Its own scope line reads: an RTP credit transfer.", "from": "applies_to" }, { "kind": "not_public", "label": "the operator's own text", "needs": "what the operator's own text says, which Orca has not read", "detail": "The Clearing House's own text is not the source for this code: it is not public, or not under terms Orca can use. It rests on 2 named public sources, so a term set by agreement rather than by a published rule is not Orca's to state.", "from": "currency.primary_not_public" } ] }, { "uid": "rtp-reject:AC06", "id": "AC06", "rail": "rtp-reject", "kind": "reason-code", "name": "Receiver's account blocked", "group": "account", "summary": "The receiver's account is blocked, so the receiving participant will not post to it. An ISO 20022 status reason code (ExternalStatusReason1Code). The meaning given is the one the public bank and processor pages agree on for RTP; ISO's generic definition is a fallback only where they say nothing more. The receiving participant sends it in its reject response [Inference: the Oracle page marks it as used by the FI only, and Rule V.C lets the receiving participant reject for reasons tied to the receiver's account].", "triggers": [ "The account is frozen by a legal order or restraint [Inference]", "The receiving participant is watching the account for suspected fraud or other illegal activity" ], "actions": [ "Sender: contact the receiver; the receiving participant owes the receiver no status information when it rejects on these grounds (Rule II.F.1.a)", "Do not keep resending while the block stands" ], "retry": { "allowed": false, "rule": "Not to the same account while the block stands. The rejected payment never settled." }, "facts": { "return_windows": [ { "action": "reject", "by": "Receiving Participant", "deadline": "Within the response time the RTP Technical Specifications set; the figure is not in the public Operating Rules. If the receiving participant has not answered by then, TCH cancels the payment and tells both participants." } ], "applies_to": "an RTP credit transfer" }, "caveat": "Same code, different rail: FedNow, SEPA and other ISO 20022 rails use their own lists and meanings, so never carry a meaning over from them.", "related": [], "basis": { "sources": "Listed as an RTP reject code by the Cross River Bank request and response codes page (family A); the Trice RTP system codes page (family B); the CU*Answers RTP Return Codes PDF, Appendix B (family C); the Oracle US RTP reason code mapping page (family D), all read 2026-09-19; the families agree on the meaning. ISO 20022 External Code Sets 2Q2026: in ExternalStatusReason1Code. Reject mechanics from the TCH RTP Operating Rules effective 2026-06-01, Rules IV.A, V.C and V.E.3. No TCH code list was consulted: the permitted list sits in the RTP Technical Specifications, under terms Orca has not accepted.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: no public source dates it", "effective_to": null, "effective_note": "No public source read says when this code became permitted on RTP [Unverified]. The pages it rests on were published or updated between 2023 and 2026.", "source_edition": "RTP Message Specifications not consulted (terms not accepted); the record rests on public bank and processor pages read 2026-09-19, and on the RTP Operating Rules effective 2026-06-01 for how a reject works", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "primary_not_public": true, "corroboration": [ { "source_url": "https://triceapi.readme.io/reference/rtp-system-codes", "source_class": "secondary", "source_title": "RTP / FedNOW / ACH System Codes (Trice)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms AC06 is listed as an RTP reject code meaning the receiver's account is blocked." }, { "source_url": "https://www.cuanswers.com/wp-content/uploads/Return-Codes.pdf", "source_class": "secondary", "source_title": "RTP Return Codes (CU*Answers)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms AC06 is listed as an RTP reject code meaning the receiver's account is blocked." } ] }, "rail_name": "RTP Payment Rejects", "governing_authority": "The Clearing House", "snapshot": "2026-09-19", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for RTP credit transfer (pacs.008). Its own scope line reads: an RTP credit transfer.", "from": "applies_to" }, { "kind": "not_public", "label": "the operator's own text", "needs": "what the operator's own text says, which Orca has not read", "detail": "The Clearing House's own text is not the source for this code: it is not public, or not under terms Orca can use. It rests on 2 named public sources, so a term set by agreement rather than by a published rule is not Orca's to state.", "from": "currency.primary_not_public" } ] }, { "uid": "rtp-reject:AC07", "id": "AC07", "rail": "rtp-reject", "kind": "reason-code", "name": "Receiver's account closed (creditor account code)", "group": "account", "summary": "The receiver's account is closed; the code names the creditor account specifically, where AC04 names any account. An ISO 20022 status reason code (ExternalStatusReason1Code). The meaning given is the one the public bank and processor pages agree on for RTP; ISO's generic definition is a fallback only where they say nothing more. The receiving participant sends it in its reject response [Inference: the Oracle page marks it as used by the FI only, and Rule V.C lets the receiving participant reject for reasons tied to the receiver's account].", "triggers": [ "The receiver's account was closed before the payment arrived" ], "actions": [ "Sender: get current account details from the receiver and send a new payment" ], "retry": { "allowed": false, "rule": "Do not send again to the same account. Get new account details and send a new payment." }, "facts": { "return_windows": [ { "action": "reject", "by": "Receiving Participant", "deadline": "Within the response time the RTP Technical Specifications set; the figure is not in the public Operating Rules. If the receiving participant has not answered by then, TCH cancels the payment and tells both participants." } ], "applies_to": "an RTP credit transfer" }, "caveat": "The sources list both AC04 and AC07 for a closed account on RTP; none says when a participant should pick one over the other [Unverified]. Same code, different rail: FedNow, SEPA and other ISO 20022 rails use their own lists and meanings, so never carry a meaning over from them.", "related": [ "rtp-reject:AC04" ], "basis": { "sources": "Listed as an RTP reject code by the Cross River Bank request and response codes page (family A); the Oracle US RTP reason code mapping page (family D), all read 2026-09-19; the families agree on the meaning. ISO 20022 External Code Sets 2Q2026: in ExternalStatusReason1Code. Reject mechanics from the TCH RTP Operating Rules effective 2026-06-01, Rules IV.A, V.C and V.E.3. No TCH code list was consulted: the permitted list sits in the RTP Technical Specifications, under terms Orca has not accepted.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: no public source dates it", "effective_to": null, "effective_note": "No public source read says when this code became permitted on RTP [Unverified]. The pages it rests on were published or updated between 2023 and 2026.", "source_edition": "RTP Message Specifications not consulted (terms not accepted); the record rests on public bank and processor pages read 2026-09-19, and on the RTP Operating Rules effective 2026-06-01 for how a reject works", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "primary_not_public": true, "corroboration": [ { "source_url": "https://docs.crossriver.com/apis/payments/instant-payments/request-and-response-codes-instant-payments", "source_class": "secondary", "source_title": "Request and response codes: Instant payments (Cross River Bank)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms AC07 is listed as an RTP reject code meaning the receiver's account is closed." }, { "source_url": "https://docs.oracle.com/en/industries/financial-services/banking-payments/14.7.0.0.0/urtpu/reason-code-mapping.html", "source_class": "secondary", "source_title": "US Real-Time Payments User Guide, Reason Code Mapping (Oracle Banking Payments 14.7)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms AC07 is listed as an RTP reject code meaning the receiver's account is closed." } ] }, "rail_name": "RTP Payment Rejects", "governing_authority": "The Clearing House", "snapshot": "2026-09-19", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for RTP credit transfer (pacs.008). Its own scope line reads: an RTP credit transfer.", "from": "applies_to" }, { "kind": "not_public", "label": "the operator's own text", "needs": "what the operator's own text says, which Orca has not read", "detail": "The Clearing House's own text is not the source for this code: it is not public, or not under terms Orca can use. It rests on 2 named public sources, so a term set by agreement rather than by a published rule is not Orca's to state.", "from": "currency.primary_not_public" } ] }, { "uid": "rtp-reject:AC11", "id": "AC11", "rail": "rtp-reject", "kind": "reason-code", "name": "Receiver's account currency wrong or missing", "group": "account", "summary": "The currency given for the receiver's account is wrong or missing. An ISO 20022 status reason code (ExternalStatusReason1Code). The meaning given is the one the public bank and processor pages agree on for RTP; ISO's generic definition is a fallback only where they say nothing more. The receiving participant sends it in its reject response [Inference: the Oracle page marks it as used by the FI only].", "triggers": [ "The message carried a currency other than US dollars for the receiver's account, or none [Inference]" ], "actions": [ "Sending participant: check how its system fills the account currency and send a new payment in US dollars" ], "retry": { "allowed": true, "rule": "Send a new payment message once the fault is fixed; the rejected payment never settled, so there is nothing to reverse or return." }, "facts": { "return_windows": [ { "action": "reject", "by": "Receiving Participant", "deadline": "Within the response time the RTP Technical Specifications set; the figure is not in the public Operating Rules. If the receiving participant has not answered by then, TCH cancels the payment and tells both participants." } ], "applies_to": "an RTP credit transfer" }, "caveat": "RTP payments are in US dollars only (Operating Rules I.A.57 and I.A.58), so this code points at a badly built message rather than a real currency choice [Inference]. Same code, different rail: FedNow, SEPA and other ISO 20022 rails use their own lists and meanings, so never carry a meaning over from them.", "related": [ "rtp-reject:AM11" ], "basis": { "sources": "Listed as an RTP reject code by the Cross River Bank request and response codes page (family A); the Trice RTP system codes page (family B); the CU*Answers RTP Return Codes PDF, Appendix B (family C); the Oracle US RTP reason code mapping page (family D), all read 2026-09-19; the families agree on the meaning. ISO 20022 External Code Sets 2Q2026: in ExternalStatusReason1Code. Reject mechanics from the TCH RTP Operating Rules effective 2026-06-01, Rules IV.A, V.C and V.E.3. No TCH code list was consulted: the permitted list sits in the RTP Technical Specifications, under terms Orca has not accepted.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: no public source dates it", "effective_to": null, "effective_note": "No public source read says when this code became permitted on RTP [Unverified]. The pages it rests on were published or updated between 2023 and 2026.", "source_edition": "RTP Message Specifications not consulted (terms not accepted); the record rests on public bank and processor pages read 2026-09-19, and on the RTP Operating Rules effective 2026-06-01 for how a reject works", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "primary_not_public": true, "corroboration": [ { "source_url": "https://triceapi.readme.io/reference/rtp-system-codes", "source_class": "secondary", "source_title": "RTP / FedNOW / ACH System Codes (Trice)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms AC11 is listed as an RTP reject code meaning the receiver's account currency is wrong or missing." }, { "source_url": "https://www.cuanswers.com/wp-content/uploads/Return-Codes.pdf", "source_class": "secondary", "source_title": "RTP Return Codes (CU*Answers)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms AC11 is listed as an RTP reject code meaning the receiver's account currency is wrong or missing." } ] }, "rail_name": "RTP Payment Rejects", "governing_authority": "The Clearing House", "snapshot": "2026-09-19", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for RTP credit transfer (pacs.008). Its own scope line reads: an RTP credit transfer.", "from": "applies_to" }, { "kind": "not_public", "label": "the operator's own text", "needs": "what the operator's own text says, which Orca has not read", "detail": "The Clearing House's own text is not the source for this code: it is not public, or not under terms Orca can use. It rests on 2 named public sources, so a term set by agreement rather than by a published rule is not Orca's to state.", "from": "currency.primary_not_public" } ] }, { "uid": "rtp-reject:AC13", "id": "AC13", "rail": "rtp-reject", "kind": "reason-code", "name": "Sender's account type wrong or missing", "group": "account", "summary": "The account type given for the sender is wrong or missing. An ISO 20022 status reason code (ExternalStatusReason1Code). The meaning given is the one the public bank and processor pages agree on for RTP; ISO's generic definition is a fallback only where they say nothing more. No public source read says whether the receiving participant or the RTP System sends it, so both are linked [Inference].", "triggers": [ "The message named a sender account type that does not match the account, or none" ], "actions": [ "Sending participant: correct the sender's account type in the message and send a new payment" ], "retry": { "allowed": true, "rule": "Send a new payment message once the fault is fixed; the rejected payment never settled, so there is nothing to reverse or return." }, "facts": { "return_windows": [ { "action": "reject", "by": "Receiving Participant", "deadline": "Within the response time the RTP Technical Specifications set; the figure is not in the public Operating Rules. If the receiving participant has not answered by then, TCH cancels the payment and tells both participants." }, { "action": "reject", "by": "RTP System", "deadline": "On receipt, before the RTP System releases the payment message to the receiving participant." } ], "applies_to": "an RTP credit transfer" }, "caveat": "Same code, different rail: FedNow, SEPA and other ISO 20022 rails use their own lists and meanings, so never carry a meaning over from them.", "related": [ "rtp-reject:AC02", "rtp-reject:AC14" ], "basis": { "sources": "Listed as an RTP reject code by the Cross River Bank request and response codes page (family A); the Trice RTP system codes page (family B); the CU*Answers RTP Return Codes PDF, Appendix B (family C), all read 2026-09-19; Cross River Bank and Trice agree; CU*Answers says only that the debtor account is invalid, which does not conflict. ISO 20022 External Code Sets 2Q2026: in ExternalStatusReason1Code. Reject mechanics from the TCH RTP Operating Rules effective 2026-06-01, Rules IV.A, V.C and V.E.3. No TCH code list was consulted: the permitted list sits in the RTP Technical Specifications, under terms Orca has not accepted.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: no public source dates it", "effective_to": null, "effective_note": "No public source read says when this code became permitted on RTP [Unverified]. The pages it rests on were published or updated between 2023 and 2026.", "source_edition": "RTP Message Specifications not consulted (terms not accepted); the record rests on public bank and processor pages read 2026-09-19, and on the RTP Operating Rules effective 2026-06-01 for how a reject works", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "primary_not_public": true, "corroboration": [ { "source_url": "https://triceapi.readme.io/reference/rtp-system-codes", "source_class": "secondary", "source_title": "RTP / FedNOW / ACH System Codes (Trice)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms AC13 is listed as an RTP reject code meaning the sender's account type is wrong or missing." }, { "source_url": "https://www.cuanswers.com/wp-content/uploads/Return-Codes.pdf", "source_class": "secondary", "source_title": "RTP Return Codes (CU*Answers)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms AC13 is listed as an RTP reject code, though CU*Answers marks the debtor account as invalid without stating the account type specifically." } ] }, "rail_name": "RTP Payment Rejects", "governing_authority": "The Clearing House", "snapshot": "2026-09-19", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for RTP credit transfer (pacs.008). Its own scope line reads: an RTP credit transfer.", "from": "applies_to" }, { "kind": "not_public", "label": "the operator's own text", "needs": "what the operator's own text says, which Orca has not read", "detail": "The Clearing House's own text is not the source for this code: it is not public, or not under terms Orca can use. It rests on 2 named public sources, so a term set by agreement rather than by a published rule is not Orca's to state.", "from": "currency.primary_not_public" } ] }, { "uid": "rtp-reject:AC14", "id": "AC14", "rail": "rtp-reject", "kind": "reason-code", "name": "Receiver's account type wrong or missing", "group": "account", "summary": "The account type given for the receiver is wrong or missing. An ISO 20022 status reason code (ExternalStatusReason1Code). The meaning given is the one the public bank and processor pages agree on for RTP; ISO's generic definition is a fallback only where they say nothing more. No public source read says whether the receiving participant or the RTP System sends it, so both are linked [Inference]; a receiving participant may reject a payment to an account that is not a Regulation D transaction account (Rule V.C.1), which this code may report.", "triggers": [ "The sender gave the wrong account type for the receiver", "The receiver's account is of a kind that cannot take RTP payments [Inference]" ], "actions": [ "Sender: confirm the receiver's account type and send a new payment", "If the receiver's account cannot take RTP payments, pay by another rail" ], "retry": { "allowed": true, "rule": "Send a new payment message once the fault is fixed; the rejected payment never settled, so there is nothing to reverse or return." }, "facts": { "return_windows": [ { "action": "reject", "by": "Receiving Participant", "deadline": "Within the response time the RTP Technical Specifications set; the figure is not in the public Operating Rules. If the receiving participant has not answered by then, TCH cancels the payment and tells both participants." }, { "action": "reject", "by": "RTP System", "deadline": "On receipt, before the RTP System releases the payment message to the receiving participant." } ], "applies_to": "an RTP credit transfer" }, "caveat": "Same code, different rail: FedNow, SEPA and other ISO 20022 rails use their own lists and meanings, so never carry a meaning over from them.", "related": [ "rtp-reject:AC13", "rtp-reject:AG01" ], "basis": { "sources": "Listed as an RTP reject code by the Cross River Bank request and response codes page (family A); the Trice RTP system codes page (family B); the CU*Answers RTP Return Codes PDF, Appendix B (family C), all read 2026-09-19; Cross River Bank and Trice agree; CU*Answers says only that the creditor account is invalid, which does not conflict. ISO 20022 External Code Sets 2Q2026: in ExternalStatusReason1Code. Reject mechanics from the TCH RTP Operating Rules effective 2026-06-01, Rules IV.A, V.C and V.E.3. No TCH code list was consulted: the permitted list sits in the RTP Technical Specifications, under terms Orca has not accepted.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: no public source dates it", "effective_to": null, "effective_note": "No public source read says when this code became permitted on RTP [Unverified]. The pages it rests on were published or updated between 2023 and 2026.", "source_edition": "RTP Message Specifications not consulted (terms not accepted); the record rests on public bank and processor pages read 2026-09-19, and on the RTP Operating Rules effective 2026-06-01 for how a reject works", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "primary_not_public": true, "corroboration": [ { "source_url": "https://triceapi.readme.io/reference/rtp-system-codes", "source_class": "secondary", "source_title": "RTP / FedNOW / ACH System Codes (Trice)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms AC14 is listed as an RTP reject code meaning the receiver's account type is wrong or missing." }, { "source_url": "https://www.cuanswers.com/wp-content/uploads/Return-Codes.pdf", "source_class": "secondary", "source_title": "RTP Return Codes (CU*Answers)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms AC14 is listed as an RTP reject code, though CU*Answers marks the creditor account as invalid without stating the account type specifically." } ] }, "rail_name": "RTP Payment Rejects", "governing_authority": "The Clearing House", "snapshot": "2026-09-19", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for RTP credit transfer (pacs.008). Its own scope line reads: an RTP credit transfer.", "from": "applies_to" }, { "kind": "not_public", "label": "the operator's own text", "needs": "what the operator's own text says, which Orca has not read", "detail": "The Clearing House's own text is not the source for this code: it is not public, or not under terms Orca can use. It rests on 2 named public sources, so a term set by agreement rather than by a published rule is not Orca's to state.", "from": "currency.primary_not_public" } ] }, { "uid": "rtp-reject:AG01", "id": "AG01", "rail": "rtp-reject", "kind": "reason-code", "name": "Account may not take this kind of transaction", "group": "authorization", "summary": "The receiver's account is of a type on which this transaction is not allowed. An ISO 20022 status reason code (ExternalStatusReason1Code). The meaning given is the one the public bank and processor pages agree on for RTP; ISO's generic definition is a fallback only where they say nothing more. The receiving participant sends it in its reject response [Inference: the Oracle page marks it as used by the FI only, and Rule V.C lets the receiving participant reject for reasons tied to the receiver's account, including an account that is not a Regulation D transaction account].", "triggers": [ "The account is not a transaction account under Regulation D, such as some savings products [Inference]", "The account holder has told the receiving participant not to accept some or all RTP payments [Inference]" ], "actions": [ "Sender: ask the receiver for an account that can take RTP payments, or pay by another rail" ], "retry": { "allowed": false, "rule": "Not to the same account. Pay to an account that can take RTP payments, or by another rail." }, "facts": { "return_windows": [ { "action": "reject", "by": "Receiving Participant", "deadline": "Within the response time the RTP Technical Specifications set; the figure is not in the public Operating Rules. If the receiving participant has not answered by then, TCH cancels the payment and tells both participants." } ], "applies_to": "an RTP credit transfer" }, "caveat": "Same code, different rail: FedNow, SEPA and other ISO 20022 rails use their own lists and meanings, so never carry a meaning over from them.", "related": [ "rtp-reject:AG03", "rtp-reject:AC14", "rtp-reject:NOAT" ], "basis": { "sources": "Listed as an RTP reject code by the Cross River Bank request and response codes page (family A); the Trice RTP system codes page (family B); the CU*Answers RTP Return Codes PDF, Appendix B (family C); the Oracle US RTP reason code mapping page (family D), all read 2026-09-19; the families agree on the meaning. ISO 20022 External Code Sets 2Q2026: in ExternalStatusReason1Code. Reject mechanics from the TCH RTP Operating Rules effective 2026-06-01, Rules IV.A, V.C and V.E.3. No TCH code list was consulted: the permitted list sits in the RTP Technical Specifications, under terms Orca has not accepted.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: no public source dates it", "effective_to": null, "effective_note": "No public source read says when this code became permitted on RTP [Unverified]. The pages it rests on were published or updated between 2023 and 2026.", "source_edition": "RTP Message Specifications not consulted (terms not accepted); the record rests on public bank and processor pages read 2026-09-19, and on the RTP Operating Rules effective 2026-06-01 for how a reject works", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "primary_not_public": true, "corroboration": [ { "source_url": "https://triceapi.readme.io/reference/rtp-system-codes", "source_class": "secondary", "source_title": "RTP / FedNOW / ACH System Codes (Trice)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms AG01 is listed as an RTP reject code meaning the account may not take this kind of transaction." }, { "source_url": "https://www.cuanswers.com/wp-content/uploads/Return-Codes.pdf", "source_class": "secondary", "source_title": "RTP Return Codes (CU*Answers)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms AG01 is listed as an RTP reject code meaning the account may not take this kind of transaction." } ] }, "rail_name": "RTP Payment Rejects", "governing_authority": "The Clearing House", "snapshot": "2026-09-19", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for RTP credit transfer (pacs.008). Its own scope line reads: an RTP credit transfer.", "from": "applies_to" }, { "kind": "not_public", "label": "the operator's own text", "needs": "what the operator's own text says, which Orca has not read", "detail": "The Clearing House's own text is not the source for this code: it is not public, or not under terms Orca can use. It rests on 2 named public sources, so a term set by agreement rather than by a published rule is not Orca's to state.", "from": "currency.primary_not_public" } ] }, { "uid": "rtp-reject:AG03", "id": "AG03", "rail": "rtp-reject", "kind": "reason-code", "name": "Transaction type not supported on the account", "group": "authorization", "summary": "The account cannot take this type of transaction, or the transaction type is not supported. An ISO 20022 status reason code (ExternalStatusReason1Code). The meaning given is the one the public bank and processor pages agree on for RTP; ISO's generic definition is a fallback only where they say nothing more. No public source read says whether the receiving participant or the RTP System sends it, so both are linked [Inference]; the Oracle page marks it as used by both the FI and the CI, which fits either sender.", "triggers": [ "The receiver's account is not set up for RTP payments of this kind [Inference]", "The message type or payment type is not enabled for the participant [Inference]" ], "actions": [ "Sender: pay by another rail or to another account" ], "retry": { "allowed": false, "rule": "Not to the same account for the same type of transaction." }, "facts": { "return_windows": [ { "action": "reject", "by": "Receiving Participant", "deadline": "Within the response time the RTP Technical Specifications set; the figure is not in the public Operating Rules. If the receiving participant has not answered by then, TCH cancels the payment and tells both participants." }, { "action": "reject", "by": "RTP System", "deadline": "On receipt, before the RTP System releases the payment message to the receiving participant." } ], "applies_to": "an RTP credit transfer" }, "caveat": "Same code, different rail: FedNow, SEPA and other ISO 20022 rails use their own lists and meanings, so never carry a meaning over from them.", "related": [ "rtp-reject:AG01", "rtp-reject:NOAT" ], "basis": { "sources": "Listed as an RTP reject code by the Cross River Bank request and response codes page (family A); the Trice RTP system codes page (family B); the CU*Answers RTP Return Codes PDF, Appendix B (family C); the Oracle US RTP reason code mapping page (family D), all read 2026-09-19; the families agree on the meaning. ISO 20022 External Code Sets 2Q2026: in ExternalStatusReason1Code. Reject mechanics from the TCH RTP Operating Rules effective 2026-06-01, Rules IV.A, V.C and V.E.3. No TCH code list was consulted: the permitted list sits in the RTP Technical Specifications, under terms Orca has not accepted.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: no public source dates it", "effective_to": null, "effective_note": "No public source read says when this code became permitted on RTP [Unverified]. The pages it rests on were published or updated between 2023 and 2026.", "source_edition": "RTP Message Specifications not consulted (terms not accepted); the record rests on public bank and processor pages read 2026-09-19, and on the RTP Operating Rules effective 2026-06-01 for how a reject works", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "primary_not_public": true, "corroboration": [ { "source_url": "https://triceapi.readme.io/reference/rtp-system-codes", "source_class": "secondary", "source_title": "RTP / FedNOW / ACH System Codes (Trice)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms AG03 is listed as an RTP reject code meaning the transaction type is not supported on the account." }, { "source_url": "https://www.cuanswers.com/wp-content/uploads/Return-Codes.pdf", "source_class": "secondary", "source_title": "RTP Return Codes (CU*Answers)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms AG03 is listed as an RTP reject code meaning the transaction type is not supported on the account." } ] }, "rail_name": "RTP Payment Rejects", "governing_authority": "The Clearing House", "snapshot": "2026-09-19", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for RTP credit transfer (pacs.008). Its own scope line reads: an RTP credit transfer.", "from": "applies_to" }, { "kind": "not_public", "label": "the operator's own text", "needs": "what the operator's own text says, which Orca has not read", "detail": "The Clearing House's own text is not the source for this code: it is not public, or not under terms Orca can use. It rests on 2 named public sources, so a term set by agreement rather than by a published rule is not Orca's to state.", "from": "currency.primary_not_public" } ] }, { "uid": "rtp-reject:AGNT", "id": "AGNT", "rail": "rtp-reject", "kind": "reason-code", "name": "A bank in the payment chain is named wrongly", "group": "technical", "summary": "An agent (a bank or participant) named in the payment chain is wrong. An ISO 20022 status reason code (ExternalStatusReason1Code). The meaning given is the one the public bank and processor pages agree on for RTP; ISO's generic definition is a fallback only where they say nothing more. No public source read says whether the receiving participant or the RTP System sends it, so both are linked [Inference].", "triggers": [ "The sending participant named the wrong receiving participant or intermediary for the receiver's routing number [Inference]" ], "actions": [ "Sending participant: check the agents named in the message against the routing details and send a new payment" ], "retry": { "allowed": true, "rule": "Send a new payment message once the fault is fixed; the rejected payment never settled, so there is nothing to reverse or return." }, "facts": { "return_windows": [ { "action": "reject", "by": "Receiving Participant", "deadline": "Within the response time the RTP Technical Specifications set; the figure is not in the public Operating Rules. If the receiving participant has not answered by then, TCH cancels the payment and tells both participants." }, { "action": "reject", "by": "RTP System", "deadline": "On receipt, before the RTP System releases the payment message to the receiving participant." } ], "applies_to": "an RTP credit transfer" }, "caveat": "Same code, different rail: FedNow, SEPA and other ISO 20022 rails use their own lists and meanings, so never carry a meaning over from them.", "related": [ "rtp-reject:RC02", "rtp-reject:RC04" ], "basis": { "sources": "Listed as an RTP reject code by the Cross River Bank request and response codes page (family A); the Trice RTP system codes page (family B); the CU*Answers RTP Return Codes PDF, Appendix B (family C), all read 2026-09-19; the families agree on the meaning. ISO 20022 External Code Sets 2Q2026: in ExternalStatusReason1Code. Reject mechanics from the TCH RTP Operating Rules effective 2026-06-01, Rules IV.A, V.C and V.E.3. No TCH code list was consulted: the permitted list sits in the RTP Technical Specifications, under terms Orca has not accepted.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: no public source dates it", "effective_to": null, "effective_note": "No public source read says when this code became permitted on RTP [Unverified]. The pages it rests on were published or updated between 2023 and 2026.", "source_edition": "RTP Message Specifications not consulted (terms not accepted); the record rests on public bank and processor pages read 2026-09-19, and on the RTP Operating Rules effective 2026-06-01 for how a reject works", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "primary_not_public": true, "corroboration": [ { "source_url": "https://triceapi.readme.io/reference/rtp-system-codes", "source_class": "secondary", "source_title": "RTP / FedNOW / ACH System Codes (Trice)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms AGNT is listed as an RTP reject code meaning a bank in the payment chain is named wrongly." }, { "source_url": "https://www.cuanswers.com/wp-content/uploads/Return-Codes.pdf", "source_class": "secondary", "source_title": "RTP Return Codes (CU*Answers)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms AGNT is listed as an RTP reject code meaning a bank in the payment chain is named wrongly." } ] }, "rail_name": "RTP Payment Rejects", "governing_authority": "The Clearing House", "snapshot": "2026-09-19", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for RTP credit transfer (pacs.008). Its own scope line reads: an RTP credit transfer.", "from": "applies_to" }, { "kind": "not_public", "label": "the operator's own text", "needs": "what the operator's own text says, which Orca has not read", "detail": "The Clearing House's own text is not the source for this code: it is not public, or not under terms Orca can use. It rests on 2 named public sources, so a term set by agreement rather than by a published rule is not Orca's to state.", "from": "currency.primary_not_public" } ] }, { "uid": "rtp-reject:AM02", "id": "AM02", "rail": "rtp-reject", "kind": "reason-code", "name": "Amount above the permitted maximum", "group": "administrative", "summary": "The amount is above the maximum allowed for this payment. An ISO 20022 status reason code (ExternalStatusReason1Code). The meaning given is the one the public bank and processor pages agree on for RTP; ISO's generic definition is a fallback only where they say nothing more. No public source read says whether the receiving participant or the RTP System sends it, so both are linked [Inference].", "triggers": [ "The amount exceeds a limit set by a participant or by the network [Inference]" ], "actions": [ "Sender: check which limit applies; AM13 names the network limit and AM14 a limit agreed between a bank and its customer" ], "retry": { "allowed": false, "rule": "Not for the same amount. Pay the amount by another rail or as the parties agree [Inference]." }, "facts": { "return_windows": [ { "action": "reject", "by": "Receiving Participant", "deadline": "Within the response time the RTP Technical Specifications set; the figure is not in the public Operating Rules. If the receiving participant has not answered by then, TCH cancels the payment and tells both participants." }, { "action": "reject", "by": "RTP System", "deadline": "On receipt, before the RTP System releases the payment message to the receiving participant." } ], "applies_to": "an RTP credit transfer" }, "caveat": "None of the sources says whose maximum AM02 refers to on RTP, as against AM13 and AM14 [Unverified]. Same code, different rail: FedNow, SEPA and other ISO 20022 rails use their own lists and meanings, so never carry a meaning over from them.", "related": [ "rtp-reject:AM13", "rtp-reject:AM14" ], "basis": { "sources": "Listed as an RTP reject code by the Cross River Bank request and response codes page (family A); the Trice RTP system codes page (family B); the CU*Answers RTP Return Codes PDF, Appendix B (family C), all read 2026-09-19; the families agree on the meaning. ISO 20022 External Code Sets 2Q2026: in ExternalStatusReason1Code. Reject mechanics from the TCH RTP Operating Rules effective 2026-06-01, Rules IV.A, V.C and V.E.3. No TCH code list was consulted: the permitted list sits in the RTP Technical Specifications, under terms Orca has not accepted.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: no public source dates it", "effective_to": null, "effective_note": "No public source read says when this code became permitted on RTP [Unverified]. The pages it rests on were published or updated between 2023 and 2026.", "source_edition": "RTP Message Specifications not consulted (terms not accepted); the record rests on public bank and processor pages read 2026-09-19, and on the RTP Operating Rules effective 2026-06-01 for how a reject works", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "primary_not_public": true, "corroboration": [ { "source_url": "https://triceapi.readme.io/reference/rtp-system-codes", "source_class": "secondary", "source_title": "RTP / FedNOW / ACH System Codes (Trice)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms AM02 is listed as an RTP reject code meaning the amount is above the permitted maximum." }, { "source_url": "https://www.cuanswers.com/wp-content/uploads/Return-Codes.pdf", "source_class": "secondary", "source_title": "RTP Return Codes (CU*Answers)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms AM02 is listed as an RTP reject code meaning the amount is above the permitted maximum." } ] }, "rail_name": "RTP Payment Rejects", "governing_authority": "The Clearing House", "snapshot": "2026-09-19", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for RTP credit transfer (pacs.008). Its own scope line reads: an RTP credit transfer.", "from": "applies_to" }, { "kind": "not_public", "label": "the operator's own text", "needs": "what the operator's own text says, which Orca has not read", "detail": "The Clearing House's own text is not the source for this code: it is not public, or not under terms Orca can use. It rests on 2 named public sources, so a term set by agreement rather than by a published rule is not Orca's to state.", "from": "currency.primary_not_public" } ] }, { "uid": "rtp-reject:AM04", "id": "AM04", "rail": "rtp-reject", "kind": "reason-code", "name": "Not enough funds", "group": "funds", "summary": "There are not enough funds to cover the payment. An ISO 20022 status reason code (ExternalStatusReason1Code). The meaning given is the one the public bank and processor pages agree on for RTP; ISO's generic definition is a fallback only where they say nothing more. No public source read says whether the receiving participant or the RTP System sends it, so both are linked [Inference].", "triggers": [ "The sender's balance at the sending participant does not cover the amount [Inference]", "The sending side's prefunded position at the RTP System does not cover it [Inference]" ], "actions": [ "Sending participant: check the sender's balance, and its own prefunded position, before sending a new payment" ], "retry": { "allowed": true, "rule": "A new payment once funds are available [Inference]; the rejected payment never settled." }, "facts": { "return_windows": [ { "action": "reject", "by": "Receiving Participant", "deadline": "Within the response time the RTP Technical Specifications set; the figure is not in the public Operating Rules. If the receiving participant has not answered by then, TCH cancels the payment and tells both participants." }, { "action": "reject", "by": "RTP System", "deadline": "On receipt, before the RTP System releases the payment message to the receiving participant." } ], "applies_to": "an RTP credit transfer" }, "caveat": "RTP is credit push, so a receiving participant has no sender funds to check. [Inference] On RTP this code most plausibly reports a shortfall on the sending side: the RTP System must reject a payment the sending participant's prefunded position does not cover (Operating Rules VI.E.1, VI.E.3). No source read says which side sends it. Same code, different rail: FedNow, SEPA and other ISO 20022 rails use their own lists and meanings, so never carry a meaning over from them.", "related": [], "basis": { "sources": "Listed as an RTP reject code by the Cross River Bank request and response codes page (family A); the Trice RTP system codes page (family B); the CU*Answers RTP Return Codes PDF, Appendix B (family C), all read 2026-09-19; the families agree on the meaning. ISO 20022 External Code Sets 2Q2026: in ExternalStatusReason1Code. Reject mechanics from the TCH RTP Operating Rules effective 2026-06-01, Rules IV.A, V.C and V.E.3. No TCH code list was consulted: the permitted list sits in the RTP Technical Specifications, under terms Orca has not accepted.", "confidence": "low" }, "currency": { "effective_since": "Unknown: no public source dates it", "effective_to": null, "effective_note": "No public source read says when this code became permitted on RTP [Unverified]. The pages it rests on were published or updated between 2023 and 2026.", "source_edition": "RTP Message Specifications not consulted (terms not accepted); the record rests on public bank and processor pages read 2026-09-19, and on the RTP Operating Rules effective 2026-06-01 for how a reject works", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "primary_not_public": true, "corroboration": [ { "source_url": "https://triceapi.readme.io/reference/rtp-system-codes", "source_class": "secondary", "source_title": "RTP / FedNOW / ACH System Codes (Trice)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms AM04 is listed as an RTP reject code meaning there are not enough funds." }, { "source_url": "https://www.cuanswers.com/wp-content/uploads/Return-Codes.pdf", "source_class": "secondary", "source_title": "RTP Return Codes (CU*Answers)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms AM04 is listed as an RTP reject code meaning there are not enough funds." } ] }, "rail_name": "RTP Payment Rejects", "governing_authority": "The Clearing House", "snapshot": "2026-09-19", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for RTP credit transfer (pacs.008). Its own scope line reads: an RTP credit transfer.", "from": "applies_to" }, { "kind": "not_public", "label": "the operator's own text", "needs": "what the operator's own text says, which Orca has not read", "detail": "The Clearing House's own text is not the source for this code: it is not public, or not under terms Orca can use. It rests on 2 named public sources, so a term set by agreement rather than by a published rule is not Orca's to state.", "from": "currency.primary_not_public" } ] }, { "uid": "rtp-reject:AM09", "id": "AM09", "rail": "rtp-reject", "kind": "reason-code", "name": "Amount not what was agreed or expected", "group": "administrative", "summary": "The amount received is not the amount agreed or expected. An ISO 20022 status reason code (ExternalStatusReason1Code). The meaning given is the one the public bank and processor pages agree on for RTP; ISO's generic definition is a fallback only where they say nothing more. No public source read says whether the receiving participant or the RTP System sends it, so both are linked [Inference].", "triggers": [ "A payment answering a request for payment carries a different amount than the request asked for [Inference]" ], "actions": [ "Sender: confirm the amount with the receiver and send a new payment for the right amount" ], "retry": { "allowed": true, "rule": "Send a new payment message once the fault is fixed; the rejected payment never settled, so there is nothing to reverse or return." }, "facts": { "return_windows": [ { "action": "reject", "by": "Receiving Participant", "deadline": "Within the response time the RTP Technical Specifications set; the figure is not in the public Operating Rules. If the receiving participant has not answered by then, TCH cancels the payment and tells both participants." }, { "action": "reject", "by": "RTP System", "deadline": "On receipt, before the RTP System releases the payment message to the receiving participant." } ], "applies_to": "an RTP credit transfer" }, "caveat": "Same code, different rail: FedNow, SEPA and other ISO 20022 rails use their own lists and meanings, so never carry a meaning over from them.", "related": [ "rtp-reject:AM12" ], "basis": { "sources": "Listed as an RTP reject code by the Cross River Bank request and response codes page (family A); the Trice RTP system codes page (family B); the CU*Answers RTP Return Codes PDF, Appendix B (family C), all read 2026-09-19; the families agree on the meaning. ISO 20022 External Code Sets 2Q2026: in ExternalStatusReason1Code. Reject mechanics from the TCH RTP Operating Rules effective 2026-06-01, Rules IV.A, V.C and V.E.3. No TCH code list was consulted: the permitted list sits in the RTP Technical Specifications, under terms Orca has not accepted.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: no public source dates it", "effective_to": null, "effective_note": "No public source read says when this code became permitted on RTP [Unverified]. The pages it rests on were published or updated between 2023 and 2026.", "source_edition": "RTP Message Specifications not consulted (terms not accepted); the record rests on public bank and processor pages read 2026-09-19, and on the RTP Operating Rules effective 2026-06-01 for how a reject works", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "primary_not_public": true, "corroboration": [ { "source_url": "https://triceapi.readme.io/reference/rtp-system-codes", "source_class": "secondary", "source_title": "RTP / FedNOW / ACH System Codes (Trice)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms AM09 is listed as an RTP reject code meaning the amount is not what was agreed or expected." }, { "source_url": "https://www.cuanswers.com/wp-content/uploads/Return-Codes.pdf", "source_class": "secondary", "source_title": "RTP Return Codes (CU*Answers)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms AM09 is listed as an RTP reject code meaning the amount is not what was agreed or expected." } ] }, "rail_name": "RTP Payment Rejects", "governing_authority": "The Clearing House", "snapshot": "2026-09-19", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for RTP credit transfer (pacs.008). Its own scope line reads: an RTP credit transfer.", "from": "applies_to" }, { "kind": "not_public", "label": "the operator's own text", "needs": "what the operator's own text says, which Orca has not read", "detail": "The Clearing House's own text is not the source for this code: it is not public, or not under terms Orca can use. It rests on 2 named public sources, so a term set by agreement rather than by a published rule is not Orca's to state.", "from": "currency.primary_not_public" } ] }, { "uid": "rtp-reject:AM11", "id": "AM11", "rail": "rtp-reject", "kind": "reason-code", "name": "Currency wrong, missing or not US dollars", "group": "administrative", "summary": "The currency of the payment is wrong or missing; Trice adds that RTP does not support the currency given. An ISO 20022 status reason code (ExternalStatusReason1Code). The meaning given is the one the public bank and processor pages agree on for RTP; ISO's generic definition is a fallback only where they say nothing more. No public source read says whether the receiving participant or the RTP System sends it, so both are linked [Inference]; the Oracle page marks it as used by both the FI and the CI.", "triggers": [ "The message carried a currency other than US dollars, or none" ], "actions": [ "Sending participant: send a new payment in US dollars" ], "retry": { "allowed": true, "rule": "Send a new payment message once the fault is fixed; the rejected payment never settled, so there is nothing to reverse or return." }, "facts": { "return_windows": [ { "action": "reject", "by": "Receiving Participant", "deadline": "Within the response time the RTP Technical Specifications set; the figure is not in the public Operating Rules. If the receiving participant has not answered by then, TCH cancels the payment and tells both participants." }, { "action": "reject", "by": "RTP System", "deadline": "On receipt, before the RTP System releases the payment message to the receiving participant." } ], "applies_to": "an RTP credit transfer" }, "caveat": "RTP carries US dollars only (Operating Rules I.A.57 and I.A.58). Same code, different rail: FedNow, SEPA and other ISO 20022 rails use their own lists and meanings, so never carry a meaning over from them.", "related": [ "rtp-reject:AC11" ], "basis": { "sources": "Listed as an RTP reject code by the Cross River Bank request and response codes page (family A); the Trice RTP system codes page (family B); the Oracle US RTP reason code mapping page (family D), all read 2026-09-19; the families agree on the meaning. ISO 20022 External Code Sets 2Q2026: in ExternalStatusReason1Code. Reject mechanics from the TCH RTP Operating Rules effective 2026-06-01, Rules IV.A, V.C and V.E.3. No TCH code list was consulted: the permitted list sits in the RTP Technical Specifications, under terms Orca has not accepted.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: no public source dates it", "effective_to": null, "effective_note": "No public source read says when this code became permitted on RTP [Unverified]. The pages it rests on were published or updated between 2023 and 2026.", "source_edition": "RTP Message Specifications not consulted (terms not accepted); the record rests on public bank and processor pages read 2026-09-19, and on the RTP Operating Rules effective 2026-06-01 for how a reject works", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "primary_not_public": true, "corroboration": [ { "source_url": "https://triceapi.readme.io/reference/rtp-system-codes", "source_class": "secondary", "source_title": "RTP / FedNOW / ACH System Codes (Trice)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms AM11 is listed as an RTP reject code meaning the currency is wrong, missing or not supported." }, { "source_url": "https://docs.oracle.com/en/industries/financial-services/banking-payments/14.7.0.0.0/urtpu/reason-code-mapping.html", "source_class": "secondary", "source_title": "US Real-Time Payments User Guide, Reason Code Mapping (Oracle Banking Payments 14.7)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms AM11 is listed as an RTP reject code meaning the currency is wrong, missing or not supported." } ] }, "rail_name": "RTP Payment Rejects", "governing_authority": "The Clearing House", "snapshot": "2026-09-19", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for RTP credit transfer (pacs.008). Its own scope line reads: an RTP credit transfer.", "from": "applies_to" }, { "kind": "not_public", "label": "the operator's own text", "needs": "what the operator's own text says, which Orca has not read", "detail": "The Clearing House's own text is not the source for this code: it is not public, or not under terms Orca can use. It rests on 2 named public sources, so a term set by agreement rather than by a published rule is not Orca's to state.", "from": "currency.primary_not_public" } ] }, { "uid": "rtp-reject:AM12", "id": "AM12", "rail": "rtp-reject", "kind": "reason-code", "name": "Amount wrong or missing", "group": "administrative", "summary": "The amount of the payment is invalid or missing. An ISO 20022 status reason code (ExternalStatusReason1Code). The meaning given is the one the public bank and processor pages agree on for RTP; ISO's generic definition is a fallback only where they say nothing more. No public source read says whether the receiving participant or the RTP System sends it, so both are linked [Inference]; the Oracle page marks it as used by both the FI and the CI.", "triggers": [ "The amount field is empty, zero, negative or badly formatted [Inference]" ], "actions": [ "Sending participant: correct the amount and send a new payment" ], "retry": { "allowed": true, "rule": "Send a new payment message once the fault is fixed; the rejected payment never settled, so there is nothing to reverse or return." }, "facts": { "return_windows": [ { "action": "reject", "by": "Receiving Participant", "deadline": "Within the response time the RTP Technical Specifications set; the figure is not in the public Operating Rules. If the receiving participant has not answered by then, TCH cancels the payment and tells both participants." }, { "action": "reject", "by": "RTP System", "deadline": "On receipt, before the RTP System releases the payment message to the receiving participant." } ], "applies_to": "an RTP credit transfer" }, "caveat": "Same code, different rail: FedNow, SEPA and other ISO 20022 rails use their own lists and meanings, so never carry a meaning over from them.", "related": [ "rtp-reject:AM09" ], "basis": { "sources": "Listed as an RTP reject code by the Cross River Bank request and response codes page (family A); the Trice RTP system codes page (family B); the CU*Answers RTP Return Codes PDF, Appendix B (family C); the Oracle US RTP reason code mapping page (family D), all read 2026-09-19; the families agree on the meaning. ISO 20022 External Code Sets 2Q2026: in ExternalStatusReason1Code. Reject mechanics from the TCH RTP Operating Rules effective 2026-06-01, Rules IV.A, V.C and V.E.3. No TCH code list was consulted: the permitted list sits in the RTP Technical Specifications, under terms Orca has not accepted.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: no public source dates it", "effective_to": null, "effective_note": "No public source read says when this code became permitted on RTP [Unverified]. The pages it rests on were published or updated between 2023 and 2026.", "source_edition": "RTP Message Specifications not consulted (terms not accepted); the record rests on public bank and processor pages read 2026-09-19, and on the RTP Operating Rules effective 2026-06-01 for how a reject works", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "primary_not_public": true, "corroboration": [ { "source_url": "https://triceapi.readme.io/reference/rtp-system-codes", "source_class": "secondary", "source_title": "RTP / FedNOW / ACH System Codes (Trice)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms AM12 is listed as an RTP reject code meaning the amount is wrong or missing." }, { "source_url": "https://www.cuanswers.com/wp-content/uploads/Return-Codes.pdf", "source_class": "secondary", "source_title": "RTP Return Codes (CU*Answers)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms AM12 is listed as an RTP reject code meaning the amount is wrong or missing." } ] }, "rail_name": "RTP Payment Rejects", "governing_authority": "The Clearing House", "snapshot": "2026-09-19", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for RTP credit transfer (pacs.008). Its own scope line reads: an RTP credit transfer.", "from": "applies_to" }, { "kind": "not_public", "label": "the operator's own text", "needs": "what the operator's own text says, which Orca has not read", "detail": "The Clearing House's own text is not the source for this code: it is not public, or not under terms Orca can use. It rests on 2 named public sources, so a term set by agreement rather than by a published rule is not Orca's to state.", "from": "currency.primary_not_public" } ] }, { "uid": "rtp-reject:AM13", "id": "AM13", "rail": "rtp-reject", "kind": "reason-code", "name": "Amount above the RTP network limit", "group": "network", "summary": "The amount is above the limit the network itself sets; Trice and CU*Answers name TCH's limit. An ISO 20022 status reason code (ExternalStatusReason1Code). The meaning given is the one the public bank and processor pages agree on for RTP; ISO's generic definition (an amount above the clearing system's limit) is a fallback only where they say nothing more. [Inference] The RTP System sends it, since the limit is the network's own; no source read says so directly.", "triggers": [ "The payment is for more than $10,000,000, the general RTP transaction limit (Operating Rules II.C.2) [Inference that this is the limit meant]" ], "actions": [ "Sender: pay the amount by a rail without this ceiling, such as a wire, or as the parties agree [Inference]" ], "retry": { "allowed": false, "rule": "Not for the same amount on RTP." }, "facts": { "return_windows": [ { "action": "reject", "by": "RTP System", "deadline": "On receipt, before the RTP System releases the payment message to the receiving participant." } ], "applies_to": "an RTP credit transfer" }, "caveat": "Same code, different rail: FedNow, SEPA and other ISO 20022 rails use their own lists and meanings, so never carry a meaning over from them.", "related": [ "rtp-reject:AM02", "rtp-reject:AM14" ], "basis": { "sources": "Listed as an RTP reject code by the Cross River Bank request and response codes page (family A); the Trice RTP system codes page (family B); the CU*Answers RTP Return Codes PDF, Appendix B (family C), all read 2026-09-19; the families agree on the meaning. ISO 20022 External Code Sets 2Q2026: in ExternalStatusReason1Code. Reject mechanics from the TCH RTP Operating Rules effective 2026-06-01, Rules IV.A, V.C and V.E.3. No TCH code list was consulted: the permitted list sits in the RTP Technical Specifications, under terms Orca has not accepted.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: no public source dates it", "effective_to": null, "effective_note": "No public source read says when this code became permitted on RTP [Unverified]. The pages it rests on were published or updated between 2023 and 2026.", "source_edition": "RTP Message Specifications not consulted (terms not accepted); the record rests on public bank and processor pages read 2026-09-19, and on the RTP Operating Rules effective 2026-06-01 for how a reject works", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "primary_not_public": true, "corroboration": [ { "source_url": "https://triceapi.readme.io/reference/rtp-system-codes", "source_class": "secondary", "source_title": "RTP / FedNOW / ACH System Codes (Trice)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms AM13 is listed as an RTP reject code meaning the amount is above the network's own limit." }, { "source_url": "https://www.cuanswers.com/wp-content/uploads/Return-Codes.pdf", "source_class": "secondary", "source_title": "RTP Return Codes (CU*Answers)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms AM13 is listed as an RTP reject code meaning the amount is above the network's own limit." } ] }, "rail_name": "RTP Payment Rejects", "governing_authority": "The Clearing House", "snapshot": "2026-09-19", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for RTP credit transfer (pacs.008). Its own scope line reads: an RTP credit transfer.", "from": "applies_to" }, { "kind": "not_public", "label": "the operator's own text", "needs": "what the operator's own text says, which Orca has not read", "detail": "The Clearing House's own text is not the source for this code: it is not public, or not under terms Orca can use. It rests on 2 named public sources, so a term set by agreement rather than by a published rule is not Orca's to state.", "from": "currency.primary_not_public" } ] }, { "uid": "rtp-reject:AM14", "id": "AM14", "rail": "rtp-reject", "kind": "reason-code", "name": "Amount above a limit agreed between bank and customer", "group": "administrative", "summary": "The amount is above a limit agreed between a bank and its customer. An ISO 20022 status reason code (ExternalStatusReason1Code). The meaning given is the one the public bank and processor pages agree on for RTP; ISO's generic definition is a fallback only where they say nothing more. No public source read says whether the receiving participant or the RTP System sends it, so both are linked [Inference].", "triggers": [ "The sender's bank has a lower per payment limit for this sender than the amount [Inference]" ], "actions": [ "Sender: ask its bank about its limit, or send a smaller amount or use another rail [Inference]" ], "retry": { "allowed": false, "rule": "Not for the same amount while the limit stands." }, "facts": { "return_windows": [ { "action": "reject", "by": "Receiving Participant", "deadline": "Within the response time the RTP Technical Specifications set; the figure is not in the public Operating Rules. If the receiving participant has not answered by then, TCH cancels the payment and tells both participants." }, { "action": "reject", "by": "RTP System", "deadline": "On receipt, before the RTP System releases the payment message to the receiving participant." } ], "applies_to": "an RTP credit transfer" }, "caveat": "Under Operating Rules II.C.2 a sending participant may set a lower limit for its senders but a receiving participant may not set one for its receivers, so AM14 sent by a receiving participant would sit badly with the rules [Inference]. Same code, different rail: FedNow, SEPA and other ISO 20022 rails use their own lists and meanings, so never carry a meaning over from them.", "related": [ "rtp-reject:AM02", "rtp-reject:AM13" ], "basis": { "sources": "Listed as an RTP reject code by the Cross River Bank request and response codes page (family A); the Trice RTP system codes page (family B); the CU*Answers RTP Return Codes PDF, Appendix B (family C), all read 2026-09-19; the families agree on the meaning. ISO 20022 External Code Sets 2Q2026: in ExternalStatusReason1Code. Reject mechanics from the TCH RTP Operating Rules effective 2026-06-01, Rules IV.A, V.C and V.E.3. No TCH code list was consulted: the permitted list sits in the RTP Technical Specifications, under terms Orca has not accepted.", "confidence": "low" }, "currency": { "effective_since": "Unknown: no public source dates it", "effective_to": null, "effective_note": "No public source read says when this code became permitted on RTP [Unverified]. The pages it rests on were published or updated between 2023 and 2026.", "source_edition": "RTP Message Specifications not consulted (terms not accepted); the record rests on public bank and processor pages read 2026-09-19, and on the RTP Operating Rules effective 2026-06-01 for how a reject works", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "primary_not_public": true, "corroboration": [ { "source_url": "https://triceapi.readme.io/reference/rtp-system-codes", "source_class": "secondary", "source_title": "RTP / FedNOW / ACH System Codes (Trice)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms AM14 is listed as an RTP reject code meaning the amount is above a limit agreed between bank and customer." }, { "source_url": "https://www.cuanswers.com/wp-content/uploads/Return-Codes.pdf", "source_class": "secondary", "source_title": "RTP Return Codes (CU*Answers)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms AM14 is listed as an RTP reject code meaning the amount is above a limit agreed between bank and customer." } ] }, "rail_name": "RTP Payment Rejects", "governing_authority": "The Clearing House", "snapshot": "2026-09-19", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for RTP credit transfer (pacs.008). Its own scope line reads: an RTP credit transfer.", "from": "applies_to" }, { "kind": "not_public", "label": "the operator's own text", "needs": "what the operator's own text says, which Orca has not read", "detail": "The Clearing House's own text is not the source for this code: it is not public, or not under terms Orca can use. It rests on 2 named public sources, so a term set by agreement rather than by a published rule is not Orca's to state.", "from": "currency.primary_not_public" } ] }, { "uid": "rtp-reject:BE04", "id": "BE04", "rail": "rtp-reject", "kind": "reason-code", "name": "Receiver's address wrong or missing", "group": "administrative", "summary": "The receiver's address is wrong or missing. An ISO 20022 status reason code (ExternalStatusReason1Code). The meaning given is the one the public bank and processor pages agree on for RTP; ISO's generic definition is a fallback only where they say nothing more. No public source read says whether the receiving participant or the RTP System sends it, so both are linked [Inference].", "triggers": [ "The message lacked a receiver address the receiving participant or network needs [Inference]" ], "actions": [ "Sender: supply a correct receiver address and send a new payment" ], "retry": { "allowed": true, "rule": "Send a new payment message once the fault is fixed; the rejected payment never settled, so there is nothing to reverse or return." }, "facts": { "return_windows": [ { "action": "reject", "by": "Receiving Participant", "deadline": "Within the response time the RTP Technical Specifications set; the figure is not in the public Operating Rules. If the receiving participant has not answered by then, TCH cancels the payment and tells both participants." }, { "action": "reject", "by": "RTP System", "deadline": "On receipt, before the RTP System releases the payment message to the receiving participant." } ], "applies_to": "an RTP credit transfer" }, "caveat": "Same code, different rail: FedNow, SEPA and other ISO 20022 rails use their own lists and meanings, so never carry a meaning over from them.", "related": [ "rtp-reject:BE07" ], "basis": { "sources": "Listed as an RTP reject code by the Cross River Bank request and response codes page (family A); the Trice RTP system codes page (family B); the CU*Answers RTP Return Codes PDF, Appendix B (family C), all read 2026-09-19; the families agree on the meaning. ISO 20022 External Code Sets 2Q2026: in ExternalStatusReason1Code. Reject mechanics from the TCH RTP Operating Rules effective 2026-06-01, Rules IV.A, V.C and V.E.3. No TCH code list was consulted: the permitted list sits in the RTP Technical Specifications, under terms Orca has not accepted.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: no public source dates it", "effective_to": null, "effective_note": "No public source read says when this code became permitted on RTP [Unverified]. The pages it rests on were published or updated between 2023 and 2026.", "source_edition": "RTP Message Specifications not consulted (terms not accepted); the record rests on public bank and processor pages read 2026-09-19, and on the RTP Operating Rules effective 2026-06-01 for how a reject works", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "primary_not_public": true, "corroboration": [ { "source_url": "https://triceapi.readme.io/reference/rtp-system-codes", "source_class": "secondary", "source_title": "RTP / FedNOW / ACH System Codes (Trice)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms BE04 is listed as an RTP reject code meaning the receiver's address is wrong or missing." }, { "source_url": "https://www.cuanswers.com/wp-content/uploads/Return-Codes.pdf", "source_class": "secondary", "source_title": "RTP Return Codes (CU*Answers)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms BE04 is listed as an RTP reject code meaning the receiver's address is wrong or missing." } ] }, "rail_name": "RTP Payment Rejects", "governing_authority": "The Clearing House", "snapshot": "2026-09-19", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for RTP credit transfer (pacs.008). Its own scope line reads: an RTP credit transfer.", "from": "applies_to" }, { "kind": "not_public", "label": "the operator's own text", "needs": "what the operator's own text says, which Orca has not read", "detail": "The Clearing House's own text is not the source for this code: it is not public, or not under terms Orca can use. It rests on 2 named public sources, so a term set by agreement rather than by a published rule is not Orca's to state.", "from": "currency.primary_not_public" } ] }, { "uid": "rtp-reject:BE06", "id": "BE06", "rail": "rtp-reject", "kind": "reason-code", "name": "Receiver not known to the receiving participant", "group": "account", "summary": "The receiving participant does not know the receiver, or the receiver is no longer on its books. An ISO 20022 status reason code (ExternalStatusReason1Code). The meaning given is the one the public bank and processor pages agree on for RTP; ISO's generic definition is a fallback only where they say nothing more. The receiving participant sends it in its reject response [Inference: Rule V.C.1 lets the receiving participant reject when the receiver's account is invalid].", "triggers": [ "The receiver's relationship with the receiving participant has ended [Inference]", "The account details point at a customer the receiving participant cannot find" ], "actions": [ "Sender: confirm the receiver's details and bank before sending again" ], "retry": { "allowed": false, "rule": "Not with the same details. Confirm who and where the receiver is first." }, "facts": { "return_windows": [ { "action": "reject", "by": "Receiving Participant", "deadline": "Within the response time the RTP Technical Specifications set; the figure is not in the public Operating Rules. If the receiving participant has not answered by then, TCH cancels the payment and tells both participants." } ], "applies_to": "an RTP credit transfer" }, "caveat": "A receiving participant may rely on the account number and need not check that the name matches (Operating Rules V.D), so BE06 is about an unknown or departed customer, not a name mismatch [Inference]. Same code, different rail: FedNow, SEPA and other ISO 20022 rails use their own lists and meanings, so never carry a meaning over from them.", "related": [ "rtp-reject:AC03", "rtp-reject:MD07" ], "basis": { "sources": "Listed as an RTP reject code by the Cross River Bank request and response codes page (family A); the Trice RTP system codes page (family B); the CU*Answers RTP Return Codes PDF, Appendix B (family C), all read 2026-09-19; the families agree on the meaning. ISO 20022 External Code Sets 2Q2026: in ExternalStatusReason1Code. Reject mechanics from the TCH RTP Operating Rules effective 2026-06-01, Rules IV.A, V.C and V.E.3. No TCH code list was consulted: the permitted list sits in the RTP Technical Specifications, under terms Orca has not accepted.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: no public source dates it", "effective_to": null, "effective_note": "No public source read says when this code became permitted on RTP [Unverified]. The pages it rests on were published or updated between 2023 and 2026.", "source_edition": "RTP Message Specifications not consulted (terms not accepted); the record rests on public bank and processor pages read 2026-09-19, and on the RTP Operating Rules effective 2026-06-01 for how a reject works", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "primary_not_public": true, "corroboration": [ { "source_url": "https://triceapi.readme.io/reference/rtp-system-codes", "source_class": "secondary", "source_title": "RTP / FedNOW / ACH System Codes (Trice)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms BE06 is listed as an RTP reject code meaning the receiver is not known to the receiving participant." }, { "source_url": "https://www.cuanswers.com/wp-content/uploads/Return-Codes.pdf", "source_class": "secondary", "source_title": "RTP Return Codes (CU*Answers)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms BE06 is listed as an RTP reject code meaning the receiver is not known to the receiving participant." } ] }, "rail_name": "RTP Payment Rejects", "governing_authority": "The Clearing House", "snapshot": "2026-09-19", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for RTP credit transfer (pacs.008). Its own scope line reads: an RTP credit transfer.", "from": "applies_to" }, { "kind": "not_public", "label": "the operator's own text", "needs": "what the operator's own text says, which Orca has not read", "detail": "The Clearing House's own text is not the source for this code: it is not public, or not under terms Orca can use. It rests on 2 named public sources, so a term set by agreement rather than by a published rule is not Orca's to state.", "from": "currency.primary_not_public" } ] }, { "uid": "rtp-reject:BE07", "id": "BE07", "rail": "rtp-reject", "kind": "reason-code", "name": "Sender's address wrong or missing", "group": "administrative", "summary": "The sender's address is wrong or missing. An ISO 20022 status reason code (ExternalStatusReason1Code). The meaning given is the one the public bank and processor pages agree on for RTP; ISO's generic definition is a fallback only where they say nothing more. No public source read says whether the receiving participant or the RTP System sends it, so both are linked [Inference].", "triggers": [ "The sending participant left out or garbled the sender's address" ], "actions": [ "Sending participant: supply the sender's address and send a new payment" ], "retry": { "allowed": true, "rule": "Send a new payment message once the fault is fixed; the rejected payment never settled, so there is nothing to reverse or return." }, "facts": { "return_windows": [ { "action": "reject", "by": "Receiving Participant", "deadline": "Within the response time the RTP Technical Specifications set; the figure is not in the public Operating Rules. If the receiving participant has not answered by then, TCH cancels the payment and tells both participants." }, { "action": "reject", "by": "RTP System", "deadline": "On receipt, before the RTP System releases the payment message to the receiving participant." } ], "applies_to": "an RTP credit transfer" }, "caveat": "Same code, different rail: FedNow, SEPA and other ISO 20022 rails use their own lists and meanings, so never carry a meaning over from them.", "related": [ "rtp-reject:BE04" ], "basis": { "sources": "Listed as an RTP reject code by the Cross River Bank request and response codes page (family A); the Trice RTP system codes page (family B); the CU*Answers RTP Return Codes PDF, Appendix B (family C), all read 2026-09-19; the families agree on the meaning. ISO 20022 External Code Sets 2Q2026: in ExternalStatusReason1Code. Reject mechanics from the TCH RTP Operating Rules effective 2026-06-01, Rules IV.A, V.C and V.E.3. No TCH code list was consulted: the permitted list sits in the RTP Technical Specifications, under terms Orca has not accepted.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: no public source dates it", "effective_to": null, "effective_note": "No public source read says when this code became permitted on RTP [Unverified]. The pages it rests on were published or updated between 2023 and 2026.", "source_edition": "RTP Message Specifications not consulted (terms not accepted); the record rests on public bank and processor pages read 2026-09-19, and on the RTP Operating Rules effective 2026-06-01 for how a reject works", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "primary_not_public": true, "corroboration": [ { "source_url": "https://triceapi.readme.io/reference/rtp-system-codes", "source_class": "secondary", "source_title": "RTP / FedNOW / ACH System Codes (Trice)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms BE07 is listed as an RTP reject code meaning the sender's address is wrong or missing." }, { "source_url": "https://www.cuanswers.com/wp-content/uploads/Return-Codes.pdf", "source_class": "secondary", "source_title": "RTP Return Codes (CU*Answers)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms BE07 is listed as an RTP reject code meaning the sender's address is wrong or missing." } ] }, "rail_name": "RTP Payment Rejects", "governing_authority": "The Clearing House", "snapshot": "2026-09-19", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for RTP credit transfer (pacs.008). Its own scope line reads: an RTP credit transfer.", "from": "applies_to" }, { "kind": "not_public", "label": "the operator's own text", "needs": "what the operator's own text says, which Orca has not read", "detail": "The Clearing House's own text is not the source for this code: it is not public, or not under terms Orca can use. It rests on 2 named public sources, so a term set by agreement rather than by a published rule is not Orca's to state.", "from": "currency.primary_not_public" } ] }, { "uid": "rtp-reject:BE10", "id": "BE10", "rail": "rtp-reject", "kind": "reason-code", "name": "Sender's country code wrong or missing", "group": "administrative", "summary": "The sender's country code is wrong or missing. An ISO 20022 status reason code (ExternalStatusReason1Code). The meaning given is the one the public bank and processor pages agree on for RTP; ISO's generic definition is a fallback only where they say nothing more. No public source read says whether the receiving participant or the RTP System sends it, so both are linked [Inference].", "triggers": [ "The country code field for the sender is empty or not a valid code" ], "actions": [ "Sending participant: correct the sender's country code and send a new payment" ], "retry": { "allowed": true, "rule": "Send a new payment message once the fault is fixed; the rejected payment never settled, so there is nothing to reverse or return." }, "facts": { "return_windows": [ { "action": "reject", "by": "Receiving Participant", "deadline": "Within the response time the RTP Technical Specifications set; the figure is not in the public Operating Rules. If the receiving participant has not answered by then, TCH cancels the payment and tells both participants." }, { "action": "reject", "by": "RTP System", "deadline": "On receipt, before the RTP System releases the payment message to the receiving participant." } ], "applies_to": "an RTP credit transfer" }, "caveat": "Both accounts in an RTP payment must be in the United States (Operating Rules II.E.2). Same code, different rail: FedNow, SEPA and other ISO 20022 rails use their own lists and meanings, so never carry a meaning over from them.", "related": [ "rtp-reject:BE11" ], "basis": { "sources": "Listed as an RTP reject code by the Cross River Bank request and response codes page (family A); the Trice RTP system codes page (family B); the CU*Answers RTP Return Codes PDF, Appendix B (family C), all read 2026-09-19; the families agree on the meaning. ISO 20022 External Code Sets 2Q2026: in ExternalStatusReason1Code. Reject mechanics from the TCH RTP Operating Rules effective 2026-06-01, Rules IV.A, V.C and V.E.3. No TCH code list was consulted: the permitted list sits in the RTP Technical Specifications, under terms Orca has not accepted.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: no public source dates it", "effective_to": null, "effective_note": "No public source read says when this code became permitted on RTP [Unverified]. The pages it rests on were published or updated between 2023 and 2026.", "source_edition": "RTP Message Specifications not consulted (terms not accepted); the record rests on public bank and processor pages read 2026-09-19, and on the RTP Operating Rules effective 2026-06-01 for how a reject works", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "primary_not_public": true, "corroboration": [ { "source_url": "https://triceapi.readme.io/reference/rtp-system-codes", "source_class": "secondary", "source_title": "RTP / FedNOW / ACH System Codes (Trice)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms BE10 is listed as an RTP reject code meaning the sender's country code is wrong or missing." }, { "source_url": "https://www.cuanswers.com/wp-content/uploads/Return-Codes.pdf", "source_class": "secondary", "source_title": "RTP Return Codes (CU*Answers)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms BE10 is listed as an RTP reject code meaning the sender's country code is wrong or missing." } ] }, "rail_name": "RTP Payment Rejects", "governing_authority": "The Clearing House", "snapshot": "2026-09-19", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for RTP credit transfer (pacs.008). Its own scope line reads: an RTP credit transfer.", "from": "applies_to" }, { "kind": "not_public", "label": "the operator's own text", "needs": "what the operator's own text says, which Orca has not read", "detail": "The Clearing House's own text is not the source for this code: it is not public, or not under terms Orca can use. It rests on 2 named public sources, so a term set by agreement rather than by a published rule is not Orca's to state.", "from": "currency.primary_not_public" } ] }, { "uid": "rtp-reject:BE11", "id": "BE11", "rail": "rtp-reject", "kind": "reason-code", "name": "Receiver's country code wrong or missing", "group": "administrative", "summary": "The receiver's country code is wrong or missing. An ISO 20022 status reason code (ExternalStatusReason1Code). The meaning given is the one the public bank and processor pages agree on for RTP; ISO's generic definition is a fallback only where they say nothing more. No public source read says whether the receiving participant or the RTP System sends it, so both are linked [Inference].", "triggers": [ "The country code field for the receiver is empty or not a valid code" ], "actions": [ "Sender: correct the receiver's country code and send a new payment" ], "retry": { "allowed": true, "rule": "Send a new payment message once the fault is fixed; the rejected payment never settled, so there is nothing to reverse or return." }, "facts": { "return_windows": [ { "action": "reject", "by": "Receiving Participant", "deadline": "Within the response time the RTP Technical Specifications set; the figure is not in the public Operating Rules. If the receiving participant has not answered by then, TCH cancels the payment and tells both participants." }, { "action": "reject", "by": "RTP System", "deadline": "On receipt, before the RTP System releases the payment message to the receiving participant." } ], "applies_to": "an RTP credit transfer" }, "caveat": "Both accounts in an RTP payment must be in the United States (Operating Rules II.E.2). Same code, different rail: FedNow, SEPA and other ISO 20022 rails use their own lists and meanings, so never carry a meaning over from them.", "related": [ "rtp-reject:BE10", "rtp-reject:BE14" ], "basis": { "sources": "Listed as an RTP reject code by the Cross River Bank request and response codes page (family A); the Trice RTP system codes page (family B); the CU*Answers RTP Return Codes PDF, Appendix B (family C), all read 2026-09-19; the families agree on the meaning. ISO 20022 External Code Sets 2Q2026: in ExternalStatusReason1Code. Reject mechanics from the TCH RTP Operating Rules effective 2026-06-01, Rules IV.A, V.C and V.E.3. No TCH code list was consulted: the permitted list sits in the RTP Technical Specifications, under terms Orca has not accepted.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: no public source dates it", "effective_to": null, "effective_note": "No public source read says when this code became permitted on RTP [Unverified]. The pages it rests on were published or updated between 2023 and 2026.", "source_edition": "RTP Message Specifications not consulted (terms not accepted); the record rests on public bank and processor pages read 2026-09-19, and on the RTP Operating Rules effective 2026-06-01 for how a reject works", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "primary_not_public": true, "corroboration": [ { "source_url": "https://triceapi.readme.io/reference/rtp-system-codes", "source_class": "secondary", "source_title": "RTP / FedNOW / ACH System Codes (Trice)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms BE11 is listed as an RTP reject code meaning the receiver's country code is wrong or missing." }, { "source_url": "https://www.cuanswers.com/wp-content/uploads/Return-Codes.pdf", "source_class": "secondary", "source_title": "RTP Return Codes (CU*Answers)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms BE11 is listed as an RTP reject code meaning the receiver's country code is wrong or missing." } ] }, "rail_name": "RTP Payment Rejects", "governing_authority": "The Clearing House", "snapshot": "2026-09-19", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for RTP credit transfer (pacs.008). Its own scope line reads: an RTP credit transfer.", "from": "applies_to" }, { "kind": "not_public", "label": "the operator's own text", "needs": "what the operator's own text says, which Orca has not read", "detail": "The Clearing House's own text is not the source for this code: it is not public, or not under terms Orca can use. It rests on 2 named public sources, so a term set by agreement rather than by a published rule is not Orca's to state.", "from": "currency.primary_not_public" } ] }, { "uid": "rtp-reject:BE14", "id": "BE14", "rail": "rtp-reject", "kind": "reason-code", "name": "Receiver's country of residence code wrong or missing", "group": "administrative", "summary": "The code for the receiver's country of residence is wrong or missing. An ISO 20022 status reason code (ExternalStatusReason1Code). The meaning given is the one the public bank and processor pages agree on for RTP; ISO's generic definition is a fallback only where they say nothing more. No public source read says whether the receiving participant or the RTP System sends it, so both are linked [Inference].", "triggers": [ "The receiver's residence country is left out or badly coded" ], "actions": [ "Sender: supply the receiver's country of residence and send a new payment" ], "retry": { "allowed": true, "rule": "Send a new payment message once the fault is fixed; the rejected payment never settled, so there is nothing to reverse or return." }, "facts": { "return_windows": [ { "action": "reject", "by": "Receiving Participant", "deadline": "Within the response time the RTP Technical Specifications set; the figure is not in the public Operating Rules. If the receiving participant has not answered by then, TCH cancels the payment and tells both participants." }, { "action": "reject", "by": "RTP System", "deadline": "On receipt, before the RTP System releases the payment message to the receiving participant." } ], "applies_to": "an RTP credit transfer" }, "caveat": "Same code, different rail: FedNow, SEPA and other ISO 20022 rails use their own lists and meanings, so never carry a meaning over from them.", "related": [ "rtp-reject:BE11" ], "basis": { "sources": "Listed as an RTP reject code by the Cross River Bank request and response codes page (family A); the Trice RTP system codes page (family B), all read 2026-09-19; Cross River Bank names the receiver's country of residence; Trice says only that a country code is missing; the two do not conflict. ISO 20022 External Code Sets 2Q2026: in ExternalStatusReason1Code. Reject mechanics from the TCH RTP Operating Rules effective 2026-06-01, Rules IV.A, V.C and V.E.3. No TCH code list was consulted: the permitted list sits in the RTP Technical Specifications, under terms Orca has not accepted.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: no public source dates it", "effective_to": null, "effective_note": "No public source read says when this code became permitted on RTP [Unverified]. The pages it rests on were published or updated between 2023 and 2026.", "source_edition": "RTP Message Specifications not consulted (terms not accepted); the record rests on public bank and processor pages read 2026-09-19, and on the RTP Operating Rules effective 2026-06-01 for how a reject works", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "primary_not_public": true, "corroboration": [ { "source_url": "https://docs.crossriver.com/apis/payments/instant-payments/request-and-response-codes-instant-payments", "source_class": "secondary", "source_title": "Request and response codes: Instant payments (Cross River Bank)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms BE14 is listed as an RTP reject code meaning the receiver's country of residence code is wrong or missing." }, { "source_url": "https://triceapi.readme.io/reference/rtp-system-codes", "source_class": "secondary", "source_title": "RTP / FedNOW / ACH System Codes (Trice)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms BE14 is listed as an RTP reject code meaning the receiver's country of residence code is wrong or missing." } ] }, "rail_name": "RTP Payment Rejects", "governing_authority": "The Clearing House", "snapshot": "2026-09-19", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for RTP credit transfer (pacs.008). Its own scope line reads: an RTP credit transfer.", "from": "applies_to" }, { "kind": "not_public", "label": "the operator's own text", "needs": "what the operator's own text says, which Orca has not read", "detail": "The Clearing House's own text is not the source for this code: it is not public, or not under terms Orca can use. It rests on 2 named public sources, so a term set by agreement rather than by a published rule is not Orca's to state.", "from": "currency.primary_not_public" } ] }, { "uid": "rtp-reject:BE16", "id": "BE16", "rail": "rtp-reject", "kind": "reason-code", "name": "Sender's identification wrong or missing", "group": "administrative", "summary": "An identification code for the sender is wrong or missing. An ISO 20022 status reason code (ExternalStatusReason1Code). The meaning given is the one the public bank and processor pages agree on for RTP; ISO's generic definition is a fallback only where they say nothing more. No public source read says whether the receiving participant or the RTP System sends it, so both are linked [Inference].", "triggers": [ "The sender's identifier the message needs is absent or malformed [Inference]" ], "actions": [ "Sending participant: supply a valid sender identification and send a new payment" ], "retry": { "allowed": true, "rule": "Send a new payment message once the fault is fixed; the rejected payment never settled, so there is nothing to reverse or return." }, "facts": { "return_windows": [ { "action": "reject", "by": "Receiving Participant", "deadline": "Within the response time the RTP Technical Specifications set; the figure is not in the public Operating Rules. If the receiving participant has not answered by then, TCH cancels the payment and tells both participants." }, { "action": "reject", "by": "RTP System", "deadline": "On receipt, before the RTP System releases the payment message to the receiving participant." } ], "applies_to": "an RTP credit transfer" }, "caveat": "Same code, different rail: FedNow, SEPA and other ISO 20022 rails use their own lists and meanings, so never carry a meaning over from them.", "related": [ "rtp-reject:BE17" ], "basis": { "sources": "Listed as an RTP reject code by the Cross River Bank request and response codes page (family A); the Trice RTP system codes page (family B); the CU*Answers RTP Return Codes PDF, Appendix B (family C), all read 2026-09-19; the families agree on the meaning. ISO 20022 External Code Sets 2Q2026: in ExternalStatusReason1Code. Reject mechanics from the TCH RTP Operating Rules effective 2026-06-01, Rules IV.A, V.C and V.E.3. No TCH code list was consulted: the permitted list sits in the RTP Technical Specifications, under terms Orca has not accepted.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: no public source dates it", "effective_to": null, "effective_note": "No public source read says when this code became permitted on RTP [Unverified]. The pages it rests on were published or updated between 2023 and 2026.", "source_edition": "RTP Message Specifications not consulted (terms not accepted); the record rests on public bank and processor pages read 2026-09-19, and on the RTP Operating Rules effective 2026-06-01 for how a reject works", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "primary_not_public": true, "corroboration": [ { "source_url": "https://triceapi.readme.io/reference/rtp-system-codes", "source_class": "secondary", "source_title": "RTP / FedNOW / ACH System Codes (Trice)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms BE16 is listed as an RTP reject code meaning the sender's identification is wrong or missing." }, { "source_url": "https://www.cuanswers.com/wp-content/uploads/Return-Codes.pdf", "source_class": "secondary", "source_title": "RTP Return Codes (CU*Answers)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms BE16 is listed as an RTP reject code meaning the sender's identification is wrong or missing." } ] }, "rail_name": "RTP Payment Rejects", "governing_authority": "The Clearing House", "snapshot": "2026-09-19", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for RTP credit transfer (pacs.008). Its own scope line reads: an RTP credit transfer.", "from": "applies_to" }, { "kind": "not_public", "label": "the operator's own text", "needs": "what the operator's own text says, which Orca has not read", "detail": "The Clearing House's own text is not the source for this code: it is not public, or not under terms Orca can use. It rests on 2 named public sources, so a term set by agreement rather than by a published rule is not Orca's to state.", "from": "currency.primary_not_public" } ] }, { "uid": "rtp-reject:BE17", "id": "BE17", "rail": "rtp-reject", "kind": "reason-code", "name": "Receiver's identification wrong or missing", "group": "administrative", "summary": "An identification code for the receiver is wrong or missing. An ISO 20022 status reason code (ExternalStatusReason1Code). The meaning given is the one the public bank and processor pages agree on for RTP; ISO's generic definition is a fallback only where they say nothing more. The receiving participant sends it in its reject response [Inference: the Oracle page marks it as used by the FI only].", "triggers": [ "The receiver's identifier in the message is absent or does not match what the receiving participant holds [Inference]" ], "actions": [ "Sender: confirm the receiver's identification and send a new payment" ], "retry": { "allowed": true, "rule": "Send a new payment message once the fault is fixed; the rejected payment never settled, so there is nothing to reverse or return." }, "facts": { "return_windows": [ { "action": "reject", "by": "Receiving Participant", "deadline": "Within the response time the RTP Technical Specifications set; the figure is not in the public Operating Rules. If the receiving participant has not answered by then, TCH cancels the payment and tells both participants." } ], "applies_to": "an RTP credit transfer" }, "caveat": "Same code, different rail: FedNow, SEPA and other ISO 20022 rails use their own lists and meanings, so never carry a meaning over from them.", "related": [ "rtp-reject:BE16" ], "basis": { "sources": "Listed as an RTP reject code by the Cross River Bank request and response codes page (family A); the Trice RTP system codes page (family B); the CU*Answers RTP Return Codes PDF, Appendix B (family C); the Oracle US RTP reason code mapping page (family D), all read 2026-09-19; the families agree on the meaning. ISO 20022 External Code Sets 2Q2026: in ExternalStatusReason1Code. Reject mechanics from the TCH RTP Operating Rules effective 2026-06-01, Rules IV.A, V.C and V.E.3. No TCH code list was consulted: the permitted list sits in the RTP Technical Specifications, under terms Orca has not accepted.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: no public source dates it", "effective_to": null, "effective_note": "No public source read says when this code became permitted on RTP [Unverified]. The pages it rests on were published or updated between 2023 and 2026.", "source_edition": "RTP Message Specifications not consulted (terms not accepted); the record rests on public bank and processor pages read 2026-09-19, and on the RTP Operating Rules effective 2026-06-01 for how a reject works", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "primary_not_public": true, "corroboration": [ { "source_url": "https://triceapi.readme.io/reference/rtp-system-codes", "source_class": "secondary", "source_title": "RTP / FedNOW / ACH System Codes (Trice)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms BE17 is listed as an RTP reject code meaning the receiver's identification is wrong or missing." }, { "source_url": "https://www.cuanswers.com/wp-content/uploads/Return-Codes.pdf", "source_class": "secondary", "source_title": "RTP Return Codes (CU*Answers)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms BE17 is listed as an RTP reject code meaning the receiver's identification is wrong or missing." } ] }, "rail_name": "RTP Payment Rejects", "governing_authority": "The Clearing House", "snapshot": "2026-09-19", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for RTP credit transfer (pacs.008). Its own scope line reads: an RTP credit transfer.", "from": "applies_to" }, { "kind": "not_public", "label": "the operator's own text", "needs": "what the operator's own text says, which Orca has not read", "detail": "The Clearing House's own text is not the source for this code: it is not public, or not under terms Orca can use. It rests on 2 named public sources, so a term set by agreement rather than by a published rule is not Orca's to state.", "from": "currency.primary_not_public" } ] }, { "uid": "rtp-reject:DS0H", "id": "DS0H", "rail": "rtp-reject", "kind": "reason-code", "name": "Signer not allowed for the account", "group": "authorization", "summary": "The person who authorized the payment may not sign for the account. An ISO 20022 status reason code (ExternalStatusReason1Code). The meaning given is the one the public bank and processor pages agree on for RTP; ISO's generic definition is a fallback only where they say nothing more. No public source read says whether the receiving participant or the RTP System sends it, so both are linked [Inference].", "triggers": [ "The payment was authorized by someone without authority over the sending account [Inference]" ], "actions": [ "Sending participant: check who authorized the payment and get a valid authorization before sending a new one" ], "retry": { "allowed": true, "rule": "Only as a new payment authorized by someone entitled to sign [Inference]." }, "facts": { "return_windows": [ { "action": "reject", "by": "Receiving Participant", "deadline": "Within the response time the RTP Technical Specifications set; the figure is not in the public Operating Rules. If the receiving participant has not answered by then, TCH cancels the payment and tells both participants." }, { "action": "reject", "by": "RTP System", "deadline": "On receipt, before the RTP System releases the payment message to the receiving participant." } ], "applies_to": "an RTP credit transfer" }, "caveat": "Same code, different rail: FedNow, SEPA and other ISO 20022 rails use their own lists and meanings, so never carry a meaning over from them.", "related": [], "basis": { "sources": "Listed as an RTP reject code by the Cross River Bank request and response codes page (family A); the Trice RTP system codes page (family B), all read 2026-09-19; the families agree on the meaning. ISO 20022 External Code Sets 2Q2026: in ExternalStatusReason1Code. Reject mechanics from the TCH RTP Operating Rules effective 2026-06-01, Rules IV.A, V.C and V.E.3. No TCH code list was consulted: the permitted list sits in the RTP Technical Specifications, under terms Orca has not accepted.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: no public source dates it", "effective_to": null, "effective_note": "No public source read says when this code became permitted on RTP [Unverified]. The pages it rests on were published or updated between 2023 and 2026.", "source_edition": "RTP Message Specifications not consulted (terms not accepted); the record rests on public bank and processor pages read 2026-09-19, and on the RTP Operating Rules effective 2026-06-01 for how a reject works", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "primary_not_public": true, "corroboration": [ { "source_url": "https://docs.crossriver.com/apis/payments/instant-payments/request-and-response-codes-instant-payments", "source_class": "secondary", "source_title": "Request and response codes: Instant payments (Cross River Bank)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms DS0H is listed as an RTP reject code meaning the signer is not allowed for the account." }, { "source_url": "https://triceapi.readme.io/reference/rtp-system-codes", "source_class": "secondary", "source_title": "RTP / FedNOW / ACH System Codes (Trice)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms DS0H is listed as an RTP reject code meaning the signer is not allowed for the account." } ] }, "rail_name": "RTP Payment Rejects", "governing_authority": "The Clearing House", "snapshot": "2026-09-19", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for RTP credit transfer (pacs.008). Its own scope line reads: an RTP credit transfer.", "from": "applies_to" }, { "kind": "not_public", "label": "the operator's own text", "needs": "what the operator's own text says, which Orca has not read", "detail": "The Clearing House's own text is not the source for this code: it is not public, or not under terms Orca can use. It rests on 2 named public sources, so a term set by agreement rather than by a published rule is not Orca's to state.", "from": "currency.primary_not_public" } ] }, { "uid": "rtp-reject:DS24", "id": "DS24", "rail": "rtp-reject", "kind": "reason-code", "name": "Payment timed out before it completed", "group": "network", "summary": "The payment was not completed in time and was undone; Trice calls it the TCH time-out. An ISO 20022 status reason code (ExternalStatusReason1Code). The meaning given is the one the public bank and processor pages agree on for RTP; ISO's generic definition (waiting time expired because the order was incomplete) is a fallback only where they say nothing more. The RTP System reports it when TCH cancels a payment the receiving participant did not answer in time [Inference from the Trice and CU*Answers wording].", "triggers": [ "The receiving participant did not answer the payment message within the response time the technical specifications set" ], "actions": [ "Sending participant: treat the payment as not made; a cancelled payment never settles (Operating Rules VI.E.5)", "Send it again only as a new payment message (Operating Rules IV.A.4)" ], "retry": { "allowed": true, "rule": "Only as a new payment message that meets the requirements for new messages (Operating Rules IV.A.4)." }, "facts": { "return_windows": [ { "action": "time-out cancellation", "by": "RTP System", "deadline": "Within the response time the RTP Technical Specifications set; the figure is not in the public Operating Rules. If the receiving participant has not answered by then, TCH cancels the payment and tells both participants." } ], "applies_to": "an RTP credit transfer" }, "caveat": "Under the Operating Rules a time-out is a cancellation by TCH (IV.A.4), not a reject by the receiving participant, so the record raises it in the time-out cancellation. The time-out figure is not public. Same code, different rail: FedNow, SEPA and other ISO 20022 rails use their own lists and meanings, so never carry a meaning over from them.", "related": [], "basis": { "sources": "Listed as an RTP reject code by the Cross River Bank request and response codes page (family A); the Trice RTP system codes page (family B); the CU*Answers RTP Return Codes PDF, Appendix B (family C), all read 2026-09-19; the families agree it reports a time-out; Cross River Bank's mixed FedNow and RTP summary table words it differently and is not used. ISO 20022 External Code Sets 2Q2026: in ExternalStatusReason1Code. Reject mechanics from the TCH RTP Operating Rules effective 2026-06-01, Rules IV.A, V.C and V.E.3. No TCH code list was consulted: the permitted list sits in the RTP Technical Specifications, under terms Orca has not accepted.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: no public source dates it", "effective_to": null, "effective_note": "No public source read says when this code became permitted on RTP [Unverified]. The pages it rests on were published or updated between 2023 and 2026.", "source_edition": "RTP Message Specifications not consulted (terms not accepted); the record rests on public bank and processor pages read 2026-09-19, and on the RTP Operating Rules effective 2026-06-01 for how a reject works", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "primary_not_public": true, "corroboration": [ { "source_url": "https://triceapi.readme.io/reference/rtp-system-codes", "source_class": "secondary", "source_title": "RTP / FedNOW / ACH System Codes (Trice)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms DS24 is listed as an RTP reject code meaning the payment timed out before it completed." }, { "source_url": "https://www.cuanswers.com/wp-content/uploads/Return-Codes.pdf", "source_class": "secondary", "source_title": "RTP Return Codes (CU*Answers)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms DS24 is listed as an RTP reject code meaning the payment timed out before it completed." } ] }, "rail_name": "RTP Payment Rejects", "governing_authority": "The Clearing House", "snapshot": "2026-09-19", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for RTP credit transfer (pacs.008). Its own scope line reads: an RTP credit transfer.", "from": "applies_to" }, { "kind": "not_public", "label": "the operator's own text", "needs": "what the operator's own text says, which Orca has not read", "detail": "The Clearing House's own text is not the source for this code: it is not public, or not under terms Orca can use. It rests on 2 named public sources, so a term set by agreement rather than by a published rule is not Orca's to state.", "from": "currency.primary_not_public" } ] }, { "uid": "rtp-reject:DT04", "id": "DT04", "rail": "rtp-reject", "kind": "reason-code", "name": "Future dating not supported", "group": "administrative", "summary": "The payment asked for a future date, which is not supported. An ISO 20022 status reason code (ExternalStatusReason1Code). The meaning given is the one the public bank and processor pages agree on for RTP; ISO's generic definition is a fallback only where they say nothing more. No public source read says whether the receiving participant or the RTP System sends it, so both are linked [Inference].", "triggers": [ "The sending system set a future execution or settlement date [Inference]" ], "actions": [ "Sending participant: send the payment on the day it should move; RTP settles when the receiving participant accepts" ], "retry": { "allowed": true, "rule": "Send a new payment message once the fault is fixed; the rejected payment never settled, so there is nothing to reverse or return." }, "facts": { "return_windows": [ { "action": "reject", "by": "Receiving Participant", "deadline": "Within the response time the RTP Technical Specifications set; the figure is not in the public Operating Rules. If the receiving participant has not answered by then, TCH cancels the payment and tells both participants." }, { "action": "reject", "by": "RTP System", "deadline": "On receipt, before the RTP System releases the payment message to the receiving participant." } ], "applies_to": "an RTP credit transfer" }, "caveat": "Same code, different rail: FedNow, SEPA and other ISO 20022 rails use their own lists and meanings, so never carry a meaning over from them.", "related": [], "basis": { "sources": "Listed as an RTP reject code by the Cross River Bank request and response codes page (family A); the Trice RTP system codes page (family B); the CU*Answers RTP Return Codes PDF, Appendix B (family C), all read 2026-09-19; the families agree on the meaning. ISO 20022 External Code Sets 2Q2026: in ExternalStatusReason1Code. Reject mechanics from the TCH RTP Operating Rules effective 2026-06-01, Rules IV.A, V.C and V.E.3. No TCH code list was consulted: the permitted list sits in the RTP Technical Specifications, under terms Orca has not accepted.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: no public source dates it", "effective_to": null, "effective_note": "No public source read says when this code became permitted on RTP [Unverified]. The pages it rests on were published or updated between 2023 and 2026.", "source_edition": "RTP Message Specifications not consulted (terms not accepted); the record rests on public bank and processor pages read 2026-09-19, and on the RTP Operating Rules effective 2026-06-01 for how a reject works", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "primary_not_public": true, "corroboration": [ { "source_url": "https://triceapi.readme.io/reference/rtp-system-codes", "source_class": "secondary", "source_title": "RTP / FedNOW / ACH System Codes (Trice)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms DT04 is listed as an RTP reject code meaning future dating is not supported." }, { "source_url": "https://www.cuanswers.com/wp-content/uploads/Return-Codes.pdf", "source_class": "secondary", "source_title": "RTP Return Codes (CU*Answers)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms DT04 is listed as an RTP reject code meaning future dating is not supported." } ] }, "rail_name": "RTP Payment Rejects", "governing_authority": "The Clearing House", "snapshot": "2026-09-19", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for RTP credit transfer (pacs.008). Its own scope line reads: an RTP credit transfer.", "from": "applies_to" }, { "kind": "not_public", "label": "the operator's own text", "needs": "what the operator's own text says, which Orca has not read", "detail": "The Clearing House's own text is not the source for this code: it is not public, or not under terms Orca can use. It rests on 2 named public sources, so a term set by agreement rather than by a published rule is not Orca's to state.", "from": "currency.primary_not_public" } ] }, { "uid": "rtp-reject:DUPL", "id": "DUPL", "rail": "rtp-reject", "kind": "reason-code", "name": "Duplicate of another payment", "group": "administrative", "summary": "The payment duplicates one already sent. An ISO 20022 status reason code (ExternalStatusReason1Code). The meaning given is the one the public bank and processor pages agree on for RTP; ISO's generic definition is a fallback only where they say nothing more. No public source read says whether the receiving participant or the RTP System sends it, so both are linked [Inference]; the Oracle page marks it as used by both the FI and the CI, and TCH may refuse a message that looks like a duplicate (Rule IV.A.3).", "triggers": [ "The same payment message was sent twice, for example after a timeout on the sending side [Inference]", "A file of payments was released twice [Inference]" ], "actions": [ "Sending participant: check whether the first payment settled before doing anything else", "Do not send the payment again; if a duplicate did settle, the route back is a request for return of funds (rtp-return-request:DUPL)" ], "retry": { "allowed": false, "rule": "Do not resend: the payment already exists. Check the status of the first one." }, "facts": { "return_windows": [ { "action": "reject", "by": "Receiving Participant", "deadline": "Within the response time the RTP Technical Specifications set; the figure is not in the public Operating Rules. If the receiving participant has not answered by then, TCH cancels the payment and tells both participants." }, { "action": "reject", "by": "RTP System", "deadline": "On receipt, before the RTP System releases the payment message to the receiving participant." } ], "applies_to": "an RTP credit transfer" }, "caveat": "A reject DUPL stops a duplicate before settlement. A settled duplicate cannot be rejected; it can only be the subject of a request for return of funds, which is a separate record (rtp-return-request:DUPL). Same code, different rail: FedNow, SEPA and other ISO 20022 rails use their own lists and meanings, so never carry a meaning over from them.", "related": [ "rtp-return-request:DUPL" ], "basis": { "sources": "Listed as an RTP reject code by the Cross River Bank request and response codes page (family A); the Trice RTP system codes page (family B); the CU*Answers RTP Return Codes PDF, Appendix B (family C); the Oracle US RTP reason code mapping page (family D), all read 2026-09-19; the families agree on the meaning. ISO 20022 External Code Sets 2Q2026: in ExternalStatusReason1Code. Reject mechanics from the TCH RTP Operating Rules effective 2026-06-01, Rules IV.A, V.C and V.E.3. No TCH code list was consulted: the permitted list sits in the RTP Technical Specifications, under terms Orca has not accepted.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: no public source dates it", "effective_to": null, "effective_note": "No public source read says when this code became permitted on RTP [Unverified]. The pages it rests on were published or updated between 2023 and 2026.", "source_edition": "RTP Message Specifications not consulted (terms not accepted); the record rests on public bank and processor pages read 2026-09-19, and on the RTP Operating Rules effective 2026-06-01 for how a reject works", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "primary_not_public": true, "corroboration": [ { "source_url": "https://triceapi.readme.io/reference/rtp-system-codes", "source_class": "secondary", "source_title": "RTP / FedNOW / ACH System Codes (Trice)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms DUPL is listed as an RTP reject code meaning the payment is a duplicate of another payment." }, { "source_url": "https://www.cuanswers.com/wp-content/uploads/Return-Codes.pdf", "source_class": "secondary", "source_title": "RTP Return Codes (CU*Answers)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms DUPL is listed as an RTP reject code meaning the payment is a duplicate of another payment." } ] }, "rail_name": "RTP Payment Rejects", "governing_authority": "The Clearing House", "snapshot": "2026-09-19", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for RTP credit transfer (pacs.008). Its own scope line reads: an RTP credit transfer.", "from": "applies_to" }, { "kind": "not_public", "label": "the operator's own text", "needs": "what the operator's own text says, which Orca has not read", "detail": "The Clearing House's own text is not the source for this code: it is not public, or not under terms Orca can use. It rests on 2 named public sources, so a term set by agreement rather than by a published rule is not Orca's to state.", "from": "currency.primary_not_public" } ] }, { "uid": "rtp-reject:FF08", "id": "FF08", "rail": "rtp-reject", "kind": "reason-code", "name": "End-to-end identifier wrong or missing", "group": "technical", "summary": "The end-to-end identifier is wrong or missing. An ISO 20022 status reason code (ExternalStatusReason1Code). The meaning given is the one the public bank and processor pages agree on for RTP; ISO's generic definition is a fallback only where they say nothing more. No public source read says whether the receiving participant or the RTP System sends it, so both are linked [Inference].", "triggers": [ "The sending system did not fill the end-to-end identifier, or filled it in a form the network does not accept [Inference]" ], "actions": [ "Sending participant: fix how its system sets the end-to-end identifier and send a new payment" ], "retry": { "allowed": true, "rule": "Send a new payment message once the fault is fixed; the rejected payment never settled, so there is nothing to reverse or return." }, "facts": { "return_windows": [ { "action": "reject", "by": "Receiving Participant", "deadline": "Within the response time the RTP Technical Specifications set; the figure is not in the public Operating Rules. If the receiving participant has not answered by then, TCH cancels the payment and tells both participants." }, { "action": "reject", "by": "RTP System", "deadline": "On receipt, before the RTP System releases the payment message to the receiving participant." } ], "applies_to": "an RTP credit transfer" }, "caveat": "Same code, different rail: FedNow, SEPA and other ISO 20022 rails use their own lists and meanings, so never carry a meaning over from them.", "related": [], "basis": { "sources": "Listed as an RTP reject code by the Cross River Bank request and response codes page (family A); the Trice RTP system codes page (family B), all read 2026-09-19; the families agree on the meaning. ISO 20022 External Code Sets 2Q2026: in ExternalStatusReason1Code. Reject mechanics from the TCH RTP Operating Rules effective 2026-06-01, Rules IV.A, V.C and V.E.3. No TCH code list was consulted: the permitted list sits in the RTP Technical Specifications, under terms Orca has not accepted.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: no public source dates it", "effective_to": null, "effective_note": "No public source read says when this code became permitted on RTP [Unverified]. The pages it rests on were published or updated between 2023 and 2026.", "source_edition": "RTP Message Specifications not consulted (terms not accepted); the record rests on public bank and processor pages read 2026-09-19, and on the RTP Operating Rules effective 2026-06-01 for how a reject works", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "primary_not_public": true, "corroboration": [ { "source_url": "https://docs.crossriver.com/apis/payments/instant-payments/request-and-response-codes-instant-payments", "source_class": "secondary", "source_title": "Request and response codes: Instant payments (Cross River Bank)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms FF08 is listed as an RTP reject code meaning the end to end identifier is wrong or missing." }, { "source_url": "https://triceapi.readme.io/reference/rtp-system-codes", "source_class": "secondary", "source_title": "RTP / FedNOW / ACH System Codes (Trice)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms FF08 is listed as an RTP reject code meaning the end to end identifier is wrong or missing." } ] }, "rail_name": "RTP Payment Rejects", "governing_authority": "The Clearing House", "snapshot": "2026-09-19", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for RTP credit transfer (pacs.008). Its own scope line reads: an RTP credit transfer.", "from": "applies_to" }, { "kind": "not_public", "label": "the operator's own text", "needs": "what the operator's own text says, which Orca has not read", "detail": "The Clearing House's own text is not the source for this code: it is not public, or not under terms Orca can use. It rests on 2 named public sources, so a term set by agreement rather than by a published rule is not Orca's to state.", "from": "currency.primary_not_public" } ] }, { "uid": "rtp-reject:MD07", "id": "MD07", "rail": "rtp-reject", "kind": "reason-code", "name": "Receiver has died", "group": "account", "summary": "The receiver, the end customer, is deceased. An ISO 20022 status reason code (ExternalStatusReason1Code). The meaning given is the one the public bank and processor pages agree on for RTP; ISO's generic definition is a fallback only where they say nothing more. The receiving participant sends it in its reject response [Inference: the Oracle page marks it as used by the FI only, and Rule V.C lets the receiving participant reject for reasons tied to the receiver's account].", "triggers": [ "The receiving participant has recorded the account holder's death" ], "actions": [ "Sender: stop payments to this receiver and contact the estate or the person handling it [Inference]" ], "retry": { "allowed": false, "rule": "Do not send again to this receiver." }, "facts": { "return_windows": [ { "action": "reject", "by": "Receiving Participant", "deadline": "Within the response time the RTP Technical Specifications set; the figure is not in the public Operating Rules. If the receiving participant has not answered by then, TCH cancels the payment and tells both participants." } ], "applies_to": "an RTP credit transfer" }, "caveat": "Same code, different rail: FedNow, SEPA and other ISO 20022 rails use their own lists and meanings, so never carry a meaning over from them.", "related": [ "rtp-reject:BE06" ], "basis": { "sources": "Listed as an RTP reject code by the Cross River Bank request and response codes page (family A); the Trice RTP system codes page (family B); the CU*Answers RTP Return Codes PDF, Appendix B (family C); the Oracle US RTP reason code mapping page (family D), all read 2026-09-19; the families agree on the meaning. ISO 20022 External Code Sets 2Q2026: in ExternalStatusReason1Code. Reject mechanics from the TCH RTP Operating Rules effective 2026-06-01, Rules IV.A, V.C and V.E.3. No TCH code list was consulted: the permitted list sits in the RTP Technical Specifications, under terms Orca has not accepted.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: no public source dates it", "effective_to": null, "effective_note": "No public source read says when this code became permitted on RTP [Unverified]. The pages it rests on were published or updated between 2023 and 2026.", "source_edition": "RTP Message Specifications not consulted (terms not accepted); the record rests on public bank and processor pages read 2026-09-19, and on the RTP Operating Rules effective 2026-06-01 for how a reject works", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "primary_not_public": true, "corroboration": [ { "source_url": "https://triceapi.readme.io/reference/rtp-system-codes", "source_class": "secondary", "source_title": "RTP / FedNOW / ACH System Codes (Trice)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms MD07 is listed as an RTP reject code meaning the receiver has died." }, { "source_url": "https://www.cuanswers.com/wp-content/uploads/Return-Codes.pdf", "source_class": "secondary", "source_title": "RTP Return Codes (CU*Answers)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms MD07 is listed as an RTP reject code meaning the receiver has died." } ] }, "rail_name": "RTP Payment Rejects", "governing_authority": "The Clearing House", "snapshot": "2026-09-19", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for RTP credit transfer (pacs.008). Its own scope line reads: an RTP credit transfer.", "from": "applies_to" }, { "kind": "not_public", "label": "the operator's own text", "needs": "what the operator's own text says, which Orca has not read", "detail": "The Clearing House's own text is not the source for this code: it is not public, or not under terms Orca can use. It rests on 2 named public sources, so a term set by agreement rather than by a published rule is not Orca's to state.", "from": "currency.primary_not_public" } ] }, { "uid": "rtp-reject:NARR", "id": "NARR", "rail": "rtp-reject", "kind": "reason-code", "name": "Reason given as free text", "group": "technical", "summary": "The reason is given in words in the additional information, not as a specific code. An ISO 20022 status reason code (ExternalStatusReason1Code). The meaning given is the one the public bank and processor pages agree on for RTP; ISO's generic definition is a fallback only where they say nothing more. No public source read says whether the receiving participant or the RTP System sends it, so both are linked [Inference].", "triggers": [ "No specific code fits, so the rejecting party wrote the reason out" ], "actions": [ "Sending participant: read the additional information and act on what it says" ], "retry": { "allowed": true, "rule": "Depends on the reason given; the rejected payment never settled." }, "facts": { "return_windows": [ { "action": "reject", "by": "Receiving Participant", "deadline": "Within the response time the RTP Technical Specifications set; the figure is not in the public Operating Rules. If the receiving participant has not answered by then, TCH cancels the payment and tells both participants." }, { "action": "reject", "by": "RTP System", "deadline": "On receipt, before the RTP System releases the payment message to the receiving participant." } ], "applies_to": "an RTP credit transfer" }, "caveat": "Same code, different rail: FedNow, SEPA and other ISO 20022 rails use their own lists and meanings, so never carry a meaning over from them.", "related": [ "rtp-reject:1100" ], "basis": { "sources": "Listed as an RTP reject code by the Cross River Bank request and response codes page (family A); the Trice RTP system codes page (family B); the CU*Answers RTP Return Codes PDF, Appendix B (family C), all read 2026-09-19; the families agree on the meaning. ISO 20022 External Code Sets 2Q2026: in ExternalStatusReason1Code. Reject mechanics from the TCH RTP Operating Rules effective 2026-06-01, Rules IV.A, V.C and V.E.3. No TCH code list was consulted: the permitted list sits in the RTP Technical Specifications, under terms Orca has not accepted.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: no public source dates it", "effective_to": null, "effective_note": "No public source read says when this code became permitted on RTP [Unverified]. The pages it rests on were published or updated between 2023 and 2026.", "source_edition": "RTP Message Specifications not consulted (terms not accepted); the record rests on public bank and processor pages read 2026-09-19, and on the RTP Operating Rules effective 2026-06-01 for how a reject works", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "primary_not_public": true, "corroboration": [ { "source_url": "https://triceapi.readme.io/reference/rtp-system-codes", "source_class": "secondary", "source_title": "RTP / FedNOW / ACH System Codes (Trice)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms NARR is listed as an RTP reject code meaning the reason is given as free text." }, { "source_url": "https://www.cuanswers.com/wp-content/uploads/Return-Codes.pdf", "source_class": "secondary", "source_title": "RTP Return Codes (CU*Answers)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms NARR is listed as an RTP reject code meaning the reason is given as free text." } ] }, "rail_name": "RTP Payment Rejects", "governing_authority": "The Clearing House", "snapshot": "2026-09-19", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for RTP credit transfer (pacs.008). Its own scope line reads: an RTP credit transfer.", "from": "applies_to" }, { "kind": "not_public", "label": "the operator's own text", "needs": "what the operator's own text says, which Orca has not read", "detail": "The Clearing House's own text is not the source for this code: it is not public, or not under terms Orca can use. It rests on 2 named public sources, so a term set by agreement rather than by a published rule is not Orca's to state.", "from": "currency.primary_not_public" } ] }, { "uid": "rtp-reject:NOAT", "id": "NOAT", "rail": "rtp-reject", "kind": "reason-code", "name": "Receiving account does not take this message type", "group": "technical", "summary": "The receiving side does not support or accept this type of message. Not an ISO 20022 code: it is absent from ISO's status reason list, and Cross River Bank lists it among the codes TCH defines for RTP outside ISO. No public source read says whether the receiving participant or the RTP System sends it, so both are linked [Inference]; Cross River Bank lists it among TCH's own codes that come back from the network level, while its result code wording speaks of the customer's account.", "triggers": [ "The receiver's account or the receiving participant is not enabled for this message type [Inference]" ], "actions": [ "Sender: pay by another rail or use a message type the receiving side supports" ], "retry": { "allowed": false, "rule": "Not the same message type to the same account." }, "facts": { "return_windows": [ { "action": "reject", "by": "Receiving Participant", "deadline": "Within the response time the RTP Technical Specifications set; the figure is not in the public Operating Rules. If the receiving participant has not answered by then, TCH cancels the payment and tells both participants." }, { "action": "reject", "by": "RTP System", "deadline": "On receipt, before the RTP System releases the payment message to the receiving participant." } ], "applies_to": "an RTP credit transfer" }, "caveat": "Same code, different rail: FedNow, SEPA and other ISO 20022 rails use their own lists and meanings, so never carry a meaning over from them.", "related": [ "rtp-reject:AG03", "rtp-reject:AG01" ], "basis": { "sources": "Listed as an RTP reject code by the Cross River Bank request and response codes page (family A); the Cross River Bank error codes page, section on TCH's own RTP codes (family A); the Trice RTP system codes page (family B), all read 2026-09-19; the families agree on the meaning. ISO 20022 External Code Sets 2Q2026: not in ExternalStatusReason1Code. Reject mechanics from the TCH RTP Operating Rules effective 2026-06-01, Rules IV.A, V.C and V.E.3. No TCH code list was consulted: the permitted list sits in the RTP Technical Specifications, under terms Orca has not accepted.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: no public source dates it", "effective_to": null, "effective_note": "No public source read says when this code became permitted on RTP [Unverified]. The pages it rests on were published or updated between 2023 and 2026.", "source_edition": "RTP Message Specifications not consulted (terms not accepted); the record rests on public bank and processor pages read 2026-09-19, and on the RTP Operating Rules effective 2026-06-01 for how a reject works", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "primary_not_public": true, "corroboration": [ { "source_url": "https://docs.crossriver.com/apis/payments/instant-payments/error-codes-instant-payments", "source_class": "secondary", "source_title": "Error codes: Instant payments (Cross River Bank)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms NOAT is listed as an RTP reject code meaning the receiving account does not take this message type." }, { "source_url": "https://triceapi.readme.io/reference/rtp-system-codes", "source_class": "secondary", "source_title": "RTP / FedNOW / ACH System Codes (Trice)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms NOAT is listed as an RTP reject code meaning the receiving account does not take this message type." } ] }, "rail_name": "RTP Payment Rejects", "governing_authority": "The Clearing House", "snapshot": "2026-09-19", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for RTP credit transfer (pacs.008). Its own scope line reads: an RTP credit transfer.", "from": "applies_to" }, { "kind": "not_public", "label": "the operator's own text", "needs": "what the operator's own text says, which Orca has not read", "detail": "The Clearing House's own text is not the source for this code: it is not public, or not under terms Orca can use. It rests on 2 named public sources, so a term set by agreement rather than by a published rule is not Orca's to state.", "from": "currency.primary_not_public" } ] }, { "uid": "rtp-reject:RC01", "id": "RC01", "rail": "rtp-reject", "kind": "reason-code", "name": "Bank identifier in the wrong format", "group": "technical", "summary": "A bank identifier in the message is in the wrong format. An ISO 20022 status reason code (ExternalStatusReason1Code). The meaning given is the one the public bank and processor pages agree on for RTP; ISO's generic definition is a fallback only where they say nothing more. No public source read says whether the receiving participant or the RTP System sends it, so both are linked [Inference].", "triggers": [ "A routing number or other bank identifier was malformed, for example the wrong length [Inference]" ], "actions": [ "Sending participant: correct the identifier's format and send a new payment" ], "retry": { "allowed": true, "rule": "Send a new payment message once the fault is fixed; the rejected payment never settled, so there is nothing to reverse or return." }, "facts": { "return_windows": [ { "action": "reject", "by": "Receiving Participant", "deadline": "Within the response time the RTP Technical Specifications set; the figure is not in the public Operating Rules. If the receiving participant has not answered by then, TCH cancels the payment and tells both participants." }, { "action": "reject", "by": "RTP System", "deadline": "On receipt, before the RTP System releases the payment message to the receiving participant." } ], "applies_to": "an RTP credit transfer" }, "caveat": "Same code, different rail: FedNow, SEPA and other ISO 20022 rails use their own lists and meanings, so never carry a meaning over from them.", "related": [ "rtp-reject:RC02", "rtp-reject:RC03", "rtp-reject:RC04" ], "basis": { "sources": "Listed as an RTP reject code by the Cross River Bank request and response codes page (family A); the Trice RTP system codes page (family B), all read 2026-09-19; the families agree on the meaning. ISO 20022 External Code Sets 2Q2026: in ExternalStatusReason1Code. Reject mechanics from the TCH RTP Operating Rules effective 2026-06-01, Rules IV.A, V.C and V.E.3. No TCH code list was consulted: the permitted list sits in the RTP Technical Specifications, under terms Orca has not accepted.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: no public source dates it", "effective_to": null, "effective_note": "No public source read says when this code became permitted on RTP [Unverified]. The pages it rests on were published or updated between 2023 and 2026.", "source_edition": "RTP Message Specifications not consulted (terms not accepted); the record rests on public bank and processor pages read 2026-09-19, and on the RTP Operating Rules effective 2026-06-01 for how a reject works", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "primary_not_public": true, "corroboration": [ { "source_url": "https://docs.crossriver.com/apis/payments/instant-payments/request-and-response-codes-instant-payments", "source_class": "secondary", "source_title": "Request and response codes: Instant payments (Cross River Bank)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms RC01 is listed as an RTP reject code meaning the bank identifier is in the wrong format." }, { "source_url": "https://triceapi.readme.io/reference/rtp-system-codes", "source_class": "secondary", "source_title": "RTP / FedNOW / ACH System Codes (Trice)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms RC01 is listed as an RTP reject code meaning the bank identifier is in the wrong format." } ] }, "rail_name": "RTP Payment Rejects", "governing_authority": "The Clearing House", "snapshot": "2026-09-19", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for RTP credit transfer (pacs.008). Its own scope line reads: an RTP credit transfer.", "from": "applies_to" }, { "kind": "not_public", "label": "the operator's own text", "needs": "what the operator's own text says, which Orca has not read", "detail": "The Clearing House's own text is not the source for this code: it is not public, or not under terms Orca can use. It rests on 2 named public sources, so a term set by agreement rather than by a published rule is not Orca's to state.", "from": "currency.primary_not_public" } ] }, { "uid": "rtp-reject:RC02", "id": "RC02", "rail": "rtp-reject", "kind": "reason-code", "name": "Bank identifier wrong or missing", "group": "technical", "summary": "A bank identifier in the message is invalid or missing. An ISO 20022 status reason code (ExternalStatusReason1Code). The meaning given is the one the public bank and processor pages agree on for RTP; ISO's generic definition is a fallback only where they say nothing more. No public source read says whether the receiving participant or the RTP System sends it, so both are linked [Inference].", "triggers": [ "A routing number or other bank identifier is absent or unknown [Inference]" ], "actions": [ "Sending participant: correct the bank identifier and send a new payment" ], "retry": { "allowed": true, "rule": "Send a new payment message once the fault is fixed; the rejected payment never settled, so there is nothing to reverse or return." }, "facts": { "return_windows": [ { "action": "reject", "by": "Receiving Participant", "deadline": "Within the response time the RTP Technical Specifications set; the figure is not in the public Operating Rules. If the receiving participant has not answered by then, TCH cancels the payment and tells both participants." }, { "action": "reject", "by": "RTP System", "deadline": "On receipt, before the RTP System releases the payment message to the receiving participant." } ], "applies_to": "an RTP credit transfer" }, "caveat": "Same code, different rail: FedNow, SEPA and other ISO 20022 rails use their own lists and meanings, so never carry a meaning over from them.", "related": [ "rtp-reject:RC01", "rtp-reject:RC03", "rtp-reject:RC04" ], "basis": { "sources": "Listed as an RTP reject code by the Cross River Bank request and response codes page (family A); the Trice RTP system codes page (family B), all read 2026-09-19; the families agree on the meaning. ISO 20022 External Code Sets 2Q2026: in ExternalStatusReason1Code. Reject mechanics from the TCH RTP Operating Rules effective 2026-06-01, Rules IV.A, V.C and V.E.3. No TCH code list was consulted: the permitted list sits in the RTP Technical Specifications, under terms Orca has not accepted.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: no public source dates it", "effective_to": null, "effective_note": "No public source read says when this code became permitted on RTP [Unverified]. The pages it rests on were published or updated between 2023 and 2026.", "source_edition": "RTP Message Specifications not consulted (terms not accepted); the record rests on public bank and processor pages read 2026-09-19, and on the RTP Operating Rules effective 2026-06-01 for how a reject works", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "primary_not_public": true, "corroboration": [ { "source_url": "https://docs.crossriver.com/apis/payments/instant-payments/request-and-response-codes-instant-payments", "source_class": "secondary", "source_title": "Request and response codes: Instant payments (Cross River Bank)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms RC02 is listed as an RTP reject code meaning the bank identifier is wrong or missing." }, { "source_url": "https://triceapi.readme.io/reference/rtp-system-codes", "source_class": "secondary", "source_title": "RTP / FedNOW / ACH System Codes (Trice)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms RC02 is listed as an RTP reject code meaning the bank identifier is wrong or missing." } ] }, "rail_name": "RTP Payment Rejects", "governing_authority": "The Clearing House", "snapshot": "2026-09-19", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for RTP credit transfer (pacs.008). Its own scope line reads: an RTP credit transfer.", "from": "applies_to" }, { "kind": "not_public", "label": "the operator's own text", "needs": "what the operator's own text says, which Orca has not read", "detail": "The Clearing House's own text is not the source for this code: it is not public, or not under terms Orca can use. It rests on 2 named public sources, so a term set by agreement rather than by a published rule is not Orca's to state.", "from": "currency.primary_not_public" } ] }, { "uid": "rtp-reject:RC03", "id": "RC03", "rail": "rtp-reject", "kind": "reason-code", "name": "Sender's bank identifier wrong or missing", "group": "technical", "summary": "The identifier of the sender's bank (the sending participant) is invalid or missing. An ISO 20022 status reason code (ExternalStatusReason1Code). The meaning given is the one the public bank and processor pages agree on for RTP; ISO's generic definition is a fallback only where they say nothing more. No public source read says whether the receiving participant or the RTP System sends it, so both are linked [Inference].", "triggers": [ "The sending participant's own identifier was set wrongly in the message [Inference]" ], "actions": [ "Sending participant: correct its identifier in the message and send a new payment" ], "retry": { "allowed": true, "rule": "Send a new payment message once the fault is fixed; the rejected payment never settled, so there is nothing to reverse or return." }, "facts": { "return_windows": [ { "action": "reject", "by": "Receiving Participant", "deadline": "Within the response time the RTP Technical Specifications set; the figure is not in the public Operating Rules. If the receiving participant has not answered by then, TCH cancels the payment and tells both participants." }, { "action": "reject", "by": "RTP System", "deadline": "On receipt, before the RTP System releases the payment message to the receiving participant." } ], "applies_to": "an RTP credit transfer" }, "caveat": "Same code, different rail: FedNow, SEPA and other ISO 20022 rails use their own lists and meanings, so never carry a meaning over from them.", "related": [ "rtp-reject:RC04", "rtp-reject:RC02" ], "basis": { "sources": "Listed as an RTP reject code by the Cross River Bank request and response codes page (family A); the Trice RTP system codes page (family B), all read 2026-09-19; the families agree on the meaning. ISO 20022 External Code Sets 2Q2026: in ExternalStatusReason1Code. Reject mechanics from the TCH RTP Operating Rules effective 2026-06-01, Rules IV.A, V.C and V.E.3. No TCH code list was consulted: the permitted list sits in the RTP Technical Specifications, under terms Orca has not accepted.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: no public source dates it", "effective_to": null, "effective_note": "No public source read says when this code became permitted on RTP [Unverified]. The pages it rests on were published or updated between 2023 and 2026.", "source_edition": "RTP Message Specifications not consulted (terms not accepted); the record rests on public bank and processor pages read 2026-09-19, and on the RTP Operating Rules effective 2026-06-01 for how a reject works", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "primary_not_public": true, "corroboration": [ { "source_url": "https://docs.crossriver.com/apis/payments/instant-payments/request-and-response-codes-instant-payments", "source_class": "secondary", "source_title": "Request and response codes: Instant payments (Cross River Bank)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms RC03 is listed as an RTP reject code meaning the sender's bank identifier is wrong or missing." }, { "source_url": "https://triceapi.readme.io/reference/rtp-system-codes", "source_class": "secondary", "source_title": "RTP / FedNOW / ACH System Codes (Trice)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms RC03 is listed as an RTP reject code meaning the sender's bank identifier is wrong or missing." } ] }, "rail_name": "RTP Payment Rejects", "governing_authority": "The Clearing House", "snapshot": "2026-09-19", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for RTP credit transfer (pacs.008). Its own scope line reads: an RTP credit transfer.", "from": "applies_to" }, { "kind": "not_public", "label": "the operator's own text", "needs": "what the operator's own text says, which Orca has not read", "detail": "The Clearing House's own text is not the source for this code: it is not public, or not under terms Orca can use. It rests on 2 named public sources, so a term set by agreement rather than by a published rule is not Orca's to state.", "from": "currency.primary_not_public" } ] }, { "uid": "rtp-reject:RC04", "id": "RC04", "rail": "rtp-reject", "kind": "reason-code", "name": "Receiver's bank identifier wrong or missing", "group": "technical", "summary": "The identifier of the receiver's bank (the receiving participant) is invalid or missing. An ISO 20022 status reason code (ExternalStatusReason1Code). The meaning given is the one the public bank and processor pages agree on for RTP; ISO's generic definition is a fallback only where they say nothing more. No public source read says whether the receiving participant or the RTP System sends it, so both are linked [Inference]; the Oracle page marks it as used by both the FI and the CI.", "triggers": [ "The routing number given for the receiver is wrong or does not belong to an RTP participant [Inference]" ], "actions": [ "Sender: confirm the receiver's routing number", "Sending participant: keep the list of routing numbers that can receive RTP payments it shows senders up to date, as Rule III.G requires" ], "retry": { "allowed": true, "rule": "Send a new payment message once the fault is fixed; the rejected payment never settled, so there is nothing to reverse or return." }, "facts": { "return_windows": [ { "action": "reject", "by": "Receiving Participant", "deadline": "Within the response time the RTP Technical Specifications set; the figure is not in the public Operating Rules. If the receiving participant has not answered by then, TCH cancels the payment and tells both participants." }, { "action": "reject", "by": "RTP System", "deadline": "On receipt, before the RTP System releases the payment message to the receiving participant." } ], "applies_to": "an RTP credit transfer" }, "caveat": "Same code, different rail: FedNow, SEPA and other ISO 20022 rails use their own lists and meanings, so never carry a meaning over from them.", "related": [ "rtp-reject:RC03", "rtp-reject:RC02", "rtp-reject:AGNT" ], "basis": { "sources": "Listed as an RTP reject code by the Cross River Bank request and response codes page (family A); the Trice RTP system codes page (family B); the CU*Answers RTP Return Codes PDF, Appendix B (family C); the Oracle US RTP reason code mapping page (family D), all read 2026-09-19; the families agree on the meaning. ISO 20022 External Code Sets 2Q2026: in ExternalStatusReason1Code. Reject mechanics from the TCH RTP Operating Rules effective 2026-06-01, Rules IV.A, V.C and V.E.3. No TCH code list was consulted: the permitted list sits in the RTP Technical Specifications, under terms Orca has not accepted.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: no public source dates it", "effective_to": null, "effective_note": "No public source read says when this code became permitted on RTP [Unverified]. The pages it rests on were published or updated between 2023 and 2026.", "source_edition": "RTP Message Specifications not consulted (terms not accepted); the record rests on public bank and processor pages read 2026-09-19, and on the RTP Operating Rules effective 2026-06-01 for how a reject works", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "primary_not_public": true, "corroboration": [ { "source_url": "https://triceapi.readme.io/reference/rtp-system-codes", "source_class": "secondary", "source_title": "RTP / FedNOW / ACH System Codes (Trice)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms RC04 is listed as an RTP reject code meaning the receiver's bank identifier is wrong or missing." }, { "source_url": "https://www.cuanswers.com/wp-content/uploads/Return-Codes.pdf", "source_class": "secondary", "source_title": "RTP Return Codes (CU*Answers)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms RC04 is listed as an RTP reject code meaning the receiver's bank identifier is wrong or missing." } ] }, "rail_name": "RTP Payment Rejects", "governing_authority": "The Clearing House", "snapshot": "2026-09-19", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for RTP credit transfer (pacs.008). Its own scope line reads: an RTP credit transfer.", "from": "applies_to" }, { "kind": "not_public", "label": "the operator's own text", "needs": "what the operator's own text says, which Orca has not read", "detail": "The Clearing House's own text is not the source for this code: it is not public, or not under terms Orca can use. It rests on 2 named public sources, so a term set by agreement rather than by a published rule is not Orca's to state.", "from": "currency.primary_not_public" } ] }, { "uid": "rtp-reject:TK01", "id": "TK01", "rail": "rtp-reject", "kind": "reason-code", "name": "Token invalid", "group": "technical", "summary": "The token used in place of account details is invalid. An ISO 20022 status reason code (ExternalStatusReason1Code). The meaning given is the one the public bank and processor pages agree on for RTP; ISO's generic definition is a fallback only where they say nothing more. No public source read says whether the receiving participant or the RTP System sends it, so both are linked [Inference].", "triggers": [ "The token is malformed or not one the token service issued [Inference]" ], "actions": [ "Sender: get a valid token for the receiver, or use account details, and send a new payment" ], "retry": { "allowed": true, "rule": "Send a new payment message once the fault is fixed; the rejected payment never settled, so there is nothing to reverse or return." }, "facts": { "return_windows": [ { "action": "reject", "by": "Receiving Participant", "deadline": "Within the response time the RTP Technical Specifications set; the figure is not in the public Operating Rules. If the receiving participant has not answered by then, TCH cancels the payment and tells both participants." }, { "action": "reject", "by": "RTP System", "deadline": "On receipt, before the RTP System releases the payment message to the receiving participant." } ], "applies_to": "an RTP credit transfer or request for payment" }, "caveat": "No public TCH document read describes RTP's token service; the token codes rest on the Cross River Bank and Trice pages only [Unverified]. Same code, different rail: FedNow, SEPA and other ISO 20022 rails use their own lists and meanings, so never carry a meaning over from them.", "related": [ "rtp-reject:TK02", "rtp-reject:TK03" ], "basis": { "sources": "Listed as an RTP reject code by the Cross River Bank request and response codes page (family A); the Trice RTP system codes page (family B), all read 2026-09-19; the families agree on the meaning. ISO 20022 External Code Sets 2Q2026: in ExternalStatusReason1Code. Reject mechanics from the TCH RTP Operating Rules effective 2026-06-01, Rules IV.A, V.C and V.E.3. No TCH code list was consulted: the permitted list sits in the RTP Technical Specifications, under terms Orca has not accepted.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: no public source dates it", "effective_to": null, "effective_note": "No public source read says when this code became permitted on RTP [Unverified]. The pages it rests on were published or updated between 2023 and 2026.", "source_edition": "RTP Message Specifications not consulted (terms not accepted); the record rests on public bank and processor pages read 2026-09-19, and on the RTP Operating Rules effective 2026-06-01 for how a reject works", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "primary_not_public": true, "corroboration": [ { "source_url": "https://docs.crossriver.com/apis/payments/instant-payments/request-and-response-codes-instant-payments", "source_class": "secondary", "source_title": "Request and response codes: Instant payments (Cross River Bank)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms TK01 is listed as an RTP reject code meaning the token is invalid." }, { "source_url": "https://triceapi.readme.io/reference/rtp-system-codes", "source_class": "secondary", "source_title": "RTP / FedNOW / ACH System Codes (Trice)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms TK01 is listed as an RTP reject code meaning the token is invalid." } ] }, "rail_name": "RTP Payment Rejects", "governing_authority": "The Clearing House", "snapshot": "2026-09-19", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "not_public", "label": "the operator's own text", "needs": "what the operator's own text says, which Orca has not read", "detail": "The Clearing House's own text is not the source for this code: it is not public, or not under terms Orca can use. It rests on 2 named public sources, so a term set by agreement rather than by a published rule is not Orca's to state.", "from": "currency.primary_not_public" } ] }, { "uid": "rtp-reject:TK02", "id": "TK02", "rail": "rtp-reject", "kind": "reason-code", "name": "Sender's token not found", "group": "technical", "summary": "The token given for the sender cannot be found. An ISO 20022 status reason code (ExternalStatusReason1Code). The meaning given is the one the public bank and processor pages agree on for RTP; ISO's generic definition is a fallback only where they say nothing more. No public source read says whether the receiving participant or the RTP System sends it, so both are linked [Inference].", "triggers": [ "The sender's token was never registered or has been removed [Inference]" ], "actions": [ "Sending participant: check the sender's token registration and send a new payment" ], "retry": { "allowed": true, "rule": "Send a new payment message once the fault is fixed; the rejected payment never settled, so there is nothing to reverse or return." }, "facts": { "return_windows": [ { "action": "reject", "by": "Receiving Participant", "deadline": "Within the response time the RTP Technical Specifications set; the figure is not in the public Operating Rules. If the receiving participant has not answered by then, TCH cancels the payment and tells both participants." }, { "action": "reject", "by": "RTP System", "deadline": "On receipt, before the RTP System releases the payment message to the receiving participant." } ], "applies_to": "an RTP credit transfer or request for payment" }, "caveat": "No public TCH document read describes RTP's token service; the token codes rest on the Cross River Bank and Trice pages only [Unverified]. Same code, different rail: FedNow, SEPA and other ISO 20022 rails use their own lists and meanings, so never carry a meaning over from them.", "related": [ "rtp-reject:TK01", "rtp-reject:TK03" ], "basis": { "sources": "Listed as an RTP reject code by the Cross River Bank request and response codes page (family A); the Trice RTP system codes page (family B), all read 2026-09-19; the families agree on the meaning. ISO 20022 External Code Sets 2Q2026: in ExternalStatusReason1Code. Reject mechanics from the TCH RTP Operating Rules effective 2026-06-01, Rules IV.A, V.C and V.E.3. No TCH code list was consulted: the permitted list sits in the RTP Technical Specifications, under terms Orca has not accepted.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: no public source dates it", "effective_to": null, "effective_note": "No public source read says when this code became permitted on RTP [Unverified]. The pages it rests on were published or updated between 2023 and 2026.", "source_edition": "RTP Message Specifications not consulted (terms not accepted); the record rests on public bank and processor pages read 2026-09-19, and on the RTP Operating Rules effective 2026-06-01 for how a reject works", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "primary_not_public": true, "corroboration": [ { "source_url": "https://docs.crossriver.com/apis/payments/instant-payments/request-and-response-codes-instant-payments", "source_class": "secondary", "source_title": "Request and response codes: Instant payments (Cross River Bank)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms TK02 is listed as an RTP reject code meaning the sender's token was not found." }, { "source_url": "https://triceapi.readme.io/reference/rtp-system-codes", "source_class": "secondary", "source_title": "RTP / FedNOW / ACH System Codes (Trice)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms TK02 is listed as an RTP reject code meaning the sender's token was not found." } ] }, "rail_name": "RTP Payment Rejects", "governing_authority": "The Clearing House", "snapshot": "2026-09-19", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "not_public", "label": "the operator's own text", "needs": "what the operator's own text says, which Orca has not read", "detail": "The Clearing House's own text is not the source for this code: it is not public, or not under terms Orca can use. It rests on 2 named public sources, so a term set by agreement rather than by a published rule is not Orca's to state.", "from": "currency.primary_not_public" } ] }, { "uid": "rtp-reject:TK03", "id": "TK03", "rail": "rtp-reject", "kind": "reason-code", "name": "Receiver's token not found", "group": "technical", "summary": "The token given for the receiver cannot be found. An ISO 20022 status reason code (ExternalStatusReason1Code). The meaning given is the one the public bank and processor pages agree on for RTP; ISO's generic definition is a fallback only where they say nothing more. No public source read says whether the receiving participant or the RTP System sends it, so both are linked [Inference].", "triggers": [ "The receiver's token was never registered or has been removed [Inference]" ], "actions": [ "Sender: ask the receiver for current payment details" ], "retry": { "allowed": true, "rule": "Send a new payment message once the fault is fixed; the rejected payment never settled, so there is nothing to reverse or return." }, "facts": { "return_windows": [ { "action": "reject", "by": "Receiving Participant", "deadline": "Within the response time the RTP Technical Specifications set; the figure is not in the public Operating Rules. If the receiving participant has not answered by then, TCH cancels the payment and tells both participants." }, { "action": "reject", "by": "RTP System", "deadline": "On receipt, before the RTP System releases the payment message to the receiving participant." } ], "applies_to": "an RTP credit transfer or request for payment" }, "caveat": "No public TCH document read describes RTP's token service; the token codes rest on the Cross River Bank and Trice pages only [Unverified]. Same code, different rail: FedNow, SEPA and other ISO 20022 rails use their own lists and meanings, so never carry a meaning over from them.", "related": [ "rtp-reject:TK01", "rtp-reject:TK02" ], "basis": { "sources": "Listed as an RTP reject code by the Cross River Bank request and response codes page (family A); the Trice RTP system codes page (family B), all read 2026-09-19; the families agree on the meaning. ISO 20022 External Code Sets 2Q2026: in ExternalStatusReason1Code. Reject mechanics from the TCH RTP Operating Rules effective 2026-06-01, Rules IV.A, V.C and V.E.3. No TCH code list was consulted: the permitted list sits in the RTP Technical Specifications, under terms Orca has not accepted.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: no public source dates it", "effective_to": null, "effective_note": "No public source read says when this code became permitted on RTP [Unverified]. The pages it rests on were published or updated between 2023 and 2026.", "source_edition": "RTP Message Specifications not consulted (terms not accepted); the record rests on public bank and processor pages read 2026-09-19, and on the RTP Operating Rules effective 2026-06-01 for how a reject works", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "primary_not_public": true, "corroboration": [ { "source_url": "https://docs.crossriver.com/apis/payments/instant-payments/request-and-response-codes-instant-payments", "source_class": "secondary", "source_title": "Request and response codes: Instant payments (Cross River Bank)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms TK03 is listed as an RTP reject code meaning the receiver's token was not found." }, { "source_url": "https://triceapi.readme.io/reference/rtp-system-codes", "source_class": "secondary", "source_title": "RTP / FedNOW / ACH System Codes (Trice)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms TK03 is listed as an RTP reject code meaning the receiver's token was not found." } ] }, "rail_name": "RTP Payment Rejects", "governing_authority": "The Clearing House", "snapshot": "2026-09-19", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "not_public", "label": "the operator's own text", "needs": "what the operator's own text says, which Orca has not read", "detail": "The Clearing House's own text is not the source for this code: it is not public, or not under terms Orca can use. It rests on 2 named public sources, so a term set by agreement rather than by a published rule is not Orca's to state.", "from": "currency.primary_not_public" } ] }, { "uid": "rtp-reject:TK04", "id": "TK04", "rail": "rtp-reject", "kind": "reason-code", "name": "Token expired", "group": "technical", "summary": "The token has expired. Not an ISO 20022 code: ISO's status reason list (2Q2026) has TK01 to TK03, TK09 and lettered token codes but no TK04 to TK08, so [Inference] TK04 to TK08 are TCH's own codes for RTP. No public source read says whether the receiving participant or the RTP System sends it, so both are linked [Inference].", "triggers": [ "The token's validity period has ended [Inference]" ], "actions": [ "Sender: get a fresh token or account details from the receiver" ], "retry": { "allowed": true, "rule": "Send a new payment message once the fault is fixed; the rejected payment never settled, so there is nothing to reverse or return." }, "facts": { "return_windows": [ { "action": "reject", "by": "Receiving Participant", "deadline": "Within the response time the RTP Technical Specifications set; the figure is not in the public Operating Rules. If the receiving participant has not answered by then, TCH cancels the payment and tells both participants." }, { "action": "reject", "by": "RTP System", "deadline": "On receipt, before the RTP System releases the payment message to the receiving participant." } ], "applies_to": "an RTP credit transfer or request for payment" }, "caveat": "No public TCH document read describes RTP's token service; the token codes rest on the Cross River Bank and Trice pages only [Unverified]. Same code, different rail: FedNow, SEPA and other ISO 20022 rails use their own lists and meanings, so never carry a meaning over from them.", "related": [ "rtp-reject:TK01" ], "basis": { "sources": "Listed as an RTP reject code by the Cross River Bank request and response codes page (family A); the Trice RTP system codes page (family B), all read 2026-09-19; the families agree on the meaning. ISO 20022 External Code Sets 2Q2026: not in ExternalStatusReason1Code. Reject mechanics from the TCH RTP Operating Rules effective 2026-06-01, Rules IV.A, V.C and V.E.3. No TCH code list was consulted: the permitted list sits in the RTP Technical Specifications, under terms Orca has not accepted.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: no public source dates it", "effective_to": null, "effective_note": "No public source read says when this code became permitted on RTP [Unverified]. The pages it rests on were published or updated between 2023 and 2026.", "source_edition": "RTP Message Specifications not consulted (terms not accepted); the record rests on public bank and processor pages read 2026-09-19, and on the RTP Operating Rules effective 2026-06-01 for how a reject works", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "primary_not_public": true, "corroboration": [ { "source_url": "https://docs.crossriver.com/apis/payments/instant-payments/request-and-response-codes-instant-payments", "source_class": "secondary", "source_title": "Request and response codes: Instant payments (Cross River Bank)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms TK04 is listed as an RTP reject code meaning the token has expired." }, { "source_url": "https://triceapi.readme.io/reference/rtp-system-codes", "source_class": "secondary", "source_title": "RTP / FedNOW / ACH System Codes (Trice)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms TK04 is listed as an RTP reject code meaning the token has expired." } ] }, "rail_name": "RTP Payment Rejects", "governing_authority": "The Clearing House", "snapshot": "2026-09-19", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "not_public", "label": "the operator's own text", "needs": "what the operator's own text says, which Orca has not read", "detail": "The Clearing House's own text is not the source for this code: it is not public, or not under terms Orca can use. It rests on 2 named public sources, so a term set by agreement rather than by a published rule is not Orca's to state.", "from": "currency.primary_not_public" } ] }, { "uid": "rtp-reject:TK05", "id": "TK05", "rail": "rtp-reject", "kind": "reason-code", "name": "Token does not match the counterparty", "group": "technical", "summary": "The token does not belong to the counterparty named in the payment. Not an ISO 20022 code: ISO's status reason list (2Q2026) has TK01 to TK03, TK09 and lettered token codes but no TK04 to TK08, so [Inference] TK04 to TK08 are TCH's own codes for RTP. No public source read says whether the receiving participant or the RTP System sends it, so both are linked [Inference].", "triggers": [ "The token was issued for a different sender or receiver than the one in the message [Inference]" ], "actions": [ "Sender: check that the token and the named counterparty go together" ], "retry": { "allowed": true, "rule": "Send a new payment message once the fault is fixed; the rejected payment never settled, so there is nothing to reverse or return." }, "facts": { "return_windows": [ { "action": "reject", "by": "Receiving Participant", "deadline": "Within the response time the RTP Technical Specifications set; the figure is not in the public Operating Rules. If the receiving participant has not answered by then, TCH cancels the payment and tells both participants." }, { "action": "reject", "by": "RTP System", "deadline": "On receipt, before the RTP System releases the payment message to the receiving participant." } ], "applies_to": "an RTP credit transfer or request for payment" }, "caveat": "No public TCH document read describes RTP's token service; the token codes rest on the Cross River Bank and Trice pages only [Unverified]. Same code, different rail: FedNow, SEPA and other ISO 20022 rails use their own lists and meanings, so never carry a meaning over from them.", "related": [ "rtp-reject:TK01" ], "basis": { "sources": "Listed as an RTP reject code by the Cross River Bank request and response codes page (family A); the Trice RTP system codes page (family B), all read 2026-09-19; the families agree on the meaning. ISO 20022 External Code Sets 2Q2026: not in ExternalStatusReason1Code. Reject mechanics from the TCH RTP Operating Rules effective 2026-06-01, Rules IV.A, V.C and V.E.3. No TCH code list was consulted: the permitted list sits in the RTP Technical Specifications, under terms Orca has not accepted.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: no public source dates it", "effective_to": null, "effective_note": "No public source read says when this code became permitted on RTP [Unverified]. The pages it rests on were published or updated between 2023 and 2026.", "source_edition": "RTP Message Specifications not consulted (terms not accepted); the record rests on public bank and processor pages read 2026-09-19, and on the RTP Operating Rules effective 2026-06-01 for how a reject works", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "primary_not_public": true, "corroboration": [ { "source_url": "https://docs.crossriver.com/apis/payments/instant-payments/request-and-response-codes-instant-payments", "source_class": "secondary", "source_title": "Request and response codes: Instant payments (Cross River Bank)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms TK05 is listed as an RTP reject code meaning the token does not match the counterparty." }, { "source_url": "https://triceapi.readme.io/reference/rtp-system-codes", "source_class": "secondary", "source_title": "RTP / FedNOW / ACH System Codes (Trice)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms TK05 is listed as an RTP reject code meaning the token does not match the counterparty." } ] }, "rail_name": "RTP Payment Rejects", "governing_authority": "The Clearing House", "snapshot": "2026-09-19", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "not_public", "label": "the operator's own text", "needs": "what the operator's own text says, which Orca has not read", "detail": "The Clearing House's own text is not the source for this code: it is not public, or not under terms Orca can use. It rests on 2 named public sources, so a term set by agreement rather than by a published rule is not Orca's to state.", "from": "currency.primary_not_public" } ] }, { "uid": "rtp-reject:TK06", "id": "TK06", "rail": "rtp-reject", "kind": "reason-code", "name": "Token value limit breached", "group": "technical", "summary": "The payment breaks a value limit attached to the token. Not an ISO 20022 code: ISO's status reason list (2Q2026) has TK01 to TK03, TK09 and lettered token codes but no TK04 to TK08, so [Inference] TK04 to TK08 are TCH's own codes for RTP. No public source read says whether the receiving participant or the RTP System sends it, so both are linked [Inference].", "triggers": [ "The amount is above what the token allows [Inference]" ], "actions": [ "Sender: send an amount within the token's limit, or pay by account details" ], "retry": { "allowed": false, "rule": "Not for the same amount with the same token." }, "facts": { "return_windows": [ { "action": "reject", "by": "Receiving Participant", "deadline": "Within the response time the RTP Technical Specifications set; the figure is not in the public Operating Rules. If the receiving participant has not answered by then, TCH cancels the payment and tells both participants." }, { "action": "reject", "by": "RTP System", "deadline": "On receipt, before the RTP System releases the payment message to the receiving participant." } ], "applies_to": "an RTP credit transfer or request for payment" }, "caveat": "No public TCH document read describes RTP's token service; the token codes rest on the Cross River Bank and Trice pages only [Unverified]. Same code, different rail: FedNow, SEPA and other ISO 20022 rails use their own lists and meanings, so never carry a meaning over from them.", "related": [ "rtp-reject:TK01" ], "basis": { "sources": "Listed as an RTP reject code by the Cross River Bank request and response codes page (family A); the Trice RTP system codes page (family B), all read 2026-09-19; the families agree on the meaning. ISO 20022 External Code Sets 2Q2026: not in ExternalStatusReason1Code. Reject mechanics from the TCH RTP Operating Rules effective 2026-06-01, Rules IV.A, V.C and V.E.3. No TCH code list was consulted: the permitted list sits in the RTP Technical Specifications, under terms Orca has not accepted.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: no public source dates it", "effective_to": null, "effective_note": "No public source read says when this code became permitted on RTP [Unverified]. The pages it rests on were published or updated between 2023 and 2026.", "source_edition": "RTP Message Specifications not consulted (terms not accepted); the record rests on public bank and processor pages read 2026-09-19, and on the RTP Operating Rules effective 2026-06-01 for how a reject works", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "primary_not_public": true, "corroboration": [ { "source_url": "https://docs.crossriver.com/apis/payments/instant-payments/request-and-response-codes-instant-payments", "source_class": "secondary", "source_title": "Request and response codes: Instant payments (Cross River Bank)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms TK06 is listed as an RTP reject code meaning the token's value limit was breached." }, { "source_url": "https://triceapi.readme.io/reference/rtp-system-codes", "source_class": "secondary", "source_title": "RTP / FedNOW / ACH System Codes (Trice)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms TK06 is listed as an RTP reject code meaning the token's value limit was breached." } ] }, "rail_name": "RTP Payment Rejects", "governing_authority": "The Clearing House", "snapshot": "2026-09-19", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "not_public", "label": "the operator's own text", "needs": "what the operator's own text says, which Orca has not read", "detail": "The Clearing House's own text is not the source for this code: it is not public, or not under terms Orca can use. It rests on 2 named public sources, so a term set by agreement rather than by a published rule is not Orca's to state.", "from": "currency.primary_not_public" } ] }, { "uid": "rtp-reject:TK07", "id": "TK07", "rail": "rtp-reject", "kind": "reason-code", "name": "Single-use token already used", "group": "technical", "summary": "The token was for one use only and has been used. Not an ISO 20022 code: ISO's status reason list (2Q2026) has TK01 to TK03, TK09 and lettered token codes but no TK04 to TK08, so [Inference] TK04 to TK08 are TCH's own codes for RTP. No public source read says whether the receiving participant or the RTP System sends it, so both are linked [Inference].", "triggers": [ "A second payment tried to use a single-use token [Inference]" ], "actions": [ "Sender: get a new token for a new payment" ], "retry": { "allowed": false, "rule": "Not with the same token." }, "facts": { "return_windows": [ { "action": "reject", "by": "Receiving Participant", "deadline": "Within the response time the RTP Technical Specifications set; the figure is not in the public Operating Rules. If the receiving participant has not answered by then, TCH cancels the payment and tells both participants." }, { "action": "reject", "by": "RTP System", "deadline": "On receipt, before the RTP System releases the payment message to the receiving participant." } ], "applies_to": "an RTP credit transfer or request for payment" }, "caveat": "No public TCH document read describes RTP's token service; the token codes rest on the Cross River Bank and Trice pages only [Unverified]. Same code, different rail: FedNow, SEPA and other ISO 20022 rails use their own lists and meanings, so never carry a meaning over from them.", "related": [ "rtp-reject:TK01" ], "basis": { "sources": "Listed as an RTP reject code by the Cross River Bank request and response codes page (family A); the Trice RTP system codes page (family B), all read 2026-09-19; the families agree on the meaning. ISO 20022 External Code Sets 2Q2026: not in ExternalStatusReason1Code. Reject mechanics from the TCH RTP Operating Rules effective 2026-06-01, Rules IV.A, V.C and V.E.3. No TCH code list was consulted: the permitted list sits in the RTP Technical Specifications, under terms Orca has not accepted.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: no public source dates it", "effective_to": null, "effective_note": "No public source read says when this code became permitted on RTP [Unverified]. The pages it rests on were published or updated between 2023 and 2026.", "source_edition": "RTP Message Specifications not consulted (terms not accepted); the record rests on public bank and processor pages read 2026-09-19, and on the RTP Operating Rules effective 2026-06-01 for how a reject works", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "primary_not_public": true, "corroboration": [ { "source_url": "https://docs.crossriver.com/apis/payments/instant-payments/request-and-response-codes-instant-payments", "source_class": "secondary", "source_title": "Request and response codes: Instant payments (Cross River Bank)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms TK07 is listed as an RTP reject code meaning the single use token was already used." }, { "source_url": "https://triceapi.readme.io/reference/rtp-system-codes", "source_class": "secondary", "source_title": "RTP / FedNOW / ACH System Codes (Trice)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms TK07 is listed as an RTP reject code meaning the single use token was already used." } ] }, "rail_name": "RTP Payment Rejects", "governing_authority": "The Clearing House", "snapshot": "2026-09-19", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "not_public", "label": "the operator's own text", "needs": "what the operator's own text says, which Orca has not read", "detail": "The Clearing House's own text is not the source for this code: it is not public, or not under terms Orca can use. It rests on 2 named public sources, so a term set by agreement rather than by a published rule is not Orca's to state.", "from": "currency.primary_not_public" } ] }, { "uid": "rtp-reject:TK08", "id": "TK08", "rail": "rtp-reject", "kind": "reason-code", "name": "Token suspended", "group": "technical", "summary": "The token is suspended. Not an ISO 20022 code: ISO's status reason list (2Q2026) has TK01 to TK03, TK09 and lettered token codes but no TK04 to TK08, so [Inference] TK04 to TK08 are TCH's own codes for RTP. No public source read says whether the receiving participant or the RTP System sends it, so both are linked [Inference].", "triggers": [ "The token's owner or issuer has suspended it [Inference]" ], "actions": [ "Sender: ask the receiver for another way to pay" ], "retry": { "allowed": false, "rule": "Not with the same token while it is suspended." }, "facts": { "return_windows": [ { "action": "reject", "by": "Receiving Participant", "deadline": "Within the response time the RTP Technical Specifications set; the figure is not in the public Operating Rules. If the receiving participant has not answered by then, TCH cancels the payment and tells both participants." }, { "action": "reject", "by": "RTP System", "deadline": "On receipt, before the RTP System releases the payment message to the receiving participant." } ], "applies_to": "an RTP credit transfer or request for payment" }, "caveat": "No public TCH document read describes RTP's token service; the token codes rest on the Cross River Bank and Trice pages only [Unverified]. Same code, different rail: FedNow, SEPA and other ISO 20022 rails use their own lists and meanings, so never carry a meaning over from them.", "related": [ "rtp-reject:TK01" ], "basis": { "sources": "Listed as an RTP reject code by the Cross River Bank request and response codes page (family A); the Trice RTP system codes page (family B), all read 2026-09-19; the families agree on the meaning. ISO 20022 External Code Sets 2Q2026: not in ExternalStatusReason1Code. Reject mechanics from the TCH RTP Operating Rules effective 2026-06-01, Rules IV.A, V.C and V.E.3. No TCH code list was consulted: the permitted list sits in the RTP Technical Specifications, under terms Orca has not accepted.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: no public source dates it", "effective_to": null, "effective_note": "No public source read says when this code became permitted on RTP [Unverified]. The pages it rests on were published or updated between 2023 and 2026.", "source_edition": "RTP Message Specifications not consulted (terms not accepted); the record rests on public bank and processor pages read 2026-09-19, and on the RTP Operating Rules effective 2026-06-01 for how a reject works", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "primary_not_public": true, "corroboration": [ { "source_url": "https://docs.crossriver.com/apis/payments/instant-payments/request-and-response-codes-instant-payments", "source_class": "secondary", "source_title": "Request and response codes: Instant payments (Cross River Bank)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms TK08 is listed as an RTP reject code meaning the token is suspended." }, { "source_url": "https://triceapi.readme.io/reference/rtp-system-codes", "source_class": "secondary", "source_title": "RTP / FedNOW / ACH System Codes (Trice)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms TK08 is listed as an RTP reject code meaning the token is suspended." } ] }, "rail_name": "RTP Payment Rejects", "governing_authority": "The Clearing House", "snapshot": "2026-09-19", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "not_public", "label": "the operator's own text", "needs": "what the operator's own text says, which Orca has not read", "detail": "The Clearing House's own text is not the source for this code: it is not public, or not under terms Orca can use. It rests on 2 named public sources, so a term set by agreement rather than by a published rule is not Orca's to state.", "from": "currency.primary_not_public" } ] }, { "uid": "rtp-reject:TM01", "id": "TM01", "rail": "rtp-reject", "kind": "reason-code", "name": "Outside the cut-off time", "group": "network", "summary": "The message arrived after a cut-off time. An ISO 20022 status reason code (ExternalStatusReason1Code). The meaning given is the one the public bank and processor pages agree on for RTP; ISO's generic definition is a fallback only where they say nothing more. No public source read says whether the receiving participant or the RTP System sends it, so both are linked [Inference].", "triggers": [ "A time bound message, such as one tied to a request for payment or a settlement window, arrived too late [Inference]" ], "actions": [ "Sending participant: check which cut-off applies before sending a new payment" ], "retry": { "allowed": true, "rule": "Send a new payment message once the fault is fixed; the rejected payment never settled, so there is nothing to reverse or return." }, "facts": { "return_windows": [ { "action": "reject", "by": "Receiving Participant", "deadline": "Within the response time the RTP Technical Specifications set; the figure is not in the public Operating Rules. If the receiving participant has not answered by then, TCH cancels the payment and tells both participants." }, { "action": "reject", "by": "RTP System", "deadline": "On receipt, before the RTP System releases the payment message to the receiving participant." } ], "applies_to": "an RTP credit transfer" }, "caveat": "A receiving participant may not set cut-off times that move a payment to another RTP day (Operating Rules V.B). None of the sources says which cut-off TM01 refers to on RTP [Unverified]. Same code, different rail: FedNow, SEPA and other ISO 20022 rails use their own lists and meanings, so never carry a meaning over from them.", "related": [], "basis": { "sources": "Listed as an RTP reject code by the Cross River Bank request and response codes page (family A); the Trice RTP system codes page (family B), all read 2026-09-19; the families agree on the meaning. ISO 20022 External Code Sets 2Q2026: in ExternalStatusReason1Code. Reject mechanics from the TCH RTP Operating Rules effective 2026-06-01, Rules IV.A, V.C and V.E.3. No TCH code list was consulted: the permitted list sits in the RTP Technical Specifications, under terms Orca has not accepted.", "confidence": "low" }, "currency": { "effective_since": "Unknown: no public source dates it", "effective_to": null, "effective_note": "No public source read says when this code became permitted on RTP [Unverified]. The pages it rests on were published or updated between 2023 and 2026.", "source_edition": "RTP Message Specifications not consulted (terms not accepted); the record rests on public bank and processor pages read 2026-09-19, and on the RTP Operating Rules effective 2026-06-01 for how a reject works", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "primary_not_public": true, "corroboration": [ { "source_url": "https://docs.crossriver.com/apis/payments/instant-payments/request-and-response-codes-instant-payments", "source_class": "secondary", "source_title": "Request and response codes: Instant payments (Cross River Bank)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms TM01 is listed as an RTP reject code meaning the payment arrived outside the cut off time." }, { "source_url": "https://triceapi.readme.io/reference/rtp-system-codes", "source_class": "secondary", "source_title": "RTP / FedNOW / ACH System Codes (Trice)", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms TM01 is listed as an RTP reject code meaning the payment arrived outside the cut off time." } ] }, "rail_name": "RTP Payment Rejects", "governing_authority": "The Clearing House", "snapshot": "2026-09-19", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for RTP credit transfer (pacs.008). Its own scope line reads: an RTP credit transfer.", "from": "applies_to" }, { "kind": "not_public", "label": "the operator's own text", "needs": "what the operator's own text says, which Orca has not read", "detail": "The Clearing House's own text is not the source for this code: it is not public, or not under terms Orca can use. It rests on 2 named public sources, so a term set by agreement rather than by a published rule is not Orca's to state.", "from": "currency.primary_not_public" } ] }, { "uid": "rtp-return-request:CUST", "id": "CUST", "rail": "rtp-return-request", "kind": "reason-code", "name": "Customer decision (receiver refused to return funds)", "group": "authorization", "summary": "A reason on the receiving participant's negative response: the receiver refused to return the funds. The Operating Rules name this code and bar the sending participant from asking again for the same payment once it has been received.", "triggers": [ "The receiver says the payment was owed to them and declines to give debit authority", "The receiver disputes the sender's account of what happened and keeps the funds" ], "actions": [ "Receiving participant: send a negative (RJCR status) response with CUST only when the receiver has actually refused; if the receiver could not be reached, NOAS is the reason the guidelines describe", "Sending participant: do not send another request for this payment; the dispute now sits outside the RTP network (Operating Rules VII.D.4)", "Sending participant: for a consumer account, the Regulation E error resolution duties stay with you whatever the response (2021 guidelines item 1) [Inference: whether the sender must recredit depends on the facts and on Regulation E, not on this code]", "Sending participant: tell the customer that RTP gives no chargeback right and that any further recovery is between the parties (2021 guidelines item 9)" ], "retry": { "allowed": false, "rule": "A sending participant may not resubmit a request for return of funds for the same payment after a negative response with reason CUST, unless TCH requires the resubmission in the RTP Technical Specifications or a published interpretation of the Operating Rules (Operating Rules VII.D.4)." }, "facts": { "return_windows": [ { "action": "negative response (camt.029, RJCR status) citing CUST", "by": "Receiving Participant (creditor FI)", "deadline": "10 banking days from receipt of the request; no fixed deadline when the request cited FRAD or UPAY (Operating Rules VII.D.2)" } ], "applies_to": "a response to any RTP request for return of funds" }, "caveat": "An RTP payment is final and irrevocable once accepted, and the sender cannot cancel it (Operating Rules I.E, III.E). A Request for Return of Funds is a non-financial message, not a cancellation, not a debit, and not an ACH-style return (VII.D). The receiving participant must answer it but need not return funds (VII.D.1). If funds come back, they move as a new payment (RTP credit transfer, wire, ACH credit, or check), not as a reversal (2021 guidelines item 4).", "related": [ "rtp-return-request:FRAD", "rtp-return-request:UPAY", "rtp-return-request:DUPL", "rtp-return-request:TECH" ], "basis": { "sources": "TCH RTP Operating Rules, edition effective 2026-06-01 (marked PUBLIC), Rule VII.D.1 (no obligation to return), VII.D.2 (response deadline), VII.D.4 (names CUST as the receiver's refusal and bars resubmission). TCH Compendium of RTP Rule Change Summaries, November 2019 to 2026 (marked PUBLIC), summary of changes effective 2019-11-18 (new rule, then VII.C.4). TCH RTP Request for Return of Funds Guidelines and Suggested Practices, dated 2021-01-21 (marked Public; guidance, not rule), items 1, 2, 9. BNY ISO 20022 webcast Module 7, camt.056 and camt.029 (September 2020, secondary, cross-border CBPR+ context) for the generic ISO code name only: CUST in camt.029 is the ISO code Customer Decision; ISO also uses CUST as a camt.056 cancellation reason, Requested By Customer, which is a different meaning [Unverified whether RTP permits CUST in the request message]. Group authorization chosen because the reason is that the receiver withheld the debit authority a return needs [Inference: the schema has no response or decline group].", "confidence": "medium" }, "currency": { "effective_since": "2019-11-18", "effective_note": "The bar on resubmission after CUST took effect 2019-11-18 as new Rule VII.C.4, now VII.D.4. The code may have been in use earlier [Unverified].", "source_edition": "TCH RTP Operating Rules, edition effective 2026-06-01 (marked PUBLIC), Rule VII.D.4; TCH Compendium of RTP Rule Change Summaries, November 2019 to 2026 (marked PUBLIC), summary of changes effective 2019-11-18", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.theclearinghouse.org/-/media/New/TCH/Documents/Payment-Systems/RTP/RTP-Operating-Rules-Effective-June-1-2026pdf.pdf", "source_class": "authoritative_primary", "source_title": "RTP Operating Rules, effective June 1 2026", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms CUST is the named reason code in Rule VII.D.4 for a negative RJCR response due to the receiver refusing to return funds, confirms the sending participant may not resubmit a request for the same payment after a CUST response unless TCH requires it, and confirms the general ten banking day response window and the FRAD or UPAY exemption in VII.D.2. Does not address the distinction between CUST and NOAS or the Regulation E point, both of which come from the 2021 guidelines and are cited that way in the record." } ] }, "rail_name": "RTP Return Request Reasons", "governing_authority": "The Clearing House", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "rtp-return-request:DUPL", "id": "DUPL", "rail": "rtp-return-request", "kind": "reason-code", "name": "Duplicate payment", "group": "administrative", "summary": "The sending participant asks for money back because the payment was a duplicate. The public TCH guidelines name DUPL as a return request reason and link it to duplicated files or payments; the receiving participant has ten banking days to respond.", "triggers": [ "A file of payments was released into the network twice", "A single payment was sent twice by the sender, the sending participant, or its service provider [Inference]" ], "actions": [ "Sending participant: send one request per duplicated payment; the network has no bulk return request (2021 guidelines, use case note 1)", "Sending participant: for a large duplicated release, tell TCH at once and work directly with the affected receiving participants (2021 guidelines, lessons learned)", "Sending participant: consider the standard optional indemnity, which the guidelines expect to accompany DUPL often", "Receiving participant: respond within ten banking days; a partial return is allowed and should not be rejected just because only part of the funds remain", "Everyone: build controls that stop duplicates before release, since an RTP payment cannot be recalled" ], "retry": { "allowed": true, "rule": "Not after a negative response with reason CUST (Operating Rules VII.D.4), unless TCH requires it. The 2021 guidelines allow one more request after NOAS, after no response within ten banking days, after a partial return (for the balance), or by agreement (item 8)." }, "facts": { "return_windows": [ { "action": "request for return of funds (camt.056)", "by": "Sending Participant (debtor FI)", "deadline": "within 60 calendar days of the original payment, as a guideline, not a rule (2021 guidelines item 5)" }, { "action": "response to the request (camt.029, accept or reject with a reason)", "by": "Receiving Participant (creditor FI)", "deadline": "10 banking days from receipt of the request (Operating Rules VII.D.2)" }, { "action": "return of funds as a new payment, only if the receiving side agrees", "by": "Receiving Participant (creditor FI)", "deadline": "2 business days after its positive response, as a guideline, not a rule (2021 guidelines item 2)" } ], "applies_to": "a settled RTP credit transfer that duplicated another" }, "caveat": "An RTP payment is final and irrevocable once accepted, and the sender cannot cancel it (Operating Rules I.E, III.E). A Request for Return of Funds is a non-financial message, not a cancellation, not a debit, and not an ACH-style return (VII.D). The receiving participant must answer it but need not return funds (VII.D.1). If funds come back, they move as a new payment (RTP credit transfer, wire, ACH credit, or check), not as a reversal (2021 guidelines item 4).", "related": [ "rtp-return-request:TECH", "rtp-return-request:CUST", "rtp-return-request:NOAS" ], "basis": { "sources": "TCH RTP Operating Rules, edition effective 2026-06-01 (marked PUBLIC), Rule II.J.1 (duplicate payment is a recognized error), VII.D, VII.D.1, VII.D.2 (ten banking days), VII.D.4. TCH RTP Request for Return of Funds Guidelines and Suggested Practices, dated 2021-01-21 (marked Public; guidance, not rule), use case note 1, items 2, 4, 5, 6 (names DUPL and pairs it with duplicated files), 8, and lessons learned. BNY ISO 20022 webcast Module 7, camt.056 and camt.029 (September 2020, secondary, cross-border CBPR+ context) for the generic ISO code name only: DUPL is the ISO code Duplicate Payment. The Operating Rules do not name DUPL; its RTP meaning is taken from the guidelines and the ISO name [Inference]. Group administrative chosen because a duplicate is a processing error on the sending side, not a funds, account, or authorization problem.", "confidence": "medium" }, "currency": { "effective_since": "2019-11-18", "effective_note": "The ten banking day response deadline took effect 2019-11-18 (then Rule VII.C.2, now VII.D.2). The date DUPL became a permitted RTP code is not stated in any public source read [Unverified].", "source_edition": "TCH RTP Operating Rules, edition effective 2026-06-01 (marked PUBLIC), Rule VII.D.2; TCH RTP Request for Return of Funds Guidelines and Suggested Practices, dated 2021-01-21 (marked Public; guidance, not rule), items 5, 6, 8", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "rail_name": "RTP Return Request Reasons", "governing_authority": "The Clearing House", "snapshot": "2026-09-17", "source_class": null, "effective_status": "draft", "effective_status_reason": null, "boundaries": [] }, { "uid": "rtp-return-request:FRAD", "id": "FRAD", "rail": "rtp-return-request", "kind": "reason-code", "name": "Fraudulent origin (claimed fraud or unauthorized payment)", "group": "authorization", "summary": "The sending participant asks for money back because it claims the RTP payment was fraudulent, for example an account takeover or other unauthorized payment. The Operating Rules name this code and exempt it from the ten banking day response deadline so the receiving participant can investigate.", "triggers": [ "The sender's account was taken over and a payment went out that the account holder did not authorize", "The account holder reports a payment they did not make", "The sender claims it was induced by fraud into sending an authorized payment [Inference: the 2021 guidelines list fraudulent inducement as a valid basis to request return but do not say which code it takes]" ], "actions": [ "Sending participant: use FRAD whenever an account takeover or other unauthorized payment is suspected or reported; the 2021 guidelines say this is how a sending participant meets the Operating Rules duty to report unauthorized payments to TCH", "Sending participant: if the original payment was accepted without posting (ACWP), wait for the receiving participant's final disposition before sending the request (2021 guidelines item 5)", "Sending participant: consider offering the standard optional indemnity with the request; the 2021 guidelines expect it to accompany FRAD, DUPL, or TECH most often", "Receiving participant: investigate promptly and send the response when the investigation ends; the ten banking day deadline does not apply to FRAD", "Receiving participant: if funds are returned, send them as a new payment addressed to the original sender's account and referencing the original payment" ], "retry": { "allowed": true, "rule": "A request may be sent again only in limited cases. It may not be resubmitted after a negative response with reason CUST (Operating Rules VII.D.4), unless TCH requires the resubmission. The 2021 guidelines allow one more request after a negative response with NOAS, after no response within the ten banking day window, after a partial return (for the balance), or by agreement between the parties (item 8) [Inference: the ten banking day trigger does not fit FRAD, which has no fixed response deadline]." }, "facts": { "return_windows": [ { "action": "request for return of funds (camt.056)", "by": "Sending Participant (debtor FI)", "deadline": "no deadline; the 60 calendar day guideline does not apply to fraud claims (2021 guidelines item 5)" }, { "action": "response to the request (camt.029, accept or reject with a reason)", "by": "Receiving Participant (creditor FI)", "deadline": "no fixed deadline; may exceed 10 banking days to allow investigation, and is expected promptly once the investigation ends (Operating Rules VII.D.2)" }, { "action": "return of funds as a new payment, only if the receiving side agrees", "by": "Receiving Participant (creditor FI)", "deadline": "2 business days after its positive response, as a guideline, not a rule (2021 guidelines item 2)" } ], "applies_to": "a settled RTP credit transfer claimed to be fraudulent or unauthorized" }, "caveat": "An RTP payment is final and irrevocable once accepted, and the sender cannot cancel it (Operating Rules I.E, III.E). A Request for Return of Funds is a non-financial message, not a cancellation, not a debit, and not an ACH-style return (VII.D). The receiving participant must answer it but need not return funds (VII.D.1). If funds come back, they move as a new payment (RTP credit transfer, wire, ACH credit, or check), not as a reversal (2021 guidelines item 4).", "related": [ "rtp-return-request:UPAY", "rtp-return-request:CUST", "rtp-return-request:NOAS", "rtp-return-request:UAPA" ], "basis": { "sources": "TCH RTP Operating Rules, edition effective 2026-06-01 (marked PUBLIC), Rule VII.D (any reason, including unauthorized payments), VII.D.1 (must respond, no duty to return), VII.D.2 (names FRAD and exempts it from the ten banking day deadline), VII.D.4, I.E and III.E (finality). TCH RTP Request for Return of Funds Guidelines and Suggested Practices, dated 2021-01-21 (marked Public; guidance, not rule), items 2, 4, 5, 6, 7, 8. BNY ISO 20022 webcast Module 7, camt.056 and camt.029 (September 2020, secondary, cross-border CBPR+ context) for the generic ISO code name only: FRAD is the ISO code Fraudulent Origin. Group authorization chosen because the claim is that the payment was not authorized by the account holder or was fraud; the schema has no fraud group.", "confidence": "medium" }, "currency": { "effective_since": "2019-11-18", "effective_note": "The FRAD exemption from the response deadline is stated in the 2019-11-18 rule change summary, when the deadline became ten banking days (then Rule VII.C.2, now VII.D.2). The code itself may be older [Unverified].", "source_edition": "TCH RTP Operating Rules, edition effective 2026-06-01 (marked PUBLIC), Rule VII.D.2; TCH RTP Request for Return of Funds Guidelines and Suggested Practices, dated 2021-01-21 (marked Public; guidance, not rule), items 5 to 8", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.theclearinghouse.org/-/media/New/TCH/Documents/Payment-Systems/RTP/RTP-Operating-Rules-Effective-June-1-2026pdf.pdf", "source_class": "authoritative_primary", "source_title": "RTP Operating Rules, effective June 1 2026", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms FRAD is a named reason code for claimed fraud in Rule VII.D.2, confirms it is exempt from the ten banking day response deadline, confirms the receiving participant has no duty to return funds VII.D.1, and confirms the resubmission bar tied to CUST in VII.D.4. Does not address the 60 calendar day request guideline or the two business day return of funds timing, which come only from the 2021 guidelines and are cited that way in the record." } ] }, "rail_name": "RTP Return Request Reasons", "governing_authority": "The Clearing House", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "rtp-return-request:NOAS", "id": "NOAS", "rail": "rtp-return-request", "kind": "reason-code", "name": "No answer from customer", "group": "authorization", "summary": "A reason on the receiving participant's negative response: it got no answer from, or could not contact, the receiver. The public TCH guidelines name this code and allow the sending participant to ask one more time after it.", "triggers": [ "The receiver did not respond to calls, letters, texts, emails, or online banking alerts asking for debit authority", "The receiving participant could not reach the receiver at all" ], "actions": [ "Receiving participant: try more than one channel before responding; the guidelines note that retail receivers rarely answer phone calls (2021 guidelines, lessons learned)", "Receiving participant: respond within ten banking days of the request, or when the investigation ends for FRAD and UPAY", "Sending participant: you may send one more request for the same payment, with a new Assignment ID that still references the original payment's Instruction ID (2021 guidelines item 8)", "Sending participant: if the second request also fails, pursue recovery outside the network [Inference]" ], "retry": { "allowed": true, "rule": "The 2021 guidelines allow one additional request after a negative response with reason NOAS, with a unique Assignment ID that references the original payment (item 8). This is guidance; the Operating Rules bar resubmission only after CUST (VII.D.4)." }, "facts": { "return_windows": [ { "action": "negative response (camt.029, RJCR status) citing NOAS", "by": "Receiving Participant (creditor FI)", "deadline": "10 banking days from receipt of the request; no fixed deadline when the request cited FRAD or UPAY (Operating Rules VII.D.2)" }, { "action": "one resubmitted request for return of funds (camt.056)", "by": "Sending Participant (debtor FI)", "deadline": "no deadline stated in the public sources read" } ], "applies_to": "a response to any RTP request for return of funds" }, "caveat": "An RTP payment is final and irrevocable once accepted, and the sender cannot cancel it (Operating Rules I.E, III.E). A Request for Return of Funds is a non-financial message, not a cancellation, not a debit, and not an ACH-style return (VII.D). The receiving participant must answer it but need not return funds (VII.D.1). If funds come back, they move as a new payment (RTP credit transfer, wire, ACH credit, or check), not as a reversal (2021 guidelines item 4).", "related": [ "rtp-return-request:CUST", "rtp-return-request:FRAD", "rtp-return-request:UPAY", "rtp-return-request:DUPL", "rtp-return-request:TECH" ], "basis": { "sources": "TCH RTP Request for Return of Funds Guidelines and Suggested Practices, dated 2021-01-21 (marked Public; guidance, not rule), item 8 (names NOAS as non-response or inability to contact the receiver and allows one resubmission) and lessons learned. TCH RTP Operating Rules, edition effective 2026-06-01 (marked PUBLIC), Rule VII.D.1, VII.D.2, VII.D.4. BNY ISO 20022 webcast Module 7, camt.056 and camt.029 (September 2020, secondary, cross-border CBPR+ context) for the generic ISO code name only: NOAS is the ISO code No Answer From Customer. The Operating Rules do not name NOAS. Group authorization chosen because the reason is that no debit authority could be obtained from the receiver [Inference: the schema has no response or decline group].", "confidence": "medium" }, "currency": { "effective_since": "2021-01-21", "effective_note": "Date of the public guidelines that name NOAS and allow one resubmission. The code may have been permitted earlier [Unverified].", "source_edition": "TCH RTP Request for Return of Funds Guidelines and Suggested Practices, dated 2021-01-21 (marked Public; guidance, not rule), item 8; TCH RTP Operating Rules, edition effective 2026-06-01 (marked PUBLIC), Rule VII.D.2", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "rail_name": "RTP Return Request Reasons", "governing_authority": "The Clearing House", "snapshot": "2026-09-17", "source_class": null, "effective_status": "draft", "effective_status_reason": null, "boundaries": [] }, { "uid": "rtp-return-request:TECH", "id": "TECH", "rail": "rtp-return-request", "kind": "reason-code", "name": "Technical problem", "group": "technical", "summary": "The sending participant asks for money back because a technical problem produced an erroneous payment. The public TCH guidelines name TECH as a return request reason and associate it with bank error; the receiving participant has ten banking days to respond.", "triggers": [ "A system fault at the sending participant or its service provider sent a wrong payment [Inference]", "A payment went out with a wrong amount or to an unintended receiver because of a processing error [Inference: Operating Rules II.J.1 lists these errors but does not map them to codes]" ], "actions": [ "Sending participant: consider the standard optional indemnity, which the guidelines expect to accompany TECH often", "Sending participant: use the additional information field to explain the error so the receiving participant can investigate (2021 guidelines, lessons learned)", "Receiving participant: respond within ten banking days", "Receiving participant: do not send funds back on your own initiative because of your own system trouble after accepting and acknowledging a payment; a 2024 TCH rules interpretation treats that as a violation [Unverified: interpretation summarized in Orca's RTP rail brief (docs/rails/rtp.md), not reread for this record]" ], "retry": { "allowed": true, "rule": "Not after a negative response with reason CUST (Operating Rules VII.D.4), unless TCH requires it. The 2021 guidelines allow one more request after NOAS, after no response within ten banking days, after a partial return, or by agreement (item 8)." }, "facts": { "return_windows": [ { "action": "request for return of funds (camt.056)", "by": "Sending Participant (debtor FI)", "deadline": "within 60 calendar days of the original payment, as a guideline, not a rule (2021 guidelines item 5)" }, { "action": "response to the request (camt.029, accept or reject with a reason)", "by": "Receiving Participant (creditor FI)", "deadline": "10 banking days from receipt of the request (Operating Rules VII.D.2)" }, { "action": "return of funds as a new payment, only if the receiving side agrees", "by": "Receiving Participant (creditor FI)", "deadline": "2 business days after its positive response, as a guideline, not a rule (2021 guidelines item 2)" } ], "applies_to": "a settled RTP credit transfer made in error because of a technical problem" }, "caveat": "An RTP payment is final and irrevocable once accepted, and the sender cannot cancel it (Operating Rules I.E, III.E). A Request for Return of Funds is a non-financial message, not a cancellation, not a debit, and not an ACH-style return (VII.D). The receiving participant must answer it but need not return funds (VII.D.1). If funds come back, they move as a new payment (RTP credit transfer, wire, ACH credit, or check), not as a reversal (2021 guidelines item 4).", "related": [ "rtp-return-request:DUPL", "rtp-return-request:CUST", "rtp-return-request:NOAS" ], "basis": { "sources": "TCH RTP Operating Rules, edition effective 2026-06-01 (marked PUBLIC), Rule II.J.1, VII.D, VII.D.1, VII.D.2, VII.D.4. TCH RTP Request for Return of Funds Guidelines and Suggested Practices, dated 2021-01-21 (marked Public; guidance, not rule), items 5, 6 (names TECH and pairs it, loosely, with bank error), 8. BNY ISO 20022 webcast Module 7, camt.056 and camt.029 (September 2020, secondary, cross-border CBPR+ context) for the generic ISO code name only: TECH is the ISO code Technical Problem. The Operating Rules do not name TECH, and no public TCH source read defines it; its RTP meaning is inferred from the guidelines and the ISO name. Group technical chosen because the code names a technical fault.", "confidence": "low" }, "currency": { "effective_since": "2019-11-18", "effective_note": "The ten banking day response deadline took effect 2019-11-18 (then Rule VII.C.2, now VII.D.2). The date TECH became a permitted RTP code is not stated in any public source read [Unverified].", "source_edition": "TCH RTP Operating Rules, edition effective 2026-06-01 (marked PUBLIC), Rule VII.D.2; TCH RTP Request for Return of Funds Guidelines and Suggested Practices, dated 2021-01-21 (marked Public; guidance, not rule), items 5, 6, 8", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "rail_name": "RTP Return Request Reasons", "governing_authority": "The Clearing House", "snapshot": "2026-09-17", "source_class": null, "effective_status": "draft", "effective_status_reason": null, "boundaries": [] }, { "uid": "rtp-return-request:UAPA", "id": "UAPA", "rail": "rtp-return-request", "kind": "reason-code", "name": "Fraudulently induced payment", "group": "authorization", "summary": "The sending participant asks for money back, and reports fraud to TCH, because it has determined that the sender authorized an RTP-native payment but was deceived into making it, for example by impersonation or social engineering. TCH has required this code for that report since 2026-03-31; an unauthorized payment takes FRAD instead. This record states the duty as it stands until 2026-09-30, when TCH widens UAPA reporting to IDS payments (see the effective note).", "triggers": [ "The sending participant determines the sender was deceived into sending an RTP-native payment, for example by someone impersonating a trusted party" ], "actions": [ "Sending participant: send a Request for Return of Funds (camt.056) with UAPA as the fraud report required by Operating Rule II.G.2; email to TCH is not a substitute for an individual payment report", "Sending participant: if the induced payment also meets the Request for Payment warranty claim prerequisites, use UPAY instead of UAPA", "Sending participant: if an earlier camt.056 for the same payment used another code and fraud is later confirmed, send a second camt.056 with UAPA", "Receiving participant: respond with a Response to Request for Return of Funds (camt.029); it must respond but has no duty to return funds (Operating Rules VII.D.1)", "Receiving participant: if funds are returned, send them as a new payment, not a reversal" ], "retry": { "allowed": true, "rule": "A request may not be resubmitted after a negative response with reason CUST (Operating Rules VII.D.4), unless TCH requires it. The rules interpretation requires a second camt.056 with UAPA when fraud is confirmed after an earlier request under another code. [Inference] The 2021 guideline allowances for one more request after NOAS or no response apply as for other codes; the guidelines predate UAPA." }, "facts": { "return_windows": [ { "action": "request for return of funds with UAPA (camt.056), as a fraud report", "by": "Sending Participant (debtor FI)", "deadline": "none stated while this record applies; the interpretation's two business day limit (section 1.c) starts 2027-03-01, after this record's effective_to" }, { "action": "response to the request (camt.029, accept or reject with a reason)", "by": "Receiving Participant (creditor FI)", "deadline": "10 banking days [Inference: Operating Rules VII.D.2 exempts only FRAD and UPAY from the ten banking day deadline and does not name UAPA]" } ], "applies_to": "a settled RTP-native credit transfer (not an RTP/Zelle Message) that the sending participant has determined the sender was fraudulently induced to send" }, "caveat": "UAPA does not appear in the Operating Rules text (editions effective 2026-06-01, 2026-09-30, 2026-10-04); it is required by a TCH rules interpretation issued under Operating Rule I.C. An RTP payment is final and irrevocable once accepted (Operating Rules I.E, III.E). A Request for Return of Funds is a request, not a cancellation or a debit (VII.D).", "related": [ "rtp-return-request:FRAD", "rtp-return-request:UPAY", "rtp-return-request:CUST" ], "basis": { "sources": "TCH RTP Rules Interpretation, Fraud Reporting and Acting on Alerts, RTP Operating Rule II.G, dated 2026-09-14 (marked Public), sections 1.a, 1.b (category chart and notes 3, 4, 6), 1.c, 1.d.i, 1.d.ii; reread 2026-09-26 for the 2026-09-30 date (introduction and the section 1.d.ii heading). TCH RTP Network Compliance Bulletin 1-2026, dated 2026-02-23 (marked PUBLIC), confirming the UAPA requirement from 2026-03-31. TCH RTP Operating Rules, editions effective 2026-06-01, 2026-09-30, and 2026-10-04, Rule VII.D.1, VII.D.2, VII.D.4, I.E, III.E; searched for UAPA, not found. TCH RTP Request for Return of Funds Guidelines and Suggested Practices, dated 2021-01-21 (marked Public; guidance, not rule), items 4 and 8, for return as a new payment and resubmission; these predate UAPA. Group authorization chosen as the nearest fit for fraud; the schema has no fraud group.", "confidence": "medium" }, "currency": { "effective_since": "2026-03-31", "effective_to": "2026-09-30", "effective_note": "UAPA fraud reporting required from 2026-03-31 (section 1.b). This record's statement stops applying 2026-09-30: from that date, under section 1.d.ii of the rules interpretation dated 2026-09-14, a Sending Participant of IDS Payments must also send UAPA for an IDS Payment found to have been fraudulently induced, whether the IDS Originating Institution passes that determination on or the Sending Participant reaches it through its own processes (note 8). UAPA stays in use with that wider scope; once the date has passed the RTP watch drafts the successor under the dated-id procedure in docs/watch.md. Later dates for the successor, not asserted by this record: the two business day reporting deadline (section 1.c) and OBO reporting (section 1.d.i), both 2027-03-01. Found by the RTP watch 2026-09-17; the end date was typed after a later reread of the interpretation (see basis).", "source_edition": "TCH RTP Rules Interpretation, Fraud Reporting and Acting on Alerts, dated 2026-09-14; TCH RTP Network Compliance Bulletin 1-2026, dated 2026-02-23", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "rail_name": "RTP Return Request Reasons", "governing_authority": "The Clearing House", "snapshot": "2026-09-17", "source_class": null, "effective_status": "draft", "effective_status_reason": null, "boundaries": [] }, { "uid": "rtp-return-request:UPAY", "id": "UPAY", "rail": "rtp-return-request", "kind": "reason-code", "name": "Undue payment (breach of Request for Payment warranty)", "group": "authorization", "summary": "The sending participant asks for money back because the payment was made in response to a Request for Payment that it claims breached the Request for Payment warranty. The Operating Rules name this code and, as with FRAD, exempt it from the ten banking day response deadline.", "triggers": [ "A payer paid a Request for Payment that turned out to be fraudulent", "A payer paid a Request for Payment that was not made for a legitimate purpose as the Operating Rules define it (Rule VII.B.3)" ], "actions": [ "Sending participant: send the request citing UPAY, which the Operating Rules tie to a claimed breach of the Request for Payment warranty", "Sending participant: note that the Operating Rules also provide a separate warranty claim and arbitration process for Request for Payment breaches (Rule VII.C); the return request is not that claim [Inference: how the two processes interact in practice is not stated in the text read]", "Receiving participant (the participant that sent the Request for Payment): investigate promptly and respond when done; the ten banking day deadline does not apply to UPAY", "Do not read UPAY by its generic ISO name alone. ISO calls it Undue Payment; on RTP the rules give it the narrower Request for Payment meaning" ], "retry": { "allowed": true, "rule": "A request may not be resubmitted after a negative response with reason CUST (Operating Rules VII.D.4), unless TCH requires the resubmission. The 2021 guidelines allow one more request after NOAS, after a partial return, or by agreement (item 8)." }, "facts": { "return_windows": [ { "action": "request for return of funds (camt.056)", "by": "Sending Participant (debtor FI)", "deadline": "no deadline; the 60 calendar day guideline does not apply to payments made in response to a Request for Payment claimed not to be for a legitimate purpose (2021 guidelines item 5)" }, { "action": "response to the request (camt.029, accept or reject with a reason)", "by": "Receiving Participant (creditor FI)", "deadline": "no fixed deadline; may exceed 10 banking days to allow investigation, and is expected promptly once the investigation ends (Operating Rules VII.D.2)" }, { "action": "return of funds as a new payment, only if the receiving side agrees", "by": "Receiving Participant (creditor FI)", "deadline": "2 business days after its positive response, as a guideline, not a rule (2021 guidelines item 2)" } ], "applies_to": "a settled RTP credit transfer sent in response to a Request for Payment" }, "caveat": "An RTP payment is final and irrevocable once accepted, and the sender cannot cancel it (Operating Rules I.E, III.E). A Request for Return of Funds is a non-financial message, not a cancellation, not a debit, and not an ACH-style return (VII.D). The receiving participant must answer it but need not return funds (VII.D.1). If funds come back, they move as a new payment (RTP credit transfer, wire, ACH credit, or check), not as a reversal (2021 guidelines item 4).", "related": [ "rtp-return-request:FRAD", "rtp-return-request:CUST", "rtp-return-request:NOAS", "rtp-return-request:UAPA" ], "basis": { "sources": "TCH RTP Operating Rules, edition effective 2026-06-01 (marked PUBLIC), Rule VII.D (any reason, including a payment made in response to a fraudulent Request for Payment), VII.D.1, VII.D.2 (names UPAY as breach of a Request for Payment warranty and exempts it from the ten banking day deadline), VII.D.4, VII.B and VII.C (Request for Payment warranty and claims). TCH RTP Request for Return of Funds Guidelines and Suggested Practices, dated 2021-01-21 (marked Public; guidance, not rule), item 5. BNY ISO 20022 webcast Module 7, camt.056 and camt.029 (September 2020, secondary, cross-border CBPR+ context) for the generic ISO code name only: UPAY is the ISO code Undue Payment. Group authorization chosen because the claim is that the payer's payment rests on a request that breached the warranty the requester gave, which is closer to an authorization failure than to any other group in the schema [Inference].", "confidence": "medium" }, "currency": { "effective_since": "2019-11-18", "effective_note": "The UPAY exemption from the response deadline is stated in the 2019-11-18 rule change summary (then Rule VII.C.2, now VII.D.2). The code itself may be older [Unverified].", "source_edition": "TCH RTP Operating Rules, edition effective 2026-06-01 (marked PUBLIC), Rule VII.D.2 and VII.C; TCH RTP Request for Return of Funds Guidelines and Suggested Practices, dated 2021-01-21 (marked Public; guidance, not rule), item 5", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.theclearinghouse.org/-/media/New/TCH/Documents/Payment-Systems/RTP/RTP-Operating-Rules-Effective-June-1-2026pdf.pdf", "source_class": "authoritative_primary", "source_title": "RTP Operating Rules, effective June 1 2026", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms UPAY is a named reason code for breach of a Request for Payment warranty in Rule VII.D.2, confirms it is exempt from the ten banking day response deadline, confirms the receiving participant has no duty to return funds VII.D.1, and confirms the resubmission bar tied to CUST in VII.D.4. Does not address the 60 calendar day request guideline or the two business day return of funds timing, which come only from the 2021 guidelines and are cited that way in the record. Does not address how the return request interacts with the separate RFP warranty arbitration process in VII.C." } ] }, "rail_name": "RTP Return Request Reasons", "governing_authority": "The Clearing House", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sct:AC01", "id": "AC01", "rail": "sepa-sct", "kind": "reason-code", "name": "Account identifier incorrect", "group": "account", "summary": "The Beneficiary's IBAN is badly formed or does not exist at the Beneficiary PSP.", "triggers": [ "The IBAN fails the format check (reject)", "The IBAN does not exist at the Beneficiary PSP (reject or return)", "The Beneficiary gave the Originator a wrong IBAN", "The Originator took a wrong IBAN from its own customer data", "A technical problem at the Originator while issuing the instruction" ], "actions": [ "Originator to obtain the correct IBAN from the Beneficiary", "Originator PSP to check IBAN plausibility when it accepts the instruction, as the rulebook requires (section 4.3.1 CT-01.02 and section 5.7 item 12)" ], "retry": { "allowed": true, "rule": "Send a new transfer once the correct IBAN is known. A new transfer is a new Credit Transfer Instruction. A rejected instruction that the Originator PSP repairs and resends is also treated as a new instruction (EPC125-05 2025 v1.1 section 4.3.2.2, CT-01.03R)." }, "facts": { "return_windows": [ { "action": "reject", "by": "Originator PSP or CSM", "deadline": "Before inter-PSP settlement. Sent the same day where possible and no later than the next Banking Business Day (a T2 day); the CSM passes a reject to the Originator PSP no later than the next Banking Business Day after rejecting" }, { "action": "return", "by": "Beneficiary PSP", "deadline": "After inter-PSP settlement. The Return message and the funds go to the Originator PSP through the CSM no later than 3 Banking Business Days after the Settlement Date" } ], "applies_to": "SCT" }, "caveat": "The guidance lists a non-existent IBAN at the Beneficiary PSP as a reject case, but the rulebook's reject reasons are framed as rejects by the Originator PSP or the CSM (AT-R004); how that case is detected before settlement is not explained [Inference: a CSM or reachability check]. The rulebook does also list the Beneficiary PSP as a possible sender of reject and return messages (AT-R002). The Beneficiary PSP credits on the IBAN as the unique identifier (section 5.8 item 8).", "related": [ "sepa-sct:AC03", "sepa-sct:AC04", "sepa-sct:AC06", "sepa-sct:RC01" ], "basis": { "sources": "EPC135-18 v6.0 section 3, entry for AC01 (ISO name, rulebook reason, R-transaction types, use cases, root causes, suggested action); EPC125-05 2025 v1.1 sections 4.3.2.1, 4.3.2.2 CT-01.03R and 4.6.1 AT-R002, AT-R004 (reject: before inter-PSP settlement, by the Originator PSP or the CSM, same day and at the latest the next Banking Business Day); EPC125-05 2025 v1.1 sections 4.3.2.2, CT-01.04R and 4.6.1 AT-R004, AT-R005 (return: Beneficiary PSP, after settlement, message and funds within 3 Banking Business Days after the Settlement Date); EPC125-05 2025 v1.1 sections 4.3.1 CT-01.02, 5.7 item 12 and 5.8 item 8 (IBAN checks and IBAN as unique identifier); EPC125-05 2025 v1.1 chapter 7 (a Banking Business Day is a T2 day).", "confidence": "high" }, "currency": { "effective_since": "2025-10-05", "effective_note": "EPC125-05 2025 v1.1 was issued and took effect on 2025-10-05; v1.1 changed only the date for the unstructured address phase-out, now 15 November 2026. EPC135-18 v6.0, published 2024-11-28, is taken to be the current SCT reason code guidance and to cover the 2025 rulebook [Unverified]. The next SCT rulebook is due for publication in November 2026 [Unverified].", "source_edition": "EPC135-18 v6.0; EPC125-05 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-09/EPC125-05%202025%20SCT%20Rulebook%20version%201.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC135-18 v6.0 Guidance on Reason Codes for SCT R-transactions and EPC125-05 2025 v1.1 SCT Rulebook", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms AC01 (Account identifier incorrect) as a valid SCT R-transaction reason code against EPC135-18 v6.0 section 3 (ISO definition, rulebook reason, and R-transaction type list match the record). Confirms: reject sent before inter-PSP settlement, at the latest the next Banking Business Day (EPC125-05 section 4.3.2.1); return sent by the Beneficiary PSP within 3 Banking Business Days after the Settlement Date (EPC125-05 section 4.3.2.2, CT-01.04R). Does not address the triggers, actions, retry rule, or caveat text beyond the sections already cited in the record's basis." } ] }, "rail_name": "SEPA Credit Transfer", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sct:AC03", "id": "AC03", "rail": "sepa-sct", "kind": "reason-code", "name": "Wrong unique identifier of the Beneficiary account", "group": "account", "summary": "The Originator asks for its money back because it sent the transfer to the wrong IBAN. This is a request for recall by the originator, which the Beneficiary may refuse.", "triggers": [ "The Originator selected or typed the wrong Beneficiary IBAN when issuing the instruction" ], "actions": [ "Originator PSP to confirm the debit date is within 13 months and that the Originator gave this reason, then send the request", "Originator PSP to tell the Originator that the request does not guarantee the funds come back (section 4.3.2.4)", "If the answer is negative, the Beneficiary PSP may pass on what it can about the Beneficiary, within data protection law, so the Originator can bring a legal claim (AT-R078)", "Originator to change its payment process so a wrong IBAN is not picked again" ], "retry": { "allowed": false, "rule": "No. After the Beneficiary PSP has answered, the Originator PSP may not send another Recall or RFRO for the same transfer (EPC125-05 2025 v1.1 sections 4.3.2.3 and 4.3.2.4). Any further recovery happens outside the scheme." }, "facts": { "return_windows": [ { "action": "request for recall by the originator", "by": "Originator PSP, at the Originator's request", "deadline": "The debit date of the original transfer must fall within the 13 months before the Originator PSP received the request. Only one request per transfer" } ], "applies_to": "SCT" }, "caveat": "This is not a Recall: the three Recall reasons are duplicate, technical problem and fraud. The Beneficiary PSP must answer within 15 Banking Business Days of receipt, and the Beneficiary's decision closes the matter within the scheme (section 4.3.2.4, Step 4B). The answer uses FOCR if positive, or a refusal code such as CUST, AC04, AM04, LEGL, NOAS, NOOR or ARDT if negative.", "related": [ "sepa-sct:AM09", "sepa-sct:CUST", "sepa-sct:FOCR", "sepa-sct:NOAS", "sepa-sct:AC01" ], "basis": { "sources": "EPC135-18 v6.0 section 3, entry for AC03 (ISO name, rulebook reason, R-transaction types, use cases, root causes, suggested action); EPC125-05 2025 v1.1 section 4.3.2.4, Step 1 and 4.6.1 AT-R071, AT-R073 (RFRO: reasons other than the three Recall reasons; debit date within the 13 months before the Originator PSP received the request; one per transfer); EPC125-05 2025 v1.1 section 4.3.2.4, Steps 3, 4A, 4B and 4C and 4.5.8 DS-08, 4.6.1 AT-R074 to AT-R078 (response to an RFRO: Beneficiary PSP, within 15 Banking Business Days of receipt); EPC125-05 2025 v1.1 chapter 7 (a Banking Business Day is a T2 day).", "confidence": "high" }, "currency": { "effective_since": "2025-10-05", "effective_note": "EPC125-05 2025 v1.1 was issued and took effect on 2025-10-05; v1.1 changed only the date for the unstructured address phase-out, now 15 November 2026. EPC135-18 v6.0, published 2024-11-28, is taken to be the current SCT reason code guidance and to cover the 2025 rulebook [Unverified]. The next SCT rulebook is due for publication in November 2026 [Unverified].", "source_edition": "EPC135-18 v6.0; EPC125-05 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-09/EPC125-05%202025%20SCT%20Rulebook%20version%201.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC135-18 v6.0 Guidance on Reason Codes for SCT R-transactions and EPC125-05 2025 v1.1 SCT Rulebook", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms AC03 (Wrong unique identifier of the Beneficiary account) as a valid SCT R-transaction reason code against EPC135-18 v6.0 section 3 (ISO definition, rulebook reason, and R-transaction type list match the record). Confirms: RFRO sent by the Originator PSP, debit date within 13 months of the request (EPC125-05 section 4.3.2.4). Does not address the triggers, actions, retry rule, or caveat text beyond the sections already cited in the record's basis." } ] }, "rail_name": "SEPA Credit Transfer", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sct:AC04", "id": "AC04", "rail": "sepa-sct", "kind": "reason-code", "name": "Account closed", "group": "account", "summary": "The Beneficiary's account at the Beneficiary PSP is closed. Used to return a transfer, or to refuse a recall or a request for recall.", "triggers": [ "The Beneficiary closed the account after the Originator's last transfer to it", "A Recall or RFRO arrives for funds that went to an account now closed" ], "actions": [ "Originator to contact the Beneficiary for the new account", "On a refused Recall or RFRO: Originator (and the Originator PSP where the Recall was for its own error) to contact the Beneficiary directly and seek the funds outside the scheme's Recall and RFRO procedures", "Where Beneficiary PSPs send MS03, remember it may stand for a closed account [Inference]" ], "retry": { "allowed": false, "rule": "Do not send to the closed account again. Send a new transfer only to the new account the Beneficiary gives. After a negative answer to a Recall or RFRO, no second request is allowed (EPC125-05 2025 v1.1 sections 4.3.2.3 and 4.3.2.4)." }, "facts": { "return_windows": [ { "action": "return", "by": "Beneficiary PSP", "deadline": "After inter-PSP settlement. The Return message and the funds go to the Originator PSP through the CSM no later than 3 Banking Business Days after the Settlement Date" }, { "action": "negative answer to a recall", "by": "Beneficiary PSP", "deadline": "Within 15 Banking Business Days after receiving the Recall" }, { "action": "negative answer to a request for recall by the originator", "by": "Beneficiary PSP", "deadline": "Within 15 Banking Business Days after receiving the request" } ], "applies_to": "SCT" }, "caveat": "Data protection law in certain SEPA countries bars this code, and MS03 may be used instead (EPC135-18 v6.0 section 3). The guidance does not name the countries.", "related": [ "sepa-sct:AC01", "sepa-sct:AC06", "sepa-sct:MS03", "sepa-sct:AM04" ], "basis": { "sources": "EPC135-18 v6.0 section 3, entry for AC04 (ISO name, rulebook reason, R-transaction types, use cases, root causes, suggested action); EPC125-05 2025 v1.1 sections 4.3.2.2, CT-01.04R and 4.6.1 AT-R004, AT-R005 (return: Beneficiary PSP, after settlement, message and funds within 3 Banking Business Days after the Settlement Date); EPC125-05 2025 v1.1 section 4.3.2.3, CT-02.03, CT-02.03R, CT-02-04 and 4.5.6 DS-06, 4.6.1 AT-R054 to AT-R057 (response to a Recall: Beneficiary PSP, within 15 Banking Business Days of receipt); EPC125-05 2025 v1.1 section 4.3.2.4, Steps 3, 4A, 4B and 4C and 4.5.8 DS-08, 4.6.1 AT-R074 to AT-R078 (response to an RFRO: Beneficiary PSP, within 15 Banking Business Days of receipt); EPC125-05 2025 v1.1 chapter 7 (a Banking Business Day is a T2 day).", "confidence": "high" }, "currency": { "effective_since": "2025-10-05", "effective_note": "EPC125-05 2025 v1.1 was issued and took effect on 2025-10-05; v1.1 changed only the date for the unstructured address phase-out, now 15 November 2026. EPC135-18 v6.0, published 2024-11-28, is taken to be the current SCT reason code guidance and to cover the 2025 rulebook [Unverified]. The next SCT rulebook is due for publication in November 2026 [Unverified].", "source_edition": "EPC135-18 v6.0; EPC125-05 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-09/EPC125-05%202025%20SCT%20Rulebook%20version%201.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC135-18 v6.0 Guidance on Reason Codes for SCT R-transactions and EPC125-05 2025 v1.1 SCT Rulebook", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms AC04 (Account closed) as a valid SCT R-transaction reason code against EPC135-18 v6.0 section 3 (ISO definition, rulebook reason, and R-transaction type list match the record). Confirms: return sent by the Beneficiary PSP within 3 Banking Business Days after the Settlement Date (EPC125-05 section 4.3.2.2, CT-01.04R); Beneficiary PSP's answer to a Recall within 15 Banking Business Days of receipt (EPC125-05 section 4.3.2.3); Beneficiary PSP's answer to an RFRO within 15 Banking Business Days of receipt (EPC125-05 section 4.3.2.4). Does not address the triggers, actions, retry rule, or caveat text beyond the sections already cited in the record's basis." } ] }, "rail_name": "SEPA Credit Transfer", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "jurisdiction", "label": "the country", "needs": "which country the payment or the account is in", "detail": "Data protection law in certain SEPA countries bars this code, and MS03 may be used instead (EPC135-18 v6.0 section 3).", "from": "caveat" } ] }, { "uid": "sepa-sct:AC06", "id": "AC06", "rail": "sepa-sct", "kind": "reason-code", "name": "Account blocked", "group": "account", "summary": "The Beneficiary's account is blocked for all financial transactions, so the Beneficiary PSP returns the transfer.", "triggers": [ "A court order blocked the account", "The Beneficiary PSP blocked the account, for example on suspected misuse or at the Beneficiary's request" ], "actions": [ "Originator to contact the Beneficiary for another account or another way to pay" ], "retry": { "allowed": false, "rule": "Do not send to the blocked account again until the Beneficiary confirms it can receive funds [Inference]. Use another account or payment method." }, "facts": { "return_windows": [ { "action": "return", "by": "Beneficiary PSP", "deadline": "After inter-PSP settlement. The Return message and the funds go to the Originator PSP through the CSM no later than 3 Banking Business Days after the Settlement Date" } ], "applies_to": "SCT" }, "caveat": "The guidance lists AC06 for returns only, not for rejects.", "related": [ "sepa-sct:AC04", "sepa-sct:AG01", "sepa-sct:MS02" ], "basis": { "sources": "EPC135-18 v6.0 section 3, entry for AC06 (ISO name, rulebook reason, R-transaction types, use cases, root causes, suggested action); EPC125-05 2025 v1.1 sections 4.3.2.2, CT-01.04R and 4.6.1 AT-R004, AT-R005 (return: Beneficiary PSP, after settlement, message and funds within 3 Banking Business Days after the Settlement Date); EPC125-05 2025 v1.1 chapter 7 (a Banking Business Day is a T2 day).", "confidence": "high" }, "currency": { "effective_since": "2025-10-05", "effective_note": "EPC125-05 2025 v1.1 was issued and took effect on 2025-10-05; v1.1 changed only the date for the unstructured address phase-out, now 15 November 2026. EPC135-18 v6.0, published 2024-11-28, is taken to be the current SCT reason code guidance and to cover the 2025 rulebook [Unverified]. The next SCT rulebook is due for publication in November 2026 [Unverified].", "source_edition": "EPC135-18 v6.0; EPC125-05 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-09/EPC125-05%202025%20SCT%20Rulebook%20version%201.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC135-18 v6.0 Guidance on Reason Codes for SCT R-transactions and EPC125-05 2025 v1.1 SCT Rulebook", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms AC06 (Account blocked) as a valid SCT R-transaction reason code against EPC135-18 v6.0 section 3 (ISO definition, rulebook reason, and R-transaction type list match the record). Confirms: return sent by the Beneficiary PSP within 3 Banking Business Days after the Settlement Date (EPC125-05 section 4.3.2.2, CT-01.04R). Does not address the triggers, actions, retry rule, or caveat text beyond the sections already cited in the record's basis." } ] }, "rail_name": "SEPA Credit Transfer", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sct:ACNR", "id": "ACNR", "rail": "sepa-sct", "kind": "reason-code", "name": "Accepted claim of non-receipt", "group": "administrative", "summary": "Positive answer to a claim of non-receipt: the Beneficiary PSP confirms it credited the transfer to the Beneficiary's IBAN and gives the credit date.", "triggers": [ "The Originator reported that the Beneficiary says it was not paid, and the Beneficiary PSP finds it did credit the account" ], "actions": [ "Originator PSP to tell the Originator the transfer was executed as instructed, with the credit date", "Originator PSP to pay any inquiry fee the Beneficiary PSP asked for; for a claim of non-receipt only a fee, not interest, may be claimed (AT-Q009), preferably through DS-11 (section 4.4.4)" ], "retry": { "allowed": false, "rule": "Nothing to resend: the funds were credited. A Request for Status Update is only for an inquiry that got no answer, and the Beneficiary PSP need not answer it once it has responded (EPC125-05 2025 v1.1 sections 4.4.1 and 4.4.2)." }, "facts": { "return_windows": [ { "action": "positive answer to an inquiry (claim of non-receipt)", "by": "Beneficiary PSP", "deadline": "Within 10 Banking Business Days after receiving the inquiry" } ], "applies_to": "SCT" }, "caveat": "An SCT inquiry is an information request between PSPs, not an R-transaction that moves the original funds. The Beneficiary PSP may charge a fee only on a positive answer (section 4.4.2).", "related": [ "sepa-sct:RJNR", "sepa-sct:NOOR" ], "basis": { "sources": "EPC135-18 v6.0 section 3, entry for ACNR (ISO name, rulebook reason, R-transaction types, use cases, root causes, suggested action); EPC125-05 2025 v1.1 sections 4.4.1 and 4.4.2 and 4.5.10 DS-10 (SCT inquiry: debit date within 13 months before the Originator submits it; Beneficiary PSP answers within 10 Banking Business Days); EPC125-05 2025 v1.1 sections 4.4.4, 4.5.11 DS-11 and 4.6.1 AT-Q007, AT-Q009 (inquiry fee); EPC125-05 2025 v1.1 chapter 7 (a Banking Business Day is a T2 day).", "confidence": "high" }, "currency": { "effective_since": "2025-10-05", "effective_note": "EPC125-05 2025 v1.1 was issued and took effect on 2025-10-05; v1.1 changed only the date for the unstructured address phase-out, now 15 November 2026. EPC135-18 v6.0, published 2024-11-28, is taken to be the current SCT reason code guidance and to cover the 2025 rulebook [Unverified]. The next SCT rulebook is due for publication in November 2026 [Unverified].", "source_edition": "EPC135-18 v6.0; EPC125-05 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-09/EPC125-05%202025%20SCT%20Rulebook%20version%201.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC135-18 v6.0 Guidance on Reason Codes for SCT R-transactions and EPC125-05 2025 v1.1 SCT Rulebook", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms ACNR (Accepted claim of non-receipt) as a valid SCT R-transaction reason code against EPC135-18 v6.0 section 3 (ISO definition, rulebook reason, and R-transaction type list match the record). Confirms: Beneficiary PSP's answer to an SCT inquiry (claim of non-receipt) within 10 Banking Business Days of receipt (EPC125-05 section 4.4.2). Does not address the triggers, actions, retry rule, or caveat text beyond the sections already cited in the record's basis." } ] }, "rail_name": "SEPA Credit Transfer", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sct:ACVA", "id": "ACVA", "rail": "sepa-sct", "kind": "reason-code", "name": "Accepted value date adjustment", "group": "administrative", "summary": "Positive answer to a claim for value date correction: the Beneficiary PSP agrees to correct the value date but wants interest compensation from the Originator PSP first.", "triggers": [ "The Beneficiary PSP agrees the value date was wrong and the cause did not lie with it" ], "actions": [ "Originator PSP to pay the interest compensation (and any fee) first, preferably through DS-11 (section 4.4.4)", "Then expect a confirmed positive answer, MODI, once the Beneficiary PSP has corrected the value date" ], "retry": { "allowed": false, "rule": "Not applicable: this is an answer to an inquiry. The Beneficiary PSP reports the total compensation and fee only once (section 4.4.2)." }, "facts": { "return_windows": [ { "action": "positive answer to an inquiry (claim for value date correction)", "by": "Beneficiary PSP", "deadline": "Within 10 Banking Business Days after receiving the inquiry" } ], "applies_to": "SCT" }, "caveat": "Interest compensation runs for the calendar days between the original and corrected value dates, at the €STR rate of the first Banking Business Day of each month on a 360-day year, and may be claimed only when that rate is positive (section 4.4.2). A Beneficiary PSP may still ask for just a fee when the rate is negative.", "related": [ "sepa-sct:MODI", "sepa-sct:CVAA", "sepa-sct:RJVA" ], "basis": { "sources": "EPC135-18 v6.0 section 3, entry for ACVA (ISO name, rulebook reason, R-transaction types, use cases, root causes, suggested action); EPC125-05 2025 v1.1 sections 4.4.1 and 4.4.2 and 4.5.10 DS-10 (SCT inquiry: debit date within 13 months before the Originator submits it; Beneficiary PSP answers within 10 Banking Business Days); EPC125-05 2025 v1.1 sections 4.4.2 and 4.4.4, 4.5.10 DS-10, 4.5.11 DS-11 and 4.6.1 AT-Q005 to AT-Q007 (value date correction: interest compensation at the €STR rate, fee, payment via DS-11); EPC125-05 2025 v1.1 chapter 7 (a Banking Business Day is a T2 day).", "confidence": "high" }, "currency": { "effective_since": "2025-10-05", "effective_note": "EPC125-05 2025 v1.1 was issued and took effect on 2025-10-05; v1.1 changed only the date for the unstructured address phase-out, now 15 November 2026. EPC135-18 v6.0, published 2024-11-28, is taken to be the current SCT reason code guidance and to cover the 2025 rulebook [Unverified]. The next SCT rulebook is due for publication in November 2026 [Unverified].", "source_edition": "EPC135-18 v6.0; EPC125-05 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-09/EPC125-05%202025%20SCT%20Rulebook%20version%201.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC135-18 v6.0 Guidance on Reason Codes for SCT R-transactions and EPC125-05 2025 v1.1 SCT Rulebook", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms ACVA (Accepted value date adjustment) as a valid SCT R-transaction reason code against EPC135-18 v6.0 section 3 (ISO definition, rulebook reason, and R-transaction type list match the record). Confirms: Beneficiary PSP's answer to an SCT inquiry (claim for value date correction) within 10 Banking Business Days of receipt (EPC125-05 section 4.4.2). Does not address the triggers, actions, retry rule, or caveat text beyond the sections already cited in the record's basis." } ] }, "rail_name": "SEPA Credit Transfer", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sct:AG01", "id": "AG01", "rail": "sepa-sct", "kind": "reason-code", "name": "Transfer forbidden on this type of account", "group": "account", "summary": "The Beneficiary's account cannot take SCT credits, for example a savings account, so the Beneficiary PSP returns the transfer.", "triggers": [ "The Beneficiary gave details of an account on which SCT transactions cannot be booked" ], "actions": [ "Originator to contact the Beneficiary and agree another account or payment instrument" ], "retry": { "allowed": false, "rule": "Do not send to the same account again. Send a new transfer only to an account that accepts SCT credits [Inference]." }, "facts": { "return_windows": [ { "action": "return", "by": "Beneficiary PSP", "deadline": "After inter-PSP settlement. The Return message and the funds go to the Originator PSP through the CSM no later than 3 Banking Business Days after the Settlement Date" } ], "applies_to": "SCT" }, "caveat": "The guidance lists AG01 for returns only.", "related": [ "sepa-sct:AC06", "sepa-sct:MS02" ], "basis": { "sources": "EPC135-18 v6.0 section 3, entry for AG01 (ISO name, rulebook reason, R-transaction types, use cases, root causes, suggested action); EPC125-05 2025 v1.1 sections 4.3.2.2, CT-01.04R and 4.6.1 AT-R004, AT-R005 (return: Beneficiary PSP, after settlement, message and funds within 3 Banking Business Days after the Settlement Date); EPC125-05 2025 v1.1 chapter 7 (a Banking Business Day is a T2 day).", "confidence": "high" }, "currency": { "effective_since": "2025-10-05", "effective_note": "EPC125-05 2025 v1.1 was issued and took effect on 2025-10-05; v1.1 changed only the date for the unstructured address phase-out, now 15 November 2026. EPC135-18 v6.0, published 2024-11-28, is taken to be the current SCT reason code guidance and to cover the 2025 rulebook [Unverified]. The next SCT rulebook is due for publication in November 2026 [Unverified].", "source_edition": "EPC135-18 v6.0; EPC125-05 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-09/EPC125-05%202025%20SCT%20Rulebook%20version%201.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC135-18 v6.0 Guidance on Reason Codes for SCT R-transactions and EPC125-05 2025 v1.1 SCT Rulebook", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms AG01 (Transfer forbidden on this type of account) as a valid SCT R-transaction reason code against EPC135-18 v6.0 section 3 (ISO definition, rulebook reason, and R-transaction type list match the record). Confirms: return sent by the Beneficiary PSP within 3 Banking Business Days after the Settlement Date (EPC125-05 section 4.3.2.2, CT-01.04R). Does not address the triggers, actions, retry rule, or caveat text beyond the sections already cited in the record's basis." } ] }, "rail_name": "SEPA Credit Transfer", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sct:AG02", "id": "AG02", "rail": "sepa-sct", "kind": "reason-code", "name": "Operation or transaction code incorrect", "group": "technical", "summary": "The scheme identification in the message (service level or local instrument) is wrong.", "triggers": [ "A technical or processing error at the Originator or in its file of SCT instructions put a wrong service level or local instrument in the message" ], "actions": [ "Originator to correct the wrong information and send again", "For XML file problems such as syntax errors, use FF01, not AG02" ], "retry": { "allowed": true, "rule": "Send again once the scheme identification is corrected. A new transfer is a new Credit Transfer Instruction. A rejected instruction that the Originator PSP repairs and resends is also treated as a new instruction (EPC125-05 2025 v1.1 section 4.3.2.2, CT-01.03R)." }, "facts": { "return_windows": [ { "action": "reject", "by": "Originator PSP or CSM", "deadline": "Before inter-PSP settlement. Sent the same day where possible and no later than the next Banking Business Day (a T2 day); the CSM passes a reject to the Originator PSP no later than the next Banking Business Day after rejecting" }, { "action": "return", "by": "Beneficiary PSP", "deadline": "After inter-PSP settlement. The Return message and the funds go to the Originator PSP through the CSM no later than 3 Banking Business Days after the Settlement Date" } ], "applies_to": "SCT" }, "caveat": "The rulebook gives one reason, operation or transaction code incorrect or invalid file format, that the guidance splits between AG02 (scheme identification) and FF01 (XML file problems).", "related": [ "sepa-sct:FF01", "sepa-sct:RC01" ], "basis": { "sources": "EPC135-18 v6.0 section 3, entry for AG02 (ISO name, rulebook reason, R-transaction types, use cases, root causes, suggested action); EPC125-05 2025 v1.1 sections 4.3.2.1, 4.3.2.2 CT-01.03R and 4.6.1 AT-R002, AT-R004 (reject: before inter-PSP settlement, by the Originator PSP or the CSM, same day and at the latest the next Banking Business Day); EPC125-05 2025 v1.1 sections 4.3.2.2, CT-01.04R and 4.6.1 AT-R004, AT-R005 (return: Beneficiary PSP, after settlement, message and funds within 3 Banking Business Days after the Settlement Date); EPC125-05 2025 v1.1 chapter 7 (a Banking Business Day is a T2 day).", "confidence": "high" }, "currency": { "effective_since": "2025-10-05", "effective_note": "EPC125-05 2025 v1.1 was issued and took effect on 2025-10-05; v1.1 changed only the date for the unstructured address phase-out, now 15 November 2026. EPC135-18 v6.0, published 2024-11-28, is taken to be the current SCT reason code guidance and to cover the 2025 rulebook [Unverified]. The next SCT rulebook is due for publication in November 2026 [Unverified].", "source_edition": "EPC135-18 v6.0; EPC125-05 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-09/EPC125-05%202025%20SCT%20Rulebook%20version%201.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC135-18 v6.0 Guidance on Reason Codes for SCT R-transactions and EPC125-05 2025 v1.1 SCT Rulebook", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms AG02 (Operation or transaction code incorrect) as a valid SCT R-transaction reason code against EPC135-18 v6.0 section 3 (ISO definition, rulebook reason, and R-transaction type list match the record). Confirms: reject sent before inter-PSP settlement, at the latest the next Banking Business Day (EPC125-05 section 4.3.2.1); return sent by the Beneficiary PSP within 3 Banking Business Days after the Settlement Date (EPC125-05 section 4.3.2.2, CT-01.04R). Does not address the triggers, actions, retry rule, or caveat text beyond the sections already cited in the record's basis." } ] }, "rail_name": "SEPA Credit Transfer", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sct:AM04", "id": "AM04", "rail": "sepa-sct", "kind": "reason-code", "name": "Insufficient funds", "group": "funds", "summary": "Negative answer to a recall or a request for recall: the Beneficiary's account does not hold enough to pay back the full amount. In SCT this code is never a reason to reject or return the original transfer.", "triggers": [ "The Beneficiary's balance is below the amount of the Recall or RFRO" ], "actions": [ "Originator (and the Originator PSP where the Recall was for its own error) to contact the Beneficiary directly and seek the funds outside the scheme's Recall and RFRO procedures", "Where Beneficiary PSPs send CUST, remember it may stand for insufficient funds [Inference]" ], "retry": { "allowed": false, "rule": "No. After the Beneficiary PSP has answered, the Originator PSP may not send another Recall or RFRO for the same transfer (EPC125-05 2025 v1.1 sections 4.3.2.3 and 4.3.2.4). Any further recovery happens outside the scheme." }, "facts": { "return_windows": [ { "action": "negative answer to a recall", "by": "Beneficiary PSP", "deadline": "Within 15 Banking Business Days after receiving the Recall" }, { "action": "negative answer to a request for recall by the originator", "by": "Beneficiary PSP", "deadline": "Within 15 Banking Business Days after receiving the request" } ], "applies_to": "SCT" }, "caveat": "Data protection law in certain SEPA countries bars this code, and CUST may be used instead (EPC135-18 v6.0 section 3). The guidance does not name the countries. The rulebook lists insufficient funds among the permitted negative answers (CT-02.03R, AT-R057, AT-R077).", "related": [ "sepa-sct:CUST", "sepa-sct:AC04", "sepa-sct:NOAS", "sepa-sct:LEGL" ], "basis": { "sources": "EPC135-18 v6.0 section 3, entry for AM04 (ISO name, rulebook reason, R-transaction types, use cases, root causes, suggested action); EPC125-05 2025 v1.1 section 4.3.2.3, CT-02.03, CT-02.03R, CT-02-04 and 4.5.6 DS-06, 4.6.1 AT-R054 to AT-R057 (response to a Recall: Beneficiary PSP, within 15 Banking Business Days of receipt); EPC125-05 2025 v1.1 section 4.3.2.4, Steps 3, 4A, 4B and 4C and 4.5.8 DS-08, 4.6.1 AT-R074 to AT-R078 (response to an RFRO: Beneficiary PSP, within 15 Banking Business Days of receipt); EPC125-05 2025 v1.1 chapter 7 (a Banking Business Day is a T2 day).", "confidence": "high" }, "currency": { "effective_since": "2025-10-05", "effective_note": "EPC125-05 2025 v1.1 was issued and took effect on 2025-10-05; v1.1 changed only the date for the unstructured address phase-out, now 15 November 2026. EPC135-18 v6.0, published 2024-11-28, is taken to be the current SCT reason code guidance and to cover the 2025 rulebook [Unverified]. The next SCT rulebook is due for publication in November 2026 [Unverified].", "source_edition": "EPC135-18 v6.0; EPC125-05 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-09/EPC125-05%202025%20SCT%20Rulebook%20version%201.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC135-18 v6.0 Guidance on Reason Codes for SCT R-transactions and EPC125-05 2025 v1.1 SCT Rulebook", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms AM04 (Insufficient funds) as a valid SCT R-transaction reason code against EPC135-18 v6.0 section 3 (ISO definition, rulebook reason, and R-transaction type list match the record). Confirms: Beneficiary PSP's answer to a Recall within 15 Banking Business Days of receipt (EPC125-05 section 4.3.2.3); Beneficiary PSP's answer to an RFRO within 15 Banking Business Days of receipt (EPC125-05 section 4.3.2.4). Does not address the triggers, actions, retry rule, or caveat text beyond the sections already cited in the record's basis." } ] }, "rail_name": "SEPA Credit Transfer", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "jurisdiction", "label": "the country", "needs": "which country the payment or the account is in", "detail": "Data protection law in certain SEPA countries bars this code, and CUST may be used instead (EPC135-18 v6.0 section 3).", "from": "caveat" } ] }, { "uid": "sepa-sct:AM05", "id": "AM05", "rail": "sepa-sct", "kind": "reason-code", "name": "Duplicate payment", "group": "administrative", "summary": "The CSM or the Beneficiary PSP considers the transfer a copy of one sent or processed very recently.", "triggers": [ "A technical or human error at the Originator or the Originator PSP sent the same transfer twice" ], "actions": [ "Originator or Originator PSP to check whether the transfer really was a duplicate", "If it was not, send it again as a new transfer, with references that show it is distinct [Inference]" ], "retry": { "allowed": true, "rule": "Only if the check shows the transfer was not a duplicate. A new transfer is a new Credit Transfer Instruction. A rejected instruction that the Originator PSP repairs and resends is also treated as a new instruction (EPC125-05 2025 v1.1 section 4.3.2.2, CT-01.03R)." }, "facts": { "return_windows": [ { "action": "reject", "by": "Originator PSP or CSM", "deadline": "Before inter-PSP settlement. Sent the same day where possible and no later than the next Banking Business Day (a T2 day); the CSM passes a reject to the Originator PSP no later than the next Banking Business Day after rejecting" }, { "action": "return", "by": "Beneficiary PSP", "deadline": "After inter-PSP settlement. The Return message and the funds go to the Originator PSP through the CSM no later than 3 Banking Business Days after the Settlement Date" } ], "applies_to": "SCT" }, "caveat": "AM05 is the receiving side's reason on a reject or return. When the Originator side finds its own duplicate after sending, the Recall reason is DUPL. The guidance names the CSM or the Beneficiary PSP as the party that spots the duplicate, while the rulebook frames rejects as coming from the Originator PSP or the CSM. The texts read define no test for what counts as a duplicate.", "related": [ "sepa-sct:DUPL", "sepa-sct:TECH" ], "basis": { "sources": "EPC135-18 v6.0 section 3, entry for AM05 (ISO name, rulebook reason, R-transaction types, use cases, root causes, suggested action); EPC125-05 2025 v1.1 sections 4.3.2.1, 4.3.2.2 CT-01.03R and 4.6.1 AT-R002, AT-R004 (reject: before inter-PSP settlement, by the Originator PSP or the CSM, same day and at the latest the next Banking Business Day); EPC125-05 2025 v1.1 sections 4.3.2.2, CT-01.04R and 4.6.1 AT-R004, AT-R005 (return: Beneficiary PSP, after settlement, message and funds within 3 Banking Business Days after the Settlement Date); EPC125-05 2025 v1.1 chapter 7 (a Banking Business Day is a T2 day).", "confidence": "high" }, "currency": { "effective_since": "2025-10-05", "effective_note": "EPC125-05 2025 v1.1 was issued and took effect on 2025-10-05; v1.1 changed only the date for the unstructured address phase-out, now 15 November 2026. EPC135-18 v6.0, published 2024-11-28, is taken to be the current SCT reason code guidance and to cover the 2025 rulebook [Unverified]. The next SCT rulebook is due for publication in November 2026 [Unverified].", "source_edition": "EPC135-18 v6.0; EPC125-05 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-09/EPC125-05%202025%20SCT%20Rulebook%20version%201.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC135-18 v6.0 Guidance on Reason Codes for SCT R-transactions and EPC125-05 2025 v1.1 SCT Rulebook", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms AM05 (Duplicate payment) as a valid SCT R-transaction reason code against EPC135-18 v6.0 section 3 (ISO definition, rulebook reason, and R-transaction type list match the record). Confirms: reject sent before inter-PSP settlement, at the latest the next Banking Business Day (EPC125-05 section 4.3.2.1); return sent by the Beneficiary PSP within 3 Banking Business Days after the Settlement Date (EPC125-05 section 4.3.2.2, CT-01.04R). Does not address the triggers, actions, retry rule, or caveat text beyond the sections already cited in the record's basis." } ] }, "rail_name": "SEPA Credit Transfer", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sct:AM09", "id": "AM09", "rail": "sepa-sct", "kind": "reason-code", "name": "Wrong amount", "group": "administrative", "summary": "The Originator asks for money back because it sent more than it meant to. This is a request for recall by the originator, which the Beneficiary may refuse.", "triggers": [ "A technical or human error at the Originator produced a higher amount than intended" ], "actions": [ "Originator PSP to confirm the debit date is within 13 months, then send the request with the reason", "Originator PSP to tell the Originator that the request does not guarantee the funds come back (section 4.3.2.4)", "Originator to fix its process so wrong amounts are not sent again" ], "retry": { "allowed": false, "rule": "No. After the Beneficiary PSP has answered, the Originator PSP may not send another Recall or RFRO for the same transfer (EPC125-05 2025 v1.1 sections 4.3.2.3 and 4.3.2.4). Any further recovery happens outside the scheme." }, "facts": { "return_windows": [ { "action": "request for recall by the originator", "by": "Originator PSP, at the Originator's request", "deadline": "The debit date of the original transfer must fall within the 13 months before the Originator PSP received the request. Only one request per transfer" } ], "applies_to": "SCT" }, "caveat": "The Beneficiary PSP must answer within 15 Banking Business Days, and the Beneficiary's decision closes the matter within the scheme (section 4.3.2.4, Step 4B). The rulebook sets the returned amount in the positive answer (AT-R074) but the texts read do not say whether only the excess is sought [Unverified]. The Beneficiary PSP may take a fee from a positive answer (AT-R075).", "related": [ "sepa-sct:AC03", "sepa-sct:CUST", "sepa-sct:FOCR", "sepa-sct:NOAS" ], "basis": { "sources": "EPC135-18 v6.0 section 3, entry for AM09 (ISO name, rulebook reason, R-transaction types, use cases, root causes, suggested action); EPC125-05 2025 v1.1 section 4.3.2.4, Step 1 and 4.6.1 AT-R071, AT-R073 (RFRO: reasons other than the three Recall reasons; debit date within the 13 months before the Originator PSP received the request; one per transfer); EPC125-05 2025 v1.1 section 4.3.2.4, Steps 3, 4A, 4B and 4C and 4.5.8 DS-08, 4.6.1 AT-R074 to AT-R078 (response to an RFRO: Beneficiary PSP, within 15 Banking Business Days of receipt); EPC125-05 2025 v1.1 chapter 7 (a Banking Business Day is a T2 day).", "confidence": "high" }, "currency": { "effective_since": "2025-10-05", "effective_note": "EPC125-05 2025 v1.1 was issued and took effect on 2025-10-05; v1.1 changed only the date for the unstructured address phase-out, now 15 November 2026. EPC135-18 v6.0, published 2024-11-28, is taken to be the current SCT reason code guidance and to cover the 2025 rulebook [Unverified]. The next SCT rulebook is due for publication in November 2026 [Unverified].", "source_edition": "EPC135-18 v6.0; EPC125-05 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-09/EPC125-05%202025%20SCT%20Rulebook%20version%201.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC135-18 v6.0 Guidance on Reason Codes for SCT R-transactions and EPC125-05 2025 v1.1 SCT Rulebook", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms AM09 (Wrong amount) as a valid SCT R-transaction reason code against EPC135-18 v6.0 section 3 (ISO definition, rulebook reason, and R-transaction type list match the record). Confirms: RFRO sent by the Originator PSP, debit date within 13 months of the request (EPC125-05 section 4.3.2.4). Does not address the triggers, actions, retry rule, or caveat text beyond the sections already cited in the record's basis." } ] }, "rail_name": "SEPA Credit Transfer", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sct:ARDT", "id": "ARDT", "rail": "sepa-sct", "kind": "reason-code", "name": "Already returned transaction", "group": "administrative", "summary": "The funds have already gone back. As an answer to a recall or request for recall, the Beneficiary already sent them back. As an answer to a claim of non-receipt, the Beneficiary PSP had returned the transfer.", "triggers": [ "The Beneficiary already paid the funds back to the Originator by SCT, SCT Inst or another means (Recall or RFRO)", "The Beneficiary PSP could not process the transfer and returned it (claim of non-receipt)" ], "actions": [ "On a Recall or RFRO: no action; check the Originator's account for the earlier repayment", "On a claim of non-receipt: look up the original return reason code and follow the action for that code" ], "retry": { "allowed": false, "rule": "No. After the Beneficiary PSP has answered, the Originator PSP may not send another Recall or RFRO for the same transfer (EPC125-05 2025 v1.1 sections 4.3.2.3 and 4.3.2.4). Any further recovery happens outside the scheme." }, "facts": { "return_windows": [ { "action": "negative answer to a recall", "by": "Beneficiary PSP", "deadline": "Within 15 Banking Business Days after receiving the Recall" }, { "action": "negative answer to a request for recall by the originator", "by": "Beneficiary PSP", "deadline": "Within 15 Banking Business Days after receiving the request" }, { "action": "negative answer to an inquiry (claim of non-receipt)", "by": "Beneficiary PSP", "deadline": "Within 10 Banking Business Days after receiving the inquiry" } ], "applies_to": "SCT" }, "caveat": "On a claim of non-receipt, ARDT sits inside a negative answer that carries RJNR (Rejected claim of non-receipt). The rulebook covers this answer through AT-Q004, which includes the case where a reject or return was already sent.", "related": [ "sepa-sct:ARJT", "sepa-sct:RJNR", "sepa-sct:FOCR", "sepa-sct:NOOR" ], "basis": { "sources": "EPC135-18 v6.0 section 3, entry for ARDT (ISO name, rulebook reason, R-transaction types, use cases, root causes, suggested action); EPC125-05 2025 v1.1 section 4.3.2.3, CT-02.03, CT-02.03R, CT-02-04 and 4.5.6 DS-06, 4.6.1 AT-R054 to AT-R057 (response to a Recall: Beneficiary PSP, within 15 Banking Business Days of receipt); EPC125-05 2025 v1.1 section 4.3.2.4, Steps 3, 4A, 4B and 4C and 4.5.8 DS-08, 4.6.1 AT-R074 to AT-R078 (response to an RFRO: Beneficiary PSP, within 15 Banking Business Days of receipt); EPC125-05 2025 v1.1 sections 4.4.1 and 4.4.2 and 4.5.10 DS-10 (SCT inquiry: debit date within 13 months before the Originator submits it; Beneficiary PSP answers within 10 Banking Business Days); EPC125-05 2025 v1.1 section 4.6.1 AT-Q004; EPC125-05 2025 v1.1 chapter 7 (a Banking Business Day is a T2 day).", "confidence": "high" }, "currency": { "effective_since": "2025-10-05", "effective_note": "EPC125-05 2025 v1.1 was issued and took effect on 2025-10-05; v1.1 changed only the date for the unstructured address phase-out, now 15 November 2026. EPC135-18 v6.0, published 2024-11-28, is taken to be the current SCT reason code guidance and to cover the 2025 rulebook [Unverified]. The next SCT rulebook is due for publication in November 2026 [Unverified].", "source_edition": "EPC135-18 v6.0; EPC125-05 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-09/EPC125-05%202025%20SCT%20Rulebook%20version%201.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC135-18 v6.0 Guidance on Reason Codes for SCT R-transactions and EPC125-05 2025 v1.1 SCT Rulebook", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms ARDT (Already returned transaction) as a valid SCT R-transaction reason code against EPC135-18 v6.0 section 3 (ISO definition, rulebook reason, and R-transaction type list match the record). Confirms: Beneficiary PSP's answer to a Recall within 15 Banking Business Days of receipt (EPC125-05 section 4.3.2.3); Beneficiary PSP's answer to an RFRO within 15 Banking Business Days of receipt (EPC125-05 section 4.3.2.4); Beneficiary PSP's answer to an SCT inquiry (claim of non-receipt) within 10 Banking Business Days of receipt (EPC125-05 section 4.4.2). Does not address the triggers, actions, retry rule, or caveat text beyond the sections already cited in the record's basis." } ] }, "rail_name": "SEPA Credit Transfer", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sct:ARJT", "id": "ARJT", "rail": "sepa-sct", "kind": "reason-code", "name": "Already rejected transaction", "group": "administrative", "summary": "Negative answer to a claim of non-receipt: the transfer was rejected earlier and never credited.", "triggers": [ "The Beneficiary PSP could not process the original transfer and it was rejected" ], "actions": [ "Look up the original reject reason code and follow the action for that code" ], "retry": { "allowed": false, "rule": "Not applicable to the inquiry. The underlying payment can be sent again as a new transfer once the reject reason is fixed [Inference]." }, "facts": { "return_windows": [ { "action": "negative answer to an inquiry (claim of non-receipt)", "by": "Beneficiary PSP", "deadline": "Within 10 Banking Business Days after receiving the inquiry" } ], "applies_to": "SCT" }, "caveat": "ARJT sits inside a negative answer that carries RJNR. The guidance lists ARJT for inquiry answers only, not for Recall or RFRO answers.", "related": [ "sepa-sct:ARDT", "sepa-sct:RJNR", "sepa-sct:RNPR", "sepa-sct:NOOR" ], "basis": { "sources": "EPC135-18 v6.0 section 3, entry for ARJT (ISO name, rulebook reason, R-transaction types, use cases, root causes, suggested action); EPC125-05 2025 v1.1 sections 4.4.1 and 4.4.2 and 4.5.10 DS-10 (SCT inquiry: debit date within 13 months before the Originator submits it; Beneficiary PSP answers within 10 Banking Business Days); EPC125-05 2025 v1.1 section 4.6.1 AT-Q004; EPC125-05 2025 v1.1 chapter 7 (a Banking Business Day is a T2 day).", "confidence": "high" }, "currency": { "effective_since": "2025-10-05", "effective_note": "EPC125-05 2025 v1.1 was issued and took effect on 2025-10-05; v1.1 changed only the date for the unstructured address phase-out, now 15 November 2026. EPC135-18 v6.0, published 2024-11-28, is taken to be the current SCT reason code guidance and to cover the 2025 rulebook [Unverified]. The next SCT rulebook is due for publication in November 2026 [Unverified].", "source_edition": "EPC135-18 v6.0; EPC125-05 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-09/EPC125-05%202025%20SCT%20Rulebook%20version%201.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC135-18 v6.0 Guidance on Reason Codes for SCT R-transactions and EPC125-05 2025 v1.1 SCT Rulebook", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms ARJT (Already rejected transaction) as a valid SCT R-transaction reason code against EPC135-18 v6.0 section 3 (ISO definition, rulebook reason, and R-transaction type list match the record). Confirms: Beneficiary PSP's answer to an SCT inquiry (claim of non-receipt) within 10 Banking Business Days of receipt (EPC125-05 section 4.4.2). Does not address the triggers, actions, retry rule, or caveat text beyond the sections already cited in the record's basis." } ] }, "rail_name": "SEPA Credit Transfer", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sct:BE04", "id": "BE04", "rail": "sepa-sct", "kind": "reason-code", "name": "Account address invalid", "group": "administrative", "summary": "The transfer lacks a Beneficiary address, or carries an invalid one, where the Beneficiary PSP needs it to process the payment.", "triggers": [ "No Beneficiary address in the transfer when the Beneficiary PSP needs one for further processing", "An invalid Beneficiary address" ], "actions": [ "Originator PSP to ask the Originator for the Beneficiary's address and send a new transfer", "Use a structured or hybrid address; unstructured addresses are not allowed from 15 November 2026 (AT-E004)" ], "retry": { "allowed": true, "rule": "Send again with a valid Beneficiary address. A new transfer is a new Credit Transfer Instruction. A rejected instruction that the Originator PSP repairs and resends is also treated as a new instruction (EPC125-05 2025 v1.1 section 4.3.2.2, CT-01.03R)." }, "facts": { "return_windows": [ { "action": "return", "by": "Beneficiary PSP", "deadline": "After inter-PSP settlement. The Return message and the funds go to the Originator PSP through the CSM no later than 3 Banking Business Days after the Settlement Date" } ], "applies_to": "SCT" }, "caveat": "The rulebook makes the Beneficiary address optional in DS-02 (AT-E004), so this code turns on the Beneficiary PSP's own processing needs. The guidance lists BE04 for returns only. When the missing or invalid Beneficiary data is needed for regulatory reasons, RR03 applies.", "related": [ "sepa-sct:RR03", "sepa-sct:RR02" ], "basis": { "sources": "EPC135-18 v6.0 section 3, entry for BE04 (ISO name, rulebook reason, R-transaction types, use cases, root causes, suggested action); EPC125-05 2025 v1.1 sections 4.3.2.2, CT-01.04R and 4.6.1 AT-R004, AT-R005 (return: Beneficiary PSP, after settlement, message and funds within 3 Banking Business Days after the Settlement Date); EPC125-05 2025 v1.1 sections 4.5.2 DS-02 and 4.6.1 AT-P005, AT-E004 (Originator address mandatory only when either PSP is in a non-EEA SEPA country or territory; unstructured addresses no longer allowed from 15 November 2026); EPC125-05 2025 v1.1 chapter 7 (a Banking Business Day is a T2 day).", "confidence": "high" }, "currency": { "effective_since": "2025-10-05", "effective_note": "EPC125-05 2025 v1.1 was issued and took effect on 2025-10-05; v1.1 changed only the date for the unstructured address phase-out, now 15 November 2026. EPC135-18 v6.0, published 2024-11-28, is taken to be the current SCT reason code guidance and to cover the 2025 rulebook [Unverified]. The next SCT rulebook is due for publication in November 2026 [Unverified].", "source_edition": "EPC135-18 v6.0; EPC125-05 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-09/EPC125-05%202025%20SCT%20Rulebook%20version%201.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC135-18 v6.0 Guidance on Reason Codes for SCT R-transactions and EPC125-05 2025 v1.1 SCT Rulebook", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms BE04 (Account address invalid) as a valid SCT R-transaction reason code against EPC135-18 v6.0 section 3 (ISO definition, rulebook reason, and R-transaction type list match the record). Confirms: return sent by the Beneficiary PSP within 3 Banking Business Days after the Settlement Date (EPC125-05 section 4.3.2.2, CT-01.04R). Does not address the triggers, actions, retry rule, or caveat text beyond the sections already cited in the record's basis." } ] }, "rail_name": "SEPA Credit Transfer", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sct:CERI", "id": "CERI", "rail": "sepa-sct", "kind": "reason-code", "name": "Check ERI", "group": "technical", "summary": "The transfer is not flagged as carrying Extended Remittance Information (ERI) but contains it.", "triggers": [ "An error at the Originator or in the Originator PSP's system built the message with ERI but without the ERI flag" ], "actions": [ "Originator PSP to check its message building and, if needed, go back to the Originator", "Resend either without ERI or correctly flagged to a Beneficiary PSP that takes part in the ERI Option [Inference]" ], "retry": { "allowed": true, "rule": "Send again once the ERI flag and content match. A new transfer is a new Credit Transfer Instruction. A rejected instruction that the Originator PSP repairs and resends is also treated as a new instruction (EPC125-05 2025 v1.1 section 4.3.2.2, CT-01.03R)." }, "facts": { "return_windows": [ { "action": "reject", "by": "Not stated by the EPC; [Inference] the Originator PSP or the CSM, the parties the rulebook lets reject an SCT", "deadline": "Not stated for this code. [Inference] The general SCT reject timing applies: before inter-PSP settlement, the same day where possible and no later than the next Banking Business Day (a T2 day); a CSM passes a reject to the Originator PSP no later than the next Banking Business Day after rejecting" } ], "applies_to": "SCT" }, "caveat": "CERI comes from the guidance, which lists it as a reject only (EPC135-18 v6.0 section 3). The rulebook's reject reasons for the Originator PSP or the CSM (EPC125-05 2025 v1.1 section 4.6.1, AT-R004) have no entry that clearly matches this case, and neither text says which of those reasons CERI stands for, who sends it, or when [Unverified]. The sender and deadline in this record are the general reject pattern, not a stated rule for this code [Inference]. The ERI Option rules themselves are in ANNEX V. The ERI Option binds only participants that declared it.", "related": [ "sepa-sct:NERI", "sepa-sct:ERIN" ], "basis": { "sources": "EPC135-18 v6.0 section 3, entry for CERI (ISO name, rulebook reason, R-transaction types, use cases, root causes, suggested action); EPC125-05 2025 v1.1 sections 4.3.2.1, 4.3.2.2 CT-01.03R and 4.6.1 AT-R002, AT-R004 (reject: before inter-PSP settlement, by the Originator PSP or the CSM, same day and at the latest the next Banking Business Day); EPC125-05 2025 v1.1 sections 0.5.3 and 2.7 and ANNEX V section 4 'ERI Processing' (ERI Option participation, reject or return of ERI sent to a non-participant); EPC125-05 2025 v1.1 chapter 7 (a Banking Business Day is a T2 day).", "confidence": "medium" }, "currency": { "effective_since": "2025-10-05", "effective_note": "EPC125-05 2025 v1.1 was issued and took effect on 2025-10-05; v1.1 changed only the date for the unstructured address phase-out, now 15 November 2026. EPC135-18 v6.0, published 2024-11-28, is taken to be the current SCT reason code guidance and to cover the 2025 rulebook [Unverified]. The next SCT rulebook is due for publication in November 2026 [Unverified].", "source_edition": "EPC135-18 v6.0; EPC125-05 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-09/EPC125-05%202025%20SCT%20Rulebook%20version%201.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC135-18 v6.0 Guidance on Reason Codes for SCT R-transactions and EPC125-05 2025 v1.1 SCT Rulebook", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17c", "notes": "Confirms CERI (Check ERI) as a reject-only code with the use case and root cause matching EPC135-18 v6.0 section 3, a message built with ERI content but without the ERI flag. Confirms the general SCT reject timing, same day where possible and no later than the next Banking Business Day, and that a rejected instruction repaired and resent is a new Credit Transfer Instruction, EPC125-05 2025 v1.1 section 4.3.2.1 and CT-01.03R. Confirms the AT-R004 reject reasons list has no entry that clearly matches this case. Does not name who sends CERI or when; the record correctly labels the sender and deadline as the general reject pattern, not a stated rule for this code." } ] }, "rail_name": "SEPA Credit Transfer", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sct:CNOR", "id": "CNOR", "rail": "sepa-sct", "kind": "reason-code", "name": "Beneficiary PSP not registered under this BIC in the CSM", "group": "network", "summary": "The CSM does not hold the Beneficiary PSP as an SCT scheme participant under the BIC used.", "triggers": [ "The Beneficiary PSP is not, or is no longer, a direct or indirect participant of this CSM" ], "actions": [ "Originator to ask the Beneficiary how it can receive SCT transfers through another PSP", "Originator PSP to check whether the Beneficiary PSP is reachable through another CSM [Inference]" ], "retry": { "allowed": false, "rule": "Do not resend through the same route until the Beneficiary PSP's reachability is confirmed, or pay to an account at another PSP [Inference]." }, "facts": { "return_windows": [ { "action": "reject", "by": "Originator PSP or CSM", "deadline": "Before inter-PSP settlement. Sent the same day where possible and no later than the next Banking Business Day (a T2 day); the CSM passes a reject to the Originator PSP no later than the next Banking Business Day after rejecting" }, { "action": "return", "by": "Beneficiary PSP", "deadline": "After inter-PSP settlement. The Return message and the funds go to the Originator PSP through the CSM no later than 3 Banking Business Days after the Settlement Date" } ], "applies_to": "SCT" }, "caveat": "The rulebook lists this reason for both rejects and returns (AT-R004), but the texts read do not explain how a Beneficiary PSP returns a transfer it is said not to be registered for [Inference: a change in registration between exchange and processing]. The reject is most likely sent by the CSM [Inference].", "related": [ "sepa-sct:DNOR", "sepa-sct:RC01" ], "basis": { "sources": "EPC135-18 v6.0 section 3, entry for CNOR (ISO name, rulebook reason, R-transaction types, use cases, root causes, suggested action); EPC125-05 2025 v1.1 sections 4.3.2.1, 4.3.2.2 CT-01.03R and 4.6.1 AT-R002, AT-R004 (reject: before inter-PSP settlement, by the Originator PSP or the CSM, same day and at the latest the next Banking Business Day); EPC125-05 2025 v1.1 sections 4.3.2.2, CT-01.04R and 4.6.1 AT-R004, AT-R005 (return: Beneficiary PSP, after settlement, message and funds within 3 Banking Business Days after the Settlement Date); EPC125-05 2025 v1.1 sections 2.6 and 5.3 (reachability); EPC125-05 2025 v1.1 chapter 7 (a Banking Business Day is a T2 day).", "confidence": "medium" }, "currency": { "effective_since": "2025-10-05", "effective_note": "EPC125-05 2025 v1.1 was issued and took effect on 2025-10-05; v1.1 changed only the date for the unstructured address phase-out, now 15 November 2026. EPC135-18 v6.0, published 2024-11-28, is taken to be the current SCT reason code guidance and to cover the 2025 rulebook [Unverified]. The next SCT rulebook is due for publication in November 2026 [Unverified].", "source_edition": "EPC135-18 v6.0; EPC125-05 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-09/EPC125-05%202025%20SCT%20Rulebook%20version%201.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC135-18 v6.0 Guidance on Reason Codes for SCT R-transactions and EPC125-05 2025 v1.1 SCT Rulebook", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms CNOR (Beneficiary PSP not registered under this BIC in the CSM) as a valid SCT R-transaction reason code against EPC135-18 v6.0 section 3 (ISO definition, rulebook reason, and R-transaction type list match the record). Confirms: reject sent before inter-PSP settlement, at the latest the next Banking Business Day (EPC125-05 section 4.3.2.1); return sent by the Beneficiary PSP within 3 Banking Business Days after the Settlement Date (EPC125-05 section 4.3.2.2, CT-01.04R). Does not address the triggers, actions, retry rule, or caveat text beyond the sections already cited in the record's basis." } ] }, "rail_name": "SEPA Credit Transfer", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sct:CUST", "id": "CUST", "rail": "sepa-sct", "kind": "reason-code", "name": "Requested by customer", "group": "authorization", "summary": "Two uses. In a request for recall by the originator, the Originator wants its money back and gives no reason. In an answer to a recall or request for recall, the Beneficiary refuses to give the money back.", "triggers": [ "The Originator asks to recover a settled transfer without stating a specific reason (RFRO)", "The Beneficiary considers itself entitled to the funds and refuses (negative answer)" ], "actions": [ "On an RFRO: Originator PSP to confirm the 13-month limit and warn the Originator that recovery is not guaranteed", "On a refusal: Originator (and the Originator PSP where the Recall was for its own error) to contact the Beneficiary directly and seek the funds outside the scheme's Recall and RFRO procedures" ], "retry": { "allowed": false, "rule": "No. After the Beneficiary PSP has answered, the Originator PSP may not send another Recall or RFRO for the same transfer (EPC125-05 2025 v1.1 sections 4.3.2.3 and 4.3.2.4). Any further recovery happens outside the scheme." }, "facts": { "return_windows": [ { "action": "request for recall by the originator", "by": "Originator PSP, at the Originator's request", "deadline": "The debit date of the original transfer must fall within the 13 months before the Originator PSP received the request. Only one request per transfer" }, { "action": "negative answer to a recall", "by": "Beneficiary PSP", "deadline": "Within 15 Banking Business Days after receiving the Recall" }, { "action": "negative answer to a request for recall by the originator", "by": "Beneficiary PSP", "deadline": "Within 15 Banking Business Days after receiving the request" } ], "applies_to": "SCT" }, "caveat": "The Beneficiary's answer to an RFRO decides the matter within the scheme (section 4.3.2.4, Step 4B). The guidance also names CUST as the substitute for AM04 where data protection law bars AM04, so a CUST refusal may hide insufficient funds.", "related": [ "sepa-sct:AM04", "sepa-sct:AC03", "sepa-sct:AM09", "sepa-sct:FOCR", "sepa-sct:NOAS", "sepa-sct:LEGL" ], "basis": { "sources": "EPC135-18 v6.0 section 3, entry for CUST (ISO name, rulebook reason, R-transaction types, use cases, root causes, suggested action); EPC135-18 v6.0 section 3, entry for AM04 (CUST as the data protection substitute); EPC125-05 2025 v1.1 section 4.3.2.4, Step 1 and 4.6.1 AT-R071, AT-R073 (RFRO: reasons other than the three Recall reasons; debit date within the 13 months before the Originator PSP received the request; one per transfer); EPC125-05 2025 v1.1 section 4.3.2.3, CT-02.03, CT-02.03R, CT-02-04 and 4.5.6 DS-06, 4.6.1 AT-R054 to AT-R057 (response to a Recall: Beneficiary PSP, within 15 Banking Business Days of receipt); EPC125-05 2025 v1.1 section 4.3.2.4, Steps 3, 4A, 4B and 4C and 4.5.8 DS-08, 4.6.1 AT-R074 to AT-R078 (response to an RFRO: Beneficiary PSP, within 15 Banking Business Days of receipt); EPC125-05 2025 v1.1 chapter 7 (a Banking Business Day is a T2 day).", "confidence": "high" }, "currency": { "effective_since": "2025-10-05", "effective_note": "EPC125-05 2025 v1.1 was issued and took effect on 2025-10-05; v1.1 changed only the date for the unstructured address phase-out, now 15 November 2026. EPC135-18 v6.0, published 2024-11-28, is taken to be the current SCT reason code guidance and to cover the 2025 rulebook [Unverified]. The next SCT rulebook is due for publication in November 2026 [Unverified].", "source_edition": "EPC135-18 v6.0; EPC125-05 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-09/EPC125-05%202025%20SCT%20Rulebook%20version%201.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC135-18 v6.0 Guidance on Reason Codes for SCT R-transactions and EPC125-05 2025 v1.1 SCT Rulebook", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms CUST (Requested by customer) as a valid SCT R-transaction reason code against EPC135-18 v6.0 section 3 (ISO definition, rulebook reason, and R-transaction type list match the record). Confirms: RFRO sent by the Originator PSP, debit date within 13 months of the request (EPC125-05 section 4.3.2.4); Beneficiary PSP's answer to a Recall within 15 Banking Business Days of receipt (EPC125-05 section 4.3.2.3); Beneficiary PSP's answer to an RFRO within 15 Banking Business Days of receipt (EPC125-05 section 4.3.2.4). Does not address the triggers, actions, retry rule, or caveat text beyond the sections already cited in the record's basis." } ] }, "rail_name": "SEPA Credit Transfer", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sct:CVAA", "id": "CVAA", "rail": "sepa-sct", "kind": "reason-code", "name": "Correct value date already applied", "group": "administrative", "summary": "Negative answer to a claim for value date correction: the Beneficiary PSP says it already applied the value date the transfer called for.", "triggers": [ "The Beneficiary PSP holds that it applied the correct value date as set out in the transfer" ], "actions": [ "Originator PSP to explain to the Originator that the transfer was executed as instructed" ], "retry": { "allowed": false, "rule": "Not applicable: this is a final answer to an inquiry. The rulebook read describes no appeal within the scheme [Unverified]." }, "facts": { "return_windows": [ { "action": "negative answer to an inquiry (claim for value date correction)", "by": "Beneficiary PSP", "deadline": "Within 10 Banking Business Days after receiving the inquiry" } ], "applies_to": "SCT" }, "caveat": "Compare RJVA, the other negative answer, which turns on the 13-month limit and the 17 November 2019 start date rather than on the value date itself.", "related": [ "sepa-sct:ACVA", "sepa-sct:MODI", "sepa-sct:RJVA" ], "basis": { "sources": "EPC135-18 v6.0 section 3, entry for CVAA (ISO name, rulebook reason, R-transaction types, use cases, root causes, suggested action); EPC125-05 2025 v1.1 sections 4.4.1 and 4.4.2 and 4.5.10 DS-10 (SCT inquiry: debit date within 13 months before the Originator submits it; Beneficiary PSP answers within 10 Banking Business Days); EPC125-05 2025 v1.1 chapter 7 (a Banking Business Day is a T2 day).", "confidence": "high" }, "currency": { "effective_since": "2025-10-05", "effective_note": "EPC125-05 2025 v1.1 was issued and took effect on 2025-10-05; v1.1 changed only the date for the unstructured address phase-out, now 15 November 2026. EPC135-18 v6.0, published 2024-11-28, is taken to be the current SCT reason code guidance and to cover the 2025 rulebook [Unverified]. The next SCT rulebook is due for publication in November 2026 [Unverified].", "source_edition": "EPC135-18 v6.0; EPC125-05 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-09/EPC125-05%202025%20SCT%20Rulebook%20version%201.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC135-18 v6.0 Guidance on Reason Codes for SCT R-transactions and EPC125-05 2025 v1.1 SCT Rulebook", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms CVAA (Correct value date already applied) as a valid SCT R-transaction reason code against EPC135-18 v6.0 section 3 (ISO definition, rulebook reason, and R-transaction type list match the record). Confirms: Beneficiary PSP's answer to an SCT inquiry (claim for value date correction) within 10 Banking Business Days of receipt (EPC125-05 section 4.4.2). Does not address the triggers, actions, retry rule, or caveat text beyond the sections already cited in the record's basis." } ] }, "rail_name": "SEPA Credit Transfer", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sct:DNOR", "id": "DNOR", "rail": "sepa-sct", "kind": "reason-code", "name": "Originator PSP not registered under this BIC in the CSM", "group": "network", "summary": "The CSM does not hold the Originator PSP as an SCT scheme participant under the BIC used.", "triggers": [ "The Originator PSP sent the transfer by mistake to a CSM it no longer uses" ], "actions": [ "Originator PSP to route the transfer through its current CSM", "Originator PSP to contact the Originator if another means of payment to the Beneficiary is needed" ], "retry": { "allowed": true, "rule": "Send again through the CSM where the Originator PSP is registered. A new transfer is a new Credit Transfer Instruction. A rejected instruction that the Originator PSP repairs and resends is also treated as a new instruction (EPC125-05 2025 v1.1 section 4.3.2.2, CT-01.03R)." }, "facts": { "return_windows": [ { "action": "reject", "by": "Originator PSP or CSM", "deadline": "Before inter-PSP settlement. Sent the same day where possible and no later than the next Banking Business Day (a T2 day); the CSM passes a reject to the Originator PSP no later than the next Banking Business Day after rejecting" } ], "applies_to": "SCT" }, "caveat": "The reject is most likely sent by the CSM, since only it holds the registration [Inference].", "related": [ "sepa-sct:CNOR", "sepa-sct:RC01" ], "basis": { "sources": "EPC135-18 v6.0 section 3, entry for DNOR (ISO name, rulebook reason, R-transaction types, use cases, root causes, suggested action); EPC125-05 2025 v1.1 sections 4.3.2.1, 4.3.2.2 CT-01.03R and 4.6.1 AT-R002, AT-R004 (reject: before inter-PSP settlement, by the Originator PSP or the CSM, same day and at the latest the next Banking Business Day); EPC125-05 2025 v1.1 chapter 7 (a Banking Business Day is a T2 day).", "confidence": "medium" }, "currency": { "effective_since": "2025-10-05", "effective_note": "EPC125-05 2025 v1.1 was issued and took effect on 2025-10-05; v1.1 changed only the date for the unstructured address phase-out, now 15 November 2026. EPC135-18 v6.0, published 2024-11-28, is taken to be the current SCT reason code guidance and to cover the 2025 rulebook [Unverified]. The next SCT rulebook is due for publication in November 2026 [Unverified].", "source_edition": "EPC135-18 v6.0; EPC125-05 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-09/EPC125-05%202025%20SCT%20Rulebook%20version%201.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC135-18 v6.0 Guidance on Reason Codes for SCT R-transactions and EPC125-05 2025 v1.1 SCT Rulebook", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms DNOR (Originator PSP not registered under this BIC in the CSM) as a valid SCT R-transaction reason code against EPC135-18 v6.0 section 3 (ISO definition, rulebook reason, and R-transaction type list match the record). Confirms: reject sent before inter-PSP settlement, at the latest the next Banking Business Day (EPC125-05 section 4.3.2.1). Does not address the triggers, actions, retry rule, or caveat text beyond the sections already cited in the record's basis." } ] }, "rail_name": "SEPA Credit Transfer", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sct:DUPL", "id": "DUPL", "rail": "sepa-sct", "kind": "reason-code", "name": "Duplicate sending", "group": "administrative", "summary": "Recall reason: the Originator or Originator PSP found it sent the same transfer twice and asks for the copy back.", "triggers": [ "A technical or human error at the Originator or the Originator PSP sent a transfer twice" ], "actions": [ "Originator PSP to send the Recall within 10 Banking Business Days of the execution date", "Expect FOCR with the funds, possibly less a fee, or a negative answer within 15 Banking Business Days of receipt", "Set up controls so duplicates are not initiated or exchanged again" ], "retry": { "allowed": false, "rule": "Only one Recall per transfer, and none after the Beneficiary PSP has answered (section 4.3.2.3). If no answer arrives in 15 Banking Business Days, the Originator PSP may send a Request for Status Update instead." }, "facts": { "return_windows": [ { "action": "recall", "by": "Originator PSP, on its own initiative or at the Originator's request", "deadline": "Sent within 10 Banking Business Days after the execution date of the original transfer. Only one Recall per transfer" }, { "action": "negative answer to a recall", "by": "Beneficiary PSP", "deadline": "Within 15 Banking Business Days after receiving the Recall" }, { "action": "positive answer to a recall", "by": "Beneficiary PSP", "deadline": "Within 15 Banking Business Days after receiving the Recall; the CSM then settles the returned amount with the Originator PSP" } ], "applies_to": "SCT" }, "caveat": "A Recall is a request, not a right: the Beneficiary PSP may answer negatively, and depending on national law or its contract may need the Beneficiary's consent to debit the account (CT-02.03). A Recall made before settlement leads to a cancellation under the CSM's own procedures. The Originator PSP may refuse a customer's Recall request that falls outside the reasons or the time limit (CT-02.01R). DUPL is the originating side's code; AM05 is the receiving side's.", "related": [ "sepa-sct:AM05", "sepa-sct:TECH", "sepa-sct:FRAD", "sepa-sct:FOCR", "sepa-sct:NOAS" ], "basis": { "sources": "EPC135-18 v6.0 section 3, entry for DUPL (ISO name, rulebook reason, R-transaction types, use cases, root causes, suggested action); EPC125-05 2025 v1.1 section 4.3.2.3, CT-02.00 to CT-02.07 and 4.6.1 AT-R051, AT-R052 (recall: three permitted reasons; 10 Banking Business Days, or 13 months for fraud, after the execution date; one Recall per transfer); EPC125-05 2025 v1.1 section 4.3.2.3, CT-02.03, CT-02.03R, CT-02-04 and 4.5.6 DS-06, 4.6.1 AT-R054 to AT-R057 (response to a Recall: Beneficiary PSP, within 15 Banking Business Days of receipt); EPC125-05 2025 v1.1 chapter 7 (a Banking Business Day is a T2 day).", "confidence": "high" }, "currency": { "effective_since": "2025-10-05", "effective_note": "EPC125-05 2025 v1.1 was issued and took effect on 2025-10-05; v1.1 changed only the date for the unstructured address phase-out, now 15 November 2026. EPC135-18 v6.0, published 2024-11-28, is taken to be the current SCT reason code guidance and to cover the 2025 rulebook [Unverified]. The next SCT rulebook is due for publication in November 2026 [Unverified].", "source_edition": "EPC135-18 v6.0; EPC125-05 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-09/EPC125-05%202025%20SCT%20Rulebook%20version%201.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC135-18 v6.0 Guidance on Reason Codes for SCT R-transactions and EPC125-05 2025 v1.1 SCT Rulebook", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms DUPL (Duplicate sending) as a valid SCT R-transaction reason code against EPC135-18 v6.0 section 3 (ISO definition, rulebook reason, and R-transaction type list match the record). Confirms: Recall sent by the Originator PSP within 10 Banking Business Days of the execution date (EPC125-05 section 4.3.2.3); Beneficiary PSP's answer to a Recall within 15 Banking Business Days of receipt (EPC125-05 section 4.3.2.3). Does not address the triggers, actions, retry rule, or caveat text beyond the sections already cited in the record's basis." } ] }, "rail_name": "SEPA Credit Transfer", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "jurisdiction", "label": "the country", "needs": "which country the payment or the account is in", "detail": "A Recall is a request, not a right: the Beneficiary PSP may answer negatively, and depending on national law or its contract may need the Beneficiary's consent to debit the account (CT-02.03).", "from": "caveat" } ] }, { "uid": "sepa-sct:ED05", "id": "ED05", "rail": "sepa-sct", "kind": "reason-code", "name": "Settlement failed", "group": "network", "summary": "The transfer could not be settled between PSPs, so it is rejected.", "triggers": [ "The Originator PSP's inter-PSP funding for SCT was not enough to settle the transfer" ], "actions": [ "Follow the service level agreement between the Originator PSP and the CSM", "Originator PSP to decide whether to repair and resend within the execution time or tell the Originator (CT-01.03R)" ], "retry": { "allowed": true, "rule": "The rulebook sets no rule specific to ED05; a resend is a new instruction. A new transfer is a new Credit Transfer Instruction. A rejected instruction that the Originator PSP repairs and resends is also treated as a new instruction (EPC125-05 2025 v1.1 section 4.3.2.2, CT-01.03R)." }, "facts": { "return_windows": [ { "action": "reject", "by": "Originator PSP or CSM", "deadline": "Before inter-PSP settlement. Sent the same day where possible and no later than the next Banking Business Day (a T2 day); the CSM passes a reject to the Originator PSP no later than the next Banking Business Day after rejecting" } ], "applies_to": "SCT" }, "caveat": "The guidance says the Originator PSP or the CSM must report the settlement failure. How funding and resubmission work is a matter for the CSM's own rules, not the rulebook.", "related": [ "sepa-sct:TM01", "sepa-sct:DNOR" ], "basis": { "sources": "EPC135-18 v6.0 section 3, entry for ED05 (ISO name, rulebook reason, R-transaction types, use cases, root causes, suggested action); EPC125-05 2025 v1.1 sections 4.3.2.1, 4.3.2.2 CT-01.03R and 4.6.1 AT-R002, AT-R004 (reject: before inter-PSP settlement, by the Originator PSP or the CSM, same day and at the latest the next Banking Business Day); EPC125-05 2025 v1.1 chapter 7 (a Banking Business Day is a T2 day).", "confidence": "high" }, "currency": { "effective_since": "2025-10-05", "effective_note": "EPC125-05 2025 v1.1 was issued and took effect on 2025-10-05; v1.1 changed only the date for the unstructured address phase-out, now 15 November 2026. EPC135-18 v6.0, published 2024-11-28, is taken to be the current SCT reason code guidance and to cover the 2025 rulebook [Unverified]. The next SCT rulebook is due for publication in November 2026 [Unverified].", "source_edition": "EPC135-18 v6.0; EPC125-05 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-09/EPC125-05%202025%20SCT%20Rulebook%20version%201.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC135-18 v6.0 Guidance on Reason Codes for SCT R-transactions and EPC125-05 2025 v1.1 SCT Rulebook", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms ED05 (Settlement failed) as a valid SCT R-transaction reason code against EPC135-18 v6.0 section 3 (ISO definition, rulebook reason, and R-transaction type list match the record). Confirms: reject sent before inter-PSP settlement, at the latest the next Banking Business Day (EPC125-05 section 4.3.2.1). Does not address the triggers, actions, retry rule, or caveat text beyond the sections already cited in the record's basis." } ] }, "rail_name": "SEPA Credit Transfer", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "judgement", "label": "your bank's own terms", "needs": "whose terms decide it: the bank's, the participant's or the scheme's", "detail": "How funding and resubmission work is a matter for the CSM's own rules, not the rulebook.", "from": "caveat" } ] }, { "uid": "sepa-sct:ERIN", "id": "ERIN", "rail": "sepa-sct", "kind": "reason-code", "name": "ERI Option not supported", "group": "technical", "summary": "The transfer carries Extended Remittance Information (ERI), but the Originator PSP or the Beneficiary PSP does not take part in the ERI Option.", "triggers": [ "The Originator PSP or the Beneficiary PSP is not an ERI Option participant (reject)", "The Beneficiary PSP is not an ERI Option participant and receives ERI after settlement (return)" ], "actions": [ "Originator decides how to proceed, for example resending with only the 140-character unstructured remittance information", "Originator PSP to check before sending whether the Beneficiary PSP takes part in the ERI Option (ANNEX V)" ], "retry": { "allowed": true, "rule": "Send again without ERI, or to a Beneficiary PSP that takes part in the ERI Option. A new transfer is a new Credit Transfer Instruction. A rejected instruction that the Originator PSP repairs and resends is also treated as a new instruction (EPC125-05 2025 v1.1 section 4.3.2.2, CT-01.03R)." }, "facts": { "return_windows": [ { "action": "reject", "by": "Originator PSP or CSM", "deadline": "Before inter-PSP settlement. Sent the same day where possible and no later than the next Banking Business Day (a T2 day); the CSM passes a reject to the Originator PSP no later than the next Banking Business Day after rejecting" }, { "action": "return", "by": "Beneficiary PSP", "deadline": "After inter-PSP settlement. The Return message and the funds go to the Originator PSP through the CSM no later than 3 Banking Business Days after the Settlement Date" } ], "applies_to": "SCT" }, "caveat": "An Originator PSP that receives ERI for a non-participating Beneficiary PSP must reject it, unless it has agreed with the Originator to strip the structured remittance information and send only the unstructured 140 characters (ANNEX V). A non-participant that receives ERI sends it back as a reject or a return, depending on whether it has settled (section 2.7).", "related": [ "sepa-sct:CERI", "sepa-sct:NERI" ], "basis": { "sources": "EPC135-18 v6.0 section 3, entry for ERIN (ISO name, rulebook reason, R-transaction types, use cases, root causes, suggested action); EPC125-05 2025 v1.1 sections 4.3.2.1, 4.3.2.2 CT-01.03R and 4.6.1 AT-R002, AT-R004 (reject: before inter-PSP settlement, by the Originator PSP or the CSM, same day and at the latest the next Banking Business Day); EPC125-05 2025 v1.1 sections 4.3.2.2, CT-01.04R and 4.6.1 AT-R004, AT-R005 (return: Beneficiary PSP, after settlement, message and funds within 3 Banking Business Days after the Settlement Date); EPC125-05 2025 v1.1 sections 0.5.3 and 2.7 and ANNEX V section 4 'ERI Processing' (ERI Option participation, reject or return of ERI sent to a non-participant); EPC125-05 2025 v1.1 chapter 7 (a Banking Business Day is a T2 day).", "confidence": "high" }, "currency": { "effective_since": "2025-10-05", "effective_note": "EPC125-05 2025 v1.1 was issued and took effect on 2025-10-05; v1.1 changed only the date for the unstructured address phase-out, now 15 November 2026. EPC135-18 v6.0, published 2024-11-28, is taken to be the current SCT reason code guidance and to cover the 2025 rulebook [Unverified]. The next SCT rulebook is due for publication in November 2026 [Unverified].", "source_edition": "EPC135-18 v6.0; EPC125-05 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-09/EPC125-05%202025%20SCT%20Rulebook%20version%201.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC135-18 v6.0 Guidance on Reason Codes for SCT R-transactions and EPC125-05 2025 v1.1 SCT Rulebook", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms ERIN (ERI Option not supported) as a valid SCT R-transaction reason code against EPC135-18 v6.0 section 3 (ISO definition, rulebook reason, and R-transaction type list match the record). Confirms: reject sent before inter-PSP settlement, at the latest the next Banking Business Day (EPC125-05 section 4.3.2.1); return sent by the Beneficiary PSP within 3 Banking Business Days after the Settlement Date (EPC125-05 section 4.3.2.2, CT-01.04R). Does not address the triggers, actions, retry rule, or caveat text beyond the sections already cited in the record's basis." } ] }, "rail_name": "SEPA Credit Transfer", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sct:FF01", "id": "FF01", "rail": "sepa-sct", "kind": "reason-code", "name": "Invalid file format", "group": "technical", "summary": "The XML file or message is not valid: badly filled in, with a syntax error, or not checked against the schema before sending.", "triggers": [ "The XML file was not filled in correctly", "The file has a syntax error", "The Originator PSP or its CSM did not run an XSD check before sending the file" ], "actions": [ "Repair the XML file and send it again" ], "retry": { "allowed": true, "rule": "Send again once the file passes validation. A new transfer is a new Credit Transfer Instruction. A rejected instruction that the Originator PSP repairs and resends is also treated as a new instruction (EPC125-05 2025 v1.1 section 4.3.2.2, CT-01.03R)." }, "facts": { "return_windows": [ { "action": "reject", "by": "Originator PSP or CSM", "deadline": "Before inter-PSP settlement. Sent the same day where possible and no later than the next Banking Business Day (a T2 day); the CSM passes a reject to the Originator PSP no later than the next Banking Business Day after rejecting" } ], "applies_to": "SCT" }, "caveat": "The guidance names the Originator, the Originator PSP and the CSM as where the error can arise. For a wrong service level or local instrument, AG02 applies instead.", "related": [ "sepa-sct:AG02" ], "basis": { "sources": "EPC135-18 v6.0 section 3, entry for FF01 (ISO name, rulebook reason, R-transaction types, use cases, root causes, suggested action); EPC125-05 2025 v1.1 sections 4.3.2.1, 4.3.2.2 CT-01.03R and 4.6.1 AT-R002, AT-R004 (reject: before inter-PSP settlement, by the Originator PSP or the CSM, same day and at the latest the next Banking Business Day); EPC125-05 2025 v1.1 chapter 7 (a Banking Business Day is a T2 day).", "confidence": "high" }, "currency": { "effective_since": "2025-10-05", "effective_note": "EPC125-05 2025 v1.1 was issued and took effect on 2025-10-05; v1.1 changed only the date for the unstructured address phase-out, now 15 November 2026. EPC135-18 v6.0, published 2024-11-28, is taken to be the current SCT reason code guidance and to cover the 2025 rulebook [Unverified]. The next SCT rulebook is due for publication in November 2026 [Unverified].", "source_edition": "EPC135-18 v6.0; EPC125-05 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-09/EPC125-05%202025%20SCT%20Rulebook%20version%201.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC135-18 v6.0 Guidance on Reason Codes for SCT R-transactions and EPC125-05 2025 v1.1 SCT Rulebook", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms FF01 (Invalid file format) as a valid SCT R-transaction reason code against EPC135-18 v6.0 section 3 (ISO definition, rulebook reason, and R-transaction type list match the record). Confirms: reject sent before inter-PSP settlement, at the latest the next Banking Business Day (EPC125-05 section 4.3.2.1). Does not address the triggers, actions, retry rule, or caveat text beyond the sections already cited in the record's basis." } ] }, "rail_name": "SEPA Credit Transfer", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sct:FOCR", "id": "FOCR", "rail": "sepa-sct", "kind": "reason-code", "name": "Following cancellation request", "group": "administrative", "summary": "Positive answer to a recall or a request for recall: the Beneficiary PSP, or the Beneficiary, agrees to pay the funds back.", "triggers": [ "The Beneficiary PSP or the Beneficiary accepts a Recall or RFRO" ], "actions": [ "Beneficiary PSP debits the Beneficiary's account, after the Beneficiary's authorisation where needed, and sends the funds back in the prescribed response message, never as a new SCT", "Originator PSP credits the Originator with the amount in the positive answer", "Expect the amount returned to be the original amount less any fee the Beneficiary PSP chose to charge (AT-R054, AT-R055, AT-R074, AT-R075)" ], "retry": { "allowed": false, "rule": "Not applicable: the funds come back with this answer." }, "facts": { "return_windows": [ { "action": "positive answer to a recall", "by": "Beneficiary PSP", "deadline": "Within 15 Banking Business Days after receiving the Recall; the CSM then settles the returned amount with the Originator PSP" }, { "action": "positive answer to a request for recall by the originator", "by": "Beneficiary PSP", "deadline": "Within 15 Banking Business Days after receiving the request; the funds go back through the CSM" } ], "applies_to": "SCT" }, "caveat": "A fee is allowed only on a positive answer to a Recall or RFRO, and has no effect on the normal return procedure (sections 4.3.2.3 and 4.3.2.4). The CSM settles the returned amount; its settlement date is AT-R056 or AT-R076.", "related": [ "sepa-sct:DUPL", "sepa-sct:TECH", "sepa-sct:FRAD", "sepa-sct:AC03", "sepa-sct:AM09", "sepa-sct:CUST" ], "basis": { "sources": "EPC135-18 v6.0 section 3, entry for FOCR (ISO name, rulebook reason, R-transaction types, use cases, root causes, suggested action); EPC125-05 2025 v1.1 section 4.3.2.3, CT-02.03, CT-02.03R, CT-02-04 and 4.5.6 DS-06, 4.6.1 AT-R054 to AT-R057 (response to a Recall: Beneficiary PSP, within 15 Banking Business Days of receipt); EPC125-05 2025 v1.1 section 4.3.2.4, Steps 3, 4A, 4B and 4C and 4.5.8 DS-08, 4.6.1 AT-R074 to AT-R078 (response to an RFRO: Beneficiary PSP, within 15 Banking Business Days of receipt); EPC125-05 2025 v1.1 chapter 7 (a Banking Business Day is a T2 day).", "confidence": "high" }, "currency": { "effective_since": "2025-10-05", "effective_note": "EPC125-05 2025 v1.1 was issued and took effect on 2025-10-05; v1.1 changed only the date for the unstructured address phase-out, now 15 November 2026. EPC135-18 v6.0, published 2024-11-28, is taken to be the current SCT reason code guidance and to cover the 2025 rulebook [Unverified]. The next SCT rulebook is due for publication in November 2026 [Unverified].", "source_edition": "EPC135-18 v6.0; EPC125-05 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-09/EPC125-05%202025%20SCT%20Rulebook%20version%201.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC135-18 v6.0 Guidance on Reason Codes for SCT R-transactions and EPC125-05 2025 v1.1 SCT Rulebook", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms FOCR (Following cancellation request) as a valid SCT R-transaction reason code against EPC135-18 v6.0 section 3 (ISO definition, rulebook reason, and R-transaction type list match the record). Confirms: Beneficiary PSP's answer to a Recall within 15 Banking Business Days of receipt (EPC125-05 section 4.3.2.3); Beneficiary PSP's answer to an RFRO within 15 Banking Business Days of receipt (EPC125-05 section 4.3.2.4). Does not address the triggers, actions, retry rule, or caveat text beyond the sections already cited in the record's basis." } ] }, "rail_name": "SEPA Credit Transfer", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sct:FRAD", "id": "FRAD", "rail": "sepa-sct", "kind": "reason-code", "name": "Fraudulently originated credit transfer", "group": "authorization", "summary": "Recall reason: the Originator or Originator PSP found the transfer was originated by fraud and asks for the funds back. Allowed up to 13 months after execution.", "triggers": [ "The Originator says it was the victim of a fraudulently executed transfer", "Fraudsters manipulated the Originator PSP's SCT applications or systems to send transfers" ], "actions": [ "Originator PSP to send the Recall within 13 months of the execution date, optionally with further details in AT-R052", "Expect FOCR or a negative answer within 15 Banking Business Days of receipt", "Set up controls against such fraud" ], "retry": { "allowed": false, "rule": "Only one Recall per transfer, and none after the Beneficiary PSP has answered (section 4.3.2.3). If no answer arrives in 15 Banking Business Days, the Originator PSP may send a Request for Status Update instead." }, "facts": { "return_windows": [ { "action": "recall", "by": "Originator PSP, on its own initiative or at the Originator's request", "deadline": "Sent within 13 months after the execution date of the original transfer. Only one Recall per transfer" }, { "action": "negative answer to a recall", "by": "Beneficiary PSP", "deadline": "Within 15 Banking Business Days after receiving the Recall" }, { "action": "positive answer to a recall", "by": "Beneficiary PSP", "deadline": "Within 15 Banking Business Days after receiving the Recall; the CSM then settles the returned amount with the Originator PSP" } ], "applies_to": "SCT" }, "caveat": "A Recall is a request, not a right: the Beneficiary PSP may answer negatively, and depending on national law or its contract may need the Beneficiary's consent to debit the account (CT-02.03). The Beneficiary PSP is not obliged to act on the extra details in AT-R052. Fraud is the only Recall reason with a 13-month limit; duplicates and technical problems allow 10 Banking Business Days. Payer rights for unauthorised transfers under payment services law sit outside this scheme procedure [Inference].", "related": [ "sepa-sct:DUPL", "sepa-sct:TECH", "sepa-sct:FOCR", "sepa-sct:CUST", "sepa-sct:NOAS", "sepa-sct:LEGL" ], "basis": { "sources": "EPC135-18 v6.0 section 3, entry for FRAD (ISO name, rulebook reason, R-transaction types, use cases, root causes, suggested action); EPC125-05 2025 v1.1 section 4.3.2.3, CT-02.00 to CT-02.07 and 4.6.1 AT-R051, AT-R052 (recall: three permitted reasons; 10 Banking Business Days, or 13 months for fraud, after the execution date; one Recall per transfer); EPC125-05 2025 v1.1 section 4.3.2.3, CT-02.03, CT-02.03R, CT-02-04 and 4.5.6 DS-06, 4.6.1 AT-R054 to AT-R057 (response to a Recall: Beneficiary PSP, within 15 Banking Business Days of receipt); EPC125-05 2025 v1.1 chapter 7 (a Banking Business Day is a T2 day).", "confidence": "high" }, "currency": { "effective_since": "2025-10-05", "effective_note": "EPC125-05 2025 v1.1 was issued and took effect on 2025-10-05; v1.1 changed only the date for the unstructured address phase-out, now 15 November 2026. EPC135-18 v6.0, published 2024-11-28, is taken to be the current SCT reason code guidance and to cover the 2025 rulebook [Unverified]. The next SCT rulebook is due for publication in November 2026 [Unverified].", "source_edition": "EPC135-18 v6.0; EPC125-05 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-09/EPC125-05%202025%20SCT%20Rulebook%20version%201.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC135-18 v6.0 Guidance on Reason Codes for SCT R-transactions and EPC125-05 2025 v1.1 SCT Rulebook", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms FRAD (Fraudulently originated credit transfer) as a valid SCT R-transaction reason code against EPC135-18 v6.0 section 3 (ISO definition, rulebook reason, and R-transaction type list match the record). Confirms: Recall sent by the Originator PSP within 13 months of the execution date, the fraud-reason window (EPC125-05 section 4.3.2.3); Beneficiary PSP's answer to a Recall within 15 Banking Business Days of receipt (EPC125-05 section 4.3.2.3). Does not address the triggers, actions, retry rule, or caveat text beyond the sections already cited in the record's basis." } ] }, "rail_name": "SEPA Credit Transfer", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "jurisdiction", "label": "the country", "needs": "which country the payment or the account is in", "detail": "A Recall is a request, not a right: the Beneficiary PSP may answer negatively, and depending on national law or its contract may need the Beneficiary's consent to debit the account (CT-02.03).", "from": "caveat" } ] }, { "uid": "sepa-sct:LEGL", "id": "LEGL", "rail": "sepa-sct", "kind": "reason-code", "name": "Legal reasons", "group": "administrative", "summary": "Negative answer to a recall or a request for recall: the Beneficiary PSP may not pay the funds back for legal reasons.", "triggers": [ "A legal reason stops the Beneficiary PSP from reimbursing the funds" ], "actions": [ "Originator (and the Originator PSP where the Recall was for its own error) to contact the Beneficiary directly and seek the funds outside the scheme's Recall and RFRO procedures" ], "retry": { "allowed": false, "rule": "No. After the Beneficiary PSP has answered, the Originator PSP may not send another Recall or RFRO for the same transfer (EPC125-05 2025 v1.1 sections 4.3.2.3 and 4.3.2.4). Any further recovery happens outside the scheme." }, "facts": { "return_windows": [ { "action": "negative answer to a recall", "by": "Beneficiary PSP", "deadline": "Within 15 Banking Business Days after receiving the Recall" }, { "action": "negative answer to a request for recall by the originator", "by": "Beneficiary PSP", "deadline": "Within 15 Banking Business Days after receiving the request" } ], "applies_to": "SCT" }, "caveat": "For a Recall, the rulebook asks the Beneficiary PSP to explain the legal reason in clear text (CT-02.03R).", "related": [ "sepa-sct:CUST", "sepa-sct:AM04", "sepa-sct:NOAS", "sepa-sct:RR04" ], "basis": { "sources": "EPC135-18 v6.0 section 3, entry for LEGL (ISO name, rulebook reason, R-transaction types, use cases, root causes, suggested action); EPC125-05 2025 v1.1 section 4.3.2.3, CT-02.03, CT-02.03R, CT-02-04 and 4.5.6 DS-06, 4.6.1 AT-R054 to AT-R057 (response to a Recall: Beneficiary PSP, within 15 Banking Business Days of receipt); EPC125-05 2025 v1.1 section 4.3.2.4, Steps 3, 4A, 4B and 4C and 4.5.8 DS-08, 4.6.1 AT-R074 to AT-R078 (response to an RFRO: Beneficiary PSP, within 15 Banking Business Days of receipt); EPC125-05 2025 v1.1 chapter 7 (a Banking Business Day is a T2 day).", "confidence": "high" }, "currency": { "effective_since": "2025-10-05", "effective_note": "EPC125-05 2025 v1.1 was issued and took effect on 2025-10-05; v1.1 changed only the date for the unstructured address phase-out, now 15 November 2026. EPC135-18 v6.0, published 2024-11-28, is taken to be the current SCT reason code guidance and to cover the 2025 rulebook [Unverified]. The next SCT rulebook is due for publication in November 2026 [Unverified].", "source_edition": "EPC135-18 v6.0; EPC125-05 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-09/EPC125-05%202025%20SCT%20Rulebook%20version%201.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC135-18 v6.0 Guidance on Reason Codes for SCT R-transactions and EPC125-05 2025 v1.1 SCT Rulebook", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms LEGL (Legal reasons) as a valid SCT R-transaction reason code against EPC135-18 v6.0 section 3 (ISO definition, rulebook reason, and R-transaction type list match the record). Confirms: Beneficiary PSP's answer to a Recall within 15 Banking Business Days of receipt (EPC125-05 section 4.3.2.3); Beneficiary PSP's answer to an RFRO within 15 Banking Business Days of receipt (EPC125-05 section 4.3.2.4). Does not address the triggers, actions, retry rule, or caveat text beyond the sections already cited in the record's basis." } ] }, "rail_name": "SEPA Credit Transfer", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sct:MD07", "id": "MD07", "rail": "sepa-sct", "kind": "reason-code", "name": "Beneficiary deceased", "group": "account", "summary": "The Beneficiary has died, so the Beneficiary PSP returns the transfer.", "triggers": [ "The Beneficiary is deceased" ], "actions": [ "No action set by the guidance; any payment owed is a matter for the Beneficiary's estate outside the scheme [Inference]" ], "retry": { "allowed": false, "rule": "Do not send to this account again [Inference]." }, "facts": { "return_windows": [ { "action": "return", "by": "Beneficiary PSP", "deadline": "After inter-PSP settlement. The Return message and the funds go to the Originator PSP through the CSM no later than 3 Banking Business Days after the Settlement Date" } ], "applies_to": "SCT" }, "caveat": "Data protection law in certain SEPA countries bars this code, and MS03 may be used instead (EPC135-18 v6.0 section 3). The guidance does not name the countries.", "related": [ "sepa-sct:MS03", "sepa-sct:AC04" ], "basis": { "sources": "EPC135-18 v6.0 section 3, entry for MD07 (ISO name, rulebook reason, R-transaction types, use cases, root causes, suggested action); EPC125-05 2025 v1.1 sections 4.3.2.2, CT-01.04R and 4.6.1 AT-R004, AT-R005 (return: Beneficiary PSP, after settlement, message and funds within 3 Banking Business Days after the Settlement Date); EPC125-05 2025 v1.1 chapter 7 (a Banking Business Day is a T2 day).", "confidence": "high" }, "currency": { "effective_since": "2025-10-05", "effective_note": "EPC125-05 2025 v1.1 was issued and took effect on 2025-10-05; v1.1 changed only the date for the unstructured address phase-out, now 15 November 2026. EPC135-18 v6.0, published 2024-11-28, is taken to be the current SCT reason code guidance and to cover the 2025 rulebook [Unverified]. The next SCT rulebook is due for publication in November 2026 [Unverified].", "source_edition": "EPC135-18 v6.0; EPC125-05 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-09/EPC125-05%202025%20SCT%20Rulebook%20version%201.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC135-18 v6.0 Guidance on Reason Codes for SCT R-transactions and EPC125-05 2025 v1.1 SCT Rulebook", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms MD07 (Beneficiary deceased) as a valid SCT R-transaction reason code against EPC135-18 v6.0 section 3 (ISO definition, rulebook reason, and R-transaction type list match the record). Confirms: return sent by the Beneficiary PSP within 3 Banking Business Days after the Settlement Date (EPC125-05 section 4.3.2.2, CT-01.04R). Does not address the triggers, actions, retry rule, or caveat text beyond the sections already cited in the record's basis." } ] }, "rail_name": "SEPA Credit Transfer", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "jurisdiction", "label": "the country", "needs": "which country the payment or the account is in", "detail": "Data protection law in certain SEPA countries bars this code, and MS03 may be used instead (EPC135-18 v6.0 section 3).", "from": "caveat" } ] }, { "uid": "sepa-sct:MODI", "id": "MODI", "rail": "sepa-sct", "kind": "reason-code", "name": "Modified as per request", "group": "administrative", "summary": "Confirmed positive answer to a claim for value date correction: the Beneficiary PSP has corrected the value date on the Beneficiary's account.", "triggers": [ "The Beneficiary PSP received the interest compensation it first asked for under ACVA", "The Beneficiary PSP asks for no interest compensation", "The Beneficiary PSP cannot claim interest because the calculation comes out negative", "The Beneficiary PSP wants the compensation paid later and marks that with the code VADA" ], "actions": [ "If the answer carries VADA, Originator PSP to pay the interest compensation, preferably through DS-11 (section 4.4.4)", "Originator PSP to tell the Originator the value date was corrected" ], "retry": { "allowed": false, "rule": "Not applicable: this closes the inquiry." }, "facts": { "return_windows": [ { "action": "confirmed positive answer to an inquiry (claim for value date correction)", "by": "Beneficiary PSP", "deadline": "Within 10 Banking Business Days after receiving the inquiry, or once the interest compensation or fee it first asked for has arrived" } ], "applies_to": "SCT" }, "caveat": "The Beneficiary PSP states the total compensation and fee only once, either with ACVA or with MODI (section 4.4.2). VADA appears in the guidance only as a marker inside this answer; it has no row of its own.", "related": [ "sepa-sct:ACVA", "sepa-sct:CVAA", "sepa-sct:RJVA" ], "basis": { "sources": "EPC135-18 v6.0 section 3, entry for MODI (ISO name, rulebook reason, R-transaction types, use cases, root causes, suggested action); EPC125-05 2025 v1.1 sections 4.4.1 and 4.4.2 and 4.5.10 DS-10 (SCT inquiry: debit date within 13 months before the Originator submits it; Beneficiary PSP answers within 10 Banking Business Days); EPC125-05 2025 v1.1 sections 4.4.2 and 4.4.4, 4.5.10 DS-10, 4.5.11 DS-11 and 4.6.1 AT-Q005 to AT-Q007 (value date correction: interest compensation at the €STR rate, fee, payment via DS-11); EPC125-05 2025 v1.1 chapter 7 (a Banking Business Day is a T2 day).", "confidence": "high" }, "currency": { "effective_since": "2025-10-05", "effective_note": "EPC125-05 2025 v1.1 was issued and took effect on 2025-10-05; v1.1 changed only the date for the unstructured address phase-out, now 15 November 2026. EPC135-18 v6.0, published 2024-11-28, is taken to be the current SCT reason code guidance and to cover the 2025 rulebook [Unverified]. The next SCT rulebook is due for publication in November 2026 [Unverified].", "source_edition": "EPC135-18 v6.0; EPC125-05 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-09/EPC125-05%202025%20SCT%20Rulebook%20version%201.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC135-18 v6.0 Guidance on Reason Codes for SCT R-transactions and EPC125-05 2025 v1.1 SCT Rulebook", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms MODI (Modified as per request) as a valid SCT R-transaction reason code against EPC135-18 v6.0 section 3 (ISO definition, rulebook reason, and R-transaction type list match the record). Confirms: Beneficiary PSP's answer to an SCT inquiry (claim for value date correction) within 10 Banking Business Days of receipt (EPC125-05 section 4.4.2). Does not address the triggers, actions, retry rule, or caveat text beyond the sections already cited in the record's basis." } ] }, "rail_name": "SEPA Credit Transfer", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sct:MS02", "id": "MS02", "rail": "sepa-sct", "kind": "reason-code", "name": "By order of the Beneficiary", "group": "authorization", "summary": "The Beneficiary refused the transfer when it was presented, so the Beneficiary PSP returns it.", "triggers": [ "The Beneficiary told its PSP not to accept funds from a particular account, Originator or payment scheme" ], "actions": [ "Originator to contact the Beneficiary directly about how to settle what is owed" ], "retry": { "allowed": false, "rule": "Do not send again without the Beneficiary's agreement [Inference]." }, "facts": { "return_windows": [ { "action": "return", "by": "Beneficiary PSP", "deadline": "After inter-PSP settlement. The Return message and the funds go to the Originator PSP through the CSM no later than 3 Banking Business Days after the Settlement Date" } ], "applies_to": "SCT" }, "caveat": "An SCT return is for a transfer the Beneficiary PSP cannot credit. A Beneficiary who has already been credited and wants to give the money back must send a new SCT, not a return (section 4.3.2.2).", "related": [ "sepa-sct:MS03", "sepa-sct:CUST", "sepa-sct:AG01", "sepa-sct:AC06" ], "basis": { "sources": "EPC135-18 v6.0 section 3, entry for MS02 (ISO name, rulebook reason, R-transaction types, use cases, root causes, suggested action); EPC125-05 2025 v1.1 sections 4.3.2.2, CT-01.04R and 4.6.1 AT-R004, AT-R005 (return: Beneficiary PSP, after settlement, message and funds within 3 Banking Business Days after the Settlement Date); EPC125-05 2025 v1.1 chapter 7 (a Banking Business Day is a T2 day).", "confidence": "high" }, "currency": { "effective_since": "2025-10-05", "effective_note": "EPC125-05 2025 v1.1 was issued and took effect on 2025-10-05; v1.1 changed only the date for the unstructured address phase-out, now 15 November 2026. EPC135-18 v6.0, published 2024-11-28, is taken to be the current SCT reason code guidance and to cover the 2025 rulebook [Unverified]. The next SCT rulebook is due for publication in November 2026 [Unverified].", "source_edition": "EPC135-18 v6.0; EPC125-05 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-09/EPC125-05%202025%20SCT%20Rulebook%20version%201.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC135-18 v6.0 Guidance on Reason Codes for SCT R-transactions and EPC125-05 2025 v1.1 SCT Rulebook", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms MS02 (By order of the Beneficiary) as a valid SCT R-transaction reason code against EPC135-18 v6.0 section 3 (ISO definition, rulebook reason, and R-transaction type list match the record). Confirms: return sent by the Beneficiary PSP within 3 Banking Business Days after the Settlement Date (EPC125-05 section 4.3.2.2, CT-01.04R). Does not address the triggers, actions, retry rule, or caveat text beyond the sections already cited in the record's basis." } ] }, "rail_name": "SEPA Credit Transfer", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sct:MS03", "id": "MS03", "rail": "sepa-sct", "kind": "reason-code", "name": "Reason not specified", "group": "administrative", "summary": "A reject or return with no stated reason, meant only for where national law bars the precise code.", "triggers": [ "National law, such as data protection law, bars AC04, RR01, RR02, RR03 or RR04, and also MD07 under the guidance" ], "actions": [ "Originator to contact the Beneficiary directly about how to settle what is owed", "Treat MS03 as possibly standing for a closed account, a deceased Beneficiary or a regulatory reason [Inference]" ], "retry": { "allowed": false, "rule": "Do not send again until the Beneficiary has confirmed where and how it can be paid [Inference]." }, "facts": { "return_windows": [ { "action": "reject", "by": "Originator PSP or CSM", "deadline": "Before inter-PSP settlement. Sent the same day where possible and no later than the next Banking Business Day (a T2 day); the CSM passes a reject to the Originator PSP no later than the next Banking Business Day after rejecting" }, { "action": "return", "by": "Beneficiary PSP", "deadline": "After inter-PSP settlement. The Return message and the funds go to the Originator PSP through the CSM no later than 3 Banking Business Days after the Settlement Date" } ], "applies_to": "SCT" }, "caveat": "The guidance asks participants to limit MS03 and to pick a precise code where the law allows. MS03 is not a substitute in a negative answer to a claim of non-receipt; RR04 must be given there, inside the negative answer that carries code RJNR.", "related": [ "sepa-sct:AC04", "sepa-sct:MD07", "sepa-sct:RR01", "sepa-sct:RR02", "sepa-sct:RR03", "sepa-sct:RR04" ], "basis": { "sources": "EPC135-18 v6.0 section 3, entry for MS03 (ISO name, rulebook reason, R-transaction types, use cases, root causes, suggested action); EPC125-05 2025 v1.1 sections 4.3.2.1, 4.3.2.2 CT-01.03R and 4.6.1 AT-R002, AT-R004 (reject: before inter-PSP settlement, by the Originator PSP or the CSM, same day and at the latest the next Banking Business Day); EPC125-05 2025 v1.1 sections 4.3.2.2, CT-01.04R and 4.6.1 AT-R004, AT-R005 (return: Beneficiary PSP, after settlement, message and funds within 3 Banking Business Days after the Settlement Date); EPC125-05 2025 v1.1 chapter 7 (a Banking Business Day is a T2 day).", "confidence": "high" }, "currency": { "effective_since": "2025-10-05", "effective_note": "EPC125-05 2025 v1.1 was issued and took effect on 2025-10-05; v1.1 changed only the date for the unstructured address phase-out, now 15 November 2026. EPC135-18 v6.0, published 2024-11-28, is taken to be the current SCT reason code guidance and to cover the 2025 rulebook [Unverified]. The next SCT rulebook is due for publication in November 2026 [Unverified].", "source_edition": "EPC135-18 v6.0; EPC125-05 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-09/EPC125-05%202025%20SCT%20Rulebook%20version%201.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC135-18 v6.0 Guidance on Reason Codes for SCT R-transactions and EPC125-05 2025 v1.1 SCT Rulebook", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms MS03 (Reason not specified) as a valid SCT R-transaction reason code against EPC135-18 v6.0 section 3 (ISO definition, rulebook reason, and R-transaction type list match the record). Confirms: reject sent before inter-PSP settlement, at the latest the next Banking Business Day (EPC125-05 section 4.3.2.1); return sent by the Beneficiary PSP within 3 Banking Business Days after the Settlement Date (EPC125-05 section 4.3.2.2, CT-01.04R). Does not address the triggers, actions, retry rule, or caveat text beyond the sections already cited in the record's basis." } ] }, "rail_name": "SEPA Credit Transfer", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sct:NERI", "id": "NERI", "rail": "sepa-sct", "kind": "reason-code", "name": "No ERI", "group": "technical", "summary": "The transfer is flagged as carrying Extended Remittance Information (ERI) but contains none.", "triggers": [ "An error at the Originator or in the Originator PSP's system set the ERI flag without adding ERI" ], "actions": [ "Originator to resend the instruction or file with the ERI included", "Originator PSP to check its processes and, if needed, go back to the Originator" ], "retry": { "allowed": true, "rule": "Send again with the ERI included. A new transfer is a new Credit Transfer Instruction. A rejected instruction that the Originator PSP repairs and resends is also treated as a new instruction (EPC125-05 2025 v1.1 section 4.3.2.2, CT-01.03R)." }, "facts": { "return_windows": [ { "action": "reject", "by": "Not stated by the EPC; [Inference] the Originator PSP or the CSM, the parties the rulebook lets reject an SCT", "deadline": "Not stated for this code. [Inference] The general SCT reject timing applies: before inter-PSP settlement, the same day where possible and no later than the next Banking Business Day (a T2 day); a CSM passes a reject to the Originator PSP no later than the next Banking Business Day after rejecting" } ], "applies_to": "SCT" }, "caveat": "NERI comes from the guidance, which lists it as a reject only (EPC135-18 v6.0 section 3). The rulebook's reject reasons for the Originator PSP or the CSM (EPC125-05 2025 v1.1 section 4.6.1, AT-R004) have no entry that clearly matches this case, and neither text says which of those reasons NERI stands for, who sends it, or when [Unverified]. The sender and deadline in this record are the general reject pattern, not a stated rule for this code [Inference]. The ERI Option rules themselves are in ANNEX V.", "related": [ "sepa-sct:CERI", "sepa-sct:ERIN" ], "basis": { "sources": "EPC135-18 v6.0 section 3, entry for NERI (ISO name, rulebook reason, R-transaction types, use cases, root causes, suggested action); EPC125-05 2025 v1.1 sections 4.3.2.1, 4.3.2.2 CT-01.03R and 4.6.1 AT-R002, AT-R004 (reject: before inter-PSP settlement, by the Originator PSP or the CSM, same day and at the latest the next Banking Business Day); EPC125-05 2025 v1.1 sections 0.5.3 and 2.7 and ANNEX V section 4 'ERI Processing' (ERI Option participation, reject or return of ERI sent to a non-participant); EPC125-05 2025 v1.1 chapter 7 (a Banking Business Day is a T2 day).", "confidence": "medium" }, "currency": { "effective_since": "2025-10-05", "effective_note": "EPC125-05 2025 v1.1 was issued and took effect on 2025-10-05; v1.1 changed only the date for the unstructured address phase-out, now 15 November 2026. EPC135-18 v6.0, published 2024-11-28, is taken to be the current SCT reason code guidance and to cover the 2025 rulebook [Unverified]. The next SCT rulebook is due for publication in November 2026 [Unverified].", "source_edition": "EPC135-18 v6.0; EPC125-05 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-09/EPC125-05%202025%20SCT%20Rulebook%20version%201.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC135-18 v6.0 Guidance on Reason Codes for SCT R-transactions and EPC125-05 2025 v1.1 SCT Rulebook", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17c", "notes": "Confirms NERI (No ERI) as a reject-only code with the use case and root cause matching EPC135-18 v6.0 section 3, a message flagged for ERI but containing none. Confirms the general SCT reject timing and the new-instruction treatment of a repaired and resent reject, EPC125-05 2025 v1.1 section 4.3.2.1 and CT-01.03R. Confirms the AT-R004 reject reasons list has no entry that clearly matches this case. Does not name who sends NERI or when; the record correctly labels the sender and deadline as the general reject pattern, not a stated rule for this code." } ] }, "rail_name": "SEPA Credit Transfer", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sct:NOAS", "id": "NOAS", "rail": "sepa-sct", "kind": "reason-code", "name": "No response from the Beneficiary", "group": "authorization", "summary": "Negative answer to a recall or a request for recall: the Beneficiary did not answer, or could not be reached, within the 15 Banking Business Days.", "triggers": [ "The Beneficiary PSP cannot reach the Beneficiary", "The Beneficiary does not answer its PSP's request for authority to pay the funds back" ], "actions": [ "Originator (and the Originator PSP where the Recall was for its own error) to contact the Beneficiary directly and seek the funds outside the scheme's Recall and RFRO procedures" ], "retry": { "allowed": false, "rule": "No. After the Beneficiary PSP has answered, the Originator PSP may not send another Recall or RFRO for the same transfer (EPC125-05 2025 v1.1 sections 4.3.2.3 and 4.3.2.4). Any further recovery happens outside the scheme." }, "facts": { "return_windows": [ { "action": "negative answer to a recall", "by": "Beneficiary PSP", "deadline": "Within 15 Banking Business Days after receiving the Recall" }, { "action": "negative answer to a request for recall by the originator", "by": "Beneficiary PSP", "deadline": "Within 15 Banking Business Days after receiving the request" } ], "applies_to": "SCT" }, "caveat": "The Beneficiary PSP must send this answer if the Beneficiary has not responded within the 15 Banking Business Days after receipt; it may not simply stay silent (sections 4.3.2.3 and 4.3.2.4, Step 3).", "related": [ "sepa-sct:CUST", "sepa-sct:AM04", "sepa-sct:LEGL", "sepa-sct:FOCR" ], "basis": { "sources": "EPC135-18 v6.0 section 3, entry for NOAS (ISO name, rulebook reason, R-transaction types, use cases, root causes, suggested action); EPC125-05 2025 v1.1 section 4.3.2.3, CT-02.03, CT-02.03R, CT-02-04 and 4.5.6 DS-06, 4.6.1 AT-R054 to AT-R057 (response to a Recall: Beneficiary PSP, within 15 Banking Business Days of receipt); EPC125-05 2025 v1.1 section 4.3.2.4, Steps 3, 4A, 4B and 4C and 4.5.8 DS-08, 4.6.1 AT-R074 to AT-R078 (response to an RFRO: Beneficiary PSP, within 15 Banking Business Days of receipt); EPC125-05 2025 v1.1 chapter 7 (a Banking Business Day is a T2 day).", "confidence": "high" }, "currency": { "effective_since": "2025-10-05", "effective_note": "EPC125-05 2025 v1.1 was issued and took effect on 2025-10-05; v1.1 changed only the date for the unstructured address phase-out, now 15 November 2026. EPC135-18 v6.0, published 2024-11-28, is taken to be the current SCT reason code guidance and to cover the 2025 rulebook [Unverified]. The next SCT rulebook is due for publication in November 2026 [Unverified].", "source_edition": "EPC135-18 v6.0; EPC125-05 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-09/EPC125-05%202025%20SCT%20Rulebook%20version%201.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC135-18 v6.0 Guidance on Reason Codes for SCT R-transactions and EPC125-05 2025 v1.1 SCT Rulebook", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms NOAS (No response from the Beneficiary) as a valid SCT R-transaction reason code against EPC135-18 v6.0 section 3 (ISO definition, rulebook reason, and R-transaction type list match the record). Confirms: Beneficiary PSP's answer to a Recall within 15 Banking Business Days of receipt (EPC125-05 section 4.3.2.3); Beneficiary PSP's answer to an RFRO within 15 Banking Business Days of receipt (EPC125-05 section 4.3.2.4). Does not address the triggers, actions, retry rule, or caveat text beyond the sections already cited in the record's basis." } ] }, "rail_name": "SEPA Credit Transfer", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sct:NOOR", "id": "NOOR", "rail": "sepa-sct", "kind": "reason-code", "name": "Original transfer never received", "group": "administrative", "summary": "The Beneficiary PSP, or the Beneficiary, says it never received the transfer that a recall, request for recall or claim of non-receipt refers to.", "triggers": [ "A Recall or RFRO went to the wrong Beneficiary PSP or Beneficiary", "The Beneficiary PSP has no record of receiving the transfer (claim of non-receipt)" ], "actions": [ "Originator PSP to send the Recall, RFRO or inquiry to the correct Beneficiary PSP or Beneficiary", "On a claim of non-receipt, trace the transfer through the Originator PSP and the CSM [Inference]" ], "retry": { "allowed": true, "rule": "The guidance suggests addressing the request to the correct Beneficiary PSP. The rulebook allows one Recall or RFRO per transfer; how that limit applies when the first went to the wrong PSP is not stated [Unverified]." }, "facts": { "return_windows": [ { "action": "negative answer to a recall", "by": "Beneficiary PSP", "deadline": "Within 15 Banking Business Days after receiving the Recall" }, { "action": "negative answer to a request for recall by the originator", "by": "Beneficiary PSP", "deadline": "Within 15 Banking Business Days after receiving the request" }, { "action": "negative answer to an inquiry (claim of non-receipt)", "by": "Beneficiary PSP", "deadline": "Within 10 Banking Business Days after receiving the inquiry" } ], "applies_to": "SCT" }, "caveat": "On a claim of non-receipt, NOOR sits inside a negative answer that carries RJNR. The rulebook covers this answer through AT-Q004.", "related": [ "sepa-sct:RJNR", "sepa-sct:ARJT", "sepa-sct:ARDT", "sepa-sct:RNPR" ], "basis": { "sources": "EPC135-18 v6.0 section 3, entry for NOOR (ISO name, rulebook reason, R-transaction types, use cases, root causes, suggested action); EPC125-05 2025 v1.1 section 4.3.2.3, CT-02.03, CT-02.03R, CT-02-04 and 4.5.6 DS-06, 4.6.1 AT-R054 to AT-R057 (response to a Recall: Beneficiary PSP, within 15 Banking Business Days of receipt); EPC125-05 2025 v1.1 section 4.3.2.4, Steps 3, 4A, 4B and 4C and 4.5.8 DS-08, 4.6.1 AT-R074 to AT-R078 (response to an RFRO: Beneficiary PSP, within 15 Banking Business Days of receipt); EPC125-05 2025 v1.1 sections 4.4.1 and 4.4.2 and 4.5.10 DS-10 (SCT inquiry: debit date within 13 months before the Originator submits it; Beneficiary PSP answers within 10 Banking Business Days); EPC125-05 2025 v1.1 section 4.6.1 AT-Q004; EPC125-05 2025 v1.1 chapter 7 (a Banking Business Day is a T2 day).", "confidence": "high" }, "currency": { "effective_since": "2025-10-05", "effective_note": "EPC125-05 2025 v1.1 was issued and took effect on 2025-10-05; v1.1 changed only the date for the unstructured address phase-out, now 15 November 2026. EPC135-18 v6.0, published 2024-11-28, is taken to be the current SCT reason code guidance and to cover the 2025 rulebook [Unverified]. The next SCT rulebook is due for publication in November 2026 [Unverified].", "source_edition": "EPC135-18 v6.0; EPC125-05 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-09/EPC125-05%202025%20SCT%20Rulebook%20version%201.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC135-18 v6.0 Guidance on Reason Codes for SCT R-transactions and EPC125-05 2025 v1.1 SCT Rulebook", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms NOOR (Original transfer never received) as a valid SCT R-transaction reason code against EPC135-18 v6.0 section 3 (ISO definition, rulebook reason, and R-transaction type list match the record). Confirms: Beneficiary PSP's answer to a Recall within 15 Banking Business Days of receipt (EPC125-05 section 4.3.2.3); Beneficiary PSP's answer to an RFRO within 15 Banking Business Days of receipt (EPC125-05 section 4.3.2.4); Beneficiary PSP's answer to an SCT inquiry (claim of non-receipt) within 10 Banking Business Days of receipt (EPC125-05 section 4.4.2). Does not address the triggers, actions, retry rule, or caveat text beyond the sections already cited in the record's basis." } ] }, "rail_name": "SEPA Credit Transfer", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sct:RC01", "id": "RC01", "rail": "sepa-sct", "kind": "reason-code", "name": "PSP identifier incorrect", "group": "technical", "summary": "The BIC in the message is not correct or does not exist.", "triggers": [ "The Originator gave an incomplete BIC (8 characters instead of 11) for a transfer involving a non-EEA SEPA country", "The BIC in the inter-PSP message is not in the CSM's or the Beneficiary PSP's BIC directory" ], "actions": [ "Originator to ask the Beneficiary for the correct BIC where a non-EEA SEPA country is involved", "Originator PSP to put the correct and complete Beneficiary PSP BIC in the inter-PSP message" ], "retry": { "allowed": true, "rule": "Send again with the correct BIC. A new transfer is a new Credit Transfer Instruction. A rejected instruction that the Originator PSP repairs and resends is also treated as a new instruction (EPC125-05 2025 v1.1 section 4.3.2.2, CT-01.03R)." }, "facts": { "return_windows": [ { "action": "reject", "by": "Originator PSP or CSM", "deadline": "Before inter-PSP settlement. Sent the same day where possible and no later than the next Banking Business Day (a T2 day); the CSM passes a reject to the Originator PSP no later than the next Banking Business Day after rejecting" }, { "action": "return", "by": "Beneficiary PSP", "deadline": "After inter-PSP settlement. The Return message and the funds go to the Originator PSP through the CSM no later than 3 Banking Business Days after the Settlement Date" } ], "applies_to": "SCT" }, "caveat": "The Originator needs to give a BIC only where the Originator PSP asks for it and at least one of the two PSPs is in a non-EEA SEPA country or territory; the BIC stays mandatory between PSPs (AT-C002, DS-01 remarks).", "related": [ "sepa-sct:CNOR", "sepa-sct:DNOR", "sepa-sct:AC01", "sepa-sct:AG02" ], "basis": { "sources": "EPC135-18 v6.0 section 3, entry for RC01 (ISO name, rulebook reason, R-transaction types, use cases, root causes, suggested action); EPC125-05 2025 v1.1 sections 4.3.2.1, 4.3.2.2 CT-01.03R and 4.6.1 AT-R002, AT-R004 (reject: before inter-PSP settlement, by the Originator PSP or the CSM, same day and at the latest the next Banking Business Day); EPC125-05 2025 v1.1 sections 4.3.2.2, CT-01.04R and 4.6.1 AT-R004, AT-R005 (return: Beneficiary PSP, after settlement, message and funds within 3 Banking Business Days after the Settlement Date); EPC125-05 2025 v1.1 sections 4.5.1 DS-01 remarks, 4.6.1 AT-C002 and 5.7 (BIC requirements); EPC125-05 2025 v1.1 chapter 7 (a Banking Business Day is a T2 day).", "confidence": "high" }, "currency": { "effective_since": "2025-10-05", "effective_note": "EPC125-05 2025 v1.1 was issued and took effect on 2025-10-05; v1.1 changed only the date for the unstructured address phase-out, now 15 November 2026. EPC135-18 v6.0, published 2024-11-28, is taken to be the current SCT reason code guidance and to cover the 2025 rulebook [Unverified]. The next SCT rulebook is due for publication in November 2026 [Unverified].", "source_edition": "EPC135-18 v6.0; EPC125-05 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-09/EPC125-05%202025%20SCT%20Rulebook%20version%201.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC135-18 v6.0 Guidance on Reason Codes for SCT R-transactions and EPC125-05 2025 v1.1 SCT Rulebook", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms RC01 (PSP identifier incorrect) as a valid SCT R-transaction reason code against EPC135-18 v6.0 section 3 (ISO definition, rulebook reason, and R-transaction type list match the record). Confirms: reject sent before inter-PSP settlement, at the latest the next Banking Business Day (EPC125-05 section 4.3.2.1); return sent by the Beneficiary PSP within 3 Banking Business Days after the Settlement Date (EPC125-05 section 4.3.2.2, CT-01.04R). Does not address the triggers, actions, retry rule, or caveat text beyond the sections already cited in the record's basis." } ] }, "rail_name": "SEPA Credit Transfer", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sct:RJNR", "id": "RJNR", "rail": "sepa-sct", "kind": "reason-code", "name": "Rejected claim of non-receipt", "group": "administrative", "summary": "Negative answer to a claim of non-receipt. It must come with one of five more precise codes: NOOR, RNPR, ARJT, ARDT or RR04.", "triggers": [ "The transfer was never received (NOOR)", "It was received but could not be processed (RNPR)", "It was already rejected (ARJT)", "It was already returned (ARDT)", "A regulatory reason stopped it (RR04)" ], "actions": [ "Read the accompanying code and follow the action for that code" ], "retry": { "allowed": false, "rule": "Not applicable: this is a final answer to the inquiry. See the accompanying code for what to do next." }, "facts": { "return_windows": [ { "action": "negative answer to an inquiry (claim of non-receipt)", "by": "Beneficiary PSP", "deadline": "Within 10 Banking Business Days after receiving the inquiry" } ], "applies_to": "SCT" }, "caveat": "MS03 cannot replace RR04 inside this answer (guidance entry for RR04). The rulebook describes the content of the answer in AT-Q004.", "related": [ "sepa-sct:NOOR", "sepa-sct:RNPR", "sepa-sct:ARJT", "sepa-sct:ARDT", "sepa-sct:RR04", "sepa-sct:ACNR" ], "basis": { "sources": "EPC135-18 v6.0 section 3, entry for RJNR (ISO name, rulebook reason, R-transaction types, use cases, root causes, suggested action); EPC125-05 2025 v1.1 sections 4.4.1 and 4.4.2 and 4.5.10 DS-10 (SCT inquiry: debit date within 13 months before the Originator submits it; Beneficiary PSP answers within 10 Banking Business Days); EPC125-05 2025 v1.1 section 4.6.1 AT-Q004; EPC125-05 2025 v1.1 chapter 7 (a Banking Business Day is a T2 day).", "confidence": "high" }, "currency": { "effective_since": "2025-10-05", "effective_note": "EPC125-05 2025 v1.1 was issued and took effect on 2025-10-05; v1.1 changed only the date for the unstructured address phase-out, now 15 November 2026. EPC135-18 v6.0, published 2024-11-28, is taken to be the current SCT reason code guidance and to cover the 2025 rulebook [Unverified]. The next SCT rulebook is due for publication in November 2026 [Unverified].", "source_edition": "EPC135-18 v6.0; EPC125-05 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-09/EPC125-05%202025%20SCT%20Rulebook%20version%201.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC135-18 v6.0 Guidance on Reason Codes for SCT R-transactions and EPC125-05 2025 v1.1 SCT Rulebook", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms RJNR (Rejected claim of non-receipt) as a valid SCT R-transaction reason code against EPC135-18 v6.0 section 3 (ISO definition, rulebook reason, and R-transaction type list match the record). Confirms: Beneficiary PSP's answer to an SCT inquiry (claim of non-receipt) within 10 Banking Business Days of receipt (EPC125-05 section 4.4.2). Does not address the triggers, actions, retry rule, or caveat text beyond the sections already cited in the record's basis." } ] }, "rail_name": "SEPA Credit Transfer", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sct:RJVA", "id": "RJVA", "rail": "sepa-sct", "kind": "reason-code", "name": "Rejected value date adjustment", "group": "administrative", "summary": "Negative answer to a claim for value date correction because the claim is out of scope in time.", "triggers": [ "The debit date of the transfer is more than 13 months before the inquiry was submitted", "The transfer's debit date is before 17 November 2019, when the SCT inquiry procedure took effect" ], "actions": [ "No further action within the scheme" ], "retry": { "allowed": false, "rule": "No. The claim falls outside the inquiry's time limits (section 4.4.1)." }, "facts": { "return_windows": [ { "action": "negative answer to an inquiry (claim for value date correction)", "by": "Beneficiary PSP", "deadline": "Within 10 Banking Business Days after receiving the inquiry" } ], "applies_to": "SCT" }, "caveat": "The 13-month limit is counted back from the date the Originator submits the inquiry to the Originator PSP (section 4.4.1).", "related": [ "sepa-sct:CVAA", "sepa-sct:ACVA", "sepa-sct:MODI" ], "basis": { "sources": "EPC135-18 v6.0 section 3, entry for RJVA (ISO name, rulebook reason, R-transaction types, use cases, root causes, suggested action); EPC125-05 2025 v1.1 sections 4.4.1 and 4.4.2 and 4.5.10 DS-10 (SCT inquiry: debit date within 13 months before the Originator submits it; Beneficiary PSP answers within 10 Banking Business Days); EPC125-05 2025 v1.1 chapter 7 (a Banking Business Day is a T2 day).", "confidence": "high" }, "currency": { "effective_since": "2025-10-05", "effective_note": "EPC125-05 2025 v1.1 was issued and took effect on 2025-10-05; v1.1 changed only the date for the unstructured address phase-out, now 15 November 2026. EPC135-18 v6.0, published 2024-11-28, is taken to be the current SCT reason code guidance and to cover the 2025 rulebook [Unverified]. The next SCT rulebook is due for publication in November 2026 [Unverified].", "source_edition": "EPC135-18 v6.0; EPC125-05 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-09/EPC125-05%202025%20SCT%20Rulebook%20version%201.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC135-18 v6.0 Guidance on Reason Codes for SCT R-transactions and EPC125-05 2025 v1.1 SCT Rulebook", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms RJVA (Rejected value date adjustment) as a valid SCT R-transaction reason code against EPC135-18 v6.0 section 3 (ISO definition, rulebook reason, and R-transaction type list match the record). Confirms: Beneficiary PSP's answer to an SCT inquiry (claim for value date correction) within 10 Banking Business Days of receipt (EPC125-05 section 4.4.2). Does not address the triggers, actions, retry rule, or caveat text beyond the sections already cited in the record's basis." } ] }, "rail_name": "SEPA Credit Transfer", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sct:RNPR", "id": "RNPR", "rail": "sepa-sct", "kind": "reason-code", "name": "Original transfer received but not processable", "group": "administrative", "summary": "Negative answer to a claim of non-receipt: the Beneficiary PSP received the transfer but cannot process it for now, for a reason other than a reject, a return or a regulatory reason.", "triggers": [ "The Beneficiary PSP cannot process the transfer at this time, for a reason not covered by ARJT, ARDT or RR04" ], "actions": [ "Originator PSP and Beneficiary PSP may contact each other to resolve what stops execution" ], "retry": { "allowed": false, "rule": "Not applicable to the inquiry. Resolution happens bilaterally between the PSPs." }, "facts": { "return_windows": [ { "action": "negative answer to an inquiry (claim of non-receipt)", "by": "Beneficiary PSP", "deadline": "Within 10 Banking Business Days after receiving the inquiry" } ], "applies_to": "SCT" }, "caveat": "RNPR sits inside a negative answer that carries RJNR. The texts read do not say what happens to the funds while the transfer stays unprocessed [Unverified].", "related": [ "sepa-sct:RJNR", "sepa-sct:ARJT", "sepa-sct:ARDT", "sepa-sct:NOOR", "sepa-sct:RR04" ], "basis": { "sources": "EPC135-18 v6.0 section 3, entry for RNPR (ISO name, rulebook reason, R-transaction types, use cases, root causes, suggested action); EPC125-05 2025 v1.1 sections 4.4.1 and 4.4.2 and 4.5.10 DS-10 (SCT inquiry: debit date within 13 months before the Originator submits it; Beneficiary PSP answers within 10 Banking Business Days); EPC125-05 2025 v1.1 section 4.6.1 AT-Q004; EPC125-05 2025 v1.1 chapter 7 (a Banking Business Day is a T2 day).", "confidence": "medium" }, "currency": { "effective_since": "2025-10-05", "effective_note": "EPC125-05 2025 v1.1 was issued and took effect on 2025-10-05; v1.1 changed only the date for the unstructured address phase-out, now 15 November 2026. EPC135-18 v6.0, published 2024-11-28, is taken to be the current SCT reason code guidance and to cover the 2025 rulebook [Unverified]. The next SCT rulebook is due for publication in November 2026 [Unverified].", "source_edition": "EPC135-18 v6.0; EPC125-05 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-09/EPC125-05%202025%20SCT%20Rulebook%20version%201.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC135-18 v6.0 Guidance on Reason Codes for SCT R-transactions and EPC125-05 2025 v1.1 SCT Rulebook", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms RNPR (Original transfer received but not processable) as a valid SCT R-transaction reason code against EPC135-18 v6.0 section 3 (ISO definition, rulebook reason, and R-transaction type list match the record). Confirms: Beneficiary PSP's answer to an SCT inquiry (claim of non-receipt) within 10 Banking Business Days of receipt (EPC125-05 section 4.4.2). Does not address the triggers, actions, retry rule, or caveat text beyond the sections already cited in the record's basis." } ] }, "rail_name": "SEPA Credit Transfer", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sct:RR01", "id": "RR01", "rail": "sepa-sct", "kind": "reason-code", "name": "Missing Originator account or identification (regulatory reason)", "group": "administrative", "summary": "The Originator's account details or unique identification, needed for regulatory reasons, are missing or insufficient.", "triggers": [ "The transfer lacks the Originator account details required by regulation" ], "actions": [ "Originator PSP to check the transfer and, if needed, repair it by completing the Originator account" ], "retry": { "allowed": true, "rule": "Send again with the Originator account completed. A new transfer is a new Credit Transfer Instruction. A rejected instruction that the Originator PSP repairs and resends is also treated as a new instruction (EPC125-05 2025 v1.1 section 4.3.2.2, CT-01.03R)." }, "facts": { "return_windows": [ { "action": "reject", "by": "Originator PSP or CSM", "deadline": "Before inter-PSP settlement. Sent the same day where possible and no later than the next Banking Business Day (a T2 day); the CSM passes a reject to the Originator PSP no later than the next Banking Business Day after rejecting" }, { "action": "return", "by": "Beneficiary PSP", "deadline": "After inter-PSP settlement. The Return message and the funds go to the Originator PSP through the CSM no later than 3 Banking Business Days after the Settlement Date" } ], "applies_to": "SCT" }, "caveat": "Under the guidance entry for MS03, national law in some countries bars RR01, and MS03 is used instead. The texts read do not name the regulation behind RR01 to RR04 [Unverified].", "related": [ "sepa-sct:RR02", "sepa-sct:RR03", "sepa-sct:RR04", "sepa-sct:MS03" ], "basis": { "sources": "EPC135-18 v6.0 section 3, entry for RR01 (ISO name, rulebook reason, R-transaction types, use cases, root causes, suggested action); EPC135-18 v6.0 section 3, entry for MS03 (MS03 as the substitute); EPC125-05 2025 v1.1 sections 4.3.2.1, 4.3.2.2 CT-01.03R and 4.6.1 AT-R002, AT-R004 (reject: before inter-PSP settlement, by the Originator PSP or the CSM, same day and at the latest the next Banking Business Day); EPC125-05 2025 v1.1 sections 4.3.2.2, CT-01.04R and 4.6.1 AT-R004, AT-R005 (return: Beneficiary PSP, after settlement, message and funds within 3 Banking Business Days after the Settlement Date); EPC125-05 2025 v1.1 chapter 7 (a Banking Business Day is a T2 day).", "confidence": "high" }, "currency": { "effective_since": "2025-10-05", "effective_note": "EPC125-05 2025 v1.1 was issued and took effect on 2025-10-05; v1.1 changed only the date for the unstructured address phase-out, now 15 November 2026. EPC135-18 v6.0, published 2024-11-28, is taken to be the current SCT reason code guidance and to cover the 2025 rulebook [Unverified]. The next SCT rulebook is due for publication in November 2026 [Unverified].", "source_edition": "EPC135-18 v6.0; EPC125-05 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-09/EPC125-05%202025%20SCT%20Rulebook%20version%201.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC135-18 v6.0 Guidance on Reason Codes for SCT R-transactions and EPC125-05 2025 v1.1 SCT Rulebook", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms RR01 (Missing Originator account or identification (regulatory reason)) as a valid SCT R-transaction reason code against EPC135-18 v6.0 section 3 (ISO definition, rulebook reason, and R-transaction type list match the record). Confirms: reject sent before inter-PSP settlement, at the latest the next Banking Business Day (EPC125-05 section 4.3.2.1); return sent by the Beneficiary PSP within 3 Banking Business Days after the Settlement Date (EPC125-05 section 4.3.2.2, CT-01.04R). Does not address the triggers, actions, retry rule, or caveat text beyond the sections already cited in the record's basis." } ] }, "rail_name": "SEPA Credit Transfer", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sct:RR02", "id": "RR02", "rail": "sepa-sct", "kind": "reason-code", "name": "Missing Originator name or address (regulatory reason)", "group": "administrative", "summary": "The Originator's name, or an address where one is required, is missing, insufficient or in a format no longer allowed.", "triggers": [ "The Originator's name is missing", "The Originator's address is missing on a transfer where either PSP is in a non-EEA SEPA country or territory", "The Originator's address format is invalid or no longer allowed, for example an unstructured address after the November 2026 phase-out" ], "actions": [ "Originator PSP to repair the transfer by completing the Originator's name or address", "Use a structured or hybrid address; the rulebook bars unstructured addresses from 15 November 2026 (AT-P005)" ], "retry": { "allowed": true, "rule": "Send again with the Originator data completed. A new transfer is a new Credit Transfer Instruction. A rejected instruction that the Originator PSP repairs and resends is also treated as a new instruction (EPC125-05 2025 v1.1 section 4.3.2.2, CT-01.03R)." }, "facts": { "return_windows": [ { "action": "reject", "by": "Originator PSP or CSM", "deadline": "Before inter-PSP settlement. Sent the same day where possible and no later than the next Banking Business Day (a T2 day); the CSM passes a reject to the Originator PSP no later than the next Banking Business Day after rejecting" }, { "action": "return", "by": "Beneficiary PSP", "deadline": "After inter-PSP settlement. The Return message and the funds go to the Originator PSP through the CSM no later than 3 Banking Business Days after the Settlement Date" } ], "applies_to": "SCT" }, "caveat": "Data protection law in certain SEPA countries bars this code, and MS03 may be used instead (EPC135-18 v6.0 section 3). The guidance does not name the countries. The address is optional on transfers between EEA PSPs. Guidance v6.0 says only 'November 2026' for the phase-out; rulebook v1.1 fixes 15 November 2026.", "related": [ "sepa-sct:RR01", "sepa-sct:RR03", "sepa-sct:RR04", "sepa-sct:MS03" ], "basis": { "sources": "EPC135-18 v6.0 section 3, entry for RR02 (ISO name, rulebook reason, R-transaction types, use cases, root causes, suggested action); EPC125-05 2025 v1.1 sections 4.3.2.1, 4.3.2.2 CT-01.03R and 4.6.1 AT-R002, AT-R004 (reject: before inter-PSP settlement, by the Originator PSP or the CSM, same day and at the latest the next Banking Business Day); EPC125-05 2025 v1.1 sections 4.3.2.2, CT-01.04R and 4.6.1 AT-R004, AT-R005 (return: Beneficiary PSP, after settlement, message and funds within 3 Banking Business Days after the Settlement Date); EPC125-05 2025 v1.1 sections 4.5.2 DS-02 and 4.6.1 AT-P005, AT-E004 (Originator address mandatory only when either PSP is in a non-EEA SEPA country or territory; unstructured addresses no longer allowed from 15 November 2026); EPC125-05 2025 v1.1 chapter 7 (a Banking Business Day is a T2 day).", "confidence": "high" }, "currency": { "effective_since": "2025-10-05", "effective_note": "EPC125-05 2025 v1.1 was issued and took effect on 2025-10-05; v1.1 changed only the date for the unstructured address phase-out, now 15 November 2026. EPC135-18 v6.0, published 2024-11-28, is taken to be the current SCT reason code guidance and to cover the 2025 rulebook [Unverified]. The next SCT rulebook is due for publication in November 2026 [Unverified].", "source_edition": "EPC135-18 v6.0; EPC125-05 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-09/EPC125-05%202025%20SCT%20Rulebook%20version%201.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC135-18 v6.0 Guidance on Reason Codes for SCT R-transactions and EPC125-05 2025 v1.1 SCT Rulebook", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms RR02 (Missing Originator name or address (regulatory reason)) as a valid SCT R-transaction reason code against EPC135-18 v6.0 section 3 (ISO definition, rulebook reason, and R-transaction type list match the record). Confirms: reject sent before inter-PSP settlement, at the latest the next Banking Business Day (EPC125-05 section 4.3.2.1); return sent by the Beneficiary PSP within 3 Banking Business Days after the Settlement Date (EPC125-05 section 4.3.2.2, CT-01.04R). Does not address the triggers, actions, retry rule, or caveat text beyond the sections already cited in the record's basis." } ] }, "rail_name": "SEPA Credit Transfer", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "jurisdiction", "label": "the country", "needs": "which country the payment or the account is in", "detail": "Data protection law in certain SEPA countries bars this code, and MS03 may be used instead (EPC135-18 v6.0 section 3).", "from": "caveat" } ] }, { "uid": "sepa-sct:RR03", "id": "RR03", "rail": "sepa-sct", "kind": "reason-code", "name": "Missing Beneficiary name or address (regulatory reason)", "group": "administrative", "summary": "The Beneficiary's name is missing or insufficient, or the Beneficiary address given is in a format no longer allowed.", "triggers": [ "The Beneficiary's name is missing", "The Beneficiary's address format is invalid or no longer allowed, for example an unstructured address after the November 2026 phase-out" ], "actions": [ "Originator PSP to repair the transfer by completing the Beneficiary's name", "Use a structured or hybrid address if one is given; the rulebook bars unstructured addresses from 15 November 2026 (AT-E004)" ], "retry": { "allowed": true, "rule": "Send again with the Beneficiary data completed. A new transfer is a new Credit Transfer Instruction. A rejected instruction that the Originator PSP repairs and resends is also treated as a new instruction (EPC125-05 2025 v1.1 section 4.3.2.2, CT-01.03R)." }, "facts": { "return_windows": [ { "action": "reject", "by": "Originator PSP or CSM", "deadline": "Before inter-PSP settlement. Sent the same day where possible and no later than the next Banking Business Day (a T2 day); the CSM passes a reject to the Originator PSP no later than the next Banking Business Day after rejecting" }, { "action": "return", "by": "Beneficiary PSP", "deadline": "After inter-PSP settlement. The Return message and the funds go to the Originator PSP through the CSM no later than 3 Banking Business Days after the Settlement Date" } ], "applies_to": "SCT" }, "caveat": "Data protection law in certain SEPA countries bars this code, and MS03 may be used instead (EPC135-18 v6.0 section 3). The guidance does not name the countries. The Beneficiary address itself is optional (AT-E004). For an address the Beneficiary PSP needs for processing rather than regulation, BE04 applies.", "related": [ "sepa-sct:RR01", "sepa-sct:RR02", "sepa-sct:RR04", "sepa-sct:BE04", "sepa-sct:MS03" ], "basis": { "sources": "EPC135-18 v6.0 section 3, entry for RR03 (ISO name, rulebook reason, R-transaction types, use cases, root causes, suggested action); EPC125-05 2025 v1.1 sections 4.3.2.1, 4.3.2.2 CT-01.03R and 4.6.1 AT-R002, AT-R004 (reject: before inter-PSP settlement, by the Originator PSP or the CSM, same day and at the latest the next Banking Business Day); EPC125-05 2025 v1.1 sections 4.3.2.2, CT-01.04R and 4.6.1 AT-R004, AT-R005 (return: Beneficiary PSP, after settlement, message and funds within 3 Banking Business Days after the Settlement Date); EPC125-05 2025 v1.1 sections 4.5.2 DS-02 and 4.6.1 AT-P005, AT-E004 (Originator address mandatory only when either PSP is in a non-EEA SEPA country or territory; unstructured addresses no longer allowed from 15 November 2026); EPC125-05 2025 v1.1 chapter 7 (a Banking Business Day is a T2 day).", "confidence": "high" }, "currency": { "effective_since": "2025-10-05", "effective_note": "EPC125-05 2025 v1.1 was issued and took effect on 2025-10-05; v1.1 changed only the date for the unstructured address phase-out, now 15 November 2026. EPC135-18 v6.0, published 2024-11-28, is taken to be the current SCT reason code guidance and to cover the 2025 rulebook [Unverified]. The next SCT rulebook is due for publication in November 2026 [Unverified].", "source_edition": "EPC135-18 v6.0; EPC125-05 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-09/EPC125-05%202025%20SCT%20Rulebook%20version%201.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC135-18 v6.0 Guidance on Reason Codes for SCT R-transactions and EPC125-05 2025 v1.1 SCT Rulebook", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms RR03 (Missing Beneficiary name or address (regulatory reason)) as a valid SCT R-transaction reason code against EPC135-18 v6.0 section 3 (ISO definition, rulebook reason, and R-transaction type list match the record). Confirms: reject sent before inter-PSP settlement, at the latest the next Banking Business Day (EPC125-05 section 4.3.2.1); return sent by the Beneficiary PSP within 3 Banking Business Days after the Settlement Date (EPC125-05 section 4.3.2.2, CT-01.04R). Does not address the triggers, actions, retry rule, or caveat text beyond the sections already cited in the record's basis." } ] }, "rail_name": "SEPA Credit Transfer", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "jurisdiction", "label": "the country", "needs": "which country the payment or the account is in", "detail": "Data protection law in certain SEPA countries bars this code, and MS03 may be used instead (EPC135-18 v6.0 section 3).", "from": "caveat" } ] }, { "uid": "sepa-sct:RR04", "id": "RR04", "rail": "sepa-sct", "kind": "reason-code", "name": "Regulatory reason", "group": "administrative", "summary": "A regulatory reason other than those covered by RR01 to RR03, such as a possible anti-money-laundering, embargo or counter-terrorist-financing hit.", "triggers": [ "A possible hit in anti-money-laundering, embargo or counter-terrorist-financing screening", "Any other regulatory reason not covered by RR01, RR02 or RR03" ], "actions": [ "Originator to contact the Originator PSP" ], "retry": { "allowed": false, "rule": "Do not send again until the Originator PSP has established what the regulatory issue is [Inference]." }, "facts": { "return_windows": [ { "action": "reject", "by": "Originator PSP or CSM", "deadline": "Before inter-PSP settlement. Sent the same day where possible and no later than the next Banking Business Day (a T2 day); the CSM passes a reject to the Originator PSP no later than the next Banking Business Day after rejecting" }, { "action": "return", "by": "Beneficiary PSP", "deadline": "After inter-PSP settlement. The Return message and the funds go to the Originator PSP through the CSM no later than 3 Banking Business Days after the Settlement Date" }, { "action": "negative answer to an inquiry (claim of non-receipt)", "by": "Beneficiary PSP", "deadline": "Within 10 Banking Business Days after receiving the inquiry" } ], "applies_to": "SCT" }, "caveat": "Data protection law in certain SEPA countries bars this code, and MS03 may be used instead (EPC135-18 v6.0 section 3). The guidance does not name the countries. That substitution does not apply in a negative answer to a claim of non-receipt, where RR04 is one of the five codes RJNR must carry. The Beneficiary PSP credits only once anti-money-laundering and terrorist financing rules are met (section 5.8 item 8), and may state a regulatory reason in an inquiry answer only where the law lets it (AT-Q004).", "related": [ "sepa-sct:RR01", "sepa-sct:RR02", "sepa-sct:RR03", "sepa-sct:MS03", "sepa-sct:RJNR", "sepa-sct:LEGL" ], "basis": { "sources": "EPC135-18 v6.0 section 3, entry for RR04 (ISO name, rulebook reason, R-transaction types, use cases, root causes, suggested action); EPC125-05 2025 v1.1 sections 4.3.2.1, 4.3.2.2 CT-01.03R and 4.6.1 AT-R002, AT-R004 (reject: before inter-PSP settlement, by the Originator PSP or the CSM, same day and at the latest the next Banking Business Day); EPC125-05 2025 v1.1 sections 4.3.2.2, CT-01.04R and 4.6.1 AT-R004, AT-R005 (return: Beneficiary PSP, after settlement, message and funds within 3 Banking Business Days after the Settlement Date); EPC125-05 2025 v1.1 sections 4.4.1 and 4.4.2 and 4.5.10 DS-10 (SCT inquiry: debit date within 13 months before the Originator submits it; Beneficiary PSP answers within 10 Banking Business Days); EPC125-05 2025 v1.1 sections 4.6.1 AT-Q004 and 5.8 item 8; EPC125-05 2025 v1.1 chapter 7 (a Banking Business Day is a T2 day).", "confidence": "high" }, "currency": { "effective_since": "2025-10-05", "effective_note": "EPC125-05 2025 v1.1 was issued and took effect on 2025-10-05; v1.1 changed only the date for the unstructured address phase-out, now 15 November 2026. EPC135-18 v6.0, published 2024-11-28, is taken to be the current SCT reason code guidance and to cover the 2025 rulebook [Unverified]. The next SCT rulebook is due for publication in November 2026 [Unverified].", "source_edition": "EPC135-18 v6.0; EPC125-05 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-09/EPC125-05%202025%20SCT%20Rulebook%20version%201.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC135-18 v6.0 Guidance on Reason Codes for SCT R-transactions and EPC125-05 2025 v1.1 SCT Rulebook", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms RR04 (Regulatory reason) as a valid SCT R-transaction reason code against EPC135-18 v6.0 section 3 (ISO definition, rulebook reason, and R-transaction type list match the record). Confirms: reject sent before inter-PSP settlement, at the latest the next Banking Business Day (EPC125-05 section 4.3.2.1); return sent by the Beneficiary PSP within 3 Banking Business Days after the Settlement Date (EPC125-05 section 4.3.2.2, CT-01.04R); Beneficiary PSP's answer to an SCT inquiry (claim of non-receipt) within 10 Banking Business Days of receipt (EPC125-05 section 4.4.2). Does not address the triggers, actions, retry rule, or caveat text beyond the sections already cited in the record's basis." } ] }, "rail_name": "SEPA Credit Transfer", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "judgement", "label": "a sanctions check", "needs": "the outcome of sanctions, AML or KYC screening", "detail": "The Beneficiary PSP credits only once anti-money-laundering and terrorist financing rules are met (section 5.8 item 8), and may state a regulatory reason in an inquiry answer only where the law lets it (AT-Q004).", "from": "caveat" }, { "kind": "jurisdiction", "label": "the country", "needs": "which country the payment or the account is in", "detail": "Data protection law in certain SEPA countries bars this code, and MS03 may be used instead (EPC135-18 v6.0 section 3).", "from": "caveat" } ] }, { "uid": "sepa-sct:TECH", "id": "TECH", "rail": "sepa-sct", "kind": "reason-code", "name": "Technical problems resulting in erroneous transfers", "group": "technical", "summary": "Recall reason: a technical problem at the Originator or the Originator PSP produced wrong transfers, and the funds are asked back.", "triggers": [ "A technical fault in the Originator's systems when creating instructions or files", "A technical fault in the Originator PSP's SCT systems when handling instructions or converting them into inter-PSP transfers" ], "actions": [ "Originator PSP to send the Recall within 10 Banking Business Days of the execution date", "Expect FOCR with the funds, possibly less a fee, or a negative answer within 15 Banking Business Days of receipt", "Set up controls so the technical problem does not recur" ], "retry": { "allowed": false, "rule": "Only one Recall per transfer, and none after the Beneficiary PSP has answered (section 4.3.2.3). If no answer arrives in 15 Banking Business Days, the Originator PSP may send a Request for Status Update instead." }, "facts": { "return_windows": [ { "action": "recall", "by": "Originator PSP, on its own initiative or at the Originator's request", "deadline": "Sent within 10 Banking Business Days after the execution date of the original transfer. Only one Recall per transfer" }, { "action": "negative answer to a recall", "by": "Beneficiary PSP", "deadline": "Within 15 Banking Business Days after receiving the Recall" }, { "action": "positive answer to a recall", "by": "Beneficiary PSP", "deadline": "Within 15 Banking Business Days after receiving the Recall; the CSM then settles the returned amount with the Originator PSP" } ], "applies_to": "SCT" }, "caveat": "A Recall is a request, not a right: the Beneficiary PSP may answer negatively, and depending on national law or its contract may need the Beneficiary's consent to debit the account (CT-02.03). A Recall made before settlement leads to a cancellation under the CSM's own procedures.", "related": [ "sepa-sct:DUPL", "sepa-sct:FRAD", "sepa-sct:FOCR", "sepa-sct:NOAS" ], "basis": { "sources": "EPC135-18 v6.0 section 3, entry for TECH (ISO name, rulebook reason, R-transaction types, use cases, root causes, suggested action); EPC125-05 2025 v1.1 section 4.3.2.3, CT-02.00 to CT-02.07 and 4.6.1 AT-R051, AT-R052 (recall: three permitted reasons; 10 Banking Business Days, or 13 months for fraud, after the execution date; one Recall per transfer); EPC125-05 2025 v1.1 section 4.3.2.3, CT-02.03, CT-02.03R, CT-02-04 and 4.5.6 DS-06, 4.6.1 AT-R054 to AT-R057 (response to a Recall: Beneficiary PSP, within 15 Banking Business Days of receipt); EPC125-05 2025 v1.1 chapter 7 (a Banking Business Day is a T2 day).", "confidence": "high" }, "currency": { "effective_since": "2025-10-05", "effective_note": "EPC125-05 2025 v1.1 was issued and took effect on 2025-10-05; v1.1 changed only the date for the unstructured address phase-out, now 15 November 2026. EPC135-18 v6.0, published 2024-11-28, is taken to be the current SCT reason code guidance and to cover the 2025 rulebook [Unverified]. The next SCT rulebook is due for publication in November 2026 [Unverified].", "source_edition": "EPC135-18 v6.0; EPC125-05 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-09/EPC125-05%202025%20SCT%20Rulebook%20version%201.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC135-18 v6.0 Guidance on Reason Codes for SCT R-transactions and EPC125-05 2025 v1.1 SCT Rulebook", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms TECH (Technical problems resulting in erroneous transfers) as a valid SCT R-transaction reason code against EPC135-18 v6.0 section 3 (ISO definition, rulebook reason, and R-transaction type list match the record). Confirms: Recall sent by the Originator PSP within 10 Banking Business Days of the execution date (EPC125-05 section 4.3.2.3); Beneficiary PSP's answer to a Recall within 15 Banking Business Days of receipt (EPC125-05 section 4.3.2.3). Does not address the triggers, actions, retry rule, or caveat text beyond the sections already cited in the record's basis." } ] }, "rail_name": "SEPA Credit Transfer", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "jurisdiction", "label": "the country", "needs": "which country the payment or the account is in", "detail": "A Recall is a request, not a right: the Beneficiary PSP may answer negatively, and depending on national law or its contract may need the Beneficiary's consent to debit the account (CT-02.03).", "from": "caveat" } ] }, { "uid": "sepa-sct:TM01", "id": "TM01", "rail": "sepa-sct", "kind": "reason-code", "name": "File received after cut-off time", "group": "network", "summary": "The CSM did not receive the transfer or file within its cut-off time.", "triggers": [ "A connection, processing or validation problem somewhere between the Originator PSP and the CSM delayed the file" ], "actions": [ "Originator PSP to resubmit the transfers before the next cut-off time" ], "retry": { "allowed": true, "rule": "Resubmit before the next cut-off. A new transfer is a new Credit Transfer Instruction. A rejected instruction that the Originator PSP repairs and resends is also treated as a new instruction (EPC125-05 2025 v1.1 section 4.3.2.2, CT-01.03R)." }, "facts": { "return_windows": [ { "action": "reject", "by": "Originator PSP or CSM", "deadline": "Before inter-PSP settlement. Sent the same day where possible and no later than the next Banking Business Day (a T2 day); the CSM passes a reject to the Originator PSP no later than the next Banking Business Day after rejecting" } ], "applies_to": "SCT" }, "caveat": "Cut-off times are agreed between each Originator PSP and its CSM and are outside the rulebook (section 4.2.2). The reject is most likely sent by the CSM [Inference]. A late resubmission can still breach the one Banking Business Day maximum execution time, which comes from the Payment Services Directive (section 4.2.3) [Inference].", "related": [ "sepa-sct:ED05", "sepa-sct:DNOR" ], "basis": { "sources": "EPC135-18 v6.0 section 3, entry for TM01 (ISO name, rulebook reason, R-transaction types, use cases, root causes, suggested action); EPC125-05 2025 v1.1 sections 4.3.2.1, 4.3.2.2 CT-01.03R and 4.6.1 AT-R002, AT-R004 (reject: before inter-PSP settlement, by the Originator PSP or the CSM, same day and at the latest the next Banking Business Day); EPC125-05 2025 v1.1 sections 4.2.2 and 4.2.3 (cut-off times, maximum execution time); EPC125-05 2025 v1.1 chapter 7 (a Banking Business Day is a T2 day).", "confidence": "high" }, "currency": { "effective_since": "2025-10-05", "effective_note": "EPC125-05 2025 v1.1 was issued and took effect on 2025-10-05; v1.1 changed only the date for the unstructured address phase-out, now 15 November 2026. EPC135-18 v6.0, published 2024-11-28, is taken to be the current SCT reason code guidance and to cover the 2025 rulebook [Unverified]. The next SCT rulebook is due for publication in November 2026 [Unverified].", "source_edition": "EPC135-18 v6.0; EPC125-05 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-09/EPC125-05%202025%20SCT%20Rulebook%20version%201.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC135-18 v6.0 Guidance on Reason Codes for SCT R-transactions and EPC125-05 2025 v1.1 SCT Rulebook", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms TM01 (File received after cut-off time) as a valid SCT R-transaction reason code against EPC135-18 v6.0 section 3 (ISO definition, rulebook reason, and R-transaction type list match the record). Confirms: reject sent before inter-PSP settlement, at the latest the next Banking Business Day (EPC125-05 section 4.3.2.1). Does not address the triggers, actions, retry rule, or caveat text beyond the sections already cited in the record's basis." } ] }, "rail_name": "SEPA Credit Transfer", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sct-inst:AB05", "id": "AB05", "rail": "sepa-sct-inst", "kind": "reason-code", "name": "Time-out at the Beneficiary PSP", "group": "technical", "summary": "The Beneficiary PSP rejects because the SCT Inst Transaction reached it after the time-out deadline. A technical reject: nothing was credited and nothing settled.", "triggers": [ "The Beneficiary PSP receives the initial transaction after the 7-second time-out deadline, or after a shorter deadline agreed between participants", "A connection, processing or validation delay somewhere from the Originator PSP through the CSMs to the Beneficiary PSP" ], "actions": [ "Originator PSP: cancel the reservation of the amount and tell the Originator at once (CT-01.05R, CT-01.06R)", "Originator PSP: suggest the Originator try again later or use another instrument such as SCT", "Originator: agree another way to pay with the Beneficiary if the instant route keeps failing" ], "retry": { "allowed": true, "rule": "The rejected transaction is final as a failure and nothing is re-presented. The Originator may send a new SCT Inst Transaction later or use another instrument such as SCT, as the guidance suggests. The scheme sets no retry limit [Unverified]." }, "facts": { "return_windows": [ { "action": "reject for time-out (negative confirmation message)", "by": "Beneficiary PSP", "deadline": "Instantly once it holds the transaction after the 7-second time-out deadline (or a shorter agreed one); the Beneficiary PSP's CSM must pass the answer to the Originator PSP by the 9th second after the Time Stamp" } ], "applies_to": "SCT Inst" }, "caveat": "TM01 is kept for the leg between the Beneficiary PSP and its CSM and may not go to the Originator PSP; the guidance points to AB05 or AB06 instead (EPC059-18 v7.0 section 3, TM01). If no confirmation at all reaches the Originator PSP within 10 seconds of the Time Stamp, it must lift the reservation and may start a status investigation, but must keep settlement certainty until a confirmation arrives (EPC004-16 2025 v1.1 section 4.2.3 D). A positive confirmation can still arrive later; what follows is outside the scheme.", "related": [ "sepa-sct-inst:AB06", "sepa-sct-inst:TM01", "sepa-sct-inst:AG09" ], "basis": { "sources": "EPC059-18 v7.0 section 3, entry for AB05; EPC004-16 2025 v1.1 sections 4.2.3 C and D (7-second time-out, 9th second, 10-second rule), 4.3.2.1 (CT-01.08R, CT-01.11R, CT-01.12R, CT-01.13R), 4.5.3 DS-03 and 4.6.1 AT-R004 (time-out reason).", "confidence": "high" }, "currency": { "effective_since": "2025-10-05", "effective_note": "EPC004-16 2025 v1.1 was issued and took effect on 2025-10-05 (03:30 CET); v1.1 changed only the unstructured address cut-off, to 15 November 2026. EPC059-18 v7.0 was published on 2025-10-05 and applies to the SCT Inst rulebook. The next SCT Inst rulebook is due for publication in November 2026 [Unverified].", "source_edition": "EPC059-18 v7.0; EPC004-16 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-10/EPC004-16%202025%20SCT%20Instant%20Rulebook%20v1.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC059-18 v7.0 Guidance on Reason Codes for SCT Inst R-transactions and EPC004-16 2025 v1.1 SCT Inst Scheme Rulebook", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms name, trigger and reject action match EPC059-18's AB05 entry; confirms the Beneficiary PSP sends this reject and the 7-second time-out and 9-second relay deadlines against rulebook section 4.2.3 C. Does not address the retry limit, which the scheme leaves open." } ] }, "rail_name": "SEPA Instant Credit Transfer", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sct-inst:AB06", "id": "AB06", "rail": "sepa-sct-inst", "kind": "reason-code", "name": "Time-out at a CSM (instructed agent)", "group": "technical", "summary": "A CSM rejects on time-out: either it received the transaction too late, or, as the Beneficiary PSP's CSM, it heard nothing from the Beneficiary PSP within the time-out deadline.", "triggers": [ "A CSM between the Originator PSP and the Beneficiary PSP receives the initial transaction after the 7-second time-out deadline, or after a shorter agreed deadline", "The Beneficiary PSP's CSM gets no confirmation message at all from the Beneficiary PSP within the time-out deadline", "A connection, processing or validation problem anywhere from the Originator PSP to the Beneficiary PSP and back to its CSM" ], "actions": [ "Originator PSP: cancel the reservation of the amount and tell the Originator at once (CT-01.08R)", "Originator PSP: suggest the Originator try again later or use another instrument such as SCT", "Beneficiary PSP receiving the CSM's time-out reject: do not make the funds available [Inference from sections 4.2.3 C and 4.3.2.1]" ], "retry": { "allowed": true, "rule": "The rejected transaction is final as a failure and nothing is re-presented. The Originator may send a new SCT Inst Transaction later or use another instrument such as SCT, as the guidance suggests. The scheme sets no retry limit [Unverified]." }, "facts": { "return_windows": [ { "action": "reject for time-out (negative confirmation message)", "by": "CSM", "deadline": "Instantly once a CSM holds the transaction after the 7-second time-out deadline (or a shorter agreed one), or cannot reach the next party within it" }, { "action": "reject for time-out (negative confirmation message)", "by": "CSM of the Beneficiary PSP", "deadline": "Instantly once 7 seconds pass after the Time Stamp with no confirmation from the Beneficiary PSP; sent to the Beneficiary PSP and toward the Originator PSP, which it must reach within 2 more seconds (by the 9th second)" } ], "applies_to": "SCT Inst" }, "caveat": "The Originator PSP and its CSM may not reject on their own after the time-out deadline; they must wait for a confirmation from the Beneficiary PSP's CSM or the Beneficiary PSP (EPC004-16 2025 v1.1 section 4.2.3 C). A time-out reject that reaches the Originator PSP more than 10 seconds after the Time Stamp still gets passed to the Originator (CT-01.12R).", "related": [ "sepa-sct-inst:AB05", "sepa-sct-inst:TM01", "sepa-sct-inst:AG09" ], "basis": { "sources": "EPC059-18 v7.0 section 3, entry for AB06; EPC004-16 2025 v1.1 sections 4.2.3 C and D (7-second time-out, 9th second, 10-second rule), 4.3.2.1 (CT-01.08R, CT-01.11R, CT-01.12R, CT-01.13R), 4.5.3 DS-03 and 4.6.1 AT-R004 (time-out reason).", "confidence": "high" }, "currency": { "effective_since": "2025-10-05", "effective_note": "EPC004-16 2025 v1.1 was issued and took effect on 2025-10-05 (03:30 CET); v1.1 changed only the unstructured address cut-off, to 15 November 2026. EPC059-18 v7.0 was published on 2025-10-05 and applies to the SCT Inst rulebook. The next SCT Inst rulebook is due for publication in November 2026 [Unverified].", "source_edition": "EPC059-18 v7.0; EPC004-16 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-10/EPC004-16%202025%20SCT%20Instant%20Rulebook%20v1.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC059-18 v7.0 Guidance on Reason Codes for SCT Inst R-transactions and EPC004-16 2025 v1.1 SCT Inst Scheme Rulebook", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms name and triggers match EPC059-18's AB06 entry; confirms a CSM, and separately the Beneficiary PSP's CSM, send this reject, and the 7-second and 9-second deadlines against section 4.2.3 C. Does not address the retry limit." } ] }, "rail_name": "SEPA Instant Credit Transfer", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sct-inst:AB07", "id": "AB07", "rail": "sepa-sct-inst", "kind": "reason-code", "name": "Agent offline", "group": "technical", "summary": "A CSM's connection infrastructure between the Originator PSP and the Beneficiary PSP is down, and it cannot be said exactly which party is offline.", "triggers": [ "The connection to or from a CSM in the chain cannot carry or process any SCT Inst message", "Generic use when the offline party cannot be identified" ], "actions": [ "Originator PSP: suggest the Originator try again later or use another instrument such as SCT", "Originator: agree another way to pay with the Beneficiary" ], "retry": { "allowed": true, "rule": "The rejected transaction is final as a failure and nothing is re-presented. The Originator may send a new SCT Inst Transaction later or use another instrument such as SCT, as the guidance suggests. The scheme sets no retry limit [Unverified]." }, "facts": { "return_windows": [ { "action": "reject (negative confirmation message)", "by": "Not stated by the EPC; [Inference] likely a CSM", "deadline": "Instantly, inside the maximum execution time (target: with the Originator PSP no later than 5 seconds after the Time Stamp)" } ], "applies_to": "SCT Inst" }, "caveat": "The EPC does not name the sender of AB07: its guidance entry names none, and the rulebook's reject reasons for the Originator PSP, the CSM and the Beneficiary PSP (EPC004-16 2025 v1.1 section 4.6.1, AT-R004) do not include this case. The guidance takes the reason from the rulebook or the implementation guidelines, and the implementation guidelines were not consulted. The sender in this record is an inference: likely a CSM, since the outage is in a CSM's connection infrastructure [Inference]. Participants must be reachable 24 hours a day on every calendar day, apart from short, announced maintenance (sections 4.2.2, 5.7 and 5.8).", "related": [ "sepa-sct-inst:AB08", "sepa-sct-inst:AB10", "sepa-sct-inst:AG10" ], "basis": { "sources": "EPC059-18 v7.0 section 3, entry for AB07; EPC004-16 2025 v1.1 sections 4.3.2.1 (CT-01.05R, CT-01.06R), 4.2.3 B and C (5-second target, 7-second time-out) and 4.6.1 AT-R002 and AT-R004 (who may reject, reject reasons); EPC004-16 2025 v1.1 sections 4.2.2, 5.7 point 5 and 5.8 point 4 (24/7 availability).", "confidence": "medium" }, "currency": { "effective_since": "2025-10-05", "effective_note": "EPC004-16 2025 v1.1 was issued and took effect on 2025-10-05 (03:30 CET); v1.1 changed only the unstructured address cut-off, to 15 November 2026. EPC059-18 v7.0 was published on 2025-10-05 and applies to the SCT Inst rulebook. The next SCT Inst rulebook is due for publication in November 2026 [Unverified].", "source_edition": "EPC059-18 v7.0; EPC004-16 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-10/EPC004-16%202025%20SCT%20Instant%20Rulebook%20v1.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC059-18 v7.0 Guidance on Reason Codes for SCT Inst R-transactions and EPC004-16 2025 v1.1 SCT Inst Scheme Rulebook", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17c", "notes": "Confirms AB07 (Agent offline) as a reject code for a CSM's connection being unavailable, generic use when the offline party cannot be identified, per EPC059-18 v7.0 section 3. Confirms the AT-R004 reject reasons for the Originator PSP, CSM and Beneficiary PSP have no entry for this case, EPC004-16 2025 v1.1 section 4.6.1. Confirms the 5-second target and the 24/7 reachability duty, sections 4.2.3 and 5.8. Does not name who sends AB07; the record correctly says the EPC names no sender and labels the CSM as an inference." } ] }, "rail_name": "SEPA Instant Credit Transfer", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sct-inst:AB08", "id": "AB08", "rail": "sepa-sct-inst", "kind": "reason-code", "name": "Beneficiary PSP offline", "group": "technical", "summary": "The connection to and from the Beneficiary PSP is down, so no SCT Inst message can reach it.", "triggers": [ "The Beneficiary PSP cannot send or receive any SCT Inst message", "An outage or unannounced downtime at the Beneficiary PSP or on its link to its CSM [Inference]" ], "actions": [ "Originator PSP: suggest the Originator try again later or use another instrument such as SCT", "Originator: agree another way to pay with the Beneficiary" ], "retry": { "allowed": true, "rule": "The rejected transaction is final as a failure and nothing is re-presented. The Originator may send a new SCT Inst Transaction later or use another instrument such as SCT, as the guidance suggests. The scheme sets no retry limit [Unverified]." }, "facts": { "return_windows": [ { "action": "reject (negative confirmation message)", "by": "Not stated by the EPC; [Inference] likely the Beneficiary PSP's CSM", "deadline": "Instantly, inside the maximum execution time (target: with the Originator PSP no later than 5 seconds after the Time Stamp)" } ], "applies_to": "SCT Inst" }, "caveat": "The EPC does not name the sender of AB08: its guidance entry names none, and the rulebook's reject reasons for the Originator PSP, the CSM and the Beneficiary PSP (EPC004-16 2025 v1.1 section 4.6.1, AT-R004) do not include this case. The guidance takes the reason from the rulebook or the implementation guidelines, and the implementation guidelines were not consulted. The sender in this record is an inference: likely the Beneficiary PSP's CSM, since an offline Beneficiary PSP cannot answer [Inference]. The rulebook requires Beneficiary PSPs to process SCT Inst 24 hours a day on every calendar day, apart from short, announced maintenance (EPC004-16 2025 v1.1 section 5.8 point 4).", "related": [ "sepa-sct-inst:AB07", "sepa-sct-inst:AB09", "sepa-sct-inst:AG11" ], "basis": { "sources": "EPC059-18 v7.0 section 3, entry for AB08; EPC004-16 2025 v1.1 sections 4.3.2.1 (CT-01.05R, CT-01.06R), 4.2.3 B and C (5-second target, 7-second time-out) and 4.6.1 AT-R002 and AT-R004 (who may reject, reject reasons); EPC004-16 2025 v1.1 section 5.8 point 4 (24/7 availability).", "confidence": "medium" }, "currency": { "effective_since": "2025-10-05", "effective_note": "EPC004-16 2025 v1.1 was issued and took effect on 2025-10-05 (03:30 CET); v1.1 changed only the unstructured address cut-off, to 15 November 2026. EPC059-18 v7.0 was published on 2025-10-05 and applies to the SCT Inst rulebook. The next SCT Inst rulebook is due for publication in November 2026 [Unverified].", "source_edition": "EPC059-18 v7.0; EPC004-16 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-10/EPC004-16%202025%20SCT%20Instant%20Rulebook%20v1.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC059-18 v7.0 Guidance on Reason Codes for SCT Inst R-transactions and EPC004-16 2025 v1.1 SCT Inst Scheme Rulebook", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17c", "notes": "Confirms AB08 (Beneficiary PSP offline, Offline Creditor Agent) as a reject code for the Beneficiary PSP's connection being unavailable, per EPC059-18 v7.0 section 3. Confirms AT-R004 has no matching entry, EPC004-16 2025 v1.1 section 4.6.1, and the 24/7 processing duty for Beneficiary PSPs, section 5.8 point 4. Does not name who sends AB08; the record correctly says the EPC names no sender and labels the Beneficiary PSP's CSM as an inference." } ] }, "rail_name": "SEPA Instant Credit Transfer", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sct-inst:AB09", "id": "AB09", "rail": "sepa-sct-inst", "kind": "reason-code", "name": "Error at the Beneficiary PSP", "group": "technical", "summary": "Processing stopped because of an error at the Beneficiary PSP; some or all of its SCT Inst service is unavailable.", "triggers": [ "The transaction process aborted on an error at the Beneficiary PSP", "Part of the Beneficiary PSP's SCT Inst service is not available" ], "actions": [ "Originator: contact the Beneficiary for another way to pay", "Originator PSP: suggest the Originator resubmit or use another payment instrument" ], "retry": { "allowed": true, "rule": "The rejected transaction is final as a failure and nothing is re-presented. The Originator may send a new SCT Inst Transaction later or use another instrument such as SCT, as the guidance suggests. The scheme sets no retry limit [Unverified]." }, "facts": { "return_windows": [ { "action": "reject (negative confirmation message)", "by": "Not stated by the EPC; [Inference] likely the Beneficiary PSP", "deadline": "Instantly, inside the maximum execution time: the Originator PSP should hold a positive or negative confirmation no later than 5 seconds after the Time Stamp, and the Beneficiary PSP's answer must reach its own CSM no later than 7 seconds after it (time-out deadline)" } ], "applies_to": "SCT Inst" }, "caveat": "The EPC does not name the sender of AB09: its guidance entry names none, and the rulebook's reject reasons for the Originator PSP, the CSM and the Beneficiary PSP (EPC004-16 2025 v1.1 section 4.6.1, AT-R004) do not include this case. The guidance takes the reason from the rulebook or the implementation guidelines, and the implementation guidelines were not consulted. The sender in this record is an inference: likely the Beneficiary PSP, since the error is on its side [Inference].", "related": [ "sepa-sct-inst:AB08", "sepa-sct-inst:AB10" ], "basis": { "sources": "EPC059-18 v7.0 section 3, entry for AB09; EPC004-16 2025 v1.1 sections 4.3.2.1 (CT-01.05R, CT-01.06R), 4.2.3 B and C (5-second target, 7-second time-out) and 4.6.1 AT-R002 and AT-R004 (who may reject, reject reasons).", "confidence": "medium" }, "currency": { "effective_since": "2025-10-05", "effective_note": "EPC004-16 2025 v1.1 was issued and took effect on 2025-10-05 (03:30 CET); v1.1 changed only the unstructured address cut-off, to 15 November 2026. EPC059-18 v7.0 was published on 2025-10-05 and applies to the SCT Inst rulebook. The next SCT Inst rulebook is due for publication in November 2026 [Unverified].", "source_edition": "EPC059-18 v7.0; EPC004-16 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-10/EPC004-16%202025%20SCT%20Instant%20Rulebook%20v1.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC059-18 v7.0 Guidance on Reason Codes for SCT Inst R-transactions and EPC004-16 2025 v1.1 SCT Inst Scheme Rulebook", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17c", "notes": "Confirms AB09 (Error at the Beneficiary PSP) as a reject code for an aborted transaction due to an error at the Beneficiary PSP, or part of its SCT Inst service unavailable, per EPC059-18 v7.0 section 3. Confirms AT-R004 has no matching entry and the 5-second target and 7-second time-out deadlines, EPC004-16 2025 v1.1 sections 4.2.3 and 4.6.1. Does not name who sends AB09; the record correctly says the EPC names no sender and labels the Beneficiary PSP as an inference." } ] }, "rail_name": "SEPA Instant Credit Transfer", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sct-inst:AB10", "id": "AB10", "rail": "sepa-sct-inst", "kind": "reason-code", "name": "Error at a CSM (instructed agent)", "group": "technical", "summary": "Processing stopped because of an error at a CSM; some or all of the CSM's SCT Inst service is unavailable.", "triggers": [ "The transaction process aborted on an error at the CSM", "Part of the CSM's SCT Inst service is not available" ], "actions": [ "Originator: contact the Beneficiary for another way to pay", "Originator PSP: suggest the Originator resubmit or use another payment instrument", "Originator PSP: check whether another route to the Beneficiary PSP exists [Inference]" ], "retry": { "allowed": true, "rule": "The rejected transaction is final as a failure and nothing is re-presented. The Originator may send a new SCT Inst Transaction later or use another instrument such as SCT, as the guidance suggests. The scheme sets no retry limit [Unverified]." }, "facts": { "return_windows": [ { "action": "reject (negative confirmation message)", "by": "Not stated by the EPC; [Inference] likely a CSM", "deadline": "Instantly, inside the maximum execution time (target: with the Originator PSP no later than 5 seconds after the Time Stamp)" } ], "applies_to": "SCT Inst" }, "caveat": "The EPC does not name the sender of AB10: its guidance entry names none, and the rulebook's reject reasons for the Originator PSP, the CSM and the Beneficiary PSP (EPC004-16 2025 v1.1 section 4.6.1, AT-R004) do not include this case. The guidance takes the reason from the rulebook or the implementation guidelines, and the implementation guidelines were not consulted. The sender in this record is an inference: likely a CSM, since the error is at a CSM [Inference]. Rejects, recalls and RFROs must go through the CSM used for the original transaction unless the participants agree otherwise (EPC059-18 v7.0 section 1).", "related": [ "sepa-sct-inst:AB07", "sepa-sct-inst:AB09", "sepa-sct-inst:AG10" ], "basis": { "sources": "EPC059-18 v7.0 section 3, entry for AB10; EPC004-16 2025 v1.1 sections 4.3.2.1 (CT-01.05R, CT-01.06R), 4.2.3 B and C (5-second target, 7-second time-out) and 4.6.1 AT-R002 and AT-R004 (who may reject, reject reasons); EPC059-18 v7.0 section 1 (same CSM for R-transactions).", "confidence": "medium" }, "currency": { "effective_since": "2025-10-05", "effective_note": "EPC004-16 2025 v1.1 was issued and took effect on 2025-10-05 (03:30 CET); v1.1 changed only the unstructured address cut-off, to 15 November 2026. EPC059-18 v7.0 was published on 2025-10-05 and applies to the SCT Inst rulebook. The next SCT Inst rulebook is due for publication in November 2026 [Unverified].", "source_edition": "EPC059-18 v7.0; EPC004-16 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-10/EPC004-16%202025%20SCT%20Instant%20Rulebook%20v1.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC059-18 v7.0 Guidance on Reason Codes for SCT Inst R-transactions and EPC004-16 2025 v1.1 SCT Inst Scheme Rulebook", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17c", "notes": "Confirms AB10 (Error at a CSM, Error Instructed Agent) as a reject code for an aborted transaction due to an error at a CSM, or part of the CSM's SCT Inst service unavailable, per EPC059-18 v7.0 section 3. Confirms AT-R004 has no matching entry, EPC004-16 2025 v1.1 section 4.6.1, and that rejects, recalls and RFROs normally go through the CSM used for the original transaction, EPC059-18 v7.0 section 1. Does not name who sends AB10; the record correctly says the EPC names no sender and labels a CSM as an inference." } ] }, "rail_name": "SEPA Instant Credit Transfer", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sct-inst:AC01", "id": "AC01", "rail": "sepa-sct-inst", "kind": "reason-code", "name": "Account identifier incorrect (invalid IBAN)", "group": "account", "summary": "The IBAN is badly formed, or no such account exists at the Beneficiary PSP.", "triggers": [ "The IBAN has an invalid format", "The IBAN does not exist at the Beneficiary PSP", "The Beneficiary gave a wrong IBAN, or the Originator took a wrong IBAN from its own records", "A technical problem at the Originator while it created the instruction" ], "actions": [ "Originator: get the correct IBAN from the Beneficiary before paying again", "Originator PSP: check IBAN format and plausibility before sending; the rulebook requires it (section 5.7 point 14)" ], "retry": { "allowed": false, "rule": "Do not send to the same IBAN again. Send a new SCT Inst Transaction only once the Beneficiary confirms the correct IBAN." }, "facts": { "return_windows": [ { "action": "reject of the SCT Inst Instruction", "by": "Originator PSP", "deadline": "When it checks the instruction, before any SCT Inst Transaction is sent; the scheme only requires the Originator PSP to tell the Originator the reason" }, { "action": "reject (negative confirmation message)", "by": "CSM", "deadline": "Instantly, inside the maximum execution time (target: with the Originator PSP no later than 5 seconds after the Time Stamp)" }, { "action": "reject (negative confirmation message)", "by": "Beneficiary PSP", "deadline": "Instantly, inside the maximum execution time: the Originator PSP should hold a positive or negative confirmation no later than 5 seconds after the Time Stamp, and the Beneficiary PSP's answer must reach its own CSM no later than 7 seconds after it (time-out deadline)" } ], "applies_to": "SCT Inst" }, "caveat": "The rulebook lets the Originator PSP, a CSM and the Beneficiary PSP reject for an incorrect account identifier, but only the Beneficiary PSP can know that an account does not exist [Inference] (EPC004-16 2025 v1.1 section 4.6.1 AT-R004). Verification of Payee, which the rulebook requires before sending where law requires it (section 5.7 point 4), may catch a wrong IBAN earlier; it is a separate EPC scheme and outside this record.", "related": [ "sepa-sct-inst:AC04", "sepa-sct-inst:AC06", "sepa-sct-inst:AC03" ], "basis": { "sources": "EPC059-18 v7.0 section 3, entry for AC01; EPC004-16 2025 v1.1 sections 4.3.2.1 (CT-01.05R, CT-01.06R), 4.2.3 B and C (5-second target, 7-second time-out) and 4.6.1 AT-R002 and AT-R004 (who may reject, reject reasons); EPC004-16 2025 v1.1 section 5.7 points 4 and 14 (VOP where law requires, IBAN plausibility check).", "confidence": "high" }, "currency": { "effective_since": "2025-10-05", "effective_note": "EPC004-16 2025 v1.1 was issued and took effect on 2025-10-05 (03:30 CET); v1.1 changed only the unstructured address cut-off, to 15 November 2026. EPC059-18 v7.0 was published on 2025-10-05 and applies to the SCT Inst rulebook. The next SCT Inst rulebook is due for publication in November 2026 [Unverified].", "source_edition": "EPC059-18 v7.0; EPC004-16 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-10/EPC004-16%202025%20SCT%20Instant%20Rulebook%20v1.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC059-18 v7.0 Guidance on Reason Codes for SCT Inst R-transactions and EPC004-16 2025 v1.1 SCT Inst Scheme Rulebook", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms the three return windows (Originator PSP pre-send reject, CSM reject, Beneficiary PSP reject) against the AT-R004 reason lists in section 4.6.1, and the 5/7/9-second timing against section 4.2.3. Confirms the IBAN plausibility and BIC-check duties in section 5.7 points 4 and 14. Does not address Verification of Payee timing, which is out of scope of this record." } ] }, "rail_name": "SEPA Instant Credit Transfer", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sct-inst:AC03", "id": "AC03", "rail": "sepa-sct-inst", "kind": "reason-code", "name": "Wrong beneficiary IBAN (RFRO reason)", "group": "account", "summary": "The Originator asks for its money back because it sent the payment to the wrong IBAN. The Beneficiary must consent before anything comes back.", "triggers": [ "The Originator picked or typed a wrong IBAN for the Beneficiary when it issued the instruction, and the payment settled" ], "actions": [ "Originator: ask the Originator PSP to send an RFRO with this reason, within 13 months of the debit", "Originator PSP: tell the Originator that an RFRO does not guarantee the money comes back (section 4.3.2.3)", "Originator: fix the processes that let a wrong IBAN be selected, and take more care when entering IBANs" ], "retry": { "allowed": false, "rule": "Only one RFRO may be sent for a given SCT Inst Transaction. After the Beneficiary PSP answers, or after 15 Banking Business Days with no answer, the Originator PSP may send only a request for status update, not a new RFRO (EPC004-16 2025 v1.1 section 4.3.2.3)." }, "facts": { "return_windows": [ { "action": "request for recall by the originator (RFRO)", "by": "Originator PSP, at the Originator's request", "deadline": "The debit date of the SCT Inst Transaction must fall within the 13 months before the Originator PSP received the request; one RFRO per transaction, sent instantly or not" }, { "action": "response to an RFRO", "by": "Beneficiary PSP", "deadline": "Within 15 Banking Business Days (T2 days) after it receives the RFRO; a later answer is a breach of the rulebook" } ], "applies_to": "SCT Inst" }, "caveat": "An RFRO is a request, not a right: the Beneficiary decides whether the funds come back (EPC004-16 2025 v1.1 section 4.3.2.3). A wrong IBAN is not one of the three recall reasons, so it goes as an RFRO, not a recall. Where Verification of Payee applies, it may flag the mismatch before sending; VOP is a separate EPC scheme.", "related": [ "sepa-sct-inst:AM09", "sepa-sct-inst:CUST", "sepa-sct-inst:FOCR", "sepa-sct-inst:NOAS" ], "basis": { "sources": "EPC059-18 v7.0 section 3, entry for AC03; EPC004-16 2025 v1.1 section 4.3.2.3 and PR-03 steps 1 to 5 (13 months, one RFRO, 15 Banking Business Day answer), 4.6.1 AT-R071 and AT-R077; chapter 7 (Banking Business Day is a T2 day).", "confidence": "high" }, "currency": { "effective_since": "2025-10-05", "effective_note": "EPC004-16 2025 v1.1 was issued and took effect on 2025-10-05 (03:30 CET); v1.1 changed only the unstructured address cut-off, to 15 November 2026. EPC059-18 v7.0 was published on 2025-10-05 and applies to the SCT Inst rulebook. The next SCT Inst rulebook is due for publication in November 2026 [Unverified].", "source_edition": "EPC059-18 v7.0; EPC004-16 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-10/EPC004-16%202025%20SCT%20Instant%20Rulebook%20v1.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC059-18 v7.0 Guidance on Reason Codes for SCT Inst R-transactions and EPC004-16 2025 v1.1 SCT Inst Scheme Rulebook", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms AC03 as one of the three RFRO reasons (attribute AT-R071) and the 13-month window and one-RFRO rule in section 4.3.2.3; confirms the 15 Banking Business Day response deadline. Does not address whether an RFRO can request only part of the amount." } ] }, "rail_name": "SEPA Instant Credit Transfer", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sct-inst:AC04", "id": "AC04", "rail": "sepa-sct-inst", "kind": "reason-code", "name": "Account closed", "group": "account", "summary": "The Beneficiary's account is closed. Used to reject an incoming transaction and to answer a recall or RFRO negatively.", "triggers": [ "The Beneficiary closed the account after the Originator's last payment to it", "A recall or RFRO arrives for a transaction whose beneficiary account has since been closed" ], "actions": [ "Originator: contact the Beneficiary for the new account", "On a negative answer to a recall or RFRO: recover the funds from the Beneficiary directly, outside the scheme", "Where Beneficiary PSPs send MS03, remember it may stand for a closed account [Inference]" ], "retry": { "allowed": false, "rule": "Do not send to the closed account again. Pay again only to a new account the Beneficiary confirms. After a negative answer, no second recall or RFRO may be sent for the same transaction (EPC004-16 2025 v1.1 sections 4.3.2.2 and 4.3.2.3)." }, "facts": { "return_windows": [ { "action": "reject (negative confirmation message)", "by": "Beneficiary PSP", "deadline": "Instantly, inside the maximum execution time: the Originator PSP should hold a positive or negative confirmation no later than 5 seconds after the Time Stamp, and the Beneficiary PSP's answer must reach its own CSM no later than 7 seconds after it (time-out deadline)" }, { "action": "response to a recall", "by": "Beneficiary PSP", "deadline": "Within 15 Banking Business Days (T2 days) after it receives the recall; a later answer is a breach of the rulebook" }, { "action": "response to an RFRO", "by": "Beneficiary PSP", "deadline": "Within 15 Banking Business Days (T2 days) after it receives the RFRO; a later answer is a breach of the rulebook" } ], "applies_to": "SCT Inst" }, "caveat": "The guidance notes that data protection law in certain SEPA countries bars this code and names MS03 as the alternative (EPC059-18 v7.0 section 3). It does not name the countries. A negative answer ends the recall or RFRO; the Originator PSP may not send another one for the same transaction (EPC004-16 2025 v1.1 sections 4.3.2.2 and 4.3.2.3). Recovery then happens outside the scheme.", "related": [ "sepa-sct-inst:AC01", "sepa-sct-inst:AC06", "sepa-sct-inst:MS03" ], "basis": { "sources": "EPC059-18 v7.0 section 3, entry for AC04; EPC004-16 2025 v1.1 sections 4.3.2.1 (CT-01.05R, CT-01.06R), 4.2.3 B and C (5-second target, 7-second time-out) and 4.6.1 AT-R002 and AT-R004 (who may reject, reject reasons); EPC004-16 2025 v1.1 section 4.3.2.2 and CT-02.01 to CT-02.07 (recall reasons, 10 Banking Business Days or 13 months, one recall, 15 Banking Business Day answer), 4.6.1 AT-R051 and AT-R057; chapter 7 (Banking Business Day is a T2 day); EPC004-16 2025 v1.1 section 4.3.2.3 and PR-03 steps 1 to 5 (13 months, one RFRO, 15 Banking Business Day answer), 4.6.1 AT-R071 and AT-R077; chapter 7 (Banking Business Day is a T2 day).", "confidence": "high" }, "currency": { "effective_since": "2025-10-05", "effective_note": "EPC004-16 2025 v1.1 was issued and took effect on 2025-10-05 (03:30 CET); v1.1 changed only the unstructured address cut-off, to 15 November 2026. EPC059-18 v7.0 was published on 2025-10-05 and applies to the SCT Inst rulebook. The next SCT Inst rulebook is due for publication in November 2026 [Unverified].", "source_edition": "EPC059-18 v7.0; EPC004-16 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-10/EPC004-16%202025%20SCT%20Instant%20Rulebook%20v1.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC059-18 v7.0 Guidance on Reason Codes for SCT Inst R-transactions and EPC004-16 2025 v1.1 SCT Inst Scheme Rulebook", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms the reject use (Beneficiary PSP only, AT-R004) and the negative recall/RFRO response use ('Account closed', AT-R057 and AT-R077); confirms the 15 Banking Business Day response windows in sections 4.3.2.2 and 4.3.2.3. Does not name the countries whose data protection law bars this code." } ] }, "rail_name": "SEPA Instant Credit Transfer", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sct-inst:AC06", "id": "AC06", "rail": "sepa-sct-inst", "kind": "reason-code", "name": "Account blocked", "group": "account", "summary": "The Beneficiary PSP has blocked the account for all financial transactions.", "triggers": [ "A court order blocks the account", "The Beneficiary PSP blocked the account itself, for example on suspected misuse or at the Beneficiary's request" ], "actions": [ "Originator: contact the Beneficiary for another account or another way to pay" ], "retry": { "allowed": false, "rule": "Do not send to the blocked account again until the Beneficiary confirms it is unblocked, or pay to another account." }, "facts": { "return_windows": [ { "action": "reject (negative confirmation message)", "by": "Beneficiary PSP", "deadline": "Instantly, inside the maximum execution time: the Originator PSP should hold a positive or negative confirmation no later than 5 seconds after the Time Stamp, and the Beneficiary PSP's answer must reach its own CSM no later than 7 seconds after it (time-out deadline)" } ], "applies_to": "SCT Inst" }, "caveat": "The rulebook's reject reason reads 'account blocked, reason not specified' and belongs to the Beneficiary PSP only (EPC004-16 2025 v1.1 section 4.6.1 AT-R004). AC06 is not listed for answers to a recall or RFRO.", "related": [ "sepa-sct-inst:AC01", "sepa-sct-inst:AC04", "sepa-sct-inst:AG01" ], "basis": { "sources": "EPC059-18 v7.0 section 3, entry for AC06; EPC004-16 2025 v1.1 sections 4.3.2.1 (CT-01.05R, CT-01.06R), 4.2.3 B and C (5-second target, 7-second time-out) and 4.6.1 AT-R002 and AT-R004 (who may reject, reject reasons).", "confidence": "high" }, "currency": { "effective_since": "2025-10-05", "effective_note": "EPC004-16 2025 v1.1 was issued and took effect on 2025-10-05 (03:30 CET); v1.1 changed only the unstructured address cut-off, to 15 November 2026. EPC059-18 v7.0 was published on 2025-10-05 and applies to the SCT Inst rulebook. The next SCT Inst rulebook is due for publication in November 2026 [Unverified].", "source_edition": "EPC059-18 v7.0; EPC004-16 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-10/EPC004-16%202025%20SCT%20Instant%20Rulebook%20v1.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC059-18 v7.0 Guidance on Reason Codes for SCT Inst R-transactions and EPC004-16 2025 v1.1 SCT Inst Scheme Rulebook", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms the reject is Beneficiary-PSP-only ('Account blocked, reason not specified', AT-R004) and the 5/7/9-second timing. Does not address whether AC06 can answer a recall or RFRO; the source lists it only as a reject reason." } ] }, "rail_name": "SEPA Instant Credit Transfer", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sct-inst:AG01", "id": "AG01", "rail": "sepa-sct-inst", "kind": "reason-code", "name": "Credit transfer forbidden on this account", "group": "account", "summary": "SCT Inst transactions cannot be booked to this type of account.", "triggers": [ "The Beneficiary gave details of an account type that cannot take SCT Inst credits" ], "actions": [ "Originator: agree another payment instrument with the Beneficiary", "Originator PSP: where the Originator agreed to this in advance, and subject to law, send the payment again as an SCT (the guidance cites Article 5a(1), introduced into the SEPA Regulation by Regulation (EU) 2024/886)" ], "retry": { "allowed": false, "rule": "Do not send the same SCT Inst to this account again. The guidance suggests another instrument, or an SCT fallback where the Originator agreed to it beforehand and law allows (EPC059-18 v7.0 section 3, AG01 and footnote 2)." }, "facts": { "return_windows": [ { "action": "reject (negative confirmation message)", "by": "Beneficiary PSP", "deadline": "Instantly, inside the maximum execution time: the Originator PSP should hold a positive or negative confirmation no later than 5 seconds after the Time Stamp, and the Beneficiary PSP's answer must reach its own CSM no later than 7 seconds after it (time-out deadline)" } ], "applies_to": "SCT Inst" }, "caveat": "The guidance footnote recalls that the Instant Payments Regulation requires PSPs that offer euro credit transfers to offer instant ones, and to make every account reachable by SCT also reachable by SCT Inst, from dates that vary by PSP type and Member State. That duty comes from law, not the rulebook. AG01 should therefore be rare on payment accounts reachable for SCT at PSPs already subject to that duty [Inference].", "related": [ "sepa-sct-inst:AC06", "sepa-sct-inst:AG02" ], "basis": { "sources": "EPC059-18 v7.0 section 3, entry for AG01 and footnote 2; EPC004-16 2025 v1.1 sections 4.3.2.1 (CT-01.05R, CT-01.06R), 4.2.3 B and C (5-second target, 7-second time-out) and 4.6.1 AT-R002 and AT-R004 (who may reject, reject reasons); EPC004-16 2025 v1.1 section 2.6 (reachability).", "confidence": "high" }, "currency": { "effective_since": "2025-10-05", "effective_note": "EPC004-16 2025 v1.1 was issued and took effect on 2025-10-05 (03:30 CET); v1.1 changed only the unstructured address cut-off, to 15 November 2026. EPC059-18 v7.0 was published on 2025-10-05 and applies to the SCT Inst rulebook. The next SCT Inst rulebook is due for publication in November 2026 [Unverified].", "source_edition": "EPC059-18 v7.0; EPC004-16 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-10/EPC004-16%202025%20SCT%20Instant%20Rulebook%20v1.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC059-18 v7.0 Guidance on Reason Codes for SCT Inst R-transactions and EPC004-16 2025 v1.1 SCT Inst Scheme Rulebook", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms the reject is Beneficiary-PSP-only ('Credit transfer forbidden on this type of account', AT-R004) and the Instant Payments Regulation reachability duty in the guidance's own footnote. Does not state how often AG01 occurs in practice." } ] }, "rail_name": "SEPA Instant Credit Transfer", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sct-inst:AG02", "id": "AG02", "rail": "sepa-sct-inst", "kind": "reason-code", "name": "Operation or transaction code incorrect, invalid format", "group": "technical", "summary": "The scheme identifier in the message (service level or local instrument) is wrong.", "triggers": [ "The service level or local instrument code does not identify SCT Inst correctly", "A technical error at the Originator, or while processing the transaction or the file that carried it" ], "actions": [ "Originator or Originator PSP: correct the scheme identification and send a new transaction" ], "retry": { "allowed": true, "rule": "Send a new SCT Inst Transaction once the scheme identification is corrected. The scheme sets no retry limit [Unverified]." }, "facts": { "return_windows": [ { "action": "reject of the SCT Inst Instruction", "by": "Originator PSP", "deadline": "When it checks the instruction, before any SCT Inst Transaction is sent; the scheme only requires the Originator PSP to tell the Originator the reason" }, { "action": "reject (negative confirmation message)", "by": "CSM", "deadline": "Instantly, inside the maximum execution time (target: with the Originator PSP no later than 5 seconds after the Time Stamp)" }, { "action": "reject (negative confirmation message)", "by": "Beneficiary PSP", "deadline": "Instantly, inside the maximum execution time: the Originator PSP should hold a positive or negative confirmation no later than 5 seconds after the Time Stamp, and the Beneficiary PSP's answer must reach its own CSM no later than 7 seconds after it (time-out deadline)" } ], "applies_to": "SCT Inst" }, "caveat": "The rulebook lists this reason for the Originator PSP, a CSM and the Beneficiary PSP (EPC004-16 2025 v1.1 section 4.6.1 AT-R004); the guidance does not say who usually sends it.", "related": [ "sepa-sct-inst:FF01", "sepa-sct-inst:RC01" ], "basis": { "sources": "EPC059-18 v7.0 section 3, entry for AG02; EPC004-16 2025 v1.1 sections 4.3.2.1 (CT-01.05R, CT-01.06R), 4.2.3 B and C (5-second target, 7-second time-out) and 4.6.1 AT-R002 and AT-R004 (who may reject, reject reasons).", "confidence": "high" }, "currency": { "effective_since": "2025-10-05", "effective_note": "EPC004-16 2025 v1.1 was issued and took effect on 2025-10-05 (03:30 CET); v1.1 changed only the unstructured address cut-off, to 15 November 2026. EPC059-18 v7.0 was published on 2025-10-05 and applies to the SCT Inst rulebook. The next SCT Inst rulebook is due for publication in November 2026 [Unverified].", "source_edition": "EPC059-18 v7.0; EPC004-16 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-10/EPC004-16%202025%20SCT%20Instant%20Rulebook%20v1.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC059-18 v7.0 Guidance on Reason Codes for SCT Inst R-transactions and EPC004-16 2025 v1.1 SCT Inst Scheme Rulebook", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms the three return windows against AT-R004's 'Operation/transaction code incorrect' reasons for Originator PSP, CSM and Beneficiary PSP, and the 5/7/9-second timing. Does not name which party typically sends it." } ] }, "rail_name": "SEPA Instant Credit Transfer", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sct-inst:AG09", "id": "AG09", "rail": "sepa-sct-inst", "kind": "reason-code", "name": "Original payment never received", "group": "technical", "summary": "Used in reply to a transaction status investigation: the CSM or Beneficiary PSP never received the SCT Inst Transaction the investigation asks about.", "triggers": [ "The status investigation went to the wrong Beneficiary PSP, through the Originator PSP's or a CSM's error", "The right Beneficiary PSP never got the transaction because of a connection or processing problem" ], "actions": [ "Wrong addressee: Originator PSP or CSM sends the investigation to the correct Beneficiary PSP", "Right addressee: Originator PSP investigates the actual problem and tells the Originator the transaction failed", "Originator PSP: treat the transaction as rejected and inform the Originator at once (CT-03.03)" ], "retry": { "allowed": true, "rule": "The scheme sets no limit on how often an Originator PSP repeats a status investigation (section 4.4). A new payment is a new SCT Inst Transaction; the scheme sets no retry limit [Unverified]." }, "facts": { "return_windows": [ { "action": "reject in reply to a transaction status investigation", "by": "CSM or Beneficiary PSP", "deadline": "Instantly on receipt of the status investigation message; the scheme sets no overall time limit for the investigation" } ], "applies_to": "SCT Inst" }, "caveat": "The status investigation is optional and follows a transaction with no confirmation after the time-out deadline; the Originator PSP may start it after the 9th second after the Time Stamp (EPC004-16 2025 v1.1 sections 4.2.3 D, 4.4 and 4.5.7 DS-07). The Originator PSP may treat the transaction as failed only on a formal confirmation message.", "related": [ "sepa-sct-inst:AB05", "sepa-sct-inst:AB06", "sepa-sct-inst:NOOR" ], "basis": { "sources": "EPC059-18 v7.0 section 3, entry for AG09; EPC004-16 2025 v1.1 section 4.4 CT-03.01 to CT-03.06 and 4.5.7 DS-07 (status investigation); EPC004-16 2025 v1.1 section 4.2.3 D.", "confidence": "high" }, "currency": { "effective_since": "2025-10-05", "effective_note": "EPC004-16 2025 v1.1 was issued and took effect on 2025-10-05 (03:30 CET); v1.1 changed only the unstructured address cut-off, to 15 November 2026. EPC059-18 v7.0 was published on 2025-10-05 and applies to the SCT Inst rulebook. The next SCT Inst rulebook is due for publication in November 2026 [Unverified].", "source_edition": "EPC059-18 v7.0; EPC004-16 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-10/EPC004-16%202025%20SCT%20Instant%20Rulebook%20v1.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC059-18 v7.0 Guidance on Reason Codes for SCT Inst R-transactions and EPC004-16 2025 v1.1 SCT Inst Scheme Rulebook", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms AG09 is the status-investigation reply for a transaction never received, sent by the CSM or the Beneficiary PSP, against section 4.4 (CT-03.01 to CT-03.06); confirms the scheme sets no time limit on the investigation and no cap on repeating it. Does not address a fixed reply deadline, since the source states there is none." } ] }, "rail_name": "SEPA Instant Credit Transfer", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sct-inst:AG10", "id": "AG10", "rail": "sepa-sct-inst", "kind": "reason-code", "name": "Agent suspended", "group": "network", "summary": "A party in the chain after the Originator PSP is suspended, temporarily or not, and it cannot be told whether it is the Beneficiary PSP or another agent.", "triggers": [ "The overseer of an agent in the chain has suspended that agent", "It cannot be determined whether the Beneficiary PSP or an intermediate agent is the one suspended" ], "actions": [ "Originator PSP: look for another route to the Beneficiary PSP", "Originator PSP: suggest the Originator try later or use another instrument such as SCT" ], "retry": { "allowed": true, "rule": "The rejected transaction is final as a failure and nothing is re-presented. The Originator may send a new SCT Inst Transaction later or use another instrument such as SCT, as the guidance suggests, or the Originator PSP may use another route. The scheme sets no retry limit [Unverified]." }, "facts": { "return_windows": [ { "action": "reject (negative confirmation message)", "by": "Not stated by the EPC; [Inference] likely a CSM", "deadline": "Instantly, inside the maximum execution time (target: with the Originator PSP no later than 5 seconds after the Time Stamp)" } ], "applies_to": "SCT Inst" }, "caveat": "The guidance says AG10 must be used when the suspended party cannot be identified; AG11 applies when it is the Beneficiary PSP. The EPC does not name the sender of AG10: its guidance entry names none, and the rulebook's reject reasons for the Originator PSP, the CSM and the Beneficiary PSP (EPC004-16 2025 v1.1 section 4.6.1, AT-R004) do not include this case. The guidance takes the reason from the rulebook or the implementation guidelines, and the implementation guidelines were not consulted. The sender in this record is an inference: likely a CSM, since the suspended party is somewhere after the Originator PSP [Inference].", "related": [ "sepa-sct-inst:AG11", "sepa-sct-inst:CNOR", "sepa-sct-inst:AB07" ], "basis": { "sources": "EPC059-18 v7.0 section 3, entry for AG10; EPC004-16 2025 v1.1 sections 4.3.2.1 (CT-01.05R, CT-01.06R), 4.2.3 B and C (5-second target, 7-second time-out) and 4.6.1 AT-R002 and AT-R004 (who may reject, reject reasons).", "confidence": "medium" }, "currency": { "effective_since": "2025-10-05", "effective_note": "EPC004-16 2025 v1.1 was issued and took effect on 2025-10-05 (03:30 CET); v1.1 changed only the unstructured address cut-off, to 15 November 2026. EPC059-18 v7.0 was published on 2025-10-05 and applies to the SCT Inst rulebook. The next SCT Inst rulebook is due for publication in November 2026 [Unverified].", "source_edition": "EPC059-18 v7.0; EPC004-16 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-10/EPC004-16%202025%20SCT%20Instant%20Rulebook%20v1.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC059-18 v7.0 Guidance on Reason Codes for SCT Inst R-transactions and EPC004-16 2025 v1.1 SCT Inst Scheme Rulebook", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17c", "notes": "Confirms AG10 (Agent suspended) as a reject code used when it cannot be determined whether the Beneficiary PSP or another agent in the chain is suspended, per EPC059-18 v7.0 section 3, and that AG11 is the code for a suspended Beneficiary PSP specifically. Confirms AT-R004 has no matching entry, EPC004-16 2025 v1.1 section 4.6.1. Does not name who sends AG10; the record correctly says the EPC names no sender and labels a CSM as an inference." } ] }, "rail_name": "SEPA Instant Credit Transfer", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sct-inst:AG11", "id": "AG11", "rail": "sepa-sct-inst", "kind": "reason-code", "name": "Beneficiary PSP suspended", "group": "network", "summary": "The Beneficiary PSP the transaction was sent to is suspended, temporarily or not.", "triggers": [ "The Beneficiary PSP's overseer, or its CSM, has suspended it" ], "actions": [ "Originator: ask the Beneficiary for an account at another PSP" ], "retry": { "allowed": false, "rule": "Do not send to the suspended Beneficiary PSP again until the suspension ends [Inference]. Pay to an account at another PSP instead." }, "facts": { "return_windows": [ { "action": "reject (negative confirmation message)", "by": "Not stated by the EPC; [Inference] likely the Beneficiary PSP's CSM", "deadline": "Instantly, inside the maximum execution time (target: with the Originator PSP no later than 5 seconds after the Time Stamp)" } ], "applies_to": "SCT Inst" }, "caveat": "The EPC does not name the sender of AG11: its guidance entry names none, and the rulebook's reject reasons for the Originator PSP, the CSM and the Beneficiary PSP (EPC004-16 2025 v1.1 section 4.6.1, AT-R004) do not include this case. The guidance takes the reason from the rulebook or the implementation guidelines, and the implementation guidelines were not consulted. The sender in this record is an inference: likely the Beneficiary PSP's CSM, since the Beneficiary PSP is the party suspended [Inference].", "related": [ "sepa-sct-inst:AG10", "sepa-sct-inst:CNOR", "sepa-sct-inst:AB08" ], "basis": { "sources": "EPC059-18 v7.0 section 3, entry for AG11; EPC004-16 2025 v1.1 sections 4.3.2.1 (CT-01.05R, CT-01.06R), 4.2.3 B and C (5-second target, 7-second time-out) and 4.6.1 AT-R002 and AT-R004 (who may reject, reject reasons).", "confidence": "medium" }, "currency": { "effective_since": "2025-10-05", "effective_note": "EPC004-16 2025 v1.1 was issued and took effect on 2025-10-05 (03:30 CET); v1.1 changed only the unstructured address cut-off, to 15 November 2026. EPC059-18 v7.0 was published on 2025-10-05 and applies to the SCT Inst rulebook. The next SCT Inst rulebook is due for publication in November 2026 [Unverified].", "source_edition": "EPC059-18 v7.0; EPC004-16 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-10/EPC004-16%202025%20SCT%20Instant%20Rulebook%20v1.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC059-18 v7.0 Guidance on Reason Codes for SCT Inst R-transactions and EPC004-16 2025 v1.1 SCT Inst Scheme Rulebook", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17c", "notes": "Confirms AG11 (Beneficiary PSP suspended, Creditor Agent Suspended) as a reject code for a suspended Beneficiary PSP, suspended by its overseer or its CSM, per EPC059-18 v7.0 section 3. Confirms AT-R004 has no matching entry, EPC004-16 2025 v1.1 section 4.6.1. Does not name who sends the reject message itself; the record correctly says the EPC names no sender and labels the Beneficiary PSP's CSM as an inference." } ] }, "rail_name": "SEPA Instant Credit Transfer", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sct-inst:AM04", "id": "AM04", "rail": "sepa-sct-inst", "kind": "reason-code", "name": "Insufficient funds (answer to a recall or RFRO)", "group": "funds", "summary": "The Beneficiary's account lacks the funds to cover the full recall or RFRO amount, so the Beneficiary PSP answers no. In SCT Inst this is not a reject reason.", "triggers": [ "A recall or RFRO arrives and the Beneficiary's account does not hold enough to debit the full amount" ], "actions": [ "Originator: contact the Beneficiary directly to recover the funds outside the scheme", "Originator PSP: do the same when the recall concerns its own error", "Where Beneficiary PSPs send CUST, remember it may stand for insufficient funds [Inference]" ], "retry": { "allowed": false, "rule": "Not within the scheme. After the Beneficiary PSP answers, the Originator PSP may not send another recall or RFRO for the same SCT Inst Transaction (EPC004-16 2025 v1.1 sections 4.3.2.2 and 4.3.2.3). Any recovery is between Originator and Beneficiary." }, "facts": { "return_windows": [ { "action": "response to a recall", "by": "Beneficiary PSP", "deadline": "Within 15 Banking Business Days (T2 days) after it receives the recall; a later answer is a breach of the rulebook" }, { "action": "response to an RFRO", "by": "Beneficiary PSP", "deadline": "Within 15 Banking Business Days (T2 days) after it receives the RFRO; a later answer is a breach of the rulebook" } ], "applies_to": "SCT Inst" }, "caveat": "The guidance notes that data protection law in certain SEPA countries bars this code and names CUST as the alternative (EPC059-18 v7.0 section 3). It does not name the countries. A negative answer ends the recall or RFRO; the Originator PSP may not send another one for the same transaction (EPC004-16 2025 v1.1 sections 4.3.2.2 and 4.3.2.3). Recovery then happens outside the scheme. Funds on the Originator's side are checked by the Originator PSP before the transaction is sent (section 4.2.1), so the rulebook has no insufficient funds reject.", "related": [ "sepa-sct-inst:CUST", "sepa-sct-inst:FOCR", "sepa-sct-inst:LEGL" ], "basis": { "sources": "EPC059-18 v7.0 section 3, entry for AM04; EPC004-16 2025 v1.1 section 4.3.2.2 and CT-02.01 to CT-02.07 (recall reasons, 10 Banking Business Days or 13 months, one recall, 15 Banking Business Day answer), 4.6.1 AT-R051 and AT-R057; chapter 7 (Banking Business Day is a T2 day); EPC004-16 2025 v1.1 section 4.3.2.3 and PR-03 steps 1 to 5 (13 months, one RFRO, 15 Banking Business Day answer), 4.6.1 AT-R071 and AT-R077; chapter 7 (Banking Business Day is a T2 day); EPC004-16 2025 v1.1 section 4.2.1 (Originator PSP funds check).", "confidence": "high" }, "currency": { "effective_since": "2025-10-05", "effective_note": "EPC004-16 2025 v1.1 was issued and took effect on 2025-10-05 (03:30 CET); v1.1 changed only the unstructured address cut-off, to 15 November 2026. EPC059-18 v7.0 was published on 2025-10-05 and applies to the SCT Inst rulebook. The next SCT Inst rulebook is due for publication in November 2026 [Unverified].", "source_edition": "EPC059-18 v7.0; EPC004-16 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-10/EPC004-16%202025%20SCT%20Instant%20Rulebook%20v1.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC059-18 v7.0 Guidance on Reason Codes for SCT Inst R-transactions and EPC004-16 2025 v1.1 SCT Inst Scheme Rulebook", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms AM04 as a negative recall/RFRO response ('Insufficient Funds', AT-R057 and AT-R077) and the 15 Banking Business Day windows. Does not name the countries whose data protection law bars this code." } ] }, "rail_name": "SEPA Instant Credit Transfer", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sct-inst:AM05", "id": "AM05", "rail": "sepa-sct-inst", "kind": "reason-code", "name": "Duplicate payment (reject)", "group": "administrative", "summary": "A CSM or the Beneficiary PSP rejects because it believes an identical SCT Inst Transaction was sent or processed very recently.", "triggers": [ "A technical or human error at the Originator or Originator PSP sends the same transaction twice" ], "actions": [ "Originator and Originator PSP: check whether the transaction really is a duplicate before sending anything again" ], "retry": { "allowed": true, "rule": "Send a new transaction only if the check shows the payment was not in fact made. The scheme sets no retry limit [Unverified]." }, "facts": { "return_windows": [ { "action": "reject of the SCT Inst Instruction", "by": "Originator PSP", "deadline": "When it checks the instruction, before any SCT Inst Transaction is sent; the scheme only requires the Originator PSP to tell the Originator the reason" }, { "action": "reject (negative confirmation message)", "by": "CSM", "deadline": "Instantly, inside the maximum execution time (target: with the Originator PSP no later than 5 seconds after the Time Stamp)" }, { "action": "reject (negative confirmation message)", "by": "Beneficiary PSP", "deadline": "Instantly, inside the maximum execution time: the Originator PSP should hold a positive or negative confirmation no later than 5 seconds after the Time Stamp, and the Beneficiary PSP's answer must reach its own CSM no later than 7 seconds after it (time-out deadline)" } ], "applies_to": "SCT Inst" }, "caveat": "The rulebook lists duplicate payment as a reject reason for the Originator PSP, a CSM and the Beneficiary PSP (EPC004-16 2025 v1.1 section 4.6.1 AT-R004) but defines no test for what counts as identical or recent. A duplicate that already settled is recovered by recall with DUPL, not by AM05.", "related": [ "sepa-sct-inst:DUPL" ], "basis": { "sources": "EPC059-18 v7.0 section 3, entry for AM05; EPC004-16 2025 v1.1 sections 4.3.2.1 (CT-01.05R, CT-01.06R), 4.2.3 B and C (5-second target, 7-second time-out) and 4.6.1 AT-R002 and AT-R004 (who may reject, reject reasons).", "confidence": "high" }, "currency": { "effective_since": "2025-10-05", "effective_note": "EPC004-16 2025 v1.1 was issued and took effect on 2025-10-05 (03:30 CET); v1.1 changed only the unstructured address cut-off, to 15 November 2026. EPC059-18 v7.0 was published on 2025-10-05 and applies to the SCT Inst rulebook. The next SCT Inst rulebook is due for publication in November 2026 [Unverified].", "source_edition": "EPC059-18 v7.0; EPC004-16 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-10/EPC004-16%202025%20SCT%20Instant%20Rulebook%20v1.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC059-18 v7.0 Guidance on Reason Codes for SCT Inst R-transactions and EPC004-16 2025 v1.1 SCT Inst Scheme Rulebook", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms the three return windows against AT-R004's 'Duplicate payment' reason for Originator PSP, CSM and Beneficiary PSP, and the 5/7/9-second timing. Does not define what counts as an identical or recent transaction, since the source gives no test." } ] }, "rail_name": "SEPA Instant Credit Transfer", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sct-inst:AM09", "id": "AM09", "rail": "sepa-sct-inst", "kind": "reason-code", "name": "Wrong amount (RFRO reason)", "group": "administrative", "summary": "The Originator asks for money back because it sent more than it meant to. The Beneficiary must consent.", "triggers": [ "A technical or human error at the Originator produced an instruction for a higher amount than intended, and the payment settled" ], "actions": [ "Originator: ask the Originator PSP to send an RFRO with this reason, within 13 months of the debit", "Originator PSP: tell the Originator an RFRO does not guarantee a refund (section 4.3.2.3)", "Originator: fix the instruction process so wrong amounts are not sent again" ], "retry": { "allowed": false, "rule": "Only one RFRO may be sent for a given SCT Inst Transaction. After an answer, or 15 Banking Business Days with none, only a request for status update is allowed (EPC004-16 2025 v1.1 section 4.3.2.3)." }, "facts": { "return_windows": [ { "action": "request for recall by the originator (RFRO)", "by": "Originator PSP, at the Originator's request", "deadline": "The debit date of the SCT Inst Transaction must fall within the 13 months before the Originator PSP received the request; one RFRO per transaction, sent instantly or not" }, { "action": "response to an RFRO", "by": "Beneficiary PSP", "deadline": "Within 15 Banking Business Days (T2 days) after it receives the RFRO; a later answer is a breach of the rulebook" } ], "applies_to": "SCT Inst" }, "caveat": "The RFRO dataset carries the amount of the original transaction (DS-08, AT-T002). The texts read do not say whether an RFRO can ask for only the excess [Unverified]. A wrong amount is not a recall reason, so it goes as an RFRO.", "related": [ "sepa-sct-inst:AC03", "sepa-sct-inst:CUST", "sepa-sct-inst:FOCR", "sepa-sct-inst:NOAS" ], "basis": { "sources": "EPC059-18 v7.0 section 3, entry for AM09; EPC004-16 2025 v1.1 section 4.3.2.3 and PR-03 steps 1 to 5 (13 months, one RFRO, 15 Banking Business Day answer), 4.6.1 AT-R071 and AT-R077; chapter 7 (Banking Business Day is a T2 day); EPC004-16 2025 v1.1 section 4.5.8 DS-08.", "confidence": "high" }, "currency": { "effective_since": "2025-10-05", "effective_note": "EPC004-16 2025 v1.1 was issued and took effect on 2025-10-05 (03:30 CET); v1.1 changed only the unstructured address cut-off, to 15 November 2026. EPC059-18 v7.0 was published on 2025-10-05 and applies to the SCT Inst rulebook. The next SCT Inst rulebook is due for publication in November 2026 [Unverified].", "source_edition": "EPC059-18 v7.0; EPC004-16 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-10/EPC004-16%202025%20SCT%20Instant%20Rulebook%20v1.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC059-18 v7.0 Guidance on Reason Codes for SCT Inst R-transactions and EPC004-16 2025 v1.1 SCT Inst Scheme Rulebook", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms AM09 as one of the three RFRO reasons (AT-R071, 'Wrong amount') and the 13-month window, one-RFRO rule and 15 Banking Business Day response deadline in section 4.3.2.3. Does not state whether an RFRO can ask for only the excess amount." } ] }, "rail_name": "SEPA Instant Credit Transfer", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sct-inst:AM23", "id": "AM23", "rail": "sepa-sct-inst", "kind": "reason-code", "name": "Amount exceeds settlement limit", "group": "network", "summary": "The Originator PSP has not got enough pre-funded settlement cover at its CSM to settle this transaction.", "triggers": [ "A sudden peak in the Originator PSP's outgoing SCT Inst volume", "The Originator PSP cannot top up its settlement cover", "The Originator PSP's monitoring of remaining cover fails and nobody notices" ], "actions": [ "Originator PSP: replenish its settlement cover as soon as possible", "Originator PSP: suggest the Originator try later or use another instrument such as SCT", "Originator: agree another way to pay with the Beneficiary" ], "retry": { "allowed": true, "rule": "A new SCT Inst Transaction can succeed once the Originator PSP's settlement cover is replenished. The scheme sets no retry limit [Unverified]." }, "facts": { "return_windows": [ { "action": "reject (negative confirmation message)", "by": "CSM", "deadline": "Instantly, inside the maximum execution time (target: with the Originator PSP no later than 5 seconds after the Time Stamp)" } ], "applies_to": "SCT Inst" }, "caveat": "Settlement limit exceeded is a CSM reject reason in the rulebook (EPC004-16 2025 v1.1 section 4.6.1 AT-R004). The CSM reserves funds from the Originator PSP to give upfront settlement certainty (section 4.3). This is not a scheme maximum amount: the 2025 rulebook removed any scheme-level maximum, citing Article 5a(6) of the amended SEPA Regulation (Annex IV change history, and section 2.5).", "related": [ "sepa-sct-inst:AG10", "sepa-sct-inst:DNOR" ], "basis": { "sources": "EPC059-18 v7.0 section 3, entry for AM23; EPC004-16 2025 v1.1 sections 4.3.2.1 (CT-01.05R, CT-01.06R), 4.2.3 B and C (5-second target, 7-second time-out) and 4.6.1 AT-R002 and AT-R004 (who may reject, reject reasons); EPC004-16 2025 v1.1 sections 2.5, 4.3 (settlement cover) and Annex IV (removal of the scheme maximum amount).", "confidence": "high" }, "currency": { "effective_since": "2025-10-05", "effective_note": "EPC004-16 2025 v1.1 was issued and took effect on 2025-10-05 (03:30 CET); v1.1 changed only the unstructured address cut-off, to 15 November 2026. EPC059-18 v7.0 was published on 2025-10-05 and applies to the SCT Inst rulebook. The next SCT Inst rulebook is due for publication in November 2026 [Unverified].", "source_edition": "EPC059-18 v7.0; EPC004-16 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-10/EPC004-16%202025%20SCT%20Instant%20Rulebook%20v1.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC059-18 v7.0 Guidance on Reason Codes for SCT Inst R-transactions and EPC004-16 2025 v1.1 SCT Inst Scheme Rulebook", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms the CSM-only reject ('Settlement limit exceeded', AT-R004) and the 5/7/9-second timing; confirms the 2025 rulebook removed the scheme-level maximum amount under Article 5a(6) of the amended SEPA Regulation, per the change history. Does not address settlement cover mechanics beyond naming section 4.3." } ] }, "rail_name": "SEPA Instant Credit Transfer", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sct-inst:ARDT", "id": "ARDT", "rail": "sepa-sct-inst", "kind": "reason-code", "name": "Already returned (answer to a recall or RFRO)", "group": "administrative", "summary": "The Beneficiary PSP answers no because the Beneficiary has already sent the funds back by some other means.", "triggers": [ "The Beneficiary already paid the funds back to the Originator by SCT, SCT Inst or another payment method" ], "actions": [ "Originator and Originator PSP: check for the earlier repayment; the guidance lists no further action" ], "retry": { "allowed": false, "rule": "Not within the scheme. After the Beneficiary PSP answers, the Originator PSP may not send another recall or RFRO for the same SCT Inst Transaction (EPC004-16 2025 v1.1 sections 4.3.2.2 and 4.3.2.3). Any recovery is between Originator and Beneficiary." }, "facts": { "return_windows": [ { "action": "response to a recall", "by": "Beneficiary PSP", "deadline": "Within 15 Banking Business Days (T2 days) after it receives the recall; a later answer is a breach of the rulebook" }, { "action": "response to an RFRO", "by": "Beneficiary PSP", "deadline": "Within 15 Banking Business Days (T2 days) after it receives the RFRO; a later answer is a breach of the rulebook" } ], "applies_to": "SCT Inst" }, "caveat": "The rulebook has no exception process for a beneficiary who wants to send funds back; the Beneficiary arranges it with its PSP, for example as a new SCT Inst Transaction (EPC004-16 2025 v1.1 section 4.3.2.4). A negative answer ends the recall or RFRO; the Originator PSP may not send another one for the same transaction (EPC004-16 2025 v1.1 sections 4.3.2.2 and 4.3.2.3). Recovery then happens outside the scheme.", "related": [ "sepa-sct-inst:FOCR", "sepa-sct-inst:CUST", "sepa-sct-inst:NOOR" ], "basis": { "sources": "EPC059-18 v7.0 section 3, entry for ARDT; EPC004-16 2025 v1.1 section 4.3.2.2 and CT-02.01 to CT-02.07 (recall reasons, 10 Banking Business Days or 13 months, one recall, 15 Banking Business Day answer), 4.6.1 AT-R051 and AT-R057; chapter 7 (Banking Business Day is a T2 day); EPC004-16 2025 v1.1 section 4.3.2.3 and PR-03 steps 1 to 5 (13 months, one RFRO, 15 Banking Business Day answer), 4.6.1 AT-R071 and AT-R077; chapter 7 (Banking Business Day is a T2 day); EPC004-16 2025 v1.1 section 4.3.2.4 (no exception process for a beneficiary sending funds back).", "confidence": "high" }, "currency": { "effective_since": "2025-10-05", "effective_note": "EPC004-16 2025 v1.1 was issued and took effect on 2025-10-05 (03:30 CET); v1.1 changed only the unstructured address cut-off, to 15 November 2026. EPC059-18 v7.0 was published on 2025-10-05 and applies to the SCT Inst rulebook. The next SCT Inst rulebook is due for publication in November 2026 [Unverified].", "source_edition": "EPC059-18 v7.0; EPC004-16 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-10/EPC004-16%202025%20SCT%20Instant%20Rulebook%20v1.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC059-18 v7.0 Guidance on Reason Codes for SCT Inst R-transactions and EPC004-16 2025 v1.1 SCT Inst Scheme Rulebook", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms ARDT as a negative recall/RFRO response ('Already returned transaction', AT-R057 and AT-R077) and the 15 Banking Business Day windows; confirms section 4.3.2.4 has no exception process for a beneficiary sending funds back. Does not address a case where only part of the funds was already returned." } ] }, "rail_name": "SEPA Instant Credit Transfer", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sct-inst:BE04", "id": "BE04", "rail": "sepa-sct-inst", "kind": "reason-code", "name": "Beneficiary address missing or invalid", "group": "administrative", "summary": "The transaction lacks the Beneficiary's address where it is needed for further processing.", "triggers": [ "The Beneficiary's address is missing or invalid where later processing needs it" ], "actions": [ "Originator PSP: ask the Originator for the Beneficiary's address and send a new transaction" ], "retry": { "allowed": true, "rule": "Send a new SCT Inst Transaction with the address supplied. The scheme sets no retry limit [Unverified]." }, "facts": { "return_windows": [ { "action": "reject (negative confirmation message)", "by": "Beneficiary PSP", "deadline": "Instantly, inside the maximum execution time: the Originator PSP should hold a positive or negative confirmation no later than 5 seconds after the Time Stamp, and the Beneficiary PSP's answer must reach its own CSM no later than 7 seconds after it (time-out deadline)" } ], "applies_to": "SCT Inst" }, "caveat": "The rulebook lists 'account address invalid' as a Beneficiary PSP reject reason only (EPC004-16 2025 v1.1 section 4.6.1 AT-R004). The guidance does not say when an address is needed. From 15 November 2026 unstructured addresses are no longer allowed (rulebook v1.1 cover note); how that interacts with BE04 as against RR02 and RR03 is not stated.", "related": [ "sepa-sct-inst:RR02", "sepa-sct-inst:RR03" ], "basis": { "sources": "EPC059-18 v7.0 section 3, entry for BE04; EPC004-16 2025 v1.1 sections 4.3.2.1 (CT-01.05R, CT-01.06R), 4.2.3 B and C (5-second target, 7-second time-out) and 4.6.1 AT-R002 and AT-R004 (who may reject, reject reasons); EPC004-16 2025 v1.1 cover note (15 November 2026 address change).", "confidence": "high" }, "currency": { "effective_since": "2025-10-05", "effective_note": "EPC004-16 2025 v1.1 was issued and took effect on 2025-10-05 (03:30 CET); v1.1 changed only the unstructured address cut-off, to 15 November 2026. EPC059-18 v7.0 was published on 2025-10-05 and applies to the SCT Inst rulebook. The next SCT Inst rulebook is due for publication in November 2026 [Unverified].", "source_edition": "EPC059-18 v7.0; EPC004-16 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-10/EPC004-16%202025%20SCT%20Instant%20Rulebook%20v1.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC059-18 v7.0 Guidance on Reason Codes for SCT Inst R-transactions and EPC004-16 2025 v1.1 SCT Inst Scheme Rulebook", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms the Beneficiary-PSP-only reject ('Account address invalid', AT-R004) and the 5/7/9-second timing. Does not state how BE04 interacts with the November 2026 address format change, since the source does not say." } ] }, "rail_name": "SEPA Instant Credit Transfer", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sct-inst:CNOR", "id": "CNOR", "rail": "sepa-sct-inst", "kind": "reason-code", "name": "Beneficiary PSP not registered under this BIC in the CSM", "group": "network", "summary": "The CSM does not have the Beneficiary PSP registered as an SCT Inst participant under the BIC used.", "triggers": [ "The Beneficiary PSP is not, or no longer, a declared participant (direct or indirect) of this CSM" ], "actions": [ "Originator: ask the Beneficiary how it can receive SCT Inst through another PSP", "Originator PSP: check the Beneficiary PSP's reachability and route [Inference]" ], "retry": { "allowed": false, "rule": "Do not resend through the same CSM under the same BIC. Pay by a route or to a PSP that can receive SCT Inst." }, "facts": { "return_windows": [ { "action": "reject (negative confirmation message)", "by": "CSM", "deadline": "Instantly, inside the maximum execution time (target: with the Originator PSP no later than 5 seconds after the Time Stamp)" } ], "applies_to": "SCT Inst" }, "caveat": "A CSM reject reason in the rulebook (EPC004-16 2025 v1.1 section 4.6.1 AT-R004). Which CSMs reach which PSPs depends on arrangements between CSMs [Inference].", "related": [ "sepa-sct-inst:DNOR", "sepa-sct-inst:AG11", "sepa-sct-inst:RC01" ], "basis": { "sources": "EPC059-18 v7.0 section 3, entry for CNOR; EPC004-16 2025 v1.1 sections 4.3.2.1 (CT-01.05R, CT-01.06R), 4.2.3 B and C (5-second target, 7-second time-out) and 4.6.1 AT-R002 and AT-R004 (who may reject, reject reasons).", "confidence": "high" }, "currency": { "effective_since": "2025-10-05", "effective_note": "EPC004-16 2025 v1.1 was issued and took effect on 2025-10-05 (03:30 CET); v1.1 changed only the unstructured address cut-off, to 15 November 2026. EPC059-18 v7.0 was published on 2025-10-05 and applies to the SCT Inst rulebook. The next SCT Inst rulebook is due for publication in November 2026 [Unverified].", "source_edition": "EPC059-18 v7.0; EPC004-16 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-10/EPC004-16%202025%20SCT%20Instant%20Rulebook%20v1.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC059-18 v7.0 Guidance on Reason Codes for SCT Inst R-transactions and EPC004-16 2025 v1.1 SCT Inst Scheme Rulebook", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms the CSM-only reject ('Beneficiary PSP not registered under this BIC in the CSM', AT-R004) and the 5/7/9-second timing. Does not address which CSMs interoperate, since that is a bilateral matter outside the rulebook." } ] }, "rail_name": "SEPA Instant Credit Transfer", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sct-inst:CUST", "id": "CUST", "rail": "sepa-sct-inst", "kind": "reason-code", "name": "Requested by customer (RFRO reason, or Beneficiary refusal)", "group": "authorization", "summary": "Two uses. As an RFRO reason, the Originator wants a settled payment back and gives no specific reason. As an answer to a recall or RFRO, the Beneficiary refuses to return the funds.", "triggers": [ "RFRO: the Originator wants the funds of a settled transaction back without giving a particular reason", "Negative answer: the Beneficiary does not agree to the recall or RFRO, usually because it claims it is entitled to the funds" ], "actions": [ "RFRO: Originator PSP tells the Originator the request does not guarantee a refund (section 4.3.2.3)", "Negative answer: Originator (and Originator PSP, if the recall was for its own error) contacts the Beneficiary directly to recover the funds outside the scheme", "Where AM04 is barred by data protection law, CUST may stand for insufficient funds [Inference from the guidance note on AM04]" ], "retry": { "allowed": false, "rule": "Not within the scheme. After the Beneficiary PSP answers, the Originator PSP may not send another recall or RFRO for the same SCT Inst Transaction (EPC004-16 2025 v1.1 sections 4.3.2.2 and 4.3.2.3). Any recovery is between Originator and Beneficiary." }, "facts": { "return_windows": [ { "action": "request for recall by the originator (RFRO)", "by": "Originator PSP, at the Originator's request", "deadline": "The debit date of the SCT Inst Transaction must fall within the 13 months before the Originator PSP received the request; one RFRO per transaction, sent instantly or not" }, { "action": "response to a recall", "by": "Beneficiary PSP", "deadline": "Within 15 Banking Business Days (T2 days) after it receives the recall; a later answer is a breach of the rulebook" }, { "action": "response to an RFRO", "by": "Beneficiary PSP", "deadline": "Within 15 Banking Business Days (T2 days) after it receives the RFRO; a later answer is a breach of the rulebook" } ], "applies_to": "SCT Inst" }, "caveat": "The guidance tells Beneficiary PSPs to use CUST instead of AM04 where data protection law bars AM04 (EPC059-18 v7.0 section 3, AM04). The Beneficiary's decision on an RFRO settles the matter for both PSPs (EPC004-16 2025 v1.1 section 4.3.2.3, step 4B). A negative answer ends the recall or RFRO; the Originator PSP may not send another one for the same transaction (EPC004-16 2025 v1.1 sections 4.3.2.2 and 4.3.2.3). Recovery then happens outside the scheme.", "related": [ "sepa-sct-inst:AC03", "sepa-sct-inst:AM09", "sepa-sct-inst:AM04", "sepa-sct-inst:NOAS", "sepa-sct-inst:FOCR" ], "basis": { "sources": "EPC059-18 v7.0 section 3, entry for CUST and AM04; EPC004-16 2025 v1.1 section 4.3.2.2 and CT-02.01 to CT-02.07 (recall reasons, 10 Banking Business Days or 13 months, one recall, 15 Banking Business Day answer), 4.6.1 AT-R051 and AT-R057; chapter 7 (Banking Business Day is a T2 day); EPC004-16 2025 v1.1 section 4.3.2.3 and PR-03 steps 1 to 5 (13 months, one RFRO, 15 Banking Business Day answer), 4.6.1 AT-R071 and AT-R077; chapter 7 (Banking Business Day is a T2 day).", "confidence": "high" }, "currency": { "effective_since": "2025-10-05", "effective_note": "EPC004-16 2025 v1.1 was issued and took effect on 2025-10-05 (03:30 CET); v1.1 changed only the unstructured address cut-off, to 15 November 2026. EPC059-18 v7.0 was published on 2025-10-05 and applies to the SCT Inst rulebook. The next SCT Inst rulebook is due for publication in November 2026 [Unverified].", "source_edition": "EPC059-18 v7.0; EPC004-16 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-10/EPC004-16%202025%20SCT%20Instant%20Rulebook%20v1.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC059-18 v7.0 Guidance on Reason Codes for SCT Inst R-transactions and EPC004-16 2025 v1.1 SCT Inst Scheme Rulebook", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms both uses: the no-reason RFRO (AT-R071, 'By request of the Originator without any reason specified') and the negative recall/RFRO response ('Beneficiary's Refusal', AT-R057 and AT-R077); confirms the 13-month RFRO window and the 15 Banking Business Day response windows. Does not name the countries whose data protection law substitutes CUST for AM04." } ] }, "rail_name": "SEPA Instant Credit Transfer", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sct-inst:DNOR", "id": "DNOR", "rail": "sepa-sct-inst", "kind": "reason-code", "name": "Originator PSP not registered under this BIC in the CSM", "group": "network", "summary": "The CSM does not have the Originator PSP registered as an SCT Inst participant under the BIC used.", "triggers": [ "The Originator PSP is not, or no longer, registered at this CSM", "The Originator PSP sends to its former CSM by mistake" ], "actions": [ "Originator PSP: route the transaction to its current CSM", "Originator PSP: agree another means of payment with the Originator, such as SCT" ], "retry": { "allowed": true, "rule": "Send a new SCT Inst Transaction through the Originator PSP's current CSM. The scheme sets no retry limit [Unverified]." }, "facts": { "return_windows": [ { "action": "reject (negative confirmation message)", "by": "CSM", "deadline": "Instantly, inside the maximum execution time (target: with the Originator PSP no later than 5 seconds after the Time Stamp)" } ], "applies_to": "SCT Inst" }, "caveat": "A CSM reject reason in the rulebook (EPC004-16 2025 v1.1 section 4.6.1 AT-R004). The fault sits with the Originator PSP's routing, not with the Beneficiary.", "related": [ "sepa-sct-inst:CNOR", "sepa-sct-inst:AM23" ], "basis": { "sources": "EPC059-18 v7.0 section 3, entry for DNOR; EPC004-16 2025 v1.1 sections 4.3.2.1 (CT-01.05R, CT-01.06R), 4.2.3 B and C (5-second target, 7-second time-out) and 4.6.1 AT-R002 and AT-R004 (who may reject, reject reasons).", "confidence": "high" }, "currency": { "effective_since": "2025-10-05", "effective_note": "EPC004-16 2025 v1.1 was issued and took effect on 2025-10-05 (03:30 CET); v1.1 changed only the unstructured address cut-off, to 15 November 2026. EPC059-18 v7.0 was published on 2025-10-05 and applies to the SCT Inst rulebook. The next SCT Inst rulebook is due for publication in November 2026 [Unverified].", "source_edition": "EPC059-18 v7.0; EPC004-16 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-10/EPC004-16%202025%20SCT%20Instant%20Rulebook%20v1.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC059-18 v7.0 Guidance on Reason Codes for SCT Inst R-transactions and EPC004-16 2025 v1.1 SCT Inst Scheme Rulebook", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms the CSM-only reject ('Originator PSP not registered under this BIC in the CSM', AT-R004) and the 5/7/9-second timing." } ] }, "rail_name": "SEPA Instant Credit Transfer", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sct-inst:DUPL", "id": "DUPL", "rail": "sepa-sct-inst", "kind": "reason-code", "name": "Duplicate sending (recall reason)", "group": "administrative", "summary": "The Originator or Originator PSP found that a settled SCT Inst Transaction was sent twice and recalls the duplicate.", "triggers": [ "A technical or human error at the Originator or Originator PSP produced a duplicate transaction that settled" ], "actions": [ "Originator PSP: send the recall within 10 Banking Business Days of the execution date", "Originator and Originator PSP: put controls in place so duplicates are not created or exchanged again" ], "retry": { "allowed": false, "rule": "Only one recall may be sent for a given SCT Inst Transaction. After an answer, or 15 Banking Business Days with none, only a request for status update is allowed (EPC004-16 2025 v1.1 section 4.3.2.2)." }, "facts": { "return_windows": [ { "action": "recall", "by": "Originator PSP, on its own initiative or at the Originator's request", "deadline": "Sent within 10 Banking Business Days (T2 days) after the execution date of the SCT Inst Transaction; one recall per transaction" }, { "action": "response to a recall", "by": "Beneficiary PSP", "deadline": "Within 15 Banking Business Days (T2 days) after it receives the recall; a later answer is a breach of the rulebook" } ], "applies_to": "SCT Inst" }, "caveat": "A recall is a request: the Beneficiary PSP may answer no, and may charge a fee on a positive answer (EPC004-16 2025 v1.1 section 4.3.2.2). The Originator PSP may refuse the Originator's recall request if the reason does not fit or the period has passed (CT-02.01R). A duplicate caught before settlement is rejected with AM05.", "related": [ "sepa-sct-inst:AM05", "sepa-sct-inst:TECH", "sepa-sct-inst:FRAD", "sepa-sct-inst:FOCR" ], "basis": { "sources": "EPC059-18 v7.0 section 3, entry for DUPL; EPC004-16 2025 v1.1 section 4.3.2.2 and CT-02.01 to CT-02.07 (recall reasons, 10 Banking Business Days or 13 months, one recall, 15 Banking Business Day answer), 4.6.1 AT-R051 and AT-R057; chapter 7 (Banking Business Day is a T2 day).", "confidence": "high" }, "currency": { "effective_since": "2025-10-05", "effective_note": "EPC004-16 2025 v1.1 was issued and took effect on 2025-10-05 (03:30 CET); v1.1 changed only the unstructured address cut-off, to 15 November 2026. EPC059-18 v7.0 was published on 2025-10-05 and applies to the SCT Inst rulebook. The next SCT Inst rulebook is due for publication in November 2026 [Unverified].", "source_edition": "EPC059-18 v7.0; EPC004-16 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-10/EPC004-16%202025%20SCT%20Instant%20Rulebook%20v1.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC059-18 v7.0 Guidance on Reason Codes for SCT Inst R-transactions and EPC004-16 2025 v1.1 SCT Inst Scheme Rulebook", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms DUPL as one of the three recall reasons (AT-R051, 'Duplicate sending') and the 10 Banking Business Day window, one-recall rule and 15 Banking Business Day response deadline in section 4.3.2.2. Does not address a duplicate caught before settlement, which the record correctly routes to AM05 instead." } ] }, "rail_name": "SEPA Instant Credit Transfer", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sct-inst:FF01", "id": "FF01", "rail": "sepa-sct-inst", "kind": "reason-code", "name": "Invalid file format", "group": "technical", "summary": "The XML failed syntax or schema (XSD) validation.", "triggers": [ "The XML file was not filled in correctly", "The file contains a syntax error", "The Originator PSP or its CSM did not run an XSD check before submitting" ], "actions": [ "Repair the XML and send a new transaction", "Validate against the XSD before sending [Inference]" ], "retry": { "allowed": true, "rule": "Send a new SCT Inst Transaction in a corrected file. The scheme sets no retry limit [Unverified]." }, "facts": { "return_windows": [ { "action": "reject of the SCT Inst Instruction", "by": "Originator PSP", "deadline": "When it checks the instruction, before any SCT Inst Transaction is sent; the scheme only requires the Originator PSP to tell the Originator the reason" }, { "action": "reject (negative confirmation message)", "by": "CSM", "deadline": "Instantly, inside the maximum execution time (target: with the Originator PSP no later than 5 seconds after the Time Stamp)" }, { "action": "reject (negative confirmation message)", "by": "Beneficiary PSP", "deadline": "Instantly, inside the maximum execution time: the Originator PSP should hold a positive or negative confirmation no later than 5 seconds after the Time Stamp, and the Beneficiary PSP's answer must reach its own CSM no later than 7 seconds after it (time-out deadline)" } ], "applies_to": "SCT Inst" }, "caveat": "The guidance names the Originator, the Originator PSP and the CSM as possible sources of the error, not as senders. The rulebook lets the Originator PSP, a CSM and the Beneficiary PSP reject for an invalid format (EPC004-16 2025 v1.1 section 4.6.1 AT-R004).", "related": [ "sepa-sct-inst:AG02", "sepa-sct-inst:RC01" ], "basis": { "sources": "EPC059-18 v7.0 section 3, entry for FF01; EPC004-16 2025 v1.1 sections 4.3.2.1 (CT-01.05R, CT-01.06R), 4.2.3 B and C (5-second target, 7-second time-out) and 4.6.1 AT-R002 and AT-R004 (who may reject, reject reasons).", "confidence": "medium" }, "currency": { "effective_since": "2025-10-05", "effective_note": "EPC004-16 2025 v1.1 was issued and took effect on 2025-10-05 (03:30 CET); v1.1 changed only the unstructured address cut-off, to 15 November 2026. EPC059-18 v7.0 was published on 2025-10-05 and applies to the SCT Inst rulebook. The next SCT Inst rulebook is due for publication in November 2026 [Unverified].", "source_edition": "EPC059-18 v7.0; EPC004-16 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-10/EPC004-16%202025%20SCT%20Instant%20Rulebook%20v1.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC059-18 v7.0 Guidance on Reason Codes for SCT Inst R-transactions and EPC004-16 2025 v1.1 SCT Inst Scheme Rulebook", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms the three return windows against AT-R004's format-related reasons for Originator PSP, CSM and Beneficiary PSP, and the 5/7/9-second timing. Does not resolve which party typically sends the reject; the guidance names Originator, Originator PSP and CSM only as possible error sources, not as senders." } ] }, "rail_name": "SEPA Instant Credit Transfer", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sct-inst:FOCR", "id": "FOCR", "rail": "sepa-sct-inst", "kind": "reason-code", "name": "Positive answer to a recall or RFRO", "group": "administrative", "summary": "The Beneficiary PSP or the Beneficiary accepts the recall or RFRO, and the funds go back to the Originator PSP.", "triggers": [ "The Beneficiary PSP accepts a recall, debiting the Beneficiary's account where law and contract allow, with the Beneficiary's authorisation if needed", "The Beneficiary agrees to an RFRO" ], "actions": [ "Beneficiary PSP: send the positive answer in the message the Inter-PSP Implementation Guidelines prescribe, not as a new SCT Inst Transaction", "Beneficiary PSP: any fee is taken from the returned amount and shown in its own field", "Originator PSP: credit the Originator with the returned amount" ], "retry": { "allowed": false, "rule": "Not applicable. A positive answer closes the recall or RFRO." }, "facts": { "return_windows": [ { "action": "positive response to a recall", "by": "Beneficiary PSP", "deadline": "Within 15 Banking Business Days (T2 days) after it receives the recall; the returned amount settles through the CSMs on the Settlement Date in the answer" }, { "action": "positive response to an RFRO", "by": "Beneficiary PSP", "deadline": "Within 15 Banking Business Days (T2 days) after it receives the RFRO; the returned amount settles through the CSMs on the Settlement Date in the answer" } ], "applies_to": "SCT Inst" }, "caveat": "The returned amount may be less than the original if the Beneficiary PSP charges a fee; fees are allowed only on positive answers (EPC004-16 2025 v1.1 sections 4.3.2.2, 4.3.2.3, 4.6.1 AT-R054, AT-R055, AT-R074, AT-R075).", "related": [ "sepa-sct-inst:DUPL", "sepa-sct-inst:TECH", "sepa-sct-inst:FRAD", "sepa-sct-inst:AC03", "sepa-sct-inst:AM09", "sepa-sct-inst:CUST" ], "basis": { "sources": "EPC059-18 v7.0 section 3, entry for FOCR; EPC004-16 2025 v1.1 section 4.3.2.2 and CT-02.01 to CT-02.07 (recall reasons, 10 Banking Business Days or 13 months, one recall, 15 Banking Business Day answer), 4.6.1 AT-R051 and AT-R057; chapter 7 (Banking Business Day is a T2 day); EPC004-16 2025 v1.1 section 4.3.2.3 and PR-03 steps 1 to 5 (13 months, one RFRO, 15 Banking Business Day answer), 4.6.1 AT-R071 and AT-R077; chapter 7 (Banking Business Day is a T2 day); EPC004-16 2025 v1.1 sections 4.5.6 DS-06 and 4.5.9 DS-09.", "confidence": "high" }, "currency": { "effective_since": "2025-10-05", "effective_note": "EPC004-16 2025 v1.1 was issued and took effect on 2025-10-05 (03:30 CET); v1.1 changed only the unstructured address cut-off, to 15 November 2026. EPC059-18 v7.0 was published on 2025-10-05 and applies to the SCT Inst rulebook. The next SCT Inst rulebook is due for publication in November 2026 [Unverified].", "source_edition": "EPC059-18 v7.0; EPC004-16 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-10/EPC004-16%202025%20SCT%20Instant%20Rulebook%20v1.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC059-18 v7.0 Guidance on Reason Codes for SCT Inst R-transactions and EPC004-16 2025 v1.1 SCT Inst Scheme Rulebook", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms FOCR as the positive recall/RFRO response, sent by the Beneficiary PSP, against sections 4.3.2.2 and 4.3.2.3 (CT-02.04, PR-03 Step 4A) and the fee provisions in AT-R054, AT-R055, AT-R074 and AT-R075; confirms the 15 Banking Business Day windows." } ] }, "rail_name": "SEPA Instant Credit Transfer", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sct-inst:FRAD", "id": "FRAD", "rail": "sepa-sct-inst", "kind": "reason-code", "name": "Fraudulently originated (recall reason)", "group": "authorization", "summary": "The Originator or Originator PSP found a fraudulent SCT Inst Transaction and recalls it, up to 13 months after execution.", "triggers": [ "The Originator says it was the victim of a fraudulently executed transaction", "Fraudsters manipulated the Originator PSP's SCT Inst applications or systems to send transactions" ], "actions": [ "Originator PSP: send the recall within 13 months of the execution date; it may add free-text information for the Beneficiary PSP", "Originator and Originator PSP: put controls in place against such fraud" ], "retry": { "allowed": false, "rule": "Only one recall may be sent for a given SCT Inst Transaction. After an answer, or 15 Banking Business Days with none, only a request for status update is allowed (EPC004-16 2025 v1.1 section 4.3.2.2)." }, "facts": { "return_windows": [ { "action": "recall", "by": "Originator PSP, on its own initiative or at the Originator's request", "deadline": "Sent within 13 months after the execution date of the SCT Inst Transaction; one recall per transaction" }, { "action": "response to a recall", "by": "Beneficiary PSP", "deadline": "Within 15 Banking Business Days (T2 days) after it receives the recall; a later answer is a breach of the rulebook" } ], "applies_to": "SCT Inst" }, "caveat": "A recall is a request; the Beneficiary PSP may answer no (EPC004-16 2025 v1.1 section 4.3.2.2). Beneficiary PSPs need not act on the additional fraud information (section 4.6.1 AT-R052). The rulebook sets the 13-month period itself; the texts read do not tie it to any law. Authorised push payment scams are not separately named [Unverified whether they fall under this reason].", "related": [ "sepa-sct-inst:DUPL", "sepa-sct-inst:TECH", "sepa-sct-inst:FOCR", "sepa-sct-inst:LEGL" ], "basis": { "sources": "EPC059-18 v7.0 section 3, entry for FRAD; EPC004-16 2025 v1.1 section 4.3.2.2 and CT-02.01 to CT-02.07 (recall reasons, 10 Banking Business Days or 13 months, one recall, 15 Banking Business Day answer), 4.6.1 AT-R051 and AT-R057; chapter 7 (Banking Business Day is a T2 day); EPC004-16 2025 v1.1 section 4.6.1 AT-R052.", "confidence": "high" }, "currency": { "effective_since": "2025-10-05", "effective_note": "EPC004-16 2025 v1.1 was issued and took effect on 2025-10-05 (03:30 CET); v1.1 changed only the unstructured address cut-off, to 15 November 2026. EPC059-18 v7.0 was published on 2025-10-05 and applies to the SCT Inst rulebook. The next SCT Inst rulebook is due for publication in November 2026 [Unverified].", "source_edition": "EPC059-18 v7.0; EPC004-16 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-10/EPC004-16%202025%20SCT%20Instant%20Rulebook%20v1.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC059-18 v7.0 Guidance on Reason Codes for SCT Inst R-transactions and EPC004-16 2025 v1.1 SCT Inst Scheme Rulebook", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms FRAD as one of the three recall reasons (AT-R051, 'Fraudulent originated SCT Inst') and the 13-month window, one-recall rule and 15 Banking Business Day response deadline in section 4.3.2.2. Does not address whether authorised push payment scams fall under this reason." } ] }, "rail_name": "SEPA Instant Credit Transfer", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sct-inst:LEGL", "id": "LEGL", "rail": "sepa-sct-inst", "kind": "reason-code", "name": "Legal reasons (answer to a recall or RFRO)", "group": "administrative", "summary": "The Beneficiary PSP answers no because it is not legally allowed to return the funds.", "triggers": [ "A legal reason prevents the Beneficiary PSP from reimbursing the funds, for example a legal hold [Inference]" ], "actions": [ "Beneficiary PSP: explain the legal reason in clear text (CT-02.03R)", "Originator (and Originator PSP, if the recall was for its own error): contact the Beneficiary directly to recover the funds outside the scheme" ], "retry": { "allowed": false, "rule": "Not within the scheme. After the Beneficiary PSP answers, the Originator PSP may not send another recall or RFRO for the same SCT Inst Transaction (EPC004-16 2025 v1.1 sections 4.3.2.2 and 4.3.2.3). Any recovery is between Originator and Beneficiary." }, "facts": { "return_windows": [ { "action": "response to a recall", "by": "Beneficiary PSP", "deadline": "Within 15 Banking Business Days (T2 days) after it receives the recall; a later answer is a breach of the rulebook" }, { "action": "response to an RFRO", "by": "Beneficiary PSP", "deadline": "Within 15 Banking Business Days (T2 days) after it receives the RFRO; a later answer is a breach of the rulebook" } ], "applies_to": "SCT Inst" }, "caveat": "A negative answer ends the recall or RFRO; the Originator PSP may not send another one for the same transaction (EPC004-16 2025 v1.1 sections 4.3.2.2 and 4.3.2.3). Recovery then happens outside the scheme.", "related": [ "sepa-sct-inst:CUST", "sepa-sct-inst:AM04", "sepa-sct-inst:FRAD" ], "basis": { "sources": "EPC059-18 v7.0 section 3, entry for LEGL; EPC004-16 2025 v1.1 section 4.3.2.2 and CT-02.01 to CT-02.07 (recall reasons, 10 Banking Business Days or 13 months, one recall, 15 Banking Business Day answer), 4.6.1 AT-R051 and AT-R057; chapter 7 (Banking Business Day is a T2 day); EPC004-16 2025 v1.1 section 4.3.2.3 and PR-03 steps 1 to 5 (13 months, one RFRO, 15 Banking Business Day answer), 4.6.1 AT-R071 and AT-R077; chapter 7 (Banking Business Day is a T2 day).", "confidence": "high" }, "currency": { "effective_since": "2025-10-05", "effective_note": "EPC004-16 2025 v1.1 was issued and took effect on 2025-10-05 (03:30 CET); v1.1 changed only the unstructured address cut-off, to 15 November 2026. EPC059-18 v7.0 was published on 2025-10-05 and applies to the SCT Inst rulebook. The next SCT Inst rulebook is due for publication in November 2026 [Unverified].", "source_edition": "EPC059-18 v7.0; EPC004-16 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-10/EPC004-16%202025%20SCT%20Instant%20Rulebook%20v1.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC059-18 v7.0 Guidance on Reason Codes for SCT Inst R-transactions and EPC004-16 2025 v1.1 SCT Inst Scheme Rulebook", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms LEGL as a negative recall/RFRO response ('Legal reasons', AT-R057 and AT-R077) and the 15 Banking Business Day windows." } ] }, "rail_name": "SEPA Instant Credit Transfer", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sct-inst:MD07", "id": "MD07", "rail": "sepa-sct-inst", "kind": "reason-code", "name": "Beneficiary deceased", "group": "account", "summary": "The Beneficiary PSP rejects because the Beneficiary has died.", "triggers": [ "The Beneficiary is deceased" ], "actions": [ "The guidance lists no action", "Originator: stop further payments to this account and settle any obligation with the estate [Inference]" ], "retry": { "allowed": false, "rule": "Do not send to this Beneficiary again." }, "facts": { "return_windows": [ { "action": "reject (negative confirmation message)", "by": "Beneficiary PSP", "deadline": "Instantly, inside the maximum execution time: the Originator PSP should hold a positive or negative confirmation no later than 5 seconds after the Time Stamp, and the Beneficiary PSP's answer must reach its own CSM no later than 7 seconds after it (time-out deadline)" } ], "applies_to": "SCT Inst" }, "caveat": "The guidance notes that data protection law in certain SEPA countries bars this code and names MS03 as the alternative (EPC059-18 v7.0 section 3). It does not name the countries.", "related": [ "sepa-sct-inst:MS03", "sepa-sct-inst:AC04" ], "basis": { "sources": "EPC059-18 v7.0 section 3, entry for MD07; EPC004-16 2025 v1.1 sections 4.3.2.1 (CT-01.05R, CT-01.06R), 4.2.3 B and C (5-second target, 7-second time-out) and 4.6.1 AT-R002 and AT-R004 (who may reject, reject reasons).", "confidence": "high" }, "currency": { "effective_since": "2025-10-05", "effective_note": "EPC004-16 2025 v1.1 was issued and took effect on 2025-10-05 (03:30 CET); v1.1 changed only the unstructured address cut-off, to 15 November 2026. EPC059-18 v7.0 was published on 2025-10-05 and applies to the SCT Inst rulebook. The next SCT Inst rulebook is due for publication in November 2026 [Unverified].", "source_edition": "EPC059-18 v7.0; EPC004-16 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-10/EPC004-16%202025%20SCT%20Instant%20Rulebook%20v1.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC059-18 v7.0 Guidance on Reason Codes for SCT Inst R-transactions and EPC004-16 2025 v1.1 SCT Inst Scheme Rulebook", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms the Beneficiary-PSP-only reject ('Beneficiary deceased', AT-R004) and the 5/7/9-second timing. Does not name the countries whose data protection law bars this code." } ] }, "rail_name": "SEPA Instant Credit Transfer", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sct-inst:MS02", "id": "MS02", "rail": "sepa-sct-inst", "kind": "reason-code", "name": "Refusal by the Beneficiary", "group": "authorization", "summary": "The Beneficiary PSP rejects on the Beneficiary's standing instruction not to accept funds from a given account, Originator or scheme.", "triggers": [ "The Beneficiary told its PSP not to accept funds from a specific account, from a specific Originator, or through a specific payment scheme" ], "actions": [ "Originator: contact the Beneficiary directly to agree how to settle what is owed" ], "retry": { "allowed": false, "rule": "Do not send again while the Beneficiary's instruction stands. Agree another way to pay with the Beneficiary." }, "facts": { "return_windows": [ { "action": "reject (negative confirmation message)", "by": "Beneficiary PSP", "deadline": "Instantly, inside the maximum execution time: the Originator PSP should hold a positive or negative confirmation no later than 5 seconds after the Time Stamp, and the Beneficiary PSP's answer must reach its own CSM no later than 7 seconds after it (time-out deadline)" } ], "applies_to": "SCT Inst" }, "caveat": "The rulebook's reason is 'by order of the Beneficiary', a Beneficiary PSP reject reason (EPC004-16 2025 v1.1 section 4.6.1 AT-R004). A Beneficiary refusing a recall or RFRO after settlement is answered with CUST, not MS02.", "related": [ "sepa-sct-inst:MS03", "sepa-sct-inst:CUST" ], "basis": { "sources": "EPC059-18 v7.0 section 3, entry for MS02; EPC004-16 2025 v1.1 sections 4.3.2.1 (CT-01.05R, CT-01.06R), 4.2.3 B and C (5-second target, 7-second time-out) and 4.6.1 AT-R002 and AT-R004 (who may reject, reject reasons).", "confidence": "high" }, "currency": { "effective_since": "2025-10-05", "effective_note": "EPC004-16 2025 v1.1 was issued and took effect on 2025-10-05 (03:30 CET); v1.1 changed only the unstructured address cut-off, to 15 November 2026. EPC059-18 v7.0 was published on 2025-10-05 and applies to the SCT Inst rulebook. The next SCT Inst rulebook is due for publication in November 2026 [Unverified].", "source_edition": "EPC059-18 v7.0; EPC004-16 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-10/EPC004-16%202025%20SCT%20Instant%20Rulebook%20v1.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC059-18 v7.0 Guidance on Reason Codes for SCT Inst R-transactions and EPC004-16 2025 v1.1 SCT Inst Scheme Rulebook", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms the Beneficiary-PSP-only reject ('By order of the Beneficiary', AT-R004) and the 5/7/9-second timing." } ] }, "rail_name": "SEPA Instant Credit Transfer", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sct-inst:MS03", "id": "MS03", "rail": "sepa-sct-inst", "kind": "reason-code", "name": "Reason not specified", "group": "administrative", "summary": "A reject with no stated reason. Only for cases where national law, such as data protection law, bars the precise code.", "triggers": [ "National law bars the Beneficiary PSP from using AC04, RR01, RR02, RR03 or RR04", "The guidance also names MS03 as the alternative to MD07" ], "actions": [ "Sender: limit MS03 and pick the precise code where allowed", "Originator: contact the Beneficiary directly to agree how to settle what is owed" ], "retry": { "allowed": false, "rule": "The scheme sets no rule; the underlying reason is unknown. Contact the Beneficiary before paying again [Inference]." }, "facts": { "return_windows": [ { "action": "reject of the SCT Inst Instruction", "by": "Originator PSP", "deadline": "When it checks the instruction, before any SCT Inst Transaction is sent; the scheme only requires the Originator PSP to tell the Originator the reason" }, { "action": "reject (negative confirmation message)", "by": "CSM", "deadline": "Instantly, inside the maximum execution time (target: with the Originator PSP no later than 5 seconds after the Time Stamp)" }, { "action": "reject (negative confirmation message)", "by": "Beneficiary PSP", "deadline": "Instantly, inside the maximum execution time: the Originator PSP should hold a positive or negative confirmation no later than 5 seconds after the Time Stamp, and the Beneficiary PSP's answer must reach its own CSM no later than 7 seconds after it (time-out deadline)" } ], "applies_to": "SCT Inst" }, "caveat": "The rulebook lists 'reason not specified' for the Originator PSP, a CSM and the Beneficiary PSP (EPC004-16 2025 v1.1 section 4.6.1 AT-R004), but the guidance frames MS03 as a Beneficiary PSP fallback where national law bars a precise code. The guidance's MS03 entry names AC04 and RR01 to RR04 as the codes it replaces. The MD07 entry also names MS03 as its alternative, while the RR01 entry carries no data protection note, so the lists do not match.", "related": [ "sepa-sct-inst:AC04", "sepa-sct-inst:MD07", "sepa-sct-inst:RR01", "sepa-sct-inst:RR02", "sepa-sct-inst:RR03", "sepa-sct-inst:RR04", "sepa-sct-inst:MS02" ], "basis": { "sources": "EPC059-18 v7.0 section 3, entry for MS03, AC04, MD07, RR02, RR03, RR04; EPC004-16 2025 v1.1 sections 4.3.2.1 (CT-01.05R, CT-01.06R), 4.2.3 B and C (5-second target, 7-second time-out) and 4.6.1 AT-R002 and AT-R004 (who may reject, reject reasons).", "confidence": "high" }, "currency": { "effective_since": "2025-10-05", "effective_note": "EPC004-16 2025 v1.1 was issued and took effect on 2025-10-05 (03:30 CET); v1.1 changed only the unstructured address cut-off, to 15 November 2026. EPC059-18 v7.0 was published on 2025-10-05 and applies to the SCT Inst rulebook. The next SCT Inst rulebook is due for publication in November 2026 [Unverified].", "source_edition": "EPC059-18 v7.0; EPC004-16 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-10/EPC004-16%202025%20SCT%20Instant%20Rulebook%20v1.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC059-18 v7.0 Guidance on Reason Codes for SCT Inst R-transactions and EPC004-16 2025 v1.1 SCT Inst Scheme Rulebook", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms the three return windows against AT-R004's 'Reason not specified' entries for Originator PSP, CSM and Beneficiary PSP, and the 5/7/9-second timing; confirms the guidance's own MS03 entry names AC04, RR01, RR02, RR03 and RR04 as the codes it can replace. Notes, as the record itself does, that RR01's individual guidance entry carries no matching data-protection footnote, an inconsistency in the source itself." } ] }, "rail_name": "SEPA Instant Credit Transfer", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "jurisdiction", "label": "the country", "needs": "which country the payment or the account is in", "detail": "The rulebook lists 'reason not specified' for the Originator PSP, a CSM and the Beneficiary PSP (EPC004-16 2025 v1.1 section 4.6.1 AT-R004), but the guidance frames MS03 as a Beneficiary PSP fallback where national law bars a precise code.", "from": "caveat" } ] }, { "uid": "sepa-sct-inst:NOAS", "id": "NOAS", "rail": "sepa-sct-inst", "kind": "reason-code", "name": "No answer from the Beneficiary", "group": "authorization", "summary": "The Beneficiary PSP answers no to a recall or RFRO because the Beneficiary did not respond within 15 Banking Business Days.", "triggers": [ "The Beneficiary PSP cannot reach the Beneficiary", "The Beneficiary does not answer the Beneficiary PSP's request for authorisation to return the funds" ], "actions": [ "Beneficiary PSP: send this negative answer when the 15 Banking Business Days end with no word from the Beneficiary; the rulebook requires it", "Originator (and Originator PSP, if the recall was for its own error): contact the Beneficiary directly to recover the funds outside the scheme" ], "retry": { "allowed": false, "rule": "Not within the scheme. After the Beneficiary PSP answers, the Originator PSP may not send another recall or RFRO for the same SCT Inst Transaction (EPC004-16 2025 v1.1 sections 4.3.2.2 and 4.3.2.3). Any recovery is between Originator and Beneficiary." }, "facts": { "return_windows": [ { "action": "response to a recall", "by": "Beneficiary PSP", "deadline": "Within 15 Banking Business Days (T2 days) after it receives the recall; a later answer is a breach of the rulebook" }, { "action": "response to an RFRO", "by": "Beneficiary PSP", "deadline": "Within 15 Banking Business Days (T2 days) after it receives the RFRO; a later answer is a breach of the rulebook" } ], "applies_to": "SCT Inst" }, "caveat": "NOAS is the Beneficiary's silence, not the Beneficiary PSP's. If the Beneficiary PSP itself does not answer within 15 Banking Business Days, the Originator PSP may send a request for status update (EPC004-16 2025 v1.1 sections 4.3.2.2 and 4.3.2.3). A negative answer ends the recall or RFRO; the Originator PSP may not send another one for the same transaction (EPC004-16 2025 v1.1 sections 4.3.2.2 and 4.3.2.3). Recovery then happens outside the scheme.", "related": [ "sepa-sct-inst:CUST", "sepa-sct-inst:AC03", "sepa-sct-inst:AM09", "sepa-sct-inst:FOCR" ], "basis": { "sources": "EPC059-18 v7.0 section 3, entry for NOAS; EPC004-16 2025 v1.1 section 4.3.2.2 and CT-02.01 to CT-02.07 (recall reasons, 10 Banking Business Days or 13 months, one recall, 15 Banking Business Day answer), 4.6.1 AT-R051 and AT-R057; chapter 7 (Banking Business Day is a T2 day); EPC004-16 2025 v1.1 section 4.3.2.3 and PR-03 steps 1 to 5 (13 months, one RFRO, 15 Banking Business Day answer), 4.6.1 AT-R071 and AT-R077; chapter 7 (Banking Business Day is a T2 day).", "confidence": "high" }, "currency": { "effective_since": "2025-10-05", "effective_note": "EPC004-16 2025 v1.1 was issued and took effect on 2025-10-05 (03:30 CET); v1.1 changed only the unstructured address cut-off, to 15 November 2026. EPC059-18 v7.0 was published on 2025-10-05 and applies to the SCT Inst rulebook. The next SCT Inst rulebook is due for publication in November 2026 [Unverified].", "source_edition": "EPC059-18 v7.0; EPC004-16 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-10/EPC004-16%202025%20SCT%20Instant%20Rulebook%20v1.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC059-18 v7.0 Guidance on Reason Codes for SCT Inst R-transactions and EPC004-16 2025 v1.1 SCT Inst Scheme Rulebook", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms NOAS as a negative recall/RFRO response ('No response from Beneficiary', AT-R057 and AT-R077) and the 15 Banking Business Day windows." } ] }, "rail_name": "SEPA Instant Credit Transfer", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sct-inst:NOOR", "id": "NOOR", "rail": "sepa-sct-inst", "kind": "reason-code", "name": "Original transaction never received (answer to a recall or RFRO)", "group": "administrative", "summary": "The Beneficiary PSP or Beneficiary answers no because it never received the SCT Inst Transaction the recall or RFRO refers to.", "triggers": [ "The recall or RFRO was sent to the wrong Beneficiary PSP" ], "actions": [ "Originator PSP: send the recall or RFRO to the correct Beneficiary PSP or Beneficiary" ], "retry": { "allowed": false, "rule": "The guidance tells the Originator PSP to address the right Beneficiary PSP, but the rulebook bars a second recall or RFRO on the same transaction once an answer is given (EPC004-16 2025 v1.1 sections 4.3.2.2 and 4.3.2.3). How the two fit is not stated [Unverified]." }, "facts": { "return_windows": [ { "action": "response to a recall", "by": "Beneficiary PSP", "deadline": "Within 15 Banking Business Days (T2 days) after it receives the recall; a later answer is a breach of the rulebook" }, { "action": "response to an RFRO", "by": "Beneficiary PSP", "deadline": "Within 15 Banking Business Days (T2 days) after it receives the RFRO; a later answer is a breach of the rulebook" } ], "applies_to": "SCT Inst" }, "caveat": "Recalls and RFROs must follow the same path as the original transaction (EPC004-16 2025 v1.1 sections 4.3.2.2 and 4.3.2.3), so a misrouted request points to an error in the Originator PSP's records [Inference]. AG09 is the matching code for a status investigation.", "related": [ "sepa-sct-inst:AG09", "sepa-sct-inst:ARDT", "sepa-sct-inst:CUST" ], "basis": { "sources": "EPC059-18 v7.0 section 3, entry for NOOR; EPC004-16 2025 v1.1 section 4.3.2.2 and CT-02.01 to CT-02.07 (recall reasons, 10 Banking Business Days or 13 months, one recall, 15 Banking Business Day answer), 4.6.1 AT-R051 and AT-R057; chapter 7 (Banking Business Day is a T2 day); EPC004-16 2025 v1.1 section 4.3.2.3 and PR-03 steps 1 to 5 (13 months, one RFRO, 15 Banking Business Day answer), 4.6.1 AT-R071 and AT-R077; chapter 7 (Banking Business Day is a T2 day).", "confidence": "medium" }, "currency": { "effective_since": "2025-10-05", "effective_note": "EPC004-16 2025 v1.1 was issued and took effect on 2025-10-05 (03:30 CET); v1.1 changed only the unstructured address cut-off, to 15 November 2026. EPC059-18 v7.0 was published on 2025-10-05 and applies to the SCT Inst rulebook. The next SCT Inst rulebook is due for publication in November 2026 [Unverified].", "source_edition": "EPC059-18 v7.0; EPC004-16 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-10/EPC004-16%202025%20SCT%20Instant%20Rulebook%20v1.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC059-18 v7.0 Guidance on Reason Codes for SCT Inst R-transactions and EPC004-16 2025 v1.1 SCT Inst Scheme Rulebook", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms NOOR as a negative recall/RFRO response ('Original Credit Transfer never received' / 'Initial SCT Inst Transaction never received', AT-R057 and AT-R077) and the 15 Banking Business Day windows. Does not resolve how the one-recall and one-RFRO rules apply after a NOOR answer." } ] }, "rail_name": "SEPA Instant Credit Transfer", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sct-inst:RC01", "id": "RC01", "rail": "sepa-sct-inst", "kind": "reason-code", "name": "PSP identifier incorrect (invalid BIC)", "group": "technical", "summary": "The BIC is wrong: incomplete for a non-EEA SEPA payment, or not found in the receiving party's BIC directory.", "triggers": [ "The Originator gave an 8-character BIC instead of 11 characters for a non-EEA SEPA SCT Inst", "The BIC in the inter-PSP message does not exist in the CSM's or Beneficiary PSP's BIC database" ], "actions": [ "Originator: get the correct BIC from the Beneficiary for a non-EEA SEPA payment", "Originator PSP: put the correct, complete Beneficiary PSP BIC in the inter-PSP message" ], "retry": { "allowed": true, "rule": "Send a new SCT Inst Transaction with the correct BIC. The scheme sets no retry limit [Unverified]." }, "facts": { "return_windows": [ { "action": "reject of the SCT Inst Instruction", "by": "Originator PSP", "deadline": "When it checks the instruction, before any SCT Inst Transaction is sent; the scheme only requires the Originator PSP to tell the Originator the reason" }, { "action": "reject (negative confirmation message)", "by": "CSM", "deadline": "Instantly, inside the maximum execution time (target: with the Originator PSP no later than 5 seconds after the Time Stamp)" }, { "action": "reject (negative confirmation message)", "by": "Beneficiary PSP", "deadline": "Instantly, inside the maximum execution time: the Originator PSP should hold a positive or negative confirmation no later than 5 seconds after the Time Stamp, and the Beneficiary PSP's answer must reach its own CSM no later than 7 seconds after it (time-out deadline)" } ], "applies_to": "SCT Inst" }, "caveat": "The Originator must supply the Beneficiary PSP's BIC only if the Originator PSP asks for it and at least one PSP is in a non-EEA SEPA country or territory (EPC004-16 2025 v1.1 section 5.7).", "related": [ "sepa-sct-inst:CNOR", "sepa-sct-inst:AG02", "sepa-sct-inst:FF01" ], "basis": { "sources": "EPC059-18 v7.0 section 3, entry for RC01; EPC004-16 2025 v1.1 sections 4.3.2.1 (CT-01.05R, CT-01.06R), 4.2.3 B and C (5-second target, 7-second time-out) and 4.6.1 AT-R002 and AT-R004 (who may reject, reject reasons); EPC004-16 2025 v1.1 section 5.7 (BIC precondition).", "confidence": "high" }, "currency": { "effective_since": "2025-10-05", "effective_note": "EPC004-16 2025 v1.1 was issued and took effect on 2025-10-05 (03:30 CET); v1.1 changed only the unstructured address cut-off, to 15 November 2026. EPC059-18 v7.0 was published on 2025-10-05 and applies to the SCT Inst rulebook. The next SCT Inst rulebook is due for publication in November 2026 [Unverified].", "source_edition": "EPC059-18 v7.0; EPC004-16 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-10/EPC004-16%202025%20SCT%20Instant%20Rulebook%20v1.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC059-18 v7.0 Guidance on Reason Codes for SCT Inst R-transactions and EPC004-16 2025 v1.1 SCT Inst Scheme Rulebook", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms the three return windows against AT-R004's BIC-related reasons for Originator PSP, CSM and Beneficiary PSP, the 5/7/9-second timing, and the non-EEA BIC precondition in section 5.7." } ] }, "rail_name": "SEPA Instant Credit Transfer", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sct-inst:RR01", "id": "RR01", "rail": "sepa-sct-inst", "kind": "reason-code", "name": "Regulatory reason: Originator account or identification missing", "group": "administrative", "summary": "The Originator's account details or unique identification, needed for regulatory reasons, are missing or insufficient.", "triggers": [ "The Originator's account or identification data is incomplete for regulatory requirements" ], "actions": [ "Originator PSP: check the transaction, complete the Originator's account details if needed, and send a new transaction" ], "retry": { "allowed": true, "rule": "Send a new SCT Inst Transaction with the Originator's details completed. The scheme sets no retry limit [Unverified]." }, "facts": { "return_windows": [ { "action": "reject of the SCT Inst Instruction", "by": "Originator PSP", "deadline": "When it checks the instruction, before any SCT Inst Transaction is sent; the scheme only requires the Originator PSP to tell the Originator the reason" }, { "action": "reject (negative confirmation message)", "by": "CSM", "deadline": "Instantly, inside the maximum execution time (target: with the Originator PSP no later than 5 seconds after the Time Stamp)" }, { "action": "reject (negative confirmation message)", "by": "Beneficiary PSP", "deadline": "Instantly, inside the maximum execution time: the Originator PSP should hold a positive or negative confirmation no later than 5 seconds after the Time Stamp, and the Beneficiary PSP's answer must reach its own CSM no later than 7 seconds after it (time-out deadline)" } ], "applies_to": "SCT Inst" }, "caveat": "The rulebook's reason is the general 'regulatory reason', listed for the Originator PSP, a CSM and the Beneficiary PSP (EPC004-16 2025 v1.1 section 4.6.1 AT-R004). The guidance's MS03 entry lists RR01 among codes national law may bar, but its RR01 entry has no such note.", "related": [ "sepa-sct-inst:RR02", "sepa-sct-inst:RR03", "sepa-sct-inst:RR04", "sepa-sct-inst:MS03" ], "basis": { "sources": "EPC059-18 v7.0 section 3, entry for RR01 and MS03; EPC004-16 2025 v1.1 sections 4.3.2.1 (CT-01.05R, CT-01.06R), 4.2.3 B and C (5-second target, 7-second time-out) and 4.6.1 AT-R002 and AT-R004 (who may reject, reject reasons).", "confidence": "high" }, "currency": { "effective_since": "2025-10-05", "effective_note": "EPC004-16 2025 v1.1 was issued and took effect on 2025-10-05 (03:30 CET); v1.1 changed only the unstructured address cut-off, to 15 November 2026. EPC059-18 v7.0 was published on 2025-10-05 and applies to the SCT Inst rulebook. The next SCT Inst rulebook is due for publication in November 2026 [Unverified].", "source_edition": "EPC059-18 v7.0; EPC004-16 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-10/EPC004-16%202025%20SCT%20Instant%20Rulebook%20v1.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC059-18 v7.0 Guidance on Reason Codes for SCT Inst R-transactions and EPC004-16 2025 v1.1 SCT Inst Scheme Rulebook", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms the three return windows against AT-R004's 'Regulatory reason' entries for Originator PSP, CSM and Beneficiary PSP, and the 5/7/9-second timing. Notes the guidance's RR01 entry carries no data-protection footnote even though the MS03 entry lists RR01 among the codes it can replace, an inconsistency in the source itself." } ] }, "rail_name": "SEPA Instant Credit Transfer", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "jurisdiction", "label": "the country", "needs": "which country the payment or the account is in", "detail": "The guidance's MS03 entry lists RR01 among codes national law may bar, but its RR01 entry has no such note.", "from": "caveat" } ] }, { "uid": "sepa-sct-inst:RR02", "id": "RR02", "rail": "sepa-sct-inst", "kind": "reason-code", "name": "Regulatory reason: Originator name or address missing or invalid", "group": "administrative", "summary": "The Originator's name is missing, or its address is missing where required or in a format no longer allowed.", "triggers": [ "The Originator's name is missing (the address is optional for EEA transactions)", "The Originator's address is missing on a non-EEA SCT Inst", "The Originator's address format is invalid or no longer allowed, for example unstructured after the November 2026 cut-off" ], "actions": [ "Originator PSP: complete the Originator's name and address and send a new transaction", "Originator PSP: move to structured or hybrid addresses before 15 November 2026 (rulebook v1.1 cover note)" ], "retry": { "allowed": true, "rule": "Send a new SCT Inst Transaction with the name and address completed. The scheme sets no retry limit [Unverified]." }, "facts": { "return_windows": [ { "action": "reject of the SCT Inst Instruction", "by": "Originator PSP", "deadline": "When it checks the instruction, before any SCT Inst Transaction is sent; the scheme only requires the Originator PSP to tell the Originator the reason" }, { "action": "reject (negative confirmation message)", "by": "CSM", "deadline": "Instantly, inside the maximum execution time (target: with the Originator PSP no later than 5 seconds after the Time Stamp)" }, { "action": "reject (negative confirmation message)", "by": "Beneficiary PSP", "deadline": "Instantly, inside the maximum execution time: the Originator PSP should hold a positive or negative confirmation no later than 5 seconds after the Time Stamp, and the Beneficiary PSP's answer must reach its own CSM no later than 7 seconds after it (time-out deadline)" } ], "applies_to": "SCT Inst" }, "caveat": "The guidance notes that data protection law in certain SEPA countries bars this code and names MS03 as the alternative (EPC059-18 v7.0 section 3). It does not name the countries. The guidance says 'November 2026'; rulebook v1.1 moved the unstructured address cut-off from 22 to 15 November 2026.", "related": [ "sepa-sct-inst:RR01", "sepa-sct-inst:RR03", "sepa-sct-inst:RR04", "sepa-sct-inst:BE04", "sepa-sct-inst:MS03" ], "basis": { "sources": "EPC059-18 v7.0 section 3, entry for RR02; EPC004-16 2025 v1.1 sections 4.3.2.1 (CT-01.05R, CT-01.06R), 4.2.3 B and C (5-second target, 7-second time-out) and 4.6.1 AT-R002 and AT-R004 (who may reject, reject reasons); EPC004-16 2025 v1.1 cover note and Annex IV (address format change).", "confidence": "high" }, "currency": { "effective_since": "2025-10-05", "effective_note": "EPC004-16 2025 v1.1 was issued and took effect on 2025-10-05 (03:30 CET); v1.1 changed only the unstructured address cut-off, to 15 November 2026. EPC059-18 v7.0 was published on 2025-10-05 and applies to the SCT Inst rulebook. The next SCT Inst rulebook is due for publication in November 2026 [Unverified].", "source_edition": "EPC059-18 v7.0; EPC004-16 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-10/EPC004-16%202025%20SCT%20Instant%20Rulebook%20v1.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC059-18 v7.0 Guidance on Reason Codes for SCT Inst R-transactions and EPC004-16 2025 v1.1 SCT Inst Scheme Rulebook", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms the three return windows against AT-R004's 'Regulatory reason' entries, the 5/7/9-second timing, and the November 2026 unstructured-address cut-off in the rulebook's cover note and change history, which give 15 November 2026, not 22 November." } ] }, "rail_name": "SEPA Instant Credit Transfer", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sct-inst:RR03", "id": "RR03", "rail": "sepa-sct-inst", "kind": "reason-code", "name": "Regulatory reason: Beneficiary name or address missing or invalid", "group": "administrative", "summary": "The Beneficiary's name is missing, or its address is in a format no longer allowed.", "triggers": [ "The Beneficiary's name is missing (the address is optional)", "The Beneficiary's address format is invalid or no longer allowed, for example unstructured after the November 2026 cut-off" ], "actions": [ "Originator PSP: complete the Beneficiary's name and send a new transaction" ], "retry": { "allowed": true, "rule": "Send a new SCT Inst Transaction with the Beneficiary's name completed. The scheme sets no retry limit [Unverified]." }, "facts": { "return_windows": [ { "action": "reject of the SCT Inst Instruction", "by": "Originator PSP", "deadline": "When it checks the instruction, before any SCT Inst Transaction is sent; the scheme only requires the Originator PSP to tell the Originator the reason" }, { "action": "reject (negative confirmation message)", "by": "CSM", "deadline": "Instantly, inside the maximum execution time (target: with the Originator PSP no later than 5 seconds after the Time Stamp)" }, { "action": "reject (negative confirmation message)", "by": "Beneficiary PSP", "deadline": "Instantly, inside the maximum execution time: the Originator PSP should hold a positive or negative confirmation no later than 5 seconds after the Time Stamp, and the Beneficiary PSP's answer must reach its own CSM no later than 7 seconds after it (time-out deadline)" } ], "applies_to": "SCT Inst" }, "caveat": "The guidance notes that data protection law in certain SEPA countries bars this code and names MS03 as the alternative (EPC059-18 v7.0 section 3). It does not name the countries. The guidance says 'November 2026'; rulebook v1.1 moved the unstructured address cut-off from 22 to 15 November 2026.", "related": [ "sepa-sct-inst:RR01", "sepa-sct-inst:RR02", "sepa-sct-inst:RR04", "sepa-sct-inst:BE04", "sepa-sct-inst:MS03" ], "basis": { "sources": "EPC059-18 v7.0 section 3, entry for RR03; EPC004-16 2025 v1.1 sections 4.3.2.1 (CT-01.05R, CT-01.06R), 4.2.3 B and C (5-second target, 7-second time-out) and 4.6.1 AT-R002 and AT-R004 (who may reject, reject reasons); EPC004-16 2025 v1.1 cover note and Annex IV (address format change).", "confidence": "high" }, "currency": { "effective_since": "2025-10-05", "effective_note": "EPC004-16 2025 v1.1 was issued and took effect on 2025-10-05 (03:30 CET); v1.1 changed only the unstructured address cut-off, to 15 November 2026. EPC059-18 v7.0 was published on 2025-10-05 and applies to the SCT Inst rulebook. The next SCT Inst rulebook is due for publication in November 2026 [Unverified].", "source_edition": "EPC059-18 v7.0; EPC004-16 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-10/EPC004-16%202025%20SCT%20Instant%20Rulebook%20v1.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC059-18 v7.0 Guidance on Reason Codes for SCT Inst R-transactions and EPC004-16 2025 v1.1 SCT Inst Scheme Rulebook", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms the three return windows against AT-R004's 'Regulatory reason' entries, the 5/7/9-second timing, and the November 2026 address cut-off, same basis as RR02." } ] }, "rail_name": "SEPA Instant Credit Transfer", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sct-inst:RR04", "id": "RR04", "rail": "sepa-sct-inst", "kind": "reason-code", "name": "Regulatory reason", "group": "administrative", "summary": "A regulatory reject for reasons other than those covered by RR01, RR02 and RR03, such as a possible anti-money laundering, embargo or terrorist financing hit.", "triggers": [ "A potential match in anti-money laundering, embargo or counter-terrorist financing screening" ], "actions": [ "Originator: contact the Originator PSP" ], "retry": { "allowed": false, "rule": "The scheme sets no rule. Do not resend until the Originator PSP has cleared the reason [Inference]." }, "facts": { "return_windows": [ { "action": "reject of the SCT Inst Instruction", "by": "Originator PSP", "deadline": "When it checks the instruction, before any SCT Inst Transaction is sent; the scheme only requires the Originator PSP to tell the Originator the reason" }, { "action": "reject (negative confirmation message)", "by": "CSM", "deadline": "Instantly, inside the maximum execution time (target: with the Originator PSP no later than 5 seconds after the Time Stamp)" }, { "action": "reject (negative confirmation message)", "by": "Beneficiary PSP", "deadline": "Instantly, inside the maximum execution time: the Originator PSP should hold a positive or negative confirmation no later than 5 seconds after the Time Stamp, and the Beneficiary PSP's answer must reach its own CSM no later than 7 seconds after it (time-out deadline)" } ], "applies_to": "SCT Inst" }, "caveat": "The guidance notes that data protection law in certain SEPA countries bars this code and names MS03 as the alternative (EPC059-18 v7.0 section 3). It does not name the countries. The rulebook allows execution to be stopped for regulatory requirements (EPC004-16 2025 v1.1 section 4.2.1). The EU Instant Payments Regulation changed how PSPs screen for sanctions; the EPC texts read do not describe that change, so it is not recorded here.", "related": [ "sepa-sct-inst:RR01", "sepa-sct-inst:RR02", "sepa-sct-inst:RR03", "sepa-sct-inst:MS03" ], "basis": { "sources": "EPC059-18 v7.0 section 3, entry for RR04; EPC004-16 2025 v1.1 sections 4.3.2.1 (CT-01.05R, CT-01.06R), 4.2.3 B and C (5-second target, 7-second time-out) and 4.6.1 AT-R002 and AT-R004 (who may reject, reject reasons); EPC004-16 2025 v1.1 section 4.2.1.", "confidence": "medium" }, "currency": { "effective_since": "2025-10-05", "effective_note": "EPC004-16 2025 v1.1 was issued and took effect on 2025-10-05 (03:30 CET); v1.1 changed only the unstructured address cut-off, to 15 November 2026. EPC059-18 v7.0 was published on 2025-10-05 and applies to the SCT Inst rulebook. The next SCT Inst rulebook is due for publication in November 2026 [Unverified].", "source_edition": "EPC059-18 v7.0; EPC004-16 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-10/EPC004-16%202025%20SCT%20Instant%20Rulebook%20v1.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC059-18 v7.0 Guidance on Reason Codes for SCT Inst R-transactions and EPC004-16 2025 v1.1 SCT Inst Scheme Rulebook", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms the three return windows against AT-R004's 'Regulatory reason' entries, the 5/7/9-second timing, and the AML/embargo/counter-terrorist-financing trigger in the guidance. Does not address how the Instant Payments Regulation's sanctions-screening change interacts with RR04, since the rulebook text does not describe it." } ] }, "rail_name": "SEPA Instant Credit Transfer", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "judgement", "label": "a sanctions check", "needs": "the outcome of sanctions, AML or KYC screening", "detail": "The EU Instant Payments Regulation changed how PSPs screen for sanctions; the EPC texts read do not describe that change, so it is not recorded here.", "from": "caveat" } ] }, { "uid": "sepa-sct-inst:TECH", "id": "TECH", "rail": "sepa-sct-inst", "kind": "reason-code", "name": "Technical problem (recall reason)", "group": "technical", "summary": "The Originator or Originator PSP found that a technical problem produced erroneous SCT Inst Transactions and recalls them.", "triggers": [ "A technical fault in the Originator's own systems while creating instructions or files", "A technical fault in the Originator PSP's SCT Inst systems while handling instructions or converting them into transactions" ], "actions": [ "Originator PSP: send the recall within 10 Banking Business Days of the execution date", "Originator and Originator PSP: put controls in place against such faults" ], "retry": { "allowed": false, "rule": "Only one recall may be sent for a given SCT Inst Transaction. After an answer, or 15 Banking Business Days with none, only a request for status update is allowed (EPC004-16 2025 v1.1 section 4.3.2.2)." }, "facts": { "return_windows": [ { "action": "recall", "by": "Originator PSP, on its own initiative or at the Originator's request", "deadline": "Sent within 10 Banking Business Days (T2 days) after the execution date of the SCT Inst Transaction; one recall per transaction" }, { "action": "response to a recall", "by": "Beneficiary PSP", "deadline": "Within 15 Banking Business Days (T2 days) after it receives the recall; a later answer is a breach of the rulebook" } ], "applies_to": "SCT Inst" }, "caveat": "A recall is a request; the Beneficiary PSP may answer no, and may charge a fee on a positive answer (EPC004-16 2025 v1.1 section 4.3.2.2).", "related": [ "sepa-sct-inst:DUPL", "sepa-sct-inst:FRAD", "sepa-sct-inst:FOCR" ], "basis": { "sources": "EPC059-18 v7.0 section 3, entry for TECH; EPC004-16 2025 v1.1 section 4.3.2.2 and CT-02.01 to CT-02.07 (recall reasons, 10 Banking Business Days or 13 months, one recall, 15 Banking Business Day answer), 4.6.1 AT-R051 and AT-R057; chapter 7 (Banking Business Day is a T2 day).", "confidence": "high" }, "currency": { "effective_since": "2025-10-05", "effective_note": "EPC004-16 2025 v1.1 was issued and took effect on 2025-10-05 (03:30 CET); v1.1 changed only the unstructured address cut-off, to 15 November 2026. EPC059-18 v7.0 was published on 2025-10-05 and applies to the SCT Inst rulebook. The next SCT Inst rulebook is due for publication in November 2026 [Unverified].", "source_edition": "EPC059-18 v7.0; EPC004-16 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-10/EPC004-16%202025%20SCT%20Instant%20Rulebook%20v1.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC059-18 v7.0 Guidance on Reason Codes for SCT Inst R-transactions and EPC004-16 2025 v1.1 SCT Inst Scheme Rulebook", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms TECH as one of the three recall reasons (AT-R051, 'Technical problems resulting in an erroneous SCT Inst') and the 10 Banking Business Day window, one-recall rule and 15 Banking Business Day response deadline in section 4.3.2.2." } ] }, "rail_name": "SEPA Instant Credit Transfer", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sct-inst:TM01", "id": "TM01", "rail": "sepa-sct-inst", "kind": "reason-code", "name": "Time-out between the Beneficiary PSP and its CSM", "group": "technical", "summary": "The Beneficiary PSP's positive confirmation did not reach its CSM within the maximum execution time. Used only between the Beneficiary PSP and its CSM.", "triggers": [ "A connection, processing or validation problem between the Beneficiary PSP and its CSM delays the positive confirmation" ], "actions": [ "Beneficiary PSP: do not make the funds available unless it is certain its CSM received the positive confirmation in time (section 4.2.3 B and C)", "CSM and Beneficiary PSP: use AB05 or AB06, not TM01, in any negative confirmation toward the Originator PSP" ], "retry": { "allowed": true, "rule": "The rejected transaction is final as a failure and nothing is re-presented. The Originator may send a new SCT Inst Transaction later or use another instrument such as SCT, as the guidance suggests. The scheme sets no retry limit [Unverified]." }, "facts": { "return_windows": [ { "action": "time-out reject on the leg between the Beneficiary PSP and its CSM", "by": "Not stated by the EPC. The rulebook gives the time-out reason to both the CSM and the Beneficiary PSP, and the guidance limits TM01 to the leg between them, so either may send it [Inference]", "deadline": "Instantly, once the confirmation has not reached, or cannot reach, the Beneficiary PSP's CSM within 7 seconds after the Time Stamp" } ], "applies_to": "SCT Inst" }, "caveat": "The guidance forbids TM01 in a negative confirmation to the Originator PSP and points to AB05 or AB06 instead. Neither the guidance nor the rulebook says whether the Beneficiary PSP, its CSM, or both send TM01 [Unverified]. The rulebook's reason for both a CSM and a Beneficiary PSP is 'Time-out, maximum execution time has been exceeded' (EPC004-16 2025 v1.1 section 4.6.1 AT-R004).", "related": [ "sepa-sct-inst:AB05", "sepa-sct-inst:AB06" ], "basis": { "sources": "EPC059-18 v7.0 section 3, entry for TM01; EPC004-16 2025 v1.1 sections 4.2.3 C and D (7-second time-out, 9th second, 10-second rule), 4.3.2.1 (CT-01.08R, CT-01.11R, CT-01.12R, CT-01.13R), 4.5.3 DS-03 and 4.6.1 AT-R004 (time-out reason).", "confidence": "medium" }, "currency": { "effective_since": "2025-10-05", "effective_note": "EPC004-16 2025 v1.1 was issued and took effect on 2025-10-05 (03:30 CET); v1.1 changed only the unstructured address cut-off, to 15 November 2026. EPC059-18 v7.0 was published on 2025-10-05 and applies to the SCT Inst rulebook. The next SCT Inst rulebook is due for publication in November 2026 [Unverified].", "source_edition": "EPC059-18 v7.0; EPC004-16 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-10/EPC004-16%202025%20SCT%20Instant%20Rulebook%20v1.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC059-18 v7.0 Guidance on Reason Codes for SCT Inst R-transactions and EPC004-16 2025 v1.1 SCT Inst Scheme Rulebook", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17c", "notes": "Confirms TM01 may only be used on the leg between the Beneficiary PSP and its CSM and is barred from a negative confirmation to the Originator PSP, per EPC059-18 v7.0 section 3. Confirms the rulebook gives the same reason, a time-out where the maximum execution time is exceeded, to both the CSM and the Beneficiary PSP under AT-R004, and the 7-second time-out deadline that either party may act on, EPC004-16 2025 v1.1 sections 4.2.3 and 4.6.1. Does not state whether the Beneficiary PSP, its CSM, or both actually send TM01; the record correctly labels this unverified." } ] }, "rail_name": "SEPA Instant Credit Transfer", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sdd-b2b:AC01", "id": "AC01", "rail": "sepa-sdd-b2b", "kind": "reason-code", "name": "Account identifier incorrect (invalid IBAN)", "group": "account", "summary": "The debtor's IBAN on the collection is wrong. As a reject it can mean the IBAN fails format checks or does not exist at the debtor PSP; as a return it means the IBAN does not exist there.", "triggers": [ "The debtor gave a wrong IBAN when signing the mandate", "The creditor's customer records hold a mistyped or stale IBAN", "A processing fault on the creditor side corrupted the IBAN while building the collection", "The IBAN fails its format or check digit validation (reject only)" ], "actions": [ "Contact the debtor and get the correct IBAN before collecting again", "If the collection followed a mandate amendment, check the new account details the debtor gave", "Remind the debtor that the debtor PSP holding the corrected account must have the mandate confirmed before it will pay (EPC222-07 2025 v1.1 sections 4.1 and 5.8)", "Validate IBAN format and check digits when the mandate is captured, so format errors never reach the scheme [Inference]" ], "retry": { "allowed": false, "rule": "Do not present again to the same IBAN. Once the debtor gives a correct IBAN, record the change as a mandate amendment and collect with the corrected data. A rejected collection that is corrected and presented again must keep its original sequence type: one-off stays one-off, recurrent stays recurrent (PT-04.04, PT-04.06, PT-04.08)." }, "facts": { "return_windows": [ { "action": "reject", "by": "Debtor PSP or CSM", "deadline": "Before inter-PSP settlement on the Due Date (D). A CSM rejects on receipt or on the later days its own rules allow" }, { "action": "return", "by": "Debtor PSP", "deadline": "Settled no later than 3 Inter-PSP Business Days (TARGET days) after the Settlement Date of the collection (D+3)" } ], "applies_to": "SDD B2B" }, "caveat": "Only the debtor PSP can know whether an IBAN exists on its books, so an AC01 reject from a CSM is in practice a format failure [Inference]. The B2B return window is D+3, two Inter-PSP Business Days shorter than in SDD Core.", "related": [ "sepa-sdd-b2b:AC04", "sepa-sdd-b2b:RC01" ], "basis": { "sources": "EPC173-14 v8.0 section 3, entry for AC01 (R-transaction types, use cases, root causes, suggested creditor action); EPC222-07 2025 v1.1 sections 4.4, 4.6.4 PT-04.06 and PT-04.08, 4.8.37 AT-R002 and 4.8.39 AT-R004 (reject: who may reject, before settlement); EPC222-07 2025 v1.1 sections 4.2, 4.3.2, 4.3.4, 4.6.4 PT-04.09 and PT-04.10 and 4.8.39 AT-R004 (return: Debtor PSP, settled by D+3 Inter-PSP Business Days); EPC222-07 2025 v1.1 section 4.6.4 PT-04.04, PT-04.06, PT-04.08 (re-presented rejects keep their sequence type); EPC222-07 2025 v1.1 sections 4.1 and 5.8 (debtor PSP mandate confirmation).", "confidence": "high" }, "currency": { "effective_since": "2025-10-05", "effective_note": "EPC222-07 2025 v1.1 was issued and took effect on 2025-10-05; v1.1 changed only the date for the unstructured address phase-out. EPC173-14 v8.0, published 2024-11-28, applies to both SDD rulebooks and is taken to be the current guidance [Unverified]. The next SDD B2B rulebook is due for publication in November 2026 [Unverified].", "source_edition": "EPC173-14 v8.0; EPC222-07 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-10/EPC222-07%202025%20SDD%20B2B%20Rulebook%20version%201.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC173-14 v8.0 Guidance on Reason Codes for SDD R-transactions and EPC222-07 2025 v1.1 SDD Business-to-Business Scheme Rulebook", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms the code name and B2B scope (EPC173-14 v8.0 section 3). Confirms the reject window: before Inter-PSP Settlement on the Due Date, sent by the Debtor PSP or the CSM (EPC222-07 2025 v1.1 sections 4.6.4 PT-04.06 and PT-04.08, section 4.8.39 AT-R004). Confirms the return window: settled no later than D+3 Inter-PSP Business Days, sent by the Debtor PSP (sections 4.6.4 PT-04.09 and PT-04.10). Confirms the B2B scheme carries no refund right for authorised collections (section 4.4). Does not address the retry rule's sequence-type detail or the caveat's code-choice inference." } ] }, "rail_name": "SEPA Direct Debit B2B", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sdd-b2b:AC04", "id": "AC04", "rail": "sepa-sdd-b2b", "kind": "reason-code", "name": "Account closed", "group": "account", "summary": "The debtor's account at the debtor PSP is closed.", "triggers": [ "The debtor closed the account after the creditor's previous collection", "The debtor moved to another PSP and did not give the creditor the new account" ], "actions": [ "Contact the debtor for the new account and record it as a mandate amendment", "Stop further collections to the closed account", "Ask the debtor to confirm the mandate with the new debtor PSP before the next collection, since that PSP must check the mandate before it debits (EPC222-07 2025 v1.1 sections 4.1, 4.6.2 PT-02.03 and 5.8)", "Where debtor PSPs send MS03, remember it may stand for a closed account [Inference]" ], "retry": { "allowed": false, "rule": "Do not present again to the closed account. Collect again only after the debtor gives a new account, carried as a mandate amendment in the next collection (EPC222-07 2025 v1.1 section 4.6.2, PR-02)." }, "facts": { "return_windows": [ { "action": "reject", "by": "Debtor PSP or CSM", "deadline": "Before inter-PSP settlement on the Due Date (D). A CSM rejects on receipt or on the later days its own rules allow" }, { "action": "return", "by": "Debtor PSP", "deadline": "Settled no later than 3 Inter-PSP Business Days (TARGET days) after the Settlement Date of the collection (D+3)" } ], "applies_to": "SDD B2B" }, "caveat": "Data protection law in certain SEPA countries bars this code, and debtor PSPs there send MS03 instead (EPC173-14 v8.0 section 3). The guidance does not name the countries. The debtor PSP must still effect rejects and returns on a closed account (EPC222-07 2025 v1.1 section 5.8, item 8).", "related": [ "sepa-sdd-b2b:MS03", "sepa-sdd-b2b:AC01", "sepa-sdd-b2b:AC06" ], "basis": { "sources": "EPC173-14 v8.0 section 3, entry for AC04 (R-transaction types, use cases, root causes, suggested creditor action); EPC222-07 2025 v1.1 sections 4.4, 4.6.4 PT-04.06 and PT-04.08, 4.8.37 AT-R002 and 4.8.39 AT-R004 (reject: who may reject, before settlement); EPC222-07 2025 v1.1 sections 4.2, 4.3.2, 4.3.4, 4.6.4 PT-04.09 and PT-04.10 and 4.8.39 AT-R004 (return: Debtor PSP, settled by D+3 Inter-PSP Business Days); EPC222-07 2025 v1.1 section 4.6.2 PR-02 and PT-02.03 (mandate amendment); EPC222-07 2025 v1.1 sections 4.1 and 5.8 items 8 and 10.", "confidence": "high" }, "currency": { "effective_since": "2025-10-05", "effective_note": "EPC222-07 2025 v1.1 was issued and took effect on 2025-10-05; v1.1 changed only the date for the unstructured address phase-out. EPC173-14 v8.0, published 2024-11-28, applies to both SDD rulebooks and is taken to be the current guidance [Unverified]. The next SDD B2B rulebook is due for publication in November 2026 [Unverified].", "source_edition": "EPC173-14 v8.0; EPC222-07 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-10/EPC222-07%202025%20SDD%20B2B%20Rulebook%20version%201.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC173-14 v8.0 Guidance on Reason Codes for SDD R-transactions and EPC222-07 2025 v1.1 SDD Business-to-Business Scheme Rulebook", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms the code name and B2B scope (EPC173-14 v8.0 section 3). Confirms the reject window: before Inter-PSP Settlement on the Due Date, sent by the Debtor PSP or the CSM (EPC222-07 2025 v1.1 sections 4.6.4 PT-04.06 and PT-04.08, section 4.8.39 AT-R004). Confirms the return window: settled no later than D+3 Inter-PSP Business Days, sent by the Debtor PSP (sections 4.6.4 PT-04.09 and PT-04.10). Confirms the B2B scheme carries no refund right for authorised collections (section 4.4). Does not confirm which countries bar this code under data protection law, and does not confirm the MS03 substitution claim." } ] }, "rail_name": "SEPA Direct Debit B2B", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sdd-b2b:AC06", "id": "AC06", "rail": "sepa-sdd-b2b", "kind": "reason-code", "name": "Account blocked", "group": "account", "summary": "The debtor's account is blocked for all financial transactions, or the debtor PSP has blocked this collection.", "triggers": [ "A court order blocks the account or the collection", "The debtor PSP blocked the account, for example on suspected misuse", "The debtor asked the debtor PSP to block the account" ], "actions": [ "Contact the debtor to agree another account or another way to pay", "Do not keep presenting to a blocked account; the block is outside the creditor's control" ], "retry": { "allowed": false, "rule": "Wait until the debtor confirms the block is lifted or gives another account. The texts read set no scheme retry rule for this code [Unverified]." }, "facts": { "return_windows": [ { "action": "reject", "by": "Debtor PSP or CSM", "deadline": "Before inter-PSP settlement on the Due Date (D). A CSM rejects on receipt or on the later days its own rules allow" }, { "action": "return", "by": "Debtor PSP", "deadline": "Settled no later than 3 Inter-PSP Business Days (TARGET days) after the Settlement Date of the collection (D+3)" } ], "applies_to": "SDD B2B" }, "caveat": "The debtor PSP must let a B2B debtor prohibit all B2B collections on its account (EPC222-07 2025 v1.1 sections 4.2 and 5.8, item 5). Unlike SDD Core, the B2B rulebook's reject and return reasons (section 4.8.39, AT-R004) list only a general account block, and EPC173-14 v8.0 section 3 does not say which code carries a debtor's prohibition of direct debits [Unverified; AC06 or SL01 are the likely candidates, Inference].", "related": [ "sepa-sdd-b2b:SL01", "sepa-sdd-b2b:AC04" ], "basis": { "sources": "EPC173-14 v8.0 section 3, entry for AC06 (R-transaction types, use cases, root causes, suggested creditor action); EPC222-07 2025 v1.1 sections 4.4, 4.6.4 PT-04.06 and PT-04.08, 4.8.37 AT-R002 and 4.8.39 AT-R004 (reject: who may reject, before settlement); EPC222-07 2025 v1.1 sections 4.2, 4.3.2, 4.3.4, 4.6.4 PT-04.09 and PT-04.10 and 4.8.39 AT-R004 (return: Debtor PSP, settled by D+3 Inter-PSP Business Days); EPC222-07 2025 v1.1 sections 4.2 and 5.8 item 5 (debtor right to prohibit B2B collections).", "confidence": "high" }, "currency": { "effective_since": "2025-10-05", "effective_note": "EPC222-07 2025 v1.1 was issued and took effect on 2025-10-05; v1.1 changed only the date for the unstructured address phase-out. EPC173-14 v8.0, published 2024-11-28, applies to both SDD rulebooks and is taken to be the current guidance [Unverified]. The next SDD B2B rulebook is due for publication in November 2026 [Unverified].", "source_edition": "EPC173-14 v8.0; EPC222-07 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-10/EPC222-07%202025%20SDD%20B2B%20Rulebook%20version%201.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC173-14 v8.0 Guidance on Reason Codes for SDD R-transactions and EPC222-07 2025 v1.1 SDD Business-to-Business Scheme Rulebook", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms the code name and B2B scope (EPC173-14 v8.0 section 3). Confirms the reject window: before Inter-PSP Settlement on the Due Date, sent by the Debtor PSP or the CSM (EPC222-07 2025 v1.1 sections 4.6.4 PT-04.06 and PT-04.08, section 4.8.39 AT-R004). Confirms the return window: settled no later than D+3 Inter-PSP Business Days, sent by the Debtor PSP (sections 4.6.4 PT-04.09 and PT-04.10). Confirms the B2B debtor's right to prohibit all B2B collections (section 4.2 and 5.8 item 5). Does not resolve whether AC06 or SL01 is the code for a debtor-instructed block, which the caveat already flags as unverified." } ] }, "rail_name": "SEPA Direct Debit B2B", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sdd-b2b:AC13", "id": "AC13", "rail": "sepa-sdd-b2b", "kind": "reason-code", "name": "Debtor account is a consumer account", "group": "account", "summary": "A B2B collection reached an account held by a consumer, or an account type meant only for consumers. SDD B2B is closed to consumer debtors.", "triggers": [ "The debtor is a consumer and did not know a B2B mandate is only for non-consumers", "The account type does not accept SDD B2B collections", "The debtor gave the details of the wrong payment account" ], "actions": [ "Contact the debtor to clarify and agree another means of payment", "Sign an SDD Core mandate with the debtor and collect under the Core scheme", "Check at onboarding that a B2B debtor is a business, and ask which account it will use [Inference]" ], "retry": { "allowed": false, "rule": "Do not present B2B collections to this account again. Move the debtor to an SDD Core mandate or another payment method (EPC173-14 v8.0 section 3)." }, "facts": { "return_windows": [ { "action": "reject", "by": "CSM or Debtor PSP", "deadline": "Before inter-PSP settlement on the Due Date (D)" }, { "action": "return", "by": "Debtor PSP", "deadline": "Settled no later than 3 Inter-PSP Business Days (TARGET days) after the Settlement Date of the collection (D+3)" } ], "applies_to": "SDD B2B" }, "caveat": "The debtor PSP must make sure the debtor is not a consumer before debiting, and that national law lets the debtor opt out of the refund right for authorised payments; some national laws treat micro-enterprises like consumers (EPC222-07 2025 v1.1 sections 2.2, 2.7, 4.6.4 PT-04.09 and 5.8 item 4). If a consumer account is debited in error, the debtor PSP has no scheme right to get the money back, while the debtor keeps its Payment Services Directive rights against the debtor PSP (sections 2.7 and PT-04.09). The guidance bars AG01 for this case. AC13 is used in SDD B2B only. The rulebook lists this reason among those a CSM or the debtor PSP may give for a reject, without saying which of the two uses it (section 4.8.39, AT-R004); the guidance names no sender. In practice the debtor PSP is the likely sender, since only it knows the account type [Inference].", "related": [ "sepa-sdd-b2b:AG01", "sepa-sdd-b2b:MD01" ], "basis": { "sources": "EPC173-14 v8.0 section 3, entry for AC13 (R-transaction types, use cases, root causes, suggested creditor action); EPC222-07 2025 v1.1 sections 4.4, 4.6.4 PT-04.06 and PT-04.08, 4.8.37 AT-R002 and 4.8.39 AT-R004 (reject: who may reject, before settlement); EPC222-07 2025 v1.1 sections 4.2, 4.3.2, 4.3.4, 4.6.4 PT-04.09 and PT-04.10 and 4.8.39 AT-R004 (return: Debtor PSP, settled by D+3 Inter-PSP Business Days); EPC222-07 2025 v1.1 sections 2.2 and 2.7 (scheme closed to consumers; no scheme recovery after debiting a consumer in error); EPC222-07 2025 v1.1 section 4.6.4 PT-04.09 and section 5.8 item 4 (debtor PSP must check non-consumer status).", "confidence": "high" }, "currency": { "effective_since": "2025-10-05", "effective_note": "EPC222-07 2025 v1.1 was issued and took effect on 2025-10-05; v1.1 changed only the date for the unstructured address phase-out. EPC173-14 v8.0, published 2024-11-28, applies to both SDD rulebooks and is taken to be the current guidance [Unverified]. The next SDD B2B rulebook is due for publication in November 2026 [Unverified].", "source_edition": "EPC173-14 v8.0; EPC222-07 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-10/EPC222-07%202025%20SDD%20B2B%20Rulebook%20version%201.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC173-14 v8.0 Guidance on Reason Codes for SDD R-transactions and EPC222-07 2025 v1.1 SDD Business-to-Business Scheme Rulebook", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17c", "notes": "Confirms AC13 (Debtor account is a consumer account) as a Reject and Return code for SDD B2B only, per EPC173-14 v8.0 section 3. Confirms the reject and return reasons list, EPC222-07 2025 v1.1 section 4.8.39 AT-R004, includes this reason for CSM or Debtor PSP reject and for Debtor PSP return, and confirms the D+3 return window, section 4.6.4 PT-04.10. Confirms the debtor PSP's duty to check non-consumer status and the absence of a scheme refund right after debiting a consumer account in error, EPC222-07 2025 v1.1 section 2.7. Does not confirm which of the CSM or the Debtor PSP sends the reject in practice; the record labels that an inference." } ] }, "rail_name": "SEPA Direct Debit B2B", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sdd-b2b:AG01", "id": "AG01", "rail": "sepa-sdd-b2b", "kind": "reason-code", "name": "Direct debit forbidden on this account for regulatory reasons", "group": "account", "summary": "Regulation does not allow direct debits from this type of account, for example a savings account.", "triggers": [ "The debtor gave a savings account or another account type that cannot be debited by direct debit" ], "actions": [ "Contact the debtor to agree a payment account that accepts direct debits, or another payment method", "Record the new account as a mandate amendment before collecting again, and have the debtor confirm it with its debtor PSP (EPC222-07 2025 v1.1 section 4.6.2 PT-02.03)" ], "retry": { "allowed": false, "rule": "Do not present again to this account. The account type, not the collection, is the problem." }, "facts": { "return_windows": [ { "action": "reject", "by": "Debtor PSP or CSM", "deadline": "Before inter-PSP settlement on the Due Date (D). A CSM rejects on receipt or on the later days its own rules allow" }, { "action": "return", "by": "Debtor PSP", "deadline": "Settled no later than 3 Inter-PSP Business Days (TARGET days) after the Settlement Date of the collection (D+3)" } ], "applies_to": "SDD B2B" }, "caveat": "The guidance bars AG01 when a B2B collection reaches a consumer account; the debtor PSP must use AC13 for that case (EPC173-14 v8.0 section 3).", "related": [ "sepa-sdd-b2b:AC06", "sepa-sdd-b2b:AC13" ], "basis": { "sources": "EPC173-14 v8.0 section 3, entry for AG01 (R-transaction types, use cases, root causes, suggested creditor action); EPC222-07 2025 v1.1 sections 4.4, 4.6.4 PT-04.06 and PT-04.08, 4.8.37 AT-R002 and 4.8.39 AT-R004 (reject: who may reject, before settlement); EPC222-07 2025 v1.1 sections 4.2, 4.3.2, 4.3.4, 4.6.4 PT-04.09 and PT-04.10 and 4.8.39 AT-R004 (return: Debtor PSP, settled by D+3 Inter-PSP Business Days); EPC222-07 2025 v1.1 section 4.6.2 PT-02.03.", "confidence": "high" }, "currency": { "effective_since": "2025-10-05", "effective_note": "EPC222-07 2025 v1.1 was issued and took effect on 2025-10-05; v1.1 changed only the date for the unstructured address phase-out. EPC173-14 v8.0, published 2024-11-28, applies to both SDD rulebooks and is taken to be the current guidance [Unverified]. The next SDD B2B rulebook is due for publication in November 2026 [Unverified].", "source_edition": "EPC173-14 v8.0; EPC222-07 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-10/EPC222-07%202025%20SDD%20B2B%20Rulebook%20version%201.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC173-14 v8.0 Guidance on Reason Codes for SDD R-transactions and EPC222-07 2025 v1.1 SDD Business-to-Business Scheme Rulebook", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms the code name and B2B scope (EPC173-14 v8.0 section 3). Confirms the reject window: before Inter-PSP Settlement on the Due Date, sent by the Debtor PSP or the CSM (EPC222-07 2025 v1.1 sections 4.6.4 PT-04.06 and PT-04.08, section 4.8.39 AT-R004). Confirms the return window: settled no later than D+3 Inter-PSP Business Days, sent by the Debtor PSP (sections 4.6.4 PT-04.09 and PT-04.10). Confirms the B2B scheme carries no refund right for authorised collections (section 4.4). Confirms AG01 must not be used where AC13 applies (EPC173-14 v8.0 section 3)." } ] }, "rail_name": "SEPA Direct Debit B2B", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sdd-b2b:AG02", "id": "AG02", "rail": "sepa-sdd-b2b", "kind": "reason-code", "name": "Operation code, transaction code or sequence type incorrect; invalid file format", "group": "technical", "summary": "The collection carries the wrong sequence type (one-off or recurrent) or the wrong scheme identification.", "triggers": [ "A recurrent collection was sent under a mandate already used for a one-off", "A one-off collection was sent under a mandate already used for recurrent collections", "The service level or local instrument code in the message does not identify the scheme correctly", "A technical or process error on the creditor side when building the collection or file" ], "actions": [ "Correct the sequence type or scheme identification and send a new collection", "Make sure B2B collections carry the B2B scheme identification and Core collections the Core one; the rulebook keeps B2B and Core mandates distinct (EPC222-07 2025 v1.1 sections 2.7 and 4.1)", "Check how the collection system records whether each mandate is one-off or recurrent [Inference]" ], "retry": { "allowed": true, "rule": "A corrected collection may be sent again. A rejected collection that is corrected and presented again must keep its original sequence type: one-off stays one-off, recurrent stays recurrent (PT-04.04, PT-04.06, PT-04.08). How that rule applies when the sequence type was itself the error is not stated in the texts read; confirm with the creditor PSP before resending [Unverified]." }, "facts": { "return_windows": [ { "action": "reject", "by": "Debtor PSP or CSM", "deadline": "Before inter-PSP settlement on the Due Date (D). A CSM rejects on receipt or on the later days its own rules allow" }, { "action": "return", "by": "Debtor PSP", "deadline": "Settled no later than 3 Inter-PSP Business Days (TARGET days) after the Settlement Date of the collection (D+3)" } ], "applies_to": "SDD B2B" }, "caveat": "In B2B the debtor PSP's mandate check covers the scheme identification, which must read B2B, and the transaction type: recurrent collections under a one-off mandate are not covered after the first (EPC222-07 2025 v1.1 section 4.6.4, PT-04.09). A B2B debtor PSP may reject or return, under B2B rules, a collection sent as Core (section 2.7). The rulebook does not say which code carries a failed PT-04.09 check; AG02 matches the guidance's use cases for these two errors [Inference]. The guidance also leaves sequence type checks to each debtor PSP (EPC173-14 v8.0 section 2).", "related": [ "sepa-sdd-b2b:FF01", "sepa-sdd-b2b:MD01" ], "basis": { "sources": "EPC173-14 v8.0 section 3, entry for AG02 (R-transaction types, use cases, root causes, suggested creditor action); EPC222-07 2025 v1.1 sections 4.4, 4.6.4 PT-04.06 and PT-04.08, 4.8.37 AT-R002 and 4.8.39 AT-R004 (reject: who may reject, before settlement); EPC222-07 2025 v1.1 sections 4.2, 4.3.2, 4.3.4, 4.6.4 PT-04.09 and PT-04.10 and 4.8.39 AT-R004 (return: Debtor PSP, settled by D+3 Inter-PSP Business Days); EPC222-07 2025 v1.1 section 4.6.4 PT-04.04, PT-04.06, PT-04.08 (re-presented rejects keep their sequence type); EPC222-07 2025 v1.1 sections 2.7 and 4.1 (Core and B2B kept apart); EPC222-07 2025 v1.1 section 4.6.4 PT-04.09 (scheme code and transaction type checks); EPC173-14 v8.0 section 2 (debtor PSP discretion on sequence type checks).", "confidence": "high" }, "currency": { "effective_since": "2025-10-05", "effective_note": "EPC222-07 2025 v1.1 was issued and took effect on 2025-10-05; v1.1 changed only the date for the unstructured address phase-out. EPC173-14 v8.0, published 2024-11-28, applies to both SDD rulebooks and is taken to be the current guidance [Unverified]. The next SDD B2B rulebook is due for publication in November 2026 [Unverified].", "source_edition": "EPC173-14 v8.0; EPC222-07 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-10/EPC222-07%202025%20SDD%20B2B%20Rulebook%20version%201.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC173-14 v8.0 Guidance on Reason Codes for SDD R-transactions and EPC222-07 2025 v1.1 SDD Business-to-Business Scheme Rulebook", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms the code name and B2B scope (EPC173-14 v8.0 section 3). Confirms the reject window: before Inter-PSP Settlement on the Due Date, sent by the Debtor PSP or the CSM (EPC222-07 2025 v1.1 sections 4.6.4 PT-04.06 and PT-04.08, section 4.8.39 AT-R004). Confirms the return window: settled no later than D+3 Inter-PSP Business Days, sent by the Debtor PSP (sections 4.6.4 PT-04.09 and PT-04.10). Confirms a re-presented rejected collection must keep its original sequence type (sections 4.6.4 PT-04.04, PT-04.06, PT-04.08). Does not resolve how that rule applies when the sequence type itself was the error, which the retry rule already flags as unverified." } ] }, "rail_name": "SEPA Direct Debit B2B", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sdd-b2b:AM04", "id": "AM04", "rail": "sepa-sdd-b2b", "kind": "reason-code", "name": "Insufficient funds", "group": "funds", "summary": "The debtor's account does not hold enough to pay the full collection.", "triggers": [ "The debtor lacks funds on the debit date", "The creditor sent no pre-notification, or sent it late, so the debtor did not know the amount and date" ], "actions": [ "Contact the debtor so funds are in place before the next collection", "Check that the pre-notification went out on time with amount and due date; the scheme default is at least 14 Calendar Days before the Due Date unless creditor and debtor agreed otherwise (EPC222-07 2025 v1.1 section 4.3.4, PT-04.02)", "Where debtor PSPs send MS03, remember it may stand for insufficient funds [Inference]" ], "retry": { "allowed": true, "rule": "The texts read set no limit on presenting a new collection after an insufficient funds reject or return [Unverified]. A new collection needs its own Due Date, must reach the debtor PSP at least 1 Inter-PSP Business Day before it, and needs pre-notification (section 4.3.4). A rejected collection that is corrected and presented again must keep its original sequence type: one-off stays one-off, recurrent stays recurrent (PT-04.04, PT-04.06, PT-04.08)." }, "facts": { "return_windows": [ { "action": "reject", "by": "Debtor PSP or CSM", "deadline": "Before inter-PSP settlement on the Due Date (D). A CSM rejects on receipt or on the later days its own rules allow" }, { "action": "return", "by": "Debtor PSP", "deadline": "Settled no later than 3 Inter-PSP Business Days (TARGET days) after the Settlement Date of the collection (D+3)" } ], "applies_to": "SDD B2B" }, "caveat": "Data protection law in certain SEPA countries bars this code, and debtor PSPs there send MS03 instead (EPC173-14 v8.0 section 3). The guidance does not name the countries. The debtor PSP may debit after the Due Date while waiting for funds or finishing the mandate checks agreed with the debtor, but must still return in time to settle by D+3 (EPC222-07 2025 v1.1 section 4.3.2). That leaves less time than the D+5 of SDD Core.", "related": [ "sepa-sdd-b2b:MS03" ], "basis": { "sources": "EPC173-14 v8.0 section 3, entry for AM04 (R-transaction types, use cases, root causes, suggested creditor action); EPC222-07 2025 v1.1 sections 4.4, 4.6.4 PT-04.06 and PT-04.08, 4.8.37 AT-R002 and 4.8.39 AT-R004 (reject: who may reject, before settlement); EPC222-07 2025 v1.1 sections 4.2, 4.3.2, 4.3.4, 4.6.4 PT-04.09 and PT-04.10 and 4.8.39 AT-R004 (return: Debtor PSP, settled by D+3 Inter-PSP Business Days); EPC222-07 2025 v1.1 section 4.6.4 PT-04.04, PT-04.06, PT-04.08 (re-presented rejects keep their sequence type); EPC222-07 2025 v1.1 sections 4.3.2 and 4.3.4, PT-04.02 (late debit, pre-notification, D-1 receipt).", "confidence": "high" }, "currency": { "effective_since": "2025-10-05", "effective_note": "EPC222-07 2025 v1.1 was issued and took effect on 2025-10-05; v1.1 changed only the date for the unstructured address phase-out. EPC173-14 v8.0, published 2024-11-28, applies to both SDD rulebooks and is taken to be the current guidance [Unverified]. The next SDD B2B rulebook is due for publication in November 2026 [Unverified].", "source_edition": "EPC173-14 v8.0; EPC222-07 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-10/EPC222-07%202025%20SDD%20B2B%20Rulebook%20version%201.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC173-14 v8.0 Guidance on Reason Codes for SDD R-transactions and EPC222-07 2025 v1.1 SDD Business-to-Business Scheme Rulebook", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms the code name and B2B scope (EPC173-14 v8.0 section 3). Confirms the reject window: before Inter-PSP Settlement on the Due Date, sent by the Debtor PSP or the CSM (EPC222-07 2025 v1.1 sections 4.6.4 PT-04.06 and PT-04.08, section 4.8.39 AT-R004). Confirms the return window: settled no later than D+3 Inter-PSP Business Days, sent by the Debtor PSP (sections 4.6.4 PT-04.09 and PT-04.10). Confirms the pre-notification deadline of 14 Calendar Days before the Due Date unless otherwise agreed (section 4.6.4 PT-04.02). Confirms the B2B scheme carries no refund right for authorised collections (section 4.4). Does not confirm any scheme-wide limit on re-presentation attempts, which the retry rule already flags as unverified." } ] }, "rail_name": "SEPA Direct Debit B2B", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sdd-b2b:AM05", "id": "AM05", "rail": "sepa-sdd-b2b", "kind": "reason-code", "name": "Duplicate collection", "group": "administrative", "summary": "The CSM or the debtor PSP believes an identical collection was sent or processed very recently. As a reversal, the creditor side uses it to pay back a collection it sent twice.", "triggers": [ "A technical fault at the creditor or creditor PSP resubmitted a file or collection", "A human error on the creditor side entered the same collection twice" ], "actions": [ "Check whether the collection really was duplicated before doing anything else", "If a duplicate settled and was not rejected or returned, pay it back with a reversal inside the reversal window", "If a debtor PSP opens an inquiry about a duplicate after the return window, answer through the creditor PSP within the Annex VI timelines (EPC222-07 2025 v1.1 Annex VI, steps 3 and 4)", "If it was not a duplicate, raise it with the creditor PSP; a new collection with distinct references may be needed [Inference]" ], "retry": { "allowed": false, "rule": "Do not resend the same collection. If it was wrongly flagged as a duplicate, agree the next step with the creditor PSP first [Inference]." }, "facts": { "return_windows": [ { "action": "reject", "by": "CSM or Debtor PSP", "deadline": "Before inter-PSP settlement on the Due Date (D). A CSM rejects on receipt or on the later days its own rules allow" }, { "action": "return", "by": "Debtor PSP", "deadline": "Settled no later than 3 Inter-PSP Business Days (TARGET days) after the Settlement Date of the collection (D+3)" }, { "action": "reversal", "by": "Creditor or Creditor PSP", "deadline": "From the Settlement Date (D) to D+5 Inter-PSP Business Days, counted end to end from the creditor's instruction to CSM forwarding" } ], "applies_to": "SDD B2B" }, "caveat": "The rulebook's inquiry annex gives debtor PSPs a working test: a collection with the same amount and Due Date as another is strongly presumed a duplicate, and the same amount with very close Due Dates may be one (EPC222-07 2025 v1.1 Annex VI, section 2.1). There is no scheme refund in B2B, but a debtor may claim a duplicate back from its debtor PSP under Article 89 of the Payment Services Directive, and the debtor PSP may then use the inquiry procedure to seek reimbursement from the creditor PSP (Annex VI). Creditor errors in the amount or Due Date count as authorised collections, which B2B does not refund (Annex VI, section 2.1). A reversal must be for the full amount; partial reversals are not allowed (section 4.8.54, AT-R042).", "related": [ "sepa-sdd-b2b:MS03" ], "basis": { "sources": "EPC173-14 v8.0 section 3, entry for AM05 (R-transaction types, use cases, root causes, suggested creditor action); EPC222-07 2025 v1.1 sections 4.4, 4.6.4 PT-04.06 and PT-04.08, 4.8.37 AT-R002 and 4.8.39 AT-R004 (reject: who may reject, before settlement); EPC222-07 2025 v1.1 sections 4.2, 4.3.2, 4.3.4, 4.6.4 PT-04.09 and PT-04.10 and 4.8.39 AT-R004 (return: Debtor PSP, settled by D+3 Inter-PSP Business Days); EPC222-07 2025 v1.1 sections 4.3.4, 4.4, 4.6.5 PT-05.01 to PT-05.03 and 4.8.53 AT-R041 (reversal: Creditor or Creditor PSP, D to D+5 Inter-PSP Business Days); EPC222-07 2025 v1.1 section 4.8.54 AT-R042 (no partial reversal); EPC222-07 2025 v1.1 Annex VI sections 2.1 and 3 (duplicate presumption, inquiry procedure).", "confidence": "high" }, "currency": { "effective_since": "2025-10-05", "effective_note": "EPC222-07 2025 v1.1 was issued and took effect on 2025-10-05; v1.1 changed only the date for the unstructured address phase-out. EPC173-14 v8.0, published 2024-11-28, applies to both SDD rulebooks and is taken to be the current guidance [Unverified]. The next SDD B2B rulebook is due for publication in November 2026 [Unverified].", "source_edition": "EPC173-14 v8.0; EPC222-07 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-10/EPC222-07%202025%20SDD%20B2B%20Rulebook%20version%201.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC173-14 v8.0 Guidance on Reason Codes for SDD R-transactions and EPC222-07 2025 v1.1 SDD Business-to-Business Scheme Rulebook", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms the code name, B2B scope, and that AM05 covers Reject, Return and Reversal (EPC173-14 v8.0 section 3). Confirms the reject window: before Inter-PSP Settlement on the Due Date, sent by the Debtor PSP or the CSM (EPC222-07 2025 v1.1 sections 4.6.4 PT-04.06 and PT-04.08, section 4.8.39 AT-R004). Confirms the return window: D+3 Inter-PSP Business Days, sent by the Debtor PSP (sections 4.6.4 PT-04.09 and PT-04.10). Confirms the reversal window: Settlement Date (D) to D+5 Inter-PSP Business Days counted end-to-end from the Creditor's instruction (PT-05.01) to the CSM forwarding to the Debtor PSP (PT-05.03), sent by the Creditor or Creditor PSP (sections 4.5.5 and 4.6.5 PT-05.01 through PT-05.03). Does not define what counts as an identical or recent collection." } ] }, "rail_name": "SEPA Direct Debit B2B", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sdd-b2b:BE05", "id": "BE05", "rail": "sepa-sdd-b2b", "kind": "reason-code", "name": "Identifier of the Creditor incorrect", "group": "administrative", "summary": "The creditor identifier (CI) on the collection is wrong, or it changed without a mandate amendment being reported.", "triggers": [ "A technical error put the wrong CI on the collection", "The creditor's CI changed, for example after a merger or acquisition, and the collection did not carry the amendment" ], "actions": [ "Correct the CI", "When the CI changes, send the amendment with the next collection under each affected mandate and tell debtors about the change (EPC222-07 2025 v1.1 section 4.6.2, PT-02.02)", "Ask each B2B debtor to pass the amendment to its debtor PSP before the next Due Date, since the debtor PSP checks the CI against the mandate data it stored (PT-02.03, PT-04.09)" ], "retry": { "allowed": true, "rule": "Correct the CI or report the amendment, then collect again. A rejected collection that is corrected and presented again must keep its original sequence type: one-off stays one-off, recurrent stays recurrent (PT-04.04, PT-04.06, PT-04.08)." }, "facts": { "return_windows": [ { "action": "reject", "by": "Debtor PSP or CSM", "deadline": "Before inter-PSP settlement on the Due Date (D). A CSM rejects on receipt or on the later days its own rules allow" }, { "action": "return", "by": "Debtor PSP", "deadline": "Settled no later than 3 Inter-PSP Business Days (TARGET days) after the Settlement Date of the collection (D+3)" } ], "applies_to": "SDD B2B" }, "caveat": "In SDD Core each debtor PSP decides whether to check the CI (EPC173-14 v8.0 section 2). In B2B the CI is one of the mandate attributes the debtor PSP must match against the data the debtor confirmed (EPC222-07 2025 v1.1 section 4.6.4, PT-04.09); on a mismatch it follows the debtor's instructions, and the rulebook does not name the code for that outcome [Inference: BE05 or MD01]. The CI has no ACH counterpart and is not a company ID.", "related": [ "sepa-sdd-b2b:MD02", "sepa-sdd-b2b:MD01" ], "basis": { "sources": "EPC173-14 v8.0 section 3, entry for BE05 (R-transaction types, use cases, root causes, suggested creditor action); EPC222-07 2025 v1.1 sections 4.4, 4.6.4 PT-04.06 and PT-04.08, 4.8.37 AT-R002 and 4.8.39 AT-R004 (reject: who may reject, before settlement); EPC222-07 2025 v1.1 sections 4.2, 4.3.2, 4.3.4, 4.6.4 PT-04.09 and PT-04.10 and 4.8.39 AT-R004 (return: Debtor PSP, settled by D+3 Inter-PSP Business Days); EPC222-07 2025 v1.1 section 4.6.4 PT-04.04, PT-04.06, PT-04.08 (re-presented rejects keep their sequence type); EPC222-07 2025 v1.1 section 4.6.2 PT-02.02 and PT-02.03 (amendments); EPC222-07 2025 v1.1 section 4.6.4 PT-04.09 (CI must match); EPC173-14 v8.0 section 2.", "confidence": "high" }, "currency": { "effective_since": "2025-10-05", "effective_note": "EPC222-07 2025 v1.1 was issued and took effect on 2025-10-05; v1.1 changed only the date for the unstructured address phase-out. EPC173-14 v8.0, published 2024-11-28, applies to both SDD rulebooks and is taken to be the current guidance [Unverified]. The next SDD B2B rulebook is due for publication in November 2026 [Unverified].", "source_edition": "EPC173-14 v8.0; EPC222-07 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-10/EPC222-07%202025%20SDD%20B2B%20Rulebook%20version%201.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC173-14 v8.0 Guidance on Reason Codes for SDD R-transactions and EPC222-07 2025 v1.1 SDD Business-to-Business Scheme Rulebook", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms the code name and B2B scope (EPC173-14 v8.0 section 3). Confirms the reject window: before Inter-PSP Settlement on the Due Date, sent by the Debtor PSP or the CSM (EPC222-07 2025 v1.1 sections 4.6.4 PT-04.06 and PT-04.08, section 4.8.39 AT-R004). Confirms the return window: settled no later than D+3 Inter-PSP Business Days, sent by the Debtor PSP (sections 4.6.4 PT-04.09 and PT-04.10). Does not address whether a mismatched Creditor Identifier is reported as BE05 or MD01 in every case." } ] }, "rail_name": "SEPA Direct Debit B2B", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sdd-b2b:CNOR", "id": "CNOR", "rail": "sepa-sdd-b2b", "kind": "reason-code", "name": "Creditor PSP not registered under this BIC in the CSM", "group": "network", "summary": "The CSM does not hold the creditor PSP as an SDD B2B scheme participant under the BIC used.", "triggers": [ "The creditor PSP is not, or is no longer, a direct or indirect participant of this CSM" ], "actions": [ "Contact the creditor PSP; the fix lies between it and the CSM" ], "retry": { "allowed": false, "rule": "Do not resend through the same route until the creditor PSP confirms its registration with the CSM [Inference]." }, "facts": { "return_windows": [ { "action": "reject", "by": "CSM or Debtor PSP", "deadline": "Before inter-PSP settlement on the Due Date (D). A CSM rejects on receipt or on the later days its own rules allow" } ], "applies_to": "SDD B2B" }, "caveat": "A PSP may join SDD B2B as a debtor PSP only (EPC222-07 2025 v1.1 section 5.3), so a bank that can receive B2B collections cannot necessarily send them [Inference]. The rulebook lists this reason among those a CSM or the debtor PSP may give for a reject, without saying which of the two uses it (section 4.8.39, AT-R004), and the guidance names no sender. The CSM is the likely sender, since the missing registration is in its own records [Inference].", "related": [ "sepa-sdd-b2b:DNOR", "sepa-sdd-b2b:RC01" ], "basis": { "sources": "EPC173-14 v8.0 section 3, entry for CNOR (R-transaction types, use cases, root causes, suggested creditor action); EPC222-07 2025 v1.1 sections 4.4, 4.6.4 PT-04.06 and PT-04.08, 4.8.37 AT-R002 and 4.8.39 AT-R004 (reject: who may reject, before settlement); EPC222-07 2025 v1.1 sections 2.6 and 5.3 (participation roles, reachability).", "confidence": "medium" }, "currency": { "effective_since": "2025-10-05", "effective_note": "EPC222-07 2025 v1.1 was issued and took effect on 2025-10-05; v1.1 changed only the date for the unstructured address phase-out. EPC173-14 v8.0, published 2024-11-28, applies to both SDD rulebooks and is taken to be the current guidance [Unverified]. The next SDD B2B rulebook is due for publication in November 2026 [Unverified].", "source_edition": "EPC173-14 v8.0; EPC222-07 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-10/EPC222-07%202025%20SDD%20B2B%20Rulebook%20version%201.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC173-14 v8.0 Guidance on Reason Codes for SDD R-transactions and EPC222-07 2025 v1.1 SDD Business-to-Business Scheme Rulebook", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17c", "notes": "Confirms CNOR (Creditor PSP not registered under this BIC in the CSM) as a reject-only reason for CSM or Debtor PSP, per EPC173-14 v8.0 section 3 and EPC222-07 2025 v1.1 section 4.8.39 AT-R004; the reason is absent from the return list, matching the record's reject-only facts. Confirms the before-settlement timing, section 4.6.4 PT-04.08, and that a PSP may adhere as Debtor PSP only, section 5.3. Does not confirm which of the CSM or the Debtor PSP actually sends this reject; the record labels that an inference." } ] }, "rail_name": "SEPA Direct Debit B2B", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sdd-b2b:DNOR", "id": "DNOR", "rail": "sepa-sdd-b2b", "kind": "reason-code", "name": "Debtor PSP not registered under this BIC in the CSM", "group": "network", "summary": "The debtor PSP is not, or is no longer, registered with the CSM as an SDD B2B scheme participant under the BIC used, so the CSM cannot deliver the collection.", "triggers": [ "The creditor or creditor PSP did not check that the debtor PSP is reachable before sending", "The debtor's PSP does not take part in SDD B2B, even if it takes part in SDD Core [Inference]" ], "actions": [ "Ask the creditor PSP to check whether the debtor PSP is reachable for B2B", "Contact the debtor to agree another way to pay" ], "retry": { "allowed": false, "rule": "Do not resend through the same route until the creditor PSP confirms the debtor PSP is reachable [Inference]." }, "facts": { "return_windows": [ { "action": "reject", "by": "CSM or Debtor PSP", "deadline": "Before inter-PSP settlement on the Due Date (D). A CSM rejects on receipt or on the later days its own rules allow" } ], "applies_to": "SDD B2B" }, "caveat": "The B2B rulebook says reachability of all PSPs is not an assumption of the scheme (EPC222-07 2025 v1.1 section 2.6), and adherence to B2B is separate from adherence to Core (section 2.7), so this code may be more common in B2B than in Core [Inference]. Each participant must still work out how to reach others (section 5.3). The rulebook lists this reason among those a CSM or the debtor PSP may give for a reject, without saying which of the two uses it (section 4.8.39, AT-R004), and the guidance names no sender. The CSM is the likely sender, since it is the party that cannot deliver the collection [Inference].", "related": [ "sepa-sdd-b2b:CNOR", "sepa-sdd-b2b:RC01" ], "basis": { "sources": "EPC173-14 v8.0 section 3, entry for DNOR (R-transaction types, use cases, root causes, suggested creditor action); EPC222-07 2025 v1.1 sections 4.4, 4.6.4 PT-04.06 and PT-04.08, 4.8.37 AT-R002 and 4.8.39 AT-R004 (reject: who may reject, before settlement); EPC222-07 2025 v1.1 sections 2.6, 2.7 and 5.3 (reachability, separate adherence).", "confidence": "medium" }, "currency": { "effective_since": "2025-10-05", "effective_note": "EPC222-07 2025 v1.1 was issued and took effect on 2025-10-05; v1.1 changed only the date for the unstructured address phase-out. EPC173-14 v8.0, published 2024-11-28, applies to both SDD rulebooks and is taken to be the current guidance [Unverified]. The next SDD B2B rulebook is due for publication in November 2026 [Unverified].", "source_edition": "EPC173-14 v8.0; EPC222-07 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-10/EPC222-07%202025%20SDD%20B2B%20Rulebook%20version%201.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC173-14 v8.0 Guidance on Reason Codes for SDD R-transactions and EPC222-07 2025 v1.1 SDD Business-to-Business Scheme Rulebook", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17c", "notes": "Confirms DNOR (Debtor PSP not registered under this BIC in the CSM) as a reject-only reason for CSM or Debtor PSP, per EPC173-14 v8.0 section 3 and EPC222-07 2025 v1.1 section 4.8.39 AT-R004; absent from the return list, matching the record. Confirms the before-settlement timing, section 4.6.4 PT-04.08, and that reachability of all PSPs is not assumed in the B2B scheme, section 2.6. Does not confirm which of the CSM or the Debtor PSP sends this reject; the record labels that an inference." } ] }, "rail_name": "SEPA Direct Debit B2B", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sdd-b2b:ED05", "id": "ED05", "rail": "sepa-sdd-b2b", "kind": "reason-code", "name": "Settlement of the collection failed", "group": "network", "summary": "The collection could not be settled between PSPs. The only root cause the guidance gives is that the debtor PSP's inter-PSP funding for SDD was not enough.", "triggers": [ "The debtor PSP's inter-PSP SDD funding facilities were insufficient to settle this collection" ], "actions": [ "Ask the creditor PSP what happens next; the outcome depends on the service agreement between the debtor PSP and the CSM", "Do not read this as a problem with the debtor's own account [Inference]" ], "retry": { "allowed": true, "rule": "The texts read set no scheme rule. Any new attempt is a new collection with its own Due Date and the usual D-1 receipt rule [Inference]." }, "facts": { "return_windows": [ { "action": "reject", "by": "Debtor PSP or CSM", "deadline": "Not stated by the EPC for this code. The guidance says only that the Debtor PSP or the CSM must report the failure; [Inference] it is reported when settlement on the Due Date (D) is attempted and fails" } ], "applies_to": "SDD B2B" }, "caveat": "This is a failure between the debtor PSP and the CSM, not a statement about the debtor. The rulebook lists it among reject reasons (EPC222-07 2025 v1.1 section 4.8.39, AT-R004); neither the rulebook nor the guidance says when in the settlement cycle it is reported, so the timing in this record is an inference and likely depends on the CSM [Inference].", "related": [ "sepa-sdd-b2b:DNOR" ], "basis": { "sources": "EPC173-14 v8.0 section 3, entry for ED05 (R-transaction types, use cases, root causes, suggested creditor action); EPC222-07 2025 v1.1 sections 4.4, 4.6.4 PT-04.06 and PT-04.08, 4.8.37 AT-R002 and 4.8.39 AT-R004 (reject: who may reject, before settlement).", "confidence": "medium" }, "currency": { "effective_since": "2025-10-05", "effective_note": "EPC222-07 2025 v1.1 was issued and took effect on 2025-10-05; v1.1 changed only the date for the unstructured address phase-out. EPC173-14 v8.0, published 2024-11-28, applies to both SDD rulebooks and is taken to be the current guidance [Unverified]. The next SDD B2B rulebook is due for publication in November 2026 [Unverified].", "source_edition": "EPC173-14 v8.0; EPC222-07 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-10/EPC222-07%202025%20SDD%20B2B%20Rulebook%20version%201.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC173-14 v8.0 Guidance on Reason Codes for SDD R-transactions and EPC222-07 2025 v1.1 SDD Business-to-Business Scheme Rulebook", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17c", "notes": "Confirms ED05 (Settlement of the collection failed) as a reject-only reason attributed to the Debtor PSP or the CSM, per EPC173-14 v8.0 section 3 and EPC222-07 2025 v1.1 section 4.8.39 AT-R004. Neither text states a deadline for this code; the record correctly says the EPC does not state one and marks the attempted-settlement timing as an inference. Does not confirm the timing inference itself." } ] }, "rail_name": "SEPA Direct Debit B2B", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sdd-b2b:FF01", "id": "FF01", "rail": "sepa-sdd-b2b", "kind": "reason-code", "name": "Invalid file format", "group": "technical", "summary": "The XML file failed syntax or schema (XSD) validation.", "triggers": [ "The file was not filled out correctly", "The file contains an XML syntax error", "The creditor PSP, an intermediary PSP or the CSM passed the file on without checking it against the XSD" ], "actions": [ "Repair the XML file and submit the collections again in a new file", "Validate every file against the XSD for the B2B implementation guidelines before it leaves the creditor [Inference]" ], "retry": { "allowed": true, "rule": "Resubmit the corrected collections in a new file (PT-04.04). A rejected collection that is corrected and presented again must keep its original sequence type: one-off stays one-off, recurrent stays recurrent (PT-04.04, PT-04.06, PT-04.08)." }, "facts": { "return_windows": [ { "action": "reject", "by": "Not named by the EPC for FF01. The rulebook lets a CSM or the Debtor PSP reject for an invalid file format, and a Creditor PSP reject on reasons agreed with the creditor", "deadline": "Before inter-PSP settlement. A creditor PSP rejects on receipt of the creditor's file or later as agreed with the creditor (PT-04.04); a CSM on receipt or as its rules allow (PT-04.06)" } ], "applies_to": "SDD B2B" }, "caveat": "FF01 is a reject reason only. The guidance lists the creditor, the creditor PSP and the CSM as possible root causes, which names who is at fault, not who sends the reject. The rulebook puts an operation code, sequence type or file format error among the reasons a CSM or the debtor PSP may give for a reject (EPC222-07 2025 v1.1 section 4.8.39, AT-R004), and leaves a creditor PSP's reject reasons to its agreement with the creditor. Neither text says which of these parties sends FF01 [Unverified].", "related": [ "sepa-sdd-b2b:AG02" ], "basis": { "sources": "EPC173-14 v8.0 section 3, entry for FF01 (R-transaction types, use cases, root causes, suggested creditor action); EPC222-07 2025 v1.1 sections 4.4, 4.6.4 PT-04.06 and PT-04.08, 4.8.37 AT-R002 and 4.8.39 AT-R004 (reject: who may reject, before settlement); EPC222-07 2025 v1.1 section 4.6.4 PT-04.04, PT-04.06, PT-04.08 (re-presented rejects keep their sequence type).", "confidence": "medium" }, "currency": { "effective_since": "2025-10-05", "effective_note": "EPC222-07 2025 v1.1 was issued and took effect on 2025-10-05; v1.1 changed only the date for the unstructured address phase-out. EPC173-14 v8.0, published 2024-11-28, applies to both SDD rulebooks and is taken to be the current guidance [Unverified]. The next SDD B2B rulebook is due for publication in November 2026 [Unverified].", "source_edition": "EPC173-14 v8.0; EPC222-07 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-10/EPC222-07%202025%20SDD%20B2B%20Rulebook%20version%201.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC173-14 v8.0 Guidance on Reason Codes for SDD R-transactions and EPC222-07 2025 v1.1 SDD Business-to-Business Scheme Rulebook", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17c", "notes": "Confirms FF01 (Invalid file format) as a reject-only reason, per EPC173-14 v8.0 section 3, with Creditor, Creditor PSP and CSM as possible root causes. Confirms the rulebook lets a CSM or Debtor PSP reject for an operation code, sequence type or file format error, and leaves a Creditor PSP's reject reasons to its own agreement with the Creditor, EPC222-07 2025 v1.1 section 4.8.39 AT-R004. Confirms sequence type is kept on a corrected re-presentation, PT-04.04, PT-04.06, PT-04.08. Does not name which party actually sends FF01; the record correctly says the EPC does not state it." } ] }, "rail_name": "SEPA Direct Debit B2B", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sdd-b2b:MD01", "id": "MD01", "rail": "sepa-sdd-b2b", "kind": "reason-code", "name": "No mandate, or unable to obtain mandate confirmation from the Debtor", "group": "authorization", "summary": "The debtor PSP holds no valid B2B mandate for the collection, or could not get the debtor to confirm the mandate before debiting. In B2B this code is a reject or return only; there is no refund.", "triggers": [ "No mandate exists between this creditor and debtor", "The debtor has not yet confirmed the B2B mandate to the debtor PSP", "The debtor PSP tried and failed to get the debtor's confirmation of the mandate", "The debtor cancelled the mandate and told the debtor PSP", "The mandate lapsed after 36 months with no collection presented; the rulebook puts the duty to cancel on the creditor, and the guidance also lists a debtor PSP cancellation on this ground", "The creditor sent no unique mandate reference (UMR), or a UMR that does not match the mandate data" ], "actions": [ "Before the first collection, ask the debtor to tell its debtor PSP about the new mandate and confirm it; the debtor PSP must have that confirmation before debiting (EPC222-07 2025 v1.1 sections 4.1, 4.6.1 PT-01.04 and 5.8 item 10)", "Compare the mandate data in the collection (UMR, CI, debtor IBAN, debtor PSP BIC, scheme code, sequence type) with the signed mandate you hold; these are the attributes the debtor PSP checks (PT-04.09)", "Check whether the debtor cancelled or 36 months passed since the last presented collection; if so, stop and obtain a new mandate", "Answer a mandate copy request promptly: the creditor PSP has up to 3 Banking Business Days to pass it on and the creditor's answer is due within 7 Banking Business Days (PT-06.02, PT-06.03)", "Keep each signed mandate for as long as it exists, and after cancellation as long as national law and the creditor PSP terms require (sections 4.1, PT-01.03)" ], "retry": { "allowed": false, "rule": "Do not collect again until you hold a valid signed B2B mandate that matches the collection data and the debtor has confirmed it to its debtor PSP. After 36 months with no collection presented, a new mandate is required (EPC222-07 2025 v1.1 section 4.2)." }, "facts": { "return_windows": [ { "action": "reject", "by": "CSM or Debtor PSP", "deadline": "Before inter-PSP settlement on the Due Date (D)" }, { "action": "return", "by": "Debtor PSP", "deadline": "Settled no later than 3 Inter-PSP Business Days (TARGET days) after the Settlement Date of the collection (D+3)" } ], "applies_to": "SDD B2B" }, "caveat": "The guidance's refund use of MD01 (unauthorised transaction, 13 months) is for SDD Core only (EPC173-14 v8.0 section 3); refunds are not part of SDD B2B (EPC222-07 2025 v1.1 sections 4.3.4 and 4.4). A B2B debtor who says a collection was unauthorised can still claim from its debtor PSP within 13 months under payment services law; the rulebook's informational Annex V says the debtor PSP may not recover such a refund from the creditor PSP, and Annex VI puts unauthorised refunds outside the scheme. The debtor PSP may instead open the Annex VI inquiry: request to the creditor PSP within 4 Banking Business Days of the debtor's claim, creditor PSP reply within 3 Banking Business Days or 10 if it asks the creditor, creditor answer within 7, and escalation after 20 without a reply. Annex VI still names the CAC for escalation, which the change history says became the Dispute Resolution Committee in 2020 [Inference that escalation now goes to the DRC]. Section 4.1 ties mandate retention to rectification of an unauthorised transaction under section 4.6.4, which has no such step in this rulebook [Unverified what retention period this implies]. Unlike SDD Core, the B2B debtor PSP must check every collection against the confirmed mandate (PT-04.09), so MD01 is the normal result of a failed check [Inference]. The rulebook lists this reason among those a CSM or the debtor PSP may give for a reject, without saying which of the two uses it (section 4.8.39, AT-R004); the debtor PSP is the likely sender, since it holds the mandate data and the debtor's confirmation [Inference].", "related": [ "sepa-sdd-b2b:MD02", "sepa-sdd-b2b:MS02", "sepa-sdd-b2b:SL01", "sepa-sdd-b2b:AC13", "sepa-sdd-b2b:BE05" ], "basis": { "sources": "EPC173-14 v8.0 section 3, entry for MD01 (R-transaction types, use cases, root causes, suggested creditor action); EPC222-07 2025 v1.1 sections 4.4, 4.6.4 PT-04.06 and PT-04.08, 4.8.37 AT-R002 and 4.8.39 AT-R004 (reject: who may reject, before settlement); EPC222-07 2025 v1.1 sections 4.2, 4.3.2, 4.3.4, 4.6.4 PT-04.09 and PT-04.10 and 4.8.39 AT-R004 (return: Debtor PSP, settled by D+3 Inter-PSP Business Days); EPC222-07 2025 v1.1 sections 4.2, 4.3.4 and 4.4 (no refund under the B2B scheme); EPC222-07 2025 v1.1 sections 4.1, 4.2, 4.6.1 PT-01.04 and PT-01.05, 4.6.4 PT-04.09 and 5.8 items 1, 10, 11 and 21 (debtor PSP mandate confirmation and checks); EPC222-07 2025 v1.1 section 4.2 (36-month rule); EPC222-07 2025 v1.1 sections 4.1 and 4.6.1 PT-01.03 (mandate retention); EPC222-07 2025 v1.1 section 4.6.6 PT-06.01 to PT-06.03 (mandate copy); EPC222-07 2025 v1.1 Annex V item 1 and Annex VI sections 1 and 3 (unauthorised claims, inquiry procedure); EPC222-07 2025 v1.1 section 0.2 (CAC replaced by DRC).", "confidence": "high" }, "currency": { "effective_since": "2025-10-05", "effective_note": "EPC222-07 2025 v1.1 was issued and took effect on 2025-10-05; v1.1 changed only the date for the unstructured address phase-out. EPC173-14 v8.0, published 2024-11-28, applies to both SDD rulebooks and is taken to be the current guidance [Unverified]. The next SDD B2B rulebook is due for publication in November 2026 [Unverified].", "source_edition": "EPC173-14 v8.0; EPC222-07 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-10/EPC222-07%202025%20SDD%20B2B%20Rulebook%20version%201.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC173-14 v8.0 Guidance on Reason Codes for SDD R-transactions and EPC222-07 2025 v1.1 SDD Business-to-Business Scheme Rulebook", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17c", "notes": "Confirms MD01 as a reject and return reason for SDD B2B, with no refund under the B2B scheme, per EPC173-14 v8.0 section 3 and EPC222-07 2025 v1.1 sections 4.3.4 and 4.4. Confirms the reject reasons list and the D+3 return window, section 4.8.39 AT-R004 and PT-04.10. Confirms the Annex VI inquiry procedure timelines of 4, 3 or 10, 7 and 20 Banking Business Days, and that the 2019 v1.1 change history dated 05/03/2020 folded the CAC and Appeals Committee into the Dispute Resolution Committee, while Annex VI itself still names the CAC. Does not confirm which body actually handles an escalation today; the record labels that an inference. Does not confirm what mandate retention period section 4.1's cross-reference to section 4.6.4 implies." } ] }, "rail_name": "SEPA Direct Debit B2B", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sdd-b2b:MD02", "id": "MD02", "rail": "sepa-sdd-b2b", "kind": "reason-code", "name": "Mandate data missing or incorrect", "group": "authorization", "summary": "The mandate data carried in the collection is incomplete or does not agree with earlier data, usually after a mandate amendment.", "triggers": [ "Mandate data in the collection differs from the mandate because an amendment was never reported", "The mandate data conflicts with a version already received under the same UMR", "An amendment says the debtor account has changed, yet the collection still carries the old account" ], "actions": [ "Fix how the amendment is reported so it follows the rulebook's amendment process (EPC222-07 2025 v1.1 section 4.6.2, PR-02)", "Check the amended values themselves, then send a corrected collection", "Make sure the debtor has passed the amendment to its debtor PSP, which checks each collection against the mandate data it stored (PT-02.03, PT-02.04, PT-04.09)" ], "retry": { "allowed": true, "rule": "Send a corrected collection with the right mandate and amendment data. A rejected collection that is corrected and presented again must keep its original sequence type: one-off stays one-off, recurrent stays recurrent (PT-04.04, PT-04.06, PT-04.08)." }, "facts": { "return_windows": [ { "action": "reject", "by": "Debtor PSP or CSM", "deadline": "Before inter-PSP settlement on the Due Date (D). A CSM rejects on receipt or on the later days its own rules allow" } ], "applies_to": "SDD B2B" }, "caveat": "MD02 is a reject reason only. The B2B rulebook's return reasons (EPC222-07 2025 v1.1 section 4.8.39, AT-R004) do not include mandate data errors, so a problem found after settlement arrives under another code [Inference: most likely MD01]. The debtor must tell its debtor PSP about an amendment no later than the day it takes effect and before the next Due Date (section 5.8, item 21).", "related": [ "sepa-sdd-b2b:MD01", "sepa-sdd-b2b:BE05" ], "basis": { "sources": "EPC173-14 v8.0 section 3, entry for MD02 (R-transaction types, use cases, root causes, suggested creditor action); EPC222-07 2025 v1.1 sections 4.4, 4.6.4 PT-04.06 and PT-04.08, 4.8.37 AT-R002 and 4.8.39 AT-R004 (reject: who may reject, before settlement); EPC222-07 2025 v1.1 section 4.6.4 PT-04.04, PT-04.06, PT-04.08 (re-presented rejects keep their sequence type); EPC222-07 2025 v1.1 section 4.6.2 PR-02, PT-02.03 and PT-02.04; EPC222-07 2025 v1.1 section 4.6.4 PT-04.09; EPC222-07 2025 v1.1 section 5.8 item 21.", "confidence": "high" }, "currency": { "effective_since": "2025-10-05", "effective_note": "EPC222-07 2025 v1.1 was issued and took effect on 2025-10-05; v1.1 changed only the date for the unstructured address phase-out. EPC173-14 v8.0, published 2024-11-28, applies to both SDD rulebooks and is taken to be the current guidance [Unverified]. The next SDD B2B rulebook is due for publication in November 2026 [Unverified].", "source_edition": "EPC173-14 v8.0; EPC222-07 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-10/EPC222-07%202025%20SDD%20B2B%20Rulebook%20version%201.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC173-14 v8.0 Guidance on Reason Codes for SDD R-transactions and EPC222-07 2025 v1.1 SDD Business-to-Business Scheme Rulebook", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17c", "notes": "Confirms MD02 as a reject-only reason for Debtor PSP or CSM, per EPC173-14 v8.0 section 3 and EPC222-07 2025 v1.1 section 4.8.39 AT-R004; absent from the return list. Confirms sequence type is kept on re-presentation, PT-04.04, PT-04.06, PT-04.08, and the debtor's duty to report a mandate amendment to its Debtor PSP before the next Due Date, section 5.8 item 21. Confirms the trigger wording no longer copies EPC173-14's IBAN example word for word. Does not confirm which code a post-settlement mandate data problem actually uses." } ] }, "rail_name": "SEPA Direct Debit B2B", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sdd-b2b:MD07", "id": "MD07", "rail": "sepa-sdd-b2b", "kind": "reason-code", "name": "Debtor deceased", "group": "account", "summary": "The debtor has died.", "triggers": [ "The debtor PSP has been told the debtor has died" ], "actions": [ "Close the agreement with the deceased debtor", "Stop all collections under the mandate", "Pursue any amount still owed through the estate, outside the scheme [Inference]" ], "retry": { "allowed": false, "rule": "Do not collect again under this mandate." }, "facts": { "return_windows": [ { "action": "reject", "by": "Debtor PSP or CSM", "deadline": "Before inter-PSP settlement on the Due Date (D). A CSM rejects on receipt or on the later days its own rules allow" }, { "action": "return", "by": "Debtor PSP", "deadline": "Settled no later than 3 Inter-PSP Business Days (TARGET days) after the Settlement Date of the collection (D+3)" } ], "applies_to": "SDD B2B" }, "caveat": "Data protection law in certain SEPA countries bars this code, and debtor PSPs there send MS03 instead (EPC173-14 v8.0 section 3). The guidance does not name the countries. B2B debtors are non-consumers, so this code should be rare, for example where a sole trader holds the account [Inference].", "related": [ "sepa-sdd-b2b:MS03", "sepa-sdd-b2b:AC04" ], "basis": { "sources": "EPC173-14 v8.0 section 3, entry for MD07 (R-transaction types, use cases, root causes, suggested creditor action); EPC222-07 2025 v1.1 sections 4.4, 4.6.4 PT-04.06 and PT-04.08, 4.8.37 AT-R002 and 4.8.39 AT-R004 (reject: who may reject, before settlement); EPC222-07 2025 v1.1 sections 4.2, 4.3.2, 4.3.4, 4.6.4 PT-04.09 and PT-04.10 and 4.8.39 AT-R004 (return: Debtor PSP, settled by D+3 Inter-PSP Business Days); EPC222-07 2025 v1.1 section 2.2 (debtors are non-consumers).", "confidence": "high" }, "currency": { "effective_since": "2025-10-05", "effective_note": "EPC222-07 2025 v1.1 was issued and took effect on 2025-10-05; v1.1 changed only the date for the unstructured address phase-out. EPC173-14 v8.0, published 2024-11-28, applies to both SDD rulebooks and is taken to be the current guidance [Unverified]. The next SDD B2B rulebook is due for publication in November 2026 [Unverified].", "source_edition": "EPC173-14 v8.0; EPC222-07 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-10/EPC222-07%202025%20SDD%20B2B%20Rulebook%20version%201.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC173-14 v8.0 Guidance on Reason Codes for SDD R-transactions and EPC222-07 2025 v1.1 SDD Business-to-Business Scheme Rulebook", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms the code name and B2B scope (EPC173-14 v8.0 section 3). Confirms the reject window: before Inter-PSP Settlement on the Due Date, sent by the Debtor PSP or the CSM (EPC222-07 2025 v1.1 sections 4.6.4 PT-04.06 and PT-04.08, section 4.8.39 AT-R004). Confirms the return window: settled no later than D+3 Inter-PSP Business Days, sent by the Debtor PSP (sections 4.6.4 PT-04.09 and PT-04.10). Does not confirm how rare MD07 is in B2B relative to Core." } ] }, "rail_name": "SEPA Direct Debit B2B", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sdd-b2b:MS02", "id": "MS02", "rail": "sepa-sdd-b2b", "kind": "reason-code", "name": "Refusal by the Debtor", "group": "authorization", "summary": "The debtor refused the collection, usually after seeing the pre-notification. No further reason is given.", "triggers": [ "The debtor received the pre-notification and told the debtor PSP not to pay this collection" ], "actions": [ "Contact the debtor to find out why and whether the mandate still stands", "Do not treat a refusal as a mandate cancellation unless the debtor says so [Inference]" ], "retry": { "allowed": false, "rule": "Do not present the refused collection again before speaking to the debtor. The texts read set no scheme rule on this [Unverified]." }, "facts": { "return_windows": [ { "action": "refusal", "by": "Debtor, instructing the Debtor PSP", "deadline": "Up to and including the Due Date for the scheme; the exact cut-off is agreed between the Debtor and the Debtor PSP" }, { "action": "reject", "by": "Debtor PSP", "deadline": "Before inter-PSP settlement on the Due Date (D)" }, { "action": "return", "by": "Debtor PSP", "deadline": "Settled by preference on the Due Date and no later than 3 Inter-PSP Business Days (TARGET days) after the Settlement Date of the collection (D+3)" }, { "action": "reversal", "by": "Creditor or Creditor PSP", "deadline": "From the Settlement Date (D) to D+5 Inter-PSP Business Days, counted end to end from the creditor's instruction to CSM forwarding" } ], "applies_to": "SDD B2B" }, "caveat": "A refusal is not itself an inter-PSP message: before settlement the debtor PSP turns it into a reject, after settlement into a return (EPC222-07 2025 v1.1 section 4.4, PT-04.02 bis). With no refund in B2B, a refusal is the debtor's only in-scheme way to stop a single authorised collection; the debtor may also prohibit all B2B collections on the account (sections 4.2 and 5.8, item 5). The guidance also lists reversal as a use of MS02, but the rulebook's reversal reasons (section 4.8.53, AT-R041) are only a duplicate and an unspecified reason, and a reversal is a creditor-side action; the reversal entry here follows the guidance and is unconfirmed [Unverified]. Standing blocks and verification instructions the debtor sets with its PSP usually surface as SL01 or MD01 instead [Inference].", "related": [ "sepa-sdd-b2b:SL01", "sepa-sdd-b2b:MD01", "sepa-sdd-b2b:MS03" ], "basis": { "sources": "EPC173-14 v8.0 section 3, entry for MS02 (R-transaction types, use cases, root causes, suggested creditor action); EPC222-07 2025 v1.1 sections 4.2, 4.3.4, 4.4 and 4.6.4 PT-04.02 bis (refusal: up to and including the Due Date; return by D+3); EPC222-07 2025 v1.1 sections 4.4, 4.6.4 PT-04.06 and PT-04.08, 4.8.37 AT-R002 and 4.8.39 AT-R004 (reject: who may reject, before settlement); EPC222-07 2025 v1.1 sections 4.2, 4.3.2, 4.3.4, 4.6.4 PT-04.09 and PT-04.10 and 4.8.39 AT-R004 (return: Debtor PSP, settled by D+3 Inter-PSP Business Days); EPC222-07 2025 v1.1 sections 4.3.4, 4.4, 4.6.5 PT-05.01 to PT-05.03 and 4.8.53 AT-R041 (reversal: Creditor or Creditor PSP, D to D+5 Inter-PSP Business Days); EPC222-07 2025 v1.1 sections 4.2, 4.3.4 and 4.4 (no refund under the B2B scheme); EPC222-07 2025 v1.1 section 5.8 item 5.", "confidence": "medium" }, "currency": { "effective_since": "2025-10-05", "effective_note": "EPC222-07 2025 v1.1 was issued and took effect on 2025-10-05; v1.1 changed only the date for the unstructured address phase-out. EPC173-14 v8.0, published 2024-11-28, applies to both SDD rulebooks and is taken to be the current guidance [Unverified]. The next SDD B2B rulebook is due for publication in November 2026 [Unverified].", "source_edition": "EPC173-14 v8.0; EPC222-07 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-10/EPC222-07%202025%20SDD%20B2B%20Rulebook%20version%201.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC173-14 v8.0 Guidance on Reason Codes for SDD R-transactions and EPC222-07 2025 v1.1 SDD Business-to-Business Scheme Rulebook", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms the code name, B2B scope, and that MS02 covers Refusal, Reject, Return and Reversal (EPC173-14 v8.0 section 3). Confirms the refusal window: up to and including the Due Date, cut-off agreed between Debtor and Debtor PSP, resulting in a Reject if handled before settlement and a Return if after (EPC222-07 2025 v1.1 section 4.6.4 PT-04.02bis). Confirms the reject window: before Inter-PSP Settlement on the Due Date, by the Debtor PSP (sections 4.4 and 4.6.4 PT-04.08). Confirms the return window: D+3 Inter-PSP Business Days, by the Debtor PSP (sections 4.6.4 PT-04.09 and PT-04.10). Confirms the reversal window: D to D+5 Inter-PSP Business Days, by the Creditor or Creditor PSP (sections 4.5.5 and 4.6.5 PT-05.01 through PT-05.03)." } ] }, "rail_name": "SEPA Direct Debit B2B", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sdd-b2b:MS03", "id": "MS03", "rail": "sepa-sdd-b2b", "kind": "reason-code", "name": "Reason not specified", "group": "administrative", "summary": "No reason is given. A debtor PSP should use it only where national law, such as data protection law, bars the specific code. On a reversal, the creditor side may use it freely.", "triggers": [ "The real reason is account closed (AC04), insufficient funds (AM04), debtor deceased (MD07) or a regulatory reason (RR01 to RR04), and national law bars disclosing it", "On a reversal, the creditor or creditor PSP chose not to give a reason (EPC222-07 2025 v1.1 section 4.8.53, AT-R041)" ], "actions": [ "Contact the debtor to find out what happened", "Read an MS03 reject or return as possibly hiding AC04, AM04, MD07 or RR01 to RR04; do not assume insufficient funds [Inference]", "Track MS03 by debtor PSP country, and raise heavy use from one debtor PSP with the creditor PSP [Inference]" ], "retry": { "allowed": false, "rule": "The texts read set no scheme retry rule [Unverified]. Because the underlying reason is unknown, find it out from the debtor before collecting again [Inference]." }, "facts": { "return_windows": [ { "action": "reject", "by": "Debtor PSP or CSM", "deadline": "Before inter-PSP settlement on the Due Date (D). A CSM rejects on receipt or on the later days its own rules allow" }, { "action": "return", "by": "Debtor PSP", "deadline": "Settled no later than 3 Inter-PSP Business Days (TARGET days) after the Settlement Date of the collection (D+3)" }, { "action": "reversal", "by": "Creditor or Creditor PSP", "deadline": "From the Settlement Date (D) to D+5 Inter-PSP Business Days, counted end to end from the creditor's instruction to CSM forwarding" } ], "applies_to": "SDD B2B" }, "caveat": "The guidance asks PSPs to limit MS03 and pick a specific code wherever the law allows (EPC173-14 v8.0 sections 2 and 3). It does not list which countries restrict which codes.", "related": [ "sepa-sdd-b2b:AC04", "sepa-sdd-b2b:AM04", "sepa-sdd-b2b:MD07", "sepa-sdd-b2b:RR01", "sepa-sdd-b2b:RR02", "sepa-sdd-b2b:RR03", "sepa-sdd-b2b:RR04", "sepa-sdd-b2b:AM05", "sepa-sdd-b2b:MS02" ], "basis": { "sources": "EPC173-14 v8.0 section 3, entry for MS03 (R-transaction types, use cases, root causes, suggested creditor action); EPC222-07 2025 v1.1 sections 4.4, 4.6.4 PT-04.06 and PT-04.08, 4.8.37 AT-R002 and 4.8.39 AT-R004 (reject: who may reject, before settlement); EPC222-07 2025 v1.1 sections 4.2, 4.3.2, 4.3.4, 4.6.4 PT-04.09 and PT-04.10 and 4.8.39 AT-R004 (return: Debtor PSP, settled by D+3 Inter-PSP Business Days); EPC222-07 2025 v1.1 sections 4.3.4, 4.4, 4.6.5 PT-05.01 to PT-05.03 and 4.8.53 AT-R041 (reversal: Creditor or Creditor PSP, D to D+5 Inter-PSP Business Days); EPC173-14 v8.0 section 2 (avoid general codes where a precise one is lawful).", "confidence": "high" }, "currency": { "effective_since": "2025-10-05", "effective_note": "EPC222-07 2025 v1.1 was issued and took effect on 2025-10-05; v1.1 changed only the date for the unstructured address phase-out. EPC173-14 v8.0, published 2024-11-28, applies to both SDD rulebooks and is taken to be the current guidance [Unverified]. The next SDD B2B rulebook is due for publication in November 2026 [Unverified].", "source_edition": "EPC173-14 v8.0; EPC222-07 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-10/EPC222-07%202025%20SDD%20B2B%20Rulebook%20version%201.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC173-14 v8.0 Guidance on Reason Codes for SDD R-transactions and EPC222-07 2025 v1.1 SDD Business-to-Business Scheme Rulebook", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms the code name, B2B scope, and that MS03 covers Reject, Return and Reversal, used only where national legislation bars AC04, AM04, MD07, RR01 through RR04 (EPC173-14 v8.0 section 3). Confirms the reject window: before Inter-PSP Settlement on the Due Date, sent by the Debtor PSP or the CSM (EPC222-07 2025 v1.1 sections 4.6.4 PT-04.06 and PT-04.08, section 4.8.39 AT-R004 'Reason not specified'). Confirms the return window: D+3 Inter-PSP Business Days, sent by the Debtor PSP (sections 4.6.4 PT-04.09 and PT-04.10). Confirms the reversal window: D to D+5 Inter-PSP Business Days, sent by the Creditor or Creditor PSP (sections 4.5.5 and 4.6.5 PT-05.01 through PT-05.03)." } ] }, "rail_name": "SEPA Direct Debit B2B", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sdd-b2b:RC01", "id": "RC01", "rail": "sepa-sdd-b2b", "kind": "reason-code", "name": "PSP identifier incorrect (invalid BIC)", "group": "technical", "summary": "A BIC on the collection is wrong, incomplete, or does not exist in the BIC directory.", "triggers": [ "For a collection involving a non-EEA SEPA country, the creditor supplied an 8-character BIC where the full 11-character BIC was needed", "The creditor PSP, the CSM or the debtor PSP put a BIC in the inter-PSP message that is not in the BIC directory" ], "actions": [ "For a non-EEA collection, get the correct and complete BIC from the debtor", "Ask the creditor PSP to put the correct and complete debtor PSP BIC in the inter-PSP message" ], "retry": { "allowed": true, "rule": "Correct the BIC and collect again. A rejected collection that is corrected and presented again must keep its original sequence type: one-off stays one-off, recurrent stays recurrent (PT-04.04, PT-04.06, PT-04.08)." }, "facts": { "return_windows": [ { "action": "reject", "by": "Debtor PSP or CSM", "deadline": "Before inter-PSP settlement on the Due Date (D). A CSM rejects on receipt or on the later days its own rules allow" }, { "action": "return", "by": "Debtor PSP", "deadline": "Settled no later than 3 Inter-PSP Business Days (TARGET days) after the Settlement Date of the collection (D+3)" } ], "applies_to": "SDD B2B" }, "caveat": "A customer needs to give a BIC only where at least one of the two PSPs is in a non-EEA SEPA country (EPC222-07 2025 v1.1 sections 4.7.2 DS-01 and 4.7.4 DS-03). Within the EEA the IBAN is enough, so RC01 on an EEA collection points to a PSP or CSM data error [Inference]. The B2B mandate check lists the debtor PSP BIC among the attributes that must match (section 4.6.4, PT-04.09); how that applies to an EEA mandate that carries no BIC is not stated [Unverified].", "related": [ "sepa-sdd-b2b:DNOR", "sepa-sdd-b2b:CNOR", "sepa-sdd-b2b:AC01" ], "basis": { "sources": "EPC173-14 v8.0 section 3, entry for RC01 (R-transaction types, use cases, root causes, suggested creditor action); EPC222-07 2025 v1.1 sections 4.4, 4.6.4 PT-04.06 and PT-04.08, 4.8.37 AT-R002 and 4.8.39 AT-R004 (reject: who may reject, before settlement); EPC222-07 2025 v1.1 sections 4.2, 4.3.2, 4.3.4, 4.6.4 PT-04.09 and PT-04.10 and 4.8.39 AT-R004 (return: Debtor PSP, settled by D+3 Inter-PSP Business Days); EPC222-07 2025 v1.1 section 4.6.4 PT-04.04, PT-04.06, PT-04.08 (re-presented rejects keep their sequence type); EPC222-07 2025 v1.1 sections 4.7.2 DS-01 and 4.7.4 DS-03 (BIC only for non-EEA cases); EPC222-07 2025 v1.1 section 4.6.4 PT-04.09.", "confidence": "high" }, "currency": { "effective_since": "2025-10-05", "effective_note": "EPC222-07 2025 v1.1 was issued and took effect on 2025-10-05; v1.1 changed only the date for the unstructured address phase-out. EPC173-14 v8.0, published 2024-11-28, applies to both SDD rulebooks and is taken to be the current guidance [Unverified]. The next SDD B2B rulebook is due for publication in November 2026 [Unverified].", "source_edition": "EPC173-14 v8.0; EPC222-07 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-10/EPC222-07%202025%20SDD%20B2B%20Rulebook%20version%201.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC173-14 v8.0 Guidance on Reason Codes for SDD R-transactions and EPC222-07 2025 v1.1 SDD Business-to-Business Scheme Rulebook", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms the code name and B2B scope (EPC173-14 v8.0 section 3). Confirms the reject window: before Inter-PSP Settlement on the Due Date, sent by the Debtor PSP or the CSM (EPC222-07 2025 v1.1 sections 4.6.4 PT-04.06 and PT-04.08, section 4.8.39 AT-R004). Confirms the return window: settled no later than D+3 Inter-PSP Business Days, sent by the Debtor PSP (sections 4.6.4 PT-04.09 and PT-04.10). Confirms a BIC is only mandatory when at least one PSP is outside the EEA (sections 4.7.2 DS-01 and 4.7.4 DS-03). Does not state how the debtor PSP BIC check at PT-04.09 applies to an EEA mandate with no BIC." } ] }, "rail_name": "SEPA Direct Debit B2B", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sdd-b2b:RR01", "id": "RR01", "rail": "sepa-sdd-b2b", "kind": "reason-code", "name": "Regulatory reason: missing debtor account or identification", "group": "administrative", "summary": "Debtor account or identification details that regulation requires are missing or insufficient.", "triggers": [ "The debtor's IBAN or unique identification, needed for regulatory reasons, is missing or incomplete" ], "actions": [ "Complete the debtor account information in the collection", "Contact the creditor PSP" ], "retry": { "allowed": true, "rule": "Complete the missing data and collect again. A rejected collection that is corrected and presented again must keep its original sequence type: one-off stays one-off, recurrent stays recurrent (PT-04.04, PT-04.06, PT-04.08)." }, "facts": { "return_windows": [ { "action": "reject", "by": "Debtor PSP or CSM", "deadline": "Before inter-PSP settlement on the Due Date (D). A CSM rejects on receipt or on the later days its own rules allow" }, { "action": "return", "by": "Debtor PSP", "deadline": "Settled no later than 3 Inter-PSP Business Days (TARGET days) after the Settlement Date of the collection (D+3)" } ], "applies_to": "SDD B2B" }, "caveat": "Data protection law in certain SEPA countries bars this code, and debtor PSPs there send MS03 instead (EPC173-14 v8.0 section 3). The guidance does not name the countries. The texts read do not name the regulation behind the requirement [Unverified; the rulebook's section 5.1 cites the Regulation on Information accompanying Transfers of Funds, which is a likely source, Inference].", "related": [ "sepa-sdd-b2b:RR02", "sepa-sdd-b2b:RR03", "sepa-sdd-b2b:RR04", "sepa-sdd-b2b:MS03" ], "basis": { "sources": "EPC173-14 v8.0 section 3, entry for RR01 (R-transaction types, use cases, root causes, suggested creditor action); EPC222-07 2025 v1.1 sections 4.4, 4.6.4 PT-04.06 and PT-04.08, 4.8.37 AT-R002 and 4.8.39 AT-R004 (reject: who may reject, before settlement); EPC222-07 2025 v1.1 sections 4.2, 4.3.2, 4.3.4, 4.6.4 PT-04.09 and PT-04.10 and 4.8.39 AT-R004 (return: Debtor PSP, settled by D+3 Inter-PSP Business Days); EPC222-07 2025 v1.1 section 4.6.4 PT-04.04, PT-04.06, PT-04.08 (re-presented rejects keep their sequence type); EPC222-07 2025 v1.1 section 5.1.", "confidence": "high" }, "currency": { "effective_since": "2025-10-05", "effective_note": "EPC222-07 2025 v1.1 was issued and took effect on 2025-10-05; v1.1 changed only the date for the unstructured address phase-out. EPC173-14 v8.0, published 2024-11-28, applies to both SDD rulebooks and is taken to be the current guidance [Unverified]. The next SDD B2B rulebook is due for publication in November 2026 [Unverified].", "source_edition": "EPC173-14 v8.0; EPC222-07 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-10/EPC222-07%202025%20SDD%20B2B%20Rulebook%20version%201.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC173-14 v8.0 Guidance on Reason Codes for SDD R-transactions and EPC222-07 2025 v1.1 SDD Business-to-Business Scheme Rulebook", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms the code name, B2B scope, and that the rulebook's reason specified for RR01 through RR04 is 'Regulatory Reason' throughout, falling under the same AT-R004 regulatory-reason bucket (EPC173-14 v8.0 section 3; EPC222-07 2025 v1.1 section 4.8.39 AT-R004). Confirms the reject window: before Inter-PSP Settlement on the Due Date, sent by the Debtor PSP or the CSM (sections 4.6.4 PT-04.06 and PT-04.08). Confirms the return window: settled no later than D+3 Inter-PSP Business Days, sent by the Debtor PSP (sections 4.6.4 PT-04.09 and PT-04.10). Does not name the underlying regulation by section." } ] }, "rail_name": "SEPA Direct Debit B2B", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sdd-b2b:RR02", "id": "RR02", "rail": "sepa-sdd-b2b", "kind": "reason-code", "name": "Regulatory reason: missing debtor name or address", "group": "administrative", "summary": "The debtor's name, or where required the debtor's address, is missing, or the address is in a format no longer allowed.", "triggers": [ "The collection has no debtor name", "A collection involving a non-EEA SEPA country has no debtor address; within the EEA the address is optional", "The debtor address is in an invalid format, or an unstructured address is sent after the November 2026 phase-out" ], "actions": [ "Add the debtor name and, where required, the debtor address in an allowed format", "Move stored debtor addresses to structured or hybrid form before 15 November 2026", "Contact the creditor PSP" ], "retry": { "allowed": true, "rule": "Complete or correct the data and collect again. A rejected collection that is corrected and presented again must keep its original sequence type: one-off stays one-off, recurrent stays recurrent (PT-04.04, PT-04.06, PT-04.08)." }, "facts": { "return_windows": [ { "action": "reject", "by": "Debtor PSP or CSM", "deadline": "Before inter-PSP settlement on the Due Date (D). A CSM rejects on receipt or on the later days its own rules allow" }, { "action": "return", "by": "Debtor PSP", "deadline": "Settled no later than 3 Inter-PSP Business Days (TARGET days) after the Settlement Date of the collection (D+3)" } ], "applies_to": "SDD B2B" }, "caveat": "From 15 November 2026 only structured or hybrid addresses are allowed; unstructured addresses are no longer accepted (EPC222-07 2025 v1.1 cover note, sections 4.8.14 AT-E004 and 4.8.20 AT-P005). EPC173-14 v8.0 predates the change of date and says only November 2026. Data protection law in certain SEPA countries bars this code, and debtor PSPs there send MS03 instead (EPC173-14 v8.0 section 3). The guidance does not name the countries. The texts read do not name the regulation behind the requirement [Unverified; the rulebook's section 5.1 cites the Regulation on Information accompanying Transfers of Funds, which is a likely source, Inference].", "related": [ "sepa-sdd-b2b:RR01", "sepa-sdd-b2b:RR03", "sepa-sdd-b2b:RR04", "sepa-sdd-b2b:MS03" ], "basis": { "sources": "EPC173-14 v8.0 section 3, entry for RR02 (R-transaction types, use cases, root causes, suggested creditor action); EPC222-07 2025 v1.1 sections 4.4, 4.6.4 PT-04.06 and PT-04.08, 4.8.37 AT-R002 and 4.8.39 AT-R004 (reject: who may reject, before settlement); EPC222-07 2025 v1.1 sections 4.2, 4.3.2, 4.3.4, 4.6.4 PT-04.09 and PT-04.10 and 4.8.39 AT-R004 (return: Debtor PSP, settled by D+3 Inter-PSP Business Days); EPC222-07 2025 v1.1 section 4.6.4 PT-04.04, PT-04.06, PT-04.08 (re-presented rejects keep their sequence type); EPC222-07 2025 v1.1 cover note (IMPORTANT MESSAGE), sections 4.8.20 AT-P005 and 5.1.", "confidence": "high" }, "currency": { "effective_since": "2025-10-05", "effective_note": "EPC222-07 2025 v1.1 was issued and took effect on 2025-10-05; v1.1 changed only the date for the unstructured address phase-out. EPC173-14 v8.0, published 2024-11-28, applies to both SDD rulebooks and is taken to be the current guidance [Unverified]. The next SDD B2B rulebook is due for publication in November 2026 [Unverified].", "source_edition": "EPC173-14 v8.0; EPC222-07 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-10/EPC222-07%202025%20SDD%20B2B%20Rulebook%20version%201.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC173-14 v8.0 Guidance on Reason Codes for SDD R-transactions and EPC222-07 2025 v1.1 SDD Business-to-Business Scheme Rulebook", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms the code name, B2B scope, and that the rulebook's reason specified for RR01 through RR04 is 'Regulatory Reason' throughout, falling under the same AT-R004 regulatory-reason bucket (EPC173-14 v8.0 section 3; EPC222-07 2025 v1.1 section 4.8.39 AT-R004). Confirms the reject window: before Inter-PSP Settlement on the Due Date, sent by the Debtor PSP or the CSM (sections 4.6.4 PT-04.06 and PT-04.08). Confirms the return window: settled no later than D+3 Inter-PSP Business Days, sent by the Debtor PSP (sections 4.6.4 PT-04.09 and PT-04.10). Does not name the underlying regulation by section." } ] }, "rail_name": "SEPA Direct Debit B2B", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sdd-b2b:RR03", "id": "RR03", "rail": "sepa-sdd-b2b", "kind": "reason-code", "name": "Regulatory reason: missing creditor name or address", "group": "administrative", "summary": "The creditor's name is missing, or the creditor address is in a format no longer allowed.", "triggers": [ "The collection has no creditor name; the creditor address itself is optional", "The creditor address is in an invalid format, or an unstructured address is sent after the November 2026 phase-out" ], "actions": [ "Add the creditor name to the collection", "Send any creditor address in structured or hybrid form from 15 November 2026", "Contact the creditor PSP" ], "retry": { "allowed": true, "rule": "Complete or correct the data and collect again. A rejected collection that is corrected and presented again must keep its original sequence type: one-off stays one-off, recurrent stays recurrent (PT-04.04, PT-04.06, PT-04.08)." }, "facts": { "return_windows": [ { "action": "reject", "by": "Debtor PSP or CSM", "deadline": "Before inter-PSP settlement on the Due Date (D). A CSM rejects on receipt or on the later days its own rules allow" }, { "action": "return", "by": "Debtor PSP", "deadline": "Settled no later than 3 Inter-PSP Business Days (TARGET days) after the Settlement Date of the collection (D+3)" } ], "applies_to": "SDD B2B" }, "caveat": "From 15 November 2026 only structured or hybrid addresses are allowed; unstructured addresses are no longer accepted (EPC222-07 2025 v1.1 cover note, sections 4.8.14 AT-E004 and 4.8.20 AT-P005). EPC173-14 v8.0 predates the change of date and says only November 2026. Data protection law in certain SEPA countries bars this code, and debtor PSPs there send MS03 instead (EPC173-14 v8.0 section 3). The guidance does not name the countries. The texts read do not name the regulation behind the requirement [Unverified; the rulebook's section 5.1 cites the Regulation on Information accompanying Transfers of Funds, which is a likely source, Inference].", "related": [ "sepa-sdd-b2b:RR01", "sepa-sdd-b2b:RR02", "sepa-sdd-b2b:RR04", "sepa-sdd-b2b:MS03" ], "basis": { "sources": "EPC173-14 v8.0 section 3, entry for RR03 (R-transaction types, use cases, root causes, suggested creditor action); EPC222-07 2025 v1.1 sections 4.4, 4.6.4 PT-04.06 and PT-04.08, 4.8.37 AT-R002 and 4.8.39 AT-R004 (reject: who may reject, before settlement); EPC222-07 2025 v1.1 sections 4.2, 4.3.2, 4.3.4, 4.6.4 PT-04.09 and PT-04.10 and 4.8.39 AT-R004 (return: Debtor PSP, settled by D+3 Inter-PSP Business Days); EPC222-07 2025 v1.1 section 4.6.4 PT-04.04, PT-04.06, PT-04.08 (re-presented rejects keep their sequence type); EPC222-07 2025 v1.1 cover note (IMPORTANT MESSAGE), sections 4.8.14 AT-E004 and 5.1.", "confidence": "high" }, "currency": { "effective_since": "2025-10-05", "effective_note": "EPC222-07 2025 v1.1 was issued and took effect on 2025-10-05; v1.1 changed only the date for the unstructured address phase-out. EPC173-14 v8.0, published 2024-11-28, applies to both SDD rulebooks and is taken to be the current guidance [Unverified]. The next SDD B2B rulebook is due for publication in November 2026 [Unverified].", "source_edition": "EPC173-14 v8.0; EPC222-07 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-10/EPC222-07%202025%20SDD%20B2B%20Rulebook%20version%201.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC173-14 v8.0 Guidance on Reason Codes for SDD R-transactions and EPC222-07 2025 v1.1 SDD Business-to-Business Scheme Rulebook", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms the code name, B2B scope, and that the rulebook's reason specified for RR01 through RR04 is 'Regulatory Reason' throughout, falling under the same AT-R004 regulatory-reason bucket (EPC173-14 v8.0 section 3; EPC222-07 2025 v1.1 section 4.8.39 AT-R004). Confirms the reject window: before Inter-PSP Settlement on the Due Date, sent by the Debtor PSP or the CSM (sections 4.6.4 PT-04.06 and PT-04.08). Confirms the return window: settled no later than D+3 Inter-PSP Business Days, sent by the Debtor PSP (sections 4.6.4 PT-04.09 and PT-04.10). Does not name the underlying regulation by section." } ] }, "rail_name": "SEPA Direct Debit B2B", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sdd-b2b:RR04", "id": "RR04", "rail": "sepa-sdd-b2b", "kind": "reason-code", "name": "Regulatory reason", "group": "administrative", "summary": "A regulatory reason other than those covered by RR01, RR02 and RR03. The code carries no further detail.", "triggers": [ "A regulatory requirement not covered by RR01, RR02 or RR03 stops the debtor PSP or the CSM from processing the collection", "Sanctions or anti-money-laundering screening results [Unverified; the EPC texts read do not say so]" ], "actions": [ "Contact the creditor PSP to learn what is needed" ], "retry": { "allowed": false, "rule": "Do not present again until the creditor PSP has established what the regulatory issue is [Inference]." }, "facts": { "return_windows": [ { "action": "reject", "by": "Debtor PSP or CSM", "deadline": "Before inter-PSP settlement on the Due Date (D). A CSM rejects on receipt or on the later days its own rules allow" }, { "action": "return", "by": "Debtor PSP", "deadline": "Settled no later than 3 Inter-PSP Business Days (TARGET days) after the Settlement Date of the collection (D+3)" } ], "applies_to": "SDD B2B" }, "caveat": "Data protection law in certain SEPA countries bars this code, and debtor PSPs there send MS03 instead (EPC173-14 v8.0 section 3). The guidance does not name the countries. The guidance reserves RR04 for regulatory reasons other than RR01 to RR03.", "related": [ "sepa-sdd-b2b:RR01", "sepa-sdd-b2b:RR02", "sepa-sdd-b2b:RR03", "sepa-sdd-b2b:MS03" ], "basis": { "sources": "EPC173-14 v8.0 section 3, entry for RR04 (R-transaction types, use cases, root causes, suggested creditor action); EPC222-07 2025 v1.1 sections 4.4, 4.6.4 PT-04.06 and PT-04.08, 4.8.37 AT-R002 and 4.8.39 AT-R004 (reject: who may reject, before settlement); EPC222-07 2025 v1.1 sections 4.2, 4.3.2, 4.3.4, 4.6.4 PT-04.09 and PT-04.10 and 4.8.39 AT-R004 (return: Debtor PSP, settled by D+3 Inter-PSP Business Days).", "confidence": "medium" }, "currency": { "effective_since": "2025-10-05", "effective_note": "EPC222-07 2025 v1.1 was issued and took effect on 2025-10-05; v1.1 changed only the date for the unstructured address phase-out. EPC173-14 v8.0, published 2024-11-28, applies to both SDD rulebooks and is taken to be the current guidance [Unverified]. The next SDD B2B rulebook is due for publication in November 2026 [Unverified].", "source_edition": "EPC173-14 v8.0; EPC222-07 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-10/EPC222-07%202025%20SDD%20B2B%20Rulebook%20version%201.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC173-14 v8.0 Guidance on Reason Codes for SDD R-transactions and EPC222-07 2025 v1.1 SDD Business-to-Business Scheme Rulebook", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms the code name, B2B scope, and that the rulebook's reason specified for RR01 through RR04 is 'Regulatory Reason' throughout, falling under the same AT-R004 regulatory-reason bucket (EPC173-14 v8.0 section 3; EPC222-07 2025 v1.1 section 4.8.39 AT-R004). Confirms the reject window: before Inter-PSP Settlement on the Due Date, sent by the Debtor PSP or the CSM (sections 4.6.4 PT-04.06 and PT-04.08). Confirms the return window: settled no later than D+3 Inter-PSP Business Days, sent by the Debtor PSP (sections 4.6.4 PT-04.09 and PT-04.10). Does not name the underlying regulation by section." } ] }, "rail_name": "SEPA Direct Debit B2B", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sdd-b2b:SL01", "id": "SL01", "rail": "sepa-sdd-b2b", "kind": "reason-code", "name": "Specific service offered by the Debtor PSP", "group": "authorization", "summary": "The debtor PSP stopped the collection because of a service it offers the debtor, most often a control the debtor set: a creditor block, an amount limit or a frequency limit.", "triggers": [ "The debtor blocked this creditor", "The collection exceeds an amount limit the debtor set", "The collection exceeds a frequency limit the debtor set", "Another service the debtor PSP offers; the texts give no examples, and an authorisation or stop payment feature is one possibility [Inference]" ], "actions": [ "Contact the debtor; only the debtor can lift a block or change a limit", "Check whether the amount or frequency changed from what the debtor expects" ], "retry": { "allowed": false, "rule": "Do not present again until the debtor confirms the block or limit has changed [Inference]." }, "facts": { "return_windows": [ { "action": "reject", "by": "CSM or Debtor PSP", "deadline": "Before inter-PSP settlement on the Due Date (D)" }, { "action": "return", "by": "Debtor PSP", "deadline": "Settled no later than 3 Inter-PSP Business Days (TARGET days) after the Settlement Date of the collection (D+3)" } ], "applies_to": "SDD B2B" }, "caveat": "In B2B the debtor PSP must offer debtors a way to prohibit all B2B collections, and it checks each collection against verification instructions agreed with the debtor, which may add attributes beyond the mandatory ones (EPC222-07 2025 v1.1 sections 4.2, 4.6.4 PT-04.09 and 5.8 items 1 and 5). A collection stopped under those instructions may surface as SL01 [Inference; the rulebook names no code for it]. The guidance describes SL01 cases as debtor-invoked consumer-right rejects (EPC173-14 v8.0 section 3), wording that fits B2B's non-consumer debtors loosely [Inference]. The rulebook lists this reason among those a CSM or the debtor PSP may give for a reject, without saying which of the two uses it (section 4.8.39, AT-R004); the debtor PSP is the likely sender, since the service is its own [Inference].", "related": [ "sepa-sdd-b2b:MS02", "sepa-sdd-b2b:AC06", "sepa-sdd-b2b:MD01" ], "basis": { "sources": "EPC173-14 v8.0 section 3, entry for SL01 (R-transaction types, use cases, root causes, suggested creditor action); EPC222-07 2025 v1.1 sections 4.4, 4.6.4 PT-04.06 and PT-04.08, 4.8.37 AT-R002 and 4.8.39 AT-R004 (reject: who may reject, before settlement); EPC222-07 2025 v1.1 sections 4.2, 4.3.2, 4.3.4, 4.6.4 PT-04.09 and PT-04.10 and 4.8.39 AT-R004 (return: Debtor PSP, settled by D+3 Inter-PSP Business Days); EPC222-07 2025 v1.1 sections 4.2, 4.6.4 PT-04.09 and 5.8 items 1 and 5 (debtor prohibition and verification instructions); EPC173-14 v8.0 section 2.", "confidence": "high" }, "currency": { "effective_since": "2025-10-05", "effective_note": "EPC222-07 2025 v1.1 was issued and took effect on 2025-10-05; v1.1 changed only the date for the unstructured address phase-out. EPC173-14 v8.0, published 2024-11-28, applies to both SDD rulebooks and is taken to be the current guidance [Unverified]. The next SDD B2B rulebook is due for publication in November 2026 [Unverified].", "source_edition": "EPC173-14 v8.0; EPC222-07 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-10/EPC222-07%202025%20SDD%20B2B%20Rulebook%20version%201.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC173-14 v8.0 Guidance on Reason Codes for SDD R-transactions and EPC222-07 2025 v1.1 SDD Business-to-Business Scheme Rulebook", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17c", "notes": "Confirms SL01 as a reject and return reason for Debtor PSP-offered services, described in the guidance as Debtor-invoked consumer-right rejects such as creditor blocking and amount or frequency limits, per EPC173-14 v8.0 section 3. Confirms the reject and return reasons list and the D+3 return window, EPC222-07 2025 v1.1 section 4.8.39 AT-R004 and PT-04.10, and the Debtor PSP's duty to let debtors prohibit all B2B collections, section 5.8 item 5. Does not confirm which of the CSM or the Debtor PSP actually sends the reject, or that a verification-instruction stop is coded as SL01; the record labels both as inferences." } ] }, "rail_name": "SEPA Direct Debit B2B", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sdd-core:AC01", "id": "AC01", "rail": "sepa-sdd-core", "kind": "reason-code", "name": "Account identifier incorrect (invalid IBAN)", "group": "account", "summary": "The debtor's IBAN on the collection is wrong. As a reject it can mean the IBAN fails format checks or does not exist at the debtor PSP; as a return it means the IBAN does not exist there.", "triggers": [ "The debtor gave a wrong IBAN when signing the mandate", "The creditor's customer records hold a mistyped or stale IBAN", "A processing fault on the creditor side corrupted the IBAN while building the collection", "The IBAN fails its format or check digit validation (reject only)" ], "actions": [ "Contact the debtor and get the correct IBAN before collecting again", "If the collection followed a mandate amendment, check the new account details the debtor gave", "Validate IBAN format and check digits when the mandate is captured, so format errors never reach the scheme [Inference]" ], "retry": { "allowed": false, "rule": "Do not present again to the same IBAN. Once the debtor gives a correct IBAN, record the change as a mandate amendment and collect with the corrected data. A rejected collection that is corrected and presented again must keep its original sequence type: one-off stays one-off, recurrent stays recurrent (PT-04.04, PT-04.06, PT-04.08)." }, "facts": { "return_windows": [ { "action": "reject", "by": "Debtor PSP or CSM", "deadline": "Before inter-PSP settlement on the Due Date (D). A CSM rejects on receipt or on the later days its own rules allow" }, { "action": "return", "by": "Debtor PSP", "deadline": "Settled no later than 5 Inter-PSP Business Days (TARGET days) after the Settlement Date of the collection (D+5)" } ], "applies_to": "SDD Core" }, "caveat": "Only the debtor PSP can know whether an IBAN exists on its books, so an AC01 reject from a CSM is in practice a format failure [Inference].", "related": [ "sepa-sdd-core:AC04", "sepa-sdd-core:RC01" ], "basis": { "sources": "EPC173-14 v8.0 section 3, entry for AC01 (R-transaction types, use cases, root causes, suggested creditor action); EPC016-06 2025 v1.1 sections 4.4, 4.6.4 PT-04.06 and PT-04.08, 4.8.37 AT-R002 and 4.8.39 AT-R004 (reject: who may reject, before settlement); EPC016-06 2025 v1.1 sections 4.2, 4.3.4, 4.6.4 PT-04.10 and 4.8.39 AT-R004 (return: Debtor PSP, settled by D+5 Inter-PSP Business Days); EPC016-06 2025 v1.1 section 4.6.4 PT-04.04, PT-04.06, PT-04.08 (re-presented rejects keep their sequence type).", "confidence": "high" }, "currency": { "effective_since": "2025-10-05", "effective_note": "EPC016-06 2025 v1.1 was issued and took effect on 2025-10-05; v1.1 changed only the date for the unstructured address phase-out. EPC173-14 v8.0, published 2024-11-28, applies to both SDD rulebooks and is taken to be the current guidance [Unverified]. The next SDD Core rulebook is due for publication in November 2026 [Unverified].", "source_edition": "EPC173-14 v8.0; EPC016-06 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2024-11/EPC173-14%20v8.0%20Guidance%20on%20Reason%20Codes%20for%20SDD%20R-transactions.pdf", "source_class": "authoritative_primary", "source_title": "EPC173-14 v8.0 Guidance on Reason Codes for SDD R-transactions; EPC016-06 2025 SDD Core Rulebook version 1.1", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms the code name and meaning and the R-transaction types reject and return for SDD Core per EPC173-14 v8.0 section 3. Confirms each return_windows entry against EPC016-06 2025 v1.1: reject by debtor PSP or CSM before inter-PSP settlement on the due date (sections 4.6.4 PT-04.06, PT-04.08); return by debtor PSP, settled by 5 inter-PSP business days after settlement, D+5 (sections 4.2, 4.3.4, 4.6.4 PT-04.10). Does not address which party can confirm an IBAN's existence at the debtor PSP; that stays the record's own inference." } ] }, "rail_name": "SEPA Direct Debit Core", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sdd-core:AC04", "id": "AC04", "rail": "sepa-sdd-core", "kind": "reason-code", "name": "Account closed", "group": "account", "summary": "The debtor's account at the debtor PSP is closed.", "triggers": [ "The debtor closed the account after the creditor's previous collection", "The debtor moved to another PSP and did not give the creditor the new account" ], "actions": [ "Contact the debtor for the new account and record it as a mandate amendment", "Stop further collections to the closed account", "Where debtor PSPs send MS03, remember it may stand for a closed account [Inference]" ], "retry": { "allowed": false, "rule": "Do not present again to the closed account. Collect again only after the debtor gives a new account, carried as a mandate amendment in the next collection (EPC016-06 2025 v1.1 section 4.6.2, PR-02)." }, "facts": { "return_windows": [ { "action": "reject", "by": "Debtor PSP or CSM", "deadline": "Before inter-PSP settlement on the Due Date (D). A CSM rejects on receipt or on the later days its own rules allow" }, { "action": "return", "by": "Debtor PSP", "deadline": "Settled no later than 5 Inter-PSP Business Days (TARGET days) after the Settlement Date of the collection (D+5)" } ], "applies_to": "SDD Core" }, "caveat": "Data protection law in certain SEPA countries bars this code, and debtor PSPs there send MS03 instead (EPC173-14 v8.0 section 3). The guidance does not name the countries.", "related": [ "sepa-sdd-core:MS03", "sepa-sdd-core:AC01", "sepa-sdd-core:AC06" ], "basis": { "sources": "EPC173-14 v8.0 section 3, entry for AC04 (R-transaction types, use cases, root causes, suggested creditor action); EPC016-06 2025 v1.1 sections 4.4, 4.6.4 PT-04.06 and PT-04.08, 4.8.37 AT-R002 and 4.8.39 AT-R004 (reject: who may reject, before settlement); EPC016-06 2025 v1.1 sections 4.2, 4.3.4, 4.6.4 PT-04.10 and 4.8.39 AT-R004 (return: Debtor PSP, settled by D+5 Inter-PSP Business Days); EPC016-06 2025 v1.1 section 4.6.2 PR-02 (mandate amendment).", "confidence": "high" }, "currency": { "effective_since": "2025-10-05", "effective_note": "EPC016-06 2025 v1.1 was issued and took effect on 2025-10-05; v1.1 changed only the date for the unstructured address phase-out. EPC173-14 v8.0, published 2024-11-28, applies to both SDD rulebooks and is taken to be the current guidance [Unverified]. The next SDD Core rulebook is due for publication in November 2026 [Unverified].", "source_edition": "EPC173-14 v8.0; EPC016-06 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2024-11/EPC173-14%20v8.0%20Guidance%20on%20Reason%20Codes%20for%20SDD%20R-transactions.pdf", "source_class": "authoritative_primary", "source_title": "EPC173-14 v8.0 Guidance on Reason Codes for SDD R-transactions; EPC016-06 2025 SDD Core Rulebook version 1.1", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms the code name and meaning and the R-transaction types reject and return for SDD Core per EPC173-14 v8.0 section 3. Confirms each return_windows entry against EPC016-06 2025 v1.1: reject before settlement, return by D+5, both as above. Does not name which SEPA countries restrict this code under data protection law; the guidance does not name them either." } ] }, "rail_name": "SEPA Direct Debit Core", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sdd-core:AC06", "id": "AC06", "rail": "sepa-sdd-core", "kind": "reason-code", "name": "Account blocked", "group": "account", "summary": "The debtor's account is blocked for all financial transactions, or the debtor PSP has blocked this collection.", "triggers": [ "A court order blocks the account or the collection", "The debtor PSP blocked the account, for example on suspected misuse", "The debtor asked the debtor PSP to block the account" ], "actions": [ "Contact the debtor to agree another account or another way to pay", "Do not keep presenting to a blocked account; the block is outside the creditor's control" ], "retry": { "allowed": false, "rule": "Wait until the debtor confirms the block is lifted or gives another account. The texts read set no scheme retry rule for this code [Unverified]." }, "facts": { "return_windows": [ { "action": "reject", "by": "Debtor PSP or CSM", "deadline": "Before inter-PSP settlement on the Due Date (D). A CSM rejects on receipt or on the later days its own rules allow" }, { "action": "return", "by": "Debtor PSP", "deadline": "Settled no later than 5 Inter-PSP Business Days (TARGET days) after the Settlement Date of the collection (D+5)" } ], "applies_to": "SDD Core" }, "caveat": "The rulebook's reject and return reasons (EPC016-06 2025 v1.1 section 4.8.39, AT-R004) also list an account blocked for direct debit by the debtor, separate from a general block. EPC173-14 v8.0 section 3 does not name a separate ISO code for that reason [Unverified which code debtor PSPs use for it; AC06 or SL01 are the likely candidates, Inference].", "related": [ "sepa-sdd-core:SL01", "sepa-sdd-core:AC04" ], "basis": { "sources": "EPC173-14 v8.0 section 3, entry for AC06 (R-transaction types, use cases, root causes, suggested creditor action); EPC016-06 2025 v1.1 sections 4.4, 4.6.4 PT-04.06 and PT-04.08, 4.8.37 AT-R002 and 4.8.39 AT-R004 (reject: who may reject, before settlement); EPC016-06 2025 v1.1 sections 4.2, 4.3.4, 4.6.4 PT-04.10 and 4.8.39 AT-R004 (return: Debtor PSP, settled by D+5 Inter-PSP Business Days).", "confidence": "high" }, "currency": { "effective_since": "2025-10-05", "effective_note": "EPC016-06 2025 v1.1 was issued and took effect on 2025-10-05; v1.1 changed only the date for the unstructured address phase-out. EPC173-14 v8.0, published 2024-11-28, applies to both SDD rulebooks and is taken to be the current guidance [Unverified]. The next SDD Core rulebook is due for publication in November 2026 [Unverified].", "source_edition": "EPC173-14 v8.0; EPC016-06 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2024-11/EPC173-14%20v8.0%20Guidance%20on%20Reason%20Codes%20for%20SDD%20R-transactions.pdf", "source_class": "authoritative_primary", "source_title": "EPC173-14 v8.0 Guidance on Reason Codes for SDD R-transactions; EPC016-06 2025 SDD Core Rulebook version 1.1", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms the code name and meaning and the R-transaction types reject and return for SDD Core per EPC173-14 v8.0 section 3. Confirms each return_windows entry against EPC016-06 2025 v1.1: reject before settlement, return by D+5, both as above. Does not resolve whether AC06 or SL01 is the code debtor PSPs use for an account blocked specifically for direct debit; EPC173-14 names no separate code for that case, so the record's own inference stands unconfirmed either way." } ] }, "rail_name": "SEPA Direct Debit Core", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sdd-core:AG01", "id": "AG01", "rail": "sepa-sdd-core", "kind": "reason-code", "name": "Direct debit forbidden on this account for regulatory reasons", "group": "account", "summary": "Regulation does not allow direct debits from this type of account, for example a savings account.", "triggers": [ "The debtor gave a savings account or another account type that cannot be debited by direct debit" ], "actions": [ "Contact the debtor to agree a payment account that accepts direct debits, or another payment method", "Record the new account as a mandate amendment before collecting again" ], "retry": { "allowed": false, "rule": "Do not present again to this account. The account type, not the collection, is the problem." }, "facts": { "return_windows": [ { "action": "reject", "by": "Debtor PSP or CSM", "deadline": "Before inter-PSP settlement on the Due Date (D). A CSM rejects on receipt or on the later days its own rules allow" }, { "action": "return", "by": "Debtor PSP", "deadline": "Settled no later than 5 Inter-PSP Business Days (TARGET days) after the Settlement Date of the collection (D+5)" } ], "applies_to": "SDD Core" }, "caveat": "In SDD B2B the guidance keeps a separate code, AC13, for a consumer account and bars AG01 for that case. AC13 has no use in SDD Core, so it is not drafted in this directory.", "related": [ "sepa-sdd-core:AC06" ], "basis": { "sources": "EPC173-14 v8.0 section 3, entry for AG01 (R-transaction types, use cases, root causes, suggested creditor action); EPC016-06 2025 v1.1 sections 4.4, 4.6.4 PT-04.06 and PT-04.08, 4.8.37 AT-R002 and 4.8.39 AT-R004 (reject: who may reject, before settlement); EPC016-06 2025 v1.1 sections 4.2, 4.3.4, 4.6.4 PT-04.10 and 4.8.39 AT-R004 (return: Debtor PSP, settled by D+5 Inter-PSP Business Days).", "confidence": "high" }, "currency": { "effective_since": "2025-10-05", "effective_note": "EPC016-06 2025 v1.1 was issued and took effect on 2025-10-05; v1.1 changed only the date for the unstructured address phase-out. EPC173-14 v8.0, published 2024-11-28, applies to both SDD rulebooks and is taken to be the current guidance [Unverified]. The next SDD Core rulebook is due for publication in November 2026 [Unverified].", "source_edition": "EPC173-14 v8.0; EPC016-06 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2024-11/EPC173-14%20v8.0%20Guidance%20on%20Reason%20Codes%20for%20SDD%20R-transactions.pdf", "source_class": "authoritative_primary", "source_title": "EPC173-14 v8.0 Guidance on Reason Codes for SDD R-transactions; EPC016-06 2025 SDD Core Rulebook version 1.1", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms the code name and meaning and the R-transaction types reject and return for SDD Core per EPC173-14 v8.0 section 3. Confirms each return_windows entry against EPC016-06 2025 v1.1: reject before settlement, return by D+5, both as above. Confirms AC13 is the B2B-only code for a consumer account presented to SDD B2B, so AG01 is correctly scoped to non-B2B account-type problems. No further open questions." } ] }, "rail_name": "SEPA Direct Debit Core", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sdd-core:AG02", "id": "AG02", "rail": "sepa-sdd-core", "kind": "reason-code", "name": "Operation code, transaction code or sequence type incorrect; invalid file format", "group": "technical", "summary": "The collection carries the wrong sequence type (one-off or recurrent) or the wrong scheme identification.", "triggers": [ "A recurrent collection was sent under a mandate already used for a one-off", "A one-off collection was sent under a mandate already used for recurrent collections", "The service level or local instrument code in the message does not identify the scheme correctly", "A technical or process error on the creditor side when building the collection or file" ], "actions": [ "Correct the sequence type or scheme identification and send a new collection", "Check how the collection system records whether each mandate is one-off or recurrent [Inference]" ], "retry": { "allowed": true, "rule": "A corrected collection may be sent again. A rejected collection that is corrected and presented again must keep its original sequence type: one-off stays one-off, recurrent stays recurrent (PT-04.04, PT-04.06, PT-04.08). How that rule applies when the sequence type was itself the error is not stated in the texts read; confirm with the creditor PSP before resending [Unverified]." }, "facts": { "return_windows": [ { "action": "reject", "by": "Debtor PSP or CSM", "deadline": "Before inter-PSP settlement on the Due Date (D). A CSM rejects on receipt or on the later days its own rules allow" }, { "action": "return", "by": "Debtor PSP", "deadline": "Settled no later than 5 Inter-PSP Business Days (TARGET days) after the Settlement Date of the collection (D+5)" } ], "applies_to": "SDD Core" }, "caveat": "Each debtor PSP decides whether to check the sequence type at all (EPC173-14 v8.0 section 2), so the same error can pass at one debtor PSP and fail at another.", "related": [ "sepa-sdd-core:FF01" ], "basis": { "sources": "EPC173-14 v8.0 section 3, entry for AG02 (R-transaction types, use cases, root causes, suggested creditor action); EPC016-06 2025 v1.1 sections 4.4, 4.6.4 PT-04.06 and PT-04.08, 4.8.37 AT-R002 and 4.8.39 AT-R004 (reject: who may reject, before settlement); EPC016-06 2025 v1.1 sections 4.2, 4.3.4, 4.6.4 PT-04.10 and 4.8.39 AT-R004 (return: Debtor PSP, settled by D+5 Inter-PSP Business Days); EPC016-06 2025 v1.1 section 4.6.4 PT-04.04, PT-04.06, PT-04.08 (re-presented rejects keep their sequence type). EPC173-14 v8.0 section 2 (debtor PSP discretion on sequence type checks).", "confidence": "high" }, "currency": { "effective_since": "2025-10-05", "effective_note": "EPC016-06 2025 v1.1 was issued and took effect on 2025-10-05; v1.1 changed only the date for the unstructured address phase-out. EPC173-14 v8.0, published 2024-11-28, applies to both SDD rulebooks and is taken to be the current guidance [Unverified]. The next SDD Core rulebook is due for publication in November 2026 [Unverified].", "source_edition": "EPC173-14 v8.0; EPC016-06 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2024-11/EPC173-14%20v8.0%20Guidance%20on%20Reason%20Codes%20for%20SDD%20R-transactions.pdf", "source_class": "authoritative_primary", "source_title": "EPC173-14 v8.0 Guidance on Reason Codes for SDD R-transactions; EPC016-06 2025 SDD Core Rulebook version 1.1", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms the code name and meaning and the R-transaction types reject and return for SDD Core per EPC173-14 v8.0 section 3. Confirms each return_windows entry against EPC016-06 2025 v1.1: reject before settlement, return by D+5, both as above. Does not address how the re-presentment sequence-type rule applies when the sequence type itself was the error; the record's retry rule already marks this unverified." } ] }, "rail_name": "SEPA Direct Debit Core", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sdd-core:AM04", "id": "AM04", "rail": "sepa-sdd-core", "kind": "reason-code", "name": "Insufficient funds", "group": "funds", "summary": "The debtor's account does not hold enough to pay the full collection.", "triggers": [ "The debtor lacks funds on the debit date", "The creditor sent no pre-notification, or sent it late, so the debtor did not know the amount and date" ], "actions": [ "Contact the debtor so funds are in place before the next collection", "Check that the pre-notification went out on time with amount and due date; the scheme default is at least 14 Calendar Days before the Due Date unless creditor and debtor agreed otherwise (EPC016-06 2025 v1.1 section 4.3.4, PT-04.02)", "Where debtor PSPs send MS03, remember it may stand for insufficient funds [Inference]" ], "retry": { "allowed": true, "rule": "The texts read set no limit on presenting a new collection after an insufficient funds reject or return [Unverified]. A new collection needs its own Due Date, must reach the debtor PSP at least 1 Inter-PSP Business Day before it, and needs pre-notification (section 4.3.4). A rejected collection that is corrected and presented again must keep its original sequence type: one-off stays one-off, recurrent stays recurrent (PT-04.04, PT-04.06, PT-04.08)." }, "facts": { "return_windows": [ { "action": "reject", "by": "Debtor PSP or CSM", "deadline": "Before inter-PSP settlement on the Due Date (D). A CSM rejects on receipt or on the later days its own rules allow" }, { "action": "return", "by": "Debtor PSP", "deadline": "Settled no later than 5 Inter-PSP Business Days (TARGET days) after the Settlement Date of the collection (D+5)" } ], "applies_to": "SDD Core" }, "caveat": "Data protection law in certain SEPA countries bars this code, and debtor PSPs there send MS03 instead (EPC173-14 v8.0 section 3). The guidance does not name the countries. The debtor PSP may also debit after the Due Date while waiting for funds, but must still return in time to settle by D+5 (EPC016-06 2025 v1.1 section 4.3.2).", "related": [ "sepa-sdd-core:MS03" ], "basis": { "sources": "EPC173-14 v8.0 section 3, entry for AM04 (R-transaction types, use cases, root causes, suggested creditor action); EPC016-06 2025 v1.1 sections 4.4, 4.6.4 PT-04.06 and PT-04.08, 4.8.37 AT-R002 and 4.8.39 AT-R004 (reject: who may reject, before settlement); EPC016-06 2025 v1.1 sections 4.2, 4.3.4, 4.6.4 PT-04.10 and 4.8.39 AT-R004 (return: Debtor PSP, settled by D+5 Inter-PSP Business Days); EPC016-06 2025 v1.1 section 4.6.4 PT-04.04, PT-04.06, PT-04.08 (re-presented rejects keep their sequence type); EPC016-06 2025 v1.1 sections 4.3.2 and 4.3.4, PT-04.02 (late debit, pre-notification, D-1 receipt).", "confidence": "high" }, "currency": { "effective_since": "2025-10-05", "effective_note": "EPC016-06 2025 v1.1 was issued and took effect on 2025-10-05; v1.1 changed only the date for the unstructured address phase-out. EPC173-14 v8.0, published 2024-11-28, applies to both SDD rulebooks and is taken to be the current guidance [Unverified]. The next SDD Core rulebook is due for publication in November 2026 [Unverified].", "source_edition": "EPC173-14 v8.0; EPC016-06 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2024-11/EPC173-14%20v8.0%20Guidance%20on%20Reason%20Codes%20for%20SDD%20R-transactions.pdf", "source_class": "authoritative_primary", "source_title": "EPC173-14 v8.0 Guidance on Reason Codes for SDD R-transactions; EPC016-06 2025 SDD Core Rulebook version 1.1", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms the code name and meaning and the R-transaction types reject and return for SDD Core per EPC173-14 v8.0 section 3. Confirms each return_windows entry against EPC016-06 2025 v1.1: reject before settlement, return by D+5, both as above; confirms the 14 calendar day pre-notification default in section 4.3.4. Does not address any scheme limit on re-presenting a collection after an insufficient-funds reject or return; the retry rule already marks this unverified." } ] }, "rail_name": "SEPA Direct Debit Core", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sdd-core:AM05", "id": "AM05", "rail": "sepa-sdd-core", "kind": "reason-code", "name": "Duplicate collection", "group": "administrative", "summary": "The CSM or the debtor PSP believes an identical collection was sent or processed very recently. As a reversal, the creditor side uses it to pay back a collection it sent twice.", "triggers": [ "A technical fault at the creditor or creditor PSP resubmitted a file or collection", "A human error on the creditor side entered the same collection twice" ], "actions": [ "Check whether the collection really was duplicated before doing anything else", "If a duplicate settled and was not rejected or returned, pay it back with a reversal inside the reversal window", "If it was not a duplicate, raise it with the creditor PSP; a new collection with distinct references may be needed [Inference]" ], "retry": { "allowed": false, "rule": "Do not resend the same collection. If it was wrongly flagged as a duplicate, agree the next step with the creditor PSP first [Inference]." }, "facts": { "return_windows": [ { "action": "reject", "by": "CSM or Debtor PSP", "deadline": "Before inter-PSP settlement on the Due Date (D). A CSM rejects on receipt or on the later days its own rules allow" }, { "action": "return", "by": "Debtor PSP", "deadline": "Settled no later than 5 Inter-PSP Business Days (TARGET days) after the Settlement Date of the collection (D+5)" }, { "action": "reversal", "by": "Creditor or Creditor PSP", "deadline": "From the Settlement Date (D) to D+5 Inter-PSP Business Days, counted end to end from the creditor's instruction to CSM forwarding" } ], "applies_to": "SDD Core" }, "caveat": "The duplicate test is the CSM's or debtor PSP's own judgment; the texts read give no scheme definition of identical or of how recent [Unverified]. A reversal must be for the full amount; partial reversals are not allowed (EPC016-06 2025 v1.1 section 4.8.57, AT-R042).", "related": [ "sepa-sdd-core:MS03" ], "basis": { "sources": "EPC173-14 v8.0 section 3, entry for AM05 (R-transaction types, use cases, root causes, suggested creditor action); EPC016-06 2025 v1.1 sections 4.4, 4.6.4 PT-04.06 and PT-04.08, 4.8.37 AT-R002 and 4.8.39 AT-R004 (reject: who may reject, before settlement); EPC016-06 2025 v1.1 sections 4.2, 4.3.4, 4.6.4 PT-04.10 and 4.8.39 AT-R004 (return: Debtor PSP, settled by D+5 Inter-PSP Business Days); EPC016-06 2025 v1.1 sections 4.3.4, 4.4, 4.6.5 PT-05.01 to PT-05.03 and 4.8.56 AT-R041 (reversal: Creditor or Creditor PSP, D to D+5 Inter-PSP Business Days); EPC016-06 2025 v1.1 section 4.8.57 AT-R042 (no partial reversal).", "confidence": "high" }, "currency": { "effective_since": "2025-10-05", "effective_note": "EPC016-06 2025 v1.1 was issued and took effect on 2025-10-05; v1.1 changed only the date for the unstructured address phase-out. EPC173-14 v8.0, published 2024-11-28, applies to both SDD rulebooks and is taken to be the current guidance [Unverified]. The next SDD Core rulebook is due for publication in November 2026 [Unverified].", "source_edition": "EPC173-14 v8.0; EPC016-06 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2024-11/EPC173-14%20v8.0%20Guidance%20on%20Reason%20Codes%20for%20SDD%20R-transactions.pdf", "source_class": "authoritative_primary", "source_title": "EPC173-14 v8.0 Guidance on Reason Codes for SDD R-transactions; EPC016-06 2025 SDD Core Rulebook version 1.1", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms the code name and meaning and the R-transaction types reject, return and reversal for SDD Core per EPC173-14 v8.0 section 3. Confirms each return_windows entry against EPC016-06 2025 v1.1: reject before settlement; return by D+5; reversal by creditor or creditor PSP, from settlement date D to D+5 inter-PSP business days counted end to end from PT-05.01 to PT-05.03 (sections 4.3.4, 4.4, 4.6.5 PT-05.01-03); confirms no partial reversals, AT-R042. Does not give a scheme definition of 'identical' or 'how recent' for the duplicate test; the record already marks this unverified." } ] }, "rail_name": "SEPA Direct Debit Core", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "judgement", "label": "your bank's own terms", "needs": "whose terms decide it: the bank's, the participant's or the scheme's", "detail": "The duplicate test is the CSM's or debtor PSP's own judgment; the texts read give no scheme definition of identical or of how recent [Unverified].", "from": "caveat" } ] }, { "uid": "sepa-sdd-core:BE05", "id": "BE05", "rail": "sepa-sdd-core", "kind": "reason-code", "name": "Identifier of the Creditor incorrect", "group": "administrative", "summary": "The creditor identifier (CI) on the collection is wrong, or it changed without a mandate amendment being reported.", "triggers": [ "A technical error put the wrong CI on the collection", "The creditor's CI changed, for example after a merger or acquisition, and the collection did not carry the amendment" ], "actions": [ "Correct the CI", "When the CI changes, send the amendment with the next collection under each affected mandate, and tell debtors about the change (EPC016-06 2025 v1.1 section 4.6.2, PR-02)" ], "retry": { "allowed": true, "rule": "Correct the CI or report the amendment, then collect again. A rejected collection that is corrected and presented again must keep its original sequence type: one-off stays one-off, recurrent stays recurrent (PT-04.04, PT-04.06, PT-04.08)." }, "facts": { "return_windows": [ { "action": "reject", "by": "Debtor PSP or CSM", "deadline": "Before inter-PSP settlement on the Due Date (D). A CSM rejects on receipt or on the later days its own rules allow" }, { "action": "return", "by": "Debtor PSP", "deadline": "Settled no later than 5 Inter-PSP Business Days (TARGET days) after the Settlement Date of the collection (D+5)" } ], "applies_to": "SDD Core" }, "caveat": "Each debtor PSP decides whether to check the CI (EPC173-14 v8.0 section 2), so this code comes from some debtor PSPs and not others. The CI has no ACH counterpart and is not a company ID.", "related": [ "sepa-sdd-core:MD02" ], "basis": { "sources": "EPC173-14 v8.0 section 3, entry for BE05 (R-transaction types, use cases, root causes, suggested creditor action); EPC016-06 2025 v1.1 sections 4.4, 4.6.4 PT-04.06 and PT-04.08, 4.8.37 AT-R002 and 4.8.39 AT-R004 (reject: who may reject, before settlement); EPC016-06 2025 v1.1 sections 4.2, 4.3.4, 4.6.4 PT-04.10 and 4.8.39 AT-R004 (return: Debtor PSP, settled by D+5 Inter-PSP Business Days); EPC016-06 2025 v1.1 section 4.6.4 PT-04.04, PT-04.06, PT-04.08 (re-presented rejects keep their sequence type); EPC016-06 2025 v1.1 section 4.6.2 PR-02. EPC173-14 v8.0 section 2 (debtor PSP discretion on CI checks).", "confidence": "high" }, "currency": { "effective_since": "2025-10-05", "effective_note": "EPC016-06 2025 v1.1 was issued and took effect on 2025-10-05; v1.1 changed only the date for the unstructured address phase-out. EPC173-14 v8.0, published 2024-11-28, applies to both SDD rulebooks and is taken to be the current guidance [Unverified]. The next SDD Core rulebook is due for publication in November 2026 [Unverified].", "source_edition": "EPC173-14 v8.0; EPC016-06 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2024-11/EPC173-14%20v8.0%20Guidance%20on%20Reason%20Codes%20for%20SDD%20R-transactions.pdf", "source_class": "authoritative_primary", "source_title": "EPC173-14 v8.0 Guidance on Reason Codes for SDD R-transactions; EPC016-06 2025 SDD Core Rulebook version 1.1", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms the code name and meaning and the R-transaction types reject and return for SDD Core per EPC173-14 v8.0 section 3. Confirms each return_windows entry against EPC016-06 2025 v1.1: reject before settlement, return by D+5, both as above; confirms the mandate-amendment reporting process at section 4.6.2 PR-02. No further open questions." } ] }, "rail_name": "SEPA Direct Debit Core", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sdd-core:CNOR", "id": "CNOR", "rail": "sepa-sdd-core", "kind": "reason-code", "name": "Creditor PSP not registered under this BIC in the CSM", "group": "network", "summary": "The CSM does not hold the creditor PSP as an SDD scheme participant under the BIC used.", "triggers": [ "The creditor PSP is not, or is no longer, a direct or indirect participant of this CSM" ], "actions": [ "Contact the creditor PSP; the fix lies between it and the CSM" ], "retry": { "allowed": false, "rule": "Do not resend through the same route until the creditor PSP confirms its registration with the CSM [Inference]." }, "facts": { "return_windows": [ { "action": "reject", "by": "CSM", "deadline": "Before inter-PSP settlement, on receipt or on the later days the CSM's own rules allow" } ], "applies_to": "SDD Core" }, "caveat": "The guidance names the CSM as the place the registration is missing but does not say in words who sends the reject; this record assumes the CSM does [Inference].", "related": [ "sepa-sdd-core:DNOR", "sepa-sdd-core:RC01" ], "basis": { "sources": "EPC173-14 v8.0 section 3, entry for CNOR (R-transaction types, use cases, root causes, suggested creditor action); EPC016-06 2025 v1.1 sections 4.4, 4.6.4 PT-04.06 and PT-04.08, 4.8.37 AT-R002 and 4.8.39 AT-R004 (reject: who may reject, before settlement).", "confidence": "medium" }, "currency": { "effective_since": "2025-10-05", "effective_note": "EPC016-06 2025 v1.1 was issued and took effect on 2025-10-05; v1.1 changed only the date for the unstructured address phase-out. EPC173-14 v8.0, published 2024-11-28, applies to both SDD rulebooks and is taken to be the current guidance [Unverified]. The next SDD Core rulebook is due for publication in November 2026 [Unverified].", "source_edition": "EPC173-14 v8.0; EPC016-06 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2024-11/EPC173-14%20v8.0%20Guidance%20on%20Reason%20Codes%20for%20SDD%20R-transactions.pdf", "source_class": "authoritative_primary", "source_title": "EPC173-14 v8.0 Guidance on Reason Codes for SDD R-transactions; EPC016-06 2025 SDD Core Rulebook version 1.1", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms the code name and meaning and the R-transaction types reject only for SDD Core per EPC173-14 v8.0 section 3. Confirms each return_windows entry against EPC016-06 2025 v1.1: reject before inter-PSP settlement, on receipt or on the later days the CSM's own rules allow. Does not state in words whether the CSM or the debtor PSP sends the reject for this code; the record's 'CSM' attribution is its own inference, unconfirmed by either text." } ] }, "rail_name": "SEPA Direct Debit Core", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sdd-core:DNOR", "id": "DNOR", "rail": "sepa-sdd-core", "kind": "reason-code", "name": "Debtor PSP not registered under this BIC in the CSM", "group": "network", "summary": "The debtor PSP is not, or is no longer, registered with the CSM as an SDD scheme participant under the BIC used, so the CSM cannot deliver the collection.", "triggers": [ "The creditor or creditor PSP did not check that the debtor PSP is reachable before sending" ], "actions": [ "Ask the creditor PSP to check whether the debtor PSP is reachable", "Contact the debtor to agree another way to pay" ], "retry": { "allowed": false, "rule": "Do not resend through the same route until the creditor PSP confirms the debtor PSP is reachable [Inference]." }, "facts": { "return_windows": [ { "action": "reject", "by": "CSM", "deadline": "Before inter-PSP settlement, on receipt or on the later days the CSM's own rules allow" } ], "applies_to": "SDD Core" }, "caveat": "Scheme participants commit to be reachable (EPC016-06 2025 v1.1 section 2.6), but whether a given CSM can reach a given debtor PSP depends on CSM arrangements [Inference]. The guidance does not say in words who sends the reject; this record assumes the CSM does [Inference].", "related": [ "sepa-sdd-core:CNOR", "sepa-sdd-core:RC01" ], "basis": { "sources": "EPC173-14 v8.0 section 3, entry for DNOR (R-transaction types, use cases, root causes, suggested creditor action); EPC016-06 2025 v1.1 sections 4.4, 4.6.4 PT-04.06 and PT-04.08, 4.8.37 AT-R002 and 4.8.39 AT-R004 (reject: who may reject, before settlement); EPC016-06 2025 v1.1 section 2.6 (reachability).", "confidence": "medium" }, "currency": { "effective_since": "2025-10-05", "effective_note": "EPC016-06 2025 v1.1 was issued and took effect on 2025-10-05; v1.1 changed only the date for the unstructured address phase-out. EPC173-14 v8.0, published 2024-11-28, applies to both SDD rulebooks and is taken to be the current guidance [Unverified]. The next SDD Core rulebook is due for publication in November 2026 [Unverified].", "source_edition": "EPC173-14 v8.0; EPC016-06 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2024-11/EPC173-14%20v8.0%20Guidance%20on%20Reason%20Codes%20for%20SDD%20R-transactions.pdf", "source_class": "authoritative_primary", "source_title": "EPC173-14 v8.0 Guidance on Reason Codes for SDD R-transactions; EPC016-06 2025 SDD Core Rulebook version 1.1", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms the code name and meaning and the R-transaction types reject only for SDD Core per EPC173-14 v8.0 section 3. Confirms each return_windows entry against EPC016-06 2025 v1.1: reject before inter-PSP settlement, on receipt or on the later days the CSM's own rules allow; confirms the reachability commitment at section 2.6. Does not state in words which party sends the reject; the record's 'CSM' attribution is its own inference, unconfirmed." } ] }, "rail_name": "SEPA Direct Debit Core", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sdd-core:ED05", "id": "ED05", "rail": "sepa-sdd-core", "kind": "reason-code", "name": "Settlement of the collection failed", "group": "network", "summary": "The collection could not settle because the debtor PSP's inter-PSP funding for SDD was not enough.", "triggers": [ "The debtor PSP's inter-PSP SDD funding facilities were insufficient to settle this collection" ], "actions": [ "Ask the creditor PSP what happens next; the outcome depends on the service agreement between the debtor PSP and the CSM", "Do not read this as a problem with the debtor's own account [Inference]" ], "retry": { "allowed": true, "rule": "The texts read set no scheme rule. Any new attempt is a new collection with its own Due Date and the usual D-1 receipt rule [Inference]." }, "facts": { "return_windows": [ { "action": "reject", "by": "Debtor PSP or CSM", "deadline": "At the attempted inter-PSP settlement on the Due Date (D); the collection is rejected instead of settled" } ], "applies_to": "SDD Core" }, "caveat": "This is a failure between the debtor PSP and the CSM, not a statement about the debtor. The rulebook lists it among reject reasons (section 4.8.39, AT-R004); exactly when in the settlement cycle a CSM reports it is CSM-specific [Inference].", "related": [ "sepa-sdd-core:DNOR" ], "basis": { "sources": "EPC173-14 v8.0 section 3, entry for ED05 (R-transaction types, use cases, root causes, suggested creditor action); EPC016-06 2025 v1.1 sections 4.4, 4.6.4 PT-04.06 and PT-04.08, 4.8.37 AT-R002 and 4.8.39 AT-R004 (reject: who may reject, before settlement).", "confidence": "medium" }, "currency": { "effective_since": "2025-10-05", "effective_note": "EPC016-06 2025 v1.1 was issued and took effect on 2025-10-05; v1.1 changed only the date for the unstructured address phase-out. EPC173-14 v8.0, published 2024-11-28, applies to both SDD rulebooks and is taken to be the current guidance [Unverified]. The next SDD Core rulebook is due for publication in November 2026 [Unverified].", "source_edition": "EPC173-14 v8.0; EPC016-06 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2024-11/EPC173-14%20v8.0%20Guidance%20on%20Reason%20Codes%20for%20SDD%20R-transactions.pdf", "source_class": "authoritative_primary", "source_title": "EPC173-14 v8.0 Guidance on Reason Codes for SDD R-transactions; EPC016-06 2025 SDD Core Rulebook version 1.1", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms the code name and meaning and the R-transaction types reject only for SDD Core per EPC173-14 v8.0 section 3. Confirms each return_windows entry against EPC016-06 2025 v1.1: reject at the attempted inter-PSP settlement on the due date, reported by the debtor PSP or the CSM. Does not say exactly when within a CSM's settlement cycle the failure is reported; the record already marks that CSM-specific and unconfirmed." } ] }, "rail_name": "SEPA Direct Debit Core", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "judgement", "label": "your bank's own terms", "needs": "whose terms decide it: the bank's, the participant's or the scheme's", "detail": "The rulebook lists it among reject reasons (section 4.8.39, AT-R004); exactly when in the settlement cycle a CSM reports it is CSM-specific [Inference].", "from": "caveat" } ] }, { "uid": "sepa-sdd-core:FF01", "id": "FF01", "rail": "sepa-sdd-core", "kind": "reason-code", "name": "Invalid file format", "group": "technical", "summary": "The XML file failed syntax or schema (XSD) validation.", "triggers": [ "The file was not filled out correctly", "The file contains an XML syntax error", "The creditor PSP, an intermediary PSP or the CSM passed the file on without checking it against the XSD" ], "actions": [ "Repair the XML file and submit the collections again in a new file", "Validate every file against the XSD before it leaves the creditor [Inference]" ], "retry": { "allowed": true, "rule": "Resubmit the corrected collections in a new file (PT-04.04). A rejected collection that is corrected and presented again must keep its original sequence type: one-off stays one-off, recurrent stays recurrent (PT-04.04, PT-04.06, PT-04.08)." }, "facts": { "return_windows": [ { "action": "reject", "by": "Creditor PSP, CSM or Debtor PSP", "deadline": "Before inter-PSP settlement. A creditor PSP rejects on receipt of the creditor's file or later as agreed with the creditor (PT-04.04); a CSM on receipt or as its rules allow (PT-04.06)" } ], "applies_to": "SDD Core" }, "caveat": "FF01 is a reject reason only. The guidance names the creditor PSP, an intermediary PSP and the CSM as the parties that should have checked the file, but does not say which of them sends the reject; this record lists the parties the rulebook allows to reject [Inference]. Reasons for a reject by the creditor PSP are otherwise set bilaterally with the creditor (section 4.8.39, AT-R004).", "related": [ "sepa-sdd-core:AG02" ], "basis": { "sources": "EPC173-14 v8.0 section 3, entry for FF01 (R-transaction types, use cases, root causes, suggested creditor action); EPC016-06 2025 v1.1 sections 4.4, 4.6.4 PT-04.06 and PT-04.08, 4.8.37 AT-R002 and 4.8.39 AT-R004 (reject: who may reject, before settlement); EPC016-06 2025 v1.1 section 4.6.4 PT-04.04, PT-04.06, PT-04.08 (re-presented rejects keep their sequence type).", "confidence": "medium" }, "currency": { "effective_since": "2025-10-05", "effective_note": "EPC016-06 2025 v1.1 was issued and took effect on 2025-10-05; v1.1 changed only the date for the unstructured address phase-out. EPC173-14 v8.0, published 2024-11-28, applies to both SDD rulebooks and is taken to be the current guidance [Unverified]. The next SDD Core rulebook is due for publication in November 2026 [Unverified].", "source_edition": "EPC173-14 v8.0; EPC016-06 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2024-11/EPC173-14%20v8.0%20Guidance%20on%20Reason%20Codes%20for%20SDD%20R-transactions.pdf", "source_class": "authoritative_primary", "source_title": "EPC173-14 v8.0 Guidance on Reason Codes for SDD R-transactions; EPC016-06 2025 SDD Core Rulebook version 1.1", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms the code name and meaning and the R-transaction types reject only for SDD Core per EPC173-14 v8.0 section 3. Confirms each return_windows entry against EPC016-06 2025 v1.1: reject before inter-PSP settlement; a creditor PSP rejects on receipt of the file or later as agreed, a CSM on receipt or as its rules allow (PT-04.04, PT-04.06). Does not state which of the creditor PSP, an intermediary PSP or the CSM actually sends the FF01 reject; the record lists the parties the rulebook allows to reject as its own inference." } ] }, "rail_name": "SEPA Direct Debit Core", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sdd-core:MD01", "id": "MD01", "rail": "sepa-sdd-core", "kind": "reason-code", "name": "No valid mandate, or unauthorised transaction", "group": "authorization", "summary": "The debtor PSP says no valid mandate supports the collection. As a refund, it is the debtor's claim that a collection was unauthorised, which can be made up to 13 months after the debit.", "triggers": [ "No mandate exists between this creditor and debtor", "The debtor cancelled the mandate", "The mandate lapsed after 36 months with no collection presented; the rulebook puts the duty to cancel on the creditor, and the guidance also lists a debtor PSP cancellation on this ground", "The creditor sent no unique mandate reference (UMR), or a UMR that does not match the mandate data", "The debtor tells the debtor PSP the collection was not authorised (refund)" ], "actions": [ "Compare the mandate data in the collection (UMR, CI, creditor name, debtor IBAN, sequence type, date of signing) with the signed mandate you hold", "Check whether the debtor cancelled or 36 months passed since the last presented collection; if so, stop and obtain a new mandate", "On an unauthorised refund claim, expect a mandate copy request through the creditor PSP. The creditor PSP has up to 3 Banking Business Days to pass it on and the creditor's answer is due within 7 Banking Business Days (PT-04.22, PT-04.23)", "Keep each signed mandate at least as long as the unauthorised refund period after it ends (PT-01.03, PT-03.02)", "After a refund, take the dispute up with the debtor; it is outside the scheme" ], "retry": { "allowed": false, "rule": "Do not collect again until you hold a valid signed mandate that matches the collection data. After 36 months with no collection presented, a new mandate is required (EPC016-06 2025 v1.1 section 4.2)." }, "facts": { "return_windows": [ { "action": "reject", "by": "Debtor PSP", "deadline": "Before inter-PSP settlement on the Due Date (D)" }, { "action": "return", "by": "Debtor PSP", "deadline": "Settled no later than 5 Inter-PSP Business Days (TARGET days) after the Settlement Date of the collection (D+5)" }, { "action": "refund claim (unauthorised transaction)", "by": "Debtor, through the Debtor PSP", "deadline": "13 months after the debit date" }, { "action": "refund (unauthorised transaction)", "by": "Debtor PSP", "deadline": "Sent within 4 Inter-PSP Business Days after the creditor's response, or after 30 Calendar Days from the claim with no response; settled no later than 30 Calendar Days + 4 Inter-PSP Business Days after the 13-month claim period ends" } ], "applies_to": "SDD Core" }, "caveat": "The debtor PSP's decision on an unauthorised refund claim is final within the scheme (PT-04.24). The 13-month period comes from payment services law; the rulebook cites Article 71 of the Payment Services Directive (section 4.3.4). A no-questions-asked refund within 8 weeks carries MD06, not MD01. The debtor PSP may add refund compensation (interest) to the amount claimed (PT-04.24, PT-04.16). The scheme does not oblige debtor PSPs to check mandates before paying (PT-04.10), so an MD01 reject or return usually reflects a debtor instruction or a debtor PSP service [Inference].", "related": [ "sepa-sdd-core:MD06", "sepa-sdd-core:MD02", "sepa-sdd-core:MS02", "sepa-sdd-core:SL01" ], "basis": { "sources": "EPC173-14 v8.0 section 3, entry for MD01 (R-transaction types, use cases, root causes, suggested creditor action); EPC016-06 2025 v1.1 sections 4.4, 4.6.4 PT-04.06 and PT-04.08, 4.8.37 AT-R002 and 4.8.39 AT-R004 (reject: who may reject, before settlement); EPC016-06 2025 v1.1 sections 4.2, 4.3.4, 4.6.4 PT-04.10 and 4.8.39 AT-R004 (return: Debtor PSP, settled by D+5 Inter-PSP Business Days); EPC016-06 2025 v1.1 sections 4.3.4, 4.6.4 PT-04.20 to PT-04.27 and 4.8.39 AT-R004 (unauthorised refund: 13 months; request, mandate copy and settlement timelines); EPC016-06 2025 v1.1 sections 4.2 (36-month rule), 4.5.1 PT-01.03 and 4.6.3 PT-03.02 (mandate retention).", "confidence": "high" }, "currency": { "effective_since": "2025-10-05", "effective_note": "EPC016-06 2025 v1.1 was issued and took effect on 2025-10-05; v1.1 changed only the date for the unstructured address phase-out. EPC173-14 v8.0, published 2024-11-28, applies to both SDD rulebooks and is taken to be the current guidance [Unverified]. The next SDD Core rulebook is due for publication in November 2026 [Unverified].", "source_edition": "EPC173-14 v8.0; EPC016-06 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2024-11/EPC173-14%20v8.0%20Guidance%20on%20Reason%20Codes%20for%20SDD%20R-transactions.pdf", "source_class": "authoritative_primary", "source_title": "EPC173-14 v8.0 Guidance on Reason Codes for SDD R-transactions; EPC016-06 2025 SDD Core Rulebook version 1.1", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms the code name and meaning and the R-transaction types reject, return and refund for SDD Core per EPC173-14 v8.0 section 3. Confirms each return_windows entry against EPC016-06 2025 v1.1: reject before settlement; return by D+5; unauthorised refund claim within 13 months of the debit date (section 4.3.4, citing PSD Article 71); refund itself sent within 4 inter-PSP business days after the creditor's response or after 30 calendar days with no response, settled no later than 30 calendar days + 4 inter-PSP business days after the 13-month claim period ends (sections 4.6.4 PT-04.20 to PT-04.27). Also confirms the 3 banking business day and 7 banking business day mandate-copy-request timings (PT-04.22, PT-04.23) and the mandate-retention rule tied to the unauthorised refund period (PT-01.03, PT-03.02). Does not separately address SDD B2B mandate-confirmation mechanics, which are out of scope for this SDD Core record." } ] }, "rail_name": "SEPA Direct Debit Core", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sdd-core:MD02", "id": "MD02", "rail": "sepa-sdd-core", "kind": "reason-code", "name": "Mandate data missing or incorrect", "group": "authorization", "summary": "The mandate data carried in the collection is incomplete or does not agree with earlier data, usually after a mandate amendment.", "triggers": [ "Mandate data in the collection differs from the mandate because an amendment was never reported", "The mandate data conflicts with a version already received under the same UMR", "An amendment says the debtor account has changed, yet the collection still carries the old account" ], "actions": [ "Fix how the amendment is reported so it follows the rulebook's amendment process (EPC016-06 2025 v1.1 section 4.6.2, PR-02)", "Check the amended values themselves, then send a corrected collection" ], "retry": { "allowed": true, "rule": "Send a corrected collection with the right mandate and amendment data. A rejected collection that is corrected and presented again must keep its original sequence type: one-off stays one-off, recurrent stays recurrent (PT-04.04, PT-04.06, PT-04.08)." }, "facts": { "return_windows": [ { "action": "reject", "by": "Debtor PSP or CSM", "deadline": "Before inter-PSP settlement on the Due Date (D). A CSM rejects on receipt or on the later days its own rules allow" } ], "applies_to": "SDD Core" }, "caveat": "MD02 is a reject reason only. The rulebook's return reasons (section 4.8.39, AT-R004) do not include mandate data errors, so a problem found after settlement arrives under another code [Inference: most likely MD01].", "related": [ "sepa-sdd-core:MD01", "sepa-sdd-core:BE05" ], "basis": { "sources": "EPC173-14 v8.0 section 3, entry for MD02 (R-transaction types, use cases, root causes, suggested creditor action); EPC016-06 2025 v1.1 sections 4.4, 4.6.4 PT-04.06 and PT-04.08, 4.8.37 AT-R002 and 4.8.39 AT-R004 (reject: who may reject, before settlement); EPC016-06 2025 v1.1 section 4.6.4 PT-04.04, PT-04.06, PT-04.08 (re-presented rejects keep their sequence type); EPC016-06 2025 v1.1 section 4.6.2 PR-02.", "confidence": "high" }, "currency": { "effective_since": "2025-10-05", "effective_note": "EPC016-06 2025 v1.1 was issued and took effect on 2025-10-05; v1.1 changed only the date for the unstructured address phase-out. EPC173-14 v8.0, published 2024-11-28, applies to both SDD rulebooks and is taken to be the current guidance [Unverified]. The next SDD Core rulebook is due for publication in November 2026 [Unverified].", "source_edition": "EPC173-14 v8.0; EPC016-06 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2024-11/EPC173-14%20v8.0%20Guidance%20on%20Reason%20Codes%20for%20SDD%20R-transactions.pdf", "source_class": "authoritative_primary", "source_title": "EPC173-14 v8.0 Guidance on Reason Codes for SDD R-transactions; EPC016-06 2025 SDD Core Rulebook version 1.1", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17c", "notes": "Confirms MD02 as a Reject-only code, reasons Debtor PSP or CSM, deadline before inter-PSP settlement on the Due Date, per EPC173-14 v8.0 section 3 and EPC016-06 2025 v1.1 section 4.8.39 AT-R004. Confirms sequence type is kept on a re-presented rejected collection, EPC016-06 2025 v1.1 PT-04.04, PT-04.06, PT-04.08. Confirms the AT-R004 return reasons list has no mandate data entry, supporting the caveat that a post-settlement problem uses another code. Does not confirm which code a post-settlement mandate data problem actually uses." } ] }, "rail_name": "SEPA Direct Debit Core", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sdd-core:MD06", "id": "MD06", "rail": "sepa-sdd-core", "kind": "reason-code", "name": "Disputed authorised transaction", "group": "authorization", "summary": "The debtor asked for its money back within 8 weeks of the debit. In SDD Core this refund is unconditional: the debtor gives no reason and the debtor PSP must refund.", "triggers": [ "The amount collected differs from the amount in the pre-notification", "The debtor disputes the charge with the creditor and uses the no-questions-asked refund right", "Any other reason; the debtor does not have to give one (PT-04.15)" ], "actions": [ "Contact the debtor to settle the dispute; the refund does not decide who owes what", "Expect the creditor PSP to debit you for the refunded amount, and to recover the refund compensation under your own agreement with it (PT-04.18)", "Check the amount and date you pre-notified against what you collected" ], "retry": { "allowed": true, "rule": "The texts read contain no scheme bar on a new collection under a mandate that is still valid [Inference]. Settle the dispute with the debtor first; a new collection can be refunded again within 8 weeks." }, "facts": { "return_windows": [ { "action": "refund claim (authorised collection)", "by": "Debtor, through the Debtor PSP", "deadline": "8 weeks after the debit date" }, { "action": "refund", "by": "Debtor PSP", "deadline": "Settled no later than debit date + 8 weeks + 2 Inter-PSP Business Days" } ], "applies_to": "SDD Core" }, "caveat": "This is a debtor right, not a PSP return window, and it is not an ACH return: the money can come back up to 8 weeks plus 2 Inter-PSP Business Days after the debit. SDD B2B has no such right. The guidance ties it to the Payment Services Directive as well as the rulebook. The debtor PSP adds refund compensation, interest at the euro short-term rate (EUR STR) from the collection's settlement date to the refund's settlement date (PT-04.16).", "related": [ "sepa-sdd-core:MD01" ], "basis": { "sources": "EPC173-14 v8.0 section 3, entry for MD06 (R-transaction types, use cases, root causes, suggested creditor action); EPC016-06 2025 v1.1 sections 4.3.4, 4.4, 4.6.4 PT-04.15 to PT-04.18 (authorised refund: 8 weeks; settlement by debit date + 8 weeks + 2 Inter-PSP Business Days; refund compensation).", "confidence": "high" }, "currency": { "effective_since": "2025-10-05", "effective_note": "EPC016-06 2025 v1.1 was issued and took effect on 2025-10-05; v1.1 changed only the date for the unstructured address phase-out. EPC173-14 v8.0, published 2024-11-28, applies to both SDD rulebooks and is taken to be the current guidance [Unverified]. The next SDD Core rulebook is due for publication in November 2026 [Unverified].", "source_edition": "EPC173-14 v8.0; EPC016-06 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2024-11/EPC173-14%20v8.0%20Guidance%20on%20Reason%20Codes%20for%20SDD%20R-transactions.pdf", "source_class": "authoritative_primary", "source_title": "EPC173-14 v8.0 Guidance on Reason Codes for SDD R-transactions; EPC016-06 2025 SDD Core Rulebook version 1.1", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms the code name and meaning and the R-transaction types refund only for SDD Core per EPC173-14 v8.0 section 3. Confirms each return_windows entry against EPC016-06 2025 v1.1: refund claim by the debtor within 8 weeks of the debit date; refund settled no later than debit date + 8 weeks + 2 inter-PSP business days (sections 4.3.4, 4.6.4 PT-04.15 to PT-04.18). Also confirms the refund compensation calculation (EUR STR rate, from the original settlement date to the refund settlement date) at PT-04.16 exactly. No further open questions." } ] }, "rail_name": "SEPA Direct Debit Core", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sdd-core:MD07", "id": "MD07", "rail": "sepa-sdd-core", "kind": "reason-code", "name": "Debtor deceased", "group": "account", "summary": "The debtor has died.", "triggers": [ "The debtor PSP has been told the debtor has died" ], "actions": [ "Close the agreement with the deceased debtor", "Stop all collections under the mandate", "Pursue any amount still owed through the estate, outside the scheme [Inference]" ], "retry": { "allowed": false, "rule": "Do not collect again under this mandate." }, "facts": { "return_windows": [ { "action": "reject", "by": "Debtor PSP or CSM", "deadline": "Before inter-PSP settlement on the Due Date (D). A CSM rejects on receipt or on the later days its own rules allow" }, { "action": "return", "by": "Debtor PSP", "deadline": "Settled no later than 5 Inter-PSP Business Days (TARGET days) after the Settlement Date of the collection (D+5)" } ], "applies_to": "SDD Core" }, "caveat": "Data protection law in certain SEPA countries bars this code, and debtor PSPs there send MS03 instead (EPC173-14 v8.0 section 3). The guidance does not name the countries.", "related": [ "sepa-sdd-core:MS03", "sepa-sdd-core:AC04" ], "basis": { "sources": "EPC173-14 v8.0 section 3, entry for MD07 (R-transaction types, use cases, root causes, suggested creditor action); EPC016-06 2025 v1.1 sections 4.4, 4.6.4 PT-04.06 and PT-04.08, 4.8.37 AT-R002 and 4.8.39 AT-R004 (reject: who may reject, before settlement); EPC016-06 2025 v1.1 sections 4.2, 4.3.4, 4.6.4 PT-04.10 and 4.8.39 AT-R004 (return: Debtor PSP, settled by D+5 Inter-PSP Business Days).", "confidence": "high" }, "currency": { "effective_since": "2025-10-05", "effective_note": "EPC016-06 2025 v1.1 was issued and took effect on 2025-10-05; v1.1 changed only the date for the unstructured address phase-out. EPC173-14 v8.0, published 2024-11-28, applies to both SDD rulebooks and is taken to be the current guidance [Unverified]. The next SDD Core rulebook is due for publication in November 2026 [Unverified].", "source_edition": "EPC173-14 v8.0; EPC016-06 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2024-11/EPC173-14%20v8.0%20Guidance%20on%20Reason%20Codes%20for%20SDD%20R-transactions.pdf", "source_class": "authoritative_primary", "source_title": "EPC173-14 v8.0 Guidance on Reason Codes for SDD R-transactions; EPC016-06 2025 SDD Core Rulebook version 1.1", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms the code name and meaning and the R-transaction types reject and return for SDD Core per EPC173-14 v8.0 section 3. Confirms each return_windows entry against EPC016-06 2025 v1.1: reject before settlement, return by D+5, both as above. Does not name which SEPA countries restrict this code under data protection law; the guidance does not name them either." } ] }, "rail_name": "SEPA Direct Debit Core", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sdd-core:MS02", "id": "MS02", "rail": "sepa-sdd-core", "kind": "reason-code", "name": "Refusal by the Debtor", "group": "authorization", "summary": "The debtor refused the collection, usually after seeing the pre-notification. No further reason is given.", "triggers": [ "The debtor received the pre-notification and told the debtor PSP not to pay this collection" ], "actions": [ "Contact the debtor to find out why and whether the mandate still stands", "Do not treat a refusal as a mandate cancellation unless the debtor says so [Inference]" ], "retry": { "allowed": false, "rule": "Do not present the refused collection again before speaking to the debtor. The texts read set no scheme rule on this [Unverified]." }, "facts": { "return_windows": [ { "action": "refusal", "by": "Debtor, instructing the Debtor PSP", "deadline": "Up to and including the Due Date for the scheme; the exact cut-off is agreed between the Debtor and the Debtor PSP" }, { "action": "reject", "by": "CSM or Debtor PSP", "deadline": "Before inter-PSP settlement on the Due Date (D)" }, { "action": "return", "by": "Debtor PSP", "deadline": "Settled no later than 5 Inter-PSP Business Days (TARGET days) after the Settlement Date of the collection (D+5)" }, { "action": "reversal", "by": "Creditor or Creditor PSP, the only parties the rulebook lets start a reversal; whether MS02 is ever carried on one is unconfirmed [Unverified]", "deadline": "From the Settlement Date (D) to D+5 Inter-PSP Business Days, counted end to end from the creditor's instruction to CSM forwarding" } ], "applies_to": "SDD Core" }, "caveat": "A refusal is not itself an inter-PSP message: before settlement the debtor PSP turns it into a reject, after settlement into a return (EPC016-06 2025 v1.1 section 4.4, PT-04.02 bis). The rulebook lists refusal among the reasons a CSM or the debtor PSP may give for a reject, without saying which uses it (section 4.8.39, AT-R004); the debtor PSP is the likely sender, since the debtor instructs it [Inference]. The guidance and the rulebook conflict on reversals. The guidance lists reversal among the R-transaction types for MS02 (EPC173-14 v8.0 section 3). The rulebook has the creditor or creditor PSP start a reversal and gives its reason code only two values, a duplicate entry and an unspecified reason (EPC016-06 2025 v1.1 sections 4.6.5 PT-05.01 and 4.8.56, AT-R041); neither text ties MS02 to either value or explains how a debtor's refusal would lead to a creditor-side reversal. The reversal entry is kept only because the guidance lists it [Unverified]. The rulebook also lets a reversal itself be rejected or returned (section 4.7.6, DS-05), which may be what the guidance means [Speculation]. Standing blocks and limits the debtor sets with its PSP usually surface as SL01 instead [Inference].", "related": [ "sepa-sdd-core:SL01", "sepa-sdd-core:MD01", "sepa-sdd-core:MS03" ], "basis": { "sources": "EPC173-14 v8.0 section 3, entry for MS02 (R-transaction types, use cases, root causes, suggested creditor action); EPC016-06 2025 v1.1 sections 4.4 and 4.6.4 PT-04.02 bis (refusal: up to and including the Due Date); EPC016-06 2025 v1.1 sections 4.4, 4.6.4 PT-04.06 and PT-04.08, 4.8.37 AT-R002 and 4.8.39 AT-R004 (reject: who may reject, before settlement); EPC016-06 2025 v1.1 sections 4.2, 4.3.4, 4.6.4 PT-04.10 and 4.8.39 AT-R004 (return: Debtor PSP, settled by D+5 Inter-PSP Business Days); EPC016-06 2025 v1.1 sections 4.3.4, 4.4, 4.6.5 PT-05.01 to PT-05.03 and 4.8.56 AT-R041 (reversal: Creditor or Creditor PSP, D to D+5 Inter-PSP Business Days). EPC016-06 2025 v1.1 section 4.7.6 DS-05 (a reversal may itself be rejected or returned).", "confidence": "medium" }, "currency": { "effective_since": "2025-10-05", "effective_note": "EPC016-06 2025 v1.1 was issued and took effect on 2025-10-05; v1.1 changed only the date for the unstructured address phase-out. EPC173-14 v8.0, published 2024-11-28, applies to both SDD rulebooks and is taken to be the current guidance [Unverified]. The next SDD Core rulebook is due for publication in November 2026 [Unverified].", "source_edition": "EPC173-14 v8.0; EPC016-06 2025 v1.1", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "rail_name": "SEPA Direct Debit Core", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": null, "effective_status": "draft", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sdd-core:MS03", "id": "MS03", "rail": "sepa-sdd-core", "kind": "reason-code", "name": "Reason not specified", "group": "administrative", "summary": "No reason is given. A debtor PSP should use it only where national law, such as data protection law, bars the specific code. On a reversal, the creditor side may use it freely.", "triggers": [ "The real reason is account closed (AC04), insufficient funds (AM04), debtor deceased (MD07) or a regulatory reason (RR01 to RR04), and national law bars disclosing it", "On a reversal, the creditor or creditor PSP chose not to give a reason (EPC016-06 2025 v1.1 section 4.8.56, AT-R041)" ], "actions": [ "Contact the debtor to find out what happened", "Read an MS03 reject or return as possibly hiding AC04, AM04, MD07 or RR01 to RR04; do not assume insufficient funds [Inference]", "Track MS03 by debtor PSP country, and raise heavy use from one debtor PSP with the creditor PSP [Inference]" ], "retry": { "allowed": false, "rule": "The texts read set no scheme retry rule [Unverified]. Because the underlying reason is unknown, find it out from the debtor before collecting again [Inference]." }, "facts": { "return_windows": [ { "action": "reject", "by": "Debtor PSP or CSM", "deadline": "Before inter-PSP settlement on the Due Date (D). A CSM rejects on receipt or on the later days its own rules allow" }, { "action": "return", "by": "Debtor PSP", "deadline": "Settled no later than 5 Inter-PSP Business Days (TARGET days) after the Settlement Date of the collection (D+5)" }, { "action": "reversal", "by": "Creditor or Creditor PSP", "deadline": "From the Settlement Date (D) to D+5 Inter-PSP Business Days, counted end to end from the creditor's instruction to CSM forwarding" } ], "applies_to": "SDD Core" }, "caveat": "The guidance asks PSPs to limit MS03 and pick a specific code wherever the law allows (EPC173-14 v8.0 sections 2 and 3). It does not list which countries restrict which codes.", "related": [ "sepa-sdd-core:AC04", "sepa-sdd-core:AM04", "sepa-sdd-core:MD07", "sepa-sdd-core:RR01", "sepa-sdd-core:RR02", "sepa-sdd-core:RR03", "sepa-sdd-core:RR04", "sepa-sdd-core:AM05", "sepa-sdd-core:MS02" ], "basis": { "sources": "EPC173-14 v8.0 section 3, entry for MS03 (R-transaction types, use cases, root causes, suggested creditor action); EPC016-06 2025 v1.1 sections 4.4, 4.6.4 PT-04.06 and PT-04.08, 4.8.37 AT-R002 and 4.8.39 AT-R004 (reject: who may reject, before settlement); EPC016-06 2025 v1.1 sections 4.2, 4.3.4, 4.6.4 PT-04.10 and 4.8.39 AT-R004 (return: Debtor PSP, settled by D+5 Inter-PSP Business Days); EPC016-06 2025 v1.1 sections 4.3.4, 4.4, 4.6.5 PT-05.01 to PT-05.03 and 4.8.56 AT-R041 (reversal: Creditor or Creditor PSP, D to D+5 Inter-PSP Business Days). EPC173-14 v8.0 section 2 (avoid general codes where a precise one is lawful).", "confidence": "high" }, "currency": { "effective_since": "2025-10-05", "effective_note": "EPC016-06 2025 v1.1 was issued and took effect on 2025-10-05; v1.1 changed only the date for the unstructured address phase-out. EPC173-14 v8.0, published 2024-11-28, applies to both SDD rulebooks and is taken to be the current guidance [Unverified]. The next SDD Core rulebook is due for publication in November 2026 [Unverified].", "source_edition": "EPC173-14 v8.0; EPC016-06 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2024-11/EPC173-14%20v8.0%20Guidance%20on%20Reason%20Codes%20for%20SDD%20R-transactions.pdf", "source_class": "authoritative_primary", "source_title": "EPC173-14 v8.0 Guidance on Reason Codes for SDD R-transactions; EPC016-06 2025 SDD Core Rulebook version 1.1", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms the code name and meaning and the R-transaction types reject, return and reversal for SDD Core per EPC173-14 v8.0 section 3. Confirms each return_windows entry against EPC016-06 2025 v1.1: reject before settlement; return by D+5; reversal by creditor or creditor PSP from D to D+5 as above. Does not name which countries or which specific codes trigger MS03 substitution beyond the general guidance in EPC173-14 v8.0 sections 2 and 3." } ] }, "rail_name": "SEPA Direct Debit Core", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sdd-core:RC01", "id": "RC01", "rail": "sepa-sdd-core", "kind": "reason-code", "name": "PSP identifier incorrect (invalid BIC)", "group": "technical", "summary": "A BIC on the collection is wrong, incomplete, or does not exist in the BIC directory.", "triggers": [ "For a collection involving a non-EEA SEPA country, the creditor supplied an 8-character BIC where the full 11-character BIC was needed", "The creditor PSP, the CSM or the debtor PSP put a BIC in the inter-PSP message that is not in the BIC directory" ], "actions": [ "For a non-EEA collection, get the correct and complete BIC from the debtor", "Ask the creditor PSP to put the correct and complete debtor PSP BIC in the inter-PSP message" ], "retry": { "allowed": true, "rule": "Correct the BIC and collect again. A rejected collection that is corrected and presented again must keep its original sequence type: one-off stays one-off, recurrent stays recurrent (PT-04.04, PT-04.06, PT-04.08)." }, "facts": { "return_windows": [ { "action": "reject", "by": "Debtor PSP or CSM", "deadline": "Before inter-PSP settlement on the Due Date (D). A CSM rejects on receipt or on the later days its own rules allow" }, { "action": "return", "by": "Debtor PSP", "deadline": "Settled no later than 5 Inter-PSP Business Days (TARGET days) after the Settlement Date of the collection (D+5)" } ], "applies_to": "SDD Core" }, "caveat": "A customer needs to give a BIC only where at least one of the two PSPs is in a non-EEA SEPA country (EPC016-06 2025 v1.1 section 4.7.2, DS-01, and 4.7.4, DS-03). Within the EEA the IBAN is enough, so RC01 on an EEA collection points to a PSP or CSM data error [Inference].", "related": [ "sepa-sdd-core:DNOR", "sepa-sdd-core:CNOR", "sepa-sdd-core:AC01" ], "basis": { "sources": "EPC173-14 v8.0 section 3, entry for RC01 (R-transaction types, use cases, root causes, suggested creditor action); EPC016-06 2025 v1.1 sections 4.4, 4.6.4 PT-04.06 and PT-04.08, 4.8.37 AT-R002 and 4.8.39 AT-R004 (reject: who may reject, before settlement); EPC016-06 2025 v1.1 sections 4.2, 4.3.4, 4.6.4 PT-04.10 and 4.8.39 AT-R004 (return: Debtor PSP, settled by D+5 Inter-PSP Business Days); EPC016-06 2025 v1.1 section 4.6.4 PT-04.04, PT-04.06, PT-04.08 (re-presented rejects keep their sequence type); EPC016-06 2025 v1.1 sections 4.7.2 DS-01 and 4.7.4 DS-03 (BIC only for non-EEA cases).", "confidence": "high" }, "currency": { "effective_since": "2025-10-05", "effective_note": "EPC016-06 2025 v1.1 was issued and took effect on 2025-10-05; v1.1 changed only the date for the unstructured address phase-out. EPC173-14 v8.0, published 2024-11-28, applies to both SDD rulebooks and is taken to be the current guidance [Unverified]. The next SDD Core rulebook is due for publication in November 2026 [Unverified].", "source_edition": "EPC173-14 v8.0; EPC016-06 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2024-11/EPC173-14%20v8.0%20Guidance%20on%20Reason%20Codes%20for%20SDD%20R-transactions.pdf", "source_class": "authoritative_primary", "source_title": "EPC173-14 v8.0 Guidance on Reason Codes for SDD R-transactions; EPC016-06 2025 SDD Core Rulebook version 1.1", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms the code name and meaning and the R-transaction types reject and return for SDD Core per EPC173-14 v8.0 section 3. Confirms each return_windows entry against EPC016-06 2025 v1.1: reject before settlement, return by D+5, both as above. Also confirms the non-EEA BIC requirement (BIC needed only when at least one PSP is in a non-EEA SEPA country or territory) at sections 4.7.2 DS-01 and 4.7.4 DS-03 exactly. No further open questions." } ] }, "rail_name": "SEPA Direct Debit Core", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sdd-core:RR01", "id": "RR01", "rail": "sepa-sdd-core", "kind": "reason-code", "name": "Regulatory reason: missing debtor account or identification", "group": "administrative", "summary": "Debtor account or identification details that regulation requires are missing or insufficient.", "triggers": [ "The debtor's IBAN or unique identification, needed for regulatory reasons, is missing or incomplete" ], "actions": [ "Complete the debtor account information in the collection", "Contact the creditor PSP" ], "retry": { "allowed": true, "rule": "Complete the missing data and collect again. A rejected collection that is corrected and presented again must keep its original sequence type: one-off stays one-off, recurrent stays recurrent (PT-04.04, PT-04.06, PT-04.08)." }, "facts": { "return_windows": [ { "action": "reject", "by": "Debtor PSP or CSM", "deadline": "Before inter-PSP settlement on the Due Date (D). A CSM rejects on receipt or on the later days its own rules allow" }, { "action": "return", "by": "Debtor PSP", "deadline": "Settled no later than 5 Inter-PSP Business Days (TARGET days) after the Settlement Date of the collection (D+5)" } ], "applies_to": "SDD Core" }, "caveat": "Data protection law in certain SEPA countries bars this code, and debtor PSPs there send MS03 instead (EPC173-14 v8.0 section 3). The guidance does not name the countries. The texts read do not name the regulation behind the requirement [Unverified; the rulebook's section 5.1 cites the Regulation on Information accompanying Transfers of Funds, which is a likely source, Inference].", "related": [ "sepa-sdd-core:RR02", "sepa-sdd-core:RR03", "sepa-sdd-core:RR04", "sepa-sdd-core:MS03" ], "basis": { "sources": "EPC173-14 v8.0 section 3, entry for RR01 (R-transaction types, use cases, root causes, suggested creditor action); EPC016-06 2025 v1.1 sections 4.4, 4.6.4 PT-04.06 and PT-04.08, 4.8.37 AT-R002 and 4.8.39 AT-R004 (reject: who may reject, before settlement); EPC016-06 2025 v1.1 sections 4.2, 4.3.4, 4.6.4 PT-04.10 and 4.8.39 AT-R004 (return: Debtor PSP, settled by D+5 Inter-PSP Business Days); EPC016-06 2025 v1.1 section 4.6.4 PT-04.04, PT-04.06, PT-04.08 (re-presented rejects keep their sequence type); EPC016-06 2025 v1.1 section 5.1.", "confidence": "high" }, "currency": { "effective_since": "2025-10-05", "effective_note": "EPC016-06 2025 v1.1 was issued and took effect on 2025-10-05; v1.1 changed only the date for the unstructured address phase-out. EPC173-14 v8.0, published 2024-11-28, applies to both SDD rulebooks and is taken to be the current guidance [Unverified]. The next SDD Core rulebook is due for publication in November 2026 [Unverified].", "source_edition": "EPC173-14 v8.0; EPC016-06 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2024-11/EPC173-14%20v8.0%20Guidance%20on%20Reason%20Codes%20for%20SDD%20R-transactions.pdf", "source_class": "authoritative_primary", "source_title": "EPC173-14 v8.0 Guidance on Reason Codes for SDD R-transactions; EPC016-06 2025 SDD Core Rulebook version 1.1", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms the code name and meaning and the R-transaction types reject and return for SDD Core per EPC173-14 v8.0 section 3. Confirms each return_windows entry against EPC016-06 2025 v1.1: reject before settlement, return by D+5, both as above. Does not name the underlying regulation for the debtor-identification requirement; the record's reference to the Regulation on Information accompanying Transfers of Funds (rulebook section 5.1) stays its own inference. Does not name which countries restrict this code." } ] }, "rail_name": "SEPA Direct Debit Core", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sdd-core:RR02", "id": "RR02", "rail": "sepa-sdd-core", "kind": "reason-code", "name": "Regulatory reason: missing debtor name or address", "group": "administrative", "summary": "The debtor's name, or where required the debtor's address, is missing, or the address is in a format no longer allowed.", "triggers": [ "The collection has no debtor name", "A collection involving a non-EEA SEPA country has no debtor address; within the EEA the address is optional", "The debtor address is in an invalid format, or an unstructured address is sent after the November 2026 phase-out" ], "actions": [ "Add the debtor name and, where required, the debtor address in an allowed format", "Move stored debtor addresses to structured or hybrid form before 15 November 2026", "Contact the creditor PSP" ], "retry": { "allowed": true, "rule": "Complete or correct the data and collect again. A rejected collection that is corrected and presented again must keep its original sequence type: one-off stays one-off, recurrent stays recurrent (PT-04.04, PT-04.06, PT-04.08)." }, "facts": { "return_windows": [ { "action": "reject", "by": "Debtor PSP or CSM", "deadline": "Before inter-PSP settlement on the Due Date (D). A CSM rejects on receipt or on the later days its own rules allow" }, { "action": "return", "by": "Debtor PSP", "deadline": "Settled no later than 5 Inter-PSP Business Days (TARGET days) after the Settlement Date of the collection (D+5)" } ], "applies_to": "SDD Core" }, "caveat": "From 15 November 2026 only structured or hybrid addresses are allowed; unstructured addresses are no longer accepted (EPC016-06 2025 v1.1 cover note, sections 4.8.14 AT-E004 and 4.8.20 AT-P005). EPC173-14 v8.0 predates the change of date and says only November 2026. Data protection law in certain SEPA countries bars this code, and debtor PSPs there send MS03 instead (EPC173-14 v8.0 section 3). The guidance does not name the countries. The texts read do not name the regulation behind the requirement [Unverified; the rulebook's section 5.1 cites the Regulation on Information accompanying Transfers of Funds, which is a likely source, Inference].", "related": [ "sepa-sdd-core:RR01", "sepa-sdd-core:RR03", "sepa-sdd-core:RR04", "sepa-sdd-core:MS03" ], "basis": { "sources": "EPC173-14 v8.0 section 3, entry for RR02 (R-transaction types, use cases, root causes, suggested creditor action); EPC016-06 2025 v1.1 sections 4.4, 4.6.4 PT-04.06 and PT-04.08, 4.8.37 AT-R002 and 4.8.39 AT-R004 (reject: who may reject, before settlement); EPC016-06 2025 v1.1 sections 4.2, 4.3.4, 4.6.4 PT-04.10 and 4.8.39 AT-R004 (return: Debtor PSP, settled by D+5 Inter-PSP Business Days); EPC016-06 2025 v1.1 section 4.6.4 PT-04.04, PT-04.06, PT-04.08 (re-presented rejects keep their sequence type); EPC016-06 2025 v1.1 cover note (IMPORTANT MESSAGE), sections 4.8.20 AT-P005 and 5.1.", "confidence": "high" }, "currency": { "effective_since": "2025-10-05", "effective_note": "EPC016-06 2025 v1.1 was issued and took effect on 2025-10-05; v1.1 changed only the date for the unstructured address phase-out. EPC173-14 v8.0, published 2024-11-28, applies to both SDD rulebooks and is taken to be the current guidance [Unverified]. The next SDD Core rulebook is due for publication in November 2026 [Unverified].", "source_edition": "EPC173-14 v8.0; EPC016-06 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2024-11/EPC173-14%20v8.0%20Guidance%20on%20Reason%20Codes%20for%20SDD%20R-transactions.pdf", "source_class": "authoritative_primary", "source_title": "EPC173-14 v8.0 Guidance on Reason Codes for SDD R-transactions; EPC016-06 2025 SDD Core Rulebook version 1.1", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms the code name and meaning and the R-transaction types reject and return for SDD Core per EPC173-14 v8.0 section 3. Confirms each return_windows entry against EPC016-06 2025 v1.1: reject before settlement, return by D+5, both as above. Also confirms the 15 November 2026 structured/hybrid address phase-out date and the AT-P005 debtor address section exactly. Does not name the underlying regulation for the requirement (record's reference to the Regulation on Information accompanying Transfers of Funds is its own inference) or which countries restrict this code." } ] }, "rail_name": "SEPA Direct Debit Core", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sdd-core:RR03", "id": "RR03", "rail": "sepa-sdd-core", "kind": "reason-code", "name": "Regulatory reason: missing creditor name or address", "group": "administrative", "summary": "The creditor's name is missing, or the creditor address is in a format no longer allowed.", "triggers": [ "The collection has no creditor name; the creditor address itself is optional", "The creditor address is in an invalid format, or an unstructured address is sent after the November 2026 phase-out" ], "actions": [ "Add the creditor name to the collection", "Send any creditor address in structured or hybrid form from 15 November 2026", "Contact the creditor PSP" ], "retry": { "allowed": true, "rule": "Complete or correct the data and collect again. A rejected collection that is corrected and presented again must keep its original sequence type: one-off stays one-off, recurrent stays recurrent (PT-04.04, PT-04.06, PT-04.08)." }, "facts": { "return_windows": [ { "action": "reject", "by": "Debtor PSP or CSM", "deadline": "Before inter-PSP settlement on the Due Date (D). A CSM rejects on receipt or on the later days its own rules allow" }, { "action": "return", "by": "Debtor PSP", "deadline": "Settled no later than 5 Inter-PSP Business Days (TARGET days) after the Settlement Date of the collection (D+5)" } ], "applies_to": "SDD Core" }, "caveat": "From 15 November 2026 only structured or hybrid addresses are allowed; unstructured addresses are no longer accepted (EPC016-06 2025 v1.1 cover note, sections 4.8.14 AT-E004 and 4.8.20 AT-P005). EPC173-14 v8.0 predates the change of date and says only November 2026. Data protection law in certain SEPA countries bars this code, and debtor PSPs there send MS03 instead (EPC173-14 v8.0 section 3). The guidance does not name the countries. The texts read do not name the regulation behind the requirement [Unverified; the rulebook's section 5.1 cites the Regulation on Information accompanying Transfers of Funds, which is a likely source, Inference].", "related": [ "sepa-sdd-core:RR01", "sepa-sdd-core:RR02", "sepa-sdd-core:RR04", "sepa-sdd-core:MS03" ], "basis": { "sources": "EPC173-14 v8.0 section 3, entry for RR03 (R-transaction types, use cases, root causes, suggested creditor action); EPC016-06 2025 v1.1 sections 4.4, 4.6.4 PT-04.06 and PT-04.08, 4.8.37 AT-R002 and 4.8.39 AT-R004 (reject: who may reject, before settlement); EPC016-06 2025 v1.1 sections 4.2, 4.3.4, 4.6.4 PT-04.10 and 4.8.39 AT-R004 (return: Debtor PSP, settled by D+5 Inter-PSP Business Days); EPC016-06 2025 v1.1 section 4.6.4 PT-04.04, PT-04.06, PT-04.08 (re-presented rejects keep their sequence type); EPC016-06 2025 v1.1 cover note (IMPORTANT MESSAGE), sections 4.8.14 AT-E004 and 5.1.", "confidence": "high" }, "currency": { "effective_since": "2025-10-05", "effective_note": "EPC016-06 2025 v1.1 was issued and took effect on 2025-10-05; v1.1 changed only the date for the unstructured address phase-out. EPC173-14 v8.0, published 2024-11-28, applies to both SDD rulebooks and is taken to be the current guidance [Unverified]. The next SDD Core rulebook is due for publication in November 2026 [Unverified].", "source_edition": "EPC173-14 v8.0; EPC016-06 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2024-11/EPC173-14%20v8.0%20Guidance%20on%20Reason%20Codes%20for%20SDD%20R-transactions.pdf", "source_class": "authoritative_primary", "source_title": "EPC173-14 v8.0 Guidance on Reason Codes for SDD R-transactions; EPC016-06 2025 SDD Core Rulebook version 1.1", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms the code name and meaning and the R-transaction types reject and return for SDD Core per EPC173-14 v8.0 section 3. Confirms each return_windows entry against EPC016-06 2025 v1.1: reject before settlement, return by D+5, both as above. Also confirms the 15 November 2026 structured/hybrid address phase-out date and the AT-E004 creditor address section exactly. Does not name the underlying regulation for the requirement (record's reference to the Regulation on Information accompanying Transfers of Funds is its own inference) or which countries restrict this code." } ] }, "rail_name": "SEPA Direct Debit Core", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sdd-core:RR04", "id": "RR04", "rail": "sepa-sdd-core", "kind": "reason-code", "name": "Regulatory reason", "group": "administrative", "summary": "A regulatory reason other than those covered by RR01, RR02 and RR03. The code carries no further detail.", "triggers": [ "A regulatory requirement not covered by RR01, RR02 or RR03 stops the debtor PSP or the CSM from processing the collection", "Sanctions or anti-money-laundering screening results [Unverified; the EPC texts read do not say so]" ], "actions": [ "Contact the creditor PSP to learn what is needed" ], "retry": { "allowed": false, "rule": "Do not present again until the creditor PSP has established what the regulatory issue is [Inference]." }, "facts": { "return_windows": [ { "action": "reject", "by": "Debtor PSP or CSM", "deadline": "Before inter-PSP settlement on the Due Date (D). A CSM rejects on receipt or on the later days its own rules allow" }, { "action": "return", "by": "Debtor PSP", "deadline": "Settled no later than 5 Inter-PSP Business Days (TARGET days) after the Settlement Date of the collection (D+5)" } ], "applies_to": "SDD Core" }, "caveat": "Data protection law in certain SEPA countries bars this code, and debtor PSPs there send MS03 instead (EPC173-14 v8.0 section 3). The guidance does not name the countries. The guidance reserves RR04 for regulatory reasons other than RR01 to RR03.", "related": [ "sepa-sdd-core:RR01", "sepa-sdd-core:RR02", "sepa-sdd-core:RR03", "sepa-sdd-core:MS03" ], "basis": { "sources": "EPC173-14 v8.0 section 3, entry for RR04 (R-transaction types, use cases, root causes, suggested creditor action); EPC016-06 2025 v1.1 sections 4.4, 4.6.4 PT-04.06 and PT-04.08, 4.8.37 AT-R002 and 4.8.39 AT-R004 (reject: who may reject, before settlement); EPC016-06 2025 v1.1 sections 4.2, 4.3.4, 4.6.4 PT-04.10 and 4.8.39 AT-R004 (return: Debtor PSP, settled by D+5 Inter-PSP Business Days).", "confidence": "medium" }, "currency": { "effective_since": "2025-10-05", "effective_note": "EPC016-06 2025 v1.1 was issued and took effect on 2025-10-05; v1.1 changed only the date for the unstructured address phase-out. EPC173-14 v8.0, published 2024-11-28, applies to both SDD rulebooks and is taken to be the current guidance [Unverified]. The next SDD Core rulebook is due for publication in November 2026 [Unverified].", "source_edition": "EPC173-14 v8.0; EPC016-06 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2024-11/EPC173-14%20v8.0%20Guidance%20on%20Reason%20Codes%20for%20SDD%20R-transactions.pdf", "source_class": "authoritative_primary", "source_title": "EPC173-14 v8.0 Guidance on Reason Codes for SDD R-transactions; EPC016-06 2025 SDD Core Rulebook version 1.1", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms the code name and meaning and the R-transaction types reject and return for SDD Core per EPC173-14 v8.0 section 3. Confirms each return_windows entry against EPC016-06 2025 v1.1: reject before settlement, return by D+5, both as above. Does not name which countries restrict this code, and does not name any specific regulatory reasons beyond RR01 to RR03; the guidance reserves RR04 as a catch-all." } ] }, "rail_name": "SEPA Direct Debit Core", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sdd-core:SL01", "id": "SL01", "rail": "sepa-sdd-core", "kind": "reason-code", "name": "Specific service offered by the Debtor PSP", "group": "authorization", "summary": "The debtor PSP stopped the collection because of a service it offers the debtor, most often a control the debtor set: a creditor block, an amount limit or a frequency limit.", "triggers": [ "The debtor blocked this creditor", "The collection exceeds an amount limit the debtor set", "The collection exceeds a frequency limit the debtor set", "Another debtor PSP service, such as an authorisation or stop payment feature" ], "actions": [ "Contact the debtor; only the debtor can lift a block or change a limit", "Check whether the amount or frequency changed from what the debtor expects" ], "retry": { "allowed": false, "rule": "Do not present again until the debtor confirms the block or limit has changed [Inference]." }, "facts": { "return_windows": [ { "action": "reject", "by": "Debtor PSP", "deadline": "Before inter-PSP settlement on the Due Date (D)" }, { "action": "return", "by": "Debtor PSP", "deadline": "Settled no later than 5 Inter-PSP Business Days (TARGET days) after the Settlement Date of the collection (D+5)" } ], "applies_to": "SDD Core" }, "caveat": "Debtor PSPs must let debtors block all direct debits and set limits on them, under Article 5 of the SEPA Regulation (EU) No 260/2012 as the rulebook cites (section 4.2). SL01 is how most of those debtor controls surface [Inference]. The guidance also notes debtor PSPs may use this code for services built as consumer protection (EPC173-14 v8.0 section 2).", "related": [ "sepa-sdd-core:MS02", "sepa-sdd-core:AC06", "sepa-sdd-core:MD01" ], "basis": { "sources": "EPC173-14 v8.0 section 3, entry for SL01 (R-transaction types, use cases, root causes, suggested creditor action); EPC016-06 2025 v1.1 sections 4.4, 4.6.4 PT-04.06 and PT-04.08, 4.8.37 AT-R002 and 4.8.39 AT-R004 (reject: who may reject, before settlement); EPC016-06 2025 v1.1 sections 4.2, 4.3.4, 4.6.4 PT-04.10 and 4.8.39 AT-R004 (return: Debtor PSP, settled by D+5 Inter-PSP Business Days); EPC016-06 2025 v1.1 section 4.2 (debtor blocking and limit rights). EPC173-14 v8.0 section 2.", "confidence": "high" }, "currency": { "effective_since": "2025-10-05", "effective_note": "EPC016-06 2025 v1.1 was issued and took effect on 2025-10-05; v1.1 changed only the date for the unstructured address phase-out. EPC173-14 v8.0, published 2024-11-28, applies to both SDD rulebooks and is taken to be the current guidance [Unverified]. The next SDD Core rulebook is due for publication in November 2026 [Unverified].", "source_edition": "EPC173-14 v8.0; EPC016-06 2025 v1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2024-11/EPC173-14%20v8.0%20Guidance%20on%20Reason%20Codes%20for%20SDD%20R-transactions.pdf", "source_class": "authoritative_primary", "source_title": "EPC173-14 v8.0 Guidance on Reason Codes for SDD R-transactions; EPC016-06 2025 SDD Core Rulebook version 1.1", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms the code name and meaning and the R-transaction types reject and return for SDD Core per EPC173-14 v8.0 section 3. Confirms each return_windows entry against EPC016-06 2025 v1.1: reject before settlement, return by D+5, both as above. Also confirms the debtor's blocking and limitation rights under Article 5 of the SEPA Regulation as stated in EPC016-06 2025 v1.1 section 4.2. No further open questions." } ] }, "rail_name": "SEPA Direct Debit Core", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "uk-fps-reject:1114", "id": "1114", "rail": "uk-fps-reject", "kind": "reason-code", "name": "Sort code and account number do not identify a known account", "group": "account", "summary": "The sort code and account number given for the payee do not together identify an account the receiving side knows. Both public sources agree on the meaning. The pair is what fails, so a valid sort code with a wrong account number lands here just as a mistyped sort code does.", "triggers": [ "A digit was mistyped or dropped in the payee's account number or sort code", "The account number is real but belongs at a different sort code", "The payee gave details for an account that was never opened or was never reachable by Faster Payments" ], "actions": [ "Payer: check the sort code and account number with the payee before sending again, and use Confirmation of Payee where it is offered", "Sending institution: tell the customer the payment failed and why, in plain words" ], "retry": { "allowed": true, "rule": "Send a new payment once the details are corrected. Nothing reached the payee and nothing settled, so there is nothing to reverse or return." }, "facts": { "return_windows": [ { "action": "rejection", "by": "Receiving FPS Institution", "deadline": "For each Faster Payment it receives, the receiving directly connected participant must answer within a few seconds with an unqualified acceptance, a qualified acceptance carrying a qualifier code, or a rejection carrying a rejection code. Pay.UK says the exact time is defined in the FPS Procedures and Technical Specifications, which it does not publish, so a few seconds is the only public figure. On the sending side the payer, where present, must be told the fate of the payment within 15 seconds." } ], "applies_to": "a Faster Payments credit push to any account type" }, "caveat": "Not an ISO 20022 code. Faster Payments runs on ISO 8583 and these numerics are Pay.UK's own, so never carry a meaning here from an ISO ExternalStatusReason value or from another rail's list. A rejection is also not a return: no money reached the payee, so there is nothing to send back. Distinguish this from the agency variants in the same list: a separate code covers a sending or receiving agency's own sort code and account number being unknown, and neither of those is drafted here.", "related": [ "uk-fps-reject:1160", "uk-fps-reject:1162" ], "basis": { "sources": "Listed as a Faster Payments reject code, with the meaning given here in Orca's own words, by two independent public sources on different hosts, both read 2026-09-20: LHV Connect's Faster Payment Reject Codes table (family B) and NatWest's Understanding Faster Payment Rejection and Reason Codes page (family A). Pay.UK's own list, in the FPS Procedures Appendix B section 8.2, was not consulted and is not published. The rejection mechanics come from Faster Payments System Principles v11 and Pay.UK's Certainty of Fate proposed rule clarification, also read 2026-09-20. Confidence is capped at medium because the governing authority's own text was not read.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: no public source read dates this code", "effective_to": null, "effective_note": "No public source read says when this code became permitted on Faster Payments [Unverified]. Pay.UK does not publish the code list; the two pages this record rests on were last updated within the year before they were read on 2026-09-20.", "source_edition": "The FPS Procedures, Appendix B, FPS Codes, were not consulted: Pay.UK makes the FPS rules and procedures available to participants' legal departments only, as its 2025 PFMI self-assessment states at key consideration 23.1. This record rests on two independent public sources on different hosts, LHV Connect's code reference tables and NatWest's support centre page, both read 2026-09-20, together with Pay.UK's own public documents for the mechanics.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "primary_not_public": true, "corroboration": [ { "source_url": "https://docs.lhv.com/home/connect/overview/code-reference-tables/payment-reject-codes", "source_class": "secondary", "source_title": "LHV Connect documentation, Payment Reject Codes", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms code 1114 as creditor sort code or account number unknown, an invalid sort code and account number combination in this family's own wording, agreeing with the second family on the same meaning." }, { "source_url": "https://www.natwest.com/support-centre/bank-accounts-and-supporting-information/general/what-are-the-faster-payment-reject-and-reason-codes.html", "source_class": "secondary", "source_title": "NatWest support centre, Understanding Faster Payment Rejection and Reason Codes", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms code 1114 as a rejection for an invalid sort code and account number combination, agreeing with the first family on the same meaning." } ] }, "rail_name": "Faster Payments Rejection Codes", "governing_authority": "Pay.UK Limited", "snapshot": "2026-09-20", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "not_public", "label": "the operator's own text", "needs": "what the operator's own text says, which Orca has not read", "detail": "Pay.UK Limited's own text is not the source for this code: it is not public, or not under terms Orca can use. It rests on 2 named public sources, so a term set by agreement rather than by a published rule is not Orca's to state.", "from": "currency.primary_not_public" } ] }, { "uid": "uk-fps-reject:1160", "id": "1160", "rail": "uk-fps-reject", "kind": "reason-code", "name": "Payee account closed", "group": "account", "summary": "The account named for the payee has been closed. Both public sources agree on the meaning. The account existed and is reachable as a record, which is what separates this from an unknown sort code and account number.", "triggers": [ "The payee closed the account and did not tell the payer", "The payee moved bank and the switching redirection period has ended", "The receiving institution closed the account" ], "actions": [ "Payer: contact the payee for current account details before sending again", "Payee: tell anyone who pays you regularly when an account closes, because a standing order will keep failing" ], "retry": { "allowed": true, "rule": "Only with different account details. Sending the same payment again to a closed account will fail the same way. Nothing reached the payee, so there is nothing to return." }, "facts": { "return_windows": [ { "action": "rejection", "by": "Receiving FPS Institution", "deadline": "For each Faster Payment it receives, the receiving directly connected participant must answer within a few seconds with an unqualified acceptance, a qualified acceptance carrying a qualifier code, or a rejection carrying a rejection code. Pay.UK says the exact time is defined in the FPS Procedures and Technical Specifications, which it does not publish, so a few seconds is the only public figure. On the sending side the payer, where present, must be told the fate of the payment within 15 seconds." } ], "applies_to": "a Faster Payments credit push to any account type" }, "caveat": "Not an ISO 20022 code. Faster Payments runs on ISO 8583 and these numerics are Pay.UK's own, so never carry a meaning here from an ISO ExternalStatusReason value or from another rail's list. A rejection is also not a return: no money reached the payee, so there is nothing to send back. There is a matching return reason for a closed account: if the payment had already been accepted the money would come back as a Return Payment instead of being rejected.", "related": [ "uk-fps-reject:1114", "uk-fps-reject:1162" ], "basis": { "sources": "Listed as a Faster Payments reject code, with the meaning given here in Orca's own words, by two independent public sources on different hosts, both read 2026-09-20: LHV Connect's Faster Payment Reject Codes table (family B) and NatWest's Understanding Faster Payment Rejection and Reason Codes page (family A). Pay.UK's own list, in the FPS Procedures Appendix B section 8.2, was not consulted and is not published. The rejection mechanics come from Faster Payments System Principles v11 and Pay.UK's Certainty of Fate proposed rule clarification, also read 2026-09-20. Confidence is capped at medium because the governing authority's own text was not read.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: no public source read dates this code", "effective_to": null, "effective_note": "No public source read says when this code became permitted on Faster Payments [Unverified]. Pay.UK does not publish the code list; the two pages this record rests on were last updated within the year before they were read on 2026-09-20.", "source_edition": "The FPS Procedures, Appendix B, FPS Codes, were not consulted: Pay.UK makes the FPS rules and procedures available to participants' legal departments only, as its 2025 PFMI self-assessment states at key consideration 23.1. This record rests on two independent public sources on different hosts, LHV Connect's code reference tables and NatWest's support centre page, both read 2026-09-20, together with Pay.UK's own public documents for the mechanics.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "primary_not_public": true, "corroboration": [ { "source_url": "https://docs.lhv.com/home/connect/overview/code-reference-tables/payment-reject-codes", "source_class": "secondary", "source_title": "LHV Connect documentation, Payment Reject Codes", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms code 1160 as creditor account closed." }, { "source_url": "https://www.natwest.com/support-centre/bank-accounts-and-supporting-information/general/what-are-the-faster-payment-reject-and-reason-codes.html", "source_class": "secondary", "source_title": "NatWest support centre, Understanding Faster Payment Rejection and Reason Codes", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms code 1160 as a rejection because the beneficiary account has been closed, agreeing with the first family." } ] }, "rail_name": "Faster Payments Rejection Codes", "governing_authority": "Pay.UK Limited", "snapshot": "2026-09-20", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "not_public", "label": "the operator's own text", "needs": "what the operator's own text says, which Orca has not read", "detail": "Pay.UK Limited's own text is not the source for this code: it is not public, or not under terms Orca can use. It rests on 2 named public sources, so a term set by agreement rather than by a published rule is not Orca's to state.", "from": "currency.primary_not_public" } ] }, { "uid": "uk-fps-reject:1162", "id": "1162", "rail": "uk-fps-reject", "kind": "reason-code", "name": "Payee account name does not match the account number", "group": "account", "summary": "The name given for the payee does not match the name held on the account that the account number identifies. Both public sources agree. This is a name check made by the receiving institution when the payment arrives, and it is separate from Confirmation of Payee, which is an overlay the payer's side runs before the payment is sent.", "triggers": [ "The payer typed a shortened, married, trading or misspelled version of the account holder's name", "The payer has the right name for the wrong account, or the right account for the wrong person", "A business account is held in a registered name the payer does not know" ], "actions": [ "Payer: get the exact name on the account from the payee and use Confirmation of Payee before sending again", "Payer: treat a name mismatch on a payment you were pressed to make as a fraud warning, not a clerical problem" ], "retry": { "allowed": true, "rule": "Send again once the name is confirmed with the payee. Nothing reached the payee, so there is nothing to return." }, "facts": { "return_windows": [ { "action": "rejection", "by": "Receiving FPS Institution", "deadline": "For each Faster Payment it receives, the receiving directly connected participant must answer within a few seconds with an unqualified acceptance, a qualified acceptance carrying a qualifier code, or a rejection carrying a rejection code. Pay.UK says the exact time is defined in the FPS Procedures and Technical Specifications, which it does not publish, so a few seconds is the only public figure. On the sending side the payer, where present, must be told the fate of the payment within 15 seconds." } ], "applies_to": "a Faster Payments credit push to any account type" }, "caveat": "Not an ISO 20022 code. Faster Payments runs on ISO 8583 and these numerics are Pay.UK's own, so never carry a meaning here from an ISO ExternalStatusReason value or from another rail's list. A rejection is also not a return: no money reached the payee, so there is nothing to send back. Do not read this as a Confirmation of Payee result. Confirmation of Payee runs before the payment and returns one of four outcomes to the payer; this code comes back after the payment was sent.", "related": [ "uk-fps-reject:1171", "uk-fps-reject:1114" ], "basis": { "sources": "Listed as a Faster Payments reject code, with the meaning given here in Orca's own words, by two independent public sources on different hosts, both read 2026-09-20: LHV Connect's Faster Payment Reject Codes table (family B) and NatWest's Understanding Faster Payment Rejection and Reason Codes page (family A). Pay.UK's own list, in the FPS Procedures Appendix B section 8.2, was not consulted and is not published. The rejection mechanics come from Faster Payments System Principles v11 and Pay.UK's Certainty of Fate proposed rule clarification, also read 2026-09-20. Confidence is capped at medium because the governing authority's own text was not read.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: no public source read dates this code", "effective_to": null, "effective_note": "No public source read says when this code became permitted on Faster Payments [Unverified]. Pay.UK does not publish the code list; the two pages this record rests on were last updated within the year before they were read on 2026-09-20.", "source_edition": "The FPS Procedures, Appendix B, FPS Codes, were not consulted: Pay.UK makes the FPS rules and procedures available to participants' legal departments only, as its 2025 PFMI self-assessment states at key consideration 23.1. This record rests on two independent public sources on different hosts, LHV Connect's code reference tables and NatWest's support centre page, both read 2026-09-20, together with Pay.UK's own public documents for the mechanics.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "primary_not_public": true, "corroboration": [ { "source_url": "https://docs.lhv.com/home/connect/overview/code-reference-tables/payment-reject-codes", "source_class": "secondary", "source_title": "LHV Connect documentation, Payment Reject Codes", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms code 1162 as creditor account name does not match creditor account number." }, { "source_url": "https://www.natwest.com/support-centre/bank-accounts-and-supporting-information/general/what-are-the-faster-payment-reject-and-reason-codes.html", "source_class": "secondary", "source_title": "NatWest support centre, Understanding Faster Payment Rejection and Reason Codes", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms code 1162 as a rejection because the beneficiary account name does not match the beneficiary account number, agreeing with the first family." } ] }, "rail_name": "Faster Payments Rejection Codes", "governing_authority": "Pay.UK Limited", "snapshot": "2026-09-20", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "not_public", "label": "the operator's own text", "needs": "what the operator's own text says, which Orca has not read", "detail": "Pay.UK Limited's own text is not the source for this code: it is not public, or not under terms Orca can use. It rests on 2 named public sources, so a term set by agreement rather than by a published rule is not Orca's to state.", "from": "currency.primary_not_public" } ] }, { "uid": "uk-fps-reject:1163", "id": "1163", "rail": "uk-fps-reject", "kind": "reason-code", "name": "The account cannot be identified without the reference field", "group": "administrative", "summary": "The sort code and account number reach a pooled or intermediary account, and the receiving side cannot tell which underlying customer account the money is for without the reference. Both public sources agree on the meaning. This is the credit card, building society roll number and utility account case.", "triggers": [ "The payer left the reference blank on a payment to a credit card, a building society account or a utility", "The payee's account is addressable only by secondary reference data and the payer did not supply it" ], "actions": [ "Payer: get the exact reference from the payee, for example the long card number or the roll number, and send again with it in the reference field", "Payee: state on your invoices that a reference is required and what it must be" ], "retry": { "allowed": true, "rule": "Send again with the reference filled in. Nothing reached the payee, so there is nothing to return." }, "facts": { "return_windows": [ { "action": "rejection", "by": "Receiving FPS Institution", "deadline": "For each Faster Payment it receives, the receiving directly connected participant must answer within a few seconds with an unqualified acceptance, a qualified acceptance carrying a qualifier code, or a rejection carrying a rejection code. Pay.UK says the exact time is defined in the FPS Procedures and Technical Specifications, which it does not publish, so a few seconds is the only public figure. On the sending side the payer, where present, must be told the fate of the payment within 15 seconds." } ], "applies_to": "a Faster Payments credit push to any account type, in practice to accounts reachable only through secondary reference data" }, "caveat": "Not an ISO 20022 code. Faster Payments runs on ISO 8583 and these numerics are Pay.UK's own, so never carry a meaning here from an ISO ExternalStatusReason value or from another rail's list. A rejection is also not a return: no money reached the payee, so there is nothing to send back. Reference information is capped at 18 characters in the field Pay.UK names for it, so a long reference may not fit and may need to be agreed with the payee.", "related": [ "uk-fps-reject:1164" ], "basis": { "sources": "Listed as a Faster Payments reject code, with the meaning given here in Orca's own words, by two independent public sources on different hosts, both read 2026-09-20: LHV Connect's Faster Payment Reject Codes table (family B) and NatWest's Understanding Faster Payment Rejection and Reason Codes page (family A). Pay.UK's own list, in the FPS Procedures Appendix B section 8.2, was not consulted and is not published. The rejection mechanics come from Faster Payments System Principles v11 and Pay.UK's Certainty of Fate proposed rule clarification, also read 2026-09-20. Confidence is capped at medium because the governing authority's own text was not read.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: no public source read dates this code", "effective_to": null, "effective_note": "No public source read says when this code became permitted on Faster Payments [Unverified]. Pay.UK does not publish the code list; the two pages this record rests on were last updated within the year before they were read on 2026-09-20.", "source_edition": "The FPS Procedures, Appendix B, FPS Codes, were not consulted: Pay.UK makes the FPS rules and procedures available to participants' legal departments only, as its 2025 PFMI self-assessment states at key consideration 23.1. This record rests on two independent public sources on different hosts, LHV Connect's code reference tables and NatWest's support centre page, both read 2026-09-20, together with Pay.UK's own public documents for the mechanics.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "primary_not_public": true, "corroboration": [ { "source_url": "https://docs.lhv.com/home/connect/overview/code-reference-tables/payment-reject-codes", "source_class": "secondary", "source_title": "LHV Connect documentation, Payment Reject Codes", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms code 1163 as the account cannot be identified without data in the reference information field." }, { "source_url": "https://www.natwest.com/support-centre/bank-accounts-and-supporting-information/general/what-are-the-faster-payment-reject-and-reason-codes.html", "source_class": "secondary", "source_title": "NatWest support centre, Understanding Faster Payment Rejection and Reason Codes", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms code 1163 as a rejection because the receiving account cannot be identified without a payee reference, agreeing with the first family." } ] }, "rail_name": "Faster Payments Rejection Codes", "governing_authority": "Pay.UK Limited", "snapshot": "2026-09-20", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "not_public", "label": "the operator's own text", "needs": "what the operator's own text says, which Orca has not read", "detail": "Pay.UK Limited's own text is not the source for this code: it is not public, or not under terms Orca can use. It rests on 2 named public sources, so a term set by agreement rather than by a published rule is not Orca's to state.", "from": "currency.primary_not_public" } ] }, { "uid": "uk-fps-reject:1164", "id": "1164", "rail": "uk-fps-reject", "kind": "reason-code", "name": "The reference is wrong", "group": "administrative", "summary": "A reference was supplied but it is not right for the account. Both public sources agree. The difference from a missing reference is that something was given and it did not match, so the payer usually has the wrong number rather than none.", "triggers": [ "The payer used an old card number, an old roll number or a customer number that has changed", "The payer put a name, an invoice number or free text where the payee needs a structured reference", "The reference was truncated to fit the field" ], "actions": [ "Payer: check the reference against the payee's own statement or invoice and send again", "Payer: watch the length, because the reference field Pay.UK names carries up to 18 characters" ], "retry": { "allowed": true, "rule": "Send again with the corrected reference. Nothing reached the payee, so there is nothing to return." }, "facts": { "return_windows": [ { "action": "rejection", "by": "Receiving FPS Institution", "deadline": "For each Faster Payment it receives, the receiving directly connected participant must answer within a few seconds with an unqualified acceptance, a qualified acceptance carrying a qualifier code, or a rejection carrying a rejection code. Pay.UK says the exact time is defined in the FPS Procedures and Technical Specifications, which it does not publish, so a few seconds is the only public figure. On the sending side the payer, where present, must be told the fate of the payment within 15 seconds." } ], "applies_to": "a Faster Payments credit push to any account type, in practice to accounts reachable only through secondary reference data" }, "caveat": "Not an ISO 20022 code. Faster Payments runs on ISO 8583 and these numerics are Pay.UK's own, so never carry a meaning here from an ISO ExternalStatusReason value or from another rail's list. A rejection is also not a return: no money reached the payee, so there is nothing to send back. A wrong reference is not the same as a missing one, and a separate code covers the missing case.", "related": [ "uk-fps-reject:1163" ], "basis": { "sources": "Listed as a Faster Payments reject code, with the meaning given here in Orca's own words, by two independent public sources on different hosts, both read 2026-09-20: LHV Connect's Faster Payment Reject Codes table (family B) and NatWest's Understanding Faster Payment Rejection and Reason Codes page (family A). Pay.UK's own list, in the FPS Procedures Appendix B section 8.2, was not consulted and is not published. The rejection mechanics come from Faster Payments System Principles v11 and Pay.UK's Certainty of Fate proposed rule clarification, also read 2026-09-20. Confidence is capped at medium because the governing authority's own text was not read.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: no public source read dates this code", "effective_to": null, "effective_note": "No public source read says when this code became permitted on Faster Payments [Unverified]. Pay.UK does not publish the code list; the two pages this record rests on were last updated within the year before they were read on 2026-09-20.", "source_edition": "The FPS Procedures, Appendix B, FPS Codes, were not consulted: Pay.UK makes the FPS rules and procedures available to participants' legal departments only, as its 2025 PFMI self-assessment states at key consideration 23.1. This record rests on two independent public sources on different hosts, LHV Connect's code reference tables and NatWest's support centre page, both read 2026-09-20, together with Pay.UK's own public documents for the mechanics.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "primary_not_public": true, "corroboration": [ { "source_url": "https://docs.lhv.com/home/connect/overview/code-reference-tables/payment-reject-codes", "source_class": "secondary", "source_title": "LHV Connect documentation, Payment Reject Codes", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms code 1164 as reference information is incorrect." }, { "source_url": "https://www.natwest.com/support-centre/bank-accounts-and-supporting-information/general/what-are-the-faster-payment-reject-and-reason-codes.html", "source_class": "secondary", "source_title": "NatWest support centre, Understanding Faster Payment Rejection and Reason Codes", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms code 1164 as a rejection due to the reference information field being incorrect, agreeing with the first family." } ] }, "rail_name": "Faster Payments Rejection Codes", "governing_authority": "Pay.UK Limited", "snapshot": "2026-09-20", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "not_public", "label": "the operator's own text", "needs": "what the operator's own text says, which Orca has not read", "detail": "Pay.UK Limited's own text is not the source for this code: it is not public, or not under terms Orca can use. It rests on 2 named public sources, so a term set by agreement rather than by a published rule is not Orca's to state.", "from": "currency.primary_not_public" } ] }, { "uid": "uk-fps-reject:1165", "id": "1165", "rail": "uk-fps-reject", "kind": "reason-code", "name": "The account is not held in the currency sent", "group": "account", "summary": "The payee's account is not denominated in the currency of the payment. Both public sources agree. Faster Payments carries sterling only, so in practice the account cannot take sterling.", "triggers": [ "The payee's account is held in a currency other than sterling", "The payer sent to a foreign currency account at a United Kingdom institution" ], "actions": [ "Payer: ask the payee for sterling account details, or use a route built for cross currency payments", "Payee: give a sterling account to anyone paying you by Faster Payments" ], "retry": { "allowed": false, "rule": "Do not send the same payment again. Faster Payments carries sterling only, so a retry to the same account will fail the same way. Nothing reached the payee, so there is nothing to return." }, "facts": { "return_windows": [ { "action": "rejection", "by": "Receiving FPS Institution", "deadline": "For each Faster Payment it receives, the receiving directly connected participant must answer within a few seconds with an unqualified acceptance, a qualified acceptance carrying a qualifier code, or a rejection carrying a rejection code. Pay.UK says the exact time is defined in the FPS Procedures and Technical Specifications, which it does not publish, so a few seconds is the only public figure. On the sending side the payer, where present, must be told the fate of the payment within 15 seconds." } ], "applies_to": "a Faster Payments credit push to any account type" }, "caveat": "Not an ISO 20022 code. Faster Payments runs on ISO 8583 and these numerics are Pay.UK's own, so never carry a meaning here from an ISO ExternalStatusReason value or from another rail's list. A rejection is also not a return: no money reached the payee, so there is nothing to send back. Faster Payments is sterling only, so this is about the payee's account rather than about the payment carrying another currency.", "related": [ "uk-fps-reject:1170" ], "basis": { "sources": "Listed as a Faster Payments reject code, with the meaning given here in Orca's own words, by two independent public sources on different hosts, both read 2026-09-20: LHV Connect's Faster Payment Reject Codes table (family B) and NatWest's Understanding Faster Payment Rejection and Reason Codes page (family A). Pay.UK's own list, in the FPS Procedures Appendix B section 8.2, was not consulted and is not published. The rejection mechanics come from Faster Payments System Principles v11 and Pay.UK's Certainty of Fate proposed rule clarification, also read 2026-09-20. Confidence is capped at medium because the governing authority's own text was not read.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: no public source read dates this code", "effective_to": null, "effective_note": "No public source read says when this code became permitted on Faster Payments [Unverified]. Pay.UK does not publish the code list; the two pages this record rests on were last updated within the year before they were read on 2026-09-20.", "source_edition": "The FPS Procedures, Appendix B, FPS Codes, were not consulted: Pay.UK makes the FPS rules and procedures available to participants' legal departments only, as its 2025 PFMI self-assessment states at key consideration 23.1. This record rests on two independent public sources on different hosts, LHV Connect's code reference tables and NatWest's support centre page, both read 2026-09-20, together with Pay.UK's own public documents for the mechanics.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "primary_not_public": true, "corroboration": [ { "source_url": "https://docs.lhv.com/home/connect/overview/code-reference-tables/payment-reject-codes", "source_class": "secondary", "source_title": "LHV Connect documentation, Payment Reject Codes", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms code 1165 as the account is not in currency quoted." }, { "source_url": "https://www.natwest.com/support-centre/bank-accounts-and-supporting-information/general/what-are-the-faster-payment-reject-and-reason-codes.html", "source_class": "secondary", "source_title": "NatWest support centre, Understanding Faster Payment Rejection and Reason Codes", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms code 1165 as a rejection because the receiving account is not in the currency quoted, agreeing with the first family." } ] }, "rail_name": "Faster Payments Rejection Codes", "governing_authority": "Pay.UK Limited", "snapshot": "2026-09-20", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "not_public", "label": "the operator's own text", "needs": "what the operator's own text says, which Orca has not read", "detail": "Pay.UK Limited's own text is not the source for this code: it is not public, or not under terms Orca can use. It rests on 2 named public sources, so a term set by agreement rather than by a published rule is not Orca's to state.", "from": "currency.primary_not_public" } ] }, { "uid": "uk-fps-reject:1170", "id": "1170", "rail": "uk-fps-reject", "kind": "reason-code", "name": "The account's terms do not allow this credit", "group": "administrative", "summary": "The account exists and can be identified, but its own terms and conditions do not permit money to be credited to it this way. Both public sources agree. It is a product restriction rather than a fault in the payment: a savings or tax advantaged account with subscription rules, a loan or mortgage account that takes payments only by another route, or an account restricted to credits from a named source.", "triggers": [ "The payee's account is a product that takes credits only from a particular source or by a particular method", "A tax advantaged or subscription limited account cannot accept a further credit", "The account is restricted so that only the holder may pay into it" ], "actions": [ "Payer: ask the payee which account and which method to use instead", "Payee: tell payers when an account cannot accept a Faster Payment, because the payment will keep failing" ], "retry": { "allowed": false, "rule": "Not to the same account. The restriction is in the account's terms and will not change on a retry. Nothing reached the payee, so there is nothing to return." }, "facts": { "return_windows": [ { "action": "rejection", "by": "Receiving FPS Institution", "deadline": "For each Faster Payment it receives, the receiving directly connected participant must answer within a few seconds with an unqualified acceptance, a qualified acceptance carrying a qualifier code, or a rejection carrying a rejection code. Pay.UK says the exact time is defined in the FPS Procedures and Technical Specifications, which it does not publish, so a few seconds is the only public figure. On the sending side the payer, where present, must be told the fate of the payment within 15 seconds." } ], "applies_to": "a Faster Payments credit push to any account type" }, "caveat": "Not an ISO 20022 code. Faster Payments runs on ISO 8583 and these numerics are Pay.UK's own, so never carry a meaning here from an ISO ExternalStatusReason value or from another rail's list. A rejection is also not a return: no money reached the payee, so there is nothing to send back. This says nothing about whether the payer or the payee did anything wrong. It is a restriction on the receiving product.", "related": [ "uk-fps-reject:1165" ], "basis": { "sources": "Listed as a Faster Payments reject code, with the meaning given here in Orca's own words, by two independent public sources on different hosts, both read 2026-09-20: LHV Connect's Faster Payment Reject Codes table (family B) and NatWest's Understanding Faster Payment Rejection and Reason Codes page (family A). Pay.UK's own list, in the FPS Procedures Appendix B section 8.2, was not consulted and is not published. The rejection mechanics come from Faster Payments System Principles v11 and Pay.UK's Certainty of Fate proposed rule clarification, also read 2026-09-20. Confidence is capped at medium because the governing authority's own text was not read.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: no public source read dates this code", "effective_to": null, "effective_note": "No public source read says when this code became permitted on Faster Payments [Unverified]. Pay.UK does not publish the code list; the two pages this record rests on were last updated within the year before they were read on 2026-09-20.", "source_edition": "The FPS Procedures, Appendix B, FPS Codes, were not consulted: Pay.UK makes the FPS rules and procedures available to participants' legal departments only, as its 2025 PFMI self-assessment states at key consideration 23.1. This record rests on two independent public sources on different hosts, LHV Connect's code reference tables and NatWest's support centre page, both read 2026-09-20, together with Pay.UK's own public documents for the mechanics.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "primary_not_public": true, "corroboration": [ { "source_url": "https://docs.lhv.com/home/connect/overview/code-reference-tables/payment-reject-codes", "source_class": "secondary", "source_title": "LHV Connect documentation, Payment Reject Codes", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms code 1170 as terms and conditions of account do not permit crediting of these funds." }, { "source_url": "https://www.natwest.com/support-centre/bank-accounts-and-supporting-information/general/what-are-the-faster-payment-reject-and-reason-codes.html", "source_class": "secondary", "source_title": "NatWest support centre, Understanding Faster Payment Rejection and Reason Codes", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms code 1170 as a rejection because the terms and conditions of the payee account do not permit crediting of these funds, agreeing with the first family." } ] }, "rail_name": "Faster Payments Rejection Codes", "governing_authority": "Pay.UK Limited", "snapshot": "2026-09-20", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "not_public", "label": "the operator's own text", "needs": "what the operator's own text says, which Orca has not read", "detail": "Pay.UK Limited's own text is not the source for this code: it is not public, or not under terms Orca can use. It rests on 2 named public sources, so a term set by agreement rather than by a published rule is not Orca's to state.", "from": "currency.primary_not_public" } ] }, { "uid": "uk-fps-reject:1171", "id": "1171", "rail": "uk-fps-reject", "kind": "reason-code", "name": "The payee name is missing", "group": "administrative", "summary": "No name was given for the payee. Both public sources agree. Pay.UK requires the sender to quote the payee's sort code, account number and name on every payment, so this is a payment that should not have been submitted in that state.", "triggers": [ "The payee name field was left empty by the payer or by the sending system", "An automated or file based submission dropped the name" ], "actions": [ "Payer: supply the payee's name and send again", "Sending institution: check the submission path, because Pay.UK requires the payee's name on every payment" ], "retry": { "allowed": true, "rule": "Send again with the payee's name present. Nothing reached the payee, so there is nothing to return." }, "facts": { "return_windows": [ { "action": "rejection", "by": "Receiving FPS Institution", "deadline": "For each Faster Payment it receives, the receiving directly connected participant must answer within a few seconds with an unqualified acceptance, a qualified acceptance carrying a qualifier code, or a rejection carrying a rejection code. Pay.UK says the exact time is defined in the FPS Procedures and Technical Specifications, which it does not publish, so a few seconds is the only public figure. On the sending side the payer, where present, must be told the fate of the payment within 15 seconds." } ], "applies_to": "a Faster Payments credit push to any account type" }, "caveat": "Not an ISO 20022 code. Faster Payments runs on ISO 8583 and these numerics are Pay.UK's own, so never carry a meaning here from an ISO ExternalStatusReason value or from another rail's list. A rejection is also not a return: no money reached the payee, so there is nothing to send back. A missing name is not a mismatched name; a separate code covers a name that does not match the account number.", "related": [ "uk-fps-reject:1162" ], "basis": { "sources": "Listed as a Faster Payments reject code, with the meaning given here in Orca's own words, by two independent public sources on different hosts, both read 2026-09-20: LHV Connect's Faster Payment Reject Codes table (family B) and NatWest's Understanding Faster Payment Rejection and Reason Codes page (family A). Pay.UK's own list, in the FPS Procedures Appendix B section 8.2, was not consulted and is not published. The rejection mechanics come from Faster Payments System Principles v11 and Pay.UK's Certainty of Fate proposed rule clarification, also read 2026-09-20. Confidence is capped at medium because the governing authority's own text was not read.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: no public source read dates this code", "effective_to": null, "effective_note": "No public source read says when this code became permitted on Faster Payments [Unverified]. Pay.UK does not publish the code list; the two pages this record rests on were last updated within the year before they were read on 2026-09-20.", "source_edition": "The FPS Procedures, Appendix B, FPS Codes, were not consulted: Pay.UK makes the FPS rules and procedures available to participants' legal departments only, as its 2025 PFMI self-assessment states at key consideration 23.1. This record rests on two independent public sources on different hosts, LHV Connect's code reference tables and NatWest's support centre page, both read 2026-09-20, together with Pay.UK's own public documents for the mechanics.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "primary_not_public": true, "corroboration": [ { "source_url": "https://docs.lhv.com/home/connect/overview/code-reference-tables/payment-reject-codes", "source_class": "secondary", "source_title": "LHV Connect documentation, Payment Reject Codes", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms code 1171 as creditor account name not present." }, { "source_url": "https://www.natwest.com/support-centre/bank-accounts-and-supporting-information/general/what-are-the-faster-payment-reject-and-reason-codes.html", "source_class": "secondary", "source_title": "NatWest support centre, Understanding Faster Payment Rejection and Reason Codes", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms code 1171 as a rejection because the beneficiary name is not present, agreeing with the first family." } ] }, "rail_name": "Faster Payments Rejection Codes", "governing_authority": "Pay.UK Limited", "snapshot": "2026-09-20", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "not_public", "label": "the operator's own text", "needs": "what the operator's own text says, which Orca has not read", "detail": "Pay.UK Limited's own text is not the source for this code: it is not public, or not under terms Orca can use. It rests on 2 named public sources, so a term set by agreement rather than by a published rule is not Orca's to state.", "from": "currency.primary_not_public" } ] }, { "uid": "uk-fps-return:00000001", "id": "00000001", "rail": "uk-fps-return", "kind": "reason-code", "name": "Sort code and account number do not identify a known account", "group": "account", "summary": "The payment was accepted and then the sort code and account number turned out not to identify an account the receiving side can credit, so the money is being sent back. Both public sources agree on the meaning.", "triggers": [ "The account number does not exist at the sort code quoted", "The payment was accepted on a check that did not reach the underlying account" ], "actions": [ "Payer: confirm the sort code and account number with the payee before sending again, and use Confirmation of Payee where it is offered", "Payer: expect the money back in your own account, not a credit at the payee" ], "retry": { "allowed": true, "rule": "Send a new payment once the details are corrected. The returned funds arrive as a separate credit; do not treat the return as a cancellation of the first payment." }, "facts": { "return_windows": [ { "action": "return Payment", "by": "Receiving FPS Institution", "deadline": "A Return Payment must be sent within one to three working days of the original payment. Which of those it is depends on the answer the receiving directly connected participant gave to the original payment. Pay.UK's public guide states the range and does not say which answer maps to which deadline; that sits in the FPS Procedures, which Pay.UK does not publish." } ], "applies_to": "a Faster Payments credit push to any account type, returned after acceptance" }, "caveat": "A return on this rail is a fresh credit push back to the sending institution, referencing the original payment. Nothing is reversed, the payee is not debited by the scheme, and the money reaches the payer's bank rather than the payer directly. Not an ISO 20022 code either: these eight digit numerics are Pay.UK's own, so never carry a meaning here from an ISO ExternalStatusReason value or another rail. There is a matching rejection code for the same fault caught before acceptance, in which case no money moves at all.", "related": [ "uk-fps-return:00000002", "uk-fps-return:00000006" ], "basis": { "sources": "Listed as a Faster Payments return reason, with the meaning given here in Orca's own words, by two independent public sources on different hosts, both read 2026-09-20: LHV Connect's Faster Payment Return Codes table (family B) and NatWest's Understanding Faster Payment Rejection and Reason Codes page (family A). Pay.UK's own list was not consulted and is not published. The return mechanics come from Faster Payments System Principles v11 and Pay.UK's Certainty of Fate proposed rule clarification, also read 2026-09-20. Confidence is capped at medium because the governing authority's own text was not read.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: no public source read dates this code", "effective_to": null, "effective_note": "No public source read says when this code became permitted on Faster Payments [Unverified]. Pay.UK does not publish the code list; the two pages this record rests on were last updated within the year before they were read on 2026-09-20.", "source_edition": "The FPS Procedures, Appendix B, FPS Codes, were not consulted: Pay.UK makes the FPS rules and procedures available to participants' legal departments only, as its 2025 PFMI self-assessment states at key consideration 23.1. This record rests on two independent public sources on different hosts, LHV Connect's code reference tables and NatWest's support centre page, both read 2026-09-20, together with Pay.UK's own public documents for the mechanics.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "primary_not_public": true, "corroboration": [ { "source_url": "https://docs.lhv.com/home/connect/overview/code-reference-tables/payment-return-codes", "source_class": "secondary", "source_title": "LHV Connect documentation, Payment Return Codes", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms return code 00000001 as creditor sort code or account number unknown." }, { "source_url": "https://www.natwest.com/support-centre/bank-accounts-and-supporting-information/general/what-are-the-faster-payment-reject-and-reason-codes.html", "source_class": "secondary", "source_title": "NatWest support centre, Understanding Faster Payment Rejection and Reason Codes", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms return code 00000001 as a return for an invalid sort code and account number combination, agreeing with the first family." } ] }, "rail_name": "Faster Payments Return Reasons", "governing_authority": "Pay.UK Limited", "snapshot": "2026-09-20", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "not_public", "label": "the operator's own text", "needs": "what the operator's own text says, which Orca has not read", "detail": "Pay.UK Limited's own text is not the source for this code: it is not public, or not under terms Orca can use. It rests on 2 named public sources, so a term set by agreement rather than by a published rule is not Orca's to state.", "from": "currency.primary_not_public" } ] }, { "uid": "uk-fps-return:00000002", "id": "00000002", "rail": "uk-fps-return", "kind": "reason-code", "name": "Payee account closed", "group": "account", "summary": "The account named for the payee has been closed, so the money is being sent back. Both public sources agree.", "triggers": [ "The payee closed the account between setting up the payment and receiving it", "A standing order kept running after the payee's account closed", "The receiving institution closed the account" ], "actions": [ "Payer: get current account details from the payee and cancel or amend any standing order pointing at the closed account", "Payee: tell anyone who pays you regularly when an account closes" ], "retry": { "allowed": true, "rule": "Only with different account details. A retry to the same closed account will come back the same way." }, "facts": { "return_windows": [ { "action": "return Payment", "by": "Receiving FPS Institution", "deadline": "A Return Payment must be sent within one to three working days of the original payment. Which of those it is depends on the answer the receiving directly connected participant gave to the original payment. Pay.UK's public guide states the range and does not say which answer maps to which deadline; that sits in the FPS Procedures, which Pay.UK does not publish." } ], "applies_to": "a Faster Payments credit push to any account type, returned after acceptance" }, "caveat": "A return on this rail is a fresh credit push back to the sending institution, referencing the original payment. Nothing is reversed, the payee is not debited by the scheme, and the money reaches the payer's bank rather than the payer directly. Not an ISO 20022 code either: these eight digit numerics are Pay.UK's own, so never carry a meaning here from an ISO ExternalStatusReason value or another rail. There is a matching rejection code for a closed account caught before acceptance.", "related": [ "uk-fps-return:00000001", "uk-fps-return:00000010" ], "basis": { "sources": "Listed as a Faster Payments return reason, with the meaning given here in Orca's own words, by two independent public sources on different hosts, both read 2026-09-20: LHV Connect's Faster Payment Return Codes table (family B) and NatWest's Understanding Faster Payment Rejection and Reason Codes page (family A). Pay.UK's own list was not consulted and is not published. The return mechanics come from Faster Payments System Principles v11 and Pay.UK's Certainty of Fate proposed rule clarification, also read 2026-09-20. Confidence is capped at medium because the governing authority's own text was not read.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: no public source read dates this code", "effective_to": null, "effective_note": "No public source read says when this code became permitted on Faster Payments [Unverified]. Pay.UK does not publish the code list; the two pages this record rests on were last updated within the year before they were read on 2026-09-20.", "source_edition": "The FPS Procedures, Appendix B, FPS Codes, were not consulted: Pay.UK makes the FPS rules and procedures available to participants' legal departments only, as its 2025 PFMI self-assessment states at key consideration 23.1. This record rests on two independent public sources on different hosts, LHV Connect's code reference tables and NatWest's support centre page, both read 2026-09-20, together with Pay.UK's own public documents for the mechanics.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "primary_not_public": true, "corroboration": [ { "source_url": "https://docs.lhv.com/home/connect/overview/code-reference-tables/payment-return-codes", "source_class": "secondary", "source_title": "LHV Connect documentation, Payment Return Codes", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms return code 00000002 as creditor account closed." }, { "source_url": "https://www.natwest.com/support-centre/bank-accounts-and-supporting-information/general/what-are-the-faster-payment-reject-and-reason-codes.html", "source_class": "secondary", "source_title": "NatWest support centre, Understanding Faster Payment Rejection and Reason Codes", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms return code 00000002 as a return because the beneficiary account has been closed, agreeing with the first family." } ] }, "rail_name": "Faster Payments Return Reasons", "governing_authority": "Pay.UK Limited", "snapshot": "2026-09-20", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "not_public", "label": "the operator's own text", "needs": "what the operator's own text says, which Orca has not read", "detail": "Pay.UK Limited's own text is not the source for this code: it is not public, or not under terms Orca can use. It rests on 2 named public sources, so a term set by agreement rather than by a published rule is not Orca's to state.", "from": "currency.primary_not_public" } ] }, { "uid": "uk-fps-return:00000005", "id": "00000005", "rail": "uk-fps-return", "kind": "reason-code", "name": "The account cannot be identified without the reference field", "group": "administrative", "summary": "The sort code and account number reach a pooled or intermediary account and the receiving side cannot tell which underlying customer account the money is for, so it is being sent back. Both public sources agree on the meaning. This is the credit card, building society roll number and utility case.", "triggers": [ "The payer left the reference blank on a payment to an account addressable only by secondary reference data", "The reference was stripped somewhere between the payer's channel and the receiving side" ], "actions": [ "Payer: get the exact reference from the payee, for example the long card number or the roll number, and send again with it in the reference field", "Payee: state on your invoices that a reference is required and what it must be" ], "retry": { "allowed": true, "rule": "Send again with the reference filled in, once the returned funds are back." }, "facts": { "return_windows": [ { "action": "return Payment", "by": "Receiving FPS Institution", "deadline": "A Return Payment must be sent within one to three working days of the original payment. Which of those it is depends on the answer the receiving directly connected participant gave to the original payment. Pay.UK's public guide states the range and does not say which answer maps to which deadline; that sits in the FPS Procedures, which Pay.UK does not publish." } ], "applies_to": "a Faster Payments credit push to any account type, returned after acceptance, in practice to accounts reachable only through secondary reference data" }, "caveat": "A return on this rail is a fresh credit push back to the sending institution, referencing the original payment. Nothing is reversed, the payee is not debited by the scheme, and the money reaches the payer's bank rather than the payer directly. Not an ISO 20022 code either: these eight digit numerics are Pay.UK's own, so never carry a meaning here from an ISO ExternalStatusReason value or another rail. Reference information is capped at 18 characters in the field Pay.UK names for it.", "related": [ "uk-fps-return:00000001", "uk-fps-return:00000006" ], "basis": { "sources": "Listed as a Faster Payments return reason, with the meaning given here in Orca's own words, by two independent public sources on different hosts, both read 2026-09-20: LHV Connect's Faster Payment Return Codes table (family B) and NatWest's Understanding Faster Payment Rejection and Reason Codes page (family A). Pay.UK's own list was not consulted and is not published. The return mechanics come from Faster Payments System Principles v11 and Pay.UK's Certainty of Fate proposed rule clarification, also read 2026-09-20. Confidence is capped at medium because the governing authority's own text was not read.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: no public source read dates this code", "effective_to": null, "effective_note": "No public source read says when this code became permitted on Faster Payments [Unverified]. Pay.UK does not publish the code list; the two pages this record rests on were last updated within the year before they were read on 2026-09-20.", "source_edition": "The FPS Procedures, Appendix B, FPS Codes, were not consulted: Pay.UK makes the FPS rules and procedures available to participants' legal departments only, as its 2025 PFMI self-assessment states at key consideration 23.1. This record rests on two independent public sources on different hosts, LHV Connect's code reference tables and NatWest's support centre page, both read 2026-09-20, together with Pay.UK's own public documents for the mechanics.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "primary_not_public": true, "corroboration": [ { "source_url": "https://docs.lhv.com/home/connect/overview/code-reference-tables/payment-return-codes", "source_class": "secondary", "source_title": "LHV Connect documentation, Payment Return Codes", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms return code 00000005 as account cannot be identified without data in the reference field." }, { "source_url": "https://www.natwest.com/support-centre/bank-accounts-and-supporting-information/general/what-are-the-faster-payment-reject-and-reason-codes.html", "source_class": "secondary", "source_title": "NatWest support centre, Understanding Faster Payment Rejection and Reason Codes", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms return code 00000005 as a return because the receiving account cannot be identified without a payee reference, agreeing with the first family." } ] }, "rail_name": "Faster Payments Return Reasons", "governing_authority": "Pay.UK Limited", "snapshot": "2026-09-20", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "not_public", "label": "the operator's own text", "needs": "what the operator's own text says, which Orca has not read", "detail": "Pay.UK Limited's own text is not the source for this code: it is not public, or not under terms Orca can use. It rests on 2 named public sources, so a term set by agreement rather than by a published rule is not Orca's to state.", "from": "currency.primary_not_public" } ] }, { "uid": "uk-fps-return:00000006", "id": "00000006", "rail": "uk-fps-return", "kind": "reason-code", "name": "Payee account name does not match the account number", "group": "account", "summary": "The name given for the payee does not match the name held on the account the account number identifies, so the money is being sent back. Both public sources agree. It is a name check the receiving institution makes, separate from Confirmation of Payee, which runs on the payer's side before the payment.", "triggers": [ "The payer used a shortened, married, trading or misspelled version of the account holder's name", "The payer has the right name for the wrong account, or the right account for the wrong person" ], "actions": [ "Payer: get the exact name on the account from the payee and use Confirmation of Payee before sending again", "Payer: treat a name mismatch on a payment you were pressed to make as a fraud warning" ], "retry": { "allowed": true, "rule": "Send again once the name is confirmed with the payee." }, "facts": { "return_windows": [ { "action": "return Payment", "by": "Receiving FPS Institution", "deadline": "A Return Payment must be sent within one to three working days of the original payment. Which of those it is depends on the answer the receiving directly connected participant gave to the original payment. Pay.UK's public guide states the range and does not say which answer maps to which deadline; that sits in the FPS Procedures, which Pay.UK does not publish." } ], "applies_to": "a Faster Payments credit push to any account type, returned after acceptance" }, "caveat": "A return on this rail is a fresh credit push back to the sending institution, referencing the original payment. Nothing is reversed, the payee is not debited by the scheme, and the money reaches the payer's bank rather than the payer directly. Not an ISO 20022 code either: these eight digit numerics are Pay.UK's own, so never carry a meaning here from an ISO ExternalStatusReason value or another rail. Do not read this as a Confirmation of Payee result: that check runs before the payment and gives the payer one of four outcomes.", "related": [ "uk-fps-return:00000001", "uk-fps-return:00000005" ], "basis": { "sources": "Listed as a Faster Payments return reason, with the meaning given here in Orca's own words, by two independent public sources on different hosts, both read 2026-09-20: LHV Connect's Faster Payment Return Codes table (family B) and NatWest's Understanding Faster Payment Rejection and Reason Codes page (family A). Pay.UK's own list was not consulted and is not published. The return mechanics come from Faster Payments System Principles v11 and Pay.UK's Certainty of Fate proposed rule clarification, also read 2026-09-20. Confidence is capped at medium because the governing authority's own text was not read.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: no public source read dates this code", "effective_to": null, "effective_note": "No public source read says when this code became permitted on Faster Payments [Unverified]. Pay.UK does not publish the code list; the two pages this record rests on were last updated within the year before they were read on 2026-09-20.", "source_edition": "The FPS Procedures, Appendix B, FPS Codes, were not consulted: Pay.UK makes the FPS rules and procedures available to participants' legal departments only, as its 2025 PFMI self-assessment states at key consideration 23.1. This record rests on two independent public sources on different hosts, LHV Connect's code reference tables and NatWest's support centre page, both read 2026-09-20, together with Pay.UK's own public documents for the mechanics.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "primary_not_public": true, "corroboration": [ { "source_url": "https://docs.lhv.com/home/connect/overview/code-reference-tables/payment-return-codes", "source_class": "secondary", "source_title": "LHV Connect documentation, Payment Return Codes", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms return code 00000006 as creditor account name does not match creditor account number." }, { "source_url": "https://www.natwest.com/support-centre/bank-accounts-and-supporting-information/general/what-are-the-faster-payment-reject-and-reason-codes.html", "source_class": "secondary", "source_title": "NatWest support centre, Understanding Faster Payment Rejection and Reason Codes", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms return code 00000006 as a return because the beneficiary account name does not match the beneficiary account number, agreeing with the first family." } ] }, "rail_name": "Faster Payments Return Reasons", "governing_authority": "Pay.UK Limited", "snapshot": "2026-09-20", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "not_public", "label": "the operator's own text", "needs": "what the operator's own text says, which Orca has not read", "detail": "Pay.UK Limited's own text is not the source for this code: it is not public, or not under terms Orca can use. It rests on 2 named public sources, so a term set by agreement rather than by a published rule is not Orca's to state.", "from": "currency.primary_not_public" } ] }, { "uid": "uk-fps-return:00000007", "id": "00000007", "rail": "uk-fps-return", "kind": "reason-code", "name": "Return requested by the sender of the original payment", "group": "authorization", "summary": "The money is coming back because the party that sent the original payment asked for it back and the receiving side agreed. Both public sources agree on the meaning. This is the nearest thing Faster Payments has to a recall, and it is not a recall: the scheme has no recall message and no obligation on the receiving side to agree. What has happened is that the receiving institution chose to send a fresh payment back.", "triggers": [ "The payer told their bank straight away that they had paid the wrong account or the wrong amount", "A recovery process for a payment sent in error succeeded and the receiving side is returning the money", "The sending institution asked for the money back after spotting its own error" ], "actions": [ "Payer: ask your bank at once if you have paid the wrong account. Speed is what decides whether the money is still there, because the scheme gives you no right to it back", "Payer: do not assume this will work. Nothing in any public Pay.UK document read obliges the receiving bank to return the money" ], "retry": { "allowed": false, "rule": "This is not a payment to retry. It is money coming back at the sender's request. Send a fresh payment to the right account if that is what was intended." }, "facts": { "return_windows": [ { "action": "return Payment", "by": "Receiving FPS Institution", "deadline": "A Return Payment must be sent within one to three working days of the original payment. Which of those it is depends on the answer the receiving directly connected participant gave to the original payment. Pay.UK's public guide states the range and does not say which answer maps to which deadline; that sits in the FPS Procedures, which Pay.UK does not publish." } ], "applies_to": "a Faster Payments credit push to any account type, returned after acceptance at the original sender's request" }, "caveat": "A return on this rail is a fresh credit push back to the sending institution, referencing the original payment. Nothing is reversed, the payee is not debited by the scheme, and the money reaches the payer's bank rather than the payer directly. Not an ISO 20022 code either: these eight digit numerics are Pay.UK's own, so never carry a meaning here from an ISO ExternalStatusReason value or another rail. Do not read this reason as evidence of a recall right. Pay.UK states that a payment cannot be revoked or recalled once it has been sent to the central infrastructure and that the system has no revocation messaging capability. This reason records a return the receiving side chose to make.", "related": [ "uk-fps-return:00000009" ], "basis": { "sources": "Listed as a Faster Payments return reason, with the meaning given here in Orca's own words, by two independent public sources on different hosts, both read 2026-09-20: LHV Connect's Faster Payment Return Codes table (family B) and NatWest's Understanding Faster Payment Rejection and Reason Codes page (family A). Pay.UK's own list was not consulted and is not published. The return mechanics come from Faster Payments System Principles v11 and Pay.UK's Certainty of Fate proposed rule clarification, also read 2026-09-20. Confidence is capped at medium because the governing authority's own text was not read.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: no public source read dates this code", "effective_to": null, "effective_note": "No public source read says when this code became permitted on Faster Payments [Unverified]. Pay.UK does not publish the code list; the two pages this record rests on were last updated within the year before they were read on 2026-09-20.", "source_edition": "The FPS Procedures, Appendix B, FPS Codes, were not consulted: Pay.UK makes the FPS rules and procedures available to participants' legal departments only, as its 2025 PFMI self-assessment states at key consideration 23.1. This record rests on two independent public sources on different hosts, LHV Connect's code reference tables and NatWest's support centre page, both read 2026-09-20, together with Pay.UK's own public documents for the mechanics.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "primary_not_public": true, "corroboration": [ { "source_url": "https://docs.lhv.com/home/connect/overview/code-reference-tables/payment-return-codes", "source_class": "secondary", "source_title": "LHV Connect documentation, Payment Return Codes", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms return code 00000007 as return requested by the sender of the original payment." }, { "source_url": "https://www.natwest.com/support-centre/bank-accounts-and-supporting-information/general/what-are-the-faster-payment-reject-and-reason-codes.html", "source_class": "secondary", "source_title": "NatWest support centre, Understanding Faster Payment Rejection and Reason Codes", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms return code 00000007 as returned by the receiving bank at the request of the sender, agreeing with the first family." } ] }, "rail_name": "Faster Payments Return Reasons", "governing_authority": "Pay.UK Limited", "snapshot": "2026-09-20", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "not_public", "label": "the operator's own text", "needs": "what the operator's own text says, which Orca has not read", "detail": "Pay.UK Limited's own text is not the source for this code: it is not public, or not under terms Orca can use. It rests on 2 named public sources, so a term set by agreement rather than by a published rule is not Orca's to state.", "from": "currency.primary_not_public" } ] }, { "uid": "uk-fps-return:00000008", "id": "00000008", "rail": "uk-fps-return", "kind": "reason-code", "name": "The account is not held in the currency sent", "group": "account", "summary": "The payee's account is not denominated in the currency of the payment, so the money is being sent back. Both public sources agree. Faster Payments carries sterling only, so in practice the account cannot take sterling.", "triggers": [ "The payee's account is held in a currency other than sterling", "The payer sent to a foreign currency account at a United Kingdom institution" ], "actions": [ "Payer: ask the payee for sterling account details, or use a route built for cross currency payments", "Payee: give a sterling account to anyone paying you by Faster Payments" ], "retry": { "allowed": false, "rule": "Do not send the same payment again. Faster Payments carries sterling only, so it will come back the same way." }, "facts": { "return_windows": [ { "action": "return Payment", "by": "Receiving FPS Institution", "deadline": "A Return Payment must be sent within one to three working days of the original payment. Which of those it is depends on the answer the receiving directly connected participant gave to the original payment. Pay.UK's public guide states the range and does not say which answer maps to which deadline; that sits in the FPS Procedures, which Pay.UK does not publish." } ], "applies_to": "a Faster Payments credit push to any account type, returned after acceptance" }, "caveat": "A return on this rail is a fresh credit push back to the sending institution, referencing the original payment. Nothing is reversed, the payee is not debited by the scheme, and the money reaches the payer's bank rather than the payer directly. Not an ISO 20022 code either: these eight digit numerics are Pay.UK's own, so never carry a meaning here from an ISO ExternalStatusReason value or another rail. LHV's own page notes that this reason is not supported on one indirect access route it offers, which is a limitation of that access arrangement and not of the scheme.", "related": [ "uk-fps-return:00000010" ], "basis": { "sources": "Listed as a Faster Payments return reason, with the meaning given here in Orca's own words, by two independent public sources on different hosts, both read 2026-09-20: LHV Connect's Faster Payment Return Codes table (family B) and NatWest's Understanding Faster Payment Rejection and Reason Codes page (family A). Pay.UK's own list was not consulted and is not published. The return mechanics come from Faster Payments System Principles v11 and Pay.UK's Certainty of Fate proposed rule clarification, also read 2026-09-20. Confidence is capped at medium because the governing authority's own text was not read.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: no public source read dates this code", "effective_to": null, "effective_note": "No public source read says when this code became permitted on Faster Payments [Unverified]. Pay.UK does not publish the code list; the two pages this record rests on were last updated within the year before they were read on 2026-09-20.", "source_edition": "The FPS Procedures, Appendix B, FPS Codes, were not consulted: Pay.UK makes the FPS rules and procedures available to participants' legal departments only, as its 2025 PFMI self-assessment states at key consideration 23.1. This record rests on two independent public sources on different hosts, LHV Connect's code reference tables and NatWest's support centre page, both read 2026-09-20, together with Pay.UK's own public documents for the mechanics.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "primary_not_public": true, "corroboration": [ { "source_url": "https://docs.lhv.com/home/connect/overview/code-reference-tables/payment-return-codes", "source_class": "secondary", "source_title": "LHV Connect documentation, Payment Return Codes", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms return code 00000008 as the account is not in the currency quoted, noting this family's own caveat that the code is not supported on one indirect access route it offers." }, { "source_url": "https://www.natwest.com/support-centre/bank-accounts-and-supporting-information/general/what-are-the-faster-payment-reject-and-reason-codes.html", "source_class": "secondary", "source_title": "NatWest support centre, Understanding Faster Payment Rejection and Reason Codes", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms return code 00000008 as a return because the receiving account is not in the currency quoted, agreeing with the first family." } ] }, "rail_name": "Faster Payments Return Reasons", "governing_authority": "Pay.UK Limited", "snapshot": "2026-09-20", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "not_public", "label": "the operator's own text", "needs": "what the operator's own text says, which Orca has not read", "detail": "Pay.UK Limited's own text is not the source for this code: it is not public, or not under terms Orca can use. It rests on 2 named public sources, so a term set by agreement rather than by a published rule is not Orca's to state.", "from": "currency.primary_not_public" } ] }, { "uid": "uk-fps-return:00000009", "id": "00000009", "rail": "uk-fps-return", "kind": "reason-code", "name": "The payee was not expecting the money and asked for it back", "group": "authorization", "summary": "The payee did not expect the funds, or told their bank to send them back, so the money is being returned. Both public sources agree on the meaning. The decision here starts with the payee, which is what separates it from a return at the sender's request.", "triggers": [ "The payee received money from someone they do not recognise and asked their bank to return it", "A business received a payment it cannot allocate to any invoice and will not hold", "The payee was sent money in error and said so" ], "actions": [ "Payer: check with the payee what they were expecting before sending again, including the amount and the reference", "Payer: a payment a stranger returns unprompted can be a sign of a mistaken or fraudulent transfer, so look at why it was sent" ], "retry": { "allowed": false, "rule": "Do not simply send it again. The payee refused the money, so find out why before sending anything further." }, "facts": { "return_windows": [ { "action": "return Payment", "by": "Receiving FPS Institution", "deadline": "A Return Payment must be sent within one to three working days of the original payment. Which of those it is depends on the answer the receiving directly connected participant gave to the original payment. Pay.UK's public guide states the range and does not say which answer maps to which deadline; that sits in the FPS Procedures, which Pay.UK does not publish." } ], "applies_to": "a Faster Payments credit push to any account type, returned after acceptance at the payee's instruction" }, "caveat": "A return on this rail is a fresh credit push back to the sending institution, referencing the original payment. Nothing is reversed, the payee is not debited by the scheme, and the money reaches the payer's bank rather than the payer directly. Not an ISO 20022 code either: these eight digit numerics are Pay.UK's own, so never carry a meaning here from an ISO ExternalStatusReason value or another rail. This is the payee's choice, not a fault in the payment. Nothing about it says the payer did anything wrong.", "related": [ "uk-fps-return:00000007" ], "basis": { "sources": "Listed as a Faster Payments return reason, with the meaning given here in Orca's own words, by two independent public sources on different hosts, both read 2026-09-20: LHV Connect's Faster Payment Return Codes table (family B) and NatWest's Understanding Faster Payment Rejection and Reason Codes page (family A). Pay.UK's own list was not consulted and is not published. The return mechanics come from Faster Payments System Principles v11 and Pay.UK's Certainty of Fate proposed rule clarification, also read 2026-09-20. Confidence is capped at medium because the governing authority's own text was not read.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: no public source read dates this code", "effective_to": null, "effective_note": "No public source read says when this code became permitted on Faster Payments [Unverified]. Pay.UK does not publish the code list; the two pages this record rests on were last updated within the year before they were read on 2026-09-20.", "source_edition": "The FPS Procedures, Appendix B, FPS Codes, were not consulted: Pay.UK makes the FPS rules and procedures available to participants' legal departments only, as its 2025 PFMI self-assessment states at key consideration 23.1. This record rests on two independent public sources on different hosts, LHV Connect's code reference tables and NatWest's support centre page, both read 2026-09-20, together with Pay.UK's own public documents for the mechanics.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "primary_not_public": true, "corroboration": [ { "source_url": "https://docs.lhv.com/home/connect/overview/code-reference-tables/payment-return-codes", "source_class": "secondary", "source_title": "LHV Connect documentation, Payment Return Codes", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms return code 00000009 as creditor not expecting funds or instructed return." }, { "source_url": "https://www.natwest.com/support-centre/bank-accounts-and-supporting-information/general/what-are-the-faster-payment-reject-and-reason-codes.html", "source_class": "secondary", "source_title": "NatWest support centre, Understanding Faster Payment Rejection and Reason Codes", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms return code 00000009 as a return because the recipient has instructed the payment to be returned, agreeing with the first family." } ] }, "rail_name": "Faster Payments Return Reasons", "governing_authority": "Pay.UK Limited", "snapshot": "2026-09-20", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "not_public", "label": "the operator's own text", "needs": "what the operator's own text says, which Orca has not read", "detail": "Pay.UK Limited's own text is not the source for this code: it is not public, or not under terms Orca can use. It rests on 2 named public sources, so a term set by agreement rather than by a published rule is not Orca's to state.", "from": "currency.primary_not_public" } ] }, { "uid": "uk-fps-return:00000010", "id": "00000010", "rail": "uk-fps-return", "kind": "reason-code", "name": "The account's terms do not allow this credit", "group": "administrative", "summary": "The account exists and can be identified, but its own terms and conditions do not permit money to be credited to it this way, so the funds are being sent back. Both public sources agree. It is a product restriction rather than a fault in the payment.", "triggers": [ "The payee's account is a product that takes credits only from a particular source or by a particular method", "A tax advantaged or subscription limited account cannot accept a further credit", "The account is restricted so that only the holder may pay into it" ], "actions": [ "Payer: ask the payee which account and which method to use instead", "Payee: tell payers when an account cannot accept a Faster Payment" ], "retry": { "allowed": false, "rule": "Not to the same account. The restriction is in the account's terms and will not change on a retry." }, "facts": { "return_windows": [ { "action": "return Payment", "by": "Receiving FPS Institution", "deadline": "A Return Payment must be sent within one to three working days of the original payment. Which of those it is depends on the answer the receiving directly connected participant gave to the original payment. Pay.UK's public guide states the range and does not say which answer maps to which deadline; that sits in the FPS Procedures, which Pay.UK does not publish." } ], "applies_to": "a Faster Payments credit push to any account type, returned after acceptance" }, "caveat": "A return on this rail is a fresh credit push back to the sending institution, referencing the original payment. Nothing is reversed, the payee is not debited by the scheme, and the money reaches the payer's bank rather than the payer directly. Not an ISO 20022 code either: these eight digit numerics are Pay.UK's own, so never carry a meaning here from an ISO ExternalStatusReason value or another rail. There is a matching rejection code for the same restriction caught before acceptance.", "related": [ "uk-fps-return:00000002", "uk-fps-return:00000008" ], "basis": { "sources": "Listed as a Faster Payments return reason, with the meaning given here in Orca's own words, by two independent public sources on different hosts, both read 2026-09-20: LHV Connect's Faster Payment Return Codes table (family B) and NatWest's Understanding Faster Payment Rejection and Reason Codes page (family A). Pay.UK's own list was not consulted and is not published. The return mechanics come from Faster Payments System Principles v11 and Pay.UK's Certainty of Fate proposed rule clarification, also read 2026-09-20. Confidence is capped at medium because the governing authority's own text was not read.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: no public source read dates this code", "effective_to": null, "effective_note": "No public source read says when this code became permitted on Faster Payments [Unverified]. Pay.UK does not publish the code list; the two pages this record rests on were last updated within the year before they were read on 2026-09-20.", "source_edition": "The FPS Procedures, Appendix B, FPS Codes, were not consulted: Pay.UK makes the FPS rules and procedures available to participants' legal departments only, as its 2025 PFMI self-assessment states at key consideration 23.1. This record rests on two independent public sources on different hosts, LHV Connect's code reference tables and NatWest's support centre page, both read 2026-09-20, together with Pay.UK's own public documents for the mechanics.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "primary_not_public": true, "corroboration": [ { "source_url": "https://docs.lhv.com/home/connect/overview/code-reference-tables/payment-return-codes", "source_class": "secondary", "source_title": "LHV Connect documentation, Payment Return Codes", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms return code 00000010 as terms and conditions of account do not permit crediting of these funds." }, { "source_url": "https://www.natwest.com/support-centre/bank-accounts-and-supporting-information/general/what-are-the-faster-payment-reject-and-reason-codes.html", "source_class": "secondary", "source_title": "NatWest support centre, Understanding Faster Payment Rejection and Reason Codes", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms return code 00000010 as a return because the terms and conditions of the payee account do not permit crediting of these funds, agreeing with the first family." } ] }, "rail_name": "Faster Payments Return Reasons", "governing_authority": "Pay.UK Limited", "snapshot": "2026-09-20", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "not_public", "label": "the operator's own text", "needs": "what the operator's own text says, which Orca has not read", "detail": "Pay.UK Limited's own text is not the source for this code: it is not public, or not under terms Orca can use. It rests on 2 named public sources, so a term set by agreement rather than by a published rule is not Orca's to state.", "from": "currency.primary_not_public" } ] }, { "uid": "us-ach:C01", "id": "C01", "rail": "us-ach", "kind": "reason-code", "name": "Incorrect DFI account number", "group": "account", "summary": "The account number on the entry is wrong or badly structured; the NOC carries the right one.", "triggers": [ "Digits added, dropped or transposed when the account number was captured", "The RDFI reissued or renumbered the account", "The RDFI changed its account numbering scheme" ], "actions": [ "Replace the account number with the one in the first 17 positions of the corrected data", "Update the stored data before the next entry, within the time the linked Rule gives", "Refuse the NOC through the ODFI only if the NOC itself is wrong, using a code from C61 to C69" ], "retry": { "allowed": false, "rule": "Nothing to retry: the entry was handled and no money came back. Do not resend it. Send later entries to this account with the corrected data." }, "facts": { "return_windows": [ { "action": "notification of change", "by": "RDFI", "deadline": "2 banking days after the settlement date of the original entry (merger and similar NOCs excepted)" } ], "wsud_required": false, "applies_to": "the corporate and consumer SEC codes CBS Bank lists for it (CCD, CIE, CTX, MTE, PPD, POS, SHR), and IAT, where for outbound entries it concerns the Gateway's account", "counts_toward": [] }, "caveat": "Federal agencies act on C01. Whether an Originator must validate a new account number received this way before debiting it was not found in the sources read.", "related": [ "us-ach:R03", "us-ach:R04" ], "basis": { "sources": "CBS Bank quick reference (March 2025), BMO NOC table (May 2025), Commerce Bank code table (2022), Jefferson Bank Obligations of Originators (March 2022) and First Hawaiian Bank NOC codes, read 2026-09-19. Nacha Operating Rules, NOC provisions and change code definitions (not consulted).", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "No rule change identified in the sources read.", "source_edition": "Nacha Operating Rules not consulted; the record rests on the public sources named in its relations and basis", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.cbsbank.com/wp-content/uploads/2025/03/ACH-Return-Reason-Codes.pdf", "source_class": "secondary", "source_title": "CBS Bank, Quick Reference Guide: ACH Return Reason Codes and Time Frames, March 2025", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms the incorrect DFI account number change definition and corrected data field layout, and the two banking day NOC transmission window with the six banking day originator action deadline." } ] }, "rail_name": "US ACH", "governing_authority": "Nacha", "snapshot": "2026-09-16", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "us-ach:C02", "id": "C02", "rail": "us-ach", "kind": "reason-code", "name": "Incorrect routing number", "group": "account", "summary": "A routing number that used to be valid must change, usually after a bank merger or consolidation; the NOC carries the new one.", "triggers": [ "The receiving bank merged or consolidated its routing numbers", "The RDFI wants entries sent to its preferred routing number" ], "actions": [ "Replace the routing number with the 9 digit value, check digit included, at the start of the corrected data", "Update the stored data before the next entry, within the time the linked Rule gives", "Refuse the NOC through the ODFI only if the NOC itself is wrong, using a code from C61 to C69" ], "retry": { "allowed": false, "rule": "Nothing to retry: the entry was handled and no money came back. Do not resend it. Send later entries to this account with the corrected data." }, "facts": { "return_windows": [ { "action": "notification of change", "by": "RDFI", "deadline": "2 banking days after the settlement date of the original entry (merger and similar NOCs excepted)" } ], "wsud_required": false, "applies_to": "the corporate and consumer SEC codes CBS Bank lists for it (CCD, CIE, CTX, MTE, PPD, POS, SHR), CBR, PBR and IAT", "counts_toward": [] }, "caveat": null, "related": [ "us-ach:C03" ], "basis": { "sources": "CBS Bank quick reference (March 2025), BMO NOC table (May 2025), Commerce Bank code table (2022), Jefferson Bank Obligations of Originators (March 2022) and First Hawaiian Bank NOC codes, read 2026-09-19. Nacha Operating Rules, NOC provisions and change code definitions (not consulted).", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "No rule change identified in the sources read.", "source_edition": "Nacha Operating Rules not consulted; the record rests on the public sources named in its relations and basis", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.cbsbank.com/wp-content/uploads/2025/03/ACH-Return-Reason-Codes.pdf", "source_class": "secondary", "source_title": "CBS Bank, Quick Reference Guide: ACH Return Reason Codes and Time Frames, March 2025", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms the incorrect routing number change definition for merger or consolidation cases, and the two banking day NOC transmission window with the six banking day originator action deadline." } ] }, "rail_name": "US ACH", "governing_authority": "Nacha", "snapshot": "2026-09-16", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "us-ach:C03", "id": "C03", "rail": "us-ach", "kind": "reason-code", "name": "Incorrect routing number and incorrect DFI account number", "group": "account", "summary": "Both the routing number and the account number must change, usually because a merger also changed the account number structure.", "triggers": [ "A merger or consolidation moved the account to a new routing number and a new account number" ], "actions": [ "Replace both values: routing number in positions 1 to 9 of the corrected data, account number from position 13", "Update the stored data before the next entry, within the time the linked Rule gives", "Refuse the NOC through the ODFI only if the NOC itself is wrong, using a code from C61 to C69" ], "retry": { "allowed": false, "rule": "Nothing to retry: the entry was handled and no money came back. Do not resend it. Send later entries to this account with the corrected data." }, "facts": { "return_windows": [ { "action": "notification of change", "by": "RDFI", "deadline": "2 banking days after the settlement date of the original entry (merger and similar NOCs excepted)" } ], "wsud_required": false, "applies_to": "the corporate and consumer SEC codes CBS Bank lists for it (CCD, CIE, CTX, MTE, PPD, POS, SHR)", "counts_toward": [] }, "caveat": "Not used for IAT, where the field is too short to carry both values.", "related": [ "us-ach:C02", "us-ach:C01" ], "basis": { "sources": "CBS Bank quick reference (March 2025), BMO NOC table (May 2025), Commerce Bank code table (2022), Jefferson Bank Obligations of Originators (March 2022) and First Hawaiian Bank NOC codes, read 2026-09-19. Nacha Operating Rules, NOC provisions and change code definitions (not consulted).", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "No rule change identified in the sources read.", "source_edition": "Nacha Operating Rules not consulted; the record rests on the public sources named in its relations and basis", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.cbsbank.com/wp-content/uploads/2025/03/ACH-Return-Reason-Codes.pdf", "source_class": "secondary", "source_title": "CBS Bank, Quick Reference Guide: ACH Return Reason Codes and Time Frames, March 2025", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms the combined incorrect routing and account number change definition, that it should not be used for outbound IAT entries, and the two banking day NOC transmission window with the six banking day originator action deadline." } ] }, "rail_name": "US ACH", "governing_authority": "Nacha", "snapshot": "2026-09-16", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is not for International ACH Transaction (IAT). Its own scope line reads: the corporate and consumer SEC codes CBS Bank lists for it (CCD, CIE, CTX, MTE, PPD, POS, SHR).", "from": "applies_to" } ] }, { "uid": "us-ach:C05", "id": "C05", "rail": "us-ach", "kind": "reason-code", "name": "Incorrect transaction code", "group": "account", "summary": "The entry was coded for the wrong kind of account, for example checking instead of savings; the NOC carries the right transaction code.", "triggers": [ "A savings account was entered as checking, or the reverse", "The entry reached the wrong posting system at the RDFI because of its transaction code" ], "actions": [ "Replace the transaction code with the 2 digit value at the start of the corrected data", "Update the stored data before the next entry, within the time the linked Rule gives", "Refuse the NOC through the ODFI only if the NOC itself is wrong, using a code from C61 to C69" ], "retry": { "allowed": false, "rule": "Nothing to retry: the entry was handled and no money came back. Do not resend it. Send later entries to this account with the corrected data." }, "facts": { "return_windows": [ { "action": "notification of change", "by": "RDFI", "deadline": "2 banking days after the settlement date of the original entry (merger and similar NOCs excepted)" } ], "wsud_required": false, "applies_to": "CCD, CTX, MTE, PPD, POS, SHR and IAT, per CBS Bank", "counts_toward": [] }, "caveat": null, "related": [ "us-ach:C06" ], "basis": { "sources": "CBS Bank quick reference (March 2025), BMO NOC table (May 2025), Commerce Bank code table (2022), Jefferson Bank Obligations of Originators (March 2022) and First Hawaiian Bank NOC codes, read 2026-09-19. Nacha Operating Rules, NOC provisions and change code definitions (not consulted).", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "No rule change identified in the sources read.", "source_edition": "Nacha Operating Rules not consulted; the record rests on the public sources named in its relations and basis", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.cbsbank.com/wp-content/uploads/2025/03/ACH-Return-Reason-Codes.pdf", "source_class": "secondary", "source_title": "CBS Bank, Quick Reference Guide: ACH Return Reason Codes and Time Frames, March 2025", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms the incorrect transaction code change definition, and the two banking day NOC transmission window with the six banking day originator action deadline." } ] }, "rail_name": "US ACH", "governing_authority": "Nacha", "snapshot": "2026-09-16", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "us-ach:C06", "id": "C06", "rail": "us-ach", "kind": "reason-code", "name": "Incorrect DFI account number and incorrect transaction code", "group": "account", "summary": "Both the account number and the account type are wrong; the NOC carries both.", "triggers": [ "The account number is wrong and the entry is also coded for the wrong type of account" ], "actions": [ "Take the account number from positions 1 to 17 and the transaction code from positions 21 and 22 of the corrected data", "Update the stored data before the next entry, within the time the linked Rule gives", "Refuse the NOC through the ODFI only if the NOC itself is wrong, using a code from C61 to C69" ], "retry": { "allowed": false, "rule": "Nothing to retry: the entry was handled and no money came back. Do not resend it. Send later entries to this account with the corrected data." }, "facts": { "return_windows": [ { "action": "notification of change", "by": "RDFI", "deadline": "2 banking days after the settlement date of the original entry (merger and similar NOCs excepted)" } ], "wsud_required": false, "applies_to": "the corporate and consumer SEC codes CBS Bank lists for it (CCD, CIE, CTX, MTE, PPD, POS, SHR), CBR and PBR", "counts_toward": [] }, "caveat": "Not used for outbound IAT entries.", "related": [ "us-ach:C01", "us-ach:C05" ], "basis": { "sources": "CBS Bank quick reference (March 2025), BMO NOC table (May 2025), Commerce Bank code table (2022), Jefferson Bank Obligations of Originators (March 2022) and First Hawaiian Bank NOC codes, read 2026-09-19. Nacha Operating Rules, NOC provisions and change code definitions (not consulted).", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "No rule change identified in the sources read.", "source_edition": "Nacha Operating Rules not consulted; the record rests on the public sources named in its relations and basis", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.cbsbank.com/wp-content/uploads/2025/03/ACH-Return-Reason-Codes.pdf", "source_class": "secondary", "source_title": "CBS Bank, Quick Reference Guide: ACH Return Reason Codes and Time Frames, March 2025", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms the combined incorrect account number and transaction code change definition and corrected data field layout, and the two banking day NOC transmission window with the six banking day originator action deadline." } ] }, "rail_name": "US ACH", "governing_authority": "Nacha", "snapshot": "2026-09-16", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is not for International ACH Transaction (IAT). Its own scope line reads: the corporate and consumer SEC codes CBS Bank lists for it (CCD, CIE, CTX, MTE, PPD, POS, SHR), CBR and PBR.", "from": "applies_to" } ] }, { "uid": "us-ach:C07", "id": "C07", "rail": "us-ach", "kind": "reason-code", "name": "Incorrect routing number, incorrect DFI account number and incorrect transaction code", "group": "account", "summary": "Routing number, account number and account type all have to change, typically after a merger.", "triggers": [ "A merger changed the routing number, the account number no longer fits the new structure, and the entry should go to another type of account" ], "actions": [ "Take the routing number from positions 1 to 9, the account number from 10 to 26 and the transaction code from 27 and 28 of the corrected data", "Update the stored data before the next entry, within the time the linked Rule gives", "Refuse the NOC through the ODFI only if the NOC itself is wrong, using a code from C61 to C69" ], "retry": { "allowed": false, "rule": "Nothing to retry: the entry was handled and no money came back. Do not resend it. Send later entries to this account with the corrected data." }, "facts": { "return_windows": [ { "action": "notification of change", "by": "RDFI", "deadline": "2 banking days after the settlement date of the original entry (merger and similar NOCs excepted)" } ], "wsud_required": false, "applies_to": "the corporate and consumer SEC codes CBS Bank lists for it (CCD, CIE, CTX, MTE, PPD, POS, SHR)", "counts_toward": [] }, "caveat": "Not used for IAT.", "related": [ "us-ach:C03", "us-ach:C06" ], "basis": { "sources": "CBS Bank quick reference (March 2025), BMO NOC table (May 2025), Commerce Bank code table (2022), Jefferson Bank Obligations of Originators (March 2022) and First Hawaiian Bank NOC codes, read 2026-09-19. Nacha Operating Rules, NOC provisions and change code definitions (not consulted).", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "No rule change identified in the sources read.", "source_edition": "Nacha Operating Rules not consulted; the record rests on the public sources named in its relations and basis", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.cbsbank.com/wp-content/uploads/2025/03/ACH-Return-Reason-Codes.pdf", "source_class": "secondary", "source_title": "CBS Bank, Quick Reference Guide: ACH Return Reason Codes and Time Frames, March 2025", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms the combined incorrect routing number, account number and transaction code change definition for merger or consolidation cases, and the two banking day NOC transmission window with the six banking day originator action deadline." } ] }, "rail_name": "US ACH", "governing_authority": "Nacha", "snapshot": "2026-09-16", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is not for International ACH Transaction (IAT). Its own scope line reads: the corporate and consumer SEC codes CBS Bank lists for it (CCD, CIE, CTX, MTE, PPD, POS, SHR).", "from": "applies_to" } ] }, { "uid": "us-ach:C08", "id": "C08", "rail": "us-ach", "kind": "reason-code", "name": "Incorrect foreign receiving DFI identification", "group": "account", "summary": "On an international entry, the identifier of the foreign receiving bank is wrong; the NOC carries the right one.", "triggers": [ "The foreign bank identifier on an IAT entry was wrong or out of date" ], "actions": [ "Replace the foreign receiving bank identifier with the value in the corrected data", "Update the stored data before the next entry, within the time the linked Rule gives" ], "retry": { "allowed": false, "rule": "Nothing to retry: the entry was handled and no money came back. Do not resend it. Send later entries to this account with the corrected data." }, "facts": { "return_windows": [ { "action": "notification of change", "by": "RDFI", "deadline": "2 banking days after the settlement date of the original entry (merger and similar NOCs excepted)" } ], "wsud_required": false, "applies_to": "IAT only", "counts_toward": [] }, "caveat": "The sources disagree on how long the corrected value is: CBS Bank and Jefferson Bank give the first 11 positions, Commerce Bank the first 34. BMO labels the code for CBR and PBR. IAT handling otherwise belongs to the IAT records.", "related": [], "basis": { "sources": "CBS Bank quick reference (March 2025), BMO NOC table (May 2025), Commerce Bank code table (2022), Jefferson Bank Obligations of Originators (March 2022) and First Hawaiian Bank NOC codes, read 2026-09-19. Nacha Operating Rules, NOC provisions and change code definitions (not consulted).", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "No rule change identified in the sources read.", "source_edition": "Nacha Operating Rules not consulted; the record rests on the public sources named in its relations and basis", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.cbsbank.com/wp-content/uploads/2025/03/ACH-Return-Reason-Codes.pdf", "source_class": "secondary", "source_title": "CBS Bank, Quick Reference Guide: ACH Return Reason Codes and Time Frames, March 2025", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms the incorrect foreign receiving DFI identification change definition, that it is IAT only, and the two banking day NOC transmission window with the six banking day originator action deadline." } ] }, "rail_name": "US ACH", "governing_authority": "Nacha", "snapshot": "2026-09-16", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for International ACH Transaction (IAT). Its own scope line reads: IAT only.", "from": "applies_to" } ] }, { "uid": "us-ach:C09", "id": "C09", "rail": "us-ach", "kind": "reason-code", "name": "Incorrect individual identification number or incorrect receiver identification number", "group": "administrative", "summary": "The identification number the Originator holds for the Receiver is wrong.", "triggers": [ "The Receiver's identification number was captured wrongly or changed, typically on customer initiated entries that may use a PIN" ], "actions": [ "Correct the identification number in your records", "Update the stored data before the next entry, within the time the linked Rule gives", "Refuse the NOC through the ODFI only if the NOC itself is wrong, using a code from C61 to C69" ], "retry": { "allowed": false, "rule": "Nothing to retry: the entry was handled and no money came back. Do not resend it. Send later entries to this account with the corrected data." }, "facts": { "return_windows": [ { "action": "notification of change", "by": "RDFI", "deadline": "2 banking days after the settlement date of the original entry (merger and similar NOCs excepted)" } ], "wsud_required": false, "applies_to": "CIE, IAT, MTE, POS and SHR, per CBS Bank", "counts_toward": [] }, "caveat": "The sources disagree on the corrected data: Commerce Bank puts the number in the first 22 positions, while CBS Bank says the change fields stay blank for domestic entries and gives the first 15 positions for IAT.", "related": [], "basis": { "sources": "CBS Bank quick reference (March 2025), BMO NOC table (May 2025), Commerce Bank code table (2022), Jefferson Bank Obligations of Originators (March 2022) and First Hawaiian Bank NOC codes, read 2026-09-19. Nacha Operating Rules, NOC provisions and change code definitions (not consulted).", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "No rule change identified in the sources read.", "source_edition": "Nacha Operating Rules not consulted; the record rests on the public sources named in its relations and basis", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.cbsbank.com/wp-content/uploads/2025/03/ACH-Return-Reason-Codes.pdf", "source_class": "secondary", "source_title": "CBS Bank, Quick Reference Guide: ACH Return Reason Codes and Time Frames, March 2025", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms the incorrect individual or receiver identification number change definition and the entry types it applies to, and the two banking day NOC transmission window with the six banking day originator action deadline." } ] }, "rail_name": "US ACH", "governing_authority": "Nacha", "snapshot": "2026-09-16", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "us-ach:C13", "id": "C13", "rail": "us-ach", "kind": "reason-code", "name": "Addenda format error", "group": "technical", "summary": "The entry posted, but its addenda record was unclear or not in an accepted format, for example a CCD addenda not following the ANSI or Nacha banking conventions.", "triggers": [ "Remittance data in the addenda did not follow an endorsed format", "The addenda text could not be read by the RDFI" ], "actions": [ "Agree a corrected addenda format with your ODFI; the NOC carries no corrected data", "Update the stored data before the next entry, within the time the linked Rule gives" ], "retry": { "allowed": false, "rule": "Nothing to retry: the entry was handled and no money came back. Do not resend it. Send later entries to this account with the corrected data." }, "facts": { "return_windows": [ { "action": "notification of change", "by": "RDFI", "deadline": "2 banking days after the settlement date of the original entry (merger and similar NOCs excepted)" } ], "wsud_required": false, "applies_to": "the corporate and consumer SEC codes CBS Bank lists for it (CCD, CIE, CTX, MTE, PPD, POS, SHR) and IAT", "counts_toward": [] }, "caveat": null, "related": [], "basis": { "sources": "CBS Bank quick reference (March 2025), BMO NOC table (May 2025), Commerce Bank code table (2022), Jefferson Bank Obligations of Originators (March 2022) and First Hawaiian Bank NOC codes, read 2026-09-19. Nacha Operating Rules, NOC provisions and change code definitions (not consulted).", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "No rule change identified in the sources read.", "source_edition": "Nacha Operating Rules not consulted; the record rests on the public sources named in its relations and basis", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.cbsbank.com/wp-content/uploads/2025/03/ACH-Return-Reason-Codes.pdf", "source_class": "secondary", "source_title": "CBS Bank, Quick Reference Guide: ACH Return Reason Codes and Time Frames, March 2025", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms the addenda format error change definition and that change fields are left blank, and the two banking day NOC transmission window with the six banking day originator action deadline." } ] }, "rail_name": "US ACH", "governing_authority": "Nacha", "snapshot": "2026-09-16", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "us-ach:C14", "id": "C14", "rail": "us-ach", "kind": "reason-code", "name": "Incorrect SEC code for outbound international payment", "group": "technical", "summary": "A Gateway has found that a domestic entry is really an international payment and asks that future entries be sent as IAT, which carries the data the Gateway needs for OFAC screening.", "triggers": [ "A CCD or PPD entry posted to a Receiver who has told the RDFI to forward the funds to an account in another country" ], "actions": [ "Send future entries to this Receiver as IAT", "Update the stored data before the next entry, within the time the linked Rule gives" ], "retry": { "allowed": false, "rule": "Nothing to retry: the entry was handled and no money came back. Do not resend it. Send later entries to this account with the corrected data." }, "facts": { "return_windows": [ { "action": "notification of change", "by": "Gateway", "deadline": "2 banking days after the settlement date of the original entry (merger and similar NOCs excepted)" } ], "wsud_required": false, "applies_to": "CCD and PPD entries that turn out to be outbound international", "counts_toward": [] }, "caveat": "Only a Gateway may use C14. IAT coding rules belong to the IAT records.", "related": [], "basis": { "sources": "CBS Bank quick reference (March 2025), Jefferson Bank Obligations of Originators (March 2022) and Modern Treasury documentation, read 2026-09-19. Nacha Operating Rules (not consulted).", "confidence": "medium" }, "currency": { "effective_since": "2013-03-15", "effective_to": null, "effective_note": "Jefferson Bank's guide gives C14 an effective date of 2013-03-15.", "source_edition": "Nacha Operating Rules not consulted; the record rests on the public sources named in its relations and basis", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.cbsbank.com/wp-content/uploads/2025/03/ACH-Return-Reason-Codes.pdf", "source_class": "secondary", "source_title": "CBS Bank, Quick Reference Guide: ACH Return Reason Codes and Time Frames, March 2025", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms the incorrect SEC code for outbound international payment definition, that it is for Gateway use only, and the two banking day NOC transmission window with the six banking day originator action deadline." } ] }, "rail_name": "US ACH", "governing_authority": "Nacha", "snapshot": "2026-09-16", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for Corporate Credit or Debit Entry (CCD), Prearranged Payment and Deposit Entry (PPD). Its own scope line reads: CCD and PPD entries that turn out to be outbound international.", "from": "applies_to" } ] }, { "uid": "us-ach:C61", "id": "C61", "rail": "us-ach", "kind": "reason-code", "name": "Misrouted notification of change", "group": "technical", "summary": "The ODFI refuses an NOC that reached the wrong bank because of a routing number error.", "triggers": [ "The RDFI put the wrong routing number on the NOC" ], "actions": [ "As the RDFI, check the routing number of the original entry's ODFI and resend the NOC to it [Inference]" ], "retry": { "allowed": false, "rule": "Nothing to retry: no money moved. As the RDFI, check the original entry and decide whether to send a new, correct NOC. [Inference]" }, "facts": { "return_windows": [ { "action": "refused notification of change", "by": "ODFI", "deadline": "No public source read states when an ODFI must send a refused NOC. The Green Book says federal agencies usually refuse one before the next payment." } ], "wsud_required": false, "applies_to": "any NOC", "counts_toward": [] }, "caveat": null, "related": [], "basis": { "sources": "CBS Bank quick reference (March 2025) and Jefferson Bank Obligations of Originators (March 2022), read 2026-09-19. Nacha Operating Rules (not consulted).", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "No rule change identified in the sources read.", "source_edition": "Nacha Operating Rules not consulted; the record rests on the public sources named in its relations and basis", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.jefferson-bank.com/uploadedfiles/includedcontent/business/obligations-of-originators.pdf?v=1D50A930C4ADA00", "source_class": "secondary", "source_title": "Jefferson Bank, Obligations of Originators, revised March 2022", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms the misrouted notification of change refusal definition as an NOC sent to the wrong ODFI on a routing number error; states no timeframe for this refusal." } ] }, "rail_name": "US ACH", "governing_authority": "Nacha", "snapshot": "2026-09-16", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "us-ach:C62", "id": "C62", "rail": "us-ach", "kind": "reason-code", "name": "Incorrect trace number", "group": "technical", "summary": "The ODFI refuses an NOC whose trace number does not identify any entry it sent.", "triggers": [ "The original entry trace number on the NOC was wrong or missing" ], "actions": [ "As the RDFI, copy the trace number from the original entry" ], "retry": { "allowed": false, "rule": "Nothing to retry: no money moved. As the RDFI, check the original entry and decide whether to send a new, correct NOC. [Inference]" }, "facts": { "return_windows": [ { "action": "refused notification of change", "by": "ODFI", "deadline": "No public source read states when an ODFI must send a refused NOC. The Green Book says federal agencies usually refuse one before the next payment." } ], "wsud_required": false, "applies_to": "any NOC", "counts_toward": [] }, "caveat": null, "related": [], "basis": { "sources": "CBS Bank quick reference (March 2025) and Jefferson Bank Obligations of Originators (March 2022), read 2026-09-19. Nacha Operating Rules (not consulted).", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "No rule change identified in the sources read.", "source_edition": "Nacha Operating Rules not consulted; the record rests on the public sources named in its relations and basis", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.jefferson-bank.com/uploadedfiles/includedcontent/business/obligations-of-originators.pdf?v=1D50A930C4ADA00", "source_class": "secondary", "source_title": "Jefferson Bank, Obligations of Originators, revised March 2022", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms the incorrect trace number refusal definition as a trace number that could not be identified; states no timeframe for this refusal." } ] }, "rail_name": "US ACH", "governing_authority": "Nacha", "snapshot": "2026-09-16", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "us-ach:C63", "id": "C63", "rail": "us-ach", "kind": "reason-code", "name": "Incorrect company identification number", "group": "technical", "summary": "The ODFI refuses an NOC because the company identification on it does not let the ODFI find the Originator.", "triggers": [ "The company identification on the NOC does not match any Originator of the ODFI" ], "actions": [ "As the RDFI, copy the company identification from the original batch header" ], "retry": { "allowed": false, "rule": "Nothing to retry: no money moved. As the RDFI, check the original entry and decide whether to send a new, correct NOC. [Inference]" }, "facts": { "return_windows": [ { "action": "refused notification of change", "by": "ODFI", "deadline": "No public source read states when an ODFI must send a refused NOC. The Green Book says federal agencies usually refuse one before the next payment." } ], "wsud_required": false, "applies_to": "any NOC", "counts_toward": [] }, "caveat": null, "related": [], "basis": { "sources": "CBS Bank quick reference (March 2025) and Jefferson Bank Obligations of Originators (March 2022), read 2026-09-19. Nacha Operating Rules (not consulted).", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "No rule change identified in the sources read.", "source_edition": "Nacha Operating Rules not consulted; the record rests on the public sources named in its relations and basis", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.jefferson-bank.com/uploadedfiles/includedcontent/business/obligations-of-originators.pdf?v=1D50A930C4ADA00", "source_class": "secondary", "source_title": "Jefferson Bank, Obligations of Originators, revised March 2022", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms the incorrect company identification number refusal definition as one the ODFI cannot use to find the originating company; states no timeframe for this refusal." } ] }, "rail_name": "US ACH", "governing_authority": "Nacha", "snapshot": "2026-09-16", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "us-ach:C64", "id": "C64", "rail": "us-ach", "kind": "reason-code", "name": "Incorrect individual identification number", "group": "technical", "summary": "The ODFI refuses an NOC whose individual identification number does not identify the Receiver.", "triggers": [ "The identification number on the NOC does not match the one on the original entry" ], "actions": [ "As the RDFI, copy the identification number from the original entry, with its spaces and characters as sent" ], "retry": { "allowed": false, "rule": "Nothing to retry: no money moved. As the RDFI, check the original entry and decide whether to send a new, correct NOC. [Inference]" }, "facts": { "return_windows": [ { "action": "refused notification of change", "by": "ODFI", "deadline": "No public source read states when an ODFI must send a refused NOC. The Green Book says federal agencies usually refuse one before the next payment." } ], "wsud_required": false, "applies_to": "any NOC", "counts_toward": [] }, "caveat": null, "related": [], "basis": { "sources": "CBS Bank quick reference (March 2025) and Jefferson Bank Obligations of Originators (March 2022), and Treasury Green Book (2025-03), Notification of Change chapter section C, read 2026-09-19. Nacha Operating Rules (not consulted).", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "No rule change identified in the sources read.", "source_edition": "Nacha Operating Rules not consulted; the record rests on the public sources named in its relations and basis", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.jefferson-bank.com/uploadedfiles/includedcontent/business/obligations-of-originators.pdf?v=1D50A930C4ADA00", "source_class": "secondary", "source_title": "Jefferson Bank, Obligations of Originators, revised March 2022", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms the incorrect individual identification number refusal definition, distinguishing an unidentifiable number from an identifiable number that still fails to identify the receiver; states no timeframe for this refusal." } ] }, "rail_name": "US ACH", "governing_authority": "Nacha", "snapshot": "2026-09-16", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "us-ach:C65", "id": "C65", "rail": "us-ach", "kind": "reason-code", "name": "Incorrectly formatted corrected data", "group": "technical", "summary": "The ODFI refuses an NOC whose corrected data cannot be processed because of how it is laid out.", "triggers": [ "The corrected value sits in the wrong positions of the corrected data field", "The corrected data does not fit the change code used" ], "actions": [ "As the RDFI, rebuild the corrected data in the layout the change code requires" ], "retry": { "allowed": false, "rule": "Nothing to retry: no money moved. As the RDFI, check the original entry and decide whether to send a new, correct NOC. [Inference]" }, "facts": { "return_windows": [ { "action": "refused notification of change", "by": "ODFI", "deadline": "No public source read states when an ODFI must send a refused NOC. The Green Book says federal agencies usually refuse one before the next payment." } ], "wsud_required": false, "applies_to": "any NOC", "counts_toward": [] }, "caveat": null, "related": [], "basis": { "sources": "CBS Bank quick reference (March 2025) and Jefferson Bank Obligations of Originators (March 2022), and Treasury Green Book (2025-03), Notification of Change chapter section C, read 2026-09-19. Nacha Operating Rules (not consulted).", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "No rule change identified in the sources read.", "source_edition": "Nacha Operating Rules not consulted; the record rests on the public sources named in its relations and basis", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.jefferson-bank.com/uploadedfiles/includedcontent/business/obligations-of-originators.pdf?v=1D50A930C4ADA00", "source_class": "secondary", "source_title": "Jefferson Bank, Obligations of Originators, revised March 2022", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms the incorrectly formatted corrected data refusal definition as addenda information that could not be processed; states no timeframe for this refusal." } ] }, "rail_name": "US ACH", "governing_authority": "Nacha", "snapshot": "2026-09-16", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "us-ach:C66", "id": "C66", "rail": "us-ach", "kind": "reason-code", "name": "Incorrect discretionary data", "group": "technical", "summary": "The ODFI refuses an NOC whose discretionary data is missing or wrong.", "triggers": [ "The discretionary data carried on the original entry was left off the NOC or altered" ], "actions": [ "As the RDFI, copy the discretionary data exactly as it appeared on the original entry" ], "retry": { "allowed": false, "rule": "Nothing to retry: no money moved. As the RDFI, check the original entry and decide whether to send a new, correct NOC. [Inference]" }, "facts": { "return_windows": [ { "action": "refused notification of change", "by": "ODFI", "deadline": "No public source read states when an ODFI must send a refused NOC. The Green Book says federal agencies usually refuse one before the next payment." } ], "wsud_required": false, "applies_to": "any NOC", "counts_toward": [] }, "caveat": null, "related": [], "basis": { "sources": "CBS Bank quick reference (March 2025) and Jefferson Bank Obligations of Originators (March 2022), and Treasury Green Book (2025-03), Notification of Change chapter section C, read 2026-09-19. Nacha Operating Rules (not consulted).", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "No rule change identified in the sources read.", "source_edition": "Nacha Operating Rules not consulted; the record rests on the public sources named in its relations and basis", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.jefferson-bank.com/uploadedfiles/includedcontent/business/obligations-of-originators.pdf?v=1D50A930C4ADA00", "source_class": "secondary", "source_title": "Jefferson Bank, Obligations of Originators, revised March 2022", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms the incorrect discretionary data refusal definition as data missing or containing errors; states no timeframe for this refusal." } ] }, "rail_name": "US ACH", "governing_authority": "Nacha", "snapshot": "2026-09-16", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "us-ach:C67", "id": "C67", "rail": "us-ach", "kind": "reason-code", "name": "Routing number not from original entry detail record", "group": "technical", "summary": "The ODFI refuses an NOC whose routing number does not match the one on the original entry.", "triggers": [ "The NOC's routing number was not copied from the original entry detail record" ], "actions": [ "As the RDFI, take the routing number from the original entry detail record" ], "retry": { "allowed": false, "rule": "Nothing to retry: no money moved. As the RDFI, check the original entry and decide whether to send a new, correct NOC. [Inference]" }, "facts": { "return_windows": [ { "action": "refused notification of change", "by": "ODFI", "deadline": "No public source read states when an ODFI must send a refused NOC. The Green Book says federal agencies usually refuse one before the next payment." } ], "wsud_required": false, "applies_to": "any NOC", "counts_toward": [] }, "caveat": null, "related": [], "basis": { "sources": "CBS Bank quick reference (March 2025) and Jefferson Bank Obligations of Originators (March 2022), and Treasury Green Book (2025-03), Notification of Change chapter section C, read 2026-09-19. Nacha Operating Rules (not consulted).", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "No rule change identified in the sources read.", "source_edition": "Nacha Operating Rules not consulted; the record rests on the public sources named in its relations and basis", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.jefferson-bank.com/uploadedfiles/includedcontent/business/obligations-of-originators.pdf?v=1D50A930C4ADA00", "source_class": "secondary", "source_title": "Jefferson Bank, Obligations of Originators, revised March 2022", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms the routing number not from original entry detail record refusal definition as a mismatch against the original entry's data; states no timeframe for this refusal." } ] }, "rail_name": "US ACH", "governing_authority": "Nacha", "snapshot": "2026-09-16", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "us-ach:C68", "id": "C68", "rail": "us-ach", "kind": "reason-code", "name": "DFI account number not from original entry detail record", "group": "technical", "summary": "The ODFI refuses an NOC whose account number does not match the one on the original entry.", "triggers": [ "The NOC's account number was not copied from the original entry detail record" ], "actions": [ "As the RDFI, take the account number from the original entry detail record; the new number belongs only in the corrected data" ], "retry": { "allowed": false, "rule": "Nothing to retry: no money moved. As the RDFI, check the original entry and decide whether to send a new, correct NOC. [Inference]" }, "facts": { "return_windows": [ { "action": "refused notification of change", "by": "ODFI", "deadline": "No public source read states when an ODFI must send a refused NOC. The Green Book says federal agencies usually refuse one before the next payment." } ], "wsud_required": false, "applies_to": "any NOC", "counts_toward": [] }, "caveat": null, "related": [], "basis": { "sources": "CBS Bank quick reference (March 2025) and Jefferson Bank Obligations of Originators (March 2022), and Treasury Green Book (2025-03), Notification of Change chapter section C, read 2026-09-19. Nacha Operating Rules (not consulted).", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "No rule change identified in the sources read.", "source_edition": "Nacha Operating Rules not consulted; the record rests on the public sources named in its relations and basis", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.jefferson-bank.com/uploadedfiles/includedcontent/business/obligations-of-originators.pdf?v=1D50A930C4ADA00", "source_class": "secondary", "source_title": "Jefferson Bank, Obligations of Originators, revised March 2022", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms the DFI account number not from original entry detail record refusal definition as a mismatch against the original entry's data; states no timeframe for this refusal." } ] }, "rail_name": "US ACH", "governing_authority": "Nacha", "snapshot": "2026-09-16", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "us-ach:C69", "id": "C69", "rail": "us-ach", "kind": "reason-code", "name": "Incorrect transaction code", "group": "technical", "summary": "The ODFI refuses an NOC whose transaction code does not match that of the original entry.", "triggers": [ "The NOC carries a transaction code that does not correspond to the original entry's" ], "actions": [ "As the RDFI, use the NOC transaction code that corresponds to the original entry's" ], "retry": { "allowed": false, "rule": "Nothing to retry: no money moved. As the RDFI, check the original entry and decide whether to send a new, correct NOC. [Inference]" }, "facts": { "return_windows": [ { "action": "refused notification of change", "by": "ODFI", "deadline": "No public source read states when an ODFI must send a refused NOC. The Green Book says federal agencies usually refuse one before the next payment." } ], "wsud_required": false, "applies_to": "any NOC", "counts_toward": [] }, "caveat": null, "related": [], "basis": { "sources": "CBS Bank quick reference (March 2025) and Jefferson Bank Obligations of Originators (March 2022), and Treasury Green Book (2025-03), Notification of Change chapter section C, read 2026-09-19. Nacha Operating Rules (not consulted).", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "No rule change identified in the sources read.", "source_edition": "Nacha Operating Rules not consulted; the record rests on the public sources named in its relations and basis", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.jefferson-bank.com/uploadedfiles/includedcontent/business/obligations-of-originators.pdf?v=1D50A930C4ADA00", "source_class": "secondary", "source_title": "Jefferson Bank, Obligations of Originators, revised March 2022", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms the incorrect transaction code refusal definition as a mismatch against the original entry's transaction code; states no timeframe for this refusal." } ] }, "rail_name": "US ACH", "governing_authority": "Nacha", "snapshot": "2026-09-16", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "us-ach:R01", "id": "R01", "rail": "us-ach", "kind": "reason-code", "name": "Insufficient funds", "group": "funds", "summary": "The account is open and valid. The available balance did not cover the debit at the moment it was presented.", "triggers": [ "Debit landed before an expected direct deposit posted", "Month-end stacking of rent, auto, and card payments drained the balance", "Receiver spent down between the day they authorized and the settlement date", "Your debit window sits a day or two ahead of the receiver's pay cycle" ], "actions": [ "Retry, but wait for the receiver's funding pattern rather than retrying immediately", "Look for repeat offenders. The same account returning R01 every cycle is a timing problem you can fix by moving the debit date, not a collection problem", "If your product allows it, let the receiver choose their debit date. This is the single highest-leverage fix for chronic R01", "Track R01 as a share of volume. It is the most common return by a wide margin and it is the first thing that pushes you toward the 15 percent overall return rate threshold" ], "retry": { "allowed": true, "rule": "Nacha permits two reinitiations after the original return, so three presentments in total. Each must occur within 180 days of the original entry's settlement date, and the reinitiated entry must carry RETRY PYMT in the Company Entry Description field. Every presentment counts separately in your return rate denominator and numerator." }, "facts": { "return_windows": [ { "action": "return", "by": "RDFI", "deadline": "2 banking days" } ], "wsud_required": false, "applies_to": "any debit", "counts_toward": [ "overall" ] }, "caveat": null, "related": [ "us-ach:R09" ], "basis": { "sources": "Nacha Operating Rules, return reason code definitions and reinitiation limits.", "confidence": "medium" }, "currency": { "effective_since": "2015-09-18", "effective_to": null, "effective_note": "Reinitiation limits and RETRY PYMT description took force 2015-09-18. Code definition is long-standing.", "source_edition": "Nacha Operating Rules not consulted; the record rests on the sources listed in its basis and corroboration", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.fhb.com/sites/default/files/2020-11/ACH_RET_Codes.pdf", "source_class": "secondary", "source_title": "ACH Return Reason Codes (First Hawaiian Bank)", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the 2 banking day return window taken by the RDFI and the insufficient funds definition." }, { "source_url": "https://www.cbsbank.com/wp-content/uploads/2025/03/ACH-Return-Reason-Codes.pdf", "source_class": "secondary", "source_title": "CBS Bank, Quick Reference Guide: ACH Return Reason Codes and Time Frames, March 2025", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the 2 banking day return window taken by the RDFI and the insufficient funds definition." } ] }, "rail_name": "US ACH", "governing_authority": "Nacha", "snapshot": "2026-09-16", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "debit or credit", "needs": "whether the entry is a debit or a credit", "detail": "This code is recorded for debits. Its own scope line reads: any debit.", "from": "applies_to" } ] }, { "uid": "us-ach:R02", "id": "R02", "rail": "us-ach", "kind": "reason-code", "name": "Account closed", "group": "account", "summary": "The account was open at some point but has since been closed at the receiving institution.", "triggers": [ "Receiver moved banks or consolidated accounts", "Bank closed the account for cause: repeated overdrafts, suspected fraud, or dormancy", "Account was folded into another during a bank merger or core conversion", "Joint account closed after a divorce, death, or business dissolution" ], "actions": [ "Stop every scheduled entry to this account now, not after the next cycle fails", "Get updated account details directly from the receiver", "Treat the new account as needing fresh authorization. An authorization is tied to the account it named; it does not follow the receiver to a new one", "Purge the account from your files. Continuing to present against a known-closed account is pure return-rate damage with zero chance of collection" ], "retry": { "allowed": false, "rule": "Do not retry. The account does not exist to be debited. Every further presentment adds to both your administrative and overall return rates for no possible benefit." }, "facts": { "return_windows": [ { "action": "return", "by": "RDFI", "deadline": "2 banking days" } ], "wsud_required": false, "applies_to": "any", "counts_toward": [ "admin", "overall" ] }, "caveat": null, "related": [ "us-ach:R03", "us-ach:R04" ], "basis": { "sources": "Nacha Operating Rules, return reason code definitions and administrative return rate definition.", "confidence": "medium" }, "currency": { "effective_since": "2015-09-18", "effective_to": null, "effective_note": "The 3 percent administrative return rate level took force 2015-09-18. Code definition is long-standing.", "source_edition": "Nacha Operating Rules not consulted; the record rests on the sources listed in its basis and corroboration", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.fhb.com/sites/default/files/2020-11/ACH_RET_Codes.pdf", "source_class": "secondary", "source_title": "ACH Return Reason Codes (First Hawaiian Bank)", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the 2 banking day return window taken by the RDFI and the closed account definition." }, { "source_url": "https://www.cbsbank.com/wp-content/uploads/2025/03/ACH-Return-Reason-Codes.pdf", "source_class": "secondary", "source_title": "CBS Bank, Quick Reference Guide: ACH Return Reason Codes and Time Frames, March 2025", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the 2 banking day return window taken by the RDFI and the closed account definition." } ] }, "rail_name": "US ACH", "governing_authority": "Nacha", "snapshot": "2026-09-16", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "us-ach:R03", "id": "R03", "rail": "us-ach", "kind": "reason-code", "name": "No account or unable to locate account", "group": "account", "summary": "The account number does not correspond to an account at that institution, or the number is valid but the name attached to the entry does not match it.", "triggers": [ "Transposed or dropped digits in the account number", "Routing number and account number came from different sources and do not belong together", "Account data captured from a voided check where the number was misread", "Receiver supplied a number from a closed or migrated core system" ], "actions": [ "Confirm the account number with the receiver before doing anything else. This is a data problem, not a funds problem", "Check for the classic failure modes: dropped leading zeros, transposition, truncation at a fixed field length", "If you are seeing R03 at any volume, your account validation step is missing or not working. Nacha's WEB debit account validation requirement exists precisely to catch this before origination", "R03 is distinct from R04. If the number is structurally impossible the RDFI should send R04 instead. Getting R03 means the number looked plausible and still found nothing" ], "retry": { "allowed": false, "rule": "Do not retry with the same account data. Correct the number first, then originate as a new entry." }, "facts": { "return_windows": [ { "action": "return", "by": "RDFI", "deadline": "2 banking days" } ], "wsud_required": false, "applies_to": "any", "counts_toward": [ "admin", "overall" ] }, "caveat": null, "related": [ "us-ach:R04", "us-ach:R02" ], "basis": { "sources": "Nacha Operating Rules, return reason code definitions; WEB account validation rule.", "confidence": "medium" }, "currency": { "effective_since": "2021-03-19", "effective_to": null, "effective_note": "WEB debit account validation rule took force 2021-03-19. Code definition is long-standing.", "source_edition": "Nacha Operating Rules not consulted; the record rests on the sources listed in its basis and corroboration", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.fhb.com/sites/default/files/2020-11/ACH_RET_Codes.pdf", "source_class": "secondary", "source_title": "ACH Return Reason Codes (First Hawaiian Bank)", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the 2 banking day return window taken by the RDFI and the no account or unable to locate account definition." }, { "source_url": "https://www.cbsbank.com/wp-content/uploads/2025/03/ACH-Return-Reason-Codes.pdf", "source_class": "secondary", "source_title": "CBS Bank, Quick Reference Guide: ACH Return Reason Codes and Time Frames, March 2025", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the 2 banking day return window taken by the RDFI and the no account or unable to locate account definition." } ] }, "rail_name": "US ACH", "governing_authority": "Nacha", "snapshot": "2026-09-16", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "us-ach:R04", "id": "R04", "rail": "us-ach", "kind": "reason-code", "name": "Invalid account number structure", "group": "account", "summary": "The account number failed the receiving institution's structural edit. It is not merely unknown, it is malformed.", "triggers": [ "Wrong digit count for that institution's account format", "Failed a check-digit validation", "Non-numeric characters or embedded spaces carried through from a form field", "Truncation in an import, an ETL step, or a fixed-width field that was too short" ], "actions": [ "Treat clustered R04 from a single institution as a pipeline bug, not a customer issue. Structural failures come from your data handling far more often than from the receiver", "Validate account number format at capture. Strip whitespace, reject non-numerics, and preserve leading zeros as text rather than integers", "Re-collect the account number from the receiver and confirm it digit by digit" ], "retry": { "allowed": false, "rule": "Do not retry. A malformed number will fail the same edit every time." }, "facts": { "return_windows": [ { "action": "return", "by": "RDFI", "deadline": "2 banking days" } ], "wsud_required": false, "applies_to": "any", "counts_toward": [ "admin", "overall" ] }, "caveat": null, "related": [ "us-ach:R03" ], "basis": { "sources": "Nacha Operating Rules, return reason code definitions.", "confidence": "medium" }, "currency": { "effective_since": "2015-09-18", "effective_to": null, "effective_note": "The 3 percent administrative return rate level took force 2015-09-18. Code definition is long-standing.", "source_edition": "Nacha Operating Rules not consulted; the record rests on the sources listed in its basis and corroboration", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.fhb.com/sites/default/files/2020-11/ACH_RET_Codes.pdf", "source_class": "secondary", "source_title": "ACH Return Reason Codes (First Hawaiian Bank)", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the 2 banking day return window taken by the RDFI and the invalid account number structure definition." }, { "source_url": "https://www.cbsbank.com/wp-content/uploads/2025/03/ACH-Return-Reason-Codes.pdf", "source_class": "secondary", "source_title": "CBS Bank, Quick Reference Guide: ACH Return Reason Codes and Time Frames, March 2025", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the 2 banking day return window taken by the RDFI and the invalid account number structure definition." } ] }, "rail_name": "US ACH", "governing_authority": "Nacha", "snapshot": "2026-09-16", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "us-ach:R05", "id": "R05", "rail": "us-ach", "kind": "reason-code", "name": "Unauthorized debit to consumer account using corporate SEC code", "group": "authorization", "summary": "You sent a corporate debit, CCD or CTX, against an account the RDFI holds as a consumer account, and the consumer has stated it was not authorized.", "triggers": [ "Sole proprietor or contractor gave you a personal checking account for a business relationship", "System defaults every debit to CCD without classifying the receiver", "Business account was converted to a consumer account and your records never caught up", "Deliberate use of a corporate SEC code to avoid consumer authorization requirements" ], "actions": [ "Understand why this code exists. Consumer protections attach to the account, not to the SEC code you chose. Labelling a consumer debit as CCD does not move it outside those protections, it just produces an R05", "Audit how your system assigns SEC codes. If classification is a default rather than a decision, you will keep generating these", "Use PPD for prearranged consumer debits, WEB for internet-authorized, TEL for telephone-authorized", "Handle this as a compliance event with a written record, not as a failed collection" ], "retry": { "allowed": false, "rule": "Do not retry. Re-presenting a debit the consumer has declared unauthorized compounds the problem. Reclassify the receiver, obtain authorization appropriate to a consumer account, and originate fresh." }, "facts": { "return_windows": [ { "action": "return", "by": "RDFI", "deadline": "60 calendar days" } ], "wsud_required": true, "applies_to": "CCD, CTX to a consumer account", "counts_toward": [ "unauth", "overall" ] }, "caveat": "The 60-day window exists because the consumer must provide a Written Statement of Unauthorized Debit to their institution. That statement is what distinguishes this from an ordinary two-day return.", "related": [ "us-ach:R07", "us-ach:R10", "us-ach:R29" ], "basis": { "sources": "Nacha Operating Rules, return reason code definitions, WSUD requirements, unauthorized entry return rate definition.", "confidence": "medium" }, "currency": { "effective_since": "2015-09-18", "effective_to": null, "effective_note": "Unauthorized return rate reduced to 0.5% effective 2015-09-18. Code definition is long-standing.", "source_edition": "Nacha Operating Rules not consulted; the record rests on the sources listed in its basis and corroboration", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.fhb.com/sites/default/files/2020-11/ACH_RET_Codes.pdf", "source_class": "secondary", "source_title": "ACH Return Reason Codes (First Hawaiian Bank)", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the 60 calendar day return window taken by the RDFI and that the code applies to a CCD or CTX entry sent to a consumer account without authorization." }, { "source_url": "https://www.cbsbank.com/wp-content/uploads/2025/03/ACH-Return-Reason-Codes.pdf", "source_class": "secondary", "source_title": "CBS Bank, Quick Reference Guide: ACH Return Reason Codes and Time Frames, March 2025", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the 60 calendar day return window taken by the RDFI, the written statement of unauthorized debit requirement, and that the code applies to a CCD or CTX entry sent to a consumer account without authorization." } ] }, "rail_name": "US ACH", "governing_authority": "Nacha", "snapshot": "2026-09-16", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the account type", "needs": "whether the account is a consumer account or a business account", "detail": "This code is recorded for consumer accounts. Its own scope line reads: CCD, CTX to a consumer account.", "from": "applies_to" }, { "kind": "scope", "label": "debit or credit", "needs": "whether the entry is a debit or a credit", "detail": "This code is recorded for debits. Its own scope line reads: CCD, CTX to a consumer account.", "from": "applies_to" }, { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for Corporate Credit or Debit Entry (CCD), Corporate Trade Exchange (CTX). Its own scope line reads: CCD, CTX to a consumer account.", "from": "applies_to" } ] }, { "uid": "us-ach:R06", "id": "R06", "rail": "us-ach", "kind": "reason-code", "name": "Returned per ODFI's request", "group": "administrative", "summary": "The ODFI asked the receiving institution to send an entry back, and the receiving institution agreed. Since 2024 an ODFI may make that request for any reason.", "triggers": [ "Originator sent an erroneous entry, such as a wrong amount, wrong account, or duplicate, and asked its ODFI to recover it", "A credit was induced by fraud, such as business email compromise or a spoofed vendor banking change", "A credit was originated without the originator's authorization", "Any other reason the ODFI chose to request a return under the expanded rule" ], "actions": [ "Treat R06 as the answer to a request your side made. If you did not ask for it, contact your ODFI", "Reconcile the returned amount against the original entry and the request", "If the RDFI declines, the funds stay with the receiver and recovery becomes a matter between you and the receiver. Since 2025-04-01 the RDFI must tell the ODFI its decision or status within 10 banking days of the request", "Your ODFI indemnifies the RDFI for honoring the request, and your origination agreement likely passes that exposure to you [Inference]" ], "retry": { "allowed": false, "rule": "The return was requested, so there is nothing to retry. Send a new, corrected entry only if the original was erroneous and a correct payment is still owed." }, "facts": { "return_windows": [ { "action": "return", "by": "RDFI", "deadline": "Not defined; RDFI compliance is optional and no fixed deadline applies" } ], "wsud_required": false, "applies_to": "any", "counts_toward": [ "overall" ] }, "caveat": "RDFI compliance with an ODFI request is voluntary. R06 is often the only network path to recover a misdirected or fraud-induced credit, and it often fails because the funds are already gone. An R06 return the ODFI did not request can be dishonored. An R06 on a debit counts toward Nacha's overall return rate because Nacha counts all return reason codes there. [Inference]", "related": [ "us-ach:R31" ], "basis": { "sources": "Nacha public rule pages: Risk Management Topics, October 1, 2024, and Risk Management Topic, April 1, 2025 (expanded Request for Return, indemnity, 10 banking day status response). Nacha Operating Rules, return reason code definitions (not consulted). Nacha public overall return rate methodology.", "confidence": "medium" }, "currency": { "effective_since": "2024-10-01", "effective_to": null, "effective_note": "Expanded use of the ODFI Request for Return took effect 2024-10-01. The RDFI status response within 10 banking days took effect 2025-04-01. The code itself is long-standing.", "source_edition": "Nacha Operating Rules not consulted; the record rests on the sources listed in its basis and corroboration", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.fhb.com/sites/default/files/2020-11/ACH_RET_Codes.pdf", "source_class": "secondary", "source_title": "ACH Return Reason Codes (First Hawaiian Bank)", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the return window is undefined and set by the ODFIs request rather than a fixed deadline, and that the RDFI executes the return." }, { "source_url": "https://www.cbsbank.com/wp-content/uploads/2025/03/ACH-Return-Reason-Codes.pdf", "source_class": "secondary", "source_title": "CBS Bank, Quick Reference Guide: ACH Return Reason Codes and Time Frames, March 2025", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the return window is undefined and set by the ODFIs request rather than a fixed deadline, and that the RDFI executes the return." } ] }, "rail_name": "US ACH", "governing_authority": "Nacha", "snapshot": "2026-09-16", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "us-ach:R07", "id": "R07", "rail": "us-ach", "kind": "reason-code", "name": "Authorization revoked by customer", "group": "authorization", "summary": "The consumer authorized you at some point and has since revoked that authorization with you. The authorization was real. It is now withdrawn.", "triggers": [ "Receiver cancelled the service and debits kept running", "Cancellation request went to support and never reached billing", "Receiver revoked in writing and your retention flow overrode it", "Billing dispute escalated and the receiver pulled authorization rather than continue arguing" ], "actions": [ "Stop all entries to this account immediately. Any debit after revocation is unauthorized by definition and will come back as R10", "Read R07 as a verdict on your cancellation process. The receiver told you to stop and had to involve their bank to make it happen", "Measure the lag between cancellation request and last debit. That number is the root cause", "Reach the receiver through your own channel to resolve whatever is behind it, but do so without presenting another debit" ], "retry": { "allowed": false, "rule": "Do not retry. Authorization no longer exists. A new debit requires new authorization, obtained and documented fresh." }, "facts": { "return_windows": [ { "action": "return", "by": "RDFI", "deadline": "60 calendar days" } ], "wsud_required": true, "applies_to": "consumer debit", "counts_toward": [ "unauth", "overall" ] }, "caveat": "R07 says an authorization existed and was revoked. R10 says the receiver does not recognize you or never authorized you at all. R11 says the authorization stands but this debit broke its terms. Each points at a different part of your operation.", "related": [ "us-ach:R10", "us-ach:R11", "us-ach:R08" ], "basis": { "sources": "Nacha Operating Rules, return reason code definitions, WSUD requirements.", "confidence": "medium" }, "currency": { "effective_since": "2015-09-18", "effective_to": null, "effective_note": "Unauthorized return rate reduced to 0.5% effective 2015-09-18. Code definition is long-standing.", "source_edition": "Nacha Operating Rules not consulted; the record rests on the sources listed in its basis and corroboration", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.fhb.com/sites/default/files/2020-11/ACH_RET_Codes.pdf", "source_class": "secondary", "source_title": "ACH Return Reason Codes (First Hawaiian Bank)", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the 60 calendar day return window taken by the RDFI and that the code covers a receiver revoking a previously given authorization." }, { "source_url": "https://www.cbsbank.com/wp-content/uploads/2025/03/ACH-Return-Reason-Codes.pdf", "source_class": "secondary", "source_title": "CBS Bank, Quick Reference Guide: ACH Return Reason Codes and Time Frames, March 2025", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the 60 calendar day return window taken by the RDFI, the written statement of unauthorized debit requirement, and that the code covers a receiver revoking a previously given authorization." } ] }, "rail_name": "US ACH", "governing_authority": "Nacha", "snapshot": "2026-09-16", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the account type", "needs": "whether the account is a consumer account or a business account", "detail": "This code is recorded for consumer accounts. Its own scope line reads: consumer debit.", "from": "applies_to" }, { "kind": "scope", "label": "debit or credit", "needs": "whether the entry is a debit or a credit", "detail": "This code is recorded for debits. Its own scope line reads: consumer debit.", "from": "applies_to" } ] }, { "uid": "us-ach:R08", "id": "R08", "rail": "us-ach", "kind": "reason-code", "name": "Payment stopped", "group": "administrative", "summary": "The receiver placed a stop payment order against this entry, or against entries from you, with their own institution.", "triggers": [ "Receiver disputes this specific charge: amount, timing, or a service issue", "Receiver believed a payment was duplicated", "Precautionary stop after a suspected account compromise", "Receiver wanted a debit halted faster than your own cancellation process could manage" ], "actions": [ "Do not read this as a revoked authorization. A stop payment blocks an entry; it is not the same legal act as revocation", "Contact the receiver and find out what they were stopping and why. R08 usually has a specific, resolvable cause behind it", "If the underlying issue resolves, a new entry may be appropriate, but confirm the stop order is lifted first", "Repeated R08 from the same receiver is effectively a revocation in practice, even if not in form. Treat it that way" ], "retry": { "allowed": false, "rule": "Do not retry this entry. Re-presenting against a live stop order produces another return and, if the receiver escalates, an unauthorized code instead." }, "facts": { "return_windows": [ { "action": "return", "by": "RDFI", "deadline": "2 banking days" } ], "wsud_required": false, "applies_to": "any debit", "counts_toward": [ "overall" ] }, "caveat": "R08 does not count toward the 0.5 percent unauthorized entry return rate threshold, which is the main reason to classify it carefully rather than lumping it with R07 and R10 in your reporting.", "related": [ "us-ach:R07" ], "basis": { "sources": "Nacha Operating Rules, return reason code definitions. Some institutions apply an extended window to consumer stop payments; treat two banking days as the floor.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "No material rule change identified for this entry.", "source_edition": "Nacha Operating Rules not consulted; the record rests on the sources listed in its basis and corroboration", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.fhb.com/sites/default/files/2020-11/ACH_RET_Codes.pdf", "source_class": "secondary", "source_title": "ACH Return Reason Codes (First Hawaiian Bank)", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the 2 banking day return window taken by the RDFI and the stop payment definition." }, { "source_url": "https://www.cbsbank.com/wp-content/uploads/2025/03/ACH-Return-Reason-Codes.pdf", "source_class": "secondary", "source_title": "CBS Bank, Quick Reference Guide: ACH Return Reason Codes and Time Frames, March 2025", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the 2 banking day return window taken by the RDFI and the stop payment definition." } ] }, "rail_name": "US ACH", "governing_authority": "Nacha", "snapshot": "2026-09-16", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "debit or credit", "needs": "whether the entry is a debit or a credit", "detail": "This code is recorded for debits. Its own scope line reads: any debit.", "from": "applies_to" } ] }, { "uid": "us-ach:R09", "id": "R09", "rail": "us-ach", "kind": "reason-code", "name": "Uncollected funds", "group": "funds", "summary": "The ledger balance was sufficient but the available balance was not. The money is in the account and has not yet cleared.", "triggers": [ "Recently deposited check still inside its Reg CC hold period", "Large or non-local deposit carrying an extended hold", "Incoming ACH credit posted but not yet made available", "Other pending items reduced available balance below the entry amount" ], "actions": [ "Time the retry rather than rushing it. Unlike R01, R09 means the funds exist and a hold is the only obstacle. Waiting for the hold to expire has a genuinely good success rate", "One to three business days is usually enough to clear a standard hold", "Persistent R09 from the same receiver points to a structural mismatch: their deposits clear after your debit window. Move the debit date", "Do not treat R09 as a credit signal. It is a timing signal" ], "retry": { "allowed": true, "rule": "Retry permitted under the same terms as R01: two reinitiations, three presentments total, within 180 days, carrying RETRY PYMT in the Company Entry Description." }, "facts": { "return_windows": [ { "action": "return", "by": "RDFI", "deadline": "2 banking days" } ], "wsud_required": false, "applies_to": "any debit", "counts_toward": [ "overall" ] }, "caveat": null, "related": [ "us-ach:R01" ], "basis": { "sources": "Nacha Operating Rules, return reason code definitions and reinitiation limits; Regulation CC for hold periods.", "confidence": "medium" }, "currency": { "effective_since": "2015-09-18", "effective_to": null, "effective_note": "Reinitiation limits and RETRY PYMT description took force 2015-09-18. Code definition is long-standing.", "source_edition": "Nacha Operating Rules not consulted; the record rests on the sources listed in its basis and corroboration", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.fhb.com/sites/default/files/2020-11/ACH_RET_Codes.pdf", "source_class": "secondary", "source_title": "ACH Return Reason Codes (First Hawaiian Bank)", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the 2 banking day return window taken by the RDFI and the uncollected funds definition." }, { "source_url": "https://www.cbsbank.com/wp-content/uploads/2025/03/ACH-Return-Reason-Codes.pdf", "source_class": "secondary", "source_title": "CBS Bank, Quick Reference Guide: ACH Return Reason Codes and Time Frames, March 2025", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the 2 banking day return window taken by the RDFI and the uncollected funds definition." } ] }, "rail_name": "US ACH", "governing_authority": "Nacha", "snapshot": "2026-09-16", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "debit or credit", "needs": "whether the entry is a debit or a credit", "detail": "This code is recorded for debits. Its own scope line reads: any debit.", "from": "applies_to" } ] }, { "uid": "us-ach:R10", "id": "R10", "rail": "us-ach", "kind": "reason-code", "name": "Customer advises originator not known or not authorized", "group": "authorization", "summary": "The consumer told their institution that they do not know you, or that they never authorized you to debit the account. This is the most consequential return an originator can receive.", "triggers": [ "Genuine unauthorized activity: stolen account details or account takeover", "Receiver does not recognize the name on their statement because your descriptor shows a legal entity rather than the brand they bought from", "A trial converted to a paid subscription and the receiver did not register that it would", "Someone other than the accountholder signed up using a shared or household account", "Receiver authorized a single purchase and did not understand it established a recurring series" ], "actions": [ "Pull the authorization record for this receiver today. A signed form, a recorded call, or a web authorization with timestamp, IP, and the exact language shown is your entire defense", "If you cannot produce that record, you have a systemic authorization capture problem and this return is a symptom, not the issue", "If the receiver simply did not recognize the name, fix the descriptor across all origination. A mismatch between your DBA and your Company Name field generates R10 at volume from customers who did authorize you and just could not tell", "Suspend every recurring entry to the account while you investigate", "Watch the unauthorized entry return rate weekly, not monthly. Against the 0.5 percent unauthorized entry return rate threshold the measurement window is 60 days, and by the time a monthly report shows a breach you have been over the line for weeks" ], "retry": { "allowed": false, "rule": "Never reinitiate the returned entry. Any new entry to this receiver requires fresh authorization, obtained and documented before you send it. Re-presenting an entry the receiver has declared unauthorized is the fastest route to ODFI intervention and, at volume, to losing origination privileges entirely." }, "facts": { "return_windows": [ { "action": "return", "by": "RDFI", "deadline": "60 calendar days" } ], "wsud_required": true, "applies_to": "consumer debit", "counts_toward": [ "unauth", "overall" ] }, "caveat": "Since 2020 R10 is narrower than it used to be. Entries where authorization existed but the debit did not match its terms now return as R11. If you are comparing R10 volumes across that boundary you are comparing two different definitions.", "related": [ "us-ach:R11", "us-ach:R07", "us-ach:R29", "us-ach:R05" ], "basis": { "sources": "Nacha Operating Rules, return reason code definitions, WSUD requirements, 2020 R10/R11 rule change, unauthorized entry return rate definition.", "confidence": "medium" }, "currency": { "effective_since": "2020-04-01", "effective_to": null, "effective_note": "R10 narrowed and R11 created effective 2020-04-01. Inclusion of R11 in the 0.5 percent unauthorized entry return rate threshold carried a later phased date; confirm against the current edition.", "source_edition": "Nacha Operating Rules not consulted; the record rests on the sources listed in its basis and corroboration", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.nacha.org/rules/differentiating-unauthorized-return-reasons", "source_class": "public_primary", "source_title": "Differentiating Unauthorized Return Reasons (Nacha)", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-16", "notes": "Confirms the current R10 definition (originator not known and or not authorized), the 2020 rule change narrowing R10, phase 1 effective April 1 2020, the Written Statement of Unauthorized Debit requirement, and the 60 calendar day return window. Does not address the 2 banking day window for other codes or retry limits generally." } ] }, "rail_name": "US ACH", "governing_authority": "Nacha", "snapshot": "2026-09-16", "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the account type", "needs": "whether the account is a consumer account or a business account", "detail": "This code is recorded for consumer accounts. Its own scope line reads: consumer debit.", "from": "applies_to" }, { "kind": "scope", "label": "debit or credit", "needs": "whether the entry is a debit or a credit", "detail": "This code is recorded for debits. Its own scope line reads: consumer debit.", "from": "applies_to" } ] }, { "uid": "us-ach:R11", "id": "R11", "rail": "us-ach", "kind": "reason-code", "name": "Entry not in accordance with the terms of the authorization", "group": "authorization", "summary": "The consumer authorized you, and the authorization still stands, but this particular debit did not match its terms. Wrong amount, wrong date, or a change the receiver was owed notice of and did not get.", "triggers": [ "Debited a different amount than the authorization specified, or than the receiver was notified of", "Debited on a date outside what the authorization allowed", "Changed the amount or date of a recurring debit without the required advance notice", "Applied a fee, a proration, or a true-up the authorization never contemplated", "Debited for a transaction the receiver considers incomplete", "Improperly reinitiated a previously returned entry", "ARC, BOC, or POP entry with a source-document problem" ], "actions": [ "Do not treat this like R10. The relationship is intact. The error is in what you sent, and it is usually fixable", "Find the specific mismatch, for example amount, date, or missing notice", "Correct the underlying error and, if the receiver still owes you, originate a new entry that does match the authorization", "If the cause was a change without notice, fix the notice process. Nacha requires advance notice of amount changes on recurring consumer debits, and the absence of that notice is the most common R11 driver", "Track R11 separately from R10 in reporting. They share the 0.5 percent unauthorized entry return rate threshold but not a root cause" ], "retry": { "allowed": false, "rule": "Do not reinitiate the returned entry. Nacha allows the originator to correct the error and send a new entry that matches the authorization within 60 days of the R11 settlement date, and that corrected entry is not treated as a reinitiation. A new entry that repeats the mismatch will come back the same way." }, "facts": { "return_windows": [ { "action": "return", "by": "RDFI", "deadline": "60 calendar days" } ], "wsud_required": true, "applies_to": "consumer debit", "counts_toward": [ "unauth", "overall" ] }, "caveat": "R11 was repurposed in 2020 so that entries with a valid authorization and a mechanical error would stop being returned as R10. It still counts toward the 0.5 percent unauthorized entry return rate threshold. The relief is in the diagnosis and the corrected-entry path, not in the threshold math.", "related": [ "us-ach:R10", "us-ach:R07" ], "basis": { "sources": "Nacha Operating Rules, 2020 R10/R11 rule change, WSUD requirements, unauthorized entry return rate definition. The 60-day corrected-entry window is stated in the rule change; confirm the current edition for any later amendment.", "confidence": "medium" }, "currency": { "effective_since": "2020-04-01", "effective_to": null, "effective_note": "Code repurposed 2020-04-01. Inclusion in the 0.5 percent unauthorized entry return rate threshold carried a later phased date; confirm against the current edition.", "source_edition": "Nacha Operating Rules not consulted; the record rests on the sources listed in its basis and corroboration", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.nacha.org/rules/differentiating-unauthorized-return-reasons", "source_class": "public_primary", "source_title": "Differentiating Unauthorized Return Reasons (Nacha)", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-16", "notes": "Confirms R11 was repurposed effective April 1 2020 to mean entry not in accordance with the terms of authorization, that it counts toward the 0.5 percent unauthorized return rate starting phase 1 (April 1 2020, not a later date), that a Written Statement of Unauthorized Debit is required, the 60 calendar day return window, and that a corrected entry sent within 60 days of the R11 return is not treated as a reinitiation. This resolves the record's own hedge about a later phased inclusion date." } ] }, "rail_name": "US ACH", "governing_authority": "Nacha", "snapshot": "2026-09-16", "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the account type", "needs": "whether the account is a consumer account or a business account", "detail": "This code is recorded for consumer accounts. Its own scope line reads: consumer debit.", "from": "applies_to" }, { "kind": "scope", "label": "debit or credit", "needs": "whether the entry is a debit or a credit", "detail": "This code is recorded for debits. Its own scope line reads: consumer debit.", "from": "applies_to" } ] }, { "uid": "us-ach:R12", "id": "R12", "rail": "us-ach", "kind": "reason-code", "name": "Account sold to another DFI", "group": "account", "summary": "The receiving institution no longer holds the account because the account, or the branch that held it, was sold to another financial institution. The entry reached the old institution.", "triggers": [ "Branch divestiture or bank acquisition moved the account to a new institution with a different routing number", "Originator is still using routing data captured before the sale", "Receiver was not told, or did not pass on, that their routing number changed" ], "actions": [ "Contact the receiver for the new routing and account number. The account likely still exists, just somewhere else", "Check whether a Notification of Change arrived for this receiver before the return. A merger NOC would have carried the new routing data [Inference]", "Update stored account data before the next scheduled entry, not after the next return" ], "retry": { "allowed": false, "rule": "Do not resend to the same routing number. Obtain the new routing and account details, then originate a new entry." }, "facts": { "return_windows": [ { "action": "return", "by": "RDFI", "deadline": "2 banking days" } ], "wsud_required": false, "applies_to": "any", "counts_toward": [ "overall" ] }, "caveat": "R12 is uncommon because acquiring institutions often keep old routing numbers working for a period or send Notifications of Change instead. Some bank guides title this code as a branch sale rather than an account sale. [Unverified] which title is current.", "related": [ "us-ach:R02", "us-ach:R03" ], "basis": { "sources": "Nacha Operating Rules, return reason code definitions (not consulted); public bank quick reference guide (cbsbank.com, ACH Return Reason Codes and Time Frames, secondary) for title and window; Nacha public overall return rate methodology.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "No material rule change identified for this entry.", "source_edition": "Nacha Operating Rules not consulted; the record rests on the sources listed in its basis and corroboration", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.fhb.com/sites/default/files/2020-11/ACH_RET_Codes.pdf", "source_class": "secondary", "source_title": "ACH Return Reason Codes (First Hawaiian Bank)", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the 2 banking day return window taken by the RDFI and the account sold to another DFI definition." }, { "source_url": "https://www.cbsbank.com/wp-content/uploads/2025/03/ACH-Return-Reason-Codes.pdf", "source_class": "secondary", "source_title": "CBS Bank, Quick Reference Guide: ACH Return Reason Codes and Time Frames, March 2025", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the 2 banking day return window taken by the RDFI and the account sold to another DFI definition." } ] }, "rail_name": "US ACH", "governing_authority": "Nacha", "snapshot": "2026-09-16", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "us-ach:R13", "id": "R13", "rail": "us-ach", "kind": "reason-code", "name": "Invalid ACH routing number", "group": "network", "summary": "The ACH Operator returned the entry because the receiving institution identifier is not a valid ACH routing number.", "triggers": [ "Routing number belongs to an institution that does not receive ACH entries", "Routing number retired after a merger", "A wire routing number supplied in place of the ACH routing number", "Routing number passes its check digit but is not in the operator's directory" ], "actions": [ "Confirm the ACH routing number with the receiver. Some institutions publish different numbers for wires and ACH", "Check routing numbers against a current directory at capture, not only the check digit", "Look for Notifications of Change you may have missed after a merger" ], "retry": { "allowed": false, "rule": "Do not resend to the same routing number. Obtain a valid ACH routing number and originate the entry again." }, "facts": { "return_windows": [ { "action": "return", "by": "ACH Operator", "deadline": "At processing, when the entry is rejected" } ], "wsud_required": false, "applies_to": "any", "counts_toward": [ "overall" ] }, "caveat": "Older bank guides title R13 as the RDFI not being qualified to participate; current public guides describe it as an invalid ACH routing number. [Unverified] Unlike R28, the routing number here can pass its check digit and still fail. Operator returns are generated before the entry reaches the receiving institution, so the receiver never saw it. Nacha's public overall rate methodology says all return reason codes count; whether operator-generated returns are included in practice is [Unverified].", "related": [ "us-ach:R28", "us-ach:R12" ], "basis": { "sources": "Nacha Operating Rules, return reason code definitions and ACH record format specifications (not consulted); public bank quick reference guide (cbsbank.com, ACH Return Reason Codes and Time Frames, secondary), ACH Operator rejects section.", "confidence": "low" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "No material rule change identified for this entry.", "source_edition": "Nacha Operating Rules not consulted; the record rests on the sources listed in its basis and corroboration", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www21.bmo.com/olbbwem/olbb-static-file/non-secure/Documents/Help%20Centre%20uploads/ACH%20Return%20Reason%20Codes%20-%20US.PDF", "source_class": "secondary", "source_title": "ACH Return Reason Codes (BMO Treasury and Payment Solutions, May 2025)", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the return happens at the next file delivery following processing rather than a banking day count, consistent with an ACH Operator reject rather than an RDFI return window, and the invalid routing number definition." } ] }, "rail_name": "US ACH", "governing_authority": "Nacha", "snapshot": "2026-09-16", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "us-ach:R14", "id": "R14", "rail": "us-ach", "kind": "reason-code", "name": "Representative payee deceased or unable to continue in that capacity", "group": "account", "summary": "The person receiving payments on behalf of a beneficiary, the representative payee, has died or can no longer act in that role. The beneficiary is alive.", "triggers": [ "Death of the representative payee named on a benefit or fiduciary arrangement", "The payee's appointment ended through incapacity or removal", "A guardian or fiduciary arrangement changed and the institution has been told" ], "actions": [ "Stop future entries to this account under the current payee arrangement", "Do not treat the beneficiary as deceased. That is R15. The beneficiary may be entitled to payments through a new payee or a different account", "For benefit programs, route to whoever administers payee changes. For debits, reassess who is now authorized to act on the account before sending anything" ], "retry": { "allowed": false, "rule": "Do not resend. Future entries need a new payee arrangement or a different account." }, "facts": { "return_windows": [ { "action": "return", "by": "RDFI", "deadline": "2 banking days" } ], "wsud_required": false, "applies_to": "any, most often benefit credits", "counts_toward": [ "overall" ] }, "caveat": "Mostly seen on benefit credits, which do not feed debit return rates. When it arrives on a debit it counts toward Nacha's overall return rate like any other debit return. [Inference] Federal benefit payments also carry a separate reclamation process under Treasury rules (31 CFR Part 210), which this record does not cover. [Unverified]", "related": [], "basis": { "sources": "Nacha Operating Rules, return reason code definitions (not consulted); public bank quick reference guide (cbsbank.com, ACH Return Reason Codes and Time Frames, secondary); Nacha public overall return rate methodology.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "No material rule change identified for this entry.", "source_edition": "Nacha Operating Rules not consulted; the record rests on the sources listed in its basis and corroboration", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.moderntreasury.com/learn/ach-return-code-reference", "source_class": "secondary", "source_title": "ACH Return Codes (R01-R85), Modern Treasury", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms the 2 banking day return window and the representative payee deceased definition. Does not address the applies_to characterization or the federal benefit reclamation caveat." } ] }, "rail_name": "US ACH", "governing_authority": "Nacha", "snapshot": "2026-09-16", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "us-ach:R15", "id": "R15", "rail": "us-ach", "kind": "reason-code", "name": "Beneficiary or account holder (other than a representative payee) deceased", "group": "account", "summary": "The beneficiary entitled to the payments, or the accountholder, has died.", "triggers": [ "Accountholder died and the institution has been notified", "A benefit beneficiary died and payments continued until the payer learned of it", "The estate has not yet closed or retitled the account" ], "actions": [ "Stop all future entries to this receiver", "For credits such as pension or benefit payments, expect recovery questions on payments made after death and route them to the team that handles reclamation", "For debits such as loan or subscription payments, route to your estate process rather than collections", "Update your records so the same person is not debited through another account without authority from the estate" ], "retry": { "allowed": false, "rule": "Never retry. Any further entry needs authority from whoever now controls the account or the estate." }, "facts": { "return_windows": [ { "action": "return", "by": "RDFI", "deadline": "2 banking days" } ], "wsud_required": false, "applies_to": "consumer accounts", "counts_toward": [ "overall" ] }, "caveat": "A Death Notification Entry (DNE) is a separate non-dollar entry sent by federal agencies to receiving institutions; it is not a return. [Unverified]", "related": [ "us-ach:R14" ], "basis": { "sources": "Nacha Operating Rules, return reason code definitions (not consulted); public bank quick reference guide (cbsbank.com, ACH Return Reason Codes and Time Frames, secondary); Nacha public overall return rate methodology.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "No material rule change identified for this entry.", "source_edition": "Nacha Operating Rules not consulted; the record rests on the sources listed in its basis and corroboration", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.moderntreasury.com/learn/ach-return-code-reference", "source_class": "secondary", "source_title": "ACH Return Codes (R01-R85), Modern Treasury", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms the 2 banking day return window and the beneficiary or account holder deceased definition. Does not address the Death Notification Entry caveat." } ] }, "rail_name": "US ACH", "governing_authority": "Nacha", "snapshot": "2026-09-16", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the account type", "needs": "whether the account is a consumer account or a business account", "detail": "This code is recorded for consumer accounts. Its own scope line reads: consumer accounts.", "from": "applies_to" } ] }, { "uid": "us-ach:R16", "id": "R16", "rail": "us-ach", "kind": "reason-code", "name": "Account frozen or entry returned per OFAC instruction", "group": "account", "summary": "Access to the account is restricted by legal process, or the entry was returned on OFAC instruction.", "triggers": [ "Garnishment, levy, or court-ordered freeze", "Tax levy from a federal or state authority", "OFAC sanctions match against the accountholder or a related party", "Bank-initiated freeze during a fraud investigation" ], "actions": [ "Do not retry. The restriction comes from an authority outside your reach and outside the receiver's", "Do not contact the receiver to ask about the freeze. You will not know which cause applies, and where OFAC or law enforcement is involved, that conversation can create problems of its own", "Route this to compliance rather than collections. If the entry was a payroll or benefit credit you may have an obligation to the receiver that needs an alternative method", "A business receiver returning R16 is a meaningful credit signal about the relationship generally" ], "retry": { "allowed": false, "rule": "Do not retry. The restriction persists until the imposing authority lifts it, on a timeline you cannot influence." }, "facts": { "return_windows": [ { "action": "return", "by": "RDFI", "deadline": "2 banking days" } ], "wsud_required": false, "applies_to": "any", "counts_toward": [ "overall" ] }, "caveat": null, "related": [ "us-ach:R90" ], "basis": { "sources": "Nacha Operating Rules, return reason code definitions; OFAC compliance obligations for RDFIs.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "No material rule change identified for this entry.", "source_edition": "Nacha Operating Rules not consulted; the record rests on the sources listed in its basis and corroboration", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.fhb.com/sites/default/files/2020-11/ACH_RET_Codes.pdf", "source_class": "secondary", "source_title": "ACH Return Reason Codes (First Hawaiian Bank)", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the 2 banking day return window taken by the RDFI and the account frozen or OFAC instruction definition." }, { "source_url": "https://www.cbsbank.com/wp-content/uploads/2025/03/ACH-Return-Reason-Codes.pdf", "source_class": "secondary", "source_title": "CBS Bank, Quick Reference Guide: ACH Return Reason Codes and Time Frames, March 2025", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the 2 banking day return window taken by the RDFI and the account frozen or OFAC instruction definition." } ] }, "rail_name": "US ACH", "governing_authority": "Nacha", "snapshot": "2026-09-16", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "us-ach:R17", "id": "R17", "rail": "us-ach", "kind": "reason-code", "name": "File record edit criteria, questionable entry, or improper reversal", "group": "administrative", "summary": "An RDFI return with three distinct uses: the RDFI could not process a field in the entry, the RDFI believes the entry was initiated under questionable circumstances such as fraud, or the entry was an improper reversal. The return addenda tells you which.", "triggers": [ "A field in the entry could not be processed by the RDFI; the addenda identifies the field", "RDFI suspects fraud or False Pretenses, such as a payment induced by impersonating a vendor, employee, or business; the addenda carries the descriptor QUESTIONABLE", "An entry to an invalid account number that the RDFI believes was initiated under questionable circumstances", "A reversal on a non-consumer account that the receiver disputed, or one the RDFI itself identified as improper" ], "actions": [ "Read the return addenda first. The same code can mean a formatting fix, a fraud signal, or a reversal dispute, and each needs a different response", "If the addenda says QUESTIONABLE, treat it as a fraud signal: pause the counterparty relationship, check for account takeover or impersonation on your side, and review recent entries involving the same account", "If a field is identified, correct it and check whether other entries in the same file share the defect", "If a reversal came back, check it against the permitted reasons and timing for reversals. The original erroneous entry stands, and recovery now runs outside the reversal process" ], "retry": { "allowed": false, "rule": "Do not retry until the reason in the addenda is resolved. Never resend after a QUESTIONABLE return without independently confirming the counterparty." }, "facts": { "return_windows": [ { "action": "return", "by": "RDFI", "deadline": "2 banking days" } ], "wsud_required": false, "applies_to": "any", "counts_toward": [ "overall" ] }, "caveat": "The QUESTIONABLE use is optional for RDFIs and does not extend the return timeframe. R17 does not feed the unauthorized return rate even when it signals fraud, so fraud returned under R17 can be invisible in the metric most originators watch. [Inference] On consumer accounts, a disputed improper reversal returns as R11 within the 60 day window instead.", "related": [ "us-ach:R11", "us-ach:R03", "us-ach:R04", "us-ach:R06" ], "basis": { "sources": "Nacha public rule pages: Risk Management Topics, October 1, 2024 (codified R17 use with the QUESTIONABLE descriptor), and Reversals and Enforcement (R17 for improper reversals, effective 2021-06-30). Nacha Operating Rules, return reason code definitions (not consulted). Bank quick reference guide (cbsbank.com, secondary) for the invalid account number use.", "confidence": "medium" }, "currency": { "effective_since": "2024-10-01", "effective_to": null, "effective_note": "Return of improper reversals under R17 took effect 2021-06-30. Use for invalid account numbers initiated under questionable circumstances predates that [Unverified: date]. Broader use for suspected fraud with the QUESTIONABLE descriptor was codified 2024-10-01. Nacha Minor Topics rule change, in force 2026-01-01, clarified that the questionable use applies whether the RDFI decides before or after posting; Nacha describes the scope as unchanged (watch 2026-09-17).", "source_edition": "Nacha Operating Rules not consulted; the record rests on the sources listed in its basis and corroboration", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www21.bmo.com/olbbwem/olbb-static-file/non-secure/Documents/Help%20Centre%20uploads/ACH%20Return%20Reason%20Codes%20-%20US.PDF", "source_class": "secondary", "source_title": "ACH Return Reason Codes (BMO Treasury and Payment Solutions, May 2025)", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the 2 banking day return window taken by the RDFI and the file record edit criteria definition." }, { "source_url": "https://www.cbsbank.com/wp-content/uploads/2025/03/ACH-Return-Reason-Codes.pdf", "source_class": "secondary", "source_title": "CBS Bank, Quick Reference Guide: ACH Return Reason Codes and Time Frames, March 2025", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the 2 banking day return window taken by the RDFI and the file record edit criteria definition." } ] }, "rail_name": "US ACH", "governing_authority": "Nacha", "snapshot": "2026-09-16", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "us-ach:R18", "id": "R18", "rail": "us-ach", "kind": "reason-code", "name": "Improper effective entry date", "group": "administrative", "summary": "The ACH Operator returned the entry because its effective entry date fell outside the range the operator accepts relative to the processing date.", "triggers": [ "Effective entry date set too far ahead of processing; public guides describe the limits as more than two banking days for credits and more than one for debits [Unverified]", "A scheduling system computed the date with the wrong holiday or weekend calendar", "Warehousing logic released a file early" ], "actions": [ "Treat this as a file-building defect, not a receiver problem", "Check how your system computes the effective entry date, including holidays and weekends", "Rebuild the entry with a valid date and send it again" ], "retry": { "allowed": false, "rule": "Do not resend unchanged. Correct the effective entry date and originate the entry again." }, "facts": { "return_windows": [ { "action": "return", "by": "ACH Operator", "deadline": "At processing, when the entry is rejected" } ], "wsud_required": false, "applies_to": "any", "counts_toward": [ "overall" ] }, "caveat": "Operator returns are generated before the entry reaches the receiving institution, so the receiver never saw it. Nacha's public overall rate methodology says all return reason codes count; whether operator-generated returns are included in practice is [Unverified].", "related": [], "basis": { "sources": "Nacha Operating Rules, return reason code definitions and ACH record format specifications (not consulted); public bank quick reference guide (cbsbank.com, ACH Return Reason Codes and Time Frames, secondary), ACH Operator rejects section.", "confidence": "low" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "No material rule change identified for this entry.", "source_edition": "Nacha Operating Rules not consulted; the record rests on the sources listed in its basis and corroboration", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.cbsbank.com/wp-content/uploads/2025/03/ACH-Return-Reason-Codes.pdf", "source_class": "secondary", "source_title": "CBS Bank, Quick Reference Guide: ACH Return Reason Codes and Time Frames, March 2025", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms R18 is an ACH Operator reject with no separate RDFI return deadline, and confirms the trigger thresholds of more than two banking days ahead of processing for credits and more than one banking day for debits." } ] }, "rail_name": "US ACH", "governing_authority": "Nacha", "snapshot": "2026-09-16", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "us-ach:R19", "id": "R19", "rail": "us-ach", "kind": "reason-code", "name": "Amount field error", "group": "administrative", "summary": "The ACH Operator returned the entry because the amount field failed an edit.", "triggers": [ "Amount field contains non-numeric characters", "A non-zero amount in an entry type that must carry zero, such as a prenotification", "A zero amount in an entry type that must carry a value", "An ARC, BOC, or POP entry above the dollar limit for those SEC codes [Unverified: 25,000 dollars]" ], "actions": [ "Treat this as a file-building defect", "Check amount formatting: implied decimal, zero padding, and character set", "Confirm that prenotes and zero-dollar remittance entries are built with zero amounts and live entries are not" ], "retry": { "allowed": false, "rule": "Do not resend unchanged. Correct the amount field and originate the entry again." }, "facts": { "return_windows": [ { "action": "return", "by": "ACH Operator", "deadline": "At processing, when the entry is rejected" } ], "wsud_required": false, "applies_to": "any", "counts_toward": [ "overall" ] }, "caveat": "Operator returns are generated before the entry reaches the receiving institution, so the receiver never saw it. Nacha's public overall rate methodology says all return reason codes count; whether operator-generated returns are included in practice is [Unverified].", "related": [ "us-ach:R18" ], "basis": { "sources": "Nacha Operating Rules, return reason code definitions and ACH record format specifications (not consulted); public bank quick reference guide (cbsbank.com, ACH Return Reason Codes and Time Frames, secondary), ACH Operator rejects section.", "confidence": "low" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "No material rule change identified for this entry.", "source_edition": "Nacha Operating Rules not consulted; the record rests on the sources listed in its basis and corroboration", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.cbsbank.com/wp-content/uploads/2025/03/ACH-Return-Reason-Codes.pdf", "source_class": "secondary", "source_title": "CBS Bank, Quick Reference Guide: ACH Return Reason Codes and Time Frames, March 2025", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms R19 is an ACH Operator reject with no separate RDFI return deadline, confirms the zero and non-zero amount field triggers, and confirms the 25,000 dollar limit for ARC, BOC, and POP entries." } ] }, "rail_name": "US ACH", "governing_authority": "Nacha", "snapshot": "2026-09-16", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "us-ach:R20", "id": "R20", "rail": "us-ach", "kind": "reason-code", "name": "Non-transaction account", "group": "account", "summary": "The account exists but does not permit the transaction you sent. It is restricted from ACH activity of this type.", "triggers": [ "Savings or money-market account with transaction restrictions", "Entry directed at a loan, CD, escrow, or custodial account", "Receiver supplied a savings account number believing it was their checking account", "Institution reclassified the account after the authorization was captured" ], "actions": [ "Ask the receiver for a transaction account, normally checking. The person and the authorization are fine; the account is the wrong instrument", "Explain the reason. Most receivers have no idea their account carries ACH restrictions and will otherwise give you the same number again", "If you offer account selection during onboarding, capture account type and validate it there rather than discovering it in a return file" ], "retry": { "allowed": false, "rule": "Do not retry to the same account. Collect a transaction account and originate fresh." }, "facts": { "return_windows": [ { "action": "return", "by": "RDFI", "deadline": "2 banking days" } ], "wsud_required": false, "applies_to": "any", "counts_toward": [ "overall" ] }, "caveat": null, "related": [ "us-ach:R02" ], "basis": { "sources": "Nacha Operating Rules, return reason code definitions. Not part of the administrative return rate despite the name.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "No material rule change identified for this entry.", "source_edition": "Nacha Operating Rules not consulted; the record rests on the sources listed in its basis and corroboration", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.fhb.com/sites/default/files/2020-11/ACH_RET_Codes.pdf", "source_class": "secondary", "source_title": "ACH Return Reason Codes (First Hawaiian Bank)", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the 2 banking day return window taken by the RDFI and the non-transaction account definition." }, { "source_url": "https://www.cbsbank.com/wp-content/uploads/2025/03/ACH-Return-Reason-Codes.pdf", "source_class": "secondary", "source_title": "CBS Bank, Quick Reference Guide: ACH Return Reason Codes and Time Frames, March 2025", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the 2 banking day return window taken by the RDFI and the non-transaction account definition." } ] }, "rail_name": "US ACH", "governing_authority": "Nacha", "snapshot": "2026-09-16", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "us-ach:R21", "id": "R21", "rail": "us-ach", "kind": "reason-code", "name": "Invalid company identification", "group": "administrative", "summary": "The identification number carried in the company identification field is not valid for the entry as presented.", "triggers": [ "Company identification does not match what the ODFI holds on file for you", "Legal entity, EIN, or company name changed and the origination profile was never updated", "Batch header misconfiguration after a platform migration or a new origination setup", "On customer-initiated entries, the identification the biller expects does not match the one presented" ], "actions": [ "Look at the whole batch, not the single entry. R21 is an originator-level or batch-level defect and it rarely arrives alone", "Verify the company identification value against what your ODFI has registered for you", "Any recent change to entity, EIN, or DBA is the first thing to check. These changes routinely reach legal and finance and never reach the ACH origination profile", "Review batch header configuration in your origination platform, particularly after a migration" ], "retry": { "allowed": false, "rule": "Do not retry until the identification value is corrected with your ODFI. The same header produces the same return." }, "facts": { "return_windows": [ { "action": "return", "by": "RDFI", "deadline": "2 banking days" } ], "wsud_required": false, "applies_to": "CIE and others", "counts_toward": [ "overall" ] }, "caveat": "R21 usage varies more than most codes between institutions and entry types, and it appears most often on customer-initiated entries. If you see it outside that context, confirm the specific cause with your ODFI rather than assuming.", "related": [], "basis": { "sources": "Nacha Operating Rules, return reason code definitions. Scope and frequency by SEC code are drawn from institutional practice rather than a single rule citation.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "No material rule change identified for this entry.", "source_edition": "Nacha Operating Rules not consulted; the record rests on the sources listed in its basis and corroboration", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.fhb.com/sites/default/files/2020-11/ACH_RET_Codes.pdf", "source_class": "secondary", "source_title": "ACH Return Reason Codes (First Hawaiian Bank)", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the 2 banking day return window taken by the RDFI and the invalid company identification definition." }, { "source_url": "https://www.cbsbank.com/wp-content/uploads/2025/03/ACH-Return-Reason-Codes.pdf", "source_class": "secondary", "source_title": "CBS Bank, Quick Reference Guide: ACH Return Reason Codes and Time Frames, March 2025", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the 2 banking day return window taken by the RDFI and the invalid company identification definition." } ] }, "rail_name": "US ACH", "governing_authority": "Nacha", "snapshot": "2026-09-16", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "us-ach:R22", "id": "R22", "rail": "us-ach", "kind": "reason-code", "name": "Invalid individual ID number", "group": "administrative", "summary": "The receiver told its institution that the identification number the originator used is wrong. In CIE and MTE entries that number is how the receiver's account is identified.", "triggers": [ "A consumer bill payment (CIE) carried the wrong customer account number at the biller [Inference]", "An MTE entry carried an identifier the receiver does not recognize", "The identifier changed at the receiver and the originator is still using the old one" ], "actions": [ "Confirm the identifier and correct it before resending", "For bill payment services, check the customer's biller account number against the biller's format", "Check that the SEC code used was the right one for this payment" ], "retry": { "allowed": false, "rule": "Do not resend unchanged. Correct the identification number, then originate a new entry." }, "facts": { "return_windows": [ { "action": "return", "by": "RDFI", "deadline": "2 banking days" } ], "wsud_required": false, "applies_to": "CIE, MTE", "counts_toward": [ "overall" ] }, "caveat": "CIE entries are credits, so R22 on a CIE entry does not affect debit return rates; only R22 on an MTE debit does. [Inference] One public guide lists R22 with an operator-style timeframe rather than 2 banking days. [Unverified]", "related": [ "us-ach:R21" ], "basis": { "sources": "Nacha Operating Rules, return reason code definitions (not consulted); public bank quick reference guide (cbsbank.com, ACH Return Reason Codes and Time Frames, secondary); Nacha public overall return rate methodology.", "confidence": "low" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "No material rule change identified for this entry.", "source_edition": "Nacha Operating Rules not consulted; the record rests on the sources listed in its basis and corroboration", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.fhb.com/sites/default/files/2020-11/ACH_RET_Codes.pdf", "source_class": "secondary", "source_title": "ACH Return Reason Codes (First Hawaiian Bank)", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the 2 banking day return window taken by the RDFI and the invalid individual ID definition." }, { "source_url": "https://www.cbsbank.com/wp-content/uploads/2025/03/ACH-Return-Reason-Codes.pdf", "source_class": "secondary", "source_title": "CBS Bank, Quick Reference Guide: ACH Return Reason Codes and Time Frames, March 2025", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the 2 banking day return window taken by the RDFI and the invalid individual ID definition." } ] }, "rail_name": "US ACH", "governing_authority": "Nacha", "snapshot": "2026-09-16", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for Customer Initiated Entry (CIE), Machine Transfer Entry (MTE). Its own scope line reads: CIE, MTE.", "from": "applies_to" } ] }, { "uid": "us-ach:R23", "id": "R23", "rail": "us-ach", "kind": "reason-code", "name": "Credit entry refused by receiver", "group": "authorization", "summary": "The receiver told its institution that it will not accept a credit you sent, and the institution sent the credit back. The funds return to you. Nothing is necessarily wrong with the account.", "triggers": [ "The amount is not what the receiver requires: below a minimum, not the exact amount due, or an overpayment", "The receiver does not know the originator, or never agreed to receive this credit to this account", "The account is subject to litigation and the receiver will not accept the payment", "The receiver suspects the credit is tied to a scam or to funds it does not want to handle [Inference]" ], "actions": [ "Contact the receiver and find out why they refused before sending anything else", "If the amount was the problem, agree the correct amount in writing and send a new entry", "If the receiver does not know you, confirm the account details. A refused credit can mean the account belongs to someone other than your payee [Inference]", "For payouts, check whether the payee's bank details changed recently. A credit refused by an account holder who did not expect it can point to payee record tampering [Inference]", "Reconcile the returned funds so the obligation shows as unpaid, not paid" ], "retry": { "allowed": false, "rule": "Do not resend the same entry. The receiver has refused it. Send a new credit only after the receiver agrees to accept it and the amount and account are confirmed." }, "facts": { "return_windows": [ { "action": "return", "by": "RDFI", "deadline": "2 banking days after the RDFI receives the Receiver's notice of refusal" } ], "wsud_required": false, "applies_to": "credit entries, consumer or non-consumer", "counts_toward": [] }, "caveat": "The R23 clock runs from when the receiving institution learns of the refusal, not from settlement of the original credit, so an R23 can arrive well after the payment date. Whether any outer limit applies is [Unverified]. R23 applies to credits only, so it feeds none of the return rates, which measure debit returns. [Inference] Nacha's public tax refund guidance (May 2024) asks institutions to avoid R23 and R03 for suspicious tax refund credits and to use R17 instead.", "related": [ "us-ach:R17", "us-ach:R06" ], "basis": { "sources": "Nacha Operating Rules, return reason code definitions and return timeframes (not consulted). CBS Bank, Quick Reference Guide: ACH Return Reason Codes and Time Frames (https://www.cbsbank.com/wp-content/uploads/2025/03/ACH-Return-Reason-Codes.pdf, secondary), for the example refusal reasons and the timeframe running from notice of refusal. Nacha, Reminder: IRS and State Tax Refund Return Opt-In Programs Open 12 Months a Year (https://www.nacha.org/news/reminder-irs-and-state-tax-refund-return-opt-programs-open-12-months-year, May 2024, public_primary), for the R17 preference. Group is authorization because the return rests on the receiver's decision not to accept the credit, not on funds, account status, or data. counts_toward is empty by inference from the rates measuring debit returns.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "No material rule change identified for this code.", "source_edition": "Nacha Operating Rules not consulted; the record rests on the sources listed in its basis and corroboration", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.cbsbank.com/wp-content/uploads/2025/03/ACH-Return-Reason-Codes.pdf", "source_class": "secondary", "source_title": "CBS Bank, Quick Reference Guide: ACH Return Reason Codes and Time Frames, March 2025", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms the credit entry declined by receiver definition, its example refusal reasons including unknown originator and unauthorized credit, and that the two banking day return window runs from the RDFI's receipt of the receiver's notice of refusal rather than from settlement." } ] }, "rail_name": "US ACH", "governing_authority": "Nacha", "snapshot": "2026-09-16", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "debit or credit", "needs": "whether the entry is a debit or a credit", "detail": "This code is recorded for credits. Its own scope line reads: credit entries, consumer or non-consumer.", "from": "applies_to" } ] }, { "uid": "us-ach:R24", "id": "R24", "rail": "us-ach", "kind": "reason-code", "name": "Duplicate entry", "group": "administrative", "summary": "The receiving institution believes it has received the same entry twice: trace number, date, amount, or other data match an earlier entry.", "triggers": [ "A file was transmitted twice by the originator, a processor, or the ODFI", "A batch was reprocessed after a system failure without checking what had already settled", "Scheduling logic created two entries for one payment", "Separate legitimate payments of the same amount on the same day looked alike to the RDFI" ], "actions": [ "Confirm whether the first entry posted. If it did, the R24 did its job", "Check whether a reversal has already been sent for the duplicated file. A reversal plus an R24 can leave the receiver short or over, and unwinding it may need your ODFI", "If the entries were genuinely separate payments, contact the receiver before resending and make the entries distinguishable", "Fix the upstream control that let the duplicate through, such as file-level duplicate checks at the processor and ODFI" ], "retry": { "allowed": false, "rule": "Do not resend unless you have confirmed the returned entry was not a duplicate and the amount is still owed." }, "facts": { "return_windows": [ { "action": "return", "by": "RDFI", "deadline": "2 banking days" } ], "wsud_required": false, "applies_to": "any", "counts_toward": [ "overall" ] }, "caveat": "Public bank guides advise RDFIs to use R24 with care because the originator may already have reversed a duplicated file. [Unverified]", "related": [ "us-ach:R06", "us-ach:R17" ], "basis": { "sources": "Nacha Operating Rules, return reason code definitions (not consulted); public bank quick reference guide (cbsbank.com, ACH Return Reason Codes and Time Frames, secondary); Nacha public overall return rate methodology.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "No material rule change identified for this entry.", "source_edition": "Nacha Operating Rules not consulted; the record rests on the sources listed in its basis and corroboration", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.fhb.com/sites/default/files/2020-11/ACH_RET_Codes.pdf", "source_class": "secondary", "source_title": "ACH Return Reason Codes (First Hawaiian Bank)", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the 2 banking day return window taken by the RDFI and the duplicate entry definition." }, { "source_url": "https://www.cbsbank.com/wp-content/uploads/2025/03/ACH-Return-Reason-Codes.pdf", "source_class": "secondary", "source_title": "CBS Bank, Quick Reference Guide: ACH Return Reason Codes and Time Frames, March 2025", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the 2 banking day return window taken by the RDFI and the duplicate entry definition." } ] }, "rail_name": "US ACH", "governing_authority": "Nacha", "snapshot": "2026-09-16", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "us-ach:R25", "id": "R25", "rail": "us-ach", "kind": "reason-code", "name": "Addenda error", "group": "administrative", "summary": "The ACH Operator returned the entry because its addenda records failed an edit.", "triggers": [ "Addenda record indicator does not match whether addenda records follow", "Addenda type code invalid, missing, or out of sequence", "More addenda records than the SEC code allows", "Addenda sequence number invalid" ], "actions": [ "Treat this as a file-building defect", "Check the file builder's handling of the addenda indicator and sequence numbers, especially for SEC codes that carry many addenda such as CTX and IAT", "Validate files against the record format specifications before transmission" ], "retry": { "allowed": false, "rule": "Do not resend unchanged. Correct the addenda and originate the entry again." }, "facts": { "return_windows": [ { "action": "return", "by": "ACH Operator", "deadline": "At processing, when the entry is rejected" } ], "wsud_required": false, "applies_to": "any", "counts_toward": [ "overall" ] }, "caveat": "Operator returns are generated before the entry reaches the receiving institution, so the receiver never saw it. Nacha's public overall rate methodology says all return reason codes count; whether operator-generated returns are included in practice is [Unverified].", "related": [ "us-ach:R18", "us-ach:R19" ], "basis": { "sources": "Nacha Operating Rules, return reason code definitions and ACH record format specifications (not consulted); public bank quick reference guide (cbsbank.com, ACH Return Reason Codes and Time Frames, secondary), ACH Operator rejects section.", "confidence": "low" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "No material rule change identified for this entry.", "source_edition": "Nacha Operating Rules not consulted; the record rests on the sources listed in its basis and corroboration", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.cbsbank.com/wp-content/uploads/2025/03/ACH-Return-Reason-Codes.pdf", "source_class": "secondary", "source_title": "CBS Bank, Quick Reference Guide: ACH Return Reason Codes and Time Frames, March 2025", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms R25 is an ACH Operator reject with no separate RDFI return deadline and confirms the addenda record indicator, type code, sequence, and count triggers." } ] }, "rail_name": "US ACH", "governing_authority": "Nacha", "snapshot": "2026-09-16", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "us-ach:R26", "id": "R26", "rail": "us-ach", "kind": "reason-code", "name": "Mandatory field error", "group": "administrative", "summary": "The ACH Operator returned the entry because a field the rules treat as mandatory was missing or contained erroneous data.", "triggers": [ "Blank or invalid data in a mandatory field [Unverified: which fields are mandatory varies by record and SEC code]", "Data capture upstream let empty values into the file", "Invalid characters the operator treats as erroneous data" ], "actions": [ "Treat this as a file-building defect", "Identify the field, then fix validation at the point of data capture, not only in this file", "Check the record format specifications for the mandatory fields of the SEC code you used" ], "retry": { "allowed": false, "rule": "Do not resend unchanged. Correct the field and originate the entry again." }, "facts": { "return_windows": [ { "action": "return", "by": "ACH Operator", "deadline": "At processing, when the entry is rejected" } ], "wsud_required": false, "applies_to": "any", "counts_toward": [ "overall" ] }, "caveat": "Operator returns are generated before the entry reaches the receiving institution, so the receiver never saw it. Nacha's public overall rate methodology says all return reason codes count; whether operator-generated returns are included in practice is [Unverified].", "related": [ "us-ach:R25", "us-ach:R19" ], "basis": { "sources": "Nacha Operating Rules, return reason code definitions and ACH record format specifications (not consulted); public bank quick reference guide (cbsbank.com, ACH Return Reason Codes and Time Frames, secondary), ACH Operator rejects section.", "confidence": "low" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "No material rule change identified for this entry.", "source_edition": "Nacha Operating Rules not consulted; the record rests on the sources listed in its basis and corroboration", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www21.bmo.com/olbbwem/olbb-static-file/non-secure/Documents/Help%20Centre%20uploads/ACH%20Return%20Reason%20Codes%20-%20US.PDF", "source_class": "secondary", "source_title": "ACH Return Reason Codes (BMO Treasury and Payment Solutions, May 2025)", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the return happens at the next file delivery following processing rather than a banking day count, consistent with an ACH Operator reject, and the mandatory field error definition." } ] }, "rail_name": "US ACH", "governing_authority": "Nacha", "snapshot": "2026-09-16", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "us-ach:R27", "id": "R27", "rail": "us-ach", "kind": "reason-code", "name": "Trace number error", "group": "administrative", "summary": "The ACH Operator returned the entry because a trace number was missing or inconsistent.", "triggers": [ "A return or Notification of Change lacks the original entry trace number in its addenda", "An addenda record's trace number does not match the entry detail record it follows" ], "actions": [ "Treat this as a file-building defect", "If you originate, check that addenda trace numbers match the entry they follow", "If this came back on a return or Notification of Change you sent, check how your system carries the original trace number" ], "retry": { "allowed": false, "rule": "Do not resend unchanged. Correct the trace number and send the entry again." }, "facts": { "return_windows": [ { "action": "return", "by": "ACH Operator", "deadline": "At processing, when the entry is rejected" } ], "wsud_required": false, "applies_to": "any, including returns and Notifications of Change", "counts_toward": [ "overall" ] }, "caveat": "Operator returns are generated before the entry reaches the receiving institution, so the receiver never saw it. Nacha's public overall rate methodology says all return reason codes count; whether operator-generated returns are included in practice is [Unverified].", "related": [ "us-ach:R25", "us-ach:R26" ], "basis": { "sources": "Nacha Operating Rules, return reason code definitions and ACH record format specifications (not consulted); public bank quick reference guide (cbsbank.com, ACH Return Reason Codes and Time Frames, secondary), ACH Operator rejects section.", "confidence": "low" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "No material rule change identified for this entry.", "source_edition": "Nacha Operating Rules not consulted; the record rests on the sources listed in its basis and corroboration", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.cbsbank.com/wp-content/uploads/2025/03/ACH-Return-Reason-Codes.pdf", "source_class": "secondary", "source_title": "CBS Bank, Quick Reference Guide: ACH Return Reason Codes and Time Frames, March 2025", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms R27 is an ACH Operator reject with no separate RDFI return deadline and confirms the two trace number conditions: a missing original trace number in a return or Notification of Change addenda, and an addenda trace number that does not match the preceding entry detail record." } ] }, "rail_name": "US ACH", "governing_authority": "Nacha", "snapshot": "2026-09-16", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "us-ach:R28", "id": "R28", "rail": "us-ach", "kind": "reason-code", "name": "Routing number check digit error", "group": "administrative", "summary": "The ACH Operator returned the entry because the check digit on a routing number was invalid.", "triggers": [ "Routing number mistyped, so the check digit calculation fails", "Routing number truncated or padded incorrectly", "Check digit field populated separately from the routing number and out of step with it" ], "actions": [ "Validate every routing number with the check digit algorithm at the point of capture", "Confirm the routing number with the receiver", "Check that the file builder splits the routing number and check digit fields correctly" ], "retry": { "allowed": false, "rule": "Do not resend unchanged. Correct the routing number and originate the entry again." }, "facts": { "return_windows": [ { "action": "return", "by": "ACH Operator", "deadline": "At processing, when the entry is rejected" } ], "wsud_required": false, "applies_to": "any", "counts_toward": [ "overall" ] }, "caveat": "Operator returns are generated before the entry reaches the receiving institution, so the receiver never saw it. Nacha's public overall rate methodology says all return reason codes count; whether operator-generated returns are included in practice is [Unverified].", "related": [ "us-ach:R26" ], "basis": { "sources": "Nacha Operating Rules, return reason code definitions and ACH record format specifications (not consulted); public bank quick reference guide (cbsbank.com, ACH Return Reason Codes and Time Frames, secondary), ACH Operator rejects section.", "confidence": "low" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "No material rule change identified for this entry.", "source_edition": "Nacha Operating Rules not consulted; the record rests on the sources listed in its basis and corroboration", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www21.bmo.com/olbbwem/olbb-static-file/non-secure/Documents/Help%20Centre%20uploads/ACH%20Return%20Reason%20Codes%20-%20US.PDF", "source_class": "secondary", "source_title": "ACH Return Reason Codes (BMO Treasury and Payment Solutions, May 2025)", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the return happens at the next file delivery following processing rather than a banking day count, consistent with an ACH Operator reject, and the routing number check digit definition." } ] }, "rail_name": "US ACH", "governing_authority": "Nacha", "snapshot": "2026-09-16", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "us-ach:R29", "id": "R29", "rail": "us-ach", "kind": "reason-code", "name": "Corporate customer advises not authorized", "group": "authorization", "summary": "A business receiver has told its institution that a corporate debit, CCD or CTX, was not authorized.", "triggers": [ "Vendor relationship ended and debits continued past the final invoice", "The individual who authorized the arrangement has left the business", "Acquisition or restructuring left it unclear which entity is authorized to debit", "Commercial dispute over the contract, dressed up as an authorization problem", "Authorization was verbal or informal and cannot now be produced" ], "actions": [ "Treat it with the urgency of R10. It feeds the 0.5 percent unauthorized entry return rate threshold, as R10 does", "Pull the underlying agreement. Corporate authorizations rest on contract rather than Reg E, so the service agreement, purchase order, or signed debit authorization is the record that matters", "If your documentation is solid, this is likely a commercial dispute and belongs with your account team rather than your payments team", "Suspend recurring entries to the account while it is unresolved" ], "retry": { "allowed": false, "rule": "Do not retry. Resolve the authorization question in writing before any further entry." }, "facts": { "return_windows": [ { "action": "return", "by": "RDFI", "deadline": "2 banking days" } ], "wsud_required": false, "applies_to": "CCD, CTX", "counts_toward": [ "unauth", "overall" ] }, "caveat": "Two things separate R29 from R10 in practice. The window is two banking days, not sixty, because the consumer protections behind the longer window do not apply to business accounts. And no written statement is required, so there is less friction between a business receiver and the return. A corporate receiver that misses the two-day window may still send a late return, which the ODFI can dishonor as R68; that is a different conversation with your ODFI.", "related": [ "us-ach:R10", "us-ach:R05" ], "basis": { "sources": "Nacha Operating Rules, return reason code definitions, unauthorized entry return rate definition, return timeframes for non-consumer entries.", "confidence": "medium" }, "currency": { "effective_since": "2015-09-18", "effective_to": null, "effective_note": "Unauthorized return rate reduced to 0.5% effective 2015-09-18. Code definition is long-standing.", "source_edition": "Nacha Operating Rules not consulted; the record rests on the sources listed in its basis and corroboration", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.fhb.com/sites/default/files/2020-11/ACH_RET_Codes.pdf", "source_class": "secondary", "source_title": "ACH Return Reason Codes (First Hawaiian Bank)", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the 2 banking day return window taken by the RDFI and that the code is the non-consumer counterpart to the 60 day consumer unauthorized codes." }, { "source_url": "https://www.cbsbank.com/wp-content/uploads/2025/03/ACH-Return-Reason-Codes.pdf", "source_class": "secondary", "source_title": "CBS Bank, Quick Reference Guide: ACH Return Reason Codes and Time Frames, March 2025", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the 2 banking day return window taken by the RDFI and that the code is limited to a non-consumer receiver advising a specific entry was not authorized." } ] }, "rail_name": "US ACH", "governing_authority": "Nacha", "snapshot": "2026-09-16", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the account type", "needs": "whether the account is a consumer account or a business account", "detail": "This code is recorded for business accounts. Its own scope line reads: CCD, CTX.", "from": "applies_to" }, { "kind": "scope", "label": "debit or credit", "needs": "whether the entry is a debit or a credit", "detail": "This code is recorded for debits. Its own scope line reads: CCD, CTX.", "from": "applies_to" }, { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for Corporate Credit or Debit Entry (CCD), Corporate Trade Exchange (CTX). Its own scope line reads: CCD, CTX.", "from": "applies_to" } ] }, { "uid": "us-ach:R30", "id": "R30", "rail": "us-ach", "kind": "reason-code", "name": "RDFI not participant in check truncation program", "group": "check-conversion", "summary": "The receiving institution does not take part in the check truncation program under which the debit was sent, so it cannot accept the entry. It only arises on truncated check entries (TRC and TRX), which have had no forward volume for years.", "triggers": [ "A TRC or TRX entry was routed to an institution that never joined a check truncation program", "Legacy software or a test file still emits a truncation SEC code" ], "actions": [ "Confirm the SEC code on the returned entry. If you did not intend to send TRC or TRX, the fault is in your file build, not the receiver", "Collect the underlying check or obtain a different payment method from the payer. This receiving institution cannot take the entry in this form", "If you see R30 at all today, ask your ODFI whether the SEC code is still recognized in the current rules edition before doing anything else [Unverified]" ], "retry": { "allowed": false, "rule": "Do not resend the same truncated entry to the same institution. Its non-participation does not change between presentments." }, "facts": { "return_windows": [ { "action": "return", "by": "ACH Operator", "deadline": "Next file delivery time following processing [Unverified]" } ], "wsud_required": false, "applies_to": "TRC, TRX debit", "counts_toward": [ "overall" ] }, "caveat": "Nacha has said publicly that no forward check truncation entries have been sent since 2014, and it repurposed R11, the old truncation return code, in 2020. R30 still appears in secondary code lists and in a FedACH sample report dated 2017, but one current bank guide (BMO, May 2025) omits it. Whether R30 remains assigned in the current edition is open. [Unverified]", "related": [ "us-ach:R11" ], "basis": { "sources": "Drafted mostly from general knowledge. Nacha Operating Rules, return reason code definitions (not consulted). Nacha, Differentiating Unauthorized Return Reasons (https://www.nacha.org/rules/differentiating-unauthorized-return-reasons), for the absence of truncation volume since 2014. FedACH sample ACH Return Reason Report (https://www.frbservices.org/binaries/content/assets/crsocms/financial-services/ach/return-reason-report.xlsx), which lists R30 as a column. Modern Treasury return code reference (secondary) for the timeframe.", "confidence": "low" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "No material rule change identified for this code. Truncation entries have had no forward volume since 2014, per Nacha; current assignment status not confirmed.", "source_edition": "Nacha Operating Rules not consulted; the record rests on the sources listed in its basis and corroboration", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "rail_name": "US ACH", "governing_authority": "Nacha", "snapshot": "2026-09-16", "source_class": null, "effective_status": "draft", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "debit or credit", "needs": "whether the entry is a debit or a credit", "detail": "This code is recorded for debits. Its own scope line reads: TRC, TRX debit.", "from": "applies_to" }, { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for Check Truncation Entry (TRC), Check Truncation Entries Exchange (TRX). Its own scope line reads: TRC, TRX debit.", "from": "applies_to" } ] }, { "uid": "us-ach:R31", "id": "R31", "rail": "us-ach", "kind": "reason-code", "name": "Permissible return entry (CCD and CTX only)", "group": "administrative", "summary": "The receiving institution returned a corporate entry after the normal return deadline, and the ODFI agreed to accept that late return.", "triggers": [ "A business receiver found an unauthorized or erroneous corporate debit after the two banking day window for R29 had closed", "ODFI and RDFI agreed on a late return to settle a dispute", "A duplicate or erroneous CCD or CTX entry was found late" ], "actions": [ "Confirm with your ODFI that it agreed to this return. An R31 the ODFI did not agree to can be dishonored", "Find out the underlying reason. R31 says the return was permitted, not why it happened", "If the underlying reason is authorization, treat it as you would an R29 even though R31 does not feed Nacha's unauthorized entry return rate" ], "retry": { "allowed": false, "rule": "Do not retry until the underlying reason is resolved with the receiver in writing." }, "facts": { "return_windows": [ { "action": "return", "by": "RDFI", "deadline": "Not defined; set by agreement between ODFI and RDFI" } ], "wsud_required": false, "applies_to": "CCD, CTX", "counts_toward": [ "overall" ] }, "caveat": "R31 is the late-return path for corporate entries that are otherwise closed to returns after two banking days. Because it records ODFI consent rather than a cause, unauthorized corporate debits returned late through R31 do not show in the unauthorized rate. [Inference]", "related": [ "us-ach:R29" ], "basis": { "sources": "Nacha Operating Rules, return reason code definitions and late return provisions (not consulted); public bank quick reference guide (cbsbank.com, ACH Return Reason Codes and Time Frames, secondary); Nacha public unauthorized and overall return rate methodology.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "No material rule change identified for this entry.", "source_edition": "Nacha Operating Rules not consulted; the record rests on the sources listed in its basis and corroboration", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.fhb.com/sites/default/files/2020-11/ACH_RET_Codes.pdf", "source_class": "secondary", "source_title": "ACH Return Reason Codes (First Hawaiian Bank)", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the return window is negotiated between ODFI and RDFI rather than fixed, taken by the RDFI, for CCD and CTX entries." }, { "source_url": "https://www.cbsbank.com/wp-content/uploads/2025/03/ACH-Return-Reason-Codes.pdf", "source_class": "secondary", "source_title": "CBS Bank, Quick Reference Guide: ACH Return Reason Codes and Time Frames, March 2025", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the return window is negotiated between ODFI and RDFI rather than fixed, taken by the RDFI, for CCD and CTX entries." } ] }, "rail_name": "US ACH", "governing_authority": "Nacha", "snapshot": "2026-09-16", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the account type", "needs": "whether the account is a consumer account or a business account", "detail": "This code is recorded for business accounts. Its own scope line reads: CCD, CTX.", "from": "applies_to" }, { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for Corporate Credit or Debit Entry (CCD), Corporate Trade Exchange (CTX). Its own scope line reads: CCD, CTX.", "from": "applies_to" } ] }, { "uid": "us-ach:R32", "id": "R32", "rail": "us-ach", "kind": "reason-code", "name": "RDFI non-settlement", "group": "network", "summary": "The receiving institution could not settle the entry, so the entry comes back without ever reaching the receiver's account. The problem sits between institutions and the operator, not with your receiver or your data.", "triggers": [ "The receiving institution has failed, been closed, or had its settlement arrangements suspended", "The receiving institution lacks a working settlement account or correspondent arrangement with the ACH Operator", "An institution in transition, for example after a merger or charter change, is not yet set up to settle under the routing number used [Inference]" ], "actions": [ "Tell your ODFI immediately. A non-settlement return can signal a failing or restricted institution, and your ODFI may already know which", "Check whether other entries to the same routing number came back the same way. If so, hold further entries to that routing number", "Contact the receiver for an alternate account or payment method. Nothing is wrong with their instruction as such, but their institution cannot settle", "For payouts, confirm the receiver was not paid by another channel before paying again" ], "retry": { "allowed": false, "rule": "Do not resend automatically. Send a new entry only after your ODFI confirms the receiving institution can settle again, or to a different account the receiver supplies." }, "facts": { "return_windows": [ { "action": "return", "by": "ACH Operator", "deadline": "Next file delivery time following processing" } ], "wsud_required": false, "applies_to": "any entry, credit or debit", "counts_toward": [ "overall" ] }, "caveat": "The overall return rate counts debit entries returned for any reason, so an R32 on a debit counts toward it and an R32 on a credit does not feed any rate. [Inference] R32 is generally described as initiated on the operator side rather than by a receiver claim, but which party originates it in each case is not confirmed here. [Unverified]", "related": [], "basis": { "sources": "Drafted mostly from general knowledge. Nacha Operating Rules, return reason code definitions (not consulted). Nacha, How to calculate administrative or overall return rate levels (https://www.nacha.org/system/files/2024-01/Calculate_Admin_or_Overall_Return_Rate.pdf), for the overall rate counting debits returned for any reason. BMO ACH Return Reason Codes guide, May 2025 (secondary), for the timeframe.", "confidence": "low" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "No material rule change identified for this code.", "source_edition": "Nacha Operating Rules not consulted; the record rests on the sources listed in its basis and corroboration", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "rail_name": "US ACH", "governing_authority": "Nacha", "snapshot": "2026-09-16", "source_class": null, "effective_status": "draft", "effective_status_reason": null, "boundaries": [] }, { "uid": "us-ach:R33", "id": "R33", "rail": "us-ach", "kind": "reason-code", "name": "Return of XCK entry", "group": "check-conversion", "summary": "The receiving institution chose to return a destroyed check entry (XCK). It needs no reason beyond its own discretion, so the return says nothing definite about the payer or the account.", "triggers": [ "The receiving institution declines to honor XCK entries as a matter of policy", "The payer disputes the underlying check once it appears as an electronic debit", "The receiving institution cannot match the entry to a check it would have paid [Inference]" ], "actions": [ "Treat the underlying check as unpaid. The XCK route to collect it is closed for this item", "Pursue the item through whatever non-ACH process your institution uses for lost or destroyed checks, such as a copy or affidavit presented through check channels [Inference]", "Do not read the return as a funds or authorization problem unless the receiving institution tells you so" ], "retry": { "allowed": false, "rule": "Do not resend the item as XCK. The receiving institution has already exercised its discretion on it." }, "facts": { "return_windows": [ { "action": "return", "by": "RDFI", "deadline": "60 calendar days" } ], "wsud_required": false, "applies_to": "XCK debit", "counts_toward": [ "overall" ] }, "caveat": "XCK is originated by financial institutions for checks lost or destroyed in processing, not by ordinary businesses, so most originators will never see R33. The XCK rules also limit which items qualify; those limits are not restated here. [Unverified]", "related": [], "basis": { "sources": "Drafted mostly from general knowledge. Nacha Operating Rules, XCK entry rules and return reason code definitions (not consulted). BMO ACH Return Reason Codes guide, May 2025 (secondary), for the sole-discretion basis and the 60 calendar day timeframe. Nacha, How to calculate administrative or overall return rate levels (https://www.nacha.org/system/files/2024-01/Calculate_Admin_or_Overall_Return_Rate.pdf), for the overall rate counting debits returned for any reason.", "confidence": "low" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "No material rule change identified for this code.", "source_edition": "Nacha Operating Rules not consulted; the record rests on the sources listed in its basis and corroboration", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www21.bmo.com/olbbwem/olbb-static-file/non-secure/Documents/Help%20Centre%20uploads/ACH%20Return%20Reason%20Codes%20-%20US.PDF", "source_class": "secondary", "source_title": "ACH Return Reason Codes (BMO Treasury and Payment Solutions, May 2025)", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the 60 calendar day return window taken by the RDFI for XCK entries." }, { "source_url": "https://www.cbsbank.com/wp-content/uploads/2025/03/ACH-Return-Reason-Codes.pdf", "source_class": "secondary", "source_title": "CBS Bank, Quick Reference Guide: ACH Return Reason Codes and Time Frames, March 2025", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the 60 calendar day return window taken by the RDFI for XCK entries." } ] }, "rail_name": "US ACH", "governing_authority": "Nacha", "snapshot": "2026-09-16", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "debit or credit", "needs": "whether the entry is a debit or a credit", "detail": "This code is recorded for debits. Its own scope line reads: XCK debit.", "from": "applies_to" }, { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for Destroyed Check Entry (XCK). Its own scope line reads: XCK debit.", "from": "applies_to" } ] }, { "uid": "us-ach:R34", "id": "R34", "rail": "us-ach", "kind": "reason-code", "name": "Limited participation DFI", "group": "network", "summary": "A federal or state supervisor has limited the receiving institution's participation in the ACH Network, and this entry falls outside what it is still allowed to receive.", "triggers": [ "A regulator has restricted the receiving institution, for example under an enforcement action or during a wind-down", "The restriction covers the entry type or direction you sent, such as debits, while other activity continues [Inference]" ], "actions": [ "Tell your ODFI. A supervisory restriction on a receiving institution is information your ODFI should act on across all its originators", "Hold further entries to that routing number until you know what the restriction covers", "Ask the receiver for an account at a different institution, or another payment method", "For payouts, confirm the receiver was not paid by another channel before paying again" ], "retry": { "allowed": false, "rule": "Do not resend to the same institution while the restriction stands. Send a new entry only to a different account, or after your ODFI confirms the restriction no longer applies." }, "facts": { "return_windows": [ { "action": "return", "by": "ACH Operator", "deadline": "Next file delivery time following processing [Unverified]" } ], "wsud_required": false, "applies_to": "any entry, credit or debit", "counts_toward": [ "overall" ] }, "caveat": "Public sources disagree on the timeframe: some processor guides give two banking days, others the next file delivery time following processing, and one current bank guide (BMO, May 2025) omits R34 altogether. Which party initiates R34 is not confirmed here. The overall return rate counts debits returned for any reason, so R34 on a credit feeds no rate. [Inference]", "related": [ "us-ach:R32" ], "basis": { "sources": "Drafted mostly from general knowledge. Nacha Operating Rules, return reason code definitions (not consulted). FedACH sample ACH Return Reason Report (https://www.frbservices.org/binaries/content/assets/crsocms/financial-services/ach/return-reason-report.xlsx), which lists R34 as a column. Processor return code references (secondary) for the conflicting timeframes. Nacha, How to calculate administrative or overall return rate levels (https://www.nacha.org/system/files/2024-01/Calculate_Admin_or_Overall_Return_Rate.pdf), for the overall rate definition.", "confidence": "low" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "No material rule change identified for this code; current assignment status not confirmed.", "source_edition": "Nacha Operating Rules not consulted; the record rests on the sources listed in its basis and corroboration", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "rail_name": "US ACH", "governing_authority": "Nacha", "snapshot": "2026-09-16", "source_class": null, "effective_status": "draft", "effective_status_reason": null, "boundaries": [] }, { "uid": "us-ach:R35", "id": "R35", "rail": "us-ach", "kind": "reason-code", "name": "Return of improper debit entry", "group": "administrative", "summary": "A debit was sent where debits are not permitted: to a loan account, or as a CIE entry, other than a reversal.", "triggers": [ "Debit to a loan account instead of a checking or savings account", "Debit sent under the CIE SEC code, which carries credits only", "Transaction code for a loan account used on a debit" ], "actions": [ "Check the transaction code and account type captured for this receiver", "Obtain a debitable account from the receiver if you still need to collect", "Fix SEC code selection so CIE is never used for debits" ], "retry": { "allowed": false, "rule": "Do not resend to the same account. Obtain an eligible account and correct the transaction code first." }, "facts": { "return_windows": [ { "action": "return", "by": "ACH Operator", "deadline": "At processing, when the entry is rejected" } ], "wsud_required": false, "applies_to": "debits to loan accounts; CIE debits; reversals excepted", "counts_toward": [ "overall" ] }, "caveat": "Public bank guides list R35 among ACH Operator returns. [Unverified] whether RDFIs may also use it. Operator returns are generated before the entry reaches the receiving institution, so the receiver never saw it. Nacha's public overall rate methodology says all return reason codes count; whether operator-generated returns are included in practice is [Unverified].", "related": [ "us-ach:R20" ], "basis": { "sources": "Nacha Operating Rules, return reason code definitions and ACH record format specifications (not consulted); public bank quick reference guide (cbsbank.com, ACH Return Reason Codes and Time Frames, secondary), ACH Operator rejects section.", "confidence": "low" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "No material rule change identified for this entry.", "source_edition": "Nacha Operating Rules not consulted; the record rests on the sources listed in its basis and corroboration", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.cbsbank.com/wp-content/uploads/2025/03/ACH-Return-Reason-Codes.pdf", "source_class": "secondary", "source_title": "CBS Bank, Quick Reference Guide: ACH Return Reason Codes and Time Frames, March 2025", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms R35 is an ACH Operator reject with no separate RDFI return deadline and confirms that debit entries are not permitted for CIE entries or to loan accounts, except reversals." } ] }, "rail_name": "US ACH", "governing_authority": "Nacha", "snapshot": "2026-09-16", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "debit or credit", "needs": "whether the entry is a debit or a credit", "detail": "This code is recorded for debits. Its own scope line reads: debits to loan accounts; CIE debits; reversals excepted.", "from": "applies_to" } ] }, { "uid": "us-ach:R36", "id": "R36", "rail": "us-ach", "kind": "reason-code", "name": "Return of improper credit entry", "group": "administrative", "summary": "The ACH Operator returned a credit sent under an SEC code that carries debits only, such as ARC, BOC, POP, RCK, TEL, or XCK. Reversals are the exception.", "triggers": [ "A refund to a consumer sent under the same SEC code as the original check conversion or telephone debit", "Origination software that stamps the batch SEC code on every entry, credits included [Inference]", "A correction credit sent under a debit-only SEC code instead of as a properly formatted reversal" ], "actions": [ "Resend the credit under an SEC code that permits credits, with whatever authorization that code requires [Inference]", "If you meant to correct an erroneous debit, use the reversal process within its time limits instead", "Put credits in their own batch with the right SEC code, and add an edit that blocks credits under debit-only codes" ], "retry": { "allowed": false, "rule": "Do not resend under the same SEC code. Originate the credit again under an SEC code that permits credits, or as a properly formatted reversal." }, "facts": { "return_windows": [ { "action": "return", "by": "ACH Operator", "deadline": "At processing, when the entry is rejected" } ], "wsud_required": false, "applies_to": "credits under ARC, BOC, POP, RCK, TEL, XCK; reversals excepted", "counts_toward": [] }, "caveat": "Public bank guides list R36 among ACH Operator returns, as the credit counterpart of R35. [Unverified] whether RDFIs may also use it. Operator returns are generated before the entry reaches the receiving institution, so the receiver never saw the credit and was never paid. R36 applies to credits only, so it feeds no return rate. [Inference] The list of debit-only SEC codes comes from one secondary guide, CBS Bank's Quick Reference Guide: ACH Return Reason Codes and Time Frames. [Unverified]", "related": [ "us-ach:R35" ], "basis": { "sources": "Drafted mostly from general knowledge. Nacha Operating Rules, return reason code definitions and SEC code rules (not consulted). CBS Bank, Quick Reference Guide: ACH Return Reason Codes and Time Frames (https://www.cbsbank.com/wp-content/uploads/2025/03/ACH-Return-Reason-Codes.pdf, secondary), ACH Operator rejects section, for the definition and the SEC code list. Group is administrative, matching its debit counterpart R35: Orca's US ACH rail brief (docs/rails/us-ach.md) reserves network for R13, R32, and R34, and although R36 is generated by the ACH Operator, its cause is an origination coding error, not a condition of an institution or the network. counts_toward is empty because R36 applies only to credits.", "confidence": "low" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "No material rule change identified for this code.", "source_edition": "Nacha Operating Rules not consulted; the record rests on the sources listed in its basis and corroboration", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.cbsbank.com/wp-content/uploads/2025/03/ACH-Return-Reason-Codes.pdf", "source_class": "secondary", "source_title": "CBS Bank, Quick Reference Guide: ACH Return Reason Codes and Time Frames, March 2025", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms the return of improper credit entry definition, the ARC, BOC, POP, RCK, TEL and XCK code list with the reversal exception, and that it is an ACH Operator reject returned at processing with no separate RDFI deadline." } ] }, "rail_name": "US ACH", "governing_authority": "Nacha", "snapshot": "2026-09-16", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "debit or credit", "needs": "whether the entry is a debit or a credit", "detail": "This code is recorded for credits. Its own scope line reads: credits under ARC, BOC, POP, RCK, TEL, XCK; reversals excepted.", "from": "applies_to" }, { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for Accounts Receivable Entry (ARC), Back Office Conversion Entry (BOC), Point-of-Purchase Entry (POP), Re-presented Check Entry (RCK), Telephone-Initiated Entry (TEL), Destroyed Check Entry (XCK). Its own scope line reads: credits under ARC, BOC, POP, RCK, TEL, XCK; reversals excepted.", "from": "applies_to" } ] }, { "uid": "us-ach:R37", "id": "R37", "rail": "us-ach", "kind": "reason-code", "name": "Source document presented for payment", "group": "check-conversion", "summary": "The payer told their institution that the check behind a converted entry (ARC, BOC, or POP) was also presented and paid, so they were charged twice for one item.", "triggers": [ "A converted check was also deposited, by you, a lockbox provider, or a downstream party", "The check image was sent through check clearing after the ACH entry was created", "At the point of sale, the check was not voided and handed back, and later entered check clearing [Inference]" ], "actions": [ "Confirm whether the check was paid. If it was, the payer is right and the ACH debit was a duplicate", "Close the receivable on the check payment and do not collect again", "Trace how the item reached check clearing and close that gap. Converted items must be retained or destroyed under your procedures, not deposited", "If the check was not in fact paid, discuss the return with your ODFI before approaching the payer" ], "retry": { "allowed": false, "rule": "Do not resend the entry. The item has already been paid once." }, "facts": { "return_windows": [ { "action": "return", "by": "RDFI", "deadline": "60 calendar days" } ], "wsud_required": true, "applies_to": "ARC, BOC, POP debit", "counts_toward": [ "overall" ] }, "caveat": "R37 rests on the receiver's claim and uses the extended window; R39 covers the same event when the receiving institution finds it on its own within two banking days. R37 is not among the codes Nacha lists for the unauthorized return rate, so it counts toward Nacha's overall return rate only. Whether a written statement is required for R37 is not confirmed here. [Unverified]", "related": [ "us-ach:R39", "us-ach:R38", "us-ach:R11" ], "basis": { "sources": "Drafted mostly from general knowledge. Nacha Operating Rules, ARC, BOC, and POP rules, return reason code definitions, and WSUD requirements (not consulted). Nacha, Differentiating Unauthorized Return Reasons (https://www.nacha.org/rules/differentiating-unauthorized-return-reasons), for R37 and R39 applying where source documents were already paid. Nacha, How to Calculate Unauthorized Return Rate (https://www.nacha.org/system/files/2024-01/Calculate_Unauthorized_Return_Rate.pdf), for R37 falling outside the unauthorized code list. BMO ACH Return Reason Codes guide, May 2025 (secondary), for the 60 calendar day timeframe.", "confidence": "low" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Code definition is long-standing. Its boundary with R11 was clarified by the 2020 R10 and R11 rule change, effective 2020-04-01.", "source_edition": "Nacha Operating Rules not consulted; the record rests on the sources listed in its basis and corroboration", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www21.bmo.com/olbbwem/olbb-static-file/non-secure/Documents/Help%20Centre%20uploads/ACH%20Return%20Reason%20Codes%20-%20US.PDF", "source_class": "secondary", "source_title": "ACH Return Reason Codes (BMO Treasury and Payment Solutions, May 2025)", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the 60 calendar day return window taken by the RDFI and that the code applies to ARC, BOC, and POP entries whose source document was presented for payment." }, { "source_url": "https://www.cbsbank.com/wp-content/uploads/2025/03/ACH-Return-Reason-Codes.pdf", "source_class": "secondary", "source_title": "CBS Bank, Quick Reference Guide: ACH Return Reason Codes and Time Frames, March 2025", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the 60 calendar day return window taken by the RDFI and that the code applies to ARC, BOC, and POP entries whose source document was presented for payment." } ] }, "rail_name": "US ACH", "governing_authority": "Nacha", "snapshot": "2026-09-16", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "debit or credit", "needs": "whether the entry is a debit or a credit", "detail": "This code is recorded for debits. Its own scope line reads: ARC, BOC, POP debit.", "from": "applies_to" }, { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for Accounts Receivable Entry (ARC), Back Office Conversion Entry (BOC), Point-of-Purchase Entry (POP). Its own scope line reads: ARC, BOC, POP debit.", "from": "applies_to" } ] }, { "uid": "us-ach:R38", "id": "R38", "rail": "us-ach", "kind": "reason-code", "name": "Stop payment on source document", "group": "check-conversion", "summary": "The payer had placed a stop payment on the check that you converted to an ACH debit (ARC or BOC), and the receiving institution applied that stop to the converted entry.", "triggers": [ "The payer mailed or handed over a check, then stopped payment on it before it cleared", "The payer disputes the underlying bill or purchase and used a check stop rather than an ACH dispute", "The payer believed the check was lost and stopped it, not knowing it had been converted" ], "actions": [ "Treat it as a check stop payment, not an ACH authorization problem. Contact the payer and find out why they stopped the check", "If the payer thought the check was lost, explain that it was received and converted, and ask for a replacement payment", "If the payer is disputing the underlying debt, route it to your collections or dispute process", "Check your conversion notice and timing. A long gap between receiving a check and converting it invites lost-check stops [Inference]" ], "retry": { "allowed": false, "rule": "Do not reconvert or resend the same check. Get a new payment from the payer." }, "facts": { "return_windows": [ { "action": "return", "by": "RDFI", "deadline": "60 calendar days" } ], "wsud_required": false, "applies_to": "ARC, BOC debit", "counts_toward": [ "overall" ] }, "caveat": "POP is generally not listed for R38, since at the point of sale the check is voided and handed back, leaving no live check to stop. [Inference] Whether the extended window rests on a receiver statement or on the stop payment order itself is not confirmed here. [Unverified]", "related": [ "us-ach:R08", "us-ach:R39" ], "basis": { "sources": "Drafted mostly from general knowledge. Nacha Operating Rules, ARC and BOC rules and return reason code definitions (not consulted). BMO ACH Return Reason Codes guide, May 2025 (secondary), for the ARC and BOC scope and the 60 calendar day timeframe. Nacha, How to calculate administrative or overall return rate levels (https://www.nacha.org/system/files/2024-01/Calculate_Admin_or_Overall_Return_Rate.pdf), for the overall rate definition.", "confidence": "low" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "No material rule change identified for this code.", "source_edition": "Nacha Operating Rules not consulted; the record rests on the sources listed in its basis and corroboration", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www21.bmo.com/olbbwem/olbb-static-file/non-secure/Documents/Help%20Centre%20uploads/ACH%20Return%20Reason%20Codes%20-%20US.PDF", "source_class": "secondary", "source_title": "ACH Return Reason Codes (BMO Treasury and Payment Solutions, May 2025)", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the 60 calendar day return window taken by the RDFI and that the code applies to ARC and BOC entries with a stop payment on the source document." }, { "source_url": "https://www.cbsbank.com/wp-content/uploads/2025/03/ACH-Return-Reason-Codes.pdf", "source_class": "secondary", "source_title": "CBS Bank, Quick Reference Guide: ACH Return Reason Codes and Time Frames, March 2025", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the 60 calendar day return window taken by the RDFI and that the code applies to ARC and BOC entries with a stop payment on the source document." } ] }, "rail_name": "US ACH", "governing_authority": "Nacha", "snapshot": "2026-09-16", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "debit or credit", "needs": "whether the entry is a debit or a credit", "detail": "This code is recorded for debits. Its own scope line reads: ARC, BOC debit.", "from": "applies_to" }, { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for Accounts Receivable Entry (ARC), Back Office Conversion Entry (BOC). Its own scope line reads: ARC, BOC debit.", "from": "applies_to" } ] }, { "uid": "us-ach:R39", "id": "R39", "rail": "us-ach", "kind": "reason-code", "name": "Improper source document or source document presented for payment", "group": "check-conversion", "summary": "The receiving institution itself found a problem with the check behind a converted entry (ARC, BOC, or POP): the check was not eligible for conversion, or the check was also paid. This is the institution's own finding, returned fast, rather than a customer claim.", "triggers": [ "An ineligible item was converted, such as a check type the conversion rules exclude [Unverified]", "The paper check was deposited or presented after being converted, and the receiving institution paid the check", "Duplicate processing at a lockbox or point of sale sent both the image or item and the ACH entry" ], "actions": [ "Find out which failure it was. An ineligible item is a capture rule problem; a double presentment is a process control problem", "For double presentment, confirm the check was paid and close the receivable. Do not collect twice", "Audit your conversion capture: item eligibility checks at scan time, and controls that stop a converted check from also being deposited", "If R39 recurs at one location or lockbox, fix that site before converting more items there" ], "retry": { "allowed": false, "rule": "Do not resend the converted entry. If the check was already paid there is nothing to collect; if the item was ineligible, collect it through check channels or another method." }, "facts": { "return_windows": [ { "action": "return", "by": "RDFI", "deadline": "2 banking days" } ], "wsud_required": false, "applies_to": "ARC, BOC, POP debit", "counts_toward": [ "overall" ] }, "caveat": "R39 and R37 can describe the same underlying event, a check paid alongside its ACH conversion. The difference is who raises it: R39 is the receiving institution's own determination on the short window, while R37 rests on the receiver's claim on the extended window. Since the 2020 R10 and R11 changes, Nacha has pointed to R37 and R39, not R11, for source documents already paid. One current bank guide (BMO, May 2025) omits R39. [Unverified]", "related": [ "us-ach:R11", "us-ach:R10" ], "basis": { "sources": "Drafted mostly from general knowledge. Nacha Operating Rules, ARC, BOC, and POP rules and return reason code definitions (not consulted). Nacha, Differentiating Unauthorized Return Reasons (https://www.nacha.org/rules/differentiating-unauthorized-return-reasons), for R37 and R39 applying where source documents were already paid. Modern Treasury return code reference (secondary) for the timeframe.", "confidence": "low" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Code definition is long-standing. Its boundary with R11 was clarified by the 2020 R10 and R11 rule change, effective 2020-04-01.", "source_edition": "Nacha Operating Rules not consulted; the record rests on the sources listed in its basis and corroboration", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.cbsbank.com/wp-content/uploads/2025/03/ACH-Return-Reason-Codes.pdf", "source_class": "secondary", "source_title": "CBS Bank, Quick Reference Guide: ACH Return Reason Codes and Time Frames, March 2025", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms the 2 banking day window and the RDFI's own determination that a source document was improper or presented for payment alongside the ARC, BOC, or POP entry." } ] }, "rail_name": "US ACH", "governing_authority": "Nacha", "snapshot": "2026-09-16", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "debit or credit", "needs": "whether the entry is a debit or a credit", "detail": "This code is recorded for debits. Its own scope line reads: ARC, BOC, POP debit.", "from": "applies_to" }, { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for Accounts Receivable Entry (ARC), Back Office Conversion Entry (BOC), Point-of-Purchase Entry (POP). Its own scope line reads: ARC, BOC, POP debit.", "from": "applies_to" } ] }, { "uid": "us-ach:R40", "id": "R40", "rail": "us-ach", "kind": "reason-code", "name": "Return of ENR entry by federal government agency", "group": "enrollment", "summary": "The federal agency named in the enrollment does not take automated enrollments, so it returned the ENR unprocessed. The customer is not enrolled for direct deposit through this entry.", "triggers": [ "ENR sent to an agency or benefit program outside the ENR program. The Green Book lists Social Security, SSI, VA benefits, OPM civil service annuities, and Railroad Retirement annuities as ENR payments", "ENR addressed to the wrong agency identifier for the customer's benefit [Inference]", "Enrollment for a federal payment type that uses its own enrollment process, such as federal salary or tax refunds [Inference]" ], "actions": [ "Tell the customer the enrollment did not take effect and that payments continue as before until they enroll another way", "Enroll through another method: the Go Direct website, the Treasury Electronic Payment Solution Center by phone with the customer present, FS Form 1200, or the paying agency directly", "Check your list of participating agencies and programs against the current Green Book" ], "retry": { "allowed": false, "rule": "Do not resend the ENR to the same agency. Use another enrollment method." }, "facts": { "return_windows": [ { "action": "return", "by": "Federal government agency", "deadline": "No return timeframe stated in the public sources consulted" } ], "wsud_required": false, "applies_to": "ENR (automated enrollment) entries only", "counts_toward": [] }, "caveat": "The Green Book titles R40 as the agency not participating in the ENR program; the CBS Bank guide gives the title used here and the same meaning. An ENR is a zero-dollar enrollment entry that a financial institution sends to a federal benefit agency for its customer, so the reader of this return is that institution, not a business originator. No money moved and no return rate is affected. An ENR that fails the ACH Operator's own edits is rejected with an operator code and never reaches the agency. No public source consulted gives the agency a deadline for this return. [Unverified]", "related": [], "basis": { "sources": "Nacha Operating Rules, return reason code definitions for ENR entries (not consulted). Bureau of the Fiscal Service, Green Book: A Guide to Federal Government ACH Payments, chapter 1, section F, Return Reason Codes and ENR Addenda Record (https://tfx.treasury.gov/system/files/2025-03/greenbook-chapter1.pdf, public_primary for federal ENR practice, not the Nacha rulebook). CBS Bank, Quick Reference Guide: ACH Return Reason Codes and Time Frames (https://www.cbsbank.com/wp-content/uploads/2025/03/ACH-Return-Reason-Codes.pdf, secondary), section on codes used by federal government agencies returning ENR entries. BMO ACH Return Reason Codes guide, May 2025 (secondary), which lists the ENR codes with no timeframe. Group is enrollment per Orca's US ACH rail brief (docs/rails/us-ach.md). counts_toward is empty by inference: an ENR carries no dollar amount and is not a debit, and the return rates measure debit returns.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "No material rule change identified for this code.", "source_edition": "Nacha Operating Rules not consulted; the record rests on the sources listed in its basis and corroboration", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "rail_name": "US ACH", "governing_authority": "Nacha", "snapshot": "2026-09-16", "source_class": null, "effective_status": "draft", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for Automated Enrollment Entry (ENR). Its own scope line reads: ENR (automated enrollment) entries only.", "from": "applies_to" } ] }, { "uid": "us-ach:R41", "id": "R41", "rail": "us-ach", "kind": "reason-code", "name": "Invalid transaction code", "group": "enrollment", "summary": "The transaction code inside the ENR addenda, which tells the agency whether to pay to checking or savings, is invalid or not appropriate for an enrollment.", "triggers": [ "A code other than the checking or savings credit code in the addenda. The Green Book sample shows 22 for checking and 32 for savings", "Account type captured wrong at enrollment", "Enrollment software filling the field with a default or a debit code [Inference]" ], "actions": [ "Confirm with the customer whether the benefit should go to checking or savings", "Correct the transaction code and send a new ENR, or enroll by another method", "Tell the customer the enrollment did not take effect" ], "retry": { "allowed": false, "rule": "Do not resend unchanged. Correct the transaction code, then send a new ENR, or enroll another way." }, "facts": { "return_windows": [ { "action": "return", "by": "Federal government agency", "deadline": "No return timeframe stated in the public sources consulted" } ], "wsud_required": false, "applies_to": "ENR (automated enrollment) entries only", "counts_toward": [] }, "caveat": "An ENR is a zero-dollar enrollment entry that a financial institution sends to a federal benefit agency for its customer, so the reader of this return is that institution, not a business originator. No money moved and no return rate is affected. An ENR that fails the ACH Operator's own edits is rejected with an operator code and never reaches the agency. No public source consulted gives the agency a deadline for this return. [Unverified]", "related": [ "us-ach:R40" ], "basis": { "sources": "Nacha Operating Rules, return reason code definitions for ENR entries (not consulted). Bureau of the Fiscal Service, Green Book: A Guide to Federal Government ACH Payments, chapter 1, section F, Return Reason Codes and ENR Addenda Record (https://tfx.treasury.gov/system/files/2025-03/greenbook-chapter1.pdf, public_primary for federal ENR practice, not the Nacha rulebook). CBS Bank, Quick Reference Guide: ACH Return Reason Codes and Time Frames (https://www.cbsbank.com/wp-content/uploads/2025/03/ACH-Return-Reason-Codes.pdf, secondary), section on codes used by federal government agencies returning ENR entries. BMO ACH Return Reason Codes guide, May 2025 (secondary), which lists the ENR codes with no timeframe. Group is enrollment per Orca's US ACH rail brief (docs/rails/us-ach.md). counts_toward is empty by inference: an ENR carries no dollar amount and is not a debit, and the return rates measure debit returns.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "No material rule change identified for this code.", "source_edition": "Nacha Operating Rules not consulted; the record rests on the sources listed in its basis and corroboration", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "rail_name": "US ACH", "governing_authority": "Nacha", "snapshot": "2026-09-16", "source_class": null, "effective_status": "draft", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for Automated Enrollment Entry (ENR). Its own scope line reads: ENR (automated enrollment) entries only.", "from": "applies_to" } ] }, { "uid": "us-ach:R42", "id": "R42", "rail": "us-ach", "kind": "reason-code", "name": "Routing number or check digit error", "group": "enrollment", "summary": "The routing number or its check digit inside the ENR addenda is not valid, so the agency could not record where to send the payments.", "triggers": [ "Routing number mistyped at enrollment", "Check digit missing or wrong. The Green Book shows the routing number and check digit as separate elements in the addenda", "A wire routing number or a retired routing number supplied by the customer [Inference]" ], "actions": [ "Confirm the ACH routing number for the customer's account and send a corrected ENR, or enroll another way", "Validate the routing number and check digit at capture before sending", "Tell the customer the enrollment did not take effect" ], "retry": { "allowed": false, "rule": "Do not resend unchanged. Correct the routing number and check digit, then send a new ENR, or enroll another way." }, "facts": { "return_windows": [ { "action": "return", "by": "Federal government agency", "deadline": "No return timeframe stated in the public sources consulted" } ], "wsud_required": false, "applies_to": "ENR (automated enrollment) entries only", "counts_toward": [] }, "caveat": "The routing number checked here is the one inside the addenda, where payments are to go. A bad routing number on the ENR entry itself would be rejected by the ACH Operator, for example as R28 or R13. [Inference] An ENR is a zero-dollar enrollment entry that a financial institution sends to a federal benefit agency for its customer, so the reader of this return is that institution, not a business originator. No money moved and no return rate is affected. An ENR that fails the ACH Operator's own edits is rejected with an operator code and never reaches the agency. No public source consulted gives the agency a deadline for this return. [Unverified]", "related": [ "us-ach:R28", "us-ach:R13", "us-ach:R40" ], "basis": { "sources": "Nacha Operating Rules, return reason code definitions for ENR entries (not consulted). Bureau of the Fiscal Service, Green Book: A Guide to Federal Government ACH Payments, chapter 1, section F, Return Reason Codes and ENR Addenda Record (https://tfx.treasury.gov/system/files/2025-03/greenbook-chapter1.pdf, public_primary for federal ENR practice, not the Nacha rulebook). CBS Bank, Quick Reference Guide: ACH Return Reason Codes and Time Frames (https://www.cbsbank.com/wp-content/uploads/2025/03/ACH-Return-Reason-Codes.pdf, secondary), section on codes used by federal government agencies returning ENR entries. BMO ACH Return Reason Codes guide, May 2025 (secondary), which lists the ENR codes with no timeframe. Group is enrollment per Orca's US ACH rail brief (docs/rails/us-ach.md). counts_toward is empty by inference: an ENR carries no dollar amount and is not a debit, and the return rates measure debit returns.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "No material rule change identified for this code.", "source_edition": "Nacha Operating Rules not consulted; the record rests on the sources listed in its basis and corroboration", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "rail_name": "US ACH", "governing_authority": "Nacha", "snapshot": "2026-09-16", "source_class": null, "effective_status": "draft", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for Automated Enrollment Entry (ENR). Its own scope line reads: ENR (automated enrollment) entries only.", "from": "applies_to" } ] }, { "uid": "us-ach:R43", "id": "R43", "rail": "us-ach", "kind": "reason-code", "name": "Invalid DFI account number", "group": "enrollment", "summary": "The customer's account number inside the ENR addenda is missing, longer than 17 positions, or contains invalid characters.", "triggers": [ "Account number left blank or truncated", "Account number over 17 positions, or with spaces, dashes, or other invalid characters", "A card number or member number entered instead of the deposit account number [Inference]" ], "actions": [ "Confirm the account number with the customer and your core system, then send a corrected ENR or enroll another way", "Strip formatting characters at capture", "Tell the customer the enrollment did not take effect" ], "retry": { "allowed": false, "rule": "Do not resend unchanged. Correct the account number, then send a new ENR, or enroll another way." }, "facts": { "return_windows": [ { "action": "return", "by": "Federal government agency", "deadline": "No return timeframe stated in the public sources consulted" } ], "wsud_required": false, "applies_to": "ENR (automated enrollment) entries only", "counts_toward": [] }, "caveat": "R43 is a format check. It does not confirm the account exists; a well-formed but wrong account number would surface later as a return of the benefit payment. [Inference] An ENR is a zero-dollar enrollment entry that a financial institution sends to a federal benefit agency for its customer, so the reader of this return is that institution, not a business originator. No money moved and no return rate is affected. An ENR that fails the ACH Operator's own edits is rejected with an operator code and never reaches the agency. No public source consulted gives the agency a deadline for this return. [Unverified]", "related": [ "us-ach:R04", "us-ach:R03", "us-ach:R40" ], "basis": { "sources": "Nacha Operating Rules, return reason code definitions for ENR entries (not consulted). Bureau of the Fiscal Service, Green Book: A Guide to Federal Government ACH Payments, chapter 1, section F, Return Reason Codes and ENR Addenda Record (https://tfx.treasury.gov/system/files/2025-03/greenbook-chapter1.pdf, public_primary for federal ENR practice, not the Nacha rulebook). CBS Bank, Quick Reference Guide: ACH Return Reason Codes and Time Frames (https://www.cbsbank.com/wp-content/uploads/2025/03/ACH-Return-Reason-Codes.pdf, secondary), section on codes used by federal government agencies returning ENR entries. BMO ACH Return Reason Codes guide, May 2025 (secondary), which lists the ENR codes with no timeframe. Group is enrollment per Orca's US ACH rail brief (docs/rails/us-ach.md). counts_toward is empty by inference: an ENR carries no dollar amount and is not a debit, and the return rates measure debit returns.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "No material rule change identified for this code.", "source_edition": "Nacha Operating Rules not consulted; the record rests on the sources listed in its basis and corroboration", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "rail_name": "US ACH", "governing_authority": "Nacha", "snapshot": "2026-09-16", "source_class": null, "effective_status": "draft", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for Automated Enrollment Entry (ENR). Its own scope line reads: ENR (automated enrollment) entries only.", "from": "applies_to" } ] }, { "uid": "us-ach:R44", "id": "R44", "rail": "us-ach", "kind": "reason-code", "name": "Invalid individual ID number or identification number", "group": "enrollment", "summary": "The identification number in the ENR addenda, the beneficiary's Social Security number in the Green Book example, does not match the agency's records.", "triggers": [ "Social Security number mistyped", "The representative payee's number used instead of the beneficiary's own number [Inference]", "A claim number or other identifier used where the agency expects the Social Security number [Inference]", "Lowercase letters in the record. The Green Book warns that at least one agency requires uppercase and that lowercase data can bring an R44 or R45 even when the data is correct" ], "actions": [ "Confirm the beneficiary's own identification number from their benefit documents", "Send all alphabetic data in uppercase", "Send a corrected ENR, or enroll another way, and tell the customer the enrollment did not take effect" ], "retry": { "allowed": false, "rule": "Do not resend unchanged. Correct the identification number and uppercase the record, then send a new ENR, or enroll another way." }, "facts": { "return_windows": [ { "action": "return", "by": "Federal government agency", "deadline": "No return timeframe stated in the public sources consulted" } ], "wsud_required": false, "applies_to": "ENR (automated enrollment) entries only", "counts_toward": [] }, "caveat": "An ENR is a zero-dollar enrollment entry that a financial institution sends to a federal benefit agency for its customer, so the reader of this return is that institution, not a business originator. No money moved and no return rate is affected. An ENR that fails the ACH Operator's own edits is rejected with an operator code and never reaches the agency. No public source consulted gives the agency a deadline for this return. [Unverified]", "related": [ "us-ach:R22", "us-ach:R40" ], "basis": { "sources": "Nacha Operating Rules, return reason code definitions for ENR entries (not consulted). Bureau of the Fiscal Service, Green Book: A Guide to Federal Government ACH Payments, chapter 1, section F, Return Reason Codes and ENR Addenda Record (https://tfx.treasury.gov/system/files/2025-03/greenbook-chapter1.pdf, public_primary for federal ENR practice, not the Nacha rulebook). CBS Bank, Quick Reference Guide: ACH Return Reason Codes and Time Frames (https://www.cbsbank.com/wp-content/uploads/2025/03/ACH-Return-Reason-Codes.pdf, secondary), section on codes used by federal government agencies returning ENR entries. BMO ACH Return Reason Codes guide, May 2025 (secondary), which lists the ENR codes with no timeframe. Group is enrollment per Orca's US ACH rail brief (docs/rails/us-ach.md). counts_toward is empty by inference: an ENR carries no dollar amount and is not a debit, and the return rates measure debit returns.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "No material rule change identified for this code.", "source_edition": "Nacha Operating Rules not consulted; the record rests on the sources listed in its basis and corroboration", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "rail_name": "US ACH", "governing_authority": "Nacha", "snapshot": "2026-09-16", "source_class": null, "effective_status": "draft", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for Automated Enrollment Entry (ENR). Its own scope line reads: ENR (automated enrollment) entries only.", "from": "applies_to" } ] }, { "uid": "us-ach:R45", "id": "R45", "rail": "us-ach", "kind": "reason-code", "name": "Invalid individual name or company name", "group": "enrollment", "summary": "The receiver's name in the ENR addenda does not match the agency's records, or contains no alphanumeric character.", "triggers": [ "Name entered as a nickname or in a different form than the benefit is paid under", "Surname and first name in the wrong order, or truncated differently than the agency expects. The Green Book allows 15 positions for surname and 7 for first name", "A name change the customer has not reported to the agency [Inference]", "Lowercase letters in the record, which the Green Book says can bring an R44 or R45 even when the data is correct" ], "actions": [ "Enter the name exactly as it appears on the benefit payment, in uppercase", "If the customer's name changed, have them update it with the agency first", "Send a corrected ENR, or enroll another way, and tell the customer the enrollment did not take effect" ], "retry": { "allowed": false, "rule": "Do not resend unchanged. Correct the name and uppercase the record, then send a new ENR, or enroll another way." }, "facts": { "return_windows": [ { "action": "return", "by": "Federal government agency", "deadline": "No return timeframe stated in the public sources consulted" } ], "wsud_required": false, "applies_to": "ENR (automated enrollment) entries only", "counts_toward": [] }, "caveat": "An ENR is a zero-dollar enrollment entry that a financial institution sends to a federal benefit agency for its customer, so the reader of this return is that institution, not a business originator. No money moved and no return rate is affected. An ENR that fails the ACH Operator's own edits is rejected with an operator code and never reaches the agency. No public source consulted gives the agency a deadline for this return. [Unverified]", "related": [ "us-ach:R44", "us-ach:R40" ], "basis": { "sources": "Nacha Operating Rules, return reason code definitions for ENR entries (not consulted). Bureau of the Fiscal Service, Green Book: A Guide to Federal Government ACH Payments, chapter 1, section F, Return Reason Codes and ENR Addenda Record (https://tfx.treasury.gov/system/files/2025-03/greenbook-chapter1.pdf, public_primary for federal ENR practice, not the Nacha rulebook). CBS Bank, Quick Reference Guide: ACH Return Reason Codes and Time Frames (https://www.cbsbank.com/wp-content/uploads/2025/03/ACH-Return-Reason-Codes.pdf, secondary), section on codes used by federal government agencies returning ENR entries. BMO ACH Return Reason Codes guide, May 2025 (secondary), which lists the ENR codes with no timeframe. Group is enrollment per Orca's US ACH rail brief (docs/rails/us-ach.md). counts_toward is empty by inference: an ENR carries no dollar amount and is not a debit, and the return rates measure debit returns.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "No material rule change identified for this code.", "source_edition": "Nacha Operating Rules not consulted; the record rests on the sources listed in its basis and corroboration", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "rail_name": "US ACH", "governing_authority": "Nacha", "snapshot": "2026-09-16", "source_class": null, "effective_status": "draft", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for Automated Enrollment Entry (ENR). Its own scope line reads: ENR (automated enrollment) entries only.", "from": "applies_to" } ] }, { "uid": "us-ach:R46", "id": "R46", "rail": "us-ach", "kind": "reason-code", "name": "Invalid representative payee indicator", "group": "enrollment", "summary": "The representative payee indicator in the ENR addenda is missing or does not agree with the agency's records.", "triggers": [ "Indicator left blank. The Green Book shows 0 for no representative payee and 1 for a representative payee", "Indicator set to 0 when the agency pays the benefit to a representative payee, or to 1 when it does not", "An ENR for a representative payee sent to an agency that does not take them. The Green Book says VA and OPM do not allow ENR enrollments for representative payees; which code those agencies return is [Unverified]" ], "actions": [ "Check how the benefit payment is styled. A payee styled as one person for another indicates a representative payee", "Confirm the account is titled to show the representative payee's fiduciary role before enrolling", "For VA and OPM representative payees, enroll by another method", "Send a corrected ENR, or enroll another way, and tell the customer the enrollment did not take effect" ], "retry": { "allowed": false, "rule": "Do not resend unchanged. Correct the representative payee indicator, then send a new ENR, or enroll another way." }, "facts": { "return_windows": [ { "action": "return", "by": "Federal government agency", "deadline": "No return timeframe stated in the public sources consulted" } ], "wsud_required": false, "applies_to": "ENR (automated enrollment) entries only", "counts_toward": [] }, "caveat": "An ENR is a zero-dollar enrollment entry that a financial institution sends to a federal benefit agency for its customer, so the reader of this return is that institution, not a business originator. No money moved and no return rate is affected. An ENR that fails the ACH Operator's own edits is rejected with an operator code and never reaches the agency. No public source consulted gives the agency a deadline for this return. [Unverified]", "related": [ "us-ach:R14", "us-ach:R40" ], "basis": { "sources": "Nacha Operating Rules, return reason code definitions for ENR entries (not consulted). Bureau of the Fiscal Service, Green Book: A Guide to Federal Government ACH Payments, chapter 1, section F, Return Reason Codes and ENR Addenda Record (https://tfx.treasury.gov/system/files/2025-03/greenbook-chapter1.pdf, public_primary for federal ENR practice, not the Nacha rulebook). CBS Bank, Quick Reference Guide: ACH Return Reason Codes and Time Frames (https://www.cbsbank.com/wp-content/uploads/2025/03/ACH-Return-Reason-Codes.pdf, secondary), section on codes used by federal government agencies returning ENR entries. BMO ACH Return Reason Codes guide, May 2025 (secondary), which lists the ENR codes with no timeframe. Group is enrollment per Orca's US ACH rail brief (docs/rails/us-ach.md). counts_toward is empty by inference: an ENR carries no dollar amount and is not a debit, and the return rates measure debit returns.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "No material rule change identified for this code.", "source_edition": "Nacha Operating Rules not consulted; the record rests on the sources listed in its basis and corroboration", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "rail_name": "US ACH", "governing_authority": "Nacha", "snapshot": "2026-09-16", "source_class": null, "effective_status": "draft", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for Automated Enrollment Entry (ENR). Its own scope line reads: ENR (automated enrollment) entries only.", "from": "applies_to" } ] }, { "uid": "us-ach:R47", "id": "R47", "rail": "us-ach", "kind": "reason-code", "name": "Duplicate enrollment", "group": "enrollment", "summary": "The agency received the same enrollment more than once from the same financial institution and returned the duplicate.", "triggers": [ "An ENR file or batch transmitted twice", "Staff re-keyed an enrollment that had already been sent [Inference]", "A third-party processor resubmitted after a transmission error without checking what had gone through [Inference]" ], "actions": [ "Verify with the agency that the enrollment took effect. The duplicate return does not by itself tell you whether the first ENR was accepted [Inference]", "Do not send the enrollment again until you know the status of the first one", "Add a duplicate check on ENR submissions before transmission" ], "retry": { "allowed": false, "rule": "Do not resend. Confirm with the agency whether the original enrollment was accepted." }, "facts": { "return_windows": [ { "action": "return", "by": "Federal government agency", "deadline": "No return timeframe stated in the public sources consulted" } ], "wsud_required": false, "applies_to": "ENR (automated enrollment) entries only", "counts_toward": [] }, "caveat": "An ENR is a zero-dollar enrollment entry that a financial institution sends to a federal benefit agency for its customer, so the reader of this return is that institution, not a business originator. No money moved and no return rate is affected. An ENR that fails the ACH Operator's own edits is rejected with an operator code and never reaches the agency. No public source consulted gives the agency a deadline for this return. [Unverified]", "related": [ "us-ach:R24", "us-ach:R40" ], "basis": { "sources": "Nacha Operating Rules, return reason code definitions for ENR entries (not consulted). Bureau of the Fiscal Service, Green Book: A Guide to Federal Government ACH Payments, chapter 1, section F, Return Reason Codes and ENR Addenda Record (https://tfx.treasury.gov/system/files/2025-03/greenbook-chapter1.pdf, public_primary for federal ENR practice, not the Nacha rulebook). CBS Bank, Quick Reference Guide: ACH Return Reason Codes and Time Frames (https://www.cbsbank.com/wp-content/uploads/2025/03/ACH-Return-Reason-Codes.pdf, secondary), section on codes used by federal government agencies returning ENR entries. BMO ACH Return Reason Codes guide, May 2025 (secondary), which lists the ENR codes with no timeframe. Group is enrollment per Orca's US ACH rail brief (docs/rails/us-ach.md). counts_toward is empty by inference: an ENR carries no dollar amount and is not a debit, and the return rates measure debit returns.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "No material rule change identified for this code.", "source_edition": "Nacha Operating Rules not consulted; the record rests on the sources listed in its basis and corroboration", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "rail_name": "US ACH", "governing_authority": "Nacha", "snapshot": "2026-09-16", "source_class": null, "effective_status": "draft", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for Automated Enrollment Entry (ENR). Its own scope line reads: ENR (automated enrollment) entries only.", "from": "applies_to" } ] }, { "uid": "us-ach:R50", "id": "R50", "rail": "us-ach", "kind": "reason-code", "name": "State law affecting RCK acceptance", "group": "check-conversion", "summary": "The receiving institution is in a state whose law does not support electronic re-presentment of a returned check, so it cannot accept your re-presented check entry (RCK).", "triggers": [ "An RCK entry was sent to an institution located in a state that has not adopted the revised version of UCC Article 4, or that otherwise restricts RCK [Unverified]", "The routing number on the RCK entry points to a different institution or location than the one the check was drawn on [Inference]" ], "actions": [ "Confirm the routing number on the RCK entry matches the paying institution on the original check", "If it does, stop re-presenting electronically to that institution and collect the returned check through paper or image re-presentment or another collection method", "Keep a list of institutions that have returned R50 so your RCK process skips them" ], "retry": { "allowed": false, "rule": "Do not resend the RCK entry to the same institution. The state law barrier does not change between presentments. A corrected entry to the right institution is a separate question." }, "facts": { "return_windows": [ { "action": "return", "by": "RDFI", "deadline": "2 banking days [Unverified]" } ], "wsud_required": false, "applies_to": "RCK debit", "counts_toward": [ "overall" ] }, "caveat": "R50 is rare, and public bank guides give no timeframe for it. Whether any state still lacks the law that RCK depends on is not confirmed here. [Unverified] RCK entries re-present paper checks that were returned for insufficient or uncollected funds, so the underlying debt is a check, not an ACH authorization.", "related": [], "basis": { "sources": "Drafted mostly from general knowledge. Nacha Operating Rules, RCK rules and return reason code definitions (not consulted). BMO ACH Return Reason Codes guide, May 2025 (secondary), for the state law basis. FedACH sample ACH Return Reason Report (https://www.frbservices.org/binaries/content/assets/crsocms/financial-services/ach/return-reason-report.xlsx), which lists R50 as a column. Nacha, How to calculate administrative or overall return rate levels (https://www.nacha.org/system/files/2024-01/Calculate_Admin_or_Overall_Return_Rate.pdf), for the overall rate definition.", "confidence": "low" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "No material rule change identified for this code.", "source_edition": "Nacha Operating Rules not consulted; the record rests on the sources listed in its basis and corroboration", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.cbsbank.com/wp-content/uploads/2025/03/ACH-Return-Reason-Codes.pdf", "source_class": "secondary", "source_title": "CBS Bank, Quick Reference Guide: ACH Return Reason Codes and Time Frames, March 2025", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms the 2 banking day window, that R50 applies to consumer accounts, and the state law basis tied to Revised Article 4 of the UCC." } ] }, "rail_name": "US ACH", "governing_authority": "Nacha", "snapshot": "2026-09-16", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "debit or credit", "needs": "whether the entry is a debit or a credit", "detail": "This code is recorded for debits. Its own scope line reads: RCK debit.", "from": "applies_to" }, { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for Re-presented Check Entry (RCK). Its own scope line reads: RCK debit.", "from": "applies_to" } ] }, { "uid": "us-ach:R51", "id": "R51", "rail": "us-ach", "kind": "reason-code", "name": "Item related to RCK entry is ineligible or RCK entry is improper", "group": "check-conversion", "summary": "The payer told their institution that your re-presented check entry (RCK) should never have been sent: the check was not eligible for RCK, required notice was not given, the check was forged or altered, or the entry amount does not match the check. It counts toward Nacha's 0.5 percent unauthorized entry return rate threshold.", "triggers": [ "The check did not qualify for RCK, for example because of its type, its amount, or the reason it was first returned [Unverified]", "The payer was not given the required notice that a returned check could be re-presented electronically", "The signature on the check was not genuine, or the check was altered", "The RCK amount was keyed wrong or does not match the face of the check" ], "actions": [ "Treat R51 as an unauthorized return. It feeds the 0.5 percent unauthorized entry return rate threshold, as R10 and R29 do, so track it with them", "Pull the check image and your notice record. Your defense is proof that the item was eligible, the notice was given before the check was accepted, and the amount matches", "If the check was forged or altered, stop collection from this payer and handle it as fraud", "If notice or eligibility failed, fix your RCK screening and point of acceptance signage before re-presenting any more items [Inference]" ], "retry": { "allowed": false, "rule": "Do not resend the RCK entry. An item the payer has declared ineligible or improper cannot be re-presented electronically; collect through other means if a valid debt remains." }, "facts": { "return_windows": [ { "action": "return", "by": "RDFI", "deadline": "60 calendar days" } ], "wsud_required": true, "applies_to": "RCK debit", "counts_toward": [ "unauth", "overall" ] }, "caveat": "R51 is the only check-conversion code in the unauthorized rate. Its sibling codes R52 and R53 use the same extended window but do not count toward it. Because R51 bundles several distinct failures under one code, the return itself does not tell you which one occurred.", "related": [ "us-ach:R52", "us-ach:R53", "us-ach:R50", "us-ach:R10", "us-ach:R29" ], "basis": { "sources": "Nacha, How to Calculate Unauthorized Return Rate (https://www.nacha.org/system/files/2024-01/Calculate_Unauthorized_Return_Rate.pdf), for R51 in the unauthorized code list and the 0.5% level. FedACH sample ACH Return Reason Report (https://www.frbservices.org/binaries/content/assets/crsocms/financial-services/ach/return-reason-report.xlsx), which groups R51 with the unauthorized codes. Nacha, Differentiating Unauthorized Return Reasons (https://www.nacha.org/rules/differentiating-unauthorized-return-reasons), for R51 continuing to apply to improper RCK entries after 2020. BMO ACH Return Reason Codes guide, May 2025 (secondary), for R51 as an RCK-only extended return. Window and WSUD requirement from general knowledge; Nacha Operating Rules, RCK rules and WSUD requirements (not consulted).", "confidence": "medium" }, "currency": { "effective_since": "2015-09-18", "effective_to": null, "effective_note": "Unauthorized return rate reduced to 0.5% effective 2015-09-18. Code definition is long-standing. Date R51 joined the unauthorized code list not confirmed.", "source_edition": "Nacha Operating Rules not consulted; the record rests on the sources listed in its basis and corroboration", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.cbsbank.com/wp-content/uploads/2025/03/ACH-Return-Reason-Codes.pdf", "source_class": "secondary", "source_title": "CBS Bank, Quick Reference Guide: ACH Return Reason Codes and Time Frames, March 2025", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms the 60 calendar day window, that a written statement of unauthorized debit is required, and the trigger list of missing notice, signature not genuine, item altered, and amount not accurately obtained." } ] }, "rail_name": "US ACH", "governing_authority": "Nacha", "snapshot": "2026-09-16", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "debit or credit", "needs": "whether the entry is a debit or a credit", "detail": "This code is recorded for debits. Its own scope line reads: RCK debit.", "from": "applies_to" }, { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for Re-presented Check Entry (RCK). Its own scope line reads: RCK debit.", "from": "applies_to" } ] }, { "uid": "us-ach:R52", "id": "R52", "rail": "us-ach", "kind": "reason-code", "name": "Stop payment on item related to RCK entry", "group": "check-conversion", "summary": "The payer had stopped payment on the paper check that your re-presented check entry (RCK) collects, and the receiving institution applied that stop to the RCK entry.", "triggers": [ "The payer stopped the check after it bounced, intending to pay another way or not at all", "The payer disputes the purchase the check paid for", "A stop placed before the first presentment was still in force when the RCK entry arrived [Inference]" ], "actions": [ "Stop electronic re-presentment of this check. The stop order blocks it", "Contact the payer. The check was already returned once for funds, so you now have a bounced check with a stop on it: a collections matter", "Review your RCK eligibility screening. Items with a stop payment on file should not be sent as RCK [Inference]" ], "retry": { "allowed": false, "rule": "Do not resend the RCK entry. Collect through other means, subject to the stop order and any dispute." }, "facts": { "return_windows": [ { "action": "return", "by": "RDFI", "deadline": "60 calendar days" } ], "wsud_required": false, "applies_to": "RCK debit", "counts_toward": [ "overall" ] }, "caveat": "Public guides describe R52 as an extended return, and at least one gives the window as 60 banking days rather than calendar days. Whether a receiver statement is required for the extended window is not confirmed here. R52 is not among the codes Nacha lists for the unauthorized return rate. [Unverified]", "related": [ "us-ach:R08", "us-ach:R38", "us-ach:R50" ], "basis": { "sources": "Drafted mostly from general knowledge. Nacha Operating Rules, RCK rules and return reason code definitions (not consulted). BMO ACH Return Reason Codes guide, May 2025 (secondary), for R52 as an RCK-only extended return. Modern Treasury return code reference (secondary), which gives a 60 banking day window. Nacha, How to Calculate Unauthorized Return Rate (https://www.nacha.org/system/files/2024-01/Calculate_Unauthorized_Return_Rate.pdf), for R52 falling outside the unauthorized code list.", "confidence": "low" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "No material rule change identified for this code.", "source_edition": "Nacha Operating Rules not consulted; the record rests on the sources listed in its basis and corroboration", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.cbsbank.com/wp-content/uploads/2025/03/ACH-Return-Reason-Codes.pdf", "source_class": "secondary", "source_title": "CBS Bank, Quick Reference Guide: ACH Return Reason Codes and Time Frames, March 2025", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms the 60 calendar day window and that no written statement is required. A separate secondary source, Modern Treasury, gives 60 banking days instead of 60 calendar days for this code; this source's calendar day figure is consistent with the record." } ] }, "rail_name": "US ACH", "governing_authority": "Nacha", "snapshot": "2026-09-16", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "debit or credit", "needs": "whether the entry is a debit or a credit", "detail": "This code is recorded for debits. Its own scope line reads: RCK debit.", "from": "applies_to" }, { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for Re-presented Check Entry (RCK). Its own scope line reads: RCK debit.", "from": "applies_to" } ] }, { "uid": "us-ach:R53", "id": "R53", "rail": "us-ach", "kind": "reason-code", "name": "Item and RCK entry presented for payment", "group": "check-conversion", "summary": "The paper check behind your re-presented check entry (RCK) was also presented again, as paper or image, so the payer was charged for the same check twice.", "triggers": [ "The returned check was re-deposited through check channels and also sent as RCK", "A collection agency or service provider re-presented the check while you, or another provider, sent the RCK entry", "The returned item was not retained or marked after the RCK entry was created [Inference]" ], "actions": [ "Confirm whether the check itself was paid on the second presentment. If so, the RCK debit was a duplicate and the debt is settled", "Do not collect again, and reconcile which presentment actually paid", "Put one owner on each returned check. Re-presentment by paper and by RCK must be mutually exclusive" ], "retry": { "allowed": false, "rule": "Do not resend the RCK entry. The check has been presented through another channel." }, "facts": { "return_windows": [ { "action": "return", "by": "RDFI", "deadline": "60 calendar days" } ], "wsud_required": true, "applies_to": "RCK debit", "counts_toward": [ "overall" ] }, "caveat": "R53 is to RCK what R37 is to ARC, BOC, and POP: a double presentment claimed on the extended window. Whether a written statement is required for R53 is not confirmed here. R53 is not among the codes Nacha lists for the unauthorized return rate. [Unverified]", "related": [ "us-ach:R37", "us-ach:R52", "us-ach:R50" ], "basis": { "sources": "Drafted mostly from general knowledge. Nacha Operating Rules, RCK rules, return reason code definitions, and WSUD requirements (not consulted). BMO ACH Return Reason Codes guide, May 2025 (secondary), for R53 as an RCK-only extended return. Modern Treasury return code reference (secondary) for the 60 calendar day window. Nacha, How to Calculate Unauthorized Return Rate (https://www.nacha.org/system/files/2024-01/Calculate_Unauthorized_Return_Rate.pdf), for R53 falling outside the unauthorized code list.", "confidence": "low" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "No material rule change identified for this code.", "source_edition": "Nacha Operating Rules not consulted; the record rests on the sources listed in its basis and corroboration", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.cbsbank.com/wp-content/uploads/2025/03/ACH-Return-Reason-Codes.pdf", "source_class": "secondary", "source_title": "CBS Bank, Quick Reference Guide: ACH Return Reason Codes and Time Frames, March 2025", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms the 60 calendar day window and that a written statement of unauthorized debit is required for a check presented for payment alongside the RCK entry." } ] }, "rail_name": "US ACH", "governing_authority": "Nacha", "snapshot": "2026-09-16", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "debit or credit", "needs": "whether the entry is a debit or a credit", "detail": "This code is recorded for debits. Its own scope line reads: RCK debit.", "from": "applies_to" }, { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for Re-presented Check Entry (RCK). Its own scope line reads: RCK debit.", "from": "applies_to" } ] }, { "uid": "us-ach:R61", "id": "R61", "rail": "us-ach", "kind": "reason-code", "name": "Misrouted return", "group": "administrative", "summary": "The ODFI sends a return back because the RDFI addressed it to the wrong routing number: the receiving institution field on the return does not name the bank that sent the original entry.", "triggers": [ "The RDFI or its processor keyed the wrong routing number into the return", "A return reached an institution that did not originate the entry" ], "actions": [ "As the RDFI, check the routing number of the original entry and the return you built from it", "Contest with R71 only if it was the dishonor that went to the wrong place; otherwise the original return has to reach the right ODFI [Inference]" ], "retry": { "allowed": false, "rule": "A dishonor is the ODFI's answer to a return, not a failed payment to resend. The RDFI's next step, if it disagrees or can fix the return, is a contested dishonored return within 2 banking days." }, "facts": { "return_windows": [ { "action": "dishonored return", "by": "ODFI", "deadline": "5 banking days after the settlement date of the return entry" } ], "wsud_required": false, "applies_to": "every SEC code except IAT", "counts_toward": [] }, "caveat": "The public guides read describe the code but not how the misrouted return is then re-sent; that step is [Unverified].", "related": [ "us-ach:R71" ], "basis": { "sources": "CBS Bank quick reference (March 2025), Commerce Bank code table (2022), Jefferson Bank Obligations of Originators (March 2022) and Bank of North Dakota ACH overview (2024), read 2026-09-19. Nacha Operating Rules, dishonored return provisions (not consulted).", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "No rule change identified in the sources read.", "source_edition": "Nacha Operating Rules not consulted; the record rests on the public sources named in its relations and basis", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.cbsbank.com/wp-content/uploads/2025/03/ACH-Return-Reason-Codes.pdf", "source_class": "secondary", "source_title": "CBS Bank, Quick Reference Guide: ACH Return Reason Codes and Time Frames, March 2025", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms the misrouted return definition, the five banking day dishonor transmission window measured from the settlement date of the returned entry, and that the code excludes IAT entries." }, { "source_url": "https://www.commercebank.com/-/media/cb/pdf/business/commerce-connections/noccodes.pdf", "source_class": "secondary", "source_title": "Commerce Bank, ACH Return, NOC, and Tran Codes, November 2022", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms the misrouted return definition, naming the incorrect routing number placed in the receiving DFI identification field, and the five banking day window measured from the settlement date of the return entry." }, { "source_url": "https://www.jefferson-bank.com/uploadedfiles/includedcontent/business/obligations-of-originators.pdf?v=1D50A930C4ADA00", "source_class": "secondary", "source_title": "Jefferson Bank, Obligations of Originators, revised March 2022", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms the misrouted return definition and that a dishonored return must be transmitted by the ODFI within five banking days of the settlement date of the return entry." }, { "source_url": "https://bnd.nd.gov/pdf/cashplus_ach_overview.pdf", "source_class": "secondary", "source_title": "Bank of North Dakota, Automated Clearing House Overview, 2024", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms the misrouted return definition and states that ACH return transactions may be dishonored within five banking days if the return was inaccurate." } ] }, "rail_name": "US ACH", "governing_authority": "Nacha", "snapshot": "2026-09-16", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is not for International ACH Transaction (IAT). Its own scope line reads: every SEC code except IAT.", "from": "applies_to" }, { "kind": "eligibility", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "The rule this rests on, Dishonor and contest codes are not for IAT entries, applies to every SEC code except IAT.", "from": "us-ach:rule.dishonor-codes-exclude-iat" } ] }, { "uid": "us-ach:R62", "id": "R62", "rail": "us-ach", "kind": "reason-code", "name": "Return of erroneous or reversing debit", "group": "administrative", "summary": "The ODFI dishonors a return because a reversal went wrong and left the Receiver with money it should not have: the RDFI returned one half of an erroneous entry and reversal pair and posted the other.", "triggers": [ "An erroneous debit and the credit reversing it both reached the Receiver's account; the RDFI returned the debit and posted the credit, so the Receiver kept the credit", "An erroneous credit and the debit reversing it both reached the account; the RDFI posted the credit and returned the debit, so the Receiver kept the credit" ], "actions": [ "As the ODFI, use R62 only in those two reversal patterns; it is not a general way to recover a mistaken credit", "As the RDFI, contest with R77 if you returned both entries of the pair or cannot recover the funds from the Receiver" ], "retry": { "allowed": false, "rule": "A dishonor is the ODFI's answer to a return, not a failed payment to resend. The RDFI's next step, if it disagrees or can fix the return, is a contested dishonored return within 2 banking days." }, "facts": { "return_windows": [ { "action": "dishonored return", "by": "ODFI", "deadline": "5 banking days after the settlement date of the return entry" } ], "wsud_required": false, "applies_to": "every SEC code except IAT", "counts_toward": [] }, "caveat": "R62 is the one dishonor code that exists to fix a reversal outcome rather than a defect in the return itself. Its time frame is the general 5 banking day dishonor window in the bank guides read. [Inference]", "related": [ "us-ach:R77" ], "basis": { "sources": "CBS Bank quick reference (March 2025), Commerce Bank code table (2022), Jefferson Bank Obligations of Originators (March 2022) and Bank of North Dakota ACH overview (2024), read 2026-09-19. Nacha Operating Rules, dishonored return provisions (not consulted).", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "No rule change identified in the sources read.", "source_edition": "Nacha Operating Rules not consulted; the record rests on the public sources named in its relations and basis", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.cbsbank.com/wp-content/uploads/2025/03/ACH-Return-Reason-Codes.pdf", "source_class": "secondary", "source_title": "CBS Bank, Quick Reference Guide: ACH Return Reason Codes and Time Frames, March 2025", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms the erroneous or reversing debit dishonor definition, including the two reversal scenarios described, the five banking day dishonor transmission window, and that the code excludes IAT entries." }, { "source_url": "https://www.commercebank.com/-/media/cb/pdf/business/commerce-connections/noccodes.pdf", "source_class": "secondary", "source_title": "Commerce Bank, ACH Return, NOC, and Tran Codes, November 2022", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms the erroneous or reversing debit dishonor definition and the five banking day window measured from the settlement date of the return entry." }, { "source_url": "https://www.jefferson-bank.com/uploadedfiles/includedcontent/business/obligations-of-originators.pdf?v=1D50A930C4ADA00", "source_class": "secondary", "source_title": "Jefferson Bank, Obligations of Originators, revised March 2022", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms the erroneous or reversing debit dishonor definition, describing it as limited to reversal scenarios where the receiver is unintentionally credited, and the five banking day dishonor window." }, { "source_url": "https://bnd.nd.gov/pdf/cashplus_ach_overview.pdf", "source_class": "secondary", "source_title": "Bank of North Dakota, Automated Clearing House Overview, 2024", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms the erroneous or reversing debit dishonor definition and states that dishonored returns may be sent within five banking days." } ] }, "rail_name": "US ACH", "governing_authority": "Nacha", "snapshot": "2026-09-16", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is not for International ACH Transaction (IAT). Its own scope line reads: every SEC code except IAT.", "from": "applies_to" }, { "kind": "eligibility", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "The rule this rests on, Dishonor and contest codes are not for IAT entries, applies to every SEC code except IAT.", "from": "us-ach:rule.dishonor-codes-exclude-iat" } ] }, { "uid": "us-ach:R67", "id": "R67", "rail": "us-ach", "kind": "reason-code", "name": "Duplicate return", "group": "administrative", "summary": "The ODFI received more than one return for the same entry and dishonors the extra one.", "triggers": [ "The RDFI sent the same return twice, for example after a file was resent", "Two returns with different codes arrived for one original entry" ], "actions": [ "As the RDFI, compare the dishonored return against the returns you sent for that trace number", "Contest with R75 if the return was not in fact a duplicate" ], "retry": { "allowed": false, "rule": "A dishonor is the ODFI's answer to a return, not a failed payment to resend. The RDFI's next step, if it disagrees or can fix the return, is a contested dishonored return within 2 banking days." }, "facts": { "return_windows": [ { "action": "dishonored return", "by": "ODFI", "deadline": "5 banking days after the settlement date of the return entry" } ], "wsud_required": false, "applies_to": "every SEC code except IAT", "counts_toward": [] }, "caveat": null, "related": [ "us-ach:R75" ], "basis": { "sources": "CBS Bank quick reference (March 2025), Commerce Bank code table (2022), Jefferson Bank Obligations of Originators (March 2022) and Bank of North Dakota ACH overview (2024), read 2026-09-19. Nacha Operating Rules, dishonored return provisions (not consulted).", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "No rule change identified in the sources read.", "source_edition": "Nacha Operating Rules not consulted; the record rests on the public sources named in its relations and basis", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.cbsbank.com/wp-content/uploads/2025/03/ACH-Return-Reason-Codes.pdf", "source_class": "secondary", "source_title": "CBS Bank, Quick Reference Guide: ACH Return Reason Codes and Time Frames, March 2025", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms the duplicate return dishonor definition, the five banking day dishonor transmission window, and that the code excludes IAT entries." }, { "source_url": "https://www.commercebank.com/-/media/cb/pdf/business/commerce-connections/noccodes.pdf", "source_class": "secondary", "source_title": "Commerce Bank, ACH Return, NOC, and Tran Codes, November 2022", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms the duplicate return dishonor definition and the five banking day dishonor window measured from the settlement date of the return entry." }, { "source_url": "https://www.jefferson-bank.com/uploadedfiles/includedcontent/business/obligations-of-originators.pdf?v=1D50A930C4ADA00", "source_class": "secondary", "source_title": "Jefferson Bank, Obligations of Originators, revised March 2022", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms the duplicate return dishonor definition and the five banking day window for an ODFI to transmit a dishonored return." }, { "source_url": "https://bnd.nd.gov/pdf/cashplus_ach_overview.pdf", "source_class": "secondary", "source_title": "Bank of North Dakota, Automated Clearing House Overview, 2024", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms the duplicate return dishonor definition and the five banking day dishonor window." } ] }, "rail_name": "US ACH", "governing_authority": "Nacha", "snapshot": "2026-09-16", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is not for International ACH Transaction (IAT). Its own scope line reads: every SEC code except IAT.", "from": "applies_to" }, { "kind": "eligibility", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "The rule this rests on, Dishonor and contest codes are not for IAT entries, applies to every SEC code except IAT.", "from": "us-ach:rule.dishonor-codes-exclude-iat" } ] }, { "uid": "us-ach:R68", "id": "R68", "rail": "us-ach", "kind": "reason-code", "name": "Untimely return", "group": "administrative", "summary": "The ODFI dishonors a return that arrived after the window the rules give for its return reason.", "triggers": [ "A return for a 2 banking day reason arrived after that window", "A late corporate return was sent as if it were timely, without the ODFI's agreement that R31 needs" ], "actions": [ "As the RDFI, check the settlement date of the original entry against the window of the code you used", "Contest with R73 if the original return was in fact on time" ], "retry": { "allowed": false, "rule": "A dishonor is the ODFI's answer to a return, not a failed payment to resend. The RDFI's next step, if it disagrees or can fix the return, is a contested dishonored return within 2 banking days." }, "facts": { "return_windows": [ { "action": "dishonored return", "by": "ODFI", "deadline": "5 banking days after the settlement date of the return entry" } ], "wsud_required": false, "applies_to": "every SEC code except IAT", "counts_toward": [] }, "caveat": "Bank of North Dakota's overview says a return may be dishonored for lateness where the lateness caused the ODFI or Originator a loss; the other guides read do not mention that condition. [Unverified]", "related": [ "us-ach:R73", "us-ach:R31" ], "basis": { "sources": "CBS Bank quick reference (March 2025), Commerce Bank code table (2022), Jefferson Bank Obligations of Originators (March 2022) and Bank of North Dakota ACH overview (2024), read 2026-09-19. Nacha Operating Rules, dishonored return provisions (not consulted).", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "No rule change identified in the sources read.", "source_edition": "Nacha Operating Rules not consulted; the record rests on the public sources named in its relations and basis", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.cbsbank.com/wp-content/uploads/2025/03/ACH-Return-Reason-Codes.pdf", "source_class": "secondary", "source_title": "CBS Bank, Quick Reference Guide: ACH Return Reason Codes and Time Frames, March 2025", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms the untimely return dishonor definition, the five banking day dishonor transmission window, and that the code excludes IAT entries." }, { "source_url": "https://www.commercebank.com/-/media/cb/pdf/business/commerce-connections/noccodes.pdf", "source_class": "secondary", "source_title": "Commerce Bank, ACH Return, NOC, and Tran Codes, November 2022", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms the untimely return dishonor definition and the five banking day dishonor window." }, { "source_url": "https://www.jefferson-bank.com/uploadedfiles/includedcontent/business/obligations-of-originators.pdf?v=1D50A930C4ADA00", "source_class": "secondary", "source_title": "Jefferson Bank, Obligations of Originators, revised March 2022", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms the untimely return dishonor definition, tying it to a return not sent within the timeframe the rules establish, and the five banking day dishonor window." }, { "source_url": "https://bnd.nd.gov/pdf/cashplus_ach_overview.pdf", "source_class": "secondary", "source_title": "Bank of North Dakota, Automated Clearing House Overview, 2024", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms the untimely return dishonor definition and the five banking day dishonor window." } ] }, "rail_name": "US ACH", "governing_authority": "Nacha", "snapshot": "2026-09-16", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is not for International ACH Transaction (IAT). Its own scope line reads: every SEC code except IAT.", "from": "applies_to" }, { "kind": "eligibility", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "The rule this rests on, Dishonor and contest codes are not for IAT entries, applies to every SEC code except IAT.", "from": "us-ach:rule.dishonor-codes-exclude-iat" } ] }, { "uid": "us-ach:R69", "id": "R69", "rail": "us-ach", "kind": "reason-code", "name": "Field error(s)", "group": "administrative", "summary": "The ODFI dishonors a return whose identifying data does not match the original entry, and names the wrong fields in the dishonor's addenda.", "triggers": [ "The return carried a wrong account number, original trace number, amount, individual identification number, transaction code, company identification or effective entry date", "A processor reformatted the original data before the return was built", "A federal agency found one of the four fields it compares (trace number, effective entry date, amount, individual identification number) different from its payment" ], "actions": [ "Read the addenda: the ODFI lists each wrong field as a two digit code from 01 to 07, separated by asterisks. 01 account number, 02 original trace number, 03 amount, 04 individual identification number, 05 transaction code, 06 company identification, 07 effective entry date", "As the RDFI, contest with R74 carrying the corrected fields taken from the original entry, or with R76 if the return had none of the errors claimed" ], "retry": { "allowed": false, "rule": "A dishonor is the ODFI's answer to a return, not a failed payment to resend. The RDFI's next step, if it disagrees or can fix the return, is a contested dishonored return within 2 banking days." }, "facts": { "return_windows": [ { "action": "dishonored return", "by": "ODFI", "deadline": "5 banking days after the settlement date of the return entry" } ], "wsud_required": false, "applies_to": "every SEC code except IAT", "counts_toward": [] }, "caveat": "The Treasury Green Book places the field error codes in positions 59 to 79 of the dishonored return's addenda information and warns that federal payments are dishonored for any mismatch in its four fields. The full addenda layout is in the paid rulebook and was not read.", "related": [ "us-ach:R74", "us-ach:R76" ], "basis": { "sources": "CBS Bank quick reference (March 2025), Commerce Bank code table (2022), Jefferson Bank Obligations of Originators (March 2022) and Bank of North Dakota ACH overview (2024), read 2026-09-19. Nacha Operating Rules, dishonored return provisions (not consulted). Treasury Green Book (2025-03), Returns chapter section D.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "No rule change identified in the sources read.", "source_edition": "Nacha Operating Rules not consulted; the record rests on the public sources named in its relations and basis", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.cbsbank.com/wp-content/uploads/2025/03/ACH-Return-Reason-Codes.pdf", "source_class": "secondary", "source_title": "CBS Bank, Quick Reference Guide: ACH Return Reason Codes and Time Frames, March 2025", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms the field errors dishonor definition and its seven listed field codes, the five banking day dishonor transmission window, and that the code excludes IAT entries." }, { "source_url": "https://www.commercebank.com/-/media/cb/pdf/business/commerce-connections/noccodes.pdf", "source_class": "secondary", "source_title": "Commerce Bank, ACH Return, NOC, and Tran Codes, November 2022", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms the field errors dishonor definition and its seven listed field codes, matching account number, trace number, dollar amount, individual identification number, transaction code, company identification number and effective entry date, and the five banking day dishonor window." }, { "source_url": "https://www.jefferson-bank.com/uploadedfiles/includedcontent/business/obligations-of-originators.pdf?v=1D50A930C4ADA00", "source_class": "secondary", "source_title": "Jefferson Bank, Obligations of Originators, revised March 2022", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms the field errors dishonor definition, listing the same seven addenda field codes, and the five banking day dishonor window." }, { "source_url": "https://bnd.nd.gov/pdf/cashplus_ach_overview.pdf", "source_class": "secondary", "source_title": "Bank of North Dakota, Automated Clearing House Overview, 2024", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms the field errors dishonor definition and the five banking day dishonor window." } ] }, "rail_name": "US ACH", "governing_authority": "Nacha", "snapshot": "2026-09-16", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is not for International ACH Transaction (IAT). Its own scope line reads: every SEC code except IAT.", "from": "applies_to" }, { "kind": "eligibility", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "The rule this rests on, Dishonor and contest codes are not for IAT entries, applies to every SEC code except IAT.", "from": "us-ach:rule.dishonor-codes-exclude-iat" } ] }, { "uid": "us-ach:R70", "id": "R70", "rail": "us-ach", "kind": "reason-code", "name": "Permissible return entry not accepted or return not requested by ODFI", "group": "administrative", "summary": "The ODFI dishonors a return that says it was sent with the ODFI's agreement (R31) or at its request (R06) when the ODFI gave no such agreement or made no such request.", "triggers": [ "An RDFI returned a late corporate entry with R31 without first getting the ODFI's agreement", "An RDFI returned an entry with R06 that the ODFI had not asked to have returned" ], "actions": [ "As the ODFI, use R70 only against returns bearing R06 or R31", "As the RDFI, get the ODFI's agreement or request in writing before using R06 or R31 [Inference]" ], "retry": { "allowed": false, "rule": "A dishonor is the ODFI's answer to a return, not a failed payment to resend. The RDFI's next step, if it disagrees or can fix the return, is a contested dishonored return within 2 banking days." }, "facts": { "return_windows": [ { "action": "dishonored return", "by": "ODFI", "deadline": "5 banking days after the settlement date of the return entry" } ], "wsud_required": false, "applies_to": "every SEC code except IAT", "counts_toward": [] }, "caveat": "The guides read list no contest code that answers R70 directly. [Inference]", "related": [ "us-ach:R06", "us-ach:R31" ], "basis": { "sources": "CBS Bank quick reference (March 2025), Commerce Bank code table (2022), Jefferson Bank Obligations of Originators (March 2022) and Bank of North Dakota ACH overview (2024), read 2026-09-19. Nacha Operating Rules, dishonored return provisions (not consulted).", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "No rule change identified in the sources read.", "source_edition": "Nacha Operating Rules not consulted; the record rests on the public sources named in its relations and basis", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.cbsbank.com/wp-content/uploads/2025/03/ACH-Return-Reason-Codes.pdf", "source_class": "secondary", "source_title": "CBS Bank, Quick Reference Guide: ACH Return Reason Codes and Time Frames, March 2025", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms the definition limiting this dishonor to return reason codes R06 and R31, the five banking day dishonor transmission window, and that the code excludes IAT entries." }, { "source_url": "https://www.commercebank.com/-/media/cb/pdf/business/commerce-connections/noccodes.pdf", "source_class": "secondary", "source_title": "Commerce Bank, ACH Return, NOC, and Tran Codes, November 2022", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms the definition limiting this dishonor to returns identified as sent with the permission of, or at the request of, the ODFI under codes R06 and R31, and the five banking day dishonor window." }, { "source_url": "https://www.jefferson-bank.com/uploadedfiles/includedcontent/business/obligations-of-originators.pdf?v=1D50A930C4ADA00", "source_class": "secondary", "source_title": "Jefferson Bank, Obligations of Originators, revised March 2022", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms the definition limiting this dishonor to return reason codes R31 and R06, and the five banking day dishonor window." }, { "source_url": "https://bnd.nd.gov/pdf/cashplus_ach_overview.pdf", "source_class": "secondary", "source_title": "Bank of North Dakota, Automated Clearing House Overview, 2024", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms the permissible return entry not accepted dishonor definition and the five banking day dishonor window." } ] }, "rail_name": "US ACH", "governing_authority": "Nacha", "snapshot": "2026-09-16", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is not for International ACH Transaction (IAT). Its own scope line reads: every SEC code except IAT.", "from": "applies_to" }, { "kind": "eligibility", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "The rule this rests on, Dishonor and contest codes are not for IAT entries, applies to every SEC code except IAT.", "from": "us-ach:rule.dishonor-codes-exclude-iat" } ] }, { "uid": "us-ach:R71", "id": "R71", "rail": "us-ach", "kind": "reason-code", "name": "Misrouted dishonored return", "group": "administrative", "summary": "The RDFI contests a dishonored return that the ODFI addressed to the wrong routing number.", "triggers": [ "The ODFI placed an incorrect routing number in the receiving institution field of its dishonored return" ], "actions": [ "As the ODFI receiving R71, check the routing number you used on the dishonor" ], "retry": { "allowed": false, "rule": "A contest is the last step on the network. If the ODFI still disagrees after a proper contest, the banks resolve it outside the ACH Network; there is nothing further to send." }, "facts": { "return_windows": [ { "action": "contested dishonored return", "by": "RDFI", "deadline": "2 banking days after the settlement date of the dishonored return" } ], "wsud_required": false, "applies_to": "every SEC code except IAT", "counts_toward": [] }, "caveat": null, "related": [ "us-ach:R61" ], "basis": { "sources": "CBS Bank quick reference (March 2025), Jefferson Bank Obligations of Originators (March 2022) and Bank of North Dakota ACH overview (2024), read 2026-09-19. Nacha Operating Rules, contested dishonored return provisions (not consulted).", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "No rule change identified in the sources read.", "source_edition": "Nacha Operating Rules not consulted; the record rests on the public sources named in its relations and basis", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.cbsbank.com/wp-content/uploads/2025/03/ACH-Return-Reason-Codes.pdf", "source_class": "secondary", "source_title": "CBS Bank, Quick Reference Guide: ACH Return Reason Codes and Time Frames, March 2025", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms the misrouted dishonored return contest definition, the two banking day contest transmission window measured from the settlement date of the dishonored return, and that the code excludes IAT entries." }, { "source_url": "https://www.jefferson-bank.com/uploadedfiles/includedcontent/business/obligations-of-originators.pdf?v=1D50A930C4ADA00", "source_class": "secondary", "source_title": "Jefferson Bank, Obligations of Originators, revised March 2022", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms the misrouted dishonored return contest definition, naming the incorrect routing number placed in the RDFI identification field, and the two banking day contest window from the settlement date of the dishonored return." }, { "source_url": "https://bnd.nd.gov/pdf/cashplus_ach_overview.pdf", "source_class": "secondary", "source_title": "Bank of North Dakota, Automated Clearing House Overview, 2024", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms the misrouted dishonored return contest definition and states that a contested dishonored return may be transmitted within two banking days of the settlement date of the dishonored return." } ] }, "rail_name": "US ACH", "governing_authority": "Nacha", "snapshot": "2026-09-16", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is not for International ACH Transaction (IAT). Its own scope line reads: every SEC code except IAT.", "from": "applies_to" }, { "kind": "eligibility", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "The rule this rests on, Dishonor and contest codes are not for IAT entries, applies to every SEC code except IAT.", "from": "us-ach:rule.dishonor-codes-exclude-iat" } ] }, { "uid": "us-ach:R72", "id": "R72", "rail": "us-ach", "kind": "reason-code", "name": "Untimely dishonored return", "group": "administrative", "summary": "The RDFI contests a dishonored return that the ODFI sent after its 5 banking day window.", "triggers": [ "The dishonor arrived more than 5 banking days after the settlement date of the return it answers" ], "actions": [ "As the ODFI receiving R72, check the settlement date of the return against the date you sent the dishonor" ], "retry": { "allowed": false, "rule": "A contest is the last step on the network. If the ODFI still disagrees after a proper contest, the banks resolve it outside the ACH Network; there is nothing further to send." }, "facts": { "return_windows": [ { "action": "contested dishonored return", "by": "RDFI", "deadline": "2 banking days after the settlement date of the dishonored return" } ], "wsud_required": false, "applies_to": "every SEC code except IAT", "counts_toward": [] }, "caveat": null, "related": [], "basis": { "sources": "CBS Bank quick reference (March 2025), Jefferson Bank Obligations of Originators (March 2022) and Bank of North Dakota ACH overview (2024), read 2026-09-19. Nacha Operating Rules, contested dishonored return provisions (not consulted).", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "No rule change identified in the sources read.", "source_edition": "Nacha Operating Rules not consulted; the record rests on the public sources named in its relations and basis", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.cbsbank.com/wp-content/uploads/2025/03/ACH-Return-Reason-Codes.pdf", "source_class": "secondary", "source_title": "CBS Bank, Quick Reference Guide: ACH Return Reason Codes and Time Frames, March 2025", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms the untimely dishonored return contest definition, the two banking day contest transmission window, and that the code excludes IAT entries." }, { "source_url": "https://www.jefferson-bank.com/uploadedfiles/includedcontent/business/obligations-of-originators.pdf?v=1D50A930C4ADA00", "source_class": "secondary", "source_title": "Jefferson Bank, Obligations of Originators, revised March 2022", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms the untimely dishonored return contest definition, tying it to a dishonored return not sent within five banking days of the settlement date of the return entry, and the two banking day contest window." }, { "source_url": "https://bnd.nd.gov/pdf/cashplus_ach_overview.pdf", "source_class": "secondary", "source_title": "Bank of North Dakota, Automated Clearing House Overview, 2024", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms the untimely dishonored return contest definition and the two banking day contest window." } ] }, "rail_name": "US ACH", "governing_authority": "Nacha", "snapshot": "2026-09-16", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is not for International ACH Transaction (IAT). Its own scope line reads: every SEC code except IAT.", "from": "applies_to" }, { "kind": "eligibility", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "The rule this rests on, Dishonor and contest codes are not for IAT entries, applies to every SEC code except IAT.", "from": "us-ach:rule.dishonor-codes-exclude-iat" } ] }, { "uid": "us-ach:R73", "id": "R73", "rail": "us-ach", "kind": "reason-code", "name": "Timely original return", "group": "administrative", "summary": "The RDFI answers an R68 dishonor by certifying that its original return was sent inside the window the rules allow.", "triggers": [ "The ODFI dishonored a return as untimely (R68), and the RDFI's records show it was on time" ], "actions": [ "As the RDFI, keep evidence of the date the original return was sent and of the window its code allows", "As the ODFI receiving R73, accept it and take any remaining dispute outside the network" ], "retry": { "allowed": false, "rule": "A contest is the last step on the network. If the ODFI still disagrees after a proper contest, the banks resolve it outside the ACH Network; there is nothing further to send." }, "facts": { "return_windows": [ { "action": "contested dishonored return", "by": "RDFI", "deadline": "2 banking days after the settlement date of the dishonored return" } ], "wsud_required": false, "applies_to": "every SEC code except IAT", "counts_toward": [] }, "caveat": null, "related": [ "us-ach:R68" ], "basis": { "sources": "CBS Bank quick reference (March 2025), Jefferson Bank Obligations of Originators (March 2022) and Bank of North Dakota ACH overview (2024), read 2026-09-19. Nacha Operating Rules, contested dishonored return provisions (not consulted).", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "No rule change identified in the sources read.", "source_edition": "Nacha Operating Rules not consulted; the record rests on the public sources named in its relations and basis", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.cbsbank.com/wp-content/uploads/2025/03/ACH-Return-Reason-Codes.pdf", "source_class": "secondary", "source_title": "CBS Bank, Quick Reference Guide: ACH Return Reason Codes and Time Frames, March 2025", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms the timely original return contest definition, the two banking day contest transmission window, and that the code excludes IAT entries." }, { "source_url": "https://www.jefferson-bank.com/uploadedfiles/includedcontent/business/obligations-of-originators.pdf?v=1D50A930C4ADA00", "source_class": "secondary", "source_title": "Jefferson Bank, Obligations of Originators, revised March 2022", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms the timely original return contest definition, describing it as the RDFI certifying the original return was sent within the rules timeframe, and the two banking day contest window." }, { "source_url": "https://bnd.nd.gov/pdf/cashplus_ach_overview.pdf", "source_class": "secondary", "source_title": "Bank of North Dakota, Automated Clearing House Overview, 2024", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms the timely original return contest definition and the two banking day contest window." } ] }, "rail_name": "US ACH", "governing_authority": "Nacha", "snapshot": "2026-09-16", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is not for International ACH Transaction (IAT). Its own scope line reads: every SEC code except IAT.", "from": "applies_to" }, { "kind": "eligibility", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "The rule this rests on, Dishonor and contest codes are not for IAT entries, applies to every SEC code except IAT.", "from": "us-ach:rule.dishonor-codes-exclude-iat" } ] }, { "uid": "us-ach:R74", "id": "R74", "rail": "us-ach", "kind": "reason-code", "name": "Corrected return", "group": "administrative", "summary": "The RDFI answers an R69 dishonor by correcting the return, carrying the right values for the fields the ODFI flagged, taken from the original entry.", "triggers": [ "The ODFI dishonored a return for field errors (R69), and the RDFI agrees the return data was wrong or incomplete" ], "actions": [ "Rebuild the flagged fields from the original batch header, entry detail and addenda records: whichever of the amount, the effective entry date, the company identification, the account number, the trace number, the transaction code or the identification number the ODFI flagged", "Send the correction within 2 banking days of the dishonor's settlement date" ], "retry": { "allowed": false, "rule": "A contest is the last step on the network. If the ODFI still disagrees after a proper contest, the banks resolve it outside the ACH Network; there is nothing further to send." }, "facts": { "return_windows": [ { "action": "contested dishonored return", "by": "RDFI", "deadline": "2 banking days after the settlement date of the dishonored return" } ], "wsud_required": false, "applies_to": "every SEC code except IAT", "counts_toward": [] }, "caveat": "R74 is how a return with bad data is repaired, rather than sending a new return. [Inference]", "related": [ "us-ach:R69", "us-ach:R76" ], "basis": { "sources": "CBS Bank quick reference (March 2025), Jefferson Bank Obligations of Originators (March 2022) and Bank of North Dakota ACH overview (2024), read 2026-09-19. Nacha Operating Rules, contested dishonored return provisions (not consulted).", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "No rule change identified in the sources read.", "source_edition": "Nacha Operating Rules not consulted; the record rests on the public sources named in its relations and basis", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.cbsbank.com/wp-content/uploads/2025/03/ACH-Return-Reason-Codes.pdf", "source_class": "secondary", "source_title": "CBS Bank, Quick Reference Guide: ACH Return Reason Codes and Time Frames, March 2025", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms the corrected return contest definition, the fields it must carry from the original entry, the two banking day contest transmission window, and that the code excludes IAT entries." }, { "source_url": "https://www.jefferson-bank.com/uploadedfiles/includedcontent/business/obligations-of-originators.pdf?v=1D50A930C4ADA00", "source_class": "secondary", "source_title": "Jefferson Bank, Obligations of Originators, revised March 2022", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms the corrected return contest definition, listing the same original entry fields it must carry, and the two banking day contest window." }, { "source_url": "https://bnd.nd.gov/pdf/cashplus_ach_overview.pdf", "source_class": "secondary", "source_title": "Bank of North Dakota, Automated Clearing House Overview, 2024", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms the corrected return contest definition and the two banking day contest window." } ] }, "rail_name": "US ACH", "governing_authority": "Nacha", "snapshot": "2026-09-16", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is not for International ACH Transaction (IAT). Its own scope line reads: every SEC code except IAT.", "from": "applies_to" }, { "kind": "eligibility", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "The rule this rests on, Dishonor and contest codes are not for IAT entries, applies to every SEC code except IAT.", "from": "us-ach:rule.dishonor-codes-exclude-iat" } ] }, { "uid": "us-ach:R75", "id": "R75", "rail": "us-ach", "kind": "reason-code", "name": "Return not a duplicate", "group": "administrative", "summary": "The RDFI answers an R67 dishonor by showing its return was not a duplicate of an earlier one.", "triggers": [ "The ODFI dishonored a return as a duplicate (R67), and the RDFI had returned the entry only once" ], "actions": [ "As the ODFI receiving R75, check whether the two returns you matched really relate to the same original entry" ], "retry": { "allowed": false, "rule": "A contest is the last step on the network. If the ODFI still disagrees after a proper contest, the banks resolve it outside the ACH Network; there is nothing further to send." }, "facts": { "return_windows": [ { "action": "contested dishonored return", "by": "RDFI", "deadline": "2 banking days after the settlement date of the dishonored return" } ], "wsud_required": false, "applies_to": "every SEC code except IAT", "counts_toward": [] }, "caveat": null, "related": [ "us-ach:R67" ], "basis": { "sources": "CBS Bank quick reference (March 2025), Jefferson Bank Obligations of Originators (March 2022) and Bank of North Dakota ACH overview (2024), read 2026-09-19. Nacha Operating Rules, contested dishonored return provisions (not consulted).", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "No rule change identified in the sources read.", "source_edition": "Nacha Operating Rules not consulted; the record rests on the public sources named in its relations and basis", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.cbsbank.com/wp-content/uploads/2025/03/ACH-Return-Reason-Codes.pdf", "source_class": "secondary", "source_title": "CBS Bank, Quick Reference Guide: ACH Return Reason Codes and Time Frames, March 2025", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms the return not a duplicate contest definition, its use to answer an R67 dishonor, the two banking day contest transmission window, and that the code excludes IAT entries." }, { "source_url": "https://www.jefferson-bank.com/uploadedfiles/includedcontent/business/obligations-of-originators.pdf?v=1D50A930C4ADA00", "source_class": "secondary", "source_title": "Jefferson Bank, Obligations of Originators, revised March 2022", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms the return not a duplicate contest definition and its use to contest a dishonor issued under return reason code R67, and the two banking day contest window." }, { "source_url": "https://bnd.nd.gov/pdf/cashplus_ach_overview.pdf", "source_class": "secondary", "source_title": "Bank of North Dakota, Automated Clearing House Overview, 2024", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms the return not a duplicate contest definition and the two banking day contest window." } ] }, "rail_name": "US ACH", "governing_authority": "Nacha", "snapshot": "2026-09-16", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is not for International ACH Transaction (IAT). Its own scope line reads: every SEC code except IAT.", "from": "applies_to" }, { "kind": "eligibility", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "The rule this rests on, Dishonor and contest codes are not for IAT entries, applies to every SEC code except IAT.", "from": "us-ach:rule.dishonor-codes-exclude-iat" } ] }, { "uid": "us-ach:R76", "id": "R76", "rail": "us-ach", "kind": "reason-code", "name": "No errors found", "group": "administrative", "summary": "The RDFI answers an R69 dishonor by stating that its return did not contain the field errors the ODFI named.", "triggers": [ "The ODFI dishonored a return for field errors (R69), and the flagged fields match the original entry" ], "actions": [ "As the RDFI, compare each field code in the dishonor's addenda with the original entry before choosing R76 over R74" ], "retry": { "allowed": false, "rule": "A contest is the last step on the network. If the ODFI still disagrees after a proper contest, the banks resolve it outside the ACH Network; there is nothing further to send." }, "facts": { "return_windows": [ { "action": "contested dishonored return", "by": "RDFI", "deadline": "2 banking days after the settlement date of the dishonored return" } ], "wsud_required": false, "applies_to": "every SEC code except IAT", "counts_toward": [] }, "caveat": null, "related": [ "us-ach:R69", "us-ach:R74" ], "basis": { "sources": "CBS Bank quick reference (March 2025), Jefferson Bank Obligations of Originators (March 2022) and Bank of North Dakota ACH overview (2024), read 2026-09-19. Nacha Operating Rules, contested dishonored return provisions (not consulted).", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "No rule change identified in the sources read.", "source_edition": "Nacha Operating Rules not consulted; the record rests on the public sources named in its relations and basis", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.cbsbank.com/wp-content/uploads/2025/03/ACH-Return-Reason-Codes.pdf", "source_class": "secondary", "source_title": "CBS Bank, Quick Reference Guide: ACH Return Reason Codes and Time Frames, March 2025", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms the no errors found contest definition, its use to answer an R69 dishonor, the two banking day contest transmission window, and that the code excludes IAT entries." }, { "source_url": "https://www.jefferson-bank.com/uploadedfiles/includedcontent/business/obligations-of-originators.pdf?v=1D50A930C4ADA00", "source_class": "secondary", "source_title": "Jefferson Bank, Obligations of Originators, revised March 2022", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms the no errors found contest definition and its use to contest a dishonor issued under return reason code R69, and the two banking day contest window." }, { "source_url": "https://bnd.nd.gov/pdf/cashplus_ach_overview.pdf", "source_class": "secondary", "source_title": "Bank of North Dakota, Automated Clearing House Overview, 2024", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms the no errors found contest definition and the two banking day contest window." } ] }, "rail_name": "US ACH", "governing_authority": "Nacha", "snapshot": "2026-09-16", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is not for International ACH Transaction (IAT). Its own scope line reads: every SEC code except IAT.", "from": "applies_to" }, { "kind": "eligibility", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "The rule this rests on, Dishonor and contest codes are not for IAT entries, applies to every SEC code except IAT.", "from": "us-ach:rule.dishonor-codes-exclude-iat" } ] }, { "uid": "us-ach:R77", "id": "R77", "rail": "us-ach", "kind": "reason-code", "name": "Non-acceptance of R62 dishonored return", "group": "administrative", "summary": "The RDFI refuses an R62 dishonor, because it returned both the erroneous entry and its reversal, or because it cannot get the funds back from the Receiver.", "triggers": [ "The RDFI returned both halves of the erroneous entry and reversal pair, so the Receiver was never left with the credit", "The Receiver no longer holds the funds the R62 dishonor seeks to recover" ], "actions": [ "Use R77 only in answer to an R62 dishonor", "As the ODFI receiving R77, recovery of the unintended credit continues outside the network [Inference]" ], "retry": { "allowed": false, "rule": "A contest is the last step on the network. If the ODFI still disagrees after a proper contest, the banks resolve it outside the ACH Network; there is nothing further to send." }, "facts": { "return_windows": [ { "action": "contested dishonored return", "by": "RDFI", "deadline": "2 banking days after the settlement date of the dishonored return" } ], "wsud_required": false, "applies_to": "every SEC code except IAT", "counts_toward": [] }, "caveat": null, "related": [ "us-ach:R62" ], "basis": { "sources": "CBS Bank quick reference (March 2025), Jefferson Bank Obligations of Originators (March 2022) and Bank of North Dakota ACH overview (2024), read 2026-09-19. Nacha Operating Rules, contested dishonored return provisions (not consulted).", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "No rule change identified in the sources read.", "source_edition": "Nacha Operating Rules not consulted; the record rests on the public sources named in its relations and basis", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.cbsbank.com/wp-content/uploads/2025/03/ACH-Return-Reason-Codes.pdf", "source_class": "secondary", "source_title": "CBS Bank, Quick Reference Guide: ACH Return Reason Codes and Time Frames, March 2025", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms the non-acceptance of R62 dishonored return definition, its two qualifying scenarios, the two banking day contest transmission window, and that the code excludes IAT entries." }, { "source_url": "https://www.jefferson-bank.com/uploadedfiles/includedcontent/business/obligations-of-originators.pdf?v=1D50A930C4ADA00", "source_class": "secondary", "source_title": "Jefferson Bank, Obligations of Originators, revised March 2022", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms the non-acceptance of R62 dishonored return definition and its two qualifying scenarios, returning both the erroneous and reversing entries or being unable to recover funds from the receiver, and the two banking day contest window." }, { "source_url": "https://bnd.nd.gov/pdf/cashplus_ach_overview.pdf", "source_class": "secondary", "source_title": "Bank of North Dakota, Automated Clearing House Overview, 2024", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms the non-acceptance of R62 dishonored return definition and the two banking day contest window." } ] }, "rail_name": "US ACH", "governing_authority": "Nacha", "snapshot": "2026-09-16", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is not for International ACH Transaction (IAT). Its own scope line reads: every SEC code except IAT.", "from": "applies_to" }, { "kind": "eligibility", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "The rule this rests on, Dishonor and contest codes are not for IAT entries, applies to every SEC code except IAT.", "from": "us-ach:rule.dishonor-codes-exclude-iat" } ] }, { "uid": "us-ach:R80", "id": "R80", "rail": "us-ach", "kind": "reason-code", "name": "IAT entry coding error", "group": "technical", "summary": "The Gateway is returning an outbound IAT because one of its IAT specific coding fields holds an invalid value, such as a country code, currency code, bank identifier qualifier, foreign exchange indicator or transaction type code.", "triggers": [ "An invalid ISO destination country code, originating or destination currency code, or bank branch country code on an outbound IAT", "An invalid DFI identification number qualifier or foreign exchange indicator", "An invalid transaction type code (the reason for payment) in the first addendum" ], "actions": [ "Find the field at fault with the Gateway and correct the IAT formatting in the originating system", "Check the ISO codes against the ISO 3166 and ISO 4217 lists; the ACH Operators do not validate them, so the error surfaces only at the Gateway [Inference]" ], "retry": { "allowed": true, "rule": "A corrected entry may be sent once the coding error is fixed; the return reflects a format defect, not a refusal by the receiver [Inference]." }, "facts": { "return_windows": [ { "action": "return", "by": "Gateway", "deadline": "2 banking days [Unverified]" } ], "wsud_required": false, "applies_to": "outbound IAT, returned by the Gateway", "counts_toward": [] }, "caveat": "For Gateway use on outbound IAT only. The list of fields comes from one bank guide; the Nacha rulebook's own list was not read.", "related": [], "basis": { "sources": "Drafted 2026-09-19 from Nacha's public IAT FAQs (web page dated 2021-05-19, and the PDF revised 2021-03-09, questions 40 and 87), which reserve R80 to R85 for Gateways, and from two bank guides read that day: CBS Bank, Quick Reference Guide (March 2025), section on codes used by Gateways for IAT, and BMO, ACH Return Reason Codes (May 2025), section on codes used by Gateway Operators. Code names follow CBS; BMO uses older cross-border wording. The Nacha Operating Rules were not consulted.", "confidence": "low" }, "currency": { "effective_since": "2009-09-18", "effective_to": null, "effective_note": "Gateway return codes of the IAT rule in force since 2009-09-18 [Inference: BMO's older wording suggests some codes existed for the earlier cross-border codes]; no later change identified in the sources read.", "source_edition": "CBS Bank guide, March 2025; BMO guide, May 2025; Nacha IAT FAQs; all read 2026-09-19. Nacha Operating Rules not consulted", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.cbsbank.com/wp-content/uploads/2025/03/ACH-Return-Reason-Codes.pdf", "source_class": "secondary", "source_title": "CBS Bank, Quick Reference Guide: ACH Return Reason Codes and Time Frames, March 2025", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms the IAT entry coding error definition, its list of invalid IAT specific fields, that it is for Gateway use with outbound IAT entries, and the two banking day return window." } ] }, "rail_name": "US ACH", "governing_authority": "Nacha", "snapshot": "2026-09-16", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for International ACH Transaction (IAT). Its own scope line reads: outbound IAT, returned by the Gateway.", "from": "applies_to" } ] }, { "uid": "us-ach:R81", "id": "R81", "rail": "us-ach", "kind": "reason-code", "name": "Non-participant in IAT program", "group": "administrative", "summary": "The Gateway is returning an outbound IAT because it has no agreement with the ODFI, or with the Gateway's own customer, to carry IAT entries.", "triggers": [ "An ODFI or third party sends IAT to a Gateway with which it has no IAT agreement", "An IAT is routed to a Gateway other than the one the ODFI has contracted with [Inference]" ], "actions": [ "The ODFI sets up an IAT agreement with a Gateway that serves the destination country, or routes the payment through its contracted Gateway", "Do not resend until the agreement is in place" ], "retry": { "allowed": false, "rule": "Do not resend to the same Gateway until an IAT agreement exists; once it does, a new entry may be sent [Inference]." }, "facts": { "return_windows": [ { "action": "return", "by": "Gateway", "deadline": "2 banking days [Unverified]" } ], "wsud_required": false, "applies_to": "outbound IAT, returned by the Gateway", "counts_toward": [] }, "caveat": "For Gateway use on outbound IAT only.", "related": [], "basis": { "sources": "Drafted 2026-09-19 from Nacha's public IAT FAQs (web page dated 2021-05-19, and the PDF revised 2021-03-09, questions 40 and 87), which reserve R80 to R85 for Gateways, and from two bank guides read that day: CBS Bank, Quick Reference Guide (March 2025), section on codes used by Gateways for IAT, and BMO, ACH Return Reason Codes (May 2025), section on codes used by Gateway Operators. Code names follow CBS; BMO uses older cross-border wording. The Nacha Operating Rules were not consulted.", "confidence": "low" }, "currency": { "effective_since": "2009-09-18", "effective_to": null, "effective_note": "Gateway return codes of the IAT rule in force since 2009-09-18 [Inference: BMO's older wording suggests some codes existed for the earlier cross-border codes]; no later change identified in the sources read.", "source_edition": "CBS Bank guide, March 2025; BMO guide, May 2025; Nacha IAT FAQs; all read 2026-09-19. Nacha Operating Rules not consulted", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.cbsbank.com/wp-content/uploads/2025/03/ACH-Return-Reason-Codes.pdf", "source_class": "secondary", "source_title": "CBS Bank, Quick Reference Guide: ACH Return Reason Codes and Time Frames, March 2025", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms the non-participant in IAT program definition as a missing agreement with the ODFI or the Gateway's customer, that it is for Gateway use with outbound IAT entries, and the two banking day return window." } ] }, "rail_name": "US ACH", "governing_authority": "Nacha", "snapshot": "2026-09-16", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for International ACH Transaction (IAT). Its own scope line reads: outbound IAT, returned by the Gateway.", "from": "applies_to" } ] }, { "uid": "us-ach:R82", "id": "R82", "rail": "us-ach", "kind": "reason-code", "name": "Invalid foreign receiving DFI identification", "group": "network", "summary": "The Gateway is returning an outbound IAT because the reference identifying the foreign receiving bank is invalid.", "triggers": [ "The foreign receiving bank identifier, or its qualifier, does not match a bank the foreign system recognises" ], "actions": [ "Obtain the correct bank identifier and numbering scheme from the receiver or its bank, then resend", "Update the stored beneficiary bank details so later payments do not fail the same way" ], "retry": { "allowed": true, "rule": "Resend once the foreign bank identifier is corrected [Inference]." }, "facts": { "return_windows": [ { "action": "return", "by": "Gateway", "deadline": "2 banking days [Unverified]" } ], "wsud_required": false, "applies_to": "outbound IAT, returned by the Gateway", "counts_toward": [] }, "caveat": "For Gateway use on outbound IAT only.", "related": [], "basis": { "sources": "Drafted 2026-09-19 from Nacha's public IAT FAQs (web page dated 2021-05-19, and the PDF revised 2021-03-09, questions 40 and 87), which reserve R80 to R85 for Gateways, and from two bank guides read that day: CBS Bank, Quick Reference Guide (March 2025), section on codes used by Gateways for IAT, and BMO, ACH Return Reason Codes (May 2025), section on codes used by Gateway Operators. Code names follow CBS; BMO uses older cross-border wording. The Nacha Operating Rules were not consulted.", "confidence": "low" }, "currency": { "effective_since": "2009-09-18", "effective_to": null, "effective_note": "Gateway return codes of the IAT rule in force since 2009-09-18 [Inference: BMO's older wording suggests some codes existed for the earlier cross-border codes]; no later change identified in the sources read.", "source_edition": "CBS Bank guide, March 2025; BMO guide, May 2025; Nacha IAT FAQs; all read 2026-09-19. Nacha Operating Rules not consulted", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.cbsbank.com/wp-content/uploads/2025/03/ACH-Return-Reason-Codes.pdf", "source_class": "secondary", "source_title": "CBS Bank, Quick Reference Guide: ACH Return Reason Codes and Time Frames, March 2025", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms the invalid foreign receiving DFI identification definition, that it is for Gateway use with outbound IAT entries, and the two banking day return window." } ] }, "rail_name": "US ACH", "governing_authority": "Nacha", "snapshot": "2026-09-16", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for International ACH Transaction (IAT). Its own scope line reads: outbound IAT, returned by the Gateway.", "from": "applies_to" } ] }, { "uid": "us-ach:R83", "id": "R83", "rail": "us-ach", "kind": "reason-code", "name": "Foreign receiving DFI unable to settle", "group": "network", "summary": "The Gateway is returning an outbound IAT because of a settlement problem in the foreign payment system.", "triggers": [ "The foreign clearing or settlement system could not settle the payment with the receiving bank" ], "actions": [ "Ask the Gateway what failed abroad before sending again", "Expect the returned amount to differ from the original if currency was converted" ], "retry": { "allowed": true, "rule": "A new entry may be sent once the Gateway confirms the settlement problem is resolved [Inference]." }, "facts": { "return_windows": [ { "action": "return", "by": "Gateway", "deadline": "2 banking days [Unverified]" } ], "wsud_required": false, "applies_to": "outbound IAT, returned by the Gateway", "counts_toward": [] }, "caveat": "For Gateway use on outbound IAT only.", "related": [], "basis": { "sources": "Drafted 2026-09-19 from Nacha's public IAT FAQs (web page dated 2021-05-19, and the PDF revised 2021-03-09, questions 40 and 87), which reserve R80 to R85 for Gateways, and from two bank guides read that day: CBS Bank, Quick Reference Guide (March 2025), section on codes used by Gateways for IAT, and BMO, ACH Return Reason Codes (May 2025), section on codes used by Gateway Operators. Code names follow CBS; BMO uses older cross-border wording. The Nacha Operating Rules were not consulted.", "confidence": "low" }, "currency": { "effective_since": "2009-09-18", "effective_to": null, "effective_note": "Gateway return codes of the IAT rule in force since 2009-09-18 [Inference: BMO's older wording suggests some codes existed for the earlier cross-border codes]; no later change identified in the sources read.", "source_edition": "CBS Bank guide, March 2025; BMO guide, May 2025; Nacha IAT FAQs; all read 2026-09-19. Nacha Operating Rules not consulted", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.cbsbank.com/wp-content/uploads/2025/03/ACH-Return-Reason-Codes.pdf", "source_class": "secondary", "source_title": "CBS Bank, Quick Reference Guide: ACH Return Reason Codes and Time Frames, March 2025", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms the foreign receiving DFI unable to settle definition, that it is for Gateway use with outbound IAT entries, and the two banking day return window." } ] }, "rail_name": "US ACH", "governing_authority": "Nacha", "snapshot": "2026-09-16", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for International ACH Transaction (IAT). Its own scope line reads: outbound IAT, returned by the Gateway.", "from": "applies_to" } ] }, { "uid": "us-ach:R84", "id": "R84", "rail": "us-ach", "kind": "reason-code", "name": "Entry not processed by Gateway", "group": "administrative", "summary": "The Gateway chose not to process an outbound IAT, either because it would expose the Gateway to excessive risk or because the foreign payment system cannot perform the function needed.", "triggers": [ "The Gateway judges the entry too risky to carry", "The foreign system does not support the function, for example a debit, a prenote or a reversal where the country has none [Inference]" ], "actions": [ "Ask the Gateway which ground applied", "Use another method or another Gateway where the foreign system cannot carry the payment" ], "retry": { "allowed": false, "rule": "Do not resend the same entry through the same Gateway; the Gateway declined it at its discretion." }, "facts": { "return_windows": [ { "action": "return", "by": "Gateway", "deadline": "2 banking days [Unverified]" } ], "wsud_required": false, "applies_to": "outbound IAT, returned by the Gateway", "counts_toward": [] }, "caveat": "For Gateway use on outbound IAT only. BMO's guide gives only the excessive risk ground.", "related": [], "basis": { "sources": "Drafted 2026-09-19 from Nacha's public IAT FAQs (web page dated 2021-05-19, and the PDF revised 2021-03-09, questions 40 and 87), which reserve R80 to R85 for Gateways, and from two bank guides read that day: CBS Bank, Quick Reference Guide (March 2025), section on codes used by Gateways for IAT, and BMO, ACH Return Reason Codes (May 2025), section on codes used by Gateway Operators. Code names follow CBS; BMO uses older cross-border wording. The Nacha Operating Rules were not consulted.", "confidence": "low" }, "currency": { "effective_since": "2009-09-18", "effective_to": null, "effective_note": "Gateway return codes of the IAT rule in force since 2009-09-18 [Inference: BMO's older wording suggests some codes existed for the earlier cross-border codes]; no later change identified in the sources read.", "source_edition": "CBS Bank guide, March 2025; BMO guide, May 2025; Nacha IAT FAQs; all read 2026-09-19. Nacha Operating Rules not consulted", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.cbsbank.com/wp-content/uploads/2025/03/ACH-Return-Reason-Codes.pdf", "source_class": "secondary", "source_title": "CBS Bank, Quick Reference Guide: ACH Return Reason Codes and Time Frames, March 2025", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms the entry not processed by Gateway definition, its two discretionary grounds, that it is for outbound IAT entries, and the two banking day return window." } ] }, "rail_name": "US ACH", "governing_authority": "Nacha", "snapshot": "2026-09-16", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is recorded for International ACH Transaction (IAT). Its own scope line reads: outbound IAT, returned by the Gateway.", "from": "applies_to" } ] }, { "uid": "us-ach:R85", "id": "R85", "rail": "us-ach", "kind": "reason-code", "name": "Incorrectly coded outbound international payment", "group": "technical", "summary": "The RDFI or Gateway is returning an entry sent under a domestic SEC code because it has identified it as an outbound international payment, and the domestic format lacks what the Gateway needs for OFAC compliance.", "triggers": [ "A payment that leaves the US is sent as PPD, CCD or another domestic code instead of IAT" ], "actions": [ "Recode the payment as IAT with the full party information and send it through a Gateway", "Review how the originator decides IAT versus domestic coding, especially under the IAT definition in force from 2026-09-18" ], "retry": { "allowed": true, "rule": "Resend as a properly formatted IAT, not under the same domestic code [Inference]." }, "facts": { "return_windows": [ { "action": "return", "by": "RDFI", "deadline": "2 banking days [Unverified]" } ], "wsud_required": false, "applies_to": "an entry under a domestic SEC code that is really an outbound international payment", "counts_toward": [] }, "caveat": "Returned by the RDFI or the Gateway. Not in BMO's list; CBS Bank's guide and Nacha's FAQ are the sources read.", "related": [], "basis": { "sources": "Drafted 2026-09-19 from Nacha's public IAT FAQs (web page dated 2021-05-19, and the PDF revised 2021-03-09, questions 40 and 87), which reserve R80 to R85 for Gateways, and from two bank guides read that day: CBS Bank, Quick Reference Guide (March 2025), section on codes used by Gateways for IAT, and BMO, ACH Return Reason Codes (May 2025), section on codes used by Gateway Operators. Code names follow CBS; BMO uses older cross-border wording. The Nacha Operating Rules were not consulted.", "confidence": "low" }, "currency": { "effective_since": "2009-09-18", "effective_to": null, "effective_note": "Gateway return codes of the IAT rule in force since 2009-09-18 [Inference: BMO's older wording suggests some codes existed for the earlier cross-border codes]; no later change identified in the sources read.", "source_edition": "CBS Bank guide, March 2025; BMO guide, May 2025; Nacha IAT FAQs; all read 2026-09-19. Nacha Operating Rules not consulted", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.cbsbank.com/wp-content/uploads/2025/03/ACH-Return-Reason-Codes.pdf", "source_class": "secondary", "source_title": "CBS Bank, Quick Reference Guide: ACH Return Reason Codes and Time Frames, March 2025", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms the incorrectly coded outbound international payment definition and the OFAC compliance rationale, and the two banking day return window." } ] }, "rail_name": "US ACH", "governing_authority": "Nacha", "snapshot": "2026-09-16", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "scope", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "This code is not for International ACH Transaction (IAT). Its own scope line reads: an entry under a domestic SEC code that is really an outbound international payment.", "from": "applies_to" } ] }, { "uid": "us-ach:R90", "id": "R90", "rail": "us-ach", "kind": "reason-code", "name": "Entry returned due to RDFI's sanctions compliance obligations", "group": "account", "summary": "The receiving institution, or a Gateway, decided it had to return the entry to meet its own sanctions compliance obligations. Not yet in force: this code takes effect 2028-03-17, and until then sanctions-driven returns use R16.", "triggers": [ "A sanctions screening match on the receiver, the originator, or another party to the entry that the RDFI resolves by returning it", "An international entry that a Gateway determines it cannot pass on under its sanctions program", "A sanctions review that concludes after the entry arrived, since the return clock starts at the RDFI's determination rather than at settlement [Inference]" ], "actions": [ "Do not retry. The return reflects the RDFI's compliance decision, and resending the same entry will meet the same screening", "Route the return to compliance, not collections or customer support, and do not speculate to the receiver about why it came back", "Expect your ODFI to review the relationship with the receiver and possibly the originator; the ODFI has to work out what the return means for the entry and the parties behind it", "Before 2028-03-17, update return handling so R90 is recognized, and stop reading R16 as a possible sanctions signal once the change is in force", "If the entry was a payroll or benefit credit, work out with compliance whether and how the receiver can be paid another way" ], "retry": { "allowed": false, "rule": "Do not reinitiate. A sanctions compliance return is not a condition the originator can cure by resending, and a new entry to the same party should wait for compliance review [Inference]." }, "facts": { "return_windows": [ { "action": "return", "by": "RDFI or Gateway", "deadline": "2 banking days from the RDFI's sanctions compliance determination" } ], "wsud_required": false, "applies_to": "any", "counts_toward": [] }, "caveat": "Pending rule. Approved by Nacha voting members 2025-10-14 with an effective date of 2028-03-17. Before that date sanctions-driven returns still use R16, which then narrows to account freezes only. The return window runs from the RDFI's determination, not from settlement, so an R90 can arrive well after the entry settled [Inference]. Nacha's public pages are silent on return rate treatment; counts_toward is left empty pending a source.", "related": [ "us-ach:R16" ], "basis": { "sources": "Nacha public rule page, New Return Reason Code for Sanctions Compliance Obligations (Appendix Four, Part 4.2; Article Three, Section 3.8, new Subsection 3.8.3.6); Nacha news release of 2025-10-14 on member approval of the IAT rule changes. Rulebook text not consulted.", "confidence": "medium" }, "currency": { "effective_since": "2028-03-17", "effective_to": null, "effective_note": "Approved 2025-10-14; in force 2028-03-17; pending at snapshot 2026-09-17", "source_edition": "Nacha rule change announcement (public page), consulted 2026-09-17; Nacha Operating Rules edition carrying the change not consulted", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.nacha.org/rules/new-return-reason-code-sanctions-compliance-obligations", "source_class": "public_primary", "source_title": "New Return Reason Code for Sanctions Compliance Obligations", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17c", "notes": "Confirms name and meaning, that RDFI or Gateway takes the return, the two banking day window measured from the RDFI's sanctions determination, the 2028-03-17 effective date, and that the code applies to all ACH entries rather than IAT only. Does not address return rate treatment (counts_toward stays empty) or retry handling; approval date 2025-10-14 confirmed separately via Nacha's member-approval news release." } ] }, "rail_name": "US ACH", "governing_authority": "Nacha", "snapshot": "2026-09-16", "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "window", "label": "the payment date", "needs": "the date of the payment you are asking about", "detail": "This code takes effect 2028-03-17, after the corpus snapshot 2026-09-20, so it does not state the rule in force at that snapshot.", "from": "currency.effective_since" } ] }, { "uid": "visa-decline:03", "id": "03", "rail": "visa-decline", "kind": "reason-code", "name": "Invalid merchant", "group": "administrative", "summary": "The issuer will not approve at this merchant. Visa directs issuers to this code when a card belongs to an approved program that restricts where it may be used. Visa places it in category 2, the codes for an issuer that cannot approve at present, so a limited number of reattempts is allowed.", "triggers": [ "The card is in a special-purpose program approved by Visa that restricts use by MCC, merchant, device or location, and the merchant falls outside it; the issuer must decline with 03 (VR 4.1.23.1, ID# 0031139)", "The issuer does not recognize the merchant data in the request [Inference]" ], "actions": [ "Merchant: ask for another card; a program restriction will not lift on a retry [Inference]", "Merchant and acquirer: never change the MCC or merchant data to get around the restriction (VR 1.7.2.1)" ], "retry": { "allowed": true, "rule": "Yes, within a cap: after a category 2 decline the merchant may reattempt, up to 20 attempts in 30 days (VR 7.3.6.3, Table 7-2, ID# 0030640). A reattempt must not deliberately change data from the original request, for example the MCC, the POS entry mode, the e-commerce indicator or the merchant or acquirer country (VR 1.7.2.1, ID# 0008752). Urban mobility merchants follow their own resubmission rule instead (VR 7.3.6.2, ID# 0030046)." }, "facts": { "return_windows": [ { "action": "send this decline response to the authorization or account verification request", "by": "Issuer; if it misses the time limit, Visa answers instead through Stand-In Processing (VR 7.3.4.1)", "deadline": "Within the authorization response time limit: outside Europe 10 seconds for POS and Visa Direct and 25 seconds for ATM cash (MCC 6011); in Europe 5 seconds (VR 7.3.4.1, Table 7-1, ID# 0004385)" }, { "action": "reattempt the authorization request or account verification", "by": "Merchant, through its acquirer", "deadline": "At most 20 attempts within 30 days (VR 7.3.6.3, Table 7-2); the rules read do not say whether the count runs per credential, per merchant or per purchase" } ], "applies_to": "All Visa Regions: an issuer decline of an authorization request or account verification request, under VR 7.3.6.3 and Table 7-2" }, "caveat": "Approved programs must tell cardholders of their limits once a year and restrict only on the criteria Visa allows (VR 4.1.23.1). The program rule does not apply in the LAC Region (Chile) (VR 4.1.23.1 note 1). A decline moves no money and is not a return.", "related": [ "visa-decline:57", "visa-decline:5C", "visa-decline:62" ], "basis": { "sources": "Visa Core Rules and Visa Product and Service Rules, edition 18 April 2026 (marked Visa Public), fetched 2026-09-19 with a plain GET from https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf and read with python3. Table 7-2 in VR 7.3.6.3 (ID# 0030640, last updated April 2026) gives the code, Visa's short label (used here as the name), its category and the merchant reattempt limit; VR 1.7.2.1 (ID# 0008752) bars manipulating data on a reattempt; VR 7.3.4.1 (ID# 0004385) sets the issuer response time limits. Also read: VR 4.1.23.1 (ID# 0031139). Visa gives each code a label and a category only; triggers and actions marked [Inference] are Orca's reading. Nothing is quoted apart from the label, which is Visa's defined name for the code.", "confidence": "medium" }, "currency": { "effective_since": "Not dated in the edition read", "effective_note": "Listed in Table 7-2 of the 18 April 2026 edition; the table rule was last updated in April 2026 and gives no start date for this code. Visa publishes a new edition each April and October; the next is expected in October 2026 [Inference].", "source_edition": "Visa Core Rules and Visa Product and Service Rules, edition 18 April 2026 (Table 7-2, ID# 0030640)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf", "source_class": "authoritative_primary", "source_title": "Visa Core Rules and Visa Product and Service Rules, 18 April 2026", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Table 7-2 (VR 7.3.6.3) confirms the label Invalid merchant, places it in category 2, and confirms the merchant reattempt limit of up to 20 attempts in 30 days subject to the data-manipulation bar in VR 1.7.2.1. VR 4.1.23.1 confirms that an issuer running an approved special-purpose program must decline a merchant outside the program with code 03, must tell cardholders of the program's limits once a year, may restrict only by the listed criteria, and that the program rule does not apply in the LAC Region (Chile)." } ] }, "rail_name": "Visa Authorization Declines", "governing_authority": "Visa (Visa Core Rules and Visa Product and Service Rules)", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "visa-decline:04", "id": "04", "rail": "visa-decline", "kind": "reason-code", "name": "Pick up card (no fraud)", "group": "authorization", "summary": "The issuer refuses the request and asks for the card to be taken out of use, without flagging fraud. Visa places it in category 1, the codes an issuer uses when it will never approve the request, so the merchant may not try this credential again.", "triggers": [ "The issuer has withdrawn or replaced the card for a reason other than fraud [Inference]", "The account is being closed or restricted and the issuer wants the plastic out of circulation [Inference]" ], "actions": [ "Merchant: do not complete the sale; the rules bar completing a transaction after a pickup response (VR 10.6.1.1, ID# 0002350)", "Merchant: do not try to take the card from the customer face to face; if an unattended terminal kept the card, tell the acquirer and follow its instructions (VR 10.6.1.1)", "Member that recovers the card: destroy it securely within 5 business days and notify the issuer through Visa Resolve Online within 5 business days of recovery (VR 10.6.1.2, ID# 0008090)", "Merchant: ask the customer for another way to pay" ], "retry": { "allowed": false, "rule": "No. This is a category 1 code: the issuer will not approve the request however often it is sent, so the merchant must never again send an authorization request or account verification for the same payment credential, and the issuer must keep answering with the same code (VR 7.3.6.3, Table 7-2 and its note 1, ID# 0030640). Asking the cardholder for a different card starts a new payment rather than a reattempt [Inference]." }, "facts": { "return_windows": [ { "action": "send this decline response to the authorization or account verification request", "by": "Issuer; if it misses the time limit, Visa answers instead through Stand-In Processing (VR 7.3.4.1)", "deadline": "Within the authorization response time limit: outside Europe 10 seconds for POS and Visa Direct and 25 seconds for ATM cash (MCC 6011); in Europe 5 seconds (VR 7.3.4.1, Table 7-1, ID# 0004385)" }, { "action": "reattempt the authorization request or account verification for the same payment credential", "by": "Merchant, through its acquirer", "deadline": "Never; no reattempt is allowed for this credential (VR 7.3.6.3, Table 7-2)" } ], "applies_to": "All Visa Regions: an issuer decline of an authorization request or account verification request, under VR 7.3.6.3 and Table 7-2" }, "caveat": "A pickup response is a decline that also asks for the card to be retained (Glossary, Pickup Response, ID# 0024945). In the Europe Region an issuer may not send one to a contactless request, and an acquirer that receives one treats it as a plain decline (VR 7.3.3.5, ID# 0029831). A merchant that completes the sale anyway is open to dispute condition 11.2, and a later approval for the same purchase does not cure it after a pickup code (VR 11.8.2.1, ID# 0030265; 11.8.2.3, ID# 0030267). A decline moves no money and is not a return.", "related": [ "visa-decline:07", "visa-decline:41", "visa-decline:43", "visa-decline:46", "visa:decision-points", "visa-dispute:11.2" ], "basis": { "sources": "Visa Core Rules and Visa Product and Service Rules, edition 18 April 2026 (marked Visa Public), fetched 2026-09-19 with a plain GET from https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf and read with python3. Table 7-2 in VR 7.3.6.3 (ID# 0030640, last updated April 2026) gives the code, Visa's short label (used here as the name), its category and the merchant reattempt limit; VR 1.7.2.1 (ID# 0008752) bars manipulating data on a reattempt; VR 7.3.4.1 (ID# 0004385) sets the issuer response time limits. Also read: Glossary, Pickup Response (ID# 0024945); VR 7.3.3.5 (ID# 0029831); 10.6.1.1 (ID# 0002350); 10.6.1.2 (ID# 0008090); 11.8.2.1 (ID# 0030265); 11.8.2.3 (ID# 0030267). Visa gives each code a label and a category only; triggers and actions marked [Inference] are Orca's reading. Nothing is quoted apart from the label, which is Visa's defined name for the code.", "confidence": "medium" }, "currency": { "effective_since": "Not dated in the edition read", "effective_note": "Listed in Table 7-2 of the 18 April 2026 edition; the table rule was last updated in April 2026 and gives no start date for this code. Visa publishes a new edition each April and October; the next is expected in October 2026 [Inference].", "source_edition": "Visa Core Rules and Visa Product and Service Rules, edition 18 April 2026 (Table 7-2, ID# 0030640)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf", "source_class": "authoritative_primary", "source_title": "Visa Core Rules and Visa Product and Service Rules, 18 April 2026", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Table 7-2 (VR 7.3.6.3) confirms the label Pick up card (no fraud), places it in category 1 among codes the issuer will never approve, and requires the merchant to never resubmit the same payment credential while the issuer keeps sending the same code. The glossary confirms a Pickup Response is a decline paired with a request to retain the card, VR 7.3.3.5 confirms the Europe contactless carve-out, and VR 11.8.2.1 and 11.8.2.3 confirm that dispute condition 11.2 stays open even after a later approval for the same purchase following this code." } ] }, "rail_name": "Visa Authorization Declines", "governing_authority": "Visa (Visa Core Rules and Visa Product and Service Rules)", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "visa-decline:07", "id": "07", "rail": "visa-decline", "kind": "reason-code", "name": "Pick up card, special condition (fraud account)", "group": "authorization", "summary": "The issuer refuses the request and asks for the card to be retained because of a special condition on the account, which Visa's label ties to fraud. Visa places it in category 1, the codes an issuer uses when it will never approve the request, so the merchant may not try this credential again.", "triggers": [ "The issuer has marked the account as used for fraud [Inference from the label]", "The card is counterfeit or compromised and the issuer wants it out of use [Inference]" ], "actions": [ "Merchant: do not complete the sale; the rules bar completing a transaction after a pickup response (VR 10.6.1.1, ID# 0002350)", "Merchant: do not try to take the card from the customer face to face; if an unattended terminal kept the card, tell the acquirer and follow its instructions (VR 10.6.1.1)", "Member that recovers the card: destroy it securely within 5 business days and notify the issuer through Visa Resolve Online within 5 business days of recovery (VR 10.6.1.2, ID# 0008090)", "Merchant: ask the customer for another way to pay" ], "retry": { "allowed": false, "rule": "No. This is a category 1 code: the issuer will not approve the request however often it is sent, so the merchant must never again send an authorization request or account verification for the same payment credential, and the issuer must keep answering with the same code (VR 7.3.6.3, Table 7-2 and its note 1, ID# 0030640). Asking the cardholder for a different card starts a new payment rather than a reattempt [Inference]." }, "facts": { "return_windows": [ { "action": "send this decline response to the authorization or account verification request", "by": "Issuer; if it misses the time limit, Visa answers instead through Stand-In Processing (VR 7.3.4.1)", "deadline": "Within the authorization response time limit: outside Europe 10 seconds for POS and Visa Direct and 25 seconds for ATM cash (MCC 6011); in Europe 5 seconds (VR 7.3.4.1, Table 7-1, ID# 0004385)" }, { "action": "reattempt the authorization request or account verification for the same payment credential", "by": "Merchant, through its acquirer", "deadline": "Never; no reattempt is allowed for this credential (VR 7.3.6.3, Table 7-2)" } ], "applies_to": "All Visa Regions: an issuer decline of an authorization request or account verification request, under VR 7.3.6.3 and Table 7-2" }, "caveat": "A pickup response is a decline that also asks for the card to be retained (Glossary, Pickup Response, ID# 0024945). In the Europe Region an issuer may not send one to a contactless request, and an acquirer that receives one treats it as a plain decline (VR 7.3.3.5, ID# 0029831). A merchant that completes the sale anyway is open to dispute condition 11.2, and a later approval for the same purchase does not cure it after a pickup code (VR 11.8.2.1, ID# 0030265; 11.8.2.3, ID# 0030267). A decline moves no money and is not a return.", "related": [ "visa-decline:04", "visa-decline:41", "visa-decline:43", "visa-decline:59", "visa:liability", "visa-dispute:11.2" ], "basis": { "sources": "Visa Core Rules and Visa Product and Service Rules, edition 18 April 2026 (marked Visa Public), fetched 2026-09-19 with a plain GET from https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf and read with python3. Table 7-2 in VR 7.3.6.3 (ID# 0030640, last updated April 2026) gives the code, Visa's short label (used here as the name), its category and the merchant reattempt limit; VR 1.7.2.1 (ID# 0008752) bars manipulating data on a reattempt; VR 7.3.4.1 (ID# 0004385) sets the issuer response time limits. Also read: Glossary, Pickup Response (ID# 0024945); VR 7.3.3.5 (ID# 0029831); 10.6.1.1 (ID# 0002350); 10.6.1.2 (ID# 0008090); 11.8.2.1 (ID# 0030265); 11.8.2.3 (ID# 0030267). Visa gives each code a label and a category only; triggers and actions marked [Inference] are Orca's reading. Nothing is quoted apart from the label, which is Visa's defined name for the code.", "confidence": "medium" }, "currency": { "effective_since": "Not dated in the edition read", "effective_note": "Listed in Table 7-2 of the 18 April 2026 edition; the table rule was last updated in April 2026 and gives no start date for this code. Visa publishes a new edition each April and October; the next is expected in October 2026 [Inference].", "source_edition": "Visa Core Rules and Visa Product and Service Rules, edition 18 April 2026 (Table 7-2, ID# 0030640)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf", "source_class": "authoritative_primary", "source_title": "Visa Core Rules and Visa Product and Service Rules, 18 April 2026", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Table 7-2 (VR 7.3.6.3) confirms the label Pick up card, special condition (fraud account), places it in category 1 among codes the issuer will never approve, and requires the merchant to never resubmit the same payment credential while the issuer keeps sending the same code. The glossary confirms a Pickup Response is a decline paired with a request to retain the card, VR 7.3.3.5 confirms the Europe contactless carve-out, and VR 11.8.2.1 and 11.8.2.3 confirm that dispute condition 11.2 stays open even after a later approval for the same purchase following this code." } ] }, "rail_name": "Visa Authorization Declines", "governing_authority": "Visa (Visa Core Rules and Visa Product and Service Rules)", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "visa-decline:12", "id": "12", "rail": "visa-decline", "kind": "reason-code", "name": "Invalid transaction", "group": "administrative", "summary": "The issuer treats the request itself as invalid for this card, as opposed to a problem with funds or the cardholder. Visa places it in category 1, the codes an issuer uses when it will never approve the request, so the merchant may not resend it for the same credential.", "triggers": [ "The transaction type or processing code is one the issuer does not support for this card [Inference]", "The request is malformed or combines values the issuer cannot accept [Inference]" ], "actions": [ "Merchant or acquirer: check that the transaction type and message set-up match what was intended [Inference]", "Merchant: ask for another way to pay; do not resend to this credential" ], "retry": { "allowed": false, "rule": "No. This is a category 1 code: the issuer will not approve the request however often it is sent, so the merchant must never again send an authorization request or account verification for the same payment credential, and the issuer must keep answering with the same code (VR 7.3.6.3, Table 7-2 and its note 1, ID# 0030640). Asking the cardholder for a different card starts a new payment rather than a reattempt [Inference]." }, "facts": { "return_windows": [ { "action": "send this decline response to the authorization or account verification request", "by": "Issuer; if it misses the time limit, Visa answers instead through Stand-In Processing (VR 7.3.4.1)", "deadline": "Within the authorization response time limit: outside Europe 10 seconds for POS and Visa Direct and 25 seconds for ATM cash (MCC 6011); in Europe 5 seconds (VR 7.3.4.1, Table 7-1, ID# 0004385)" }, { "action": "reattempt the authorization request or account verification for the same payment credential", "by": "Merchant, through its acquirer", "deadline": "Never; no reattempt is allowed for this credential (VR 7.3.6.3, Table 7-2)" } ], "applies_to": "All Visa Regions: an issuer decline of an authorization request or account verification request, under VR 7.3.6.3 and Table 7-2" }, "caveat": "Visa's label is broad and the rules read give no example of when an issuer should choose 12 over a category 2 or 3 code. Because it is category 1, a request refused with 12 cannot be retried even after a fix to the same credential [Inference from Table 7-2].", "related": [ "visa-decline:57", "visa-decline:CATEGORY_4", "visa:decision-points" ], "basis": { "sources": "Visa Core Rules and Visa Product and Service Rules, edition 18 April 2026 (marked Visa Public), fetched 2026-09-19 with a plain GET from https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf and read with python3. Table 7-2 in VR 7.3.6.3 (ID# 0030640, last updated April 2026) gives the code, Visa's short label (used here as the name), its category and the merchant reattempt limit; VR 1.7.2.1 (ID# 0008752) bars manipulating data on a reattempt; VR 7.3.4.1 (ID# 0004385) sets the issuer response time limits. Visa gives each code a label and a category only; triggers and actions marked [Inference] are Orca's reading. Nothing is quoted apart from the label, which is Visa's defined name for the code.", "confidence": "medium" }, "currency": { "effective_since": "Not dated in the edition read", "effective_note": "Listed in Table 7-2 of the 18 April 2026 edition; the table rule was last updated in April 2026 and gives no start date for this code. Visa publishes a new edition each April and October; the next is expected in October 2026 [Inference].", "source_edition": "Visa Core Rules and Visa Product and Service Rules, edition 18 April 2026 (Table 7-2, ID# 0030640)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf", "source_class": "authoritative_primary", "source_title": "Visa Core Rules and Visa Product and Service Rules, 18 April 2026", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Table 7-2 (VR 7.3.6.3) confirms the label Invalid Transaction, places it in category 1 among codes the issuer will never approve, and requires the merchant to never resubmit the same payment credential while the issuer keeps sending the same code. The table gives no further definition of the code, matching the record's own account of the limits of what is published." } ] }, "rail_name": "Visa Authorization Declines", "governing_authority": "Visa (Visa Core Rules and Visa Product and Service Rules)", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "visa-decline:14", "id": "14", "rail": "visa-decline", "kind": "reason-code", "name": "Invalid account number (no such number)", "group": "account", "summary": "The issuer does not recognize the account number: no such account exists in its records. Visa places it in category 1, the codes an issuer uses when it will never approve the request, so the merchant may not try this number again.", "triggers": [ "The card number was keyed or stored wrongly [Inference]", "The number was never issued, or belongs to a card replaced under a new number [Inference]" ], "actions": [ "Merchant: check how the number was captured, and ask the cardholder to re-enter or present the card", "Merchant holding stored credentials: remove the number and ask the cardholder for current details [Inference]" ], "retry": { "allowed": false, "rule": "No. This is a category 1 code: the issuer will not approve the request however often it is sent, so the merchant must never again send an authorization request or account verification for the same payment credential, and the issuer must keep answering with the same code (VR 7.3.6.3, Table 7-2 and its note 1, ID# 0030640). Asking the cardholder for a different card starts a new payment rather than a reattempt [Inference]." }, "facts": { "return_windows": [ { "action": "send this decline response to the authorization or account verification request", "by": "Issuer; if it misses the time limit, Visa answers instead through Stand-In Processing (VR 7.3.4.1)", "deadline": "Within the authorization response time limit: outside Europe 10 seconds for POS and Visa Direct and 25 seconds for ATM cash (MCC 6011); in Europe 5 seconds (VR 7.3.4.1, Table 7-1, ID# 0004385)" }, { "action": "reattempt the authorization request or account verification for the same payment credential", "by": "Merchant, through its acquirer", "deadline": "Never; no reattempt is allowed for this credential (VR 7.3.6.3, Table 7-2)" } ], "applies_to": "All Visa Regions: an issuer decline of an authorization request or account verification request, under VR 7.3.6.3 and Table 7-2" }, "caveat": "A corrected number is a different credential, so a fresh request with the right number is not a reattempt of this one [Inference]. A decline moves no money and is not a return.", "related": [ "visa-decline:15", "visa-decline:46", "visa-decline:54" ], "basis": { "sources": "Visa Core Rules and Visa Product and Service Rules, edition 18 April 2026 (marked Visa Public), fetched 2026-09-19 with a plain GET from https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf and read with python3. Table 7-2 in VR 7.3.6.3 (ID# 0030640, last updated April 2026) gives the code, Visa's short label (used here as the name), its category and the merchant reattempt limit; VR 1.7.2.1 (ID# 0008752) bars manipulating data on a reattempt; VR 7.3.4.1 (ID# 0004385) sets the issuer response time limits. Visa gives each code a label and a category only; triggers and actions marked [Inference] are Orca's reading. Nothing is quoted apart from the label, which is Visa's defined name for the code.", "confidence": "medium" }, "currency": { "effective_since": "Not dated in the edition read", "effective_note": "Listed in Table 7-2 of the 18 April 2026 edition; the table rule was last updated in April 2026 and gives no start date for this code. Visa publishes a new edition each April and October; the next is expected in October 2026 [Inference].", "source_edition": "Visa Core Rules and Visa Product and Service Rules, edition 18 April 2026 (Table 7-2, ID# 0030640)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf", "source_class": "authoritative_primary", "source_title": "Visa Core Rules and Visa Product and Service Rules, 18 April 2026", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Table 7-2 (VR 7.3.6.3) confirms the label Invalid account number (no such number), places it in category 1 among codes the issuer will never approve, and requires the merchant to never resubmit the same payment credential while the issuer keeps sending the same code." } ] }, "rail_name": "Visa Authorization Declines", "governing_authority": "Visa (Visa Core Rules and Visa Product and Service Rules)", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "visa-decline:15", "id": "15", "rail": "visa-decline", "kind": "reason-code", "name": "No such issuer (first 8 digits of account number do not relate to an issuing identifier)", "group": "account", "summary": "The leading digits of the account number do not belong to any issuing identifier, so the request cannot be matched to an issuer. Visa places it in category 1, the codes an issuer uses when it will never approve the request, so the merchant may not try this number again.", "triggers": [ "The first 8 digits were mistyped [Inference]", "The acquirer's routing data is out of date [Inference]" ], "actions": [ "Acquirer: if it relies on Visa's Account Range table for routing, it must use the table to validate cards and install each update within 6 business days (VR 7.3.1.1, ID# 0008754)", "Merchant: ask the cardholder to re-enter or present the card, or to pay another way" ], "retry": { "allowed": false, "rule": "No. This is a category 1 code: the issuer will not approve the request however often it is sent, so the merchant must never again send an authorization request or account verification for the same payment credential, and the issuer must keep answering with the same code (VR 7.3.6.3, Table 7-2 and its note 1, ID# 0030640). Asking the cardholder for a different card starts a new payment rather than a reattempt [Inference]." }, "facts": { "return_windows": [ { "action": "send this decline response to the authorization or account verification request", "by": "Issuer; if it misses the time limit, Visa answers instead through Stand-In Processing (VR 7.3.4.1)", "deadline": "Within the authorization response time limit: outside Europe 10 seconds for POS and Visa Direct and 25 seconds for ATM cash (MCC 6011); in Europe 5 seconds (VR 7.3.4.1, Table 7-1, ID# 0004385)" }, { "action": "reattempt the authorization request or account verification for the same payment credential", "by": "Merchant, through its acquirer", "deadline": "Never; no reattempt is allowed for this credential (VR 7.3.6.3, Table 7-2)" } ], "applies_to": "All Visa Regions: an issuer decline of an authorization request or account verification request, under VR 7.3.6.3 and Table 7-2" }, "caveat": "Visa's label points at the first 8 digits of the account number as the part that identifies the issuer. A decline moves no money and is not a return.", "related": [ "visa-decline:14", "visa:messages" ], "basis": { "sources": "Visa Core Rules and Visa Product and Service Rules, edition 18 April 2026 (marked Visa Public), fetched 2026-09-19 with a plain GET from https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf and read with python3. Table 7-2 in VR 7.3.6.3 (ID# 0030640, last updated April 2026) gives the code, Visa's short label (used here as the name), its category and the merchant reattempt limit; VR 1.7.2.1 (ID# 0008752) bars manipulating data on a reattempt; VR 7.3.4.1 (ID# 0004385) sets the issuer response time limits. Also read: VR 7.3.1.1 (ID# 0008754). Visa gives each code a label and a category only; triggers and actions marked [Inference] are Orca's reading. Nothing is quoted apart from the label, which is Visa's defined name for the code.", "confidence": "medium" }, "currency": { "effective_since": "Not dated in the edition read", "effective_note": "Listed in Table 7-2 of the 18 April 2026 edition; the table rule was last updated in April 2026 and gives no start date for this code. Visa publishes a new edition each April and October; the next is expected in October 2026 [Inference].", "source_edition": "Visa Core Rules and Visa Product and Service Rules, edition 18 April 2026 (Table 7-2, ID# 0030640)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf", "source_class": "authoritative_primary", "source_title": "Visa Core Rules and Visa Product and Service Rules, 18 April 2026", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Table 7-2 (VR 7.3.6.3) confirms the label No such issuer, naming the first 8 digits of the account number as the part that fails to relate to an issuing identifier, places it in category 1 among codes the issuer will never approve, and requires the merchant to never resubmit the same payment credential while the issuer keeps sending the same code." } ] }, "rail_name": "Visa Authorization Declines", "governing_authority": "Visa (Visa Core Rules and Visa Product and Service Rules)", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "visa-decline:19", "id": "19", "rail": "visa-decline", "kind": "reason-code", "name": "Re-enter transaction", "group": "administrative", "summary": "The issuer asks for the transaction to be sent again. Visa places it in category 2, the codes for an issuer that cannot approve at present, so the merchant may reattempt within the cap.", "triggers": [ "A short-lived processing problem at the issuer [Inference]", "The issuer could not complete its checks on the first attempt [Inference]" ], "actions": [ "Merchant: resend the same request unchanged after a short pause [Inference]", "Merchant: stop after repeated failures and ask for another way to pay" ], "retry": { "allowed": true, "rule": "Yes, within a cap: after a category 2 decline the merchant may reattempt, up to 20 attempts in 30 days (VR 7.3.6.3, Table 7-2, ID# 0030640). A reattempt must not deliberately change data from the original request, for example the MCC, the POS entry mode, the e-commerce indicator or the merchant or acquirer country (VR 1.7.2.1, ID# 0008752). Urban mobility merchants follow their own resubmission rule instead (VR 7.3.6.2, ID# 0030046)." }, "facts": { "return_windows": [ { "action": "send this decline response to the authorization or account verification request", "by": "Issuer; if it misses the time limit, Visa answers instead through Stand-In Processing (VR 7.3.4.1)", "deadline": "Within the authorization response time limit: outside Europe 10 seconds for POS and Visa Direct and 25 seconds for ATM cash (MCC 6011); in Europe 5 seconds (VR 7.3.4.1, Table 7-1, ID# 0004385)" }, { "action": "reattempt the authorization request or account verification", "by": "Merchant, through its acquirer", "deadline": "At most 20 attempts within 30 days (VR 7.3.6.3, Table 7-2); the rules read do not say whether the count runs per credential, per merchant or per purchase" } ], "applies_to": "All Visa Regions: an issuer decline of an authorization request or account verification request, under VR 7.3.6.3 and Table 7-2" }, "caveat": "The rules read give no detail on when an issuer uses 19 rather than 91 or 96. A decline moves no money and is not a return.", "related": [ "visa-decline:91", "visa-decline:96" ], "basis": { "sources": "Visa Core Rules and Visa Product and Service Rules, edition 18 April 2026 (marked Visa Public), fetched 2026-09-19 with a plain GET from https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf and read with python3. Table 7-2 in VR 7.3.6.3 (ID# 0030640, last updated April 2026) gives the code, Visa's short label (used here as the name), its category and the merchant reattempt limit; VR 1.7.2.1 (ID# 0008752) bars manipulating data on a reattempt; VR 7.3.4.1 (ID# 0004385) sets the issuer response time limits. Visa gives each code a label and a category only; triggers and actions marked [Inference] are Orca's reading. Nothing is quoted apart from the label, which is Visa's defined name for the code.", "confidence": "medium" }, "currency": { "effective_since": "Not dated in the edition read", "effective_note": "Listed in Table 7-2 of the 18 April 2026 edition; the table rule was last updated in April 2026 and gives no start date for this code. Visa publishes a new edition each April and October; the next is expected in October 2026 [Inference].", "source_edition": "Visa Core Rules and Visa Product and Service Rules, edition 18 April 2026 (Table 7-2, ID# 0030640)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf", "source_class": "authoritative_primary", "source_title": "Visa Core Rules and Visa Product and Service Rules, 18 April 2026", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Table 7-2 (VR 7.3.6.3) confirms the label Re-enter Transaction, places it in category 2, and confirms the merchant reattempt limit of up to 20 attempts in 30 days subject to the data-manipulation bar in VR 1.7.2.1. The table gives no further detail on when an issuer chooses this code over 91 or 96, matching the record's own account of the limits of what is published." } ] }, "rail_name": "Visa Authorization Declines", "governing_authority": "Visa (Visa Core Rules and Visa Product and Service Rules)", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "visa-decline:1A", "id": "1A", "rail": "visa-decline", "kind": "reason-code", "name": "Additional customer authentication required", "group": "authorization", "summary": "The issuer requires further customer authentication before it will approve. Only issuers in the CEMEA and Europe Regions use this code. Visa places it in category 3, the data-quality codes that tell the merchant to check the payment details again, so the merchant may authenticate the cardholder and reattempt within the cap.", "triggers": [ "An e-commerce transaction on a card issued in the EEA or the United Kingdom arrived without the strong customer authentication Visa requires in Europe (VR 7.9.1.1, ID# 0030622) [Inference that 1A is how the issuer signals it]" ], "actions": [ "Merchant: authenticate the cardholder, for example through Visa Secure, and send a new request [Inference]" ], "retry": { "allowed": true, "rule": "Yes, within a cap: after a category 3 decline the merchant may reattempt, up to 20 attempts in 30 days (VR 7.3.6.3, Table 7-2, ID# 0030640). A reattempt must not deliberately change data from the original request, for example the MCC, the POS entry mode, the e-commerce indicator or the merchant or acquirer country (VR 1.7.2.1, ID# 0008752). Correcting card data the cardholder gave (an expiry date, a PIN, a security code) is what a data-quality decline invites, and does not count as the manipulation VR 1.7.2.1 forbids, which concerns merchant and acquirer data [Inference]. Urban mobility merchants follow their own resubmission rule instead (VR 7.3.6.2, ID# 0030046)." }, "facts": { "return_windows": [ { "action": "send this decline response to the authorization or account verification request", "by": "Issuer; if it misses the time limit, Visa answers instead through Stand-In Processing (VR 7.3.4.1)", "deadline": "Within the authorization response time limit: outside Europe 10 seconds for POS and Visa Direct and 25 seconds for ATM cash (MCC 6011); in Europe 5 seconds (VR 7.3.4.1, Table 7-1, ID# 0004385)" }, { "action": "reattempt the authorization request or account verification", "by": "Merchant, through its acquirer", "deadline": "At most 20 attempts within 30 days (VR 7.3.6.3, Table 7-2); the rules read do not say whether the count runs per credential, per merchant or per purchase" } ], "applies_to": "CEMEA and Europe Regions only: Table 7-2 lists this code for issuers in those two regions; under VR 1.1.1.5 a region-labelled rule applies only there" }, "caveat": "Table 7-2 lists 1A only for the CEMEA and Europe Regions. The rules read do not say how a resubmission after authentication squares with the bar on changing the e-commerce indicator on a reattempt (VR 1.7.2.1) [Unverified]. A decline moves no money and is not a return.", "related": [ "visa-decline:70", "visa-decline:59", "visa:consumer-law" ], "basis": { "sources": "Visa Core Rules and Visa Product and Service Rules, edition 18 April 2026 (marked Visa Public), fetched 2026-09-19 with a plain GET from https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf and read with python3. Table 7-2 in VR 7.3.6.3 (ID# 0030640, last updated April 2026) gives the code, Visa's short label (used here as the name), its category and the merchant reattempt limit; VR 1.7.2.1 (ID# 0008752) bars manipulating data on a reattempt; VR 7.3.4.1 (ID# 0004385) sets the issuer response time limits. Also read: VR 7.9.1.1 (ID# 0030622). Visa gives each code a label and a category only; triggers and actions marked [Inference] are Orca's reading. Nothing is quoted apart from the label, which is Visa's defined name for the code.", "confidence": "medium" }, "currency": { "effective_since": "Not dated in the edition read", "effective_note": "Listed in Table 7-2 of the 18 April 2026 edition; the table rule was last updated in April 2026 and gives no start date for this code. Visa publishes a new edition each April and October; the next is expected in October 2026 [Inference].", "source_edition": "Visa Core Rules and Visa Product and Service Rules, edition 18 April 2026 (Table 7-2, ID# 0030640)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf", "source_class": "authoritative_primary", "source_title": "Visa Core Rules and Visa Product and Service Rules, 18 April 2026", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Table 7-2 (VR 7.3.6.3) confirms the label Additional customer authentication required, confirms it is listed only for issuers in the CEMEA and Europe Regions, places it in category 3, and confirms the merchant reattempt limit of up to 20 attempts in 30 days subject to the data-manipulation bar in VR 1.7.2.1." } ] }, "rail_name": "Visa Authorization Declines", "governing_authority": "Visa (Visa Core Rules and Visa Product and Service Rules)", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "visa-decline:39", "id": "39", "rail": "visa-decline", "kind": "reason-code", "name": "No credit account", "group": "account", "summary": "The card has no credit account of the kind the request asked for. Visa places it in category 2, the codes for an issuer that cannot approve at present, so the merchant may reattempt within the cap.", "triggers": [ "The cardholder or terminal selected a credit account the card does not carry, for example at an ATM or PIN terminal offering account choice [Inference]" ], "actions": [ "Merchant or ATM: let the cardholder choose the right account type and try again [Inference]" ], "retry": { "allowed": true, "rule": "Yes, within a cap: after a category 2 decline the merchant may reattempt, up to 20 attempts in 30 days (VR 7.3.6.3, Table 7-2, ID# 0030640). A reattempt must not deliberately change data from the original request, for example the MCC, the POS entry mode, the e-commerce indicator or the merchant or acquirer country (VR 1.7.2.1, ID# 0008752). Urban mobility merchants follow their own resubmission rule instead (VR 7.3.6.2, ID# 0030046)." }, "facts": { "return_windows": [ { "action": "send this decline response to the authorization or account verification request", "by": "Issuer; if it misses the time limit, Visa answers instead through Stand-In Processing (VR 7.3.4.1)", "deadline": "Within the authorization response time limit: outside Europe 10 seconds for POS and Visa Direct and 25 seconds for ATM cash (MCC 6011); in Europe 5 seconds (VR 7.3.4.1, Table 7-1, ID# 0004385)" }, { "action": "reattempt the authorization request or account verification", "by": "Merchant, through its acquirer", "deadline": "At most 20 attempts within 30 days (VR 7.3.6.3, Table 7-2); the rules read do not say whether the count runs per credential, per merchant or per purchase" } ], "applies_to": "All Visa Regions: an issuer decline of an authorization request or account verification request, under VR 7.3.6.3 and Table 7-2" }, "caveat": "A decline moves no money and is not a return. The rules read do not describe account selection; the reading here rests on Visa's label.", "related": [ "visa-decline:52", "visa-decline:53" ], "basis": { "sources": "Visa Core Rules and Visa Product and Service Rules, edition 18 April 2026 (marked Visa Public), fetched 2026-09-19 with a plain GET from https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf and read with python3. Table 7-2 in VR 7.3.6.3 (ID# 0030640, last updated April 2026) gives the code, Visa's short label (used here as the name), its category and the merchant reattempt limit; VR 1.7.2.1 (ID# 0008752) bars manipulating data on a reattempt; VR 7.3.4.1 (ID# 0004385) sets the issuer response time limits. Visa gives each code a label and a category only; triggers and actions marked [Inference] are Orca's reading. Nothing is quoted apart from the label, which is Visa's defined name for the code.", "confidence": "medium" }, "currency": { "effective_since": "Not dated in the edition read", "effective_note": "Listed in Table 7-2 of the 18 April 2026 edition; the table rule was last updated in April 2026 and gives no start date for this code. Visa publishes a new edition each April and October; the next is expected in October 2026 [Inference].", "source_edition": "Visa Core Rules and Visa Product and Service Rules, edition 18 April 2026 (Table 7-2, ID# 0030640)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf", "source_class": "authoritative_primary", "source_title": "Visa Core Rules and Visa Product and Service Rules, 18 April 2026", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Table 7-2 (VR 7.3.6.3) confirms the label No credit account, places it in category 2, and confirms the merchant reattempt limit of up to 20 attempts in 30 days subject to the data-manipulation bar in VR 1.7.2.1." } ] }, "rail_name": "Visa Authorization Declines", "governing_authority": "Visa (Visa Core Rules and Visa Product and Service Rules)", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "visa-decline:41", "id": "41", "rail": "visa-decline", "kind": "reason-code", "name": "Lost card, pick up", "group": "authorization", "summary": "The card has been reported lost and the issuer asks for it to be retained. Visa places it in category 1, the codes an issuer uses when it will never approve the request, so the merchant may not try this credential again.", "triggers": [ "The cardholder told the issuer the card is lost", "The issuer listed the card on the Visa Account Screen, which it must do at once for a card reported lost, so Stand-In Processing declines it too (VR 7.3.5.1, ID# 0003235) [Inference as to the stand-in effect]" ], "actions": [ "Merchant: do not complete the sale; the rules bar completing a transaction after a pickup response (VR 10.6.1.1, ID# 0002350)", "Merchant: do not try to take the card from the customer face to face; if an unattended terminal kept the card, tell the acquirer and follow its instructions (VR 10.6.1.1)", "Member that recovers the card: destroy it securely within 5 business days and notify the issuer through Visa Resolve Online within 5 business days of recovery (VR 10.6.1.2, ID# 0008090)", "Merchant: ask the customer for another way to pay" ], "retry": { "allowed": false, "rule": "No. This is a category 1 code: the issuer will not approve the request however often it is sent, so the merchant must never again send an authorization request or account verification for the same payment credential, and the issuer must keep answering with the same code (VR 7.3.6.3, Table 7-2 and its note 1, ID# 0030640). Asking the cardholder for a different card starts a new payment rather than a reattempt [Inference]." }, "facts": { "return_windows": [ { "action": "send this decline response to the authorization or account verification request", "by": "Issuer; if it misses the time limit, Visa answers instead through Stand-In Processing (VR 7.3.4.1)", "deadline": "Within the authorization response time limit: outside Europe 10 seconds for POS and Visa Direct and 25 seconds for ATM cash (MCC 6011); in Europe 5 seconds (VR 7.3.4.1, Table 7-1, ID# 0004385)" }, { "action": "reattempt the authorization request or account verification for the same payment credential", "by": "Merchant, through its acquirer", "deadline": "Never; no reattempt is allowed for this credential (VR 7.3.6.3, Table 7-2)" } ], "applies_to": "All Visa Regions: an issuer decline of an authorization request or account verification request, under VR 7.3.6.3 and Table 7-2" }, "caveat": "A pickup response is a decline that also asks for the card to be retained (Glossary, Pickup Response, ID# 0024945). In the Europe Region an issuer may not send one to a contactless request, and an acquirer that receives one treats it as a plain decline (VR 7.3.3.5, ID# 0029831). A merchant that completes the sale anyway is open to dispute condition 11.2, and a later approval for the same purchase does not cure it after a pickup code (VR 11.8.2.1, ID# 0030265; 11.8.2.3, ID# 0030267). A decline moves no money and is not a return.", "related": [ "visa-decline:43", "visa-decline:04", "visa-decline:07", "visa:liability", "visa-dispute:11.2" ], "basis": { "sources": "Visa Core Rules and Visa Product and Service Rules, edition 18 April 2026 (marked Visa Public), fetched 2026-09-19 with a plain GET from https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf and read with python3. Table 7-2 in VR 7.3.6.3 (ID# 0030640, last updated April 2026) gives the code, Visa's short label (used here as the name), its category and the merchant reattempt limit; VR 1.7.2.1 (ID# 0008752) bars manipulating data on a reattempt; VR 7.3.4.1 (ID# 0004385) sets the issuer response time limits. Also read: Glossary, Pickup Response (ID# 0024945); VR 7.3.3.5 (ID# 0029831); 10.6.1.1 (ID# 0002350); 10.6.1.2 (ID# 0008090); 11.8.2.1 (ID# 0030265); 11.8.2.3 (ID# 0030267). VR 7.3.5.1 (ID# 0003235). Visa gives each code a label and a category only; triggers and actions marked [Inference] are Orca's reading. Nothing is quoted apart from the label, which is Visa's defined name for the code.", "confidence": "medium" }, "currency": { "effective_since": "Not dated in the edition read", "effective_note": "Listed in Table 7-2 of the 18 April 2026 edition; the table rule was last updated in April 2026 and gives no start date for this code. Visa publishes a new edition each April and October; the next is expected in October 2026 [Inference].", "source_edition": "Visa Core Rules and Visa Product and Service Rules, edition 18 April 2026 (Table 7-2, ID# 0030640)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf", "source_class": "authoritative_primary", "source_title": "Visa Core Rules and Visa Product and Service Rules, 18 April 2026", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Table 7-2 (VR 7.3.6.3) confirms the label Lost card, pick up, places it in category 1 among codes the issuer will never approve, and requires the merchant to never resubmit the same payment credential while the issuer keeps sending the same code. The glossary confirms a Pickup Response is a decline paired with a request to retain the card, VR 7.3.3.5 confirms the Europe contactless carve-out, and VR 11.8.2.1 and 11.8.2.3 confirm that dispute condition 11.2 stays open even after a later approval for the same purchase following this code." } ] }, "rail_name": "Visa Authorization Declines", "governing_authority": "Visa (Visa Core Rules and Visa Product and Service Rules)", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "visa-decline:43", "id": "43", "rail": "visa-decline", "kind": "reason-code", "name": "Stolen card, pick up", "group": "authorization", "summary": "The card has been reported stolen and the issuer asks for it to be retained. Visa places it in category 1, the codes an issuer uses when it will never approve the request, so the merchant may not try this credential again.", "triggers": [ "The cardholder told the issuer the card was stolen", "The issuer listed the card on the Visa Account Screen, which it must do at once for a card reported stolen (VR 7.3.5.1, ID# 0003235)" ], "actions": [ "Merchant: do not complete the sale; the rules bar completing a transaction after a pickup response (VR 10.6.1.1, ID# 0002350)", "Merchant: do not try to take the card from the customer face to face; if an unattended terminal kept the card, tell the acquirer and follow its instructions (VR 10.6.1.1)", "Member that recovers the card: destroy it securely within 5 business days and notify the issuer through Visa Resolve Online within 5 business days of recovery (VR 10.6.1.2, ID# 0008090)", "Merchant: ask the customer for another way to pay" ], "retry": { "allowed": false, "rule": "No. This is a category 1 code: the issuer will not approve the request however often it is sent, so the merchant must never again send an authorization request or account verification for the same payment credential, and the issuer must keep answering with the same code (VR 7.3.6.3, Table 7-2 and its note 1, ID# 0030640). Asking the cardholder for a different card starts a new payment rather than a reattempt [Inference]." }, "facts": { "return_windows": [ { "action": "send this decline response to the authorization or account verification request", "by": "Issuer; if it misses the time limit, Visa answers instead through Stand-In Processing (VR 7.3.4.1)", "deadline": "Within the authorization response time limit: outside Europe 10 seconds for POS and Visa Direct and 25 seconds for ATM cash (MCC 6011); in Europe 5 seconds (VR 7.3.4.1, Table 7-1, ID# 0004385)" }, { "action": "reattempt the authorization request or account verification for the same payment credential", "by": "Merchant, through its acquirer", "deadline": "Never; no reattempt is allowed for this credential (VR 7.3.6.3, Table 7-2)" } ], "applies_to": "All Visa Regions: an issuer decline of an authorization request or account verification request, under VR 7.3.6.3 and Table 7-2" }, "caveat": "A pickup response is a decline that also asks for the card to be retained (Glossary, Pickup Response, ID# 0024945). In the Europe Region an issuer may not send one to a contactless request, and an acquirer that receives one treats it as a plain decline (VR 7.3.3.5, ID# 0029831). A merchant that completes the sale anyway is open to dispute condition 11.2, and a later approval for the same purchase does not cure it after a pickup code (VR 11.8.2.1, ID# 0030265; 11.8.2.3, ID# 0030267). A decline moves no money and is not a return.", "related": [ "visa-decline:41", "visa-decline:04", "visa-decline:07", "visa:liability", "visa-dispute:11.2" ], "basis": { "sources": "Visa Core Rules and Visa Product and Service Rules, edition 18 April 2026 (marked Visa Public), fetched 2026-09-19 with a plain GET from https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf and read with python3. Table 7-2 in VR 7.3.6.3 (ID# 0030640, last updated April 2026) gives the code, Visa's short label (used here as the name), its category and the merchant reattempt limit; VR 1.7.2.1 (ID# 0008752) bars manipulating data on a reattempt; VR 7.3.4.1 (ID# 0004385) sets the issuer response time limits. Also read: Glossary, Pickup Response (ID# 0024945); VR 7.3.3.5 (ID# 0029831); 10.6.1.1 (ID# 0002350); 10.6.1.2 (ID# 0008090); 11.8.2.1 (ID# 0030265); 11.8.2.3 (ID# 0030267). VR 7.3.5.1 (ID# 0003235). Visa gives each code a label and a category only; triggers and actions marked [Inference] are Orca's reading. Nothing is quoted apart from the label, which is Visa's defined name for the code.", "confidence": "medium" }, "currency": { "effective_since": "Not dated in the edition read", "effective_note": "Listed in Table 7-2 of the 18 April 2026 edition; the table rule was last updated in April 2026 and gives no start date for this code. Visa publishes a new edition each April and October; the next is expected in October 2026 [Inference].", "source_edition": "Visa Core Rules and Visa Product and Service Rules, edition 18 April 2026 (Table 7-2, ID# 0030640)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf", "source_class": "authoritative_primary", "source_title": "Visa Core Rules and Visa Product and Service Rules, 18 April 2026", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Table 7-2 (VR 7.3.6.3) confirms the label Stolen card, pick up, places it in category 1 among codes the issuer will never approve, and requires the merchant to never resubmit the same payment credential while the issuer keeps sending the same code. The glossary confirms a Pickup Response is a decline paired with a request to retain the card, VR 7.3.3.5 confirms the Europe contactless carve-out, and VR 11.8.2.1 and 11.8.2.3 confirm that dispute condition 11.2 stays open even after a later approval for the same purchase following this code." } ] }, "rail_name": "Visa Authorization Declines", "governing_authority": "Visa (Visa Core Rules and Visa Product and Service Rules)", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "visa-decline:46", "id": "46", "rail": "visa-decline", "kind": "reason-code", "name": "Closed account", "group": "account", "summary": "The account behind the card is closed. Visa places it in category 1, the codes an issuer uses when it will never approve the request, so the merchant may not try this credential again.", "triggers": [ "The cardholder or the issuer closed the account", "A stored credential for a recurring or card-on-file payment points to an account that no longer exists [Inference]" ], "actions": [ "Merchant: stop billing this credential and ask the cardholder for a new way to pay", "Merchant owing the cardholder a refund on a closed account: the refund may go to a second credential if the cardholder has proof of purchase, or by other means (VR 1.5.4.14, ID# 0003076)" ], "retry": { "allowed": false, "rule": "No. This is a category 1 code: the issuer will not approve the request however often it is sent, so the merchant must never again send an authorization request or account verification for the same payment credential, and the issuer must keep answering with the same code (VR 7.3.6.3, Table 7-2 and its note 1, ID# 0030640). Asking the cardholder for a different card starts a new payment rather than a reattempt [Inference]." }, "facts": { "return_windows": [ { "action": "send this decline response to the authorization or account verification request", "by": "Issuer; if it misses the time limit, Visa answers instead through Stand-In Processing (VR 7.3.4.1)", "deadline": "Within the authorization response time limit: outside Europe 10 seconds for POS and Visa Direct and 25 seconds for ATM cash (MCC 6011); in Europe 5 seconds (VR 7.3.4.1, Table 7-1, ID# 0004385)" }, { "action": "reattempt the authorization request or account verification for the same payment credential", "by": "Merchant, through its acquirer", "deadline": "Never; no reattempt is allowed for this credential (VR 7.3.6.3, Table 7-2)" } ], "applies_to": "All Visa Regions: an issuer decline of an authorization request or account verification request, under VR 7.3.6.3 and Table 7-2" }, "caveat": "A decline moves no money and is not a return. Closure of the card account does not by itself cancel the cardholder's contract with the merchant [Inference].", "related": [ "visa-decline:14", "visa-decline:R1", "visa:refund" ], "basis": { "sources": "Visa Core Rules and Visa Product and Service Rules, edition 18 April 2026 (marked Visa Public), fetched 2026-09-19 with a plain GET from https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf and read with python3. Table 7-2 in VR 7.3.6.3 (ID# 0030640, last updated April 2026) gives the code, Visa's short label (used here as the name), its category and the merchant reattempt limit; VR 1.7.2.1 (ID# 0008752) bars manipulating data on a reattempt; VR 7.3.4.1 (ID# 0004385) sets the issuer response time limits. Also read: VR 1.5.4.14 (ID# 0003076). Visa gives each code a label and a category only; triggers and actions marked [Inference] are Orca's reading. Nothing is quoted apart from the label, which is Visa's defined name for the code.", "confidence": "medium" }, "currency": { "effective_since": "Not dated in the edition read", "effective_note": "Listed in Table 7-2 of the 18 April 2026 edition; the table rule was last updated in April 2026 and gives no start date for this code. Visa publishes a new edition each April and October; the next is expected in October 2026 [Inference].", "source_edition": "Visa Core Rules and Visa Product and Service Rules, edition 18 April 2026 (Table 7-2, ID# 0030640)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf", "source_class": "authoritative_primary", "source_title": "Visa Core Rules and Visa Product and Service Rules, 18 April 2026", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Table 7-2 (VR 7.3.6.3) confirms the label Closed account, places it in category 1 among codes the issuer will never approve, and requires the merchant to never resubmit the same payment credential while the issuer keeps sending the same code." } ] }, "rail_name": "Visa Authorization Declines", "governing_authority": "Visa (Visa Core Rules and Visa Product and Service Rules)", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "visa-decline:51", "id": "51", "rail": "visa-decline", "kind": "reason-code", "name": "Not sufficient funds", "group": "funds", "summary": "The account does not have enough available balance or credit for the amount. Visa places it in category 2, the codes for an issuer that cannot approve at present, so the merchant may reattempt within the cap.", "triggers": [ "The balance or open-to-buy is below the amount", "Funds are held by earlier authorizations [Inference]" ], "actions": [ "Merchant: ask for another card or a smaller amount", "Merchant billing on a schedule: retry later within the limit of 20 attempts in 30 days, without changing the request data (VR 1.7.2.1)" ], "retry": { "allowed": true, "rule": "Yes, within a cap: after a category 2 decline the merchant may reattempt, up to 20 attempts in 30 days (VR 7.3.6.3, Table 7-2, ID# 0030640). A reattempt must not deliberately change data from the original request, for example the MCC, the POS entry mode, the e-commerce indicator or the merchant or acquirer country (VR 1.7.2.1, ID# 0008752). Urban mobility merchants follow their own resubmission rule instead (VR 7.3.6.2, ID# 0030046)." }, "facts": { "return_windows": [ { "action": "send this decline response to the authorization or account verification request", "by": "Issuer; if it misses the time limit, Visa answers instead through Stand-In Processing (VR 7.3.4.1)", "deadline": "Within the authorization response time limit: outside Europe 10 seconds for POS and Visa Direct and 25 seconds for ATM cash (MCC 6011); in Europe 5 seconds (VR 7.3.4.1, Table 7-1, ID# 0004385)" }, { "action": "reattempt the authorization request or account verification", "by": "Merchant, through its acquirer", "deadline": "At most 20 attempts within 30 days (VR 7.3.6.3, Table 7-2); the rules read do not say whether the count runs per credential, per merchant or per purchase" } ], "applies_to": "All Visa Regions: an issuer decline of an authorization request or account verification request, under VR 7.3.6.3 and Table 7-2" }, "caveat": "Do not treat this as the card version of an ACH insufficient-funds return: a decline happens before any money moves, while an ACH return sends back money already posted. In the LAC Region, a Visa Infinite Corporate card with no preset limit may be declined with 51 only when the transaction takes the balance more than 20% over the approved line or is an ATM withdrawal over activity limits, and the issuer must warn the cardholder first (VR 4.24.2.2, ID# 0027743).", "related": [ "visa-decline:61", "visa-decline:N4", "visa-decline:Z5", "visa:limits", "visa-dispute:11.2" ], "basis": { "sources": "Visa Core Rules and Visa Product and Service Rules, edition 18 April 2026 (marked Visa Public), fetched 2026-09-19 with a plain GET from https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf and read with python3. Table 7-2 in VR 7.3.6.3 (ID# 0030640, last updated April 2026) gives the code, Visa's short label (used here as the name), its category and the merchant reattempt limit; VR 1.7.2.1 (ID# 0008752) bars manipulating data on a reattempt; VR 7.3.4.1 (ID# 0004385) sets the issuer response time limits. Also read: VR 4.24.2.2 (ID# 0027743). Visa gives each code a label and a category only; triggers and actions marked [Inference] are Orca's reading. Nothing is quoted apart from the label, which is Visa's defined name for the code.", "confidence": "medium" }, "currency": { "effective_since": "Not dated in the edition read", "effective_note": "Listed in Table 7-2 of the 18 April 2026 edition; the table rule was last updated in April 2026 and gives no start date for this code. Visa publishes a new edition each April and October; the next is expected in October 2026 [Inference].", "source_edition": "Visa Core Rules and Visa Product and Service Rules, edition 18 April 2026 (Table 7-2, ID# 0030640)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf", "source_class": "authoritative_primary", "source_title": "Visa Core Rules and Visa Product and Service Rules, 18 April 2026", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Table 7-2 (VR 7.3.6.3) confirms the label Not sufficient funds, places it in category 2, and confirms the merchant reattempt limit of up to 20 attempts in 30 days subject to the data-manipulation bar in VR 1.7.2.1. VR 4.24.2.2 confirms the LAC Region Visa Infinite Corporate Card no-preset-limit carve-out: a decline with this code needs prior cardholder notice, and is limited to a balance more than 20 percent over the approved line or an ATM disbursement over activity parameters." } ] }, "rail_name": "Visa Authorization Declines", "governing_authority": "Visa (Visa Core Rules and Visa Product and Service Rules)", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "visa-decline:52", "id": "52", "rail": "visa-decline", "kind": "reason-code", "name": "No checking account", "group": "account", "summary": "The card has no checking account of the kind the request asked for. Visa places it in category 2, the codes for an issuer that cannot approve at present, so the merchant may reattempt within the cap.", "triggers": [ "The cardholder or terminal selected a checking account that the card does not link to [Inference]" ], "actions": [ "Merchant or ATM: let the cardholder choose the right account type and try again [Inference]" ], "retry": { "allowed": true, "rule": "Yes, within a cap: after a category 2 decline the merchant may reattempt, up to 20 attempts in 30 days (VR 7.3.6.3, Table 7-2, ID# 0030640). A reattempt must not deliberately change data from the original request, for example the MCC, the POS entry mode, the e-commerce indicator or the merchant or acquirer country (VR 1.7.2.1, ID# 0008752). Urban mobility merchants follow their own resubmission rule instead (VR 7.3.6.2, ID# 0030046)." }, "facts": { "return_windows": [ { "action": "send this decline response to the authorization or account verification request", "by": "Issuer; if it misses the time limit, Visa answers instead through Stand-In Processing (VR 7.3.4.1)", "deadline": "Within the authorization response time limit: outside Europe 10 seconds for POS and Visa Direct and 25 seconds for ATM cash (MCC 6011); in Europe 5 seconds (VR 7.3.4.1, Table 7-1, ID# 0004385)" }, { "action": "reattempt the authorization request or account verification", "by": "Merchant, through its acquirer", "deadline": "At most 20 attempts within 30 days (VR 7.3.6.3, Table 7-2); the rules read do not say whether the count runs per credential, per merchant or per purchase" } ], "applies_to": "All Visa Regions: an issuer decline of an authorization request or account verification request, under VR 7.3.6.3 and Table 7-2" }, "caveat": "A decline moves no money and is not a return. The rules read do not describe account selection; the reading here rests on Visa's label.", "related": [ "visa-decline:39", "visa-decline:53" ], "basis": { "sources": "Visa Core Rules and Visa Product and Service Rules, edition 18 April 2026 (marked Visa Public), fetched 2026-09-19 with a plain GET from https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf and read with python3. Table 7-2 in VR 7.3.6.3 (ID# 0030640, last updated April 2026) gives the code, Visa's short label (used here as the name), its category and the merchant reattempt limit; VR 1.7.2.1 (ID# 0008752) bars manipulating data on a reattempt; VR 7.3.4.1 (ID# 0004385) sets the issuer response time limits. Visa gives each code a label and a category only; triggers and actions marked [Inference] are Orca's reading. Nothing is quoted apart from the label, which is Visa's defined name for the code.", "confidence": "medium" }, "currency": { "effective_since": "Not dated in the edition read", "effective_note": "Listed in Table 7-2 of the 18 April 2026 edition; the table rule was last updated in April 2026 and gives no start date for this code. Visa publishes a new edition each April and October; the next is expected in October 2026 [Inference].", "source_edition": "Visa Core Rules and Visa Product and Service Rules, edition 18 April 2026 (Table 7-2, ID# 0030640)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf", "source_class": "authoritative_primary", "source_title": "Visa Core Rules and Visa Product and Service Rules, 18 April 2026", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Table 7-2 (VR 7.3.6.3) confirms the label No checking account, places it in category 2, and confirms the merchant reattempt limit of up to 20 attempts in 30 days subject to the data-manipulation bar in VR 1.7.2.1." } ] }, "rail_name": "Visa Authorization Declines", "governing_authority": "Visa (Visa Core Rules and Visa Product and Service Rules)", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "visa-decline:53", "id": "53", "rail": "visa-decline", "kind": "reason-code", "name": "No savings account", "group": "account", "summary": "The card has no savings account of the kind the request asked for. Visa places it in category 2, the codes for an issuer that cannot approve at present, so the merchant may reattempt within the cap.", "triggers": [ "The cardholder or terminal selected a savings account that the card does not link to [Inference]" ], "actions": [ "Merchant or ATM: let the cardholder choose the right account type and try again [Inference]" ], "retry": { "allowed": true, "rule": "Yes, within a cap: after a category 2 decline the merchant may reattempt, up to 20 attempts in 30 days (VR 7.3.6.3, Table 7-2, ID# 0030640). A reattempt must not deliberately change data from the original request, for example the MCC, the POS entry mode, the e-commerce indicator or the merchant or acquirer country (VR 1.7.2.1, ID# 0008752). Urban mobility merchants follow their own resubmission rule instead (VR 7.3.6.2, ID# 0030046)." }, "facts": { "return_windows": [ { "action": "send this decline response to the authorization or account verification request", "by": "Issuer; if it misses the time limit, Visa answers instead through Stand-In Processing (VR 7.3.4.1)", "deadline": "Within the authorization response time limit: outside Europe 10 seconds for POS and Visa Direct and 25 seconds for ATM cash (MCC 6011); in Europe 5 seconds (VR 7.3.4.1, Table 7-1, ID# 0004385)" }, { "action": "reattempt the authorization request or account verification", "by": "Merchant, through its acquirer", "deadline": "At most 20 attempts within 30 days (VR 7.3.6.3, Table 7-2); the rules read do not say whether the count runs per credential, per merchant or per purchase" } ], "applies_to": "All Visa Regions: an issuer decline of an authorization request or account verification request, under VR 7.3.6.3 and Table 7-2" }, "caveat": "A decline moves no money and is not a return. The rules read do not describe account selection; the reading here rests on Visa's label.", "related": [ "visa-decline:39", "visa-decline:52" ], "basis": { "sources": "Visa Core Rules and Visa Product and Service Rules, edition 18 April 2026 (marked Visa Public), fetched 2026-09-19 with a plain GET from https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf and read with python3. Table 7-2 in VR 7.3.6.3 (ID# 0030640, last updated April 2026) gives the code, Visa's short label (used here as the name), its category and the merchant reattempt limit; VR 1.7.2.1 (ID# 0008752) bars manipulating data on a reattempt; VR 7.3.4.1 (ID# 0004385) sets the issuer response time limits. Visa gives each code a label and a category only; triggers and actions marked [Inference] are Orca's reading. Nothing is quoted apart from the label, which is Visa's defined name for the code.", "confidence": "medium" }, "currency": { "effective_since": "Not dated in the edition read", "effective_note": "Listed in Table 7-2 of the 18 April 2026 edition; the table rule was last updated in April 2026 and gives no start date for this code. Visa publishes a new edition each April and October; the next is expected in October 2026 [Inference].", "source_edition": "Visa Core Rules and Visa Product and Service Rules, edition 18 April 2026 (Table 7-2, ID# 0030640)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf", "source_class": "authoritative_primary", "source_title": "Visa Core Rules and Visa Product and Service Rules, 18 April 2026", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Table 7-2 (VR 7.3.6.3) confirms the label No savings account, places it in category 2, and confirms the merchant reattempt limit of up to 20 attempts in 30 days subject to the data-manipulation bar in VR 1.7.2.1." } ] }, "rail_name": "Visa Authorization Declines", "governing_authority": "Visa (Visa Core Rules and Visa Product and Service Rules)", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "visa-decline:54", "id": "54", "rail": "visa-decline", "kind": "reason-code", "name": "Expired card or expiration date missing", "group": "account", "summary": "The card has expired, or the expiry date is missing from the request. Visa places it in category 3, the data-quality codes that tell the merchant to check the payment details again, so the merchant may correct and reattempt within the cap.", "triggers": [ "The expiry date on file has passed", "The expiry date was not captured or not sent [Inference]" ], "actions": [ "Merchant: ask the cardholder for the current card and its expiry date", "Merchant holding stored credentials: update the card details before the next scheduled charge [Inference]" ], "retry": { "allowed": true, "rule": "Yes, within a cap: after a category 3 decline the merchant may reattempt, up to 20 attempts in 30 days (VR 7.3.6.3, Table 7-2, ID# 0030640). A reattempt must not deliberately change data from the original request, for example the MCC, the POS entry mode, the e-commerce indicator or the merchant or acquirer country (VR 1.7.2.1, ID# 0008752). Correcting card data the cardholder gave (an expiry date, a PIN, a security code) is what a data-quality decline invites, and does not count as the manipulation VR 1.7.2.1 forbids, which concerns merchant and acquirer data [Inference]. Urban mobility merchants follow their own resubmission rule instead (VR 7.3.6.2, ID# 0030046)." }, "facts": { "return_windows": [ { "action": "send this decline response to the authorization or account verification request", "by": "Issuer; if it misses the time limit, Visa answers instead through Stand-In Processing (VR 7.3.4.1)", "deadline": "Within the authorization response time limit: outside Europe 10 seconds for POS and Visa Direct and 25 seconds for ATM cash (MCC 6011); in Europe 5 seconds (VR 7.3.4.1, Table 7-1, ID# 0004385)" }, { "action": "reattempt the authorization request or account verification", "by": "Merchant, through its acquirer", "deadline": "At most 20 attempts within 30 days (VR 7.3.6.3, Table 7-2); the rules read do not say whether the count runs per credential, per merchant or per purchase" } ], "applies_to": "All Visa Regions: an issuer decline of an authorization request or account verification request, under VR 7.3.6.3 and Table 7-2" }, "caveat": "A decline moves no money and is not a return.", "related": [ "visa-decline:14", "visa-decline:N7", "visa-decline:82" ], "basis": { "sources": "Visa Core Rules and Visa Product and Service Rules, edition 18 April 2026 (marked Visa Public), fetched 2026-09-19 with a plain GET from https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf and read with python3. Table 7-2 in VR 7.3.6.3 (ID# 0030640, last updated April 2026) gives the code, Visa's short label (used here as the name), its category and the merchant reattempt limit; VR 1.7.2.1 (ID# 0008752) bars manipulating data on a reattempt; VR 7.3.4.1 (ID# 0004385) sets the issuer response time limits. Visa gives each code a label and a category only; triggers and actions marked [Inference] are Orca's reading. Nothing is quoted apart from the label, which is Visa's defined name for the code.", "confidence": "medium" }, "currency": { "effective_since": "Not dated in the edition read", "effective_note": "Listed in Table 7-2 of the 18 April 2026 edition; the table rule was last updated in April 2026 and gives no start date for this code. Visa publishes a new edition each April and October; the next is expected in October 2026 [Inference].", "source_edition": "Visa Core Rules and Visa Product and Service Rules, edition 18 April 2026 (Table 7-2, ID# 0030640)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf", "source_class": "authoritative_primary", "source_title": "Visa Core Rules and Visa Product and Service Rules, 18 April 2026", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Table 7-2 (VR 7.3.6.3) confirms the label Expired card or expiration date missing, places it in category 3, and confirms the merchant reattempt limit of up to 20 attempts in 30 days subject to the data-manipulation bar in VR 1.7.2.1." } ] }, "rail_name": "Visa Authorization Declines", "governing_authority": "Visa (Visa Core Rules and Visa Product and Service Rules)", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "visa-decline:55", "id": "55", "rail": "visa-decline", "kind": "reason-code", "name": "PIN incorrect or missing", "group": "authorization", "summary": "The PIN entered is wrong, or no PIN came with a request that needs one. Visa places it in category 3, the data-quality codes that tell the merchant to check the payment details again, so the cardholder may re-enter and the merchant may reattempt within the cap.", "triggers": [ "The cardholder keyed the wrong PIN", "The terminal did not capture or send a PIN where the issuer requires one [Inference]" ], "actions": [ "Merchant: ask the cardholder to enter the PIN again", "Merchant: stop after repeated failures; the issuer may lock PIN use (see 75) [Inference]" ], "retry": { "allowed": true, "rule": "Yes, within a cap: after a category 3 decline the merchant may reattempt, up to 20 attempts in 30 days (VR 7.3.6.3, Table 7-2, ID# 0030640). A reattempt must not deliberately change data from the original request, for example the MCC, the POS entry mode, the e-commerce indicator or the merchant or acquirer country (VR 1.7.2.1, ID# 0008752). Correcting card data the cardholder gave (an expiry date, a PIN, a security code) is what a data-quality decline invites, and does not count as the manipulation VR 1.7.2.1 forbids, which concerns merchant and acquirer data [Inference]. Urban mobility merchants follow their own resubmission rule instead (VR 7.3.6.2, ID# 0030046)." }, "facts": { "return_windows": [ { "action": "send this decline response to the authorization or account verification request", "by": "Issuer; if it misses the time limit, Visa answers instead through Stand-In Processing (VR 7.3.4.1)", "deadline": "Within the authorization response time limit: outside Europe 10 seconds for POS and Visa Direct and 25 seconds for ATM cash (MCC 6011); in Europe 5 seconds (VR 7.3.4.1, Table 7-1, ID# 0004385)" }, { "action": "reattempt the authorization request or account verification", "by": "Merchant, through its acquirer", "deadline": "At most 20 attempts within 30 days (VR 7.3.6.3, Table 7-2); the rules read do not say whether the count runs per credential, per merchant or per purchase" } ], "applies_to": "All Visa Regions: an issuer decline of an authorization request or account verification request, under VR 7.3.6.3 and Table 7-2" }, "caveat": "In the AP Region (India), an issuer must decline a domestic card-present debit or reloadable prepaid transaction that comes without a PIN or confirmation of a correct PIN; the rule does not name the code (VR 4.1.9.1, ID# 0027954). A decline moves no money and is not a return.", "related": [ "visa-decline:75", "visa-decline:86", "visa-decline:70" ], "basis": { "sources": "Visa Core Rules and Visa Product and Service Rules, edition 18 April 2026 (marked Visa Public), fetched 2026-09-19 with a plain GET from https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf and read with python3. Table 7-2 in VR 7.3.6.3 (ID# 0030640, last updated April 2026) gives the code, Visa's short label (used here as the name), its category and the merchant reattempt limit; VR 1.7.2.1 (ID# 0008752) bars manipulating data on a reattempt; VR 7.3.4.1 (ID# 0004385) sets the issuer response time limits. Also read: VR 4.1.9.1 (ID# 0027954). Visa gives each code a label and a category only; triggers and actions marked [Inference] are Orca's reading. Nothing is quoted apart from the label, which is Visa's defined name for the code.", "confidence": "medium" }, "currency": { "effective_since": "Not dated in the edition read", "effective_note": "Listed in Table 7-2 of the 18 April 2026 edition; the table rule was last updated in April 2026 and gives no start date for this code. Visa publishes a new edition each April and October; the next is expected in October 2026 [Inference].", "source_edition": "Visa Core Rules and Visa Product and Service Rules, edition 18 April 2026 (Table 7-2, ID# 0030640)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf", "source_class": "authoritative_primary", "source_title": "Visa Core Rules and Visa Product and Service Rules, 18 April 2026", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Table 7-2 (VR 7.3.6.3) confirms the label PIN incorrect or missing, places it in category 3, and confirms the merchant reattempt limit of up to 20 attempts in 30 days subject to the data-manipulation bar in VR 1.7.2.1. VR 4.1.9.1 confirms the AP Region (India) rule requiring a decline when a domestic card-present debit or reloadable prepaid transaction arrives without a PIN or PIN confirmation, though it does not name which decline code applies." } ] }, "rail_name": "Visa Authorization Declines", "governing_authority": "Visa (Visa Core Rules and Visa Product and Service Rules)", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "visa-decline:57", "id": "57", "rail": "visa-decline", "kind": "reason-code", "name": "Transaction not permitted to cardholder", "group": "administrative", "summary": "The cardholder's card or account is not allowed to make this kind of transaction. Visa places it in category 1, the codes an issuer uses when it will never approve the request, so the merchant may not try this credential again.", "triggers": [ "The card product does not permit the transaction type, for example a non-reloadable prepaid card asked to verify an account for a recurring payment, which the issuer must decline with 57 (VR 7.3.10.1, ID# 0031047)", "The cardholder's agreement excludes the transaction [Inference]" ], "actions": [ "Merchant: ask for another card; a card that is not allowed the transaction will not become allowed by resending", "Merchant setting up recurring billing: do not store a non-reloadable prepaid card declined with 57 for that purpose" ], "retry": { "allowed": false, "rule": "No. This is a category 1 code: the issuer will not approve the request however often it is sent, so the merchant must never again send an authorization request or account verification for the same payment credential, and the issuer must keep answering with the same code (VR 7.3.6.3, Table 7-2 and its note 1, ID# 0030640). Asking the cardholder for a different card starts a new payment rather than a reattempt [Inference]." }, "facts": { "return_windows": [ { "action": "send this decline response to the authorization or account verification request", "by": "Issuer; if it misses the time limit, Visa answers instead through Stand-In Processing (VR 7.3.4.1)", "deadline": "Within the authorization response time limit: outside Europe 10 seconds for POS and Visa Direct and 25 seconds for ATM cash (MCC 6011); in Europe 5 seconds (VR 7.3.4.1, Table 7-1, ID# 0004385)" }, { "action": "reattempt the authorization request or account verification for the same payment credential", "by": "Merchant, through its acquirer", "deadline": "Never; no reattempt is allowed for this credential (VR 7.3.6.3, Table 7-2)" } ], "applies_to": "All Visa Regions: an issuer decline of an authorization request or account verification request, under VR 7.3.6.3 and Table 7-2" }, "caveat": "Code 57 describes the cardholder's permission; code 03 is the one Visa assigns where a card program restricts the merchant (VR 4.1.23.1, ID# 0031139). A decline moves no money and is not a return.", "related": [ "visa-decline:03", "visa-decline:12", "visa-decline:5C" ], "basis": { "sources": "Visa Core Rules and Visa Product and Service Rules, edition 18 April 2026 (marked Visa Public), fetched 2026-09-19 with a plain GET from https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf and read with python3. Table 7-2 in VR 7.3.6.3 (ID# 0030640, last updated April 2026) gives the code, Visa's short label (used here as the name), its category and the merchant reattempt limit; VR 1.7.2.1 (ID# 0008752) bars manipulating data on a reattempt; VR 7.3.4.1 (ID# 0004385) sets the issuer response time limits. Also read: VR 7.3.10.1 (ID# 0031047); 4.1.23.1 (ID# 0031139). Visa gives each code a label and a category only; triggers and actions marked [Inference] are Orca's reading. Nothing is quoted apart from the label, which is Visa's defined name for the code.", "confidence": "medium" }, "currency": { "effective_since": "Not dated in the edition read", "effective_note": "Listed in Table 7-2 of the 18 April 2026 edition; the table rule was last updated in April 2026 and gives no start date for this code. Visa publishes a new edition each April and October; the next is expected in October 2026 [Inference].", "source_edition": "Visa Core Rules and Visa Product and Service Rules, edition 18 April 2026 (Table 7-2, ID# 0030640)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf", "source_class": "authoritative_primary", "source_title": "Visa Core Rules and Visa Product and Service Rules, 18 April 2026", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Table 7-2 (VR 7.3.6.3) confirms the label Transaction not permitted to cardholder, places it in category 1 among codes the issuer will never approve, and requires the merchant to never resubmit the same payment credential while the issuer keeps sending the same code. VR 7.3.10.1 confirms an issuer must decline an account verification request for a recurring transaction on a non-reloadable prepaid card with this code." } ] }, "rail_name": "Visa Authorization Declines", "governing_authority": "Visa (Visa Core Rules and Visa Product and Service Rules)", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "visa-decline:59", "id": "59", "rail": "visa-decline", "kind": "reason-code", "name": "Suspected fraud", "group": "authorization", "summary": "The issuer suspects the transaction is fraudulent and declines it for now. Visa places it in category 2, the codes for an issuer that cannot approve at present, so the merchant may reattempt within the cap.", "triggers": [ "The issuer's fraud screening scored the transaction as risky [Inference]", "Unusual location, amount or merchant for this cardholder [Inference]" ], "actions": [ "Merchant: ask the cardholder to contact the issuer, then retry once the issuer has cleared the card [Inference]", "Merchant: do not alter request data to get past the screen (VR 1.7.2.1)" ], "retry": { "allowed": true, "rule": "Yes, within a cap: after a category 2 decline the merchant may reattempt, up to 20 attempts in 30 days (VR 7.3.6.3, Table 7-2, ID# 0030640). A reattempt must not deliberately change data from the original request, for example the MCC, the POS entry mode, the e-commerce indicator or the merchant or acquirer country (VR 1.7.2.1, ID# 0008752). Urban mobility merchants follow their own resubmission rule instead (VR 7.3.6.2, ID# 0030046)." }, "facts": { "return_windows": [ { "action": "send this decline response to the authorization or account verification request", "by": "Issuer; if it misses the time limit, Visa answers instead through Stand-In Processing (VR 7.3.4.1)", "deadline": "Within the authorization response time limit: outside Europe 10 seconds for POS and Visa Direct and 25 seconds for ATM cash (MCC 6011); in Europe 5 seconds (VR 7.3.4.1, Table 7-1, ID# 0004385)" }, { "action": "reattempt the authorization request or account verification", "by": "Merchant, through its acquirer", "deadline": "At most 20 attempts within 30 days (VR 7.3.6.3, Table 7-2); the rules read do not say whether the count runs per credential, per merchant or per purchase" } ], "applies_to": "All Visa Regions: an issuer decline of an authorization request or account verification request, under VR 7.3.6.3 and Table 7-2" }, "caveat": "Unlike 07, 41 and 43, this code is not permanent: Visa puts it in category 2. The issuer must still judge each transaction on its merits rather than decline wholesale (VR 1.7.4.1, ID# 0029326). A decline moves no money and is not a return.", "related": [ "visa-decline:83", "visa-decline:07", "visa-decline:1A", "visa:decision-points", "visa-dispute:11.2" ], "basis": { "sources": "Visa Core Rules and Visa Product and Service Rules, edition 18 April 2026 (marked Visa Public), fetched 2026-09-19 with a plain GET from https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf and read with python3. Table 7-2 in VR 7.3.6.3 (ID# 0030640, last updated April 2026) gives the code, Visa's short label (used here as the name), its category and the merchant reattempt limit; VR 1.7.2.1 (ID# 0008752) bars manipulating data on a reattempt; VR 7.3.4.1 (ID# 0004385) sets the issuer response time limits. Also read: VR 1.7.4.1 (ID# 0029326). Visa gives each code a label and a category only; triggers and actions marked [Inference] are Orca's reading. Nothing is quoted apart from the label, which is Visa's defined name for the code.", "confidence": "medium" }, "currency": { "effective_since": "Not dated in the edition read", "effective_note": "Listed in Table 7-2 of the 18 April 2026 edition; the table rule was last updated in April 2026 and gives no start date for this code. Visa publishes a new edition each April and October; the next is expected in October 2026 [Inference].", "source_edition": "Visa Core Rules and Visa Product and Service Rules, edition 18 April 2026 (Table 7-2, ID# 0030640)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf", "source_class": "authoritative_primary", "source_title": "Visa Core Rules and Visa Product and Service Rules, 18 April 2026", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Table 7-2 (VR 7.3.6.3) confirms the label Suspected fraud, places it in category 2, and confirms the merchant reattempt limit of up to 20 attempts in 30 days subject to the data-manipulation bar in VR 1.7.2.1. VR 1.7.4.1 confirms the issuer must evaluate each transaction and must not block, refuse or decline in a systematic or wholesale manner, apart from listed exceptions." } ] }, "rail_name": "Visa Authorization Declines", "governing_authority": "Visa (Visa Core Rules and Visa Product and Service Rules)", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "visa-decline:5C", "id": "5C", "rail": "visa-decline", "kind": "reason-code", "name": "Transaction not supported/blocked by issuer", "group": "administrative", "summary": "The issuer does not support the transaction or has blocked it. Visa directs issuers in its Visa Payment Controls service for commercial cards to use this code when a control stops a transaction. Visa places it in category 2, the codes for an issuer that cannot approve at present, so the merchant may reattempt within the cap.", "triggers": [ "A control set on a commercial card through Visa Payment Controls blocked the transaction (VR 8.6.2.1, ID# 0027238)", "The issuer does not support this transaction type on the card [Inference from the label]" ], "actions": [ "Merchant: ask for another card", "Commercial cardholder: ask the card program administrator to adjust the control [Inference]" ], "retry": { "allowed": true, "rule": "Yes, within a cap: after a category 2 decline the merchant may reattempt, up to 20 attempts in 30 days (VR 7.3.6.3, Table 7-2, ID# 0030640). A reattempt must not deliberately change data from the original request, for example the MCC, the POS entry mode, the e-commerce indicator or the merchant or acquirer country (VR 1.7.2.1, ID# 0008752). Urban mobility merchants follow their own resubmission rule instead (VR 7.3.6.2, ID# 0030046)." }, "facts": { "return_windows": [ { "action": "send this decline response to the authorization or account verification request", "by": "Issuer; if it misses the time limit, Visa answers instead through Stand-In Processing (VR 7.3.4.1)", "deadline": "Within the authorization response time limit: outside Europe 10 seconds for POS and Visa Direct and 25 seconds for ATM cash (MCC 6011); in Europe 5 seconds (VR 7.3.4.1, Table 7-1, ID# 0004385)" }, { "action": "reattempt the authorization request or account verification", "by": "Merchant, through its acquirer", "deadline": "At most 20 attempts within 30 days (VR 7.3.6.3, Table 7-2); the rules read do not say whether the count runs per credential, per merchant or per purchase" } ], "applies_to": "All Visa Regions: an issuer decline of an authorization request or account verification request, under VR 7.3.6.3 and Table 7-2" }, "caveat": "Visa Payment Controls is offered for Visa Commercial Cards only, and its code rule does not apply in the LAC Region (Chile) (VR 8.6.2.1 note 1). Blocks a consumer sets on its own card use 9G instead. A decline moves no money and is not a return.", "related": [ "visa-decline:9G", "visa-decline:03", "visa-decline:57" ], "basis": { "sources": "Visa Core Rules and Visa Product and Service Rules, edition 18 April 2026 (marked Visa Public), fetched 2026-09-19 with a plain GET from https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf and read with python3. Table 7-2 in VR 7.3.6.3 (ID# 0030640, last updated April 2026) gives the code, Visa's short label (used here as the name), its category and the merchant reattempt limit; VR 1.7.2.1 (ID# 0008752) bars manipulating data on a reattempt; VR 7.3.4.1 (ID# 0004385) sets the issuer response time limits. Also read: VR 8.6.2.1 (ID# 0027238). Visa gives each code a label and a category only; triggers and actions marked [Inference] are Orca's reading. Nothing is quoted apart from the label, which is Visa's defined name for the code.", "confidence": "high" }, "currency": { "effective_since": "Not dated in the edition read", "effective_note": "Listed in Table 7-2 of the 18 April 2026 edition; the table rule was last updated in April 2026 and gives no start date for this code. Visa publishes a new edition each April and October; the next is expected in October 2026 [Inference].", "source_edition": "Visa Core Rules and Visa Product and Service Rules, edition 18 April 2026 (Table 7-2, ID# 0030640)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf", "source_class": "authoritative_primary", "source_title": "Visa Core Rules and Visa Product and Service Rules, 18 April 2026", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Table 7-2 (VR 7.3.6.3) confirms the label Transaction not supported/blocked by issuer, places it in category 2, and confirms the merchant reattempt limit of up to 20 attempts in 30 days subject to the data-manipulation bar in VR 1.7.2.1. VR 8.6.2.1 confirms Visa Payment Controls is offered for Visa Commercial Cards only, that a control decline must use this code, and that the rule does not apply in the LAC Region (Chile)." } ] }, "rail_name": "Visa Authorization Declines", "governing_authority": "Visa (Visa Core Rules and Visa Product and Service Rules)", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "visa-decline:61", "id": "61", "rail": "visa-decline", "kind": "reason-code", "name": "Exceeds approval amount limit", "group": "funds", "summary": "The amount is above an approval limit the issuer applies to this card. Visa places it in category 2, the codes for an issuer that cannot approve at present, so the merchant may reattempt within the cap.", "triggers": [ "The amount exceeds a per-transaction or daily spending limit the issuer sets [Inference]", "A cash withdrawal exceeds the amount the issuer allows [Inference]" ], "actions": [ "Merchant: offer a smaller amount or another card [Inference]", "Cardholder: ask the issuer to raise the limit [Inference]" ], "retry": { "allowed": true, "rule": "Yes, within a cap: after a category 2 decline the merchant may reattempt, up to 20 attempts in 30 days (VR 7.3.6.3, Table 7-2, ID# 0030640). A reattempt must not deliberately change data from the original request, for example the MCC, the POS entry mode, the e-commerce indicator or the merchant or acquirer country (VR 1.7.2.1, ID# 0008752). Urban mobility merchants follow their own resubmission rule instead (VR 7.3.6.2, ID# 0030046)." }, "facts": { "return_windows": [ { "action": "send this decline response to the authorization or account verification request", "by": "Issuer; if it misses the time limit, Visa answers instead through Stand-In Processing (VR 7.3.4.1)", "deadline": "Within the authorization response time limit: outside Europe 10 seconds for POS and Visa Direct and 25 seconds for ATM cash (MCC 6011); in Europe 5 seconds (VR 7.3.4.1, Table 7-1, ID# 0004385)" }, { "action": "reattempt the authorization request or account verification", "by": "Merchant, through its acquirer", "deadline": "At most 20 attempts within 30 days (VR 7.3.6.3, Table 7-2); the rules read do not say whether the count runs per credential, per merchant or per purchase" } ], "applies_to": "All Visa Regions: an issuer decline of an authorization request or account verification request, under VR 7.3.6.3 and Table 7-2" }, "caveat": "The limit is the issuer's, not a Visa network maximum; the rules read set no network-wide amount limit (see visa:limits). A decline moves no money and is not a return.", "related": [ "visa-decline:51", "visa-decline:65", "visa-decline:N4", "visa:limits" ], "basis": { "sources": "Visa Core Rules and Visa Product and Service Rules, edition 18 April 2026 (marked Visa Public), fetched 2026-09-19 with a plain GET from https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf and read with python3. Table 7-2 in VR 7.3.6.3 (ID# 0030640, last updated April 2026) gives the code, Visa's short label (used here as the name), its category and the merchant reattempt limit; VR 1.7.2.1 (ID# 0008752) bars manipulating data on a reattempt; VR 7.3.4.1 (ID# 0004385) sets the issuer response time limits. Visa gives each code a label and a category only; triggers and actions marked [Inference] are Orca's reading. Nothing is quoted apart from the label, which is Visa's defined name for the code.", "confidence": "medium" }, "currency": { "effective_since": "Not dated in the edition read", "effective_note": "Listed in Table 7-2 of the 18 April 2026 edition; the table rule was last updated in April 2026 and gives no start date for this code. Visa publishes a new edition each April and October; the next is expected in October 2026 [Inference].", "source_edition": "Visa Core Rules and Visa Product and Service Rules, edition 18 April 2026 (Table 7-2, ID# 0030640)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf", "source_class": "authoritative_primary", "source_title": "Visa Core Rules and Visa Product and Service Rules, 18 April 2026", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Table 7-2 (VR 7.3.6.3) confirms the label Exceeds approval amount limit, places it in category 2, and confirms the merchant reattempt limit of up to 20 attempts in 30 days subject to the data-manipulation bar in VR 1.7.2.1." } ] }, "rail_name": "Visa Authorization Declines", "governing_authority": "Visa (Visa Core Rules and Visa Product and Service Rules)", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "visa-decline:62", "id": "62", "rail": "visa-decline", "kind": "reason-code", "name": "Restricted card (card invalid in region or country)", "group": "account", "summary": "The card is restricted and not valid for use in this region or country. Visa places it in category 2, the codes for an issuer that cannot approve at present, so the merchant may reattempt within the cap.", "triggers": [ "The card is issued for domestic use only and is used abroad [Inference]", "The issuer has blocked a geography as part of an approved program [Inference]" ], "actions": [ "Merchant: ask for another card", "Cardholder: ask the issuer whether the card can be used in this country [Inference]" ], "retry": { "allowed": true, "rule": "Yes, within a cap: after a category 2 decline the merchant may reattempt, up to 20 attempts in 30 days (VR 7.3.6.3, Table 7-2, ID# 0030640). A reattempt must not deliberately change data from the original request, for example the MCC, the POS entry mode, the e-commerce indicator or the merchant or acquirer country (VR 1.7.2.1, ID# 0008752). Urban mobility merchants follow their own resubmission rule instead (VR 7.3.6.2, ID# 0030046)." }, "facts": { "return_windows": [ { "action": "send this decline response to the authorization or account verification request", "by": "Issuer; if it misses the time limit, Visa answers instead through Stand-In Processing (VR 7.3.4.1)", "deadline": "Within the authorization response time limit: outside Europe 10 seconds for POS and Visa Direct and 25 seconds for ATM cash (MCC 6011); in Europe 5 seconds (VR 7.3.4.1, Table 7-1, ID# 0004385)" }, { "action": "reattempt the authorization request or account verification", "by": "Merchant, through its acquirer", "deadline": "At most 20 attempts within 30 days (VR 7.3.6.3, Table 7-2); the rules read do not say whether the count runs per credential, per merchant or per purchase" } ], "applies_to": "All Visa Regions: an issuer decline of an authorization request or account verification request, under VR 7.3.6.3 and Table 7-2" }, "caveat": "Issuers may not decline systematically by geography except in approved programs or other allowed cases (VR 1.7.4.1, ID# 0029326), and an issuer must still pay for a geographically restricted card used abroad if the transaction went through (VR 1.7.6.1, ID# 0006558). A decline moves no money and is not a return.", "related": [ "visa-decline:03", "visa-decline:57", "visa:decision-points" ], "basis": { "sources": "Visa Core Rules and Visa Product and Service Rules, edition 18 April 2026 (marked Visa Public), fetched 2026-09-19 with a plain GET from https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf and read with python3. Table 7-2 in VR 7.3.6.3 (ID# 0030640, last updated April 2026) gives the code, Visa's short label (used here as the name), its category and the merchant reattempt limit; VR 1.7.2.1 (ID# 0008752) bars manipulating data on a reattempt; VR 7.3.4.1 (ID# 0004385) sets the issuer response time limits. Also read: VR 1.7.4.1 (ID# 0029326); 1.7.6.1 (ID# 0006558). Visa gives each code a label and a category only; triggers and actions marked [Inference] are Orca's reading. Nothing is quoted apart from the label, which is Visa's defined name for the code.", "confidence": "medium" }, "currency": { "effective_since": "Not dated in the edition read", "effective_note": "Listed in Table 7-2 of the 18 April 2026 edition; the table rule was last updated in April 2026 and gives no start date for this code. Visa publishes a new edition each April and October; the next is expected in October 2026 [Inference].", "source_edition": "Visa Core Rules and Visa Product and Service Rules, edition 18 April 2026 (Table 7-2, ID# 0030640)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf", "source_class": "authoritative_primary", "source_title": "Visa Core Rules and Visa Product and Service Rules, 18 April 2026", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Table 7-2 (VR 7.3.6.3) confirms the label Restricted card (card invalid in region or country), places it in category 2, and confirms the merchant reattempt limit of up to 20 attempts in 30 days subject to the data-manipulation bar in VR 1.7.2.1. VR 1.7.4.1 confirms the bar on systematic or wholesale geographic declines, and VR 1.7.6.1 confirms the issuer must still pay the acquirer for a transaction from geographically restricted card use outside the country of issuance." } ] }, "rail_name": "Visa Authorization Declines", "governing_authority": "Visa (Visa Core Rules and Visa Product and Service Rules)", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "visa-decline:65", "id": "65", "rail": "visa-decline", "kind": "reason-code", "name": "Exceeds withdrawal frequency limit", "group": "funds", "summary": "The card has been used, or cash withdrawn, more often than the issuer allows in a period. Visa places it in category 2, the codes for an issuer that cannot approve at present, so the merchant may reattempt within the cap.", "triggers": [ "The number of withdrawals or uses in a day or other period is over an issuer limit [Inference]" ], "actions": [ "Merchant or ATM: suggest the cardholder try later or use another card [Inference]" ], "retry": { "allowed": true, "rule": "Yes, within a cap: after a category 2 decline the merchant may reattempt, up to 20 attempts in 30 days (VR 7.3.6.3, Table 7-2, ID# 0030640). A reattempt must not deliberately change data from the original request, for example the MCC, the POS entry mode, the e-commerce indicator or the merchant or acquirer country (VR 1.7.2.1, ID# 0008752). Urban mobility merchants follow their own resubmission rule instead (VR 7.3.6.2, ID# 0030046)." }, "facts": { "return_windows": [ { "action": "send this decline response to the authorization or account verification request", "by": "Issuer; if it misses the time limit, Visa answers instead through Stand-In Processing (VR 7.3.4.1)", "deadline": "Within the authorization response time limit: outside Europe 10 seconds for POS and Visa Direct and 25 seconds for ATM cash (MCC 6011); in Europe 5 seconds (VR 7.3.4.1, Table 7-1, ID# 0004385)" }, { "action": "reattempt the authorization request or account verification", "by": "Merchant, through its acquirer", "deadline": "At most 20 attempts within 30 days (VR 7.3.6.3, Table 7-2); the rules read do not say whether the count runs per credential, per merchant or per purchase" } ], "applies_to": "All Visa Regions: an issuer decline of an authorization request or account verification request, under VR 7.3.6.3 and Table 7-2" }, "caveat": "The frequency limit is the issuer's and is not published by Visa. A decline moves no money and is not a return.", "related": [ "visa-decline:61", "visa-decline:N4" ], "basis": { "sources": "Visa Core Rules and Visa Product and Service Rules, edition 18 April 2026 (marked Visa Public), fetched 2026-09-19 with a plain GET from https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf and read with python3. Table 7-2 in VR 7.3.6.3 (ID# 0030640, last updated April 2026) gives the code, Visa's short label (used here as the name), its category and the merchant reattempt limit; VR 1.7.2.1 (ID# 0008752) bars manipulating data on a reattempt; VR 7.3.4.1 (ID# 0004385) sets the issuer response time limits. Visa gives each code a label and a category only; triggers and actions marked [Inference] are Orca's reading. Nothing is quoted apart from the label, which is Visa's defined name for the code.", "confidence": "medium" }, "currency": { "effective_since": "Not dated in the edition read", "effective_note": "Listed in Table 7-2 of the 18 April 2026 edition; the table rule was last updated in April 2026 and gives no start date for this code. Visa publishes a new edition each April and October; the next is expected in October 2026 [Inference].", "source_edition": "Visa Core Rules and Visa Product and Service Rules, edition 18 April 2026 (Table 7-2, ID# 0030640)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf", "source_class": "authoritative_primary", "source_title": "Visa Core Rules and Visa Product and Service Rules, 18 April 2026", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Table 7-2 (VR 7.3.6.3) confirms the label Exceeds withdrawal frequency limit, places it in category 2, and confirms the merchant reattempt limit of up to 20 attempts in 30 days subject to the data-manipulation bar in VR 1.7.2.1." } ] }, "rail_name": "Visa Authorization Declines", "governing_authority": "Visa (Visa Core Rules and Visa Product and Service Rules)", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "visa-decline:6P", "id": "6P", "rail": "visa-decline", "kind": "reason-code", "name": "Verification failed (cardholder identification does not match issuer records)", "group": "authorization", "summary": "The cardholder identification in the request does not match the issuer's records. Visa places it in category 3, the data-quality codes that tell the merchant to check the payment details again, so the merchant may correct and reattempt within the cap.", "triggers": [ "A name or other identity data sent for verification did not match the issuer's records [Inference from the label]" ], "actions": [ "Merchant: ask the cardholder to confirm the details exactly as the issuer holds them [Inference]", "Merchant: send only data obtained from the cardholder; from 2026-07-25 acquirers must send genuine cardholder name and address data in verification checks (VR 7.3.10.2, ID# 0031048)" ], "retry": { "allowed": true, "rule": "Yes, within a cap: after a category 3 decline the merchant may reattempt, up to 20 attempts in 30 days (VR 7.3.6.3, Table 7-2, ID# 0030640). A reattempt must not deliberately change data from the original request, for example the MCC, the POS entry mode, the e-commerce indicator or the merchant or acquirer country (VR 1.7.2.1, ID# 0008752). Correcting card data the cardholder gave (an expiry date, a PIN, a security code) is what a data-quality decline invites, and does not count as the manipulation VR 1.7.2.1 forbids, which concerns merchant and acquirer data [Inference]. Urban mobility merchants follow their own resubmission rule instead (VR 7.3.6.2, ID# 0030046)." }, "facts": { "return_windows": [ { "action": "send this decline response to the authorization or account verification request", "by": "Issuer; if it misses the time limit, Visa answers instead through Stand-In Processing (VR 7.3.4.1)", "deadline": "Within the authorization response time limit: outside Europe 10 seconds for POS and Visa Direct and 25 seconds for ATM cash (MCC 6011); in Europe 5 seconds (VR 7.3.4.1, Table 7-1, ID# 0004385)" }, { "action": "reattempt the authorization request or account verification", "by": "Merchant, through its acquirer", "deadline": "At most 20 attempts within 30 days (VR 7.3.6.3, Table 7-2); the rules read do not say whether the count runs per credential, per merchant or per purchase" } ], "applies_to": "All Visa Regions: an issuer decline of an authorization request or account verification request, under VR 7.3.6.3 and Table 7-2" }, "caveat": "The verification services behind this code, such as Account Name Inquiry, are set out in sections not read [Unverified]. A decline moves no money and is not a return.", "related": [ "visa-decline:N7", "visa-decline:1A" ], "basis": { "sources": "Visa Core Rules and Visa Product and Service Rules, edition 18 April 2026 (marked Visa Public), fetched 2026-09-19 with a plain GET from https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf and read with python3. Table 7-2 in VR 7.3.6.3 (ID# 0030640, last updated April 2026) gives the code, Visa's short label (used here as the name), its category and the merchant reattempt limit; VR 1.7.2.1 (ID# 0008752) bars manipulating data on a reattempt; VR 7.3.4.1 (ID# 0004385) sets the issuer response time limits. Also read: VR 7.3.10.2 (ID# 0031048). Visa gives each code a label and a category only; triggers and actions marked [Inference] are Orca's reading. Nothing is quoted apart from the label, which is Visa's defined name for the code.", "confidence": "medium" }, "currency": { "effective_since": "Not dated in the edition read", "effective_note": "Listed in Table 7-2 of the 18 April 2026 edition; the table rule was last updated in April 2026 and gives no start date for this code. Visa publishes a new edition each April and October; the next is expected in October 2026 [Inference].", "source_edition": "Visa Core Rules and Visa Product and Service Rules, edition 18 April 2026 (Table 7-2, ID# 0030640)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf", "source_class": "authoritative_primary", "source_title": "Visa Core Rules and Visa Product and Service Rules, 18 April 2026", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Table 7-2 (VR 7.3.6.3) confirms the label Verification Failed (Cardholder Identification does not match Issuer records), places it in category 3, and confirms the merchant reattempt limit of up to 20 attempts in 30 days subject to the data-manipulation bar in VR 1.7.2.1." } ] }, "rail_name": "Visa Authorization Declines", "governing_authority": "Visa (Visa Core Rules and Visa Product and Service Rules)", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "visa-decline:70", "id": "70", "rail": "visa-decline", "kind": "reason-code", "name": "PIN data required", "group": "authorization", "summary": "The issuer wants a PIN for this transaction and none was provided. Only issuers in the CEMEA and Europe Regions use this code. Visa places it in category 3, the data-quality codes that tell the merchant to check the payment details again, so the merchant may reattempt with a PIN within the cap.", "triggers": [ "A contactless or other no-PIN transaction triggered the issuer's need for cardholder verification by PIN [Inference]" ], "actions": [ "Merchant: ask the cardholder to insert the card and enter the PIN, then send the request again [Inference]" ], "retry": { "allowed": true, "rule": "Yes, within a cap: after a category 3 decline the merchant may reattempt, up to 20 attempts in 30 days (VR 7.3.6.3, Table 7-2, ID# 0030640). A reattempt must not deliberately change data from the original request, for example the MCC, the POS entry mode, the e-commerce indicator or the merchant or acquirer country (VR 1.7.2.1, ID# 0008752). Correcting card data the cardholder gave (an expiry date, a PIN, a security code) is what a data-quality decline invites, and does not count as the manipulation VR 1.7.2.1 forbids, which concerns merchant and acquirer data [Inference]. Urban mobility merchants follow their own resubmission rule instead (VR 7.3.6.2, ID# 0030046)." }, "facts": { "return_windows": [ { "action": "send this decline response to the authorization or account verification request", "by": "Issuer; if it misses the time limit, Visa answers instead through Stand-In Processing (VR 7.3.4.1)", "deadline": "Within the authorization response time limit: outside Europe 10 seconds for POS and Visa Direct and 25 seconds for ATM cash (MCC 6011); in Europe 5 seconds (VR 7.3.4.1, Table 7-1, ID# 0004385)" }, { "action": "reattempt the authorization request or account verification", "by": "Merchant, through its acquirer", "deadline": "At most 20 attempts within 30 days (VR 7.3.6.3, Table 7-2); the rules read do not say whether the count runs per credential, per merchant or per purchase" } ], "applies_to": "CEMEA and Europe Regions only: Table 7-2 lists this code for issuers in those two regions; under VR 1.1.1.5 a region-labelled rule applies only there" }, "caveat": "Table 7-2 lists 70 only for the CEMEA and Europe Regions. Outside them it is not a named code and would fall in the generic category 4 [Inference]. A decline moves no money and is not a return.", "related": [ "visa-decline:1A", "visa-decline:55", "visa-decline:CATEGORY_4" ], "basis": { "sources": "Visa Core Rules and Visa Product and Service Rules, edition 18 April 2026 (marked Visa Public), fetched 2026-09-19 with a plain GET from https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf and read with python3. Table 7-2 in VR 7.3.6.3 (ID# 0030640, last updated April 2026) gives the code, Visa's short label (used here as the name), its category and the merchant reattempt limit; VR 1.7.2.1 (ID# 0008752) bars manipulating data on a reattempt; VR 7.3.4.1 (ID# 0004385) sets the issuer response time limits. Visa gives each code a label and a category only; triggers and actions marked [Inference] are Orca's reading. Nothing is quoted apart from the label, which is Visa's defined name for the code.", "confidence": "medium" }, "currency": { "effective_since": "Not dated in the edition read", "effective_note": "Listed in Table 7-2 of the 18 April 2026 edition; the table rule was last updated in April 2026 and gives no start date for this code. Visa publishes a new edition each April and October; the next is expected in October 2026 [Inference].", "source_edition": "Visa Core Rules and Visa Product and Service Rules, edition 18 April 2026 (Table 7-2, ID# 0030640)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf", "source_class": "authoritative_primary", "source_title": "Visa Core Rules and Visa Product and Service Rules, 18 April 2026", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Table 7-2 (VR 7.3.6.3) confirms the label PIN data required, confirms it is listed only for issuers in the CEMEA and Europe Regions, places it in category 3, and confirms the merchant reattempt limit of up to 20 attempts in 30 days subject to the data-manipulation bar in VR 1.7.2.1." } ] }, "rail_name": "Visa Authorization Declines", "governing_authority": "Visa (Visa Core Rules and Visa Product and Service Rules)", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "visa-decline:75", "id": "75", "rail": "visa-decline", "kind": "reason-code", "name": "Allowable number of PIN-entry tries exceeded", "group": "authorization", "summary": "The cardholder has entered a wrong PIN too many times and the issuer will not accept more attempts for now. Visa places it in category 2, the codes for an issuer that cannot approve at present, so the merchant may reattempt within the cap.", "triggers": [ "Repeated wrong PIN entries have locked PIN use on the card [Inference]" ], "actions": [ "Merchant: ask for another payment method; further tries will fail until the issuer resets the PIN count [Inference]", "Cardholder: contact the issuer to unlock or reset the PIN [Inference]" ], "retry": { "allowed": true, "rule": "Yes, within a cap: after a category 2 decline the merchant may reattempt, up to 20 attempts in 30 days (VR 7.3.6.3, Table 7-2, ID# 0030640). A reattempt must not deliberately change data from the original request, for example the MCC, the POS entry mode, the e-commerce indicator or the merchant or acquirer country (VR 1.7.2.1, ID# 0008752). Urban mobility merchants follow their own resubmission rule instead (VR 7.3.6.2, ID# 0030046)." }, "facts": { "return_windows": [ { "action": "send this decline response to the authorization or account verification request", "by": "Issuer; if it misses the time limit, Visa answers instead through Stand-In Processing (VR 7.3.4.1)", "deadline": "Within the authorization response time limit: outside Europe 10 seconds for POS and Visa Direct and 25 seconds for ATM cash (MCC 6011); in Europe 5 seconds (VR 7.3.4.1, Table 7-1, ID# 0004385)" }, { "action": "reattempt the authorization request or account verification", "by": "Merchant, through its acquirer", "deadline": "At most 20 attempts within 30 days (VR 7.3.6.3, Table 7-2); the rules read do not say whether the count runs per credential, per merchant or per purchase" } ], "applies_to": "All Visa Regions: an issuer decline of an authorization request or account verification request, under VR 7.3.6.3 and Table 7-2" }, "caveat": "Being category 2, a reattempt is allowed, but it serves only after the issuer has reset the PIN count [Inference]. A decline moves no money and is not a return.", "related": [ "visa-decline:55", "visa-decline:86", "visa-decline:70" ], "basis": { "sources": "Visa Core Rules and Visa Product and Service Rules, edition 18 April 2026 (marked Visa Public), fetched 2026-09-19 with a plain GET from https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf and read with python3. Table 7-2 in VR 7.3.6.3 (ID# 0030640, last updated April 2026) gives the code, Visa's short label (used here as the name), its category and the merchant reattempt limit; VR 1.7.2.1 (ID# 0008752) bars manipulating data on a reattempt; VR 7.3.4.1 (ID# 0004385) sets the issuer response time limits. Visa gives each code a label and a category only; triggers and actions marked [Inference] are Orca's reading. Nothing is quoted apart from the label, which is Visa's defined name for the code.", "confidence": "medium" }, "currency": { "effective_since": "Not dated in the edition read", "effective_note": "Listed in Table 7-2 of the 18 April 2026 edition; the table rule was last updated in April 2026 and gives no start date for this code. Visa publishes a new edition each April and October; the next is expected in October 2026 [Inference].", "source_edition": "Visa Core Rules and Visa Product and Service Rules, edition 18 April 2026 (Table 7-2, ID# 0030640)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf", "source_class": "authoritative_primary", "source_title": "Visa Core Rules and Visa Product and Service Rules, 18 April 2026", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Table 7-2 (VR 7.3.6.3) confirms the label Allowable number of PIN-entry tries exceeded, places it in category 2, and confirms the merchant reattempt limit of up to 20 attempts in 30 days subject to the data-manipulation bar in VR 1.7.2.1." } ] }, "rail_name": "Visa Authorization Declines", "governing_authority": "Visa (Visa Core Rules and Visa Product and Service Rules)", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "visa-decline:78", "id": "78", "rail": "visa-decline", "kind": "reason-code", "name": "Blocked, first used or special condition (account is temporarily blocked)", "group": "account", "summary": "The account is blocked for now, for example because a new card has not been activated or a special condition applies. Visa places it in category 2, the codes for an issuer that cannot approve at present, so the merchant may reattempt within the cap.", "triggers": [ "A new or replacement card is used before activation [Inference from the label]", "The issuer has placed a temporary block on the account [Inference]" ], "actions": [ "Cardholder: activate the card or contact the issuer [Inference]", "Merchant: retry after the cardholder confirms the block is lifted, within the cap" ], "retry": { "allowed": true, "rule": "Yes, within a cap: after a category 2 decline the merchant may reattempt, up to 20 attempts in 30 days (VR 7.3.6.3, Table 7-2, ID# 0030640). A reattempt must not deliberately change data from the original request, for example the MCC, the POS entry mode, the e-commerce indicator or the merchant or acquirer country (VR 1.7.2.1, ID# 0008752). Urban mobility merchants follow their own resubmission rule instead (VR 7.3.6.2, ID# 0030046)." }, "facts": { "return_windows": [ { "action": "send this decline response to the authorization or account verification request", "by": "Issuer; if it misses the time limit, Visa answers instead through Stand-In Processing (VR 7.3.4.1)", "deadline": "Within the authorization response time limit: outside Europe 10 seconds for POS and Visa Direct and 25 seconds for ATM cash (MCC 6011); in Europe 5 seconds (VR 7.3.4.1, Table 7-1, ID# 0004385)" }, { "action": "reattempt the authorization request or account verification", "by": "Merchant, through its acquirer", "deadline": "At most 20 attempts within 30 days (VR 7.3.6.3, Table 7-2); the rules read do not say whether the count runs per credential, per merchant or per purchase" } ], "applies_to": "All Visa Regions: an issuer decline of an authorization request or account verification request, under VR 7.3.6.3 and Table 7-2" }, "caveat": "This is a temporary block set by the issuer; a block the cardholder sets with a card control is signalled with 9G instead (VR 4.1.19.1, ID# 0031150). A decline moves no money and is not a return.", "related": [ "visa-decline:9G", "visa-decline:62" ], "basis": { "sources": "Visa Core Rules and Visa Product and Service Rules, edition 18 April 2026 (marked Visa Public), fetched 2026-09-19 with a plain GET from https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf and read with python3. Table 7-2 in VR 7.3.6.3 (ID# 0030640, last updated April 2026) gives the code, Visa's short label (used here as the name), its category and the merchant reattempt limit; VR 1.7.2.1 (ID# 0008752) bars manipulating data on a reattempt; VR 7.3.4.1 (ID# 0004385) sets the issuer response time limits. Also read: VR 4.1.19.1 (ID# 0031150). Visa gives each code a label and a category only; triggers and actions marked [Inference] are Orca's reading. Nothing is quoted apart from the label, which is Visa's defined name for the code.", "confidence": "medium" }, "currency": { "effective_since": "Not dated in the edition read", "effective_note": "Listed in Table 7-2 of the 18 April 2026 edition; the table rule was last updated in April 2026 and gives no start date for this code. Visa publishes a new edition each April and October; the next is expected in October 2026 [Inference].", "source_edition": "Visa Core Rules and Visa Product and Service Rules, edition 18 April 2026 (Table 7-2, ID# 0030640)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf", "source_class": "authoritative_primary", "source_title": "Visa Core Rules and Visa Product and Service Rules, 18 April 2026", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Table 7-2 (VR 7.3.6.3) confirms the label Blocked, first used or special condition (account is temporarily blocked), places it in category 2, and confirms the merchant reattempt limit of up to 20 attempts in 30 days subject to the data-manipulation bar in VR 1.7.2.1. VR 4.1.19.1 confirms that a cardholder-set block or limit is instead signalled with code 9G." } ] }, "rail_name": "Visa Authorization Declines", "governing_authority": "Visa (Visa Core Rules and Visa Product and Service Rules)", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "visa-decline:82", "id": "82", "rail": "visa-decline", "kind": "reason-code", "name": "Negative online CAM, dCVV, iCVV, or CVV results", "group": "authorization", "summary": "A card authentication check failed: the chip cryptogram, a dynamic card verification value or the magnetic stripe CVV did not validate. Visa places it in category 3, the data-quality codes that tell the merchant to check the payment details again, so the merchant may correct and reattempt within the cap.", "triggers": [ "The card data read from the chip or stripe did not match what the issuer expected [Inference]", "The card may be counterfeit or damaged [Inference]" ], "actions": [ "Merchant: read the card again, by chip where possible [Inference]", "Merchant: if the check keeps failing, ask for another card and do not key the number in to get around it [Inference]" ], "retry": { "allowed": true, "rule": "Yes, within a cap: after a category 3 decline the merchant may reattempt, up to 20 attempts in 30 days (VR 7.3.6.3, Table 7-2, ID# 0030640). A reattempt must not deliberately change data from the original request, for example the MCC, the POS entry mode, the e-commerce indicator or the merchant or acquirer country (VR 1.7.2.1, ID# 0008752). Correcting card data the cardholder gave (an expiry date, a PIN, a security code) is what a data-quality decline invites, and does not count as the manipulation VR 1.7.2.1 forbids, which concerns merchant and acquirer data [Inference]. Urban mobility merchants follow their own resubmission rule instead (VR 7.3.6.2, ID# 0030046)." }, "facts": { "return_windows": [ { "action": "send this decline response to the authorization or account verification request", "by": "Issuer; if it misses the time limit, Visa answers instead through Stand-In Processing (VR 7.3.4.1)", "deadline": "Within the authorization response time limit: outside Europe 10 seconds for POS and Visa Direct and 25 seconds for ATM cash (MCC 6011); in Europe 5 seconds (VR 7.3.4.1, Table 7-1, ID# 0004385)" }, { "action": "reattempt the authorization request or account verification", "by": "Merchant, through its acquirer", "deadline": "At most 20 attempts within 30 days (VR 7.3.6.3, Table 7-2); the rules read do not say whether the count runs per credential, per merchant or per purchase" } ], "applies_to": "All Visa Regions: an issuer decline of an authorization request or account verification request, under VR 7.3.6.3 and Table 7-2" }, "caveat": "A repeat failure on a card read may point to counterfeit, and counterfeit fraud losses follow the chip liability shift (see visa:liability) [Inference]. A decline moves no money and is not a return.", "related": [ "visa-decline:N7", "visa-decline:07", "visa:liability" ], "basis": { "sources": "Visa Core Rules and Visa Product and Service Rules, edition 18 April 2026 (marked Visa Public), fetched 2026-09-19 with a plain GET from https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf and read with python3. Table 7-2 in VR 7.3.6.3 (ID# 0030640, last updated April 2026) gives the code, Visa's short label (used here as the name), its category and the merchant reattempt limit; VR 1.7.2.1 (ID# 0008752) bars manipulating data on a reattempt; VR 7.3.4.1 (ID# 0004385) sets the issuer response time limits. Visa gives each code a label and a category only; triggers and actions marked [Inference] are Orca's reading. Nothing is quoted apart from the label, which is Visa's defined name for the code.", "confidence": "medium" }, "currency": { "effective_since": "Not dated in the edition read", "effective_note": "Listed in Table 7-2 of the 18 April 2026 edition; the table rule was last updated in April 2026 and gives no start date for this code. Visa publishes a new edition each April and October; the next is expected in October 2026 [Inference].", "source_edition": "Visa Core Rules and Visa Product and Service Rules, edition 18 April 2026 (Table 7-2, ID# 0030640)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf", "source_class": "authoritative_primary", "source_title": "Visa Core Rules and Visa Product and Service Rules, 18 April 2026", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Table 7-2 (VR 7.3.6.3) confirms the label Negative online CAM, dCVV, iCVV, or CVV results, places it in category 3, and confirms the merchant reattempt limit of up to 20 attempts in 30 days subject to the data-manipulation bar in VR 1.7.2.1." } ] }, "rail_name": "Visa Authorization Declines", "governing_authority": "Visa (Visa Core Rules and Visa Product and Service Rules)", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "visa-decline:83", "id": "83", "rail": "visa-decline", "kind": "reason-code", "name": "Fraud/Security (Visa use only)", "group": "authorization", "summary": "A decline that only Visa sends, signalling that Visa's Stand-In Processing turned the transaction down because of high-risk or fraudulent conditions. Visa places it in category 2, the codes for an issuer that cannot approve at present, so the merchant may reattempt within the cap.", "triggers": [ "Visa declined in stand-in, on the issuer's behalf, because it judged the transaction high-risk or fraudulent (Summary of Changes p. 47)" ], "actions": [ "Merchant: treat it like a fraud decline; ask the cardholder to contact the issuer or to use another payment method [Inference]", "Merchant: do not change request data to get past the decline (VR 1.7.2.1)" ], "retry": { "allowed": true, "rule": "Yes, within a cap: after a category 2 decline the merchant may reattempt, up to 20 attempts in 30 days (VR 7.3.6.3, Table 7-2, ID# 0030640). A reattempt must not deliberately change data from the original request, for example the MCC, the POS entry mode, the e-commerce indicator or the merchant or acquirer country (VR 1.7.2.1, ID# 0008752). Urban mobility merchants follow their own resubmission rule instead (VR 7.3.6.2, ID# 0030046)." }, "facts": { "return_windows": [ { "action": "send this decline response to the authorization or account verification request", "by": "Visa, through Stand-In Processing (Visa use only)", "deadline": "Within the authorization response time limit: outside Europe 10 seconds for POS and Visa Direct and 25 seconds for ATM cash (MCC 6011); in Europe 5 seconds (VR 7.3.4.1, Table 7-1, ID# 0004385)" }, { "action": "reattempt the authorization request or account verification", "by": "Merchant, through its acquirer", "deadline": "At most 20 attempts within 30 days (VR 7.3.6.3, Table 7-2); the rules read do not say whether the count runs per credential, per merchant or per purchase" } ], "applies_to": "All Visa Regions: an issuer decline of an authorization request or account verification request, under VR 7.3.6.3 and Table 7-2" }, "caveat": "The code is new: Visa added it with effect from 2026-07-25. It is reserved for Visa, so issuers do not send it [Inference from the label]. It is unrelated to the old Visa chargeback reason code 83, which predates the current dispute conditions [Unverified: general knowledge]. A decline moves no money and is not a return.", "related": [ "visa-decline:59", "visa-decline:07", "visa:hours" ], "basis": { "sources": "Visa Core Rules and Visa Product and Service Rules, edition 18 April 2026 (marked Visa Public), fetched 2026-09-19 with a plain GET from https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf and read with python3. Table 7-2 in VR 7.3.6.3 (ID# 0030640, last updated April 2026) gives the code, Visa's short label (used here as the name), its category and the merchant reattempt limit; VR 1.7.2.1 (ID# 0008752) bars manipulating data on a reattempt; VR 7.3.4.1 (ID# 0004385) sets the issuer response time limits. Also read: Summary of Changes, Global New Visa-Only Authorization Response Code for Ecosystem Fraud (p. 47); Glossary, Stand-In Processing (ID# 0025121). Visa gives each code a label and a category only; triggers and actions marked [Inference] are Orca's reading. Nothing is quoted apart from the label, which is Visa's defined name for the code.", "confidence": "medium" }, "currency": { "effective_since": "2026-07-25", "effective_note": "Added to Table 7-2 with effect from 2026-07-25 (18 April 2026 edition, Summary of Changes p. 47). The next edition is expected in October 2026 [Inference].", "source_edition": "Visa Core Rules and Visa Product and Service Rules, edition 18 April 2026 (Table 7-2, ID# 0030640)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf", "source_class": "authoritative_primary", "source_title": "Visa Core Rules and Visa Product and Service Rules, 18 April 2026", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Table 7-2 (VR 7.3.6.3) confirms the label Fraud/Security (Visa use only), confirms it takes effect 25 July 2026, places it in category 2, and confirms the merchant reattempt limit of up to 20 attempts in 30 days subject to the data-manipulation bar in VR 1.7.2.1. The Summary of Changes at page 47 lists the addition." } ] }, "rail_name": "Visa Authorization Declines", "governing_authority": "Visa (Visa Core Rules and Visa Product and Service Rules)", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "visa-decline:86", "id": "86", "rail": "visa-decline", "kind": "reason-code", "name": "Cannot verify PIN", "group": "authorization", "summary": "The issuer cannot verify the PIN that came with the request. Visa places it in category 2, the codes for an issuer that cannot approve at present, so the merchant may reattempt within the cap.", "triggers": [ "The issuer's PIN verification was unavailable [Inference]", "The PIN block could not be processed, for example because of a key or format problem [Inference]" ], "actions": [ "Merchant: retry, or complete the sale another way if the terminal allows [Inference]", "Acquirer: check PIN encryption set-up if the code recurs [Inference]" ], "retry": { "allowed": true, "rule": "Yes, within a cap: after a category 2 decline the merchant may reattempt, up to 20 attempts in 30 days (VR 7.3.6.3, Table 7-2, ID# 0030640). A reattempt must not deliberately change data from the original request, for example the MCC, the POS entry mode, the e-commerce indicator or the merchant or acquirer country (VR 1.7.2.1, ID# 0008752). Urban mobility merchants follow their own resubmission rule instead (VR 7.3.6.2, ID# 0030046)." }, "facts": { "return_windows": [ { "action": "send this decline response to the authorization or account verification request", "by": "Issuer; if it misses the time limit, Visa answers instead through Stand-In Processing (VR 7.3.4.1)", "deadline": "Within the authorization response time limit: outside Europe 10 seconds for POS and Visa Direct and 25 seconds for ATM cash (MCC 6011); in Europe 5 seconds (VR 7.3.4.1, Table 7-1, ID# 0004385)" }, { "action": "reattempt the authorization request or account verification", "by": "Merchant, through its acquirer", "deadline": "At most 20 attempts within 30 days (VR 7.3.6.3, Table 7-2); the rules read do not say whether the count runs per credential, per merchant or per purchase" } ], "applies_to": "All Visa Regions: an issuer decline of an authorization request or account verification request, under VR 7.3.6.3 and Table 7-2" }, "caveat": "A failed verification of a PIN that was entered wrongly is 55; 86 reads as the issuer being unable to check at all [Inference from the labels]. A decline moves no money and is not a return.", "related": [ "visa-decline:55", "visa-decline:75", "visa-decline:91" ], "basis": { "sources": "Visa Core Rules and Visa Product and Service Rules, edition 18 April 2026 (marked Visa Public), fetched 2026-09-19 with a plain GET from https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf and read with python3. Table 7-2 in VR 7.3.6.3 (ID# 0030640, last updated April 2026) gives the code, Visa's short label (used here as the name), its category and the merchant reattempt limit; VR 1.7.2.1 (ID# 0008752) bars manipulating data on a reattempt; VR 7.3.4.1 (ID# 0004385) sets the issuer response time limits. Visa gives each code a label and a category only; triggers and actions marked [Inference] are Orca's reading. Nothing is quoted apart from the label, which is Visa's defined name for the code.", "confidence": "medium" }, "currency": { "effective_since": "Not dated in the edition read", "effective_note": "Listed in Table 7-2 of the 18 April 2026 edition; the table rule was last updated in April 2026 and gives no start date for this code. Visa publishes a new edition each April and October; the next is expected in October 2026 [Inference].", "source_edition": "Visa Core Rules and Visa Product and Service Rules, edition 18 April 2026 (Table 7-2, ID# 0030640)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf", "source_class": "authoritative_primary", "source_title": "Visa Core Rules and Visa Product and Service Rules, 18 April 2026", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Table 7-2 (VR 7.3.6.3) confirms the label Cannot verify PIN, places it in category 2, and confirms the merchant reattempt limit of up to 20 attempts in 30 days subject to the data-manipulation bar in VR 1.7.2.1." } ] }, "rail_name": "Visa Authorization Declines", "governing_authority": "Visa (Visa Core Rules and Visa Product and Service Rules)", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "visa-decline:91", "id": "91", "rail": "visa-decline", "kind": "reason-code", "name": "Issuer or switch inoperative", "group": "technical", "summary": "The issuer, or the switch between Visa and the issuer, is not working, so the request could not be answered. Visa places it in category 2, the codes for an issuer that cannot approve at present, so the merchant may reattempt within the cap.", "triggers": [ "The issuer or its processor is down or unreachable [Inference from the label]", "The issuer did not respond and stand-in did not approve [Inference]" ], "actions": [ "Merchant: retry after a short pause, within the cap", "Merchant: offer another payment method if the outage persists" ], "retry": { "allowed": true, "rule": "Yes, within a cap: after a category 2 decline the merchant may reattempt, up to 20 attempts in 30 days (VR 7.3.6.3, Table 7-2, ID# 0030640). A reattempt must not deliberately change data from the original request, for example the MCC, the POS entry mode, the e-commerce indicator or the merchant or acquirer country (VR 1.7.2.1, ID# 0008752). Urban mobility merchants follow their own resubmission rule instead (VR 7.3.6.2, ID# 0030046)." }, "facts": { "return_windows": [ { "action": "send this decline response to the authorization or account verification request", "by": "Issuer; if it misses the time limit, Visa answers instead through Stand-In Processing (VR 7.3.4.1)", "deadline": "Within the authorization response time limit: outside Europe 10 seconds for POS and Visa Direct and 25 seconds for ATM cash (MCC 6011); in Europe 5 seconds (VR 7.3.4.1, Table 7-1, ID# 0004385)" }, { "action": "reattempt the authorization request or account verification", "by": "Merchant, through its acquirer", "deadline": "At most 20 attempts within 30 days (VR 7.3.6.3, Table 7-2); the rules read do not say whether the count runs per credential, per merchant or per purchase" } ], "applies_to": "All Visa Regions: an issuer decline of an authorization request or account verification request, under VR 7.3.6.3 and Table 7-2" }, "caveat": "Members must provide authorization 24 hours a day, and when an issuer does not answer in time Visa responds through Stand-In Processing (VR 7.3.3.1, ID# 0004381; 7.3.4.1, ID# 0004385). The rules read do not say when stand-in declines with 91 rather than deciding on the issuer's parameters. A decline moves no money and is not a return.", "related": [ "visa-decline:96", "visa-decline:19", "visa:hours" ], "basis": { "sources": "Visa Core Rules and Visa Product and Service Rules, edition 18 April 2026 (marked Visa Public), fetched 2026-09-19 with a plain GET from https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf and read with python3. Table 7-2 in VR 7.3.6.3 (ID# 0030640, last updated April 2026) gives the code, Visa's short label (used here as the name), its category and the merchant reattempt limit; VR 1.7.2.1 (ID# 0008752) bars manipulating data on a reattempt; VR 7.3.4.1 (ID# 0004385) sets the issuer response time limits. Also read: VR 7.3.3.1 (ID# 0004381). Visa gives each code a label and a category only; triggers and actions marked [Inference] are Orca's reading. Nothing is quoted apart from the label, which is Visa's defined name for the code.", "confidence": "medium" }, "currency": { "effective_since": "Not dated in the edition read", "effective_note": "Listed in Table 7-2 of the 18 April 2026 edition; the table rule was last updated in April 2026 and gives no start date for this code. Visa publishes a new edition each April and October; the next is expected in October 2026 [Inference].", "source_edition": "Visa Core Rules and Visa Product and Service Rules, edition 18 April 2026 (Table 7-2, ID# 0030640)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf", "source_class": "authoritative_primary", "source_title": "Visa Core Rules and Visa Product and Service Rules, 18 April 2026", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Table 7-2 (VR 7.3.6.3) confirms the label Issuer or switch inoperative, places it in category 2, and confirms the merchant reattempt limit of up to 20 attempts in 30 days subject to the data-manipulation bar in VR 1.7.2.1. VR 7.3.3.1 confirms the 24/7 authorization service duty and VR 7.3.4.1 confirms Visa answers through Stand-In Processing when an issuer misses the response time limit." } ] }, "rail_name": "Visa Authorization Declines", "governing_authority": "Visa (Visa Core Rules and Visa Product and Service Rules)", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "visa-decline:93", "id": "93", "rail": "visa-decline", "kind": "reason-code", "name": "Transaction cannot be completed, violation of law", "group": "administrative", "summary": "The issuer has found the transaction illegal and declines it. Visa requires this code when an issuer makes that finding. Visa places it in category 2, the codes for an issuer that cannot approve at present, so the reattempt cap applies.", "triggers": [ "The issuer has determined the transaction is illegal, which obliges it to answer with 93, also for a token provisioning request (VR 1.7.4.1, ID# 0029326)", "A transaction must be legal where the cardholder is and where the merchant outlet is (VR 1.1.1.3, ID# 0000385)" ], "actions": [ "Merchant: do not retry the same transaction; a legal bar will not lift on a reattempt [Inference]", "Merchant and acquirer: review whether the goods or service may be sold to this cardholder's jurisdiction" ], "retry": { "allowed": true, "rule": "Yes, within a cap: after a category 2 decline the merchant may reattempt, up to 20 attempts in 30 days (VR 7.3.6.3, Table 7-2, ID# 0030640). A reattempt must not deliberately change data from the original request, for example the MCC, the POS entry mode, the e-commerce indicator or the merchant or acquirer country (VR 1.7.2.1, ID# 0008752). Urban mobility merchants follow their own resubmission rule instead (VR 7.3.6.2, ID# 0030046)." }, "facts": { "return_windows": [ { "action": "send this decline response to the authorization or account verification request", "by": "Issuer; if it misses the time limit, Visa answers instead through Stand-In Processing (VR 7.3.4.1)", "deadline": "Within the authorization response time limit: outside Europe 10 seconds for POS and Visa Direct and 25 seconds for ATM cash (MCC 6011); in Europe 5 seconds (VR 7.3.4.1, Table 7-1, ID# 0004385)" }, { "action": "reattempt the authorization request or account verification", "by": "Merchant, through its acquirer", "deadline": "At most 20 attempts within 30 days (VR 7.3.6.3, Table 7-2); the rules read do not say whether the count runs per credential, per merchant or per purchase" } ], "applies_to": "All Visa Regions: an issuer decline of an authorization request or account verification request, under VR 7.3.6.3 and Table 7-2" }, "caveat": "Although Table 7-2 allows reattempts after 93, a retry of a transaction the issuer has found illegal serves no purpose unless the facts change [Inference]. A decline moves no money and is not a return.", "related": [ "visa-decline:57", "visa:consumer-law", "visa:decision-points" ], "basis": { "sources": "Visa Core Rules and Visa Product and Service Rules, edition 18 April 2026 (marked Visa Public), fetched 2026-09-19 with a plain GET from https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf and read with python3. Table 7-2 in VR 7.3.6.3 (ID# 0030640, last updated April 2026) gives the code, Visa's short label (used here as the name), its category and the merchant reattempt limit; VR 1.7.2.1 (ID# 0008752) bars manipulating data on a reattempt; VR 7.3.4.1 (ID# 0004385) sets the issuer response time limits. Also read: VR 1.1.1.3 (ID# 0000385); 1.7.4.1 (ID# 0029326). Visa gives each code a label and a category only; triggers and actions marked [Inference] are Orca's reading. Nothing is quoted apart from the label, which is Visa's defined name for the code.", "confidence": "high" }, "currency": { "effective_since": "Not dated in the edition read", "effective_note": "Listed in Table 7-2 of the 18 April 2026 edition; the table rule was last updated in April 2026 and gives no start date for this code. Visa publishes a new edition each April and October; the next is expected in October 2026 [Inference].", "source_edition": "Visa Core Rules and Visa Product and Service Rules, edition 18 April 2026 (Table 7-2, ID# 0030640)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf", "source_class": "authoritative_primary", "source_title": "Visa Core Rules and Visa Product and Service Rules, 18 April 2026", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Table 7-2 (VR 7.3.6.3) confirms the label Transaction cannot be completed, violation of law, places it in category 2, and confirms the merchant reattempt limit of up to 20 attempts in 30 days subject to the data-manipulation bar in VR 1.7.2.1. VR 1.7.4.1 confirms an issuer that has determined a transaction is illegal must send this code, including for a token provisioning request, and VR 1.1.1.3 confirms law overrides the rules where they conflict." } ] }, "rail_name": "Visa Authorization Declines", "governing_authority": "Visa (Visa Core Rules and Visa Product and Service Rules)", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "visa-decline:96", "id": "96", "rail": "visa-decline", "kind": "reason-code", "name": "System malfunction", "group": "technical", "summary": "A system malfunction prevented the request from being processed. Visa places it in category 2, the codes for an issuer that cannot approve at present, so the merchant may reattempt within the cap.", "triggers": [ "A processing fault at the issuer, its processor or in the network [Inference]" ], "actions": [ "Merchant: retry after a short pause, within the cap", "Acquirer: check for a wider outage if many requests fail [Inference]" ], "retry": { "allowed": true, "rule": "Yes, within a cap: after a category 2 decline the merchant may reattempt, up to 20 attempts in 30 days (VR 7.3.6.3, Table 7-2, ID# 0030640). A reattempt must not deliberately change data from the original request, for example the MCC, the POS entry mode, the e-commerce indicator or the merchant or acquirer country (VR 1.7.2.1, ID# 0008752). Urban mobility merchants follow their own resubmission rule instead (VR 7.3.6.2, ID# 0030046)." }, "facts": { "return_windows": [ { "action": "send this decline response to the authorization or account verification request", "by": "Issuer; if it misses the time limit, Visa answers instead through Stand-In Processing (VR 7.3.4.1)", "deadline": "Within the authorization response time limit: outside Europe 10 seconds for POS and Visa Direct and 25 seconds for ATM cash (MCC 6011); in Europe 5 seconds (VR 7.3.4.1, Table 7-1, ID# 0004385)" }, { "action": "reattempt the authorization request or account verification", "by": "Merchant, through its acquirer", "deadline": "At most 20 attempts within 30 days (VR 7.3.6.3, Table 7-2); the rules read do not say whether the count runs per credential, per merchant or per purchase" } ], "applies_to": "All Visa Regions: an issuer decline of an authorization request or account verification request, under VR 7.3.6.3 and Table 7-2" }, "caveat": "The rules read do not say where the malfunction must sit for 96 to be used. A decline moves no money and is not a return.", "related": [ "visa-decline:91", "visa-decline:19" ], "basis": { "sources": "Visa Core Rules and Visa Product and Service Rules, edition 18 April 2026 (marked Visa Public), fetched 2026-09-19 with a plain GET from https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf and read with python3. Table 7-2 in VR 7.3.6.3 (ID# 0030640, last updated April 2026) gives the code, Visa's short label (used here as the name), its category and the merchant reattempt limit; VR 1.7.2.1 (ID# 0008752) bars manipulating data on a reattempt; VR 7.3.4.1 (ID# 0004385) sets the issuer response time limits. Visa gives each code a label and a category only; triggers and actions marked [Inference] are Orca's reading. Nothing is quoted apart from the label, which is Visa's defined name for the code.", "confidence": "medium" }, "currency": { "effective_since": "Not dated in the edition read", "effective_note": "Listed in Table 7-2 of the 18 April 2026 edition; the table rule was last updated in April 2026 and gives no start date for this code. Visa publishes a new edition each April and October; the next is expected in October 2026 [Inference].", "source_edition": "Visa Core Rules and Visa Product and Service Rules, edition 18 April 2026 (Table 7-2, ID# 0030640)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf", "source_class": "authoritative_primary", "source_title": "Visa Core Rules and Visa Product and Service Rules, 18 April 2026", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Table 7-2 (VR 7.3.6.3) confirms the label System malfunction, places it in category 2, and confirms the merchant reattempt limit of up to 20 attempts in 30 days subject to the data-manipulation bar in VR 1.7.2.1." } ] }, "rail_name": "Visa Authorization Declines", "governing_authority": "Visa (Visa Core Rules and Visa Product and Service Rules)", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "visa-decline:9G", "id": "9G", "rail": "visa-decline", "kind": "reason-code", "name": "Blocked by cardholder/contact cardholder", "group": "authorization", "summary": "The cardholder has blocked the card or this kind of transaction, and the issuer asks the merchant to have the cardholder get in touch. Visa places it in category 2, the codes for an issuer that cannot approve at present, so the merchant may reattempt within the cap.", "triggers": [ "The cardholder has paused the card, or limited it by transaction type or MCC, with a control offered by the issuer; the issuer must then decline with 9G (VR 4.1.19.1, ID# 0031150)" ], "actions": [ "Merchant: tell the customer the card is blocked by their own setting and ask them to lift it in the issuer's app, website or service channel", "Merchant: retry once the customer confirms, within the cap" ], "retry": { "allowed": true, "rule": "Yes, within a cap: after a category 2 decline the merchant may reattempt, up to 20 attempts in 30 days (VR 7.3.6.3, Table 7-2, ID# 0030640). A reattempt must not deliberately change data from the original request, for example the MCC, the POS entry mode, the e-commerce indicator or the merchant or acquirer country (VR 1.7.2.1, ID# 0008752). Urban mobility merchants follow their own resubmission rule instead (VR 7.3.6.2, ID# 0030046)." }, "facts": { "return_windows": [ { "action": "send this decline response to the authorization or account verification request", "by": "Issuer; if it misses the time limit, Visa answers instead through Stand-In Processing (VR 7.3.4.1)", "deadline": "Within the authorization response time limit: outside Europe 10 seconds for POS and Visa Direct and 25 seconds for ATM cash (MCC 6011); in Europe 5 seconds (VR 7.3.4.1, Table 7-1, ID# 0004385)" }, { "action": "reattempt the authorization request or account verification", "by": "Merchant, through its acquirer", "deadline": "At most 20 attempts within 30 days (VR 7.3.6.3, Table 7-2); the rules read do not say whether the count runs per credential, per merchant or per purchase" } ], "applies_to": "All Visa Regions: an issuer decline of an authorization request or account verification request, under VR 7.3.6.3 and Table 7-2" }, "caveat": "An issuer offering such controls must also let the cardholder block and unblock through its website, app or customer service (VR 4.1.19.1). In listed Europe countries, larger consumer card issuers must offer temporary block and unblock from 2026-04-18 (VR 4.1.19.2, ID# 0031077). Issuers in Visa Transaction Controls follow the same code rule (VR 8.6.2.2, ID# 0031151). The rule does not apply in the LAC Region (Chile). A decline moves no money and is not a return.", "related": [ "visa-decline:5C", "visa-decline:78", "visa-decline:R1" ], "basis": { "sources": "Visa Core Rules and Visa Product and Service Rules, edition 18 April 2026 (marked Visa Public), fetched 2026-09-19 with a plain GET from https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf and read with python3. Table 7-2 in VR 7.3.6.3 (ID# 0030640, last updated April 2026) gives the code, Visa's short label (used here as the name), its category and the merchant reattempt limit; VR 1.7.2.1 (ID# 0008752) bars manipulating data on a reattempt; VR 7.3.4.1 (ID# 0004385) sets the issuer response time limits. Also read: VR 4.1.19.1 (ID# 0031150); 4.1.19.2 (ID# 0031077); 8.6.2.2 (ID# 0031151). Visa gives each code a label and a category only; triggers and actions marked [Inference] are Orca's reading. Nothing is quoted apart from the label, which is Visa's defined name for the code.", "confidence": "high" }, "currency": { "effective_since": "Not dated in the edition read", "effective_note": "Listed in Table 7-2 of the 18 April 2026 edition; the table rule was last updated in April 2026 and gives no start date for this code. Visa publishes a new edition each April and October; the next is expected in October 2026 [Inference].", "source_edition": "Visa Core Rules and Visa Product and Service Rules, edition 18 April 2026 (Table 7-2, ID# 0030640)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf", "source_class": "authoritative_primary", "source_title": "Visa Core Rules and Visa Product and Service Rules, 18 April 2026", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Table 7-2 (VR 7.3.6.3) confirms the label Blocked by cardholder/contact cardholder, places it in category 2, and confirms the merchant reattempt limit of up to 20 attempts in 30 days subject to the data-manipulation bar in VR 1.7.2.1. VR 4.1.19.1 confirms an issuer offering cardholder block or transaction-type or MCC limit functionality must decline with this code and must also offer the block or unblock function through a website, app or customer service, with the rule not applying in the LAC Region (Chile). VR 4.1.19.2 confirms the listed Europe countries must offer temporary block and unblock from 18 April 2026, subject to portfolio-size and card-type exclusions. VR 8.6.2.2 confirms Visa Transaction Controls follows the same code rule." } ] }, "rail_name": "Visa Authorization Declines", "governing_authority": "Visa (Visa Core Rules and Visa Product and Service Rules)", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "visa-decline:CATEGORY_4", "id": "CATEGORY_4", "rail": "visa-decline", "kind": "reason-code", "name": "Generic decline response codes (Visa category 4)", "group": "administrative", "summary": "Not a single code: this record covers every decline response code that Table 7-2 does not name. Visa groups them as generic responses, which issuers should use only when no named code applies. Visa places it in category 4, the generic group, so the merchant may reattempt within the cap.", "triggers": [ "The issuer sent a decline value that Table 7-2 does not list [Inference: the rules read name none of these codes]", "No named code fitted the issuer's reason" ], "actions": [ "Merchant: reattempt within the cap, or ask for another way to pay", "Issuer: prefer the named code that most accurately reflects the reason, as VR 7.3.6.3 requires" ], "retry": { "allowed": true, "rule": "Yes, within a cap: after a category 4 decline the merchant may reattempt, up to 20 attempts in 30 days (VR 7.3.6.3, Table 7-2, ID# 0030640). A reattempt must not deliberately change data from the original request, for example the MCC, the POS entry mode, the e-commerce indicator or the merchant or acquirer country (VR 1.7.2.1, ID# 0008752). Urban mobility merchants follow their own resubmission rule instead (VR 7.3.6.2, ID# 0030046)." }, "facts": { "return_windows": [ { "action": "send this decline response to the authorization or account verification request", "by": "Issuer; if it misses the time limit, Visa answers instead through Stand-In Processing (VR 7.3.4.1)", "deadline": "Within the authorization response time limit: outside Europe 10 seconds for POS and Visa Direct and 25 seconds for ATM cash (MCC 6011); in Europe 5 seconds (VR 7.3.4.1, Table 7-1, ID# 0004385)" }, { "action": "reattempt the authorization request or account verification", "by": "Merchant, through its acquirer", "deadline": "At most 20 attempts within 30 days (VR 7.3.6.3, Table 7-2); the rules read do not say whether the count runs per credential, per merchant or per purchase" } ], "applies_to": "All Visa Regions: an issuer decline of an authorization request or account verification request, under VR 7.3.6.3 and Table 7-2" }, "caveat": "Visa gives this group no code of its own; CATEGORY_4 is Orca's id, built from Visa's label for the table's fourth category. The values that fall here are set out in VisaNet manuals, which were not read. A decline moves no money and is not a return.", "related": [ "visa-decline:12", "visa:decision-points" ], "basis": { "sources": "Visa Core Rules and Visa Product and Service Rules, edition 18 April 2026 (marked Visa Public), fetched 2026-09-19 with a plain GET from https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf and read with python3. Table 7-2 in VR 7.3.6.3 (ID# 0030640, last updated April 2026) gives the code, Visa's short label (used here as the name), its category and the merchant reattempt limit; VR 1.7.2.1 (ID# 0008752) bars manipulating data on a reattempt; VR 7.3.4.1 (ID# 0004385) sets the issuer response time limits. Visa gives each code a label and a category only; triggers and actions marked [Inference] are Orca's reading. Nothing is quoted apart from the label, which is Visa's defined name for the code.", "confidence": "medium" }, "currency": { "effective_since": "Not dated in the edition read", "effective_note": "Listed in Table 7-2 of the 18 April 2026 edition; the table rule was last updated in April 2026 and gives no start date for this code. Visa publishes a new edition each April and October; the next is expected in October 2026 [Inference].", "source_edition": "Visa Core Rules and Visa Product and Service Rules, edition 18 April 2026 (Table 7-2, ID# 0030640)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf", "source_class": "authoritative_primary", "source_title": "Visa Core Rules and Visa Product and Service Rules, 18 April 2026", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Table 7-2 (VR 7.3.6.3) confirms a fourth category, all other decline response codes, limited to transactions where no other value applies, with the merchant reattempt limit of up to 20 attempts in 30 days subject to the data-manipulation bar in VR 1.7.2.1. Visa gives this category no code of its own in the table, matching the record's own account that CATEGORY_4 is Orca's id built from Visa's label." } ] }, "rail_name": "Visa Authorization Declines", "governing_authority": "Visa (Visa Core Rules and Visa Product and Service Rules)", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "visa-decline:N3", "id": "N3", "rail": "visa-decline", "kind": "reason-code", "name": "Cash service not available", "group": "administrative", "summary": "Cash is not available on this card for this request. Visa places it in category 2, the codes for an issuer that cannot approve at present, so the merchant may reattempt within the cap.", "triggers": [ "The card does not allow cash withdrawals or cash back [Inference from the label]", "Cash service is switched off for the card or the location [Inference]" ], "actions": [ "Merchant or ATM: complete the purchase without cash back, or suggest another card [Inference]" ], "retry": { "allowed": true, "rule": "Yes, within a cap: after a category 2 decline the merchant may reattempt, up to 20 attempts in 30 days (VR 7.3.6.3, Table 7-2, ID# 0030640). A reattempt must not deliberately change data from the original request, for example the MCC, the POS entry mode, the e-commerce indicator or the merchant or acquirer country (VR 1.7.2.1, ID# 0008752). Urban mobility merchants follow their own resubmission rule instead (VR 7.3.6.2, ID# 0030046)." }, "facts": { "return_windows": [ { "action": "send this decline response to the authorization or account verification request", "by": "Issuer; if it misses the time limit, Visa answers instead through Stand-In Processing (VR 7.3.4.1)", "deadline": "Within the authorization response time limit: outside Europe 10 seconds for POS and Visa Direct and 25 seconds for ATM cash (MCC 6011); in Europe 5 seconds (VR 7.3.4.1, Table 7-1, ID# 0004385)" }, { "action": "reattempt the authorization request or account verification", "by": "Merchant, through its acquirer", "deadline": "At most 20 attempts within 30 days (VR 7.3.6.3, Table 7-2); the rules read do not say whether the count runs per credential, per merchant or per purchase" } ], "applies_to": "All Visa Regions: an issuer decline of an authorization request or account verification request, under VR 7.3.6.3 and Table 7-2" }, "caveat": "The rules read give no detail on this code beyond its label. A decline moves no money and is not a return.", "related": [ "visa-decline:N4", "visa-decline:65" ], "basis": { "sources": "Visa Core Rules and Visa Product and Service Rules, edition 18 April 2026 (marked Visa Public), fetched 2026-09-19 with a plain GET from https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf and read with python3. Table 7-2 in VR 7.3.6.3 (ID# 0030640, last updated April 2026) gives the code, Visa's short label (used here as the name), its category and the merchant reattempt limit; VR 1.7.2.1 (ID# 0008752) bars manipulating data on a reattempt; VR 7.3.4.1 (ID# 0004385) sets the issuer response time limits. Visa gives each code a label and a category only; triggers and actions marked [Inference] are Orca's reading. Nothing is quoted apart from the label, which is Visa's defined name for the code.", "confidence": "medium" }, "currency": { "effective_since": "Not dated in the edition read", "effective_note": "Listed in Table 7-2 of the 18 April 2026 edition; the table rule was last updated in April 2026 and gives no start date for this code. Visa publishes a new edition each April and October; the next is expected in October 2026 [Inference].", "source_edition": "Visa Core Rules and Visa Product and Service Rules, edition 18 April 2026 (Table 7-2, ID# 0030640)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf", "source_class": "authoritative_primary", "source_title": "Visa Core Rules and Visa Product and Service Rules, 18 April 2026", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Table 7-2 (VR 7.3.6.3) confirms the label Cash service not available, places it in category 2, and confirms the merchant reattempt limit of up to 20 attempts in 30 days subject to the data-manipulation bar in VR 1.7.2.1. The table gives no further definition of the code, matching the record's own account of the limits of what is published." } ] }, "rail_name": "Visa Authorization Declines", "governing_authority": "Visa (Visa Core Rules and Visa Product and Service Rules)", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "visa-decline:N4", "id": "N4", "rail": "visa-decline", "kind": "reason-code", "name": "Cash request exceeds issuer or approved limit", "group": "funds", "summary": "The cash amount asked for is above the issuer's limit or the approved limit. Visa places it in category 2, the codes for an issuer that cannot approve at present, so the merchant may reattempt within the cap.", "triggers": [ "A cash withdrawal or cash back amount exceeds an issuer cash limit [Inference from the label]" ], "actions": [ "Merchant or ATM: offer a smaller cash amount [Inference]" ], "retry": { "allowed": true, "rule": "Yes, within a cap: after a category 2 decline the merchant may reattempt, up to 20 attempts in 30 days (VR 7.3.6.3, Table 7-2, ID# 0030640). A reattempt must not deliberately change data from the original request, for example the MCC, the POS entry mode, the e-commerce indicator or the merchant or acquirer country (VR 1.7.2.1, ID# 0008752). Urban mobility merchants follow their own resubmission rule instead (VR 7.3.6.2, ID# 0030046)." }, "facts": { "return_windows": [ { "action": "send this decline response to the authorization or account verification request", "by": "Issuer; if it misses the time limit, Visa answers instead through Stand-In Processing (VR 7.3.4.1)", "deadline": "Within the authorization response time limit: outside Europe 10 seconds for POS and Visa Direct and 25 seconds for ATM cash (MCC 6011); in Europe 5 seconds (VR 7.3.4.1, Table 7-1, ID# 0004385)" }, { "action": "reattempt the authorization request or account verification", "by": "Merchant, through its acquirer", "deadline": "At most 20 attempts within 30 days (VR 7.3.6.3, Table 7-2); the rules read do not say whether the count runs per credential, per merchant or per purchase" } ], "applies_to": "All Visa Regions: an issuer decline of an authorization request or account verification request, under VR 7.3.6.3 and Table 7-2" }, "caveat": "The limit is the issuer's and is not published in the Visa rules. A decline moves no money and is not a return.", "related": [ "visa-decline:N3", "visa-decline:61", "visa-decline:51" ], "basis": { "sources": "Visa Core Rules and Visa Product and Service Rules, edition 18 April 2026 (marked Visa Public), fetched 2026-09-19 with a plain GET from https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf and read with python3. Table 7-2 in VR 7.3.6.3 (ID# 0030640, last updated April 2026) gives the code, Visa's short label (used here as the name), its category and the merchant reattempt limit; VR 1.7.2.1 (ID# 0008752) bars manipulating data on a reattempt; VR 7.3.4.1 (ID# 0004385) sets the issuer response time limits. Visa gives each code a label and a category only; triggers and actions marked [Inference] are Orca's reading. Nothing is quoted apart from the label, which is Visa's defined name for the code.", "confidence": "medium" }, "currency": { "effective_since": "Not dated in the edition read", "effective_note": "Listed in Table 7-2 of the 18 April 2026 edition; the table rule was last updated in April 2026 and gives no start date for this code. Visa publishes a new edition each April and October; the next is expected in October 2026 [Inference].", "source_edition": "Visa Core Rules and Visa Product and Service Rules, edition 18 April 2026 (Table 7-2, ID# 0030640)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf", "source_class": "authoritative_primary", "source_title": "Visa Core Rules and Visa Product and Service Rules, 18 April 2026", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Table 7-2 (VR 7.3.6.3) confirms the label Cash request exceeds issuer or approved limit, places it in category 2, and confirms the merchant reattempt limit of up to 20 attempts in 30 days subject to the data-manipulation bar in VR 1.7.2.1." } ] }, "rail_name": "Visa Authorization Declines", "governing_authority": "Visa (Visa Core Rules and Visa Product and Service Rules)", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "visa-decline:N7", "id": "N7", "rail": "visa-decline", "kind": "reason-code", "name": "Decline for CVV2 failure", "group": "authorization", "summary": "The card security code (CVV2) sent with the request failed the issuer's check. Visa places it in category 3, the data-quality codes that tell the merchant to check the payment details again, so the merchant may correct and reattempt within the cap.", "triggers": [ "The cardholder entered the wrong CVV2 [Inference]", "The CVV2 did not match because the card data is not genuine [Inference]" ], "actions": [ "Merchant: ask the cardholder to re-enter the code from the card", "Merchant: stop after repeated failures and ask for another card [Inference]" ], "retry": { "allowed": true, "rule": "Yes, within a cap: after a category 3 decline the merchant may reattempt, up to 20 attempts in 30 days (VR 7.3.6.3, Table 7-2, ID# 0030640). A reattempt must not deliberately change data from the original request, for example the MCC, the POS entry mode, the e-commerce indicator or the merchant or acquirer country (VR 1.7.2.1, ID# 0008752). Correcting card data the cardholder gave (an expiry date, a PIN, a security code) is what a data-quality decline invites, and does not count as the manipulation VR 1.7.2.1 forbids, which concerns merchant and acquirer data [Inference]. Urban mobility merchants follow their own resubmission rule instead (VR 7.3.6.2, ID# 0030046)." }, "facts": { "return_windows": [ { "action": "send this decline response to the authorization or account verification request", "by": "Issuer; if it misses the time limit, Visa answers instead through Stand-In Processing (VR 7.3.4.1)", "deadline": "Within the authorization response time limit: outside Europe 10 seconds for POS and Visa Direct and 25 seconds for ATM cash (MCC 6011); in Europe 5 seconds (VR 7.3.4.1, Table 7-1, ID# 0004385)" }, { "action": "reattempt the authorization request or account verification", "by": "Merchant, through its acquirer", "deadline": "At most 20 attempts within 30 days (VR 7.3.6.3, Table 7-2); the rules read do not say whether the count runs per credential, per merchant or per purchase" } ], "applies_to": "All Visa Regions: an issuer decline of an authorization request or account verification request, under VR 7.3.6.3 and Table 7-2" }, "caveat": "An issuer may not decline solely because the CVV2 is missing for token provisioning, token transactions, mobility and transport resubmissions, or where capture of CVV2 is barred or not required (VR 7.3.6.1, ID# 0029985). A decline moves no money and is not a return.", "related": [ "visa-decline:82", "visa-decline:54", "visa-decline:6P" ], "basis": { "sources": "Visa Core Rules and Visa Product and Service Rules, edition 18 April 2026 (marked Visa Public), fetched 2026-09-19 with a plain GET from https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf and read with python3. Table 7-2 in VR 7.3.6.3 (ID# 0030640, last updated April 2026) gives the code, Visa's short label (used here as the name), its category and the merchant reattempt limit; VR 1.7.2.1 (ID# 0008752) bars manipulating data on a reattempt; VR 7.3.4.1 (ID# 0004385) sets the issuer response time limits. Also read: VR 7.3.6.1 (ID# 0029985). Visa gives each code a label and a category only; triggers and actions marked [Inference] are Orca's reading. Nothing is quoted apart from the label, which is Visa's defined name for the code.", "confidence": "medium" }, "currency": { "effective_since": "Not dated in the edition read", "effective_note": "Listed in Table 7-2 of the 18 April 2026 edition; the table rule was last updated in April 2026 and gives no start date for this code. Visa publishes a new edition each April and October; the next is expected in October 2026 [Inference].", "source_edition": "Visa Core Rules and Visa Product and Service Rules, edition 18 April 2026 (Table 7-2, ID# 0030640)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf", "source_class": "authoritative_primary", "source_title": "Visa Core Rules and Visa Product and Service Rules, 18 April 2026", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Table 7-2 (VR 7.3.6.3) confirms the label Decline for CVV2 failure, places it in category 3, and confirms the merchant reattempt limit of up to 20 attempts in 30 days subject to the data-manipulation bar in VR 1.7.2.1. VR 7.3.6.1 confirms an issuer must not decline solely for a missing CVV2 on a token provisioning request, a token transaction, a mobility and transport resubmission, or a transaction where CVV2 capture is barred or not required." } ] }, "rail_name": "Visa Authorization Declines", "governing_authority": "Visa (Visa Core Rules and Visa Product and Service Rules)", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "visa-decline:R0", "id": "R0", "rail": "visa-decline", "kind": "reason-code", "name": "Stop payment order", "group": "authorization", "summary": "The cardholder has asked the issuer to stop a payment, and the issuer refuses the request on that instruction. Visa places it in category 1, the codes an issuer uses when it will never approve the request, so the merchant may not try this credential again for the payment.", "triggers": [ "The cardholder told the issuer to stop a card-absent payment to this merchant; an issuer in the Stop Payment Service records such instructions (VR 7.8.2.1, ID# 0030698) [Inference that R0 is how the instruction surfaces]" ], "actions": [ "Merchant: stop charging this credential and contact the customer about the payment", "Merchant: settle any disagreement about the contract with the customer directly; the stop is the cardholder's instruction to its issuer" ], "retry": { "allowed": false, "rule": "No. This is a category 1 code: the issuer will not approve the request however often it is sent, so the merchant must never again send an authorization request or account verification for the same payment credential, and the issuer must keep answering with the same code (VR 7.3.6.3, Table 7-2 and its note 1, ID# 0030640). Asking the cardholder for a different card starts a new payment rather than a reattempt [Inference]." }, "facts": { "return_windows": [ { "action": "send this decline response to the authorization or account verification request", "by": "Issuer; if it misses the time limit, Visa answers instead through Stand-In Processing (VR 7.3.4.1)", "deadline": "Within the authorization response time limit: outside Europe 10 seconds for POS and Visa Direct and 25 seconds for ATM cash (MCC 6011); in Europe 5 seconds (VR 7.3.4.1, Table 7-1, ID# 0004385)" }, { "action": "reattempt the authorization request or account verification for the same payment credential", "by": "Merchant, through its acquirer", "deadline": "Never; no reattempt is allowed for this credential (VR 7.3.6.3, Table 7-2)" } ], "applies_to": "All Visa Regions: an issuer decline of an authorization request or account verification request, under VR 7.3.6.3 and Table 7-2" }, "caveat": "The Stop Payment Service is an issuer service placed on card-absent transactions at the cardholder's request (Glossary, ID# 0030697). From 2026-10-24 the service rule does not apply in the LAC Region (Brazil) (VR 7.8.2.1 note 1). A decline moves no money and is not a return.", "related": [ "visa-decline:R1", "visa-decline:R3", "visa:recall", "visa-dispute:13.2" ], "basis": { "sources": "Visa Core Rules and Visa Product and Service Rules, edition 18 April 2026 (marked Visa Public), fetched 2026-09-19 with a plain GET from https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf and read with python3. Table 7-2 in VR 7.3.6.3 (ID# 0030640, last updated April 2026) gives the code, Visa's short label (used here as the name), its category and the merchant reattempt limit; VR 1.7.2.1 (ID# 0008752) bars manipulating data on a reattempt; VR 7.3.4.1 (ID# 0004385) sets the issuer response time limits. Also read: VR 7.8.2.1 (ID# 0030698); Glossary, Stop Payment Service (ID# 0030697); VR 4.1.19.3 (ID# 0031078); Summary of Changes p. 52. Visa gives each code a label and a category only; triggers and actions marked [Inference] are Orca's reading. Nothing is quoted apart from the label, which is Visa's defined name for the code.", "confidence": "medium" }, "currency": { "effective_since": "Not dated in the edition read", "effective_note": "Listed in Table 7-2 of the 18 April 2026 edition; the table rule was last updated in April 2026 and gives no start date for this code. Visa publishes a new edition each April and October; the next is expected in October 2026 [Inference].", "source_edition": "Visa Core Rules and Visa Product and Service Rules, edition 18 April 2026 (Table 7-2, ID# 0030640)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf", "source_class": "authoritative_primary", "source_title": "Visa Core Rules and Visa Product and Service Rules, 18 April 2026", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Table 7-2 (VR 7.3.6.3) confirms the label Stop payment order, places it in category 1 among codes the issuer will never approve, and requires the merchant to never resubmit the same payment credential while the issuer keeps sending the same code. The glossary and VR 7.8.2.1 confirm the Stop Payment Service lets an issuer act on a cardholder's instruction against a card-absent transaction, and VR 7.8.2.1 confirms the service stops applying in the LAC Region (Brazil) from 24 October 2026." } ] }, "rail_name": "Visa Authorization Declines", "governing_authority": "Visa (Visa Core Rules and Visa Product and Service Rules)", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "visa-decline:R1", "id": "R1", "rail": "visa-decline", "kind": "reason-code", "name": "Revocation of authorization order", "group": "authorization", "summary": "The cardholder has revoked authorization for further payments, and the issuer refuses the request on that order. Visa places it in category 1, the codes an issuer uses when it will never approve the request, so the merchant may not try this credential again.", "triggers": [ "The cardholder used a subscription control to stop future payments to this merchant; where the issuer must offer such controls it must decline with R1 or R3 (VR 4.1.19.3, ID# 0031078)", "The cardholder asked the issuer to revoke a standing authorization [Inference]" ], "actions": [ "Merchant: stop recurring, installment or unscheduled card-on-file charges to this credential", "Merchant: take up any remaining contract with the customer directly; the issuer must tell cardholders that stopping payments may not end their contract with the merchant (VR 4.1.19.3)" ], "retry": { "allowed": false, "rule": "No. This is a category 1 code: the issuer will not approve the request however often it is sent, so the merchant must never again send an authorization request or account verification for the same payment credential, and the issuer must keep answering with the same code (VR 7.3.6.3, Table 7-2 and its note 1, ID# 0030640). Asking the cardholder for a different card starts a new payment rather than a reattempt [Inference]." }, "facts": { "return_windows": [ { "action": "send this decline response to the authorization or account verification request", "by": "Issuer; if it misses the time limit, Visa answers instead through Stand-In Processing (VR 7.3.4.1)", "deadline": "Within the authorization response time limit: outside Europe 10 seconds for POS and Visa Direct and 25 seconds for ATM cash (MCC 6011); in Europe 5 seconds (VR 7.3.4.1, Table 7-1, ID# 0004385)" }, { "action": "reattempt the authorization request or account verification for the same payment credential", "by": "Merchant, through its acquirer", "deadline": "Never; no reattempt is allowed for this credential (VR 7.3.6.3, Table 7-2)" } ], "applies_to": "All Visa Regions: an issuer decline of an authorization request or account verification request, under VR 7.3.6.3 and Table 7-2" }, "caveat": "VR 4.1.19.3 describes R1 in other words than Table 7-2 (a stop on all future payments), and this record uses Table 7-2's label. The subscription control duty applies in listed Europe countries from 2026-04-18 and in most of the AP Region from 2027-04-24; the Summary of Changes says the AP change also revises R1 and R3 [Unverified whether their meaning changes or only their labels]. A decline moves no money and is not a return.", "related": [ "visa-decline:R3", "visa-decline:R0", "visa:recall", "visa-dispute:13.2" ], "basis": { "sources": "Visa Core Rules and Visa Product and Service Rules, edition 18 April 2026 (marked Visa Public), fetched 2026-09-19 with a plain GET from https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf and read with python3. Table 7-2 in VR 7.3.6.3 (ID# 0030640, last updated April 2026) gives the code, Visa's short label (used here as the name), its category and the merchant reattempt limit; VR 1.7.2.1 (ID# 0008752) bars manipulating data on a reattempt; VR 7.3.4.1 (ID# 0004385) sets the issuer response time limits. Also read: VR 7.8.2.1 (ID# 0030698); Glossary, Stop Payment Service (ID# 0030697); VR 4.1.19.3 (ID# 0031078); Summary of Changes p. 52. Visa gives each code a label and a category only; triggers and actions marked [Inference] are Orca's reading. Nothing is quoted apart from the label, which is Visa's defined name for the code.", "confidence": "medium" }, "currency": { "effective_since": "Not dated in the edition read", "effective_note": "Listed in Table 7-2 of the 18 April 2026 edition; the table rule was last updated in April 2026 and gives no start date for this code. Visa publishes a new edition each April and October; the next is expected in October 2026 [Inference]. Known dated change: on 2027-04-24 an AP Region subscription control change revises codes R1 and R3 (Summary of Changes p. 52; VR 4.1.19.3, ID# 0031078).", "source_edition": "Visa Core Rules and Visa Product and Service Rules, edition 18 April 2026 (Table 7-2, ID# 0030640)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf", "source_class": "authoritative_primary", "source_title": "Visa Core Rules and Visa Product and Service Rules, 18 April 2026", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Table 7-2 (VR 7.3.6.3) confirms the label Revocation of authorization order, places it in category 1 among codes the issuer will never approve, and requires the merchant to never resubmit the same payment credential while the issuer keeps sending the same code. VR 4.1.19.3 confirms this code is described there as stopping all future payments, confirms the Europe list effective 18 April 2026 and the AP Region start of 24 April 2027, though it does not say whether the 2027 change touches this code's meaning or only its label." } ] }, "rail_name": "Visa Authorization Declines", "governing_authority": "Visa (Visa Core Rules and Visa Product and Service Rules)", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "jurisdiction", "label": "the country", "needs": "which country the payment or the account is in", "detail": "The subscription control duty applies in listed Europe countries from 2026-04-18 and in most of the AP Region from 2027-04-24; the Summary of Changes says the AP change also revises R1 and R3 [Unverified whether their meaning changes or only their labels].", "from": "caveat" } ] }, { "uid": "visa-decline:R3", "id": "R3", "rail": "visa-decline", "kind": "reason-code", "name": "Revocation of all authorizations order", "group": "authorization", "summary": "The cardholder has revoked all standing authorizations on the card, and the issuer refuses the request on that order. Visa places it in category 1, the codes an issuer uses when it will never approve the request, so the merchant may not try this credential again.", "triggers": [ "The cardholder used a subscription control to stop future payments to all merchants; where the issuer must offer such controls it must decline with R1 or R3 (VR 4.1.19.3, ID# 0031078)" ], "actions": [ "Merchant: stop all stored-credential charges to this card and ask the customer for a new way to pay", "Merchant: take up any remaining contract with the customer directly" ], "retry": { "allowed": false, "rule": "No. This is a category 1 code: the issuer will not approve the request however often it is sent, so the merchant must never again send an authorization request or account verification for the same payment credential, and the issuer must keep answering with the same code (VR 7.3.6.3, Table 7-2 and its note 1, ID# 0030640). Asking the cardholder for a different card starts a new payment rather than a reattempt [Inference]." }, "facts": { "return_windows": [ { "action": "send this decline response to the authorization or account verification request", "by": "Issuer; if it misses the time limit, Visa answers instead through Stand-In Processing (VR 7.3.4.1)", "deadline": "Within the authorization response time limit: outside Europe 10 seconds for POS and Visa Direct and 25 seconds for ATM cash (MCC 6011); in Europe 5 seconds (VR 7.3.4.1, Table 7-1, ID# 0004385)" }, { "action": "reattempt the authorization request or account verification for the same payment credential", "by": "Merchant, through its acquirer", "deadline": "Never; no reattempt is allowed for this credential (VR 7.3.6.3, Table 7-2)" } ], "applies_to": "All Visa Regions: an issuer decline of an authorization request or account verification request, under VR 7.3.6.3 and Table 7-2" }, "caveat": "VR 4.1.19.3 describes R3 as a stop on all merchants, while Table 7-2 speaks of revoking all authorizations; this record uses Table 7-2's label. The subscription control duty applies in listed Europe countries from 2026-04-18 and in most of the AP Region from 2027-04-24, and the AP change also revises R1 and R3 [Unverified whether meaning or only labels]. A decline moves no money and is not a return.", "related": [ "visa-decline:R1", "visa-decline:R0", "visa:recall", "visa-dispute:13.2" ], "basis": { "sources": "Visa Core Rules and Visa Product and Service Rules, edition 18 April 2026 (marked Visa Public), fetched 2026-09-19 with a plain GET from https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf and read with python3. Table 7-2 in VR 7.3.6.3 (ID# 0030640, last updated April 2026) gives the code, Visa's short label (used here as the name), its category and the merchant reattempt limit; VR 1.7.2.1 (ID# 0008752) bars manipulating data on a reattempt; VR 7.3.4.1 (ID# 0004385) sets the issuer response time limits. Also read: VR 7.8.2.1 (ID# 0030698); Glossary, Stop Payment Service (ID# 0030697); VR 4.1.19.3 (ID# 0031078); Summary of Changes p. 52. Visa gives each code a label and a category only; triggers and actions marked [Inference] are Orca's reading. Nothing is quoted apart from the label, which is Visa's defined name for the code.", "confidence": "medium" }, "currency": { "effective_since": "Not dated in the edition read", "effective_note": "Listed in Table 7-2 of the 18 April 2026 edition; the table rule was last updated in April 2026 and gives no start date for this code. Visa publishes a new edition each April and October; the next is expected in October 2026 [Inference]. Known dated change: on 2027-04-24 an AP Region subscription control change revises codes R1 and R3 (Summary of Changes p. 52; VR 4.1.19.3, ID# 0031078).", "source_edition": "Visa Core Rules and Visa Product and Service Rules, edition 18 April 2026 (Table 7-2, ID# 0030640)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf", "source_class": "authoritative_primary", "source_title": "Visa Core Rules and Visa Product and Service Rules, 18 April 2026", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Table 7-2 (VR 7.3.6.3) confirms the label Revocation of all authorizations order, places it in category 1 among codes the issuer will never approve, and requires the merchant to never resubmit the same payment credential while the issuer keeps sending the same code. VR 4.1.19.3 confirms this code is described there as stopping all merchants, confirms the Europe list effective 18 April 2026 and the AP Region start of 24 April 2027, though it does not say whether the 2027 change touches this code's meaning or only its label." } ] }, "rail_name": "Visa Authorization Declines", "governing_authority": "Visa (Visa Core Rules and Visa Product and Service Rules)", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "jurisdiction", "label": "the country", "needs": "which country the payment or the account is in", "detail": "The subscription control duty applies in listed Europe countries from 2026-04-18 and in most of the AP Region from 2027-04-24, and the AP change also revises R1 and R3 [Unverified whether meaning or only labels].", "from": "caveat" } ] }, { "uid": "visa-decline:Z5", "id": "Z5", "rail": "visa-decline", "kind": "reason-code", "name": "Valid account but amount not supported", "group": "administrative", "summary": "The account is valid, but the issuer does not support the amount in the request. Visa places it in category 2, the codes for an issuer that cannot approve at present, so the merchant may reattempt within the cap.", "triggers": [ "The amount is of a kind the issuer does not accept on this account [Inference from the label; the rules read give no example]" ], "actions": [ "Merchant: check the amount and currency sent, and retry with a corrected amount if it was wrong [Inference]" ], "retry": { "allowed": true, "rule": "Yes, within a cap: after a category 2 decline the merchant may reattempt, up to 20 attempts in 30 days (VR 7.3.6.3, Table 7-2, ID# 0030640). A reattempt must not deliberately change data from the original request, for example the MCC, the POS entry mode, the e-commerce indicator or the merchant or acquirer country (VR 1.7.2.1, ID# 0008752). Urban mobility merchants follow their own resubmission rule instead (VR 7.3.6.2, ID# 0030046)." }, "facts": { "return_windows": [ { "action": "send this decline response to the authorization or account verification request", "by": "Issuer; if it misses the time limit, Visa answers instead through Stand-In Processing (VR 7.3.4.1)", "deadline": "Within the authorization response time limit: outside Europe 10 seconds for POS and Visa Direct and 25 seconds for ATM cash (MCC 6011); in Europe 5 seconds (VR 7.3.4.1, Table 7-1, ID# 0004385)" }, { "action": "reattempt the authorization request or account verification", "by": "Merchant, through its acquirer", "deadline": "At most 20 attempts within 30 days (VR 7.3.6.3, Table 7-2); the rules read do not say whether the count runs per credential, per merchant or per purchase" } ], "applies_to": "All Visa Regions: an issuer decline of an authorization request or account verification request, under VR 7.3.6.3 and Table 7-2" }, "caveat": "Visa's label is all the rules read say about this code. A decline moves no money and is not a return.", "related": [ "visa-decline:61", "visa-decline:51" ], "basis": { "sources": "Visa Core Rules and Visa Product and Service Rules, edition 18 April 2026 (marked Visa Public), fetched 2026-09-19 with a plain GET from https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf and read with python3. Table 7-2 in VR 7.3.6.3 (ID# 0030640, last updated April 2026) gives the code, Visa's short label (used here as the name), its category and the merchant reattempt limit; VR 1.7.2.1 (ID# 0008752) bars manipulating data on a reattempt; VR 7.3.4.1 (ID# 0004385) sets the issuer response time limits. Visa gives each code a label and a category only; triggers and actions marked [Inference] are Orca's reading. Nothing is quoted apart from the label, which is Visa's defined name for the code.", "confidence": "medium" }, "currency": { "effective_since": "Not dated in the edition read", "effective_note": "Listed in Table 7-2 of the 18 April 2026 edition; the table rule was last updated in April 2026 and gives no start date for this code. Visa publishes a new edition each April and October; the next is expected in October 2026 [Inference].", "source_edition": "Visa Core Rules and Visa Product and Service Rules, edition 18 April 2026 (Table 7-2, ID# 0030640)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf", "source_class": "authoritative_primary", "source_title": "Visa Core Rules and Visa Product and Service Rules, 18 April 2026", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Table 7-2 (VR 7.3.6.3) confirms the label Valid account but amount not supported, places it in category 2, and confirms the merchant reattempt limit of up to 20 attempts in 30 days subject to the data-manipulation bar in VR 1.7.2.1. The table gives no further definition of the code, matching the record's own account of the limits of what is published." } ] }, "rail_name": "Visa Authorization Declines", "governing_authority": "Visa (Visa Core Rules and Visa Product and Service Rules)", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "visa-dispute:10.1", "id": "10.1", "rail": "visa-dispute", "kind": "reason-code", "name": "EMV Liability Shift Counterfeit Fraud", "group": "authorization", "summary": "Fraud dispute for a counterfeit copy of a chip card used in person where the merchant side did not use the chip: the terminal could not read chips, or the chip data never reached Visa. The EMV liability shift puts the loss on the Acquirer.", "triggers": [ "The Transaction qualifies for the EMV liability shift (VR 1.10.1.2) and the cardholder says they neither authorized it nor took part in it", "A Counterfeit Card was used in a Card-Present Environment and the genuine card is a Chip Card", "The chip was not used or its data was lost: an offline approval whose Clearing Record lacked the Full-Chip Data, an online chip authorization whose Authorization Request lacked it, or no Chip-Reading Device at all (terminal entry capability code other than 5)" ], "actions": [ "Issuer: before filing, report the Fraud Activity to Visa as fraud type code 4, counterfeit (VR 11.7.2.2, ID# 0030234)", "Issuer: certify that the cardholder denies the transaction and, if it was key-entered, that the card is a Chip Card; if the fraud was first reported under another type, explain the change (VR 11.7.2.5, ID# 0030237)", "Acquirer: check whether chip data was captured and sent; if the dispute falls in an invalid case below, contest it at pre-arbitration" ], "retry": { "allowed": true, "rule": "Retry here means the Acquirer's right to contest. Categories 10 and 11 have no dispute response stage: the Acquirer contests with a pre-arbitration attempt, the Issuer accepts it or declines it, and a case still open goes to arbitration filed by the Acquirer (VR 11.2.2, Table 11-1, ID# 0030212). For 10.1 the pre-arbitration attempt must show that the dispute fails this condition's rules, that the cardholder has withdrawn it, or that the Issuer left out a credit or reversal the merchant had already made. For a delayed charge it may instead show that the charge belongs to an earlier stay, trip or rental during which an Imprint was taken at a Chip-Reading Device. Only in the US Region may the Acquirer also offer Compelling Evidence, as listed for this condition in Table 11-6 (VR 11.7.2.6, Table 11-13, ID# 0030238; VR 11.5.1, ID# 0030221). An Acquirer may answer a dispute only once, and a merchant must not put a disputed and returned transaction through again; it may still seek payment from the customer outside the Visa system (VR 11.2.1, ID# 0030211; VR 5.10.1.2, ID# 0003022)." }, "facts": { "return_windows": [ { "action": "dispute", "by": "Issuer", "deadline": "120 calendar days from the Transaction Processing Date" }, { "action": "pre-arbitration attempt", "by": "Acquirer", "deadline": "30 calendar days from the Dispute Processing Date" }, { "action": "pre-arbitration attempt", "by": "Acquirer (CEMEA Region, Nigeria domestic)", "deadline": "2 business days from the Dispute Processing Date" }, { "action": "pre-arbitration attempt", "by": "Acquirer (CEMEA Region, Tanzania domestic)", "deadline": "20 calendar days from the Dispute Processing Date" }, { "action": "pre-arbitration attempt", "by": "Acquirer (Europe Region, Poland domestic ATM Transaction)", "deadline": "20 calendar days from the Dispute Processing Date" }, { "action": "pre-arbitration response (accept or decline)", "by": "Issuer", "deadline": "30 calendar days from the Processing Date of the pre-arbitration attempt" }, { "action": "pre-arbitration response (accept or decline)", "by": "Issuer (CEMEA Region, Tanzania domestic)", "deadline": "10 calendar days from the Processing Date of the pre-arbitration attempt" }, { "action": "arbitration filing", "by": "Acquirer", "deadline": "10 calendar days from the Processing Date of the pre-arbitration response" } ], "applies_to": "All Visa Regions. Outside Europe a Token transaction is excluded; US Region Acquirers may use Compelling Evidence at pre-arbitration" }, "caveat": "Invalid under 10.1, grouped by Orca: (a) the chip or its fallback was in fact used: a Chip-initiated Transaction, or a Fallback Transaction; (b) card data checks: a magnetic-stripe read (POS Entry Mode code 90) whose Service Code shows no chip, or a request carrying the CVV where the CVV failed or was not checked; (c) fraud already on record: the credential was reported as Fraud Activity before the approval, unless the report was fraud type C or D or concerned declined Transactions; (d) transaction types outside the condition: Emergency Cash Disbursement, Mobile Push Payment Transaction, Visa Commercial Choice Omni Product; (e) a delayed charge flagged with message reason code 3902 and linked to an earlier stay, trip or rental where a chip Imprint was taken; (f) outside the Europe Region, a Transaction that contained a Token (VR 11.7.2.3, Table 11-10, ID# 0030235). Day counts are calendar days unless stated, and the processing date of the event that starts a count is not itself counted (VR 11.2.1, ID# 0030211).", "related": [ "visa-dispute:10.2", "visa-dispute:10.3", "visa-dispute:10.4", "visa:return", "visa:liability" ], "basis": { "sources": "Visa Core Rules and Visa Product and Service Rules, 18 April 2026 edition: VR 11.7.2.1 to 11.7.2.6 (ID# 0030233 to 0030238), Tables 11-8 to 11-13; VR 11.7.1 (ID# 0030223, certification method); VR 11.5.1, Table 11-6 (ID# 0030221); VR 11.2.1 (ID# 0030211); VR 11.2.2, Table 11-1 (ID# 0030212, stage deadlines and country notes); VR 5.10.1.2 (ID# 0003022); VR 11.6.1, Table 11-7 (ID# 0030222, region labels).", "confidence": "high" }, "currency": { "effective_since": "Before the current edition; start not stated in it", "effective_note": "Rules as in the 18 April 2026 edition of the Visa rules. Each rule cited carries its own last-updated month in its ID# footer, which the watch compares edition to edition. The next edition is expected in October 2026 [Inference].", "source_edition": "Visa Core Rules and Visa Product and Service Rules, 18 April 2026 edition (Visa Public), https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf", "source_class": "authoritative_primary", "source_title": "Visa Core Rules and Visa Product and Service Rules, 18 April 2026", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms the 120 calendar day filing deadline from the transaction processing date (Table 11-11, VR 11.7.2.4) and the category 10/11 process cycle: a 30 day pre-arbitration attempt by the acquirer, a 30 day accept-or-decline response by the issuer, and a 10 day arbitration filing by the acquirer, with the Nigeria, Tanzania and Poland domestic variants (Table 11-1, VR 11.2.2). Confirms the group is authorization-category dispute resolution and that categories 10 and 11 have no dispute-response stage." } ] }, "rail_name": "Visa Disputes", "governing_authority": "Visa", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "visa-dispute:10.2", "id": "10.2", "rail": "visa-dispute", "kind": "reason-code", "name": "EMV Liability Shift Non-Counterfeit Fraud", "group": "authorization", "summary": "Fraud dispute for a lost, stolen or never-received PIN-Preferring Chip Card used in person where the acceptance setup did not protect the PIN: no chip reader, a chip reader that was not EMV PIN-compliant, or an online chip transaction without online PIN whose chip data the Acquirer did not send.", "triggers": [ "The Transaction qualifies for the EMV liability shift (VR 1.10.1.2) and the cardholder denies authorizing it or taking part in it", "A PIN-Preferring Chip Card was used in a Card-Present Environment", "The PIN was not protected: a chip transaction authorized online without online PIN and without Full-Chip Data in the Authorization Request, a chip read at a device that was not EMV PIN-compliant, or no Chip-Reading Device at all" ], "actions": [ "Issuer: before filing, report the Fraud Activity as fraud type code 0 (lost), 1 (stolen) or 2 (card not received as issued, NRI) (VR 11.7.3.2, ID# 0030240)", "Issuer: certify that the card is a PIN-Preferring Chip Card and that the cardholder denies the transaction; explain any change from the fraud type first reported (VR 11.7.3.5, ID# 0030243)", "Acquirer: check the terminal's PIN capability and the chip data sent; contest an invalid dispute at pre-arbitration" ], "retry": { "allowed": true, "rule": "Retry here means the Acquirer's right to contest. Categories 10 and 11 have no dispute response stage: the Acquirer contests with a pre-arbitration attempt, the Issuer accepts it or declines it, and a case still open goes to arbitration filed by the Acquirer (VR 11.2.2, Table 11-1, ID# 0030212). For 10.2 the pre-arbitration attempt must show that the dispute fails this condition's rules, that the cardholder has withdrawn it, or that the Issuer left out a credit or reversal the merchant had already made, or, for a delayed charge, that it belongs to an earlier stay, trip or rental during which an Imprint was taken at an EMV PIN-compliant chip reader. Compelling Evidence is not among the options for this condition (VR 11.7.3.6, Table 11-19, ID# 0030244). An Acquirer may answer a dispute only once, and a merchant must not put a disputed and returned transaction through again; it may still seek payment from the customer outside the Visa system (VR 11.2.1, ID# 0030211; VR 5.10.1.2, ID# 0003022)." }, "facts": { "return_windows": [ { "action": "dispute", "by": "Issuer", "deadline": "120 calendar days from the Transaction Processing Date" }, { "action": "pre-arbitration attempt", "by": "Acquirer", "deadline": "30 calendar days from the Dispute Processing Date" }, { "action": "pre-arbitration attempt", "by": "Acquirer (CEMEA Region, Nigeria domestic)", "deadline": "2 business days from the Dispute Processing Date" }, { "action": "pre-arbitration attempt", "by": "Acquirer (CEMEA Region, Tanzania domestic)", "deadline": "20 calendar days from the Dispute Processing Date" }, { "action": "pre-arbitration attempt", "by": "Acquirer (Europe Region, Poland domestic ATM Transaction)", "deadline": "20 calendar days from the Dispute Processing Date" }, { "action": "pre-arbitration response (accept or decline)", "by": "Issuer", "deadline": "30 calendar days from the Processing Date of the pre-arbitration attempt" }, { "action": "pre-arbitration response (accept or decline)", "by": "Issuer (CEMEA Region, Tanzania domestic)", "deadline": "10 calendar days from the Processing Date of the pre-arbitration attempt" }, { "action": "arbitration filing", "by": "Acquirer", "deadline": "10 calendar days from the Processing Date of the pre-arbitration response" } ], "applies_to": "All Visa Regions" }, "caveat": "Invalid under 10.2, grouped by Orca: (a) PIN handled properly: the Transaction was correctly processed at an EMV PIN-Compliant Acceptance Device; (b) fraud already on record before the approval, with the same carve-outs as 10.1 (fraud type C or D, or reports about declined Transactions); (c) cash: ATM Cash Disbursement and Emergency Cash Disbursement; (d) channels without a PIN step or with their own rules: Contactless Transaction, Visa Easy Payment Service (VEPS), Mobility and Transport Transaction, Fallback Transaction; (e) other types: Mobile Push Payment Transaction, Visa Commercial Choice Omni Product; (f) a delayed charge flagged with message reason code 3902 and linked to an earlier stay, trip or rental where an Imprint was taken at an EMV PIN-compliant chip reader (VR 11.7.3.3, Table 11-16, ID# 0030241). Day counts are calendar days unless stated, and the processing date of the event that starts a count is not itself counted (VR 11.2.1, ID# 0030211).", "related": [ "visa-dispute:10.1", "visa-dispute:10.3", "visa:return", "visa:liability" ], "basis": { "sources": "Visa Core Rules and Visa Product and Service Rules, 18 April 2026 edition: VR 11.7.3.1 to 11.7.3.6 (ID# 0030239 to 0030244), Tables 11-14 to 11-19; VR 11.7.1 (ID# 0030223); VR 11.2.1 (ID# 0030211); VR 11.2.2, Table 11-1 (ID# 0030212, stage deadlines and country notes); VR 5.10.1.2 (ID# 0003022); VR 11.6.1, Table 11-7 (ID# 0030222, region labels).", "confidence": "high" }, "currency": { "effective_since": "Before the current edition; start not stated in it", "effective_note": "Rules as in the 18 April 2026 edition of the Visa rules. Each rule cited carries its own last-updated month in its ID# footer, which the watch compares edition to edition. The next edition is expected in October 2026 [Inference].", "source_edition": "Visa Core Rules and Visa Product and Service Rules, 18 April 2026 edition (Visa Public), https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf", "source_class": "authoritative_primary", "source_title": "Visa Core Rules and Visa Product and Service Rules, 18 April 2026", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms the 120 calendar day filing deadline from the transaction processing date (Table 11-17, VR 11.7.3.4) and the category 10/11 process cycle: a 30 day pre-arbitration attempt by the acquirer, a 30 day accept-or-decline response by the issuer, and a 10 day arbitration filing by the acquirer, with the Nigeria, Tanzania and Poland domestic variants (Table 11-1, VR 11.2.2). Confirms the group is authorization-category dispute resolution and that categories 10 and 11 have no dispute-response stage." } ] }, "rail_name": "Visa Disputes", "governing_authority": "Visa", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "judgement", "label": "your bank's own terms", "needs": "whose terms decide it: the bank's, the participant's or the scheme's", "detail": "Invalid under 10.2, grouped by Orca: (a) PIN handled properly: the Transaction was correctly processed at an EMV PIN-Compliant Acceptance Device; (b) fraud already on record before the approval, with the same carve-outs as 10.1 (fraud type C or D, or reports about declined Transactions); (c) cash: ATM Cash Disbursement and Emergency Cash Disbursement; (d) channels without a PIN step or with their own rules: Contactless Transaction, Visa Easy Payment Service (VEPS), Mobility and Transport Transaction, Fallback Transaction; (e) other types: Mobile Push Payment Transaction, Visa Commercial Choice Omni Product; (f) a delayed charge flagged with message reason code 3902 and linked to an earlier stay, trip or rental where an Imprint was taken at an EMV PIN-compliant chip reader (VR 11.7.3.3, Table 11-16, ID# 0030241).", "from": "caveat" } ] }, { "uid": "visa-dispute:10.3", "id": "10.3", "rail": "visa-dispute", "kind": "reason-code", "name": "Other Fraud – Card-Present Environment", "group": "authorization", "summary": "Fraud dispute for a key-entered transaction made in person that the cardholder denies. It covers card-present fraud outside the two EMV liability shift conditions.", "triggers": [ "The cardholder denies authorizing or taking part in a key-entered Transaction in a Card-Present Environment" ], "actions": [ "Issuer: before filing, report the Fraud Activity to Visa; no particular fraud type is required (VR 11.7.4.2, ID# 0030246)", "Issuer: certify that the cardholder denies the transaction (VR 11.7.4.5, ID# 0030249)", "Merchant and Acquirer: an Imprint of the card defends the transaction; a pencil rubbing or a photocopy of the card does not count as one (VR 11.7.4.6, Table 11-25 note 1)" ], "retry": { "allowed": true, "rule": "Retry here means the Acquirer's right to contest. Categories 10 and 11 have no dispute response stage: the Acquirer contests with a pre-arbitration attempt, the Issuer accepts it or declines it, and a case still open goes to arbitration filed by the Acquirer (VR 11.2.2, Table 11-1, ID# 0030212). For 10.3 the pre-arbitration attempt may rest on an Imprint of the card, or show that the dispute fails this condition's rules, that the cardholder has withdrawn it, or that the Issuer left out a credit or reversal the merchant had already made, or show that a delayed charge belongs to an earlier stay, trip or rental during which an Imprint was taken. In the US Region the Acquirer may also offer Compelling Evidence; Table 11-6 includes an item for a US domestic key-entered card-present transaction made away from a Chip-Reading Device, where the same card was used in another undisputed transaction or the cardholder's identification ties to the receipt [Inference: which conditions each Table 11-6 item serves is read from the table's column marks, whose layout the extracted text does not show clearly] (VR 11.7.4.6, Table 11-25, ID# 0030250; VR 11.5.1, ID# 0030221). An Acquirer may answer a dispute only once, and a merchant must not put a disputed and returned transaction through again; it may still seek payment from the customer outside the Visa system (VR 11.2.1, ID# 0030211; VR 5.10.1.2, ID# 0003022)." }, "facts": { "return_windows": [ { "action": "dispute", "by": "Issuer", "deadline": "120 calendar days from the Transaction Processing Date" }, { "action": "pre-arbitration attempt", "by": "Acquirer", "deadline": "30 calendar days from the Dispute Processing Date" }, { "action": "pre-arbitration attempt", "by": "Acquirer (CEMEA Region, Nigeria domestic)", "deadline": "2 business days from the Dispute Processing Date" }, { "action": "pre-arbitration attempt", "by": "Acquirer (CEMEA Region, Tanzania domestic)", "deadline": "20 calendar days from the Dispute Processing Date" }, { "action": "pre-arbitration attempt", "by": "Acquirer (Europe Region, Poland domestic ATM Transaction)", "deadline": "20 calendar days from the Dispute Processing Date" }, { "action": "pre-arbitration response (accept or decline)", "by": "Issuer", "deadline": "30 calendar days from the Processing Date of the pre-arbitration attempt" }, { "action": "pre-arbitration response (accept or decline)", "by": "Issuer (CEMEA Region, Tanzania domestic)", "deadline": "10 calendar days from the Processing Date of the pre-arbitration attempt" }, { "action": "arbitration filing", "by": "Acquirer", "deadline": "10 calendar days from the Processing Date of the pre-arbitration response" } ], "applies_to": "All Visa Regions. US Region merchants: a chip-reader fuel dispenser exclusion; US Region Acquirers may use Compelling Evidence at pre-arbitration" }, "caveat": "Invalid under 10.3, grouped by Orca: (a) fraud reporting: the credential was reported as Fraud Activity before the approval (fraud type C or D and reports about declined Transactions aside), or was reported under fraud type 3 (fraudulent application), C (merchant misrepresentation) or D (manipulation of account holder); (b) an imprint exists: an Electronic Imprint, or a delayed charge flagged with message reason code 3902 and linked to an earlier stay, trip or rental with an Electronic Imprint; (c) cash and special types: ATM Cash Disbursement, Emergency Cash Disbursement, Mobile Push Payment Transaction, Mobility and Transport Transaction, Visa Commercial Choice Omni Product; (d) for US Region merchants, an Automated Fuel Dispenser Transaction at a Chip-Reading Device (VR 11.7.4.3, Table 11-22, ID# 0030247). Day counts are calendar days unless stated, and the processing date of the event that starts a count is not itself counted (VR 11.2.1, ID# 0030211).", "related": [ "visa-dispute:10.1", "visa-dispute:10.2", "visa-dispute:10.4", "visa:return", "visa:liability" ], "basis": { "sources": "Visa Core Rules and Visa Product and Service Rules, 18 April 2026 edition: VR 11.7.4.1 to 11.7.4.6 (ID# 0030245 to 0030250), Tables 11-20 to 11-25; VR 11.5.1, Table 11-6 (ID# 0030221); VR 11.7.1 (ID# 0030223); VR 11.2.1 (ID# 0030211); VR 11.2.2, Table 11-1 (ID# 0030212, stage deadlines and country notes); VR 5.10.1.2 (ID# 0003022); VR 11.6.1, Table 11-7 (ID# 0030222, region labels).", "confidence": "high" }, "currency": { "effective_since": "Before the current edition; start not stated in it", "effective_note": "Rules as in the 18 April 2026 edition of the Visa rules. Each rule cited carries its own last-updated month in its ID# footer, which the watch compares edition to edition. The next edition is expected in October 2026 [Inference].", "source_edition": "Visa Core Rules and Visa Product and Service Rules, 18 April 2026 edition (Visa Public), https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf", "source_class": "authoritative_primary", "source_title": "Visa Core Rules and Visa Product and Service Rules, 18 April 2026", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms the 120 calendar day filing deadline from the transaction processing date (Table 11-23, VR 11.7.4.4) and the category 10/11 process cycle: a 30 day pre-arbitration attempt by the acquirer, a 30 day accept-or-decline response by the issuer, and a 10 day arbitration filing by the acquirer, with the Nigeria, Tanzania and Poland domestic variants (Table 11-1, VR 11.2.2). Confirms the group is authorization-category dispute resolution and that categories 10 and 11 have no dispute-response stage." } ] }, "rail_name": "Visa Disputes", "governing_authority": "Visa", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "visa-dispute:10.4", "id": "10.4", "rail": "visa-dispute", "kind": "reason-code", "name": "Other Fraud – Card-Absent Environment", "group": "authorization", "summary": "Fraud dispute for a card-absent transaction (online, mail, phone) that the cardholder denies authorizing or taking part in. Authentication through Visa Secure, certain CVV2 results, fraud history, and a match with the cardholder's earlier undisputed transactions (the rule Visa calls Compelling Evidence 3.0) can make the dispute invalid.", "triggers": [ "The cardholder denies authorizing or taking part in a Transaction in a Card-Absent Environment", "US domestic: for Electronic Commerce Transactions at merchants with MCC 4829, 5967, 6051, 6540, 7801, 7802 or 7995 (money transfer, adult content, crypto and foreign currency or money orders, stored-value loads, online gambling, racing and betting), the dispute is available whatever the Electronic Commerce Indicator value (VR 11.7.5.2, Table 11-27, ID# 0030253)" ], "actions": [ "Issuer: before filing, report the Fraud Activity to Visa (VR 11.7.5.2, ID# 0030253)", "Issuer: certify that the cardholder denies the transaction (VR 11.7.5.5, ID# 0030256)", "Issuer: check the invalid cases below before filing, in particular authentication results, CVV2 results, the 35-dispute limit and the cardholder's earlier undisputed transactions", "Issuer declining a pre-arbitration attempt that carried Compelling Evidence: certify either that the contact details given do not match the cardholder's records, or that the cardholder was contacted, reviewed the evidence and explained why they still dispute; if the evidence is delivery to an address with an AVS result of Y, explain that result (VR 11.2.2, Table 11-1)" ], "retry": { "allowed": true, "rule": "Retry here means the Acquirer's right to contest. Categories 10 and 11 have no dispute response stage: the Acquirer contests with a pre-arbitration attempt, the Issuer accepts it or declines it, and a case still open goes to arbitration filed by the Acquirer (VR 11.2.2, Table 11-1, ID# 0030212). For 10.4 the pre-arbitration attempt may show that the dispute fails this condition's rules, that the cardholder has withdrawn it, or that the Issuer left out a credit or reversal the merchant had already made; or offer Compelling Evidence from Table 11-6 (for example: goods delivered to an address that matched AVS, proof tying the recipient or user of the goods to the cardholder, a household member making the purchase, prior undisputed transactions sharing at least 3 identifiers such as device, IP address, email or login) [Inference: which conditions each Table 11-6 item serves is read from the table's column marks, whose layout the extracted text does not show clearly]; or show that a delayed charge belongs to an earlier stay, trip or rental with an Imprint; or show the history match: the same credential used in 2 earlier transactions not reported as fraud, processed more than 120 and not more than 365 calendar days before, with a detailed description of what was bought and certification of the date it was provided, and with the device ID or fingerprint or the IP address plus at least one more identifier (login ID, full delivery address, device ID or fingerprint, IP address) matching. For an Airline Transaction, evidence that the cardholder's name is on the departed flight's manifest and matches the itinerary also serves (VR 11.7.5.6, Table 11-31, ID# 0030257; VR 11.5.1, ID# 0030221). An Acquirer may answer a dispute only once, and a merchant must not put a disputed and returned transaction through again; it may still seek payment from the customer outside the Visa system (VR 11.2.1, ID# 0030211; VR 5.10.1.2, ID# 0003022)." }, "facts": { "return_windows": [ { "action": "dispute", "by": "Issuer", "deadline": "120 calendar days from the Transaction Processing Date" }, { "action": "pre-arbitration attempt", "by": "Acquirer", "deadline": "30 calendar days from the Dispute Processing Date" }, { "action": "pre-arbitration attempt", "by": "Acquirer (CEMEA Region, Nigeria domestic)", "deadline": "2 business days from the Dispute Processing Date" }, { "action": "pre-arbitration attempt", "by": "Acquirer (CEMEA Region, Tanzania domestic)", "deadline": "20 calendar days from the Dispute Processing Date" }, { "action": "pre-arbitration response (accept or decline)", "by": "Issuer", "deadline": "30 calendar days from the Processing Date of the pre-arbitration attempt" }, { "action": "pre-arbitration response (accept or decline)", "by": "Issuer (CEMEA Region, Tanzania domestic)", "deadline": "10 calendar days from the Processing Date of the pre-arbitration attempt" }, { "action": "arbitration filing", "by": "Acquirer", "deadline": "10 calendar days from the Processing Date of the pre-arbitration response" } ], "applies_to": "All Visa Regions, with region rows: US domestic MCC rights and airline AVS rule; the AVS result U rule for Canada, US and UK domestic (widening on dated changes); Kazakhstan domestic QR rule" }, "caveat": "Invalid under 10.4, grouped by Orca: (a) authenticated: a Secure Electronic Commerce Transaction with ECI 5 where the Issuer confirmed authentication through Visa Secure with EMV 3DS and the CAVV was in the Authorization Request; an ECI 5 transaction on an Authenticated Payment Credential with a TAVV where the Issuer or Token Requestor approved a Cardholder Verification Method; an EMV 3DS attempt (ECI 6) with CAVV where the Issuer or Visa on its behalf gave an Attempt Response, unless the card is a Non-Reloadable Prepaid Card; (b) CVV2: presence indicator 1 with result U (disputes processed on or after 18 April 2026), or presence indicator 1 with result N and the request approved anyway; (c) fraud history: the credential was reported as Fraud Activity before the approval (types C and D and declined-transaction reports aside), or was reported under fraud type 3, C or D; (d) volume: the Issuer has filed more than 35 disputes on the account in the previous 120 calendar days (clearings with a Multiple Clearing Sequence Number from one authorization count as one; Brazil domestic Installment Transactions are counted from the original authorization); (e) history match (Compelling Evidence 3.0, disputes processed through 23 October 2026): same credential used in 2 earlier transactions not reported as fraud, processed more than 120 and not more than 365 calendar days before the dispute (the current text does not say from which date the 120 days run [Inference: the dispute]; the 120 does not apply if the earlier transactions were Original Credit Transactions), with a detailed description of what was bought (or, for Visa Secure ECI 7 transactions with CAVV, a purchase order number) and the device ID or fingerprint or the IP address plus one more identifier matching, each identifier meeting Visa's format rules such as clear text and minimum lengths; (f) types outside the condition: Emergency Cash Disbursement, Straight Through Processing Transaction, Mobile Push Payment Transaction, Visa Commercial Choice Omni Product, urban mobility and Known Fare debt recovery (Transactions on or after 18 April 2026), a delayed charge flagged with message reason code 3902 and linked to an earlier stay with an Electronic Imprint; (g) crypto and NFT purchases the cardholder made but says they were tricked into sending to a fraudster; (h) region rows: US domestic airline or passenger rail tickets where AVS returned Y and tickets were mailed to the billing address, or the Issuer was not in AVS that day; domestic transactions with an authorization where the Acquirer attempted AVS and received result code U [Inference: the extracted text runs U into the note marker 7, and note 7 sets the card-type exception], in Canada, the US and the UK (not where the Issuer could not answer the AVS request because the card was a Visa Commercial Card or a non-reloadable Prepaid Card); Kazakhstan domestic card-absent transactions started by reading a QR code with terminal entry capability code 3 (VR 11.7.5.3, Table 11-28, ID# 0030254). Day counts are calendar days unless stated, and the processing date of the event that starts a count is not itself counted (VR 11.2.1, ID# 0030211).", "related": [ "visa-dispute:10.1", "visa-dispute:10.3", "visa-dispute:10.5", "visa-dispute:13.1", "visa:return", "visa:liability", "visa:limits", "paypal-dispute:UNAUTHORISED" ], "basis": { "sources": "Visa Core Rules and Visa Product and Service Rules, 18 April 2026 edition: VR 11.7.5.1 to 11.7.5.6 (ID# 0030252 to 0030257), Tables 11-26 to 11-31, including the dated rows effective through 23 October 2026 and from 24 October 2026 and 24 April 2027; VR 11.5.1, Table 11-6 (ID# 0030221); VR 11.7.1 (ID# 0030223); Summary of Changes pp. 48 and 51 (Compelling Evidence 3.0 update, AVS liability shift in selected countries); VR 11.2.1 (ID# 0030211); VR 11.2.2, Table 11-1 (ID# 0030212, stage deadlines and country notes); VR 5.10.1.2 (ID# 0003022); VR 11.6.1, Table 11-7 (ID# 0030222, region labels).", "confidence": "high" }, "currency": { "effective_since": "Before the current edition; start not stated in it", "effective_note": "Rules as in the 18 April 2026 edition (ID# 0030254 and 0030257 last updated Apr 2026). Known dated changes, by the date a dispute is processed: from 2026-10-24 the history match widens: the earlier transactions may be at one or more merchants on the same card or a credential linked to it, the 120 days count back from when the dispute was submitted, login IDs for an Agentic Payment Provider count, a purchase order number may also stand in for the description on Visa Token Service (TAVV) and Visa Intelligent Data Exchange transactions with ECI 7, device ID and device fingerprint count as one element, and at pre-arbitration an Acquirer may submit only transaction data it accepted and processed; the widened rule does not apply in Chile. Also from 2026-10-24 the AVS result U rule moves from the UK alone to the whole Europe Region and starts for Argentina, Brazil, Mexico, Paraguay, Peru, Puerto Rico and Uruguay. From 2027-04-24 the AVS result U rule starts for Australia, New Zealand and Singapore. Under the dated-id procedure the watch renames this record 10.4@2026-10-24 and drafts a new 10.4 once the first change is in force, and repeats this for 2027-04-24.", "source_edition": "Visa Core Rules and Visa Product and Service Rules, 18 April 2026 edition (Visa Public), https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf", "source_class": "authoritative_primary", "source_title": "Visa Core Rules and Visa Product and Service Rules, 18 April 2026", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms the 120 calendar day filing deadline from the transaction processing date (Table 11-29, VR 11.7.5.4) and the category 10/11 process cycle: a 30 day pre-arbitration attempt by the acquirer, a 30 day accept-or-decline response by the issuer, and a 10 day arbitration filing by the acquirer, with the Nigeria and Tanzania domestic variants (Table 11-1, VR 11.2.2). The Summary of Changes at page 48 confirms the Compelling Evidence 3.0 widening for this condition takes effect for disputes processed on or after 24 October 2026 (VR 11.7.5.3, 11.7.5.6). Confirms the group is authorization-category dispute resolution and that categories 10 and 11 have no dispute-response stage." } ] }, "rail_name": "Visa Disputes", "governing_authority": "Visa", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "visa-dispute:10.5", "id": "10.5", "rail": "visa-dispute", "kind": "reason-code", "name": "Visa Fraud Monitoring Program", "group": "authorization", "summary": "Fraud dispute that Visa opens for the Issuer: Visa tells the Issuer that the Visa Fraud Monitoring Program flagged a transaction, and the Issuer may dispute it if no other condition has already succeeded. It is the only condition under which a transaction already disputed may be disputed again.", "triggers": [ "Visa notified the Issuer that the Visa Fraud Monitoring Program identified the Transaction", "The Issuer has not already won a dispute on the Transaction under another condition" ], "actions": [ "Issuer: file within 120 calendar days of the date of the program report, not of the transaction", "Acquirer: contest only on the narrow grounds below" ], "retry": { "allowed": true, "rule": "Retry here means the Acquirer's right to contest. Categories 10 and 11 have no dispute response stage: the Acquirer contests with a pre-arbitration attempt, the Issuer accepts it or declines it, and a case still open goes to arbitration filed by the Acquirer (VR 11.2.2, Table 11-1, ID# 0030212). For 10.5 the pre-arbitration attempt may only show that the dispute is invalid or that the Issuer left out a credit or reversal the merchant had already made (VR 11.7.6.4, Table 11-35, ID# 0030260). An Acquirer may answer a dispute only once, and a merchant must not put a disputed and returned transaction through again; it may still seek payment from the customer outside the Visa system (VR 11.2.1, ID# 0030211; VR 5.10.1.2, ID# 0003022)." }, "facts": { "return_windows": [ { "action": "dispute", "by": "Issuer", "deadline": "120 calendar days from the date of the Visa Fraud Monitoring Program report" }, { "action": "pre-arbitration attempt", "by": "Acquirer", "deadline": "30 calendar days from the Dispute Processing Date" }, { "action": "pre-arbitration attempt", "by": "Acquirer (CEMEA Region, Nigeria domestic)", "deadline": "2 business days from the Dispute Processing Date" }, { "action": "pre-arbitration attempt", "by": "Acquirer (CEMEA Region, Tanzania domestic)", "deadline": "20 calendar days from the Dispute Processing Date" }, { "action": "pre-arbitration attempt", "by": "Acquirer (Europe Region, Poland domestic ATM Transaction)", "deadline": "20 calendar days from the Dispute Processing Date" }, { "action": "pre-arbitration response (accept or decline)", "by": "Issuer", "deadline": "30 calendar days from the Processing Date of the pre-arbitration attempt" }, { "action": "pre-arbitration response (accept or decline)", "by": "Issuer (CEMEA Region, Tanzania domestic)", "deadline": "10 calendar days from the Processing Date of the pre-arbitration attempt" }, { "action": "arbitration filing", "by": "Acquirer", "deadline": "10 calendar days from the Processing Date of the pre-arbitration response" } ], "applies_to": "All Visa Regions" }, "caveat": "Visa lists no invalid-dispute cases for 10.5 (VR 11.7.6.2, Table 11-33, ID# 0030626). The general bar on disputing a transaction more than once does not apply to 10.5 (VR 11.2.1). How a transaction enters the Visa Fraud Monitoring Program, and the program's thresholds, are not set out in the dispute rules [Unverified]. Day counts are calendar days unless stated, and the processing date of the event that starts a count is not itself counted (VR 11.2.1, ID# 0030211).", "related": [ "visa-dispute:10.4", "visa:return", "visa:liability" ], "basis": { "sources": "Visa Core Rules and Visa Product and Service Rules, 18 April 2026 edition: VR 11.7.6.1 to 11.7.6.4 (ID# 0030258, 0030626, 0030259, 0030260), Tables 11-32 to 11-35; VR 11.2.1 (ID# 0030211); VR 11.2.2, Table 11-1 (ID# 0030212, stage deadlines and country notes); VR 5.10.1.2 (ID# 0003022); VR 11.6.1, Table 11-7 (ID# 0030222, region labels).", "confidence": "high" }, "currency": { "effective_since": "Before the current edition; start not stated in it", "effective_note": "Rules as in the 18 April 2026 edition of the Visa rules. Each rule cited carries its own last-updated month in its ID# footer, which the watch compares edition to edition. The next edition is expected in October 2026 [Inference].", "source_edition": "Visa Core Rules and Visa Product and Service Rules, 18 April 2026 edition (Visa Public), https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf", "source_class": "authoritative_primary", "source_title": "Visa Core Rules and Visa Product and Service Rules, 18 April 2026", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms the 120 calendar day filing deadline from the date of the Visa Fraud Monitoring Program report (Table 11-34, VR 11.7.6.3) and the category 10/11 process cycle: a 30 day pre-arbitration attempt by the acquirer, a 30 day accept-or-decline response by the issuer, and a 10 day arbitration filing by the acquirer, with the Nigeria, Tanzania and Poland domestic variants (Table 11-1, VR 11.2.2). Confirms the group is authorization-category dispute resolution and that categories 10 and 11 have no dispute-response stage." } ] }, "rail_name": "Visa Disputes", "governing_authority": "Visa", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "visa-dispute:11.1", "id": "11.1", "rail": "visa-dispute", "kind": "reason-code", "name": "Card Recovery Bulletin", "group": "authorization", "summary": "Authorization dispute for a sale below the merchant's Floor Limit, taken without authorization, on an account that the Card Recovery Bulletin listed for the merchant's Visa Region that day. It applies only to disputes processed through 23 October 2026, and the rules name no successor.", "triggers": [ "No authorization was sought because the amount was under the Merchant's Floor Limit", "On the Transaction Date the account was in the Card Recovery Bulletin for the Visa Region where the Merchant Outlet is; a blocked BIN counts even if the account itself is not listed", "If the Clearing Record has no Transaction Date, a listing within the 10 calendar days before the Transaction Processing Date counts" ], "actions": [ "Issuer: file within 75 calendar days of the Transaction Processing Date, and only for disputes processed through 23 October 2026", "Acquirer at a car rental, cruise line or lodging merchant with several authorizations: show the account was not listed on the rental, embarkation or check-in date" ], "retry": { "allowed": true, "rule": "Retry here means the Acquirer's right to contest. Categories 10 and 11 have no dispute response stage: the Acquirer contests with a pre-arbitration attempt, the Issuer accepts it or declines it, and a case still open goes to arbitration filed by the Acquirer (VR 11.2.2, Table 11-1, ID# 0030212). For 11.1 the pre-arbitration attempt may show that the dispute is invalid or that the Issuer left out a merchant credit or reversal, or, for a car rental, cruise line or lodging merchant with several authorizations, that the account was not listed on the relevant start date (VR 11.8.1.4, Table 11-39, ID# 0030264). An Acquirer may answer a dispute only once, and a merchant must not put a disputed and returned transaction through again; it may still seek payment from the customer outside the Visa system (VR 11.2.1, ID# 0030211; VR 5.10.1.2, ID# 0003022)." }, "facts": { "return_windows": [ { "action": "dispute", "by": "Issuer", "deadline": "75 calendar days from the Transaction Processing Date (disputes processed through 23 October 2026 only)" }, { "action": "pre-arbitration attempt", "by": "Acquirer", "deadline": "30 calendar days from the Dispute Processing Date" }, { "action": "pre-arbitration attempt", "by": "Acquirer (CEMEA Region, Nigeria domestic)", "deadline": "2 business days from the Dispute Processing Date" }, { "action": "pre-arbitration attempt", "by": "Acquirer (CEMEA Region, Tanzania domestic)", "deadline": "20 calendar days from the Dispute Processing Date" }, { "action": "pre-arbitration attempt", "by": "Acquirer (Europe Region, Poland domestic ATM Transaction)", "deadline": "20 calendar days from the Dispute Processing Date" }, { "action": "pre-arbitration response (accept or decline)", "by": "Issuer", "deadline": "30 calendar days from the Processing Date of the pre-arbitration attempt" }, { "action": "pre-arbitration response (accept or decline)", "by": "Issuer (CEMEA Region, Tanzania domestic)", "deadline": "10 calendar days from the Processing Date of the pre-arbitration attempt" }, { "action": "arbitration filing", "by": "Acquirer", "deadline": "10 calendar days from the Processing Date of the pre-arbitration response" } ], "applies_to": "All Visa Regions, for disputes processed through 23 October 2026" }, "caveat": "Invalid under 11.1, grouped by Orca: (a) covered by chip rules instead: a Transaction at a Chip-Reading Device that qualifies for the EMV liability shift; (b) device or type: a Contactless-Only Acceptance Device, an ATM Cash Disbursement, a Mobile Push Payment Transaction (VR 11.8.1.2, Table 11-37, ID# 0030262). A T&E Transaction may be disputed under this condition only if the Transaction amount or the partial Dispute amount is at least USD 25 or the local equivalent; the minimum does not apply to Brazil domestic Installment Transactions (VR 11.4.3, Table 11-5, ID# 0030219). Day counts are calendar days unless stated, and the processing date of the event that starts a count is not itself counted (VR 11.2.1, ID# 0030211).", "related": [ "visa-dispute:11.2", "visa-dispute:11.3", "visa:return" ], "basis": { "sources": "Visa Core Rules and Visa Product and Service Rules, 18 April 2026 edition: VR 11.8.1.1 to 11.8.1.4 (ID# 0030261 to 0030264), Tables 11-36 to 11-39, each limited to disputes processed through 23 October 2026; VR 11.4.3, Table 11-5 (ID# 0030219); VR 11.2.1 (ID# 0030211); VR 11.2.2, Table 11-1 (ID# 0030212, stage deadlines and country notes); VR 5.10.1.2 (ID# 0003022); VR 11.6.1, Table 11-7 (ID# 0030222, region labels).", "confidence": "high" }, "currency": { "effective_since": "Before the current edition; start not stated in it", "effective_note": "Rules as in the 18 April 2026 edition; every 11.1 rule (ID# 0030261 to 0030264, last updated Oct 2025) is limited to disputes processed through 23 October 2026, and the edition names no replacement condition. Under the dated-id procedure the watch retires this record on 2026-10-24 (status superseded, superseded_by null).", "source_edition": "Visa Core Rules and Visa Product and Service Rules, 18 April 2026 edition (Visa Public), https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf", "source_class": "authoritative_primary", "source_title": "Visa Core Rules and Visa Product and Service Rules, 18 April 2026", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms the 75 calendar day filing deadline from the transaction processing date, limited to disputes processed through 23 October 2026 with no successor named (Table 11-38, VR 11.8.1.3), and the category 10/11 process cycle: a 30 day pre-arbitration attempt by the acquirer, a 30 day accept-or-decline response by the issuer, and a 10 day arbitration filing by the acquirer, with the Nigeria, Tanzania and Poland domestic variants (Table 11-1, VR 11.2.2). Confirms the USD 25 T&E minimum applies to this condition (Table 11-5, VR 11.4.3), with the Brazil domestic Installment Transaction carve-out. Confirms the group is authorization-category dispute resolution." } ] }, "rail_name": "Visa Disputes", "governing_authority": "Visa", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "visa-dispute:11.2", "id": "11.2", "rail": "visa-dispute", "kind": "reason-code", "name": "Declined Authorization", "group": "authorization", "summary": "Authorization dispute for a sale the merchant completed even though its Authorization Request received a Decline Response or a Pickup Response.", "triggers": [ "An Authorization Request received a Decline Response or Pickup Response and the merchant completed the Transaction anyway", "Mobility and Transport: the full amount is disputable when a Decline Response was sent and the amount exceeded the limit set in VR 5.8.19.2 (VR 11.8.2.2, Table 11-41, ID# 0030266)" ], "actions": [ "Issuer: certify that on the Dispute Processing Date the account was flagged as closed, as a credit problem, or as fraud; the fraud flag does not serve for an ATM Deposit Adjustment (VR 11.8.2.5, Table 11-44, ID# 0031081)", "Merchant: do not complete a sale after a decline; a later approval for the same purchase makes the dispute invalid unless the decline was a pickup response" ], "retry": { "allowed": true, "rule": "Retry here means the Acquirer's right to contest. Categories 10 and 11 have no dispute response stage: the Acquirer contests with a pre-arbitration attempt, the Issuer accepts it or declines it, and a case still open goes to arbitration filed by the Acquirer (VR 11.2.2, Table 11-1, ID# 0030212). For 11.2 the pre-arbitration attempt may show that the dispute is invalid, that the Issuer left out a merchant credit or reversal, or that the Transaction was Chip-initiated and approved offline; for a car rental, cruise line or lodging merchant with several authorizations, the Acquirer certifies the start and end dates and the date, amount and Authorization Code of each approval (VR 11.8.2.6, Table 11-45, ID# 0030269). An Acquirer may answer a dispute only once, and a merchant must not put a disputed and returned transaction through again; it may still seek payment from the customer outside the Visa system (VR 11.2.1, ID# 0030211; VR 5.10.1.2, ID# 0003022)." }, "facts": { "return_windows": [ { "action": "dispute", "by": "Issuer", "deadline": "75 calendar days from the Transaction Processing Date" }, { "action": "pre-arbitration attempt", "by": "Acquirer", "deadline": "30 calendar days from the Dispute Processing Date" }, { "action": "pre-arbitration attempt", "by": "Acquirer (CEMEA Region, Nigeria domestic)", "deadline": "2 business days from the Dispute Processing Date" }, { "action": "pre-arbitration attempt", "by": "Acquirer (CEMEA Region, Tanzania domestic)", "deadline": "20 calendar days from the Dispute Processing Date" }, { "action": "pre-arbitration attempt", "by": "Acquirer (Europe Region, Poland domestic ATM Transaction)", "deadline": "20 calendar days from the Dispute Processing Date" }, { "action": "pre-arbitration response (accept or decline)", "by": "Issuer", "deadline": "30 calendar days from the Processing Date of the pre-arbitration attempt" }, { "action": "pre-arbitration response (accept or decline)", "by": "Issuer (CEMEA Region, Tanzania domestic)", "deadline": "10 calendar days from the Processing Date of the pre-arbitration attempt" }, { "action": "arbitration filing", "by": "Acquirer", "deadline": "10 calendar days from the Processing Date of the pre-arbitration response" } ], "applies_to": "All Visa Regions" }, "caveat": "Invalid under 11.2: an approval obtained later for the same purchase after a Decline Response, except where the decline was Pickup Response 04, 07, 41 or 43, which a later approval does not cure; an ATM Cash Disbursement; a Mobile Push Payment Transaction (VR 11.8.2.3, Table 11-42, ID# 0030267). A T&E Transaction may be disputed under this condition only if the Transaction amount or the partial Dispute amount is at least USD 25 or the local equivalent; the minimum does not apply to Brazil domestic Installment Transactions (VR 11.4.3, Table 11-5, ID# 0030219). Day counts are calendar days unless stated, and the processing date of the event that starts a count is not itself counted (VR 11.2.1, ID# 0030211).", "related": [ "visa-dispute:11.1", "visa-dispute:11.3", "visa:return", "visa-decline:04", "visa-decline:07", "visa-decline:41", "visa-decline:43", "visa-decline:51", "visa-decline:59" ], "basis": { "sources": "Visa Core Rules and Visa Product and Service Rules, 18 April 2026 edition: VR 11.8.2.1 to 11.8.2.6 (ID# 0030265, 0030266, 0030267, 0030268, 0031081, 0030269), Tables 11-40 to 11-45; VR 11.4.3, Table 11-5 (ID# 0030219); VR 11.2.1 (ID# 0030211); VR 11.2.2, Table 11-1 (ID# 0030212, stage deadlines and country notes); VR 5.10.1.2 (ID# 0003022); VR 11.6.1, Table 11-7 (ID# 0030222, region labels).", "confidence": "high" }, "currency": { "effective_since": "Before the current edition; start not stated in it", "effective_note": "Rules as in the 18 April 2026 edition of the Visa rules. Each rule cited carries its own last-updated month in its ID# footer, which the watch compares edition to edition. The next edition is expected in October 2026 [Inference].", "source_edition": "Visa Core Rules and Visa Product and Service Rules, 18 April 2026 edition (Visa Public), https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf", "source_class": "authoritative_primary", "source_title": "Visa Core Rules and Visa Product and Service Rules, 18 April 2026", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms the 75 calendar day filing deadline from the transaction processing date (Table 11-43, VR 11.8.2.4) and the category 10/11 process cycle: a 30 day pre-arbitration attempt by the acquirer, a 30 day accept-or-decline response by the issuer, and a 10 day arbitration filing by the acquirer, with the Nigeria, Tanzania and Poland domestic variants (Table 11-1, VR 11.2.2). Confirms the invalid-dispute carve-out for pickup response codes 04, 07, 41 and 43 (Table 11-42, VR 11.8.2.3) and the USD 25 T&E minimum with the Brazil Installment carve-out (Table 11-5, VR 11.4.3). Confirms the group is authorization-category dispute resolution." } ] }, "rail_name": "Visa Disputes", "governing_authority": "Visa", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "visa-dispute:11.3", "id": "11.3", "rail": "visa-dispute", "kind": "reason-code", "name": "No Authorization/Late Presentment", "group": "authorization", "summary": "Authorization dispute where a required authorization was never obtained, or the transaction reached clearing later than Visa's timeframes allow; it also covers late ATM adjustments posted to accounts flagged closed, credit problem or fraud.", "triggers": [ "A valid authorization was required (VR 5.7.3.4, 7.5.6) and not obtained", "The Transaction was processed after the timeframe in VR 5.7.3.5 and 7.5.6, whether or not an authorization was obtained or needed", "A Chip-initiated Transaction whose Clearing Record carried an ARQC but which the Issuer or its agent never authorized online", "ATM adjustments: an ATM Deposit adjustment posted to a closed or credit-problem account more than 10 days after the Transaction Date; an ATM Cash Disbursement adjustment posted to a closed, credit-problem or fraud account more than 10 days after (4 days for India domestic, 3 days for Nepal domestic; in the US, also PIN-Authenticated Visa Debit adjustments)" ], "actions": [ "Issuer: certify that on the Dispute Processing Date the account was flagged as closed, as a credit problem, or as fraud; the fraud flag does not serve for an ATM Deposit Adjustment (VR 11.8.3.5, Table 11-50, ID# 0031082)", "Issuer: limit the amount to the part above the Floor Limit for a chip offline approval, and to the unauthorized part when an authorization covered less than the full amount (VR 11.8.3.2, Table 11-47, ID# 0030271)" ], "retry": { "allowed": true, "rule": "Retry here means the Acquirer's right to contest. Categories 10 and 11 have no dispute response stage: the Acquirer contests with a pre-arbitration attempt, the Issuer accepts it or declines it, and a case still open goes to arbitration filed by the Acquirer (VR 11.2.2, Table 11-1, ID# 0030212). For 11.3 the pre-arbitration attempt may show that the dispute is invalid or that the Issuer left out a merchant credit or reversal, or prove that the Clearing Record carried a wrong Transaction Date and a valid authorization existed, backed by a receipt or record; where an estimated authorization and incremental authorizations shared one Transaction Identifier and cleared in time, the Acquirer certifies the start and completion dates and each approval's date, amount and code (VR 11.8.3.6, Table 11-51, ID# 0030274). An Acquirer may answer a dispute only once, and a merchant must not put a disputed and returned transaction through again; it may still seek payment from the customer outside the Visa system (VR 11.2.1, ID# 0030211; VR 5.10.1.2, ID# 0003022)." }, "facts": { "return_windows": [ { "action": "dispute", "by": "Issuer", "deadline": "75 calendar days from the Transaction Processing Date" }, { "action": "dispute", "by": "Issuer (US domestic)", "deadline": "For an Adjustment of an ATM Cash Disbursement or a PIN-Authenticated Visa Debit Transaction, 75 calendar days from the Transaction Date of the Adjustment" }, { "action": "dispute", "by": "Issuer (India domestic and Nepal domestic)", "deadline": "For an Adjustment of an ATM Cash Disbursement, 75 calendar days from the Transaction Date of the Adjustment" }, { "action": "pre-arbitration attempt", "by": "Acquirer", "deadline": "30 calendar days from the Dispute Processing Date" }, { "action": "pre-arbitration attempt", "by": "Acquirer (CEMEA Region, Nigeria domestic)", "deadline": "2 business days from the Dispute Processing Date" }, { "action": "pre-arbitration attempt", "by": "Acquirer (CEMEA Region, Tanzania domestic)", "deadline": "20 calendar days from the Dispute Processing Date" }, { "action": "pre-arbitration attempt", "by": "Acquirer (Europe Region, Poland domestic ATM Transaction)", "deadline": "20 calendar days from the Dispute Processing Date" }, { "action": "pre-arbitration response (accept or decline)", "by": "Issuer", "deadline": "30 calendar days from the Processing Date of the pre-arbitration attempt" }, { "action": "pre-arbitration response (accept or decline)", "by": "Issuer (CEMEA Region, Tanzania domestic)", "deadline": "10 calendar days from the Processing Date of the pre-arbitration attempt" }, { "action": "arbitration filing", "by": "Acquirer", "deadline": "10 calendar days from the Processing Date of the pre-arbitration response" } ], "applies_to": "All Visa Regions, with ATM adjustment rows for India, Nepal and US domestic and a Europe exclusion for Visa Drive extra cards" }, "caveat": "Invalid under 11.3: a Mobile Push Payment Transaction; a Credit Transaction lacking a required authorization at airline, commuter and ferry, passenger rail or bus merchants (MCC 3000 to 3350, 4111, 4112, 4131, 4511); in the Europe Region, a transaction lacking a required authorization on a Visa Drive Card extra card with a Privately Contracted Agreement at tolls (MCC 4784) or parking (MCC 7523) (VR 11.8.3.3, Table 11-48, ID# 0030272). Brazil domestic Installment Transactions carry a note on the time limit tied to the period between approval and the first installment; its effect is not clear from the text [Unverified]. A T&E Transaction may be disputed under this condition only if the Transaction amount or the partial Dispute amount is at least USD 25 or the local equivalent; the minimum does not apply to Brazil domestic Installment Transactions (VR 11.4.3, Table 11-5, ID# 0030219). Day counts are calendar days unless stated, and the processing date of the event that starts a count is not itself counted (VR 11.2.1, ID# 0030211).", "related": [ "visa-dispute:11.1", "visa-dispute:11.2", "visa-dispute:12.7", "visa:return" ], "basis": { "sources": "Visa Core Rules and Visa Product and Service Rules, 18 April 2026 edition: VR 11.8.3.1 to 11.8.3.6 (ID# 0030270 to 0030274, 0031082), Tables 11-46 to 11-51; VR 11.4.3, Table 11-5 (ID# 0030219); VR 11.2.1 (ID# 0030211); VR 11.2.2, Table 11-1 (ID# 0030212, stage deadlines and country notes); VR 5.10.1.2 (ID# 0003022); VR 11.6.1, Table 11-7 (ID# 0030222, region labels).", "confidence": "high" }, "currency": { "effective_since": "Before the current edition; start not stated in it", "effective_note": "Rules as in the 18 April 2026 edition of the Visa rules. Each rule cited carries its own last-updated month in its ID# footer, which the watch compares edition to edition. The next edition is expected in October 2026 [Inference].", "source_edition": "Visa Core Rules and Visa Product and Service Rules, 18 April 2026 edition (Visa Public), https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf", "source_class": "authoritative_primary", "source_title": "Visa Core Rules and Visa Product and Service Rules, 18 April 2026", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms the 75 calendar day filing deadline from the transaction processing date, with the US, India and Nepal domestic ATM and PIN-debit adjustment variant counting from the adjustment date instead (Table 11-49, VR 11.8.3.4), and the category 10/11 process cycle: a 30 day pre-arbitration attempt by the acquirer, a 30 day accept-or-decline response by the issuer, and a 10 day arbitration filing by the acquirer, with the Nigeria, Tanzania and Poland domestic variants (Table 11-1, VR 11.2.2). Confirms the USD 25 T&E minimum with the Brazil Installment carve-out (Table 11-5, VR 11.4.3). Confirms the group is authorization-category dispute resolution." } ] }, "rail_name": "Visa Disputes", "governing_authority": "Visa", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "visa-dispute:12.2", "id": "12.2", "rail": "visa-dispute", "kind": "reason-code", "name": "Incorrect Transaction Code", "group": "administrative", "summary": "Processing-error dispute where a transaction went through as the wrong type: a credit posted as a debit, a debit posted as a credit, or a credit refund used where a Reversal or Adjustment was due, leaving the cardholder short after exchange-rate movement.", "triggers": [ "A debit was processed as a credit, or a credit as a debit", "The merchant issued a credit refund instead of a Reversal or an Adjustment, and the exchange-rate difference left the cardholder with less than the full amount back" ], "actions": [ "Issuer: for a reversed-direction error, dispute twice the Transaction amount; this is the one condition where a dispute may exceed the Transaction amount (VR 11.9.1.2, Table 11-53, ID# 0030281; VR 11.4.1, ID# 0030217)", "Issuer: for a refund used instead of a reversal, dispute only the gap between the refund and the original debit, explain why the refund was an error, and give the dates of the original and the credit (VR 11.9.1.5, Table 11-56, ID# 0030283)" ], "retry": { "allowed": true, "rule": "Retry here means the Acquirer's right to contest. The Acquirer answers with a dispute response; the Issuer may reply with a pre-arbitration attempt, the Acquirer accepts it or declines it, and a case still open goes to arbitration filed by the Issuer (VR 11.2.3, Table 11-2, ID# 0030213). For 12.2 the dispute response may, for a wrong-direction error, prove with a receipt or other record that the Transaction code was right or show an unaddressed merchant credit or reversal; for a refund used instead of a reversal, it may show an unaddressed reversal or give the reason a credit was used (VR 11.9.1.6, Table 11-57, ID# 0030284). An Acquirer may answer a dispute only once, and a merchant must not put a disputed and returned transaction through again; it may still seek payment from the customer outside the Visa system (VR 11.2.1, ID# 0030211; VR 5.10.1.2, ID# 0003022)." }, "facts": { "return_windows": [ { "action": "dispute", "by": "Issuer", "deadline": "120 calendar days from the Transaction Processing Date, or, for a credit refund processed instead of a Reversal or Adjustment, from the Processing Date of that credit refund" }, { "action": "dispute response", "by": "Acquirer", "deadline": "30 calendar days from the Dispute Processing Date" }, { "action": "dispute response", "by": "Acquirer (CEMEA Region, Nigeria domestic)", "deadline": "2 business days from the Dispute Processing Date" }, { "action": "dispute response", "by": "Acquirer (CEMEA Region, Tanzania domestic)", "deadline": "20 calendar days from the Dispute Processing Date" }, { "action": "pre-arbitration attempt", "by": "Issuer", "deadline": "30 calendar days from the Dispute Response Processing Date" }, { "action": "pre-arbitration attempt", "by": "Issuer (CEMEA Region, Tanzania domestic)", "deadline": "10 calendar days from the Dispute Response Processing Date" }, { "action": "pre-arbitration response (accept or decline)", "by": "Acquirer", "deadline": "30 calendar days from the Processing Date of the pre-arbitration attempt" }, { "action": "pre-arbitration response (accept or decline)", "by": "Acquirer (CEMEA Region, Tanzania domestic)", "deadline": "10 calendar days from the Processing Date of the pre-arbitration attempt" }, { "action": "arbitration filing", "by": "Issuer", "deadline": "10 calendar days from the Processing Date of the pre-arbitration response" } ], "applies_to": "All Visa Regions" }, "caveat": "The only invalid case listed is a Mobile Push Payment Transaction (VR 11.9.1.3, Table 11-54, ID# 0030551). A T&E Transaction may be disputed under this condition only if the Transaction amount or the partial Dispute amount is at least USD 25 or the local equivalent; the minimum does not apply to Brazil domestic Installment Transactions (VR 11.4.3, Table 11-5, ID# 0030219). Day counts are calendar days unless stated, and the processing date of the event that starts a count is not itself counted (VR 11.2.1, ID# 0030211).", "related": [ "visa-dispute:12.5", "visa-dispute:13.6", "visa:return" ], "basis": { "sources": "Visa Core Rules and Visa Product and Service Rules, 18 April 2026 edition: VR 11.9.1.1 to 11.9.1.6 (ID# 0030280, 0030281, 0030551, 0030282, 0030283, 0030284), Tables 11-52 to 11-57; VR 11.4.1 (ID# 0030217); VR 11.4.3, Table 11-5 (ID# 0030219); VR 11.2.1 (ID# 0030211); VR 11.2.3, Table 11-2 (ID# 0030213, stage deadlines and country notes); VR 5.10.1.2 (ID# 0003022); VR 11.6.1, Table 11-7 (ID# 0030222, region labels).", "confidence": "high" }, "currency": { "effective_since": "Before the current edition; start not stated in it", "effective_note": "Rules as in the 18 April 2026 edition of the Visa rules. Each rule cited carries its own last-updated month in its ID# footer, which the watch compares edition to edition. The next edition is expected in October 2026 [Inference].", "source_edition": "Visa Core Rules and Visa Product and Service Rules, 18 April 2026 edition (Visa Public), https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf", "source_class": "authoritative_primary", "source_title": "Visa Core Rules and Visa Product and Service Rules, 18 April 2026", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms the 120 calendar day filing deadline from the transaction processing date or, where a credit refund was processed instead of a reversal or adjustment, from the credit refund's processing date (Table 11-55, VR 11.9.1.4), and the category 12/13 process cycle: a 30 day dispute response by the acquirer, a 30 day pre-arbitration attempt by the issuer, a 30 day pre-arbitration response by the acquirer, and a 10 day arbitration filing by the issuer, with the Egypt, India, Nigeria, Poland and Tanzania domestic variants (Table 11-2, VR 11.2.3). Confirms the USD 25 T&E minimum with the Brazil Installment carve-out (Table 11-5, VR 11.4.3). Confirms the group is administrative-category dispute resolution." } ] }, "rail_name": "Visa Disputes", "governing_authority": "Visa", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "visa-dispute:12.3", "id": "12.3", "rail": "visa-dispute", "kind": "reason-code", "name": "Incorrect Currency", "group": "administrative", "summary": "Processing-error dispute where the currency sent through VisaNet differs from the Transaction Currency, or Dynamic Currency Conversion was applied without the cardholder's express agreement or after the cardholder was denied the choice of the local currency.", "triggers": [ "The currency transmitted through VisaNet is not the Transaction Currency", "DCC was applied although the cardholder did not expressly agree, or the cardholder was not allowed to pay in the merchant's, branch's or ATM's local currency or the ATM currency selected" ], "actions": [ "Issuer: dispute the entire Transaction amount (VR 11.9.2.2, Table 11-59, ID# 0030286)", "Issuer: certify the correct currency code, or that the cardholder made no active choice of DCC or was refused the local currency (VR 11.9.2.5, Table 11-62, ID# 0030289)", "Acquirer without proof of DCC agreement: either respond in the local currency for the amount before conversion, leaving out DCC fees and commission, or present the transaction again as a first Presentment and accept the risk of a late-presentment dispute (VR 11.9.2.6, Table 11-63, ID# 0030290)" ], "retry": { "allowed": true, "rule": "Retry here means the Acquirer's right to contest. The Acquirer answers with a dispute response; the Issuer may reply with a pre-arbitration attempt, the Acquirer accepts it or declines it, and a case still open goes to arbitration filed by the Issuer (VR 11.2.3, Table 11-2, ID# 0030213). For 12.3 the dispute response may prove with a receipt or record that the currency was right, or show that the dispute fails this condition's rules, that the cardholder has withdrawn it, or that the Issuer left out a credit or reversal the merchant had already made. For DCC, a response in the local currency needs certification that the merchant is registered for DCC and a receipt in that currency; a response in the DCC currency needs proof of the cardholder's express agreement, a receipt, and certification that the device makes the cardholder choose DCC electronically. An Issuer pre-arbitration attempt on a DCC transaction is limited to the difference between what was charged and what should have been (VR 11.9.2.7, Table 11-64, ID# 0030291; VR 11.9.2.8, Table 11-65, ID# 0031083). An Acquirer may answer a dispute only once, and a merchant must not put a disputed and returned transaction through again; it may still seek payment from the customer outside the Visa system (VR 11.2.1, ID# 0030211; VR 5.10.1.2, ID# 0003022)." }, "facts": { "return_windows": [ { "action": "dispute", "by": "Issuer", "deadline": "120 calendar days from the Transaction Processing Date" }, { "action": "dispute response", "by": "Acquirer", "deadline": "30 calendar days from the Dispute Processing Date" }, { "action": "dispute response", "by": "Acquirer (CEMEA Region, Nigeria domestic)", "deadline": "2 business days from the Dispute Processing Date" }, { "action": "dispute response", "by": "Acquirer (CEMEA Region, Tanzania domestic)", "deadline": "20 calendar days from the Dispute Processing Date" }, { "action": "pre-arbitration attempt", "by": "Issuer", "deadline": "30 calendar days from the Dispute Response Processing Date" }, { "action": "pre-arbitration attempt", "by": "Issuer (CEMEA Region, Tanzania domestic)", "deadline": "10 calendar days from the Dispute Response Processing Date" }, { "action": "pre-arbitration response (accept or decline)", "by": "Acquirer", "deadline": "30 calendar days from the Processing Date of the pre-arbitration attempt" }, { "action": "pre-arbitration response (accept or decline)", "by": "Acquirer (CEMEA Region, Tanzania domestic)", "deadline": "10 calendar days from the Processing Date of the pre-arbitration attempt" }, { "action": "arbitration filing", "by": "Issuer", "deadline": "10 calendar days from the Processing Date of the pre-arbitration response" } ], "applies_to": "All Visa Regions" }, "caveat": "Invalid under 12.3: a transaction settled in USD at a Plus-connected ATM outside the US Region, unless it was a DCC transaction; a Mobile Push Payment Transaction; a Straight Through Processing Transaction (VR 11.9.2.3, Table 11-60, ID# 0030287). DCC details are in Visa's DCC Guide, a Supplemental Requirement [Unverified: not read]. A T&E Transaction may be disputed under this condition only if the Transaction amount or the partial Dispute amount is at least USD 25 or the local equivalent; the minimum does not apply to Brazil domestic Installment Transactions (VR 11.4.3, Table 11-5, ID# 0030219). Day counts are calendar days unless stated, and the processing date of the event that starts a count is not itself counted (VR 11.2.1, ID# 0030211).", "related": [ "visa-dispute:12.5", "visa:return" ], "basis": { "sources": "Visa Core Rules and Visa Product and Service Rules, 18 April 2026 edition: VR 11.9.2.1 to 11.9.2.8 (ID# 0030285 to 0030291, 0031083), Tables 11-58 to 11-65; VR 11.4.3, Table 11-5 (ID# 0030219); VR 11.2.1 (ID# 0030211); VR 11.2.3, Table 11-2 (ID# 0030213, stage deadlines and country notes); VR 5.10.1.2 (ID# 0003022); VR 11.6.1, Table 11-7 (ID# 0030222, region labels).", "confidence": "high" }, "currency": { "effective_since": "Before the current edition; start not stated in it", "effective_note": "Rules as in the 18 April 2026 edition of the Visa rules. Each rule cited carries its own last-updated month in its ID# footer, which the watch compares edition to edition. The next edition is expected in October 2026 [Inference].", "source_edition": "Visa Core Rules and Visa Product and Service Rules, 18 April 2026 edition (Visa Public), https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf", "source_class": "authoritative_primary", "source_title": "Visa Core Rules and Visa Product and Service Rules, 18 April 2026", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms the 120 calendar day filing deadline from the transaction processing date (Table 11-61, VR 11.9.2.4), and the category 12/13 process cycle: a 30 day dispute response by the acquirer, a 30 day pre-arbitration attempt by the issuer, a 30 day pre-arbitration response by the acquirer, and a 10 day arbitration filing by the issuer, with the Egypt, India, Nigeria, Poland and Tanzania domestic variants (Table 11-2, VR 11.2.3). Confirms the USD 25 T&E minimum with the Brazil Installment carve-out (Table 11-5, VR 11.4.3). Confirms the group is administrative-category dispute resolution." } ] }, "rail_name": "Visa Disputes", "governing_authority": "Visa", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "visa-dispute:12.4", "id": "12.4", "rail": "visa-dispute", "kind": "reason-code", "name": "Incorrect Account Number", "group": "administrative", "summary": "Processing-error dispute where a transaction, an Original Credit Transaction or an ATM Deposit Adjustment was posted to the wrong Payment Credential.", "triggers": [ "A Transaction or an Original Credit Transaction was processed on an incorrect Payment Credential; in the US Region this includes adjustments of ATM Cash Disbursements and of PIN-Authenticated Visa Debit Transactions", "An ATM Deposit Adjustment was processed on an incorrect Payment Credential" ], "actions": [ "Issuer: certify that a wrong credential was used, or that the credential matches nothing on the Issuer's master file and no authorization was obtained (VR 11.9.3.4, Table 11-69, ID# 0030546)" ], "retry": { "allowed": true, "rule": "Retry here means the Acquirer's right to contest. The Acquirer answers with a dispute response; the Issuer may reply with a pre-arbitration attempt, the Acquirer accepts it or declines it, and a case still open goes to arbitration filed by the Issuer (VR 11.2.3, Table 11-2, ID# 0030213). For 12.4 the dispute response may prove with a receipt or other record that the right credential was processed, or show that the dispute fails this condition's rules, that the cardholder has withdrawn it, or that the Issuer left out a credit or reversal the merchant had already made (VR 11.9.3.5, Table 11-70, ID# 0030295). An Acquirer may answer a dispute only once, and a merchant must not put a disputed and returned transaction through again; it may still seek payment from the customer outside the Visa system (VR 11.2.1, ID# 0030211; VR 5.10.1.2, ID# 0003022)." }, "facts": { "return_windows": [ { "action": "dispute", "by": "Issuer", "deadline": "120 calendar days from the Transaction Processing Date, or from the Transaction Processing Date of an ATM Deposit Adjustment" }, { "action": "dispute", "by": "Issuer (US domestic)", "deadline": "For an Adjustment of an ATM Cash Disbursement or a PIN-Authenticated Visa Debit Transaction, 120 calendar days from the Transaction Date of the Adjustment" }, { "action": "dispute response", "by": "Acquirer", "deadline": "30 calendar days from the Dispute Processing Date" }, { "action": "dispute response", "by": "Acquirer (CEMEA Region, Nigeria domestic)", "deadline": "2 business days from the Dispute Processing Date" }, { "action": "dispute response", "by": "Acquirer (CEMEA Region, Tanzania domestic)", "deadline": "20 calendar days from the Dispute Processing Date" }, { "action": "pre-arbitration attempt", "by": "Issuer", "deadline": "30 calendar days from the Dispute Response Processing Date" }, { "action": "pre-arbitration attempt", "by": "Issuer (CEMEA Region, Tanzania domestic)", "deadline": "10 calendar days from the Dispute Response Processing Date" }, { "action": "pre-arbitration response (accept or decline)", "by": "Acquirer", "deadline": "30 calendar days from the Processing Date of the pre-arbitration attempt" }, { "action": "pre-arbitration response (accept or decline)", "by": "Acquirer (CEMEA Region, Tanzania domestic)", "deadline": "10 calendar days from the Processing Date of the pre-arbitration attempt" }, { "action": "arbitration filing", "by": "Issuer", "deadline": "10 calendar days from the Processing Date of the pre-arbitration response" } ], "applies_to": "All Visa Regions, with a US domestic row for adjustments" }, "caveat": "Invalid under 12.4, grouped by Orca: (a) validated at the time: a Chip-initiated Transaction with a valid Cryptogram, or a credential for which no card was issued or is outstanding where an Imprint or an authorization was obtained; (b) types: ATM Cash Disbursement, Straight Through Processing Transaction, Mobility and Transport Transaction, Mobile Push Payment Transaction (VR 11.9.3.2, Table 11-67, ID# 0030293). A T&E Transaction may be disputed under this condition only if the Transaction amount or the partial Dispute amount is at least USD 25 or the local equivalent; the minimum does not apply to Brazil domestic Installment Transactions (VR 11.4.3, Table 11-5, ID# 0030219). Day counts are calendar days unless stated, and the processing date of the event that starts a count is not itself counted (VR 11.2.1, ID# 0030211).", "related": [ "visa-dispute:12.7", "visa:return" ], "basis": { "sources": "Visa Core Rules and Visa Product and Service Rules, 18 April 2026 edition: VR 11.9.3.1 to 11.9.3.5 (ID# 0030292, 0030293, 0030294, 0030546, 0030295), Tables 11-66 to 11-70; VR 11.4.3, Table 11-5 (ID# 0030219); VR 11.2.1 (ID# 0030211); VR 11.2.3, Table 11-2 (ID# 0030213, stage deadlines and country notes); VR 5.10.1.2 (ID# 0003022); VR 11.6.1, Table 11-7 (ID# 0030222, region labels).", "confidence": "high" }, "currency": { "effective_since": "Before the current edition; start not stated in it", "effective_note": "Rules as in the 18 April 2026 edition of the Visa rules. Each rule cited carries its own last-updated month in its ID# footer, which the watch compares edition to edition. The next edition is expected in October 2026 [Inference].", "source_edition": "Visa Core Rules and Visa Product and Service Rules, 18 April 2026 edition (Visa Public), https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf", "source_class": "authoritative_primary", "source_title": "Visa Core Rules and Visa Product and Service Rules, 18 April 2026", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms the 120 calendar day filing deadline from the transaction processing date or an ATM Deposit Adjustment date, with the US domestic ATM cash and PIN-debit adjustment variant counting from the adjustment date instead (Table 11-68, VR 11.9.3.3), and the category 12/13 process cycle with its country variants (Table 11-2, VR 11.2.3). Confirms the USD 25 T&E minimum with the Brazil Installment carve-out (Table 11-5, VR 11.4.3). Confirms the group is administrative-category dispute resolution." } ] }, "rail_name": "Visa Disputes", "governing_authority": "Visa", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "visa-dispute:12.5", "id": "12.5", "rail": "visa-dispute", "kind": "reason-code", "name": "Incorrect Amount", "group": "administrative", "summary": "Processing-error dispute where the amount charged was wrong, including addition or transposition errors, or an ATM Deposit Adjustment carried the wrong amount. Only the difference is disputed.", "triggers": [ "The Transaction amount is wrong, or an addition or transposition error occurred", "At an ATM, the ATM Deposit Adjustment amount is wrong" ], "actions": [ "Issuer: dispute only the difference between the amounts; where a handwritten amount differs from the imprinted amount, the handwritten amount decides (VR 11.9.4.2, Table 11-72, ID# 0030297)", "Issuer: supply the receipt or other record showing the correct amount, or certify the correct ATM Deposit Adjustment amount (VR 11.9.4.5, Table 11-75, ID# 0030300)" ], "retry": { "allowed": true, "rule": "Retry here means the Acquirer's right to contest. The Acquirer answers with a dispute response; the Issuer may reply with a pre-arbitration attempt, the Acquirer accepts it or declines it, and a case still open goes to arbitration filed by the Issuer (VR 11.2.3, Table 11-2, ID# 0030213). For 12.5 the dispute response may prove with a receipt or record that the amount was right, or show that the dispute is invalid, that the cardholder has withdrawn it, or that the Issuer left out a credit or reversal (Visa's text here names a credit or reversal issued by the Acquirer) (VR 11.9.4.6, Table 11-76, ID# 0030301). An Acquirer may answer a dispute only once, and a merchant must not put a disputed and returned transaction through again; it may still seek payment from the customer outside the Visa system (VR 11.2.1, ID# 0030211; VR 5.10.1.2, ID# 0003022)." }, "facts": { "return_windows": [ { "action": "dispute", "by": "Issuer", "deadline": "120 calendar days from the Transaction Processing Date, or from the Transaction Processing Date of an ATM Deposit Adjustment" }, { "action": "dispute", "by": "Issuer (US domestic)", "deadline": "For an Adjustment of an ATM Cash Disbursement or a PIN-Authenticated Visa Debit Transaction, 120 calendar days from the Transaction Date of the Adjustment" }, { "action": "dispute response", "by": "Acquirer", "deadline": "30 calendar days from the Dispute Processing Date" }, { "action": "dispute response", "by": "Acquirer (CEMEA Region, Nigeria domestic)", "deadline": "2 business days from the Dispute Processing Date" }, { "action": "dispute response", "by": "Acquirer (CEMEA Region, Tanzania domestic)", "deadline": "20 calendar days from the Dispute Processing Date" }, { "action": "pre-arbitration attempt", "by": "Issuer", "deadline": "30 calendar days from the Dispute Response Processing Date" }, { "action": "pre-arbitration attempt", "by": "Issuer (CEMEA Region, Tanzania domestic)", "deadline": "10 calendar days from the Dispute Response Processing Date" }, { "action": "pre-arbitration response (accept or decline)", "by": "Acquirer", "deadline": "30 calendar days from the Processing Date of the pre-arbitration attempt" }, { "action": "pre-arbitration response (accept or decline)", "by": "Acquirer (CEMEA Region, Tanzania domestic)", "deadline": "10 calendar days from the Processing Date of the pre-arbitration attempt" }, { "action": "arbitration filing", "by": "Issuer", "deadline": "10 calendar days from the Processing Date of the pre-arbitration response" } ], "applies_to": "All Visa Regions, with a US domestic row for adjustments" }, "caveat": "Invalid under 12.5, grouped by Orca: (a) the merchant was allowed to set or change the amount: where the merchant may alter the amount after completion without the cardholder's consent, a No-Show Transaction, an Advance Payment processed under VR 5.8.11.1, and a T&E charge that differs from a quoted price; (b) types: ATM Cash Disbursement, Mobile Push Payment Transaction, Straight Through Processing Transaction (VR 11.9.4.3, Table 11-73, ID# 0030298). A T&E Transaction may be disputed under this condition only if the Transaction amount or the partial Dispute amount is at least USD 25 or the local equivalent; the minimum does not apply to Brazil domestic Installment Transactions (VR 11.4.3, Table 11-5, ID# 0030219). Day counts are calendar days unless stated, and the processing date of the event that starts a count is not itself counted (VR 11.2.1, ID# 0030211).", "related": [ "visa-dispute:12.2", "visa-dispute:12.3", "visa-dispute:12.6", "visa:return", "paypal-dispute:INCORRECT_AMOUNT" ], "basis": { "sources": "Visa Core Rules and Visa Product and Service Rules, 18 April 2026 edition: VR 11.9.4.1 to 11.9.4.6 (ID# 0030296 to 0030301), Tables 11-71 to 11-76; VR 11.4.3, Table 11-5 (ID# 0030219); VR 11.2.1 (ID# 0030211); VR 11.2.3, Table 11-2 (ID# 0030213, stage deadlines and country notes); VR 5.10.1.2 (ID# 0003022); VR 11.6.1, Table 11-7 (ID# 0030222, region labels).", "confidence": "high" }, "currency": { "effective_since": "Before the current edition; start not stated in it", "effective_note": "Rules as in the 18 April 2026 edition of the Visa rules. Each rule cited carries its own last-updated month in its ID# footer, which the watch compares edition to edition. The next edition is expected in October 2026 [Inference].", "source_edition": "Visa Core Rules and Visa Product and Service Rules, 18 April 2026 edition (Visa Public), https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf", "source_class": "authoritative_primary", "source_title": "Visa Core Rules and Visa Product and Service Rules, 18 April 2026", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms the 120 calendar day filing deadline from the transaction processing date or an ATM Deposit Adjustment date, with the US domestic ATM cash and PIN-debit adjustment variant counting from the adjustment date instead (Table 11-74, VR 11.9.4.4), and the category 12/13 process cycle with its country variants (Table 11-2, VR 11.2.3). Confirms the USD 25 T&E minimum with the Brazil Installment carve-out (Table 11-5, VR 11.4.3). Confirms the group is administrative-category dispute resolution." } ] }, "rail_name": "Visa Disputes", "governing_authority": "Visa", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "visa-dispute:12.6", "id": "12.6", "rail": "visa-dispute", "kind": "reason-code", "name": "Duplicate Processing/Paid by Other Means", "group": "administrative", "summary": "Processing-error dispute for a charge processed twice (same credential, date and amount, with the cardholder having taken part in one), an ATM Deposit Adjustment processed twice, or a purchase the cardholder also paid for by other means.", "triggers": [ "Duplicate: one Transaction processed more than once on the same credential, date and amount, and the cardholder took part in one of them; in the US Region this includes ATM Cash Disbursement and PIN-Authenticated Visa Debit adjustments", "Duplicate ATM Deposit Adjustment", "Paid by other means: the cardholder (or Virtual Account holder) paid for the same goods or services another way, including where the merchant accepted a third-party voucher, failed to collect on it, and billed the cardholder" ], "actions": [ "Cardholder, for paid by other means: first try to resolve it with the merchant or its liquidator (not required for a travel agency using a Visa Commercial Card Virtual Account under a contract with a T&E Merchant) (VR 11.9.5.2, Table 11-78, ID# 0030303)", "Issuer, for a duplicate: certify the date and Acquirer Reference Number of the valid transaction, or the first adjustment's date and amount", "Issuer, for paid by other means: certify the attempt to resolve and show how the merchant was paid (a cash receipt, a cancelled check, a statement for another card or account, or the Acquirer Reference Number where a Visa card paid, as it applies), or that the merchant accepted the voucher; for disputes processed on or after 18 April 2026 on a card-present transaction, explain why the cardholder presented the card for the second one (VR 11.9.5.5, Table 11-81, ID# 0030306)", "Where different Acquirers processed the two, the Acquirer of the invalid one is liable; if the Issuer cannot tell which, the Acquirer of the second is liable (VR 11.9.5.2)" ], "retry": { "allowed": true, "rule": "Retry here means the Acquirer's right to contest. The Acquirer answers with a dispute response; the Issuer may reply with a pre-arbitration attempt, the Acquirer accepts it or declines it, and a case still open goes to arbitration filed by the Issuer (VR 11.2.3, Table 11-2, ID# 0030213). For 12.6 the dispute response may show that the dispute fails this condition's rules, that the cardholder has withdrawn it, or that the Issuer left out a credit or reversal the merchant had already made; at an ATM it may supply the disbursement or load records showing the credential, a time or sequence number for each transaction, and an indicator that each succeeded; elsewhere it may supply two receipts or records proving two separate purchases, or evidence that the merchant was not paid another way (VR 11.9.5.6, Table 11-82, ID# 0030307). An Acquirer may answer a dispute only once, and a merchant must not put a disputed and returned transaction through again; it may still seek payment from the customer outside the Visa system (VR 11.2.1, ID# 0030211; VR 5.10.1.2, ID# 0003022)." }, "facts": { "return_windows": [ { "action": "dispute", "by": "Issuer", "deadline": "120 calendar days from the Transaction Processing Date, or from the Transaction date of an ATM Deposit Adjustment" }, { "action": "dispute", "by": "Issuer (US domestic)", "deadline": "For an Adjustment of an ATM Cash Disbursement or a PIN-Authenticated Visa Debit Transaction, 120 calendar days from the Transaction Date of the Adjustment" }, { "action": "dispute response", "by": "Acquirer", "deadline": "30 calendar days from the Dispute Processing Date" }, { "action": "dispute response", "by": "Acquirer (AP Region, India domestic ATM Transaction)", "deadline": "6 calendar days from the Dispute Processing Date" }, { "action": "dispute response", "by": "Acquirer (CEMEA Region, Egypt domestic ATM Transaction)", "deadline": "10 calendar days from the Dispute Processing Date" }, { "action": "dispute response", "by": "Acquirer (Europe Region, Poland domestic ATM Transaction)", "deadline": "20 calendar days from the Dispute Processing Date" }, { "action": "dispute response", "by": "Acquirer (CEMEA Region, Nigeria domestic)", "deadline": "2 business days from the Dispute Processing Date" }, { "action": "dispute response", "by": "Acquirer (CEMEA Region, Tanzania domestic)", "deadline": "20 calendar days from the Dispute Processing Date" }, { "action": "pre-arbitration attempt", "by": "Issuer", "deadline": "30 calendar days from the Dispute Response Processing Date" }, { "action": "pre-arbitration attempt", "by": "Issuer (CEMEA Region, Tanzania domestic)", "deadline": "10 calendar days from the Dispute Response Processing Date" }, { "action": "pre-arbitration response (accept or decline)", "by": "Acquirer", "deadline": "30 calendar days from the Processing Date of the pre-arbitration attempt" }, { "action": "pre-arbitration response (accept or decline)", "by": "Acquirer (CEMEA Region, Tanzania domestic)", "deadline": "10 calendar days from the Processing Date of the pre-arbitration attempt" }, { "action": "arbitration filing", "by": "Issuer", "deadline": "10 calendar days from the Processing Date of the pre-arbitration response" } ], "applies_to": "All Visa Regions, with a US domestic row for adjustments and shorter dispute response limits for domestic ATM Transactions in Egypt, India and Poland" }, "caveat": "Invalid under 12.6: payments made to different merchants, unless there is evidence that the payment passed from one to the other, as from a travel agent to a T&E Merchant (VR 11.9.5.3, Table 11-79, ID# 0030304). A cash withdrawal processed more than once belongs here, not under 13.9 (VR 11.10.10.3). A T&E Transaction may be disputed under this condition only if the Transaction amount or the partial Dispute amount is at least USD 25 or the local equivalent; the minimum does not apply to Brazil domestic Installment Transactions (VR 11.4.3, Table 11-5, ID# 0030219). Day counts are calendar days unless stated, and the processing date of the event that starts a count is not itself counted (VR 11.2.1, ID# 0030211).", "related": [ "visa-dispute:12.5", "visa-dispute:13.9", "visa:return", "paypal-dispute:DUPLICATE_TRANSACTION", "paypal-dispute:PAYMENT_BY_OTHER_MEANS" ], "basis": { "sources": "Visa Core Rules and Visa Product and Service Rules, 18 April 2026 edition: VR 11.9.5.1 to 11.9.5.6 (ID# 0030302 to 0030307), Tables 11-77 to 11-82; VR 11.4.3, Table 11-5 (ID# 0030219); VR 11.2.1 (ID# 0030211); VR 11.2.3, Table 11-2 (ID# 0030213, stage deadlines and country notes); VR 5.10.1.2 (ID# 0003022); VR 11.6.1, Table 11-7 (ID# 0030222, region labels).", "confidence": "high" }, "currency": { "effective_since": "Before the current edition; start not stated in it", "effective_note": "Rules as in the 18 April 2026 edition of the Visa rules. Each rule cited carries its own last-updated month in its ID# footer, which the watch compares edition to edition. The next edition is expected in October 2026 [Inference].", "source_edition": "Visa Core Rules and Visa Product and Service Rules, 18 April 2026 edition (Visa Public), https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf", "source_class": "authoritative_primary", "source_title": "Visa Core Rules and Visa Product and Service Rules, 18 April 2026", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms the 120 calendar day filing deadline from the transaction processing date or an ATM Deposit Adjustment date, with the US domestic ATM cash and PIN-debit adjustment variant counting from the adjustment date instead (Table 11-80, VR 11.9.5.4), and the category 12/13 process cycle, including the Egypt and India domestic ATM variants naming this condition by number (Table 11-2, VR 11.2.3). Confirms the USD 25 T&E minimum with the Brazil Installment carve-out (Table 11-5, VR 11.4.3). Confirms the group is administrative-category dispute resolution." } ] }, "rail_name": "Visa Disputes", "governing_authority": "Visa", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "visa-dispute:12.7", "id": "12.7", "rail": "visa-dispute", "kind": "reason-code", "name": "Invalid Data", "group": "administrative", "summary": "Processing-error dispute where authorization was obtained with invalid or incorrect data, or the MCC in the Authorization Request differs from the MCC in the first Presentment's Clearing Record, and valid data would have led to a decline.", "triggers": [ "The authorization was obtained with invalid or incorrect data; an authorization counts as invalid when a required field was wrong, such as the MCC, the Transaction Date, a country or state code, or a merchant, transaction-type or special-condition indicator (VR 11.9.6.2, Table 11-84, ID# 0030309)", "The MCC in the Authorization Request does not match the MCC in the Clearing Record of the first Presentment" ], "actions": [ "Issuer: dispute the entire Transaction amount", "Issuer: certify that the request would have been declined with valid data and explain why (VR 11.9.6.5, Table 11-87, ID# 0030311)" ], "retry": { "allowed": true, "rule": "Retry here means the Acquirer's right to contest. The Acquirer answers with a dispute response; the Issuer may reply with a pre-arbitration attempt, the Acquirer accepts it or declines it, and a case still open goes to arbitration filed by the Issuer (VR 11.2.3, Table 11-2, ID# 0030213). For 12.7 the dispute response may show that the authorization contained no invalid data, or that the dispute fails this condition's rules, that the cardholder has withdrawn it, or that the Issuer left out a credit or reversal the merchant had already made (VR 11.9.6.6, Table 11-88, ID# 0030312). An Acquirer may answer a dispute only once, and a merchant must not put a disputed and returned transaction through again; it may still seek payment from the customer outside the Visa system (VR 11.2.1, ID# 0030211; VR 5.10.1.2, ID# 0003022)." }, "facts": { "return_windows": [ { "action": "dispute", "by": "Issuer", "deadline": "75 calendar days from the Transaction Processing Date" }, { "action": "dispute response", "by": "Acquirer", "deadline": "30 calendar days from the Dispute Processing Date" }, { "action": "dispute response", "by": "Acquirer (CEMEA Region, Nigeria domestic)", "deadline": "2 business days from the Dispute Processing Date" }, { "action": "dispute response", "by": "Acquirer (CEMEA Region, Tanzania domestic)", "deadline": "20 calendar days from the Dispute Processing Date" }, { "action": "pre-arbitration attempt", "by": "Issuer", "deadline": "30 calendar days from the Dispute Response Processing Date" }, { "action": "pre-arbitration attempt", "by": "Issuer (CEMEA Region, Tanzania domestic)", "deadline": "10 calendar days from the Dispute Response Processing Date" }, { "action": "pre-arbitration response (accept or decline)", "by": "Acquirer", "deadline": "30 calendar days from the Processing Date of the pre-arbitration attempt" }, { "action": "pre-arbitration response (accept or decline)", "by": "Acquirer (CEMEA Region, Tanzania domestic)", "deadline": "10 calendar days from the Processing Date of the pre-arbitration attempt" }, { "action": "arbitration filing", "by": "Issuer", "deadline": "10 calendar days from the Processing Date of the pre-arbitration response" } ], "applies_to": "All Visa Regions" }, "caveat": "Invalid under 12.7: an ATM Cash Disbursement; a Mobile Push Payment Transaction (VR 11.9.6.3, Table 11-85, ID# 0030629). Unlike the rest of category 12, the time limit is 75 days. A T&E Transaction may be disputed under this condition only if the Transaction amount or the partial Dispute amount is at least USD 25 or the local equivalent; the minimum does not apply to Brazil domestic Installment Transactions (VR 11.4.3, Table 11-5, ID# 0030219). Day counts are calendar days unless stated, and the processing date of the event that starts a count is not itself counted (VR 11.2.1, ID# 0030211).", "related": [ "visa-dispute:11.3", "visa-dispute:12.4", "visa:return" ], "basis": { "sources": "Visa Core Rules and Visa Product and Service Rules, 18 April 2026 edition: VR 11.9.6.1 to 11.9.6.6 (ID# 0030308, 0030309, 0030629, 0030310, 0030311, 0030312), Tables 11-83 to 11-88; VR 11.4.3, Table 11-5 (ID# 0030219); VR 11.2.1 (ID# 0030211); VR 11.2.3, Table 11-2 (ID# 0030213, stage deadlines and country notes); VR 5.10.1.2 (ID# 0003022); VR 11.6.1, Table 11-7 (ID# 0030222, region labels).", "confidence": "high" }, "currency": { "effective_since": "Before the current edition; start not stated in it", "effective_note": "Rules as in the 18 April 2026 edition of the Visa rules. Each rule cited carries its own last-updated month in its ID# footer, which the watch compares edition to edition. The next edition is expected in October 2026 [Inference].", "source_edition": "Visa Core Rules and Visa Product and Service Rules, 18 April 2026 edition (Visa Public), https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf", "source_class": "authoritative_primary", "source_title": "Visa Core Rules and Visa Product and Service Rules, 18 April 2026", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms the 75 calendar day filing deadline from the transaction processing date, shorter than the rest of category 12 (Table 11-86, VR 11.9.6.4), and the category 12/13 process cycle with its country variants (Table 11-2, VR 11.2.3). Confirms the USD 25 T&E minimum with the Brazil Installment carve-out (Table 11-5, VR 11.4.3). Confirms the group is administrative-category dispute resolution." } ] }, "rail_name": "Visa Disputes", "governing_authority": "Visa", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "visa-dispute:13.1", "id": "13.1", "rail": "visa-dispute", "kind": "reason-code", "name": "Merchandise/Services Not Received", "group": "consumer-dispute", "summary": "Consumer dispute where the cardholder took part in the purchase but the goods or services, or bought crypto or NFTs, never arrived because the Merchant or Load Partner would not or could not provide them.", "triggers": [ "The cardholder (or Virtual Account holder) took part, and neither they nor a person they authorized received what was bought, because the Merchant or Load Partner was unwilling or unable to provide it", "The merchant cancelled the goods or services", "Goods arrived late and the cardholder returned or tried to return them", "Non-fiat currency or an NFT was not delivered to the wallet address the cardholder gave at purchase; the dispute is limited to its cost at the time of purchase" ], "actions": [ "Cardholder: try to resolve it with the Merchant, its liquidator, the Ramp Provider or its Conversion Affiliate before the Issuer files (not required for a travel agency using a Visa Commercial Card Virtual Account under a contract with a T&E Merchant) (VR 11.10.2.2, Table 11-90, ID# 0030314)", "Issuer: dispute only the part not received; certify what was not received and when or where it was due, the attempt to resolve, and any return or cancellation date; give a description of the goods beyond what the Clearing Record carries (unless Enhanced Data describes them); explain any filing before the expected delivery date (VR 11.10.2.5, Table 11-93, ID# 0030317)", "Issuer: supply a signed cardholder letter when the cardholder has disputed 3 or more non-receipt transactions at the same merchant on the same card within one 30-day period (VR 11.10.2.5; letter rules VR 11.10.1, ID# 0030224)", "Europe: for travel from an insolvent provider covered by a bonding authority or insurance scheme, claim there first unless the cover is insufficient, in which case public information may support the dispute (VR 11.10.2.2)", "Merchant: goods held by customs in the merchant's own country remain the merchant's responsibility" ], "retry": { "allowed": true, "rule": "Retry here means the Acquirer's right to contest. The Acquirer answers with a dispute response; the Issuer may reply with a pre-arbitration attempt, the Acquirer accepts it or declines it, and a case still open goes to arbitration filed by the Issuer (VR 11.2.3, Table 11-2, ID# 0030213). For 13.1 the dispute response may show that the dispute fails this condition's rules, that the cardholder has withdrawn it, or that the Issuer left out a credit or reversal the merchant had already made, or prove the purchase was received: for crypto or NFTs, delivery to the cardholder's wallet with the wallet address or a searchable blockchain hash; for an Airline Transaction, that the flight left; for future services, that the merchant did not cancel and could perform; for other services, that they were provided at the agreed place or time; for physical goods, a pickup record with the cardholder's acknowledgment (card-absent collection), certification that the goods were taken at the till (card-present), or proof of delivery with the full address, since tracking with a partial address is not accepted (VR 11.10.2.6, Table 11-94, ID# 0030318). The Issuer's pre-arbitration attempt answers the merchant's evidence point by point, and for dispute responses processed on or after 18 April 2026 carrying delivery or collection evidence, the Issuer must certify it reviewed that evidence with the cardholder and addressed each item (VR 11.10.2.7, Table 11-95, ID# 0031084). An Acquirer may answer a dispute only once, and a merchant must not put a disputed and returned transaction through again; it may still seek payment from the customer outside the Visa system (VR 11.2.1, ID# 0030211; VR 5.10.1.2, ID# 0003022)." }, "facts": { "return_windows": [ { "action": "dispute", "by": "Issuer", "deadline": "Not before a waiting period: 15 calendar days from the Transaction Date when no delivery or service date was set, from the return or attempted return of late goods, or from the merchant's cancellation; 30 calendar days after the provider cancels for MCC 4722 travel agencies and tour operators and third-party ticket sellers. Not later than 120 calendar days from the Transaction Processing Date or from the last date the cardholder expected to receive the goods or services, never beyond 540 calendar days from the Transaction Processing Date" }, { "action": "dispute", "by": "Issuer (Europe)", "deadline": "As for all regions, and where a bonding authority or insurance claim was required: wait 60 calendar days after submitting the claim (or proceed if it goes unanswered for 60 days), and the dispute may also be filed within 60 days of the scheme's letter or advice" }, { "action": "dispute response", "by": "Acquirer", "deadline": "30 calendar days from the Dispute Processing Date" }, { "action": "dispute response", "by": "Acquirer (CEMEA Region, Nigeria domestic)", "deadline": "2 business days from the Dispute Processing Date" }, { "action": "dispute response", "by": "Acquirer (CEMEA Region, Tanzania domestic)", "deadline": "20 calendar days from the Dispute Processing Date" }, { "action": "pre-arbitration attempt", "by": "Issuer", "deadline": "30 calendar days from the Dispute Response Processing Date" }, { "action": "pre-arbitration attempt", "by": "Issuer (CEMEA Region, Tanzania domestic)", "deadline": "10 calendar days from the Dispute Response Processing Date" }, { "action": "pre-arbitration response (accept or decline)", "by": "Acquirer", "deadline": "30 calendar days from the Processing Date of the pre-arbitration attempt" }, { "action": "pre-arbitration response (accept or decline)", "by": "Acquirer (CEMEA Region, Tanzania domestic)", "deadline": "10 calendar days from the Processing Date of the pre-arbitration attempt" }, { "action": "arbitration filing", "by": "Issuer", "deadline": "10 calendar days from the Processing Date of the pre-arbitration response" } ], "applies_to": "All Visa Regions; Europe adds a bonding and insurance step for travel from insolvent providers" }, "caveat": "Invalid under 13.1, grouped by Orca: (a) not a non-receipt problem: the cardholder cancelled before the expected date (buyer's remorse, for example), a complaint about quality, or a claim that the transaction was fraud; (b) delivered or deliverable: goods held by customs in the cardholder's country, crypto or NFTs delivered but later inaccessible to the cardholder, a partial Advance Payment where the balance is unpaid and the merchant can still deliver; (c) types: ATM Cash Disbursement, Straight Through Processing Transaction, Automated Fuel Dispenser Transaction, the Cash-Back portion of a Visa Cash-Back Transaction (VR 11.10.2.3, Table 11-91, ID# 0030315). Waiting periods: none when the merchant is insolvent or bankrupt or when waiting would pass the time limit; the Europe bonding wait falls away when the cover is insufficient. The expected-date extension does not apply to third-party gift cards without an expiry that were not honoured because the third party failed. Brazil counts the 3-dispute letter threshold from the original Authorization Request; clearings with one Multiple Clearing Sequence Number count as one. A T&E Transaction may be disputed under this condition only if the Transaction amount or the partial Dispute amount is at least USD 25 or the local equivalent; the minimum does not apply to Brazil domestic Installment Transactions (VR 11.4.3, Table 11-5, ID# 0030219). Day counts are calendar days unless stated, and the processing date of the event that starts a count is not itself counted (VR 11.2.1, ID# 0030211).", "related": [ "visa-dispute:13.3", "visa-dispute:13.7", "visa-dispute:13.5", "visa:return", "visa:finality", "paypal-dispute:MERCHANDISE_OR_SERVICE_NOT_RECEIVED" ], "basis": { "sources": "Visa Core Rules and Visa Product and Service Rules, 18 April 2026 edition: VR 11.10.2.1 to 11.10.2.7 (ID# 0030313 to 0030318, 0031084), Tables 11-89 to 11-95; VR 11.10.1 (ID# 0030224); VR 11.4.3, Table 11-5 (ID# 0030219); VR 11.2.1 (ID# 0030211); VR 11.2.3, Table 11-2 (ID# 0030213, stage deadlines and country notes); VR 5.10.1.2 (ID# 0003022); VR 11.6.1, Table 11-7 (ID# 0030222, region labels).", "confidence": "high" }, "currency": { "effective_since": "Before the current edition; start not stated in it", "effective_note": "Rules as in the 18 April 2026 edition of the Visa rules. Each rule cited carries its own last-updated month in its ID# footer, which the watch compares edition to edition. The next edition is expected in October 2026 [Inference].", "source_edition": "Visa Core Rules and Visa Product and Service Rules, 18 April 2026 edition (Visa Public), https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf", "source_class": "authoritative_primary", "source_title": "Visa Core Rules and Visa Product and Service Rules, 18 April 2026", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms the waiting periods (15 days, or 30 days for MCC 4722 travel agencies and third-party ticket sellers), the 120 day filing deadline from the transaction processing date or the last expected receipt date, the 540 day ceiling, and the Europe bonding and insurance wait (Table 11-92, VR 11.10.2.4), plus the category 12/13 process cycle with its country variants (Table 11-2, VR 11.2.3). Confirms the USD 25 T&E minimum with the Brazil Installment carve-out (Table 11-5, VR 11.4.3). Confirms the group is consumer-dispute category dispute resolution." } ] }, "rail_name": "Visa Disputes", "governing_authority": "Visa", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "visa-dispute:13.2", "id": "13.2", "rail": "visa-dispute", "kind": "reason-code", "name": "Cancelled Recurring Transaction", "group": "consumer-dispute", "summary": "Consumer dispute for a Recurring Transaction (in Europe also an Installment Transaction) charged after the cardholder withdrew permission, or after the merchant or Acquirer was told the account was closed (in Europe also that facilities were withdrawn or the cardholder died).", "triggers": [ "The cardholder withdrew permission to charge the credential for a Recurring Transaction (in the Europe Region, also an Installment Transaction)", "Before the Transaction was processed, the Acquirer or merchant had been told the account was closed; in the Europe Region, also that facilities were withdrawn or the cardholder had died" ], "actions": [ "Issuer: dispute only the unused portion of the service or goods (in Europe, not a limit for Installment Transactions) (VR 11.10.3.2, Table 11-97, ID# 0030320)", "Issuer: certify the date permission was withdrawn, the contact details used to reach the merchant and any other payment method given to it, or the date the Issuer told the merchant the credential was closed; in Europe, certify the cancellation or notice date, the closure with facilities withdrawn, or the death (VR 11.10.3.5, Table 11-100, ID# 0030323)" ], "retry": { "allowed": true, "rule": "Retry here means the Acquirer's right to contest. The Acquirer answers with a dispute response; the Issuer may reply with a pre-arbitration attempt, the Acquirer accepts it or declines it, and a case still open goes to arbitration filed by the Issuer (VR 11.2.3, Table 11-2, ID# 0030213). For 13.2 the dispute response may show that the cardholder used the service after withdrawing permission and before the dispute (the cancellation date being the last day the cardholder may use the service); that the Issuer's claim of a closure notice is wrong; that the merchant bills in arrears and served the cardholder up to cancellation; that the cardholder chose a later cancellation date and was served until then; or that the dispute fails this condition's rules, that the cardholder has withdrawn it, or that the Issuer left out a credit or reversal the merchant had already made. In Europe the closure-claim, arrears and later-date answers do not answer an Issuer that reported closure, withdrawn facilities or death (VR 11.10.3.6, Table 11-101, ID# 0030324). The Issuer's pre-arbitration attempt may produce the cardholder's withdrawal notice, or show that later use related to an earlier paid period (VR 11.10.3.7, Table 11-102, ID# 0031085). An Acquirer may answer a dispute only once, and a merchant must not put a disputed and returned transaction through again; it may still seek payment from the customer outside the Visa system (VR 11.2.1, ID# 0030211; VR 5.10.1.2, ID# 0003022)." }, "facts": { "return_windows": [ { "action": "dispute", "by": "Issuer", "deadline": "120 calendar days from the Transaction Processing Date" }, { "action": "dispute response", "by": "Acquirer", "deadline": "30 calendar days from the Dispute Processing Date" }, { "action": "dispute response", "by": "Acquirer (CEMEA Region, Nigeria domestic)", "deadline": "2 business days from the Dispute Processing Date" }, { "action": "dispute response", "by": "Acquirer (CEMEA Region, Tanzania domestic)", "deadline": "20 calendar days from the Dispute Processing Date" }, { "action": "pre-arbitration attempt", "by": "Issuer", "deadline": "30 calendar days from the Dispute Response Processing Date" }, { "action": "pre-arbitration attempt", "by": "Issuer (CEMEA Region, Tanzania domestic)", "deadline": "10 calendar days from the Dispute Response Processing Date" }, { "action": "pre-arbitration response (accept or decline)", "by": "Acquirer", "deadline": "30 calendar days from the Processing Date of the pre-arbitration attempt" }, { "action": "pre-arbitration response (accept or decline)", "by": "Acquirer (CEMEA Region, Tanzania domestic)", "deadline": "10 calendar days from the Processing Date of the pre-arbitration attempt" }, { "action": "arbitration filing", "by": "Issuer", "deadline": "10 calendar days from the Processing Date of the pre-arbitration response" } ], "applies_to": "All Visa Regions; Europe adds Installment Transactions and closure, withdrawn-facility and death grounds" }, "caveat": "Invalid under 13.2, grouped by Orca: (a) not a recurring charge: an Unscheduled Credential-on-File Transaction, a Cardholder-initiated Transaction, or an Installment Transaction outside Europe; (b) cancelled too late: the cancellation came after the Transaction date (disputes processed on or after 18 April 2026); (c) a claim that the transaction was fraud; (d) types: Mobile Push Payment Transaction, Straight Through Processing Transaction (VR 11.10.3.3, Table 11-98, ID# 0030321). A T&E Transaction may be disputed under this condition only if the Transaction amount or the partial Dispute amount is at least USD 25 or the local equivalent; the minimum does not apply to Brazil domestic Installment Transactions (VR 11.4.3, Table 11-5, ID# 0030219). Day counts are calendar days unless stated, and the processing date of the event that starts a count is not itself counted (VR 11.2.1, ID# 0030211).", "related": [ "visa-dispute:13.7", "visa-dispute:13.5", "visa:return", "visa-decline:R0", "visa-decline:R1", "visa-decline:R3", "paypal-dispute:CANCELED_RECURRING_BILLING" ], "basis": { "sources": "Visa Core Rules and Visa Product and Service Rules, 18 April 2026 edition: VR 11.10.3.1 to 11.10.3.7 (ID# 0030319 to 0030324, 0031085), Tables 11-96 to 11-102; VR 11.4.3, Table 11-5 (ID# 0030219); VR 11.2.1 (ID# 0030211); VR 11.2.3, Table 11-2 (ID# 0030213, stage deadlines and country notes); VR 5.10.1.2 (ID# 0003022); VR 11.6.1, Table 11-7 (ID# 0030222, region labels).", "confidence": "high" }, "currency": { "effective_since": "Before the current edition; start not stated in it", "effective_note": "Rules as in the 18 April 2026 edition of the Visa rules. Each rule cited carries its own last-updated month in its ID# footer, which the watch compares edition to edition. The next edition is expected in October 2026 [Inference].", "source_edition": "Visa Core Rules and Visa Product and Service Rules, 18 April 2026 edition (Visa Public), https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf", "source_class": "authoritative_primary", "source_title": "Visa Core Rules and Visa Product and Service Rules, 18 April 2026", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms the 120 calendar day filing deadline from the transaction processing date, with no waiting period (Table 11-99, VR 11.10.3.4), and the category 12/13 process cycle with its country variants (Table 11-2, VR 11.2.3). Confirms the USD 25 T&E minimum with the Brazil Installment carve-out (Table 11-5, VR 11.4.3). Confirms the group is consumer-dispute category dispute resolution." } ] }, "rail_name": "Visa Disputes", "governing_authority": "Visa", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "visa-dispute:13.3", "id": "13.3", "rail": "visa-dispute", "kind": "reason-code", "name": "Not as Described or Defective Merchandise/Services", "group": "consumer-dispute", "summary": "Consumer dispute where what arrived did not match the receipt or the description given at purchase, was damaged or defective, or was of disputed quality; it also covers crypto or NFTs that did not match their description and breaches of a travel agency's contract with a T&E merchant.", "triggers": [ "The goods or services differ from the Transaction Receipt or other record shown at purchase, arrived damaged or defective, or their quality is disputed", "Non-fiat currency or an NFT received does not match its description at purchase, or the merchant guaranteed it would rise in value", "A travel agency using a Visa Commercial Card Virtual Account under a contract with a T&E Merchant: the merchant did not honour the contract or delivered something other than it describes", "Canada domestic, US domestic and Canada/US interregional: on a card-absent sale, what arrived does not match the merchant's verbal description or other documents given at purchase" ], "actions": [ "Cardholder: try to resolve it with the merchant or its liquidator (a cancellation counts as the attempt) and return or try to return the goods or cancel the services; for services already rendered, ask the merchant for a credit. A return attempt counts only where the merchant gave no clear return instructions, stopped responding or no longer exists, told the cardholder not to send the goods back, or refused the return or a return authorization or label (VR 11.10.4.2, Table 11-104, ID# 0030326)", "Issuer: dispute no more than the unused part of a cancelled service, the value of goods returned or offered back, the value of items outside a travel agency contract, or the purchase cost of crypto or NFTs", "Issuer: certify what was wrong, when the goods or services were received, the attempt to resolve, and the return or cancellation details with shipping data where available; for a dispute based on ongoing negotiations, certify when they began and when the Issuer was first told, with evidence (VR 11.10.4.5, Table 11-107, ID# 0030329)", "Merchant: goods held by customs in the merchant's own country remain the merchant's responsibility" ], "retry": { "allowed": true, "rule": "Retry here means the Acquirer's right to contest. The Acquirer answers with a dispute response; the Issuer may reply with a pre-arbitration attempt, the Acquirer accepts it or declines it, and a case still open goes to arbitration filed by the Issuer (VR 11.2.3, Table 11-2, ID# 0030213). For 13.3 the dispute response may show that crypto or NFTs matched their description or that a travel agency contract was honoured; or show that the cardholder never tried to return the goods, or certify that the return has not arrived; or pair the merchant's rebuttal with proof that the goods or services matched their description and were not defective; or show that the dispute fails this condition's rules, that the cardholder has withdrawn it, or that the Issuer left out a credit or reversal the merchant had already made (VR 11.10.4.6, Table 11-108, ID# 0030330). The Issuer's pre-arbitration attempt may add third-party evidence of the defect, proof of the return, or a repair or replacement estimate in moving disputes (VR 11.10.4.7, Table 11-109, ID# 0031086). An Acquirer may answer a dispute only once, and a merchant must not put a disputed and returned transaction through again; it may still seek payment from the customer outside the Visa system (VR 11.2.1, ID# 0030211; VR 5.10.1.2, ID# 0003022)." }, "facts": { "return_windows": [ { "action": "dispute", "by": "Issuer", "deadline": "Not before 15 calendar days after the cardholder returned or tried to return the goods or cancelled the services. Not later than 120 calendar days from the Transaction Processing Date or from the date the cardholder received the goods or services, or 60 calendar days from the Issuer's first notice of the dispute where that notice shows negotiations with the merchant within 120 days of the Transaction Processing Date; never beyond 540 calendar days from the Transaction Processing Date" }, { "action": "dispute response", "by": "Acquirer", "deadline": "30 calendar days from the Dispute Processing Date" }, { "action": "dispute response", "by": "Acquirer (CEMEA Region, Nigeria domestic)", "deadline": "2 business days from the Dispute Processing Date" }, { "action": "dispute response", "by": "Acquirer (CEMEA Region, Tanzania domestic)", "deadline": "20 calendar days from the Dispute Processing Date" }, { "action": "pre-arbitration attempt", "by": "Issuer", "deadline": "30 calendar days from the Dispute Response Processing Date" }, { "action": "pre-arbitration attempt", "by": "Issuer (CEMEA Region, Tanzania domestic)", "deadline": "10 calendar days from the Dispute Response Processing Date" }, { "action": "pre-arbitration response (accept or decline)", "by": "Acquirer", "deadline": "30 calendar days from the Processing Date of the pre-arbitration attempt" }, { "action": "pre-arbitration response (accept or decline)", "by": "Acquirer (CEMEA Region, Tanzania domestic)", "deadline": "10 calendar days from the Processing Date of the pre-arbitration attempt" }, { "action": "arbitration filing", "by": "Issuer", "deadline": "10 calendar days from the Processing Date of the pre-arbitration response" } ], "applies_to": "All Visa Regions; a wider card-absent description right for Canada domestic, US domestic and Canada/US interregional" }, "caveat": "Invalid under 13.3, grouped by Orca: (a) price and tax: a price discrepancy, a Value-Added Tax dispute, or crypto or NFTs not rising in resale value as hoped; (b) restaurant food quality (a cold meal, for example); (c) a claim that the transaction was fraud; (d) returned goods held by a customs agency other than the one in the merchant's country; (e) types: ATM Cash Disbursement, Straight Through Processing Transaction, Automated Fuel Dispenser Transaction, the Cash-Back portion of a Visa Cash-Back Transaction (VR 11.10.4.3, Table 11-105, ID# 0030327). The 15-day wait does not apply when it would pass the time limit, when the merchant refuses the cancellation or return, or to the travel agency Virtual Account case. How the USD 25 T&E minimum in Table 11-5 applies to this condition depends on a note limited to travel agency Virtual Account contracts [Unverified]. Day counts are calendar days unless stated, and the processing date of the event that starts a count is not itself counted (VR 11.2.1, ID# 0030211).", "related": [ "visa-dispute:13.1", "visa-dispute:13.4", "visa-dispute:13.5", "visa-dispute:13.7", "visa:return", "paypal-dispute:MERCHANDISE_OR_SERVICE_NOT_AS_DESCRIBED" ], "basis": { "sources": "Visa Core Rules and Visa Product and Service Rules, 18 April 2026 edition: VR 11.10.4.1 to 11.10.4.7 (ID# 0030325 to 0030330, 0031086), Tables 11-103 to 11-109; VR 11.4.3, Table 11-5 (ID# 0030219); VR 11.2.1 (ID# 0030211); VR 11.2.3, Table 11-2 (ID# 0030213, stage deadlines and country notes); VR 5.10.1.2 (ID# 0003022); VR 11.6.1, Table 11-7 (ID# 0030222, region labels).", "confidence": "high" }, "currency": { "effective_since": "Before the current edition; start not stated in it", "effective_note": "Rules as in the 18 April 2026 edition of the Visa rules. Each rule cited carries its own last-updated month in its ID# footer, which the watch compares edition to edition. The next edition is expected in October 2026 [Inference].", "source_edition": "Visa Core Rules and Visa Product and Service Rules, 18 April 2026 edition (Visa Public), https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf", "source_class": "authoritative_primary", "source_title": "Visa Core Rules and Visa Product and Service Rules, 18 April 2026", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms the 15 day waiting period, the 120 day filing deadline from the transaction processing date or receipt date, the 60 day negotiation exception, and the 540 day ceiling (Table 11-106, VR 11.10.4.4), plus the category 12/13 process cycle with its country variants (Table 11-2, VR 11.2.3). Confirms the USD 25 T&E minimum applies only through the travel agency Virtual Account note, not generally to this condition (Table 11-5, VR 11.4.3). Confirms the group is consumer-dispute category dispute resolution." } ] }, "rail_name": "Visa Disputes", "governing_authority": "Visa", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "visa-dispute:13.4", "id": "13.4", "rail": "visa-dispute", "kind": "reason-code", "name": "Counterfeit Merchandise", "group": "consumer-dispute", "summary": "Consumer dispute where goods bought turn out to be counterfeit, as identified by a government body (customs, police or another agency), an independent expert, or the holder of the intellectual property or its agent.", "triggers": [ "The goods were identified as counterfeit by a qualified party: a customs, law enforcement or other government agency, a third-party expert, or the intellectual property owner or its authorized representative", "The cardholder was told an order was counterfeit before it arrived; the dispute applies even if the goods were never received (VR 11.10.5.2, Table 11-111, ID# 0030332)" ], "actions": [ "Issuer: provide evidence of the counterfeit notice naming who gave it and showing they are qualified to give it, the date the goods or the notice were received, a description of the goods, and where the goods are now (VR 11.10.5.5, Table 11-114, ID# 0030335)" ], "retry": { "allowed": true, "rule": "Retry here means the Acquirer's right to contest. The Acquirer answers with a dispute response; the Issuer may reply with a pre-arbitration attempt, the Acquirer accepts it or declines it, and a case still open goes to arbitration filed by the Issuer (VR 11.2.3, Table 11-2, ID# 0030213). For 13.4 the dispute response may support the merchant's claim that the goods were genuine, or show that the dispute fails this condition's rules, that the cardholder has withdrawn it, or that the Issuer left out a credit or reversal the merchant had already made (VR 11.10.5.6, Table 11-115, ID# 0030336). An Acquirer may answer a dispute only once, and a merchant must not put a disputed and returned transaction through again; it may still seek payment from the customer outside the Visa system (VR 11.2.1, ID# 0030211; VR 5.10.1.2, ID# 0003022)." }, "facts": { "return_windows": [ { "action": "dispute", "by": "Issuer", "deadline": "No later than 120 calendar days from the Transaction Processing Date, from the date the cardholder received the goods, or from the date the cardholder was told they were counterfeit; the last two never beyond 540 calendar days from the Transaction Processing Date. No waiting period" }, { "action": "dispute response", "by": "Acquirer", "deadline": "30 calendar days from the Dispute Processing Date" }, { "action": "dispute response", "by": "Acquirer (CEMEA Region, Nigeria domestic)", "deadline": "2 business days from the Dispute Processing Date" }, { "action": "dispute response", "by": "Acquirer (CEMEA Region, Tanzania domestic)", "deadline": "20 calendar days from the Dispute Processing Date" }, { "action": "pre-arbitration attempt", "by": "Issuer", "deadline": "30 calendar days from the Dispute Response Processing Date" }, { "action": "pre-arbitration attempt", "by": "Issuer (CEMEA Region, Tanzania domestic)", "deadline": "10 calendar days from the Dispute Response Processing Date" }, { "action": "pre-arbitration response (accept or decline)", "by": "Acquirer", "deadline": "30 calendar days from the Processing Date of the pre-arbitration attempt" }, { "action": "pre-arbitration response (accept or decline)", "by": "Acquirer (CEMEA Region, Tanzania domestic)", "deadline": "10 calendar days from the Processing Date of the pre-arbitration attempt" }, { "action": "arbitration filing", "by": "Issuer", "deadline": "10 calendar days from the Processing Date of the pre-arbitration response" } ], "applies_to": "All Visa Regions" }, "caveat": "Invalid under 13.4: a Value-Added Tax dispute; an Automated Fuel Dispenser Transaction; the Cash-Back portion of a Visa Cash-Back Transaction; a Straight Through Processing Transaction (VR 11.10.5.3, Table 11-112, ID# 0030333). A T&E Transaction may be disputed under this condition only if the Transaction amount or the partial Dispute amount is at least USD 25 or the local equivalent; the minimum does not apply to Brazil domestic Installment Transactions (VR 11.4.3, Table 11-5, ID# 0030219). Day counts are calendar days unless stated, and the processing date of the event that starts a count is not itself counted (VR 11.2.1, ID# 0030211).", "related": [ "visa-dispute:13.3", "visa:return" ], "basis": { "sources": "Visa Core Rules and Visa Product and Service Rules, 18 April 2026 edition: VR 11.10.5.1 to 11.10.5.6 (ID# 0030331 to 0030336), Tables 11-110 to 11-115; VR 11.4.3, Table 11-5 (ID# 0030219); VR 11.2.1 (ID# 0030211); VR 11.2.3, Table 11-2 (ID# 0030213, stage deadlines and country notes); VR 5.10.1.2 (ID# 0003022); VR 11.6.1, Table 11-7 (ID# 0030222, region labels).", "confidence": "high" }, "currency": { "effective_since": "Before the current edition; start not stated in it", "effective_note": "Rules as in the 18 April 2026 edition of the Visa rules. Each rule cited carries its own last-updated month in its ID# footer, which the watch compares edition to edition. The next edition is expected in October 2026 [Inference].", "source_edition": "Visa Core Rules and Visa Product and Service Rules, 18 April 2026 edition (Visa Public), https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf", "source_class": "authoritative_primary", "source_title": "Visa Core Rules and Visa Product and Service Rules, 18 April 2026", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms the 120 day filing deadline from the transaction processing date, the receipt date or the counterfeit-notification date, the 540 day ceiling, and that this condition carries no waiting period (Table 11-113, VR 11.10.5.4), plus the category 12/13 process cycle with its country variants (Table 11-2, VR 11.2.3). Confirms the USD 25 T&E minimum with the Brazil Installment carve-out (Table 11-5, VR 11.4.3). Confirms the group is consumer-dispute category dispute resolution." } ] }, "rail_name": "Visa Disputes", "governing_authority": "Visa", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "visa-dispute:13.5", "id": "13.5", "rail": "visa-dispute", "kind": "reason-code", "name": "Misrepresentation", "group": "consumer-dispute", "summary": "Consumer dispute where the merchant misrepresented the terms of sale. Visa names high-risk sellers where the dispute applies, such as debt relief and credit repair sold card-absent, timeshare resale, fund recovery, business opportunities and investment platforms that block withdrawals.", "triggers": [ "The cardholder says the merchant misrepresented the terms of sale", "Card-absent trial, promotional, introductory or one-off purchases of goods or digital goods where the cardholder was not clearly told of further charges", "Card-absent sellers of financial rescue: card interest rate reduction, foreclosure relief, mortgage repair or counselling, credit repair or counselling, debt consolidation; judged by what is sold, not only the MCC", "Timeshare resellers and reseller advisers, or recovery of reseller fees, for property the merchant does not own", "Outbound telemarketing merchants; tech support or software sold through inaccurate online ads or carrying malicious downloads; business opportunities promising income or pressing for more purchases; merchants who promise to recover the cardholder's funds and do not", "Investment goods or services, such as binary options or foreign exchange trading, where the merchant refuses to let the cardholder withdraw an available balance" ], "actions": [ "Cardholder: try to resolve it with the merchant or its liquidator first, and return the goods or cancel the service; the dispute is limited to the unused service or the value of goods returned or offered back (VR 11.10.6.2, Table 11-117, ID# 0030338)", "Issuer: explain how the merchant's spoken or written statements differ from the agreed terms, and certify return or cancellation details, any refusal of the return, the date received and the attempt to resolve; for investment platforms, supply the account record at the time of the withdrawal request (or proof the account cannot be reached) and the merchant's acknowledgment of the request; for disputes based on ongoing negotiations, certify the dates and give evidence (VR 11.10.6.5, Table 11-120, ID# 0030341)", "Merchant: goods held by customs in the merchant's own country remain the merchant's responsibility" ], "retry": { "allowed": true, "rule": "Retry here means the Acquirer's right to contest. The Acquirer answers with a dispute response; the Issuer may reply with a pre-arbitration attempt, the Acquirer accepts it or declines it, and a case still open goes to arbitration filed by the Issuer (VR 11.2.3, Table 11-2, ID# 0030213). For 13.5 the dispute response may prove the terms were not misrepresented or show that the dispute fails this condition's rules, that the cardholder has withdrawn it, or that the Issuer left out a credit or reversal the merchant had already made; for a card-absent trial, promotional, introductory or one-off purchase, it must prove both that the cardholder expressly agreed to future charges at the first transaction and that the merchant gave notice at least 7 days before the charge (VR 11.10.6.6, Table 11-121, ID# 0030342). An Acquirer may answer a dispute only once, and a merchant must not put a disputed and returned transaction through again; it may still seek payment from the customer outside the Visa system (VR 11.2.1, ID# 0030211; VR 5.10.1.2, ID# 0003022)." }, "facts": { "return_windows": [ { "action": "dispute", "by": "Issuer", "deadline": "Not later than 120 calendar days from the Transaction Processing Date or from the date the cardholder received the goods or services, or 60 calendar days from the Issuer's first notice of the dispute where that notice shows negotiations with the merchant within 120 days of the Transaction Processing Date; the Dispute Processing Date never beyond 540 calendar days from the Transaction Processing Date. No waiting period" }, { "action": "dispute response", "by": "Acquirer", "deadline": "30 calendar days from the Dispute Processing Date" }, { "action": "dispute response", "by": "Acquirer (CEMEA Region, Nigeria domestic)", "deadline": "2 business days from the Dispute Processing Date" }, { "action": "dispute response", "by": "Acquirer (CEMEA Region, Tanzania domestic)", "deadline": "20 calendar days from the Dispute Processing Date" }, { "action": "pre-arbitration attempt", "by": "Issuer", "deadline": "30 calendar days from the Dispute Response Processing Date" }, { "action": "pre-arbitration attempt", "by": "Issuer (CEMEA Region, Tanzania domestic)", "deadline": "10 calendar days from the Dispute Response Processing Date" }, { "action": "pre-arbitration response (accept or decline)", "by": "Acquirer", "deadline": "30 calendar days from the Processing Date of the pre-arbitration attempt" }, { "action": "pre-arbitration response (accept or decline)", "by": "Acquirer (CEMEA Region, Tanzania domestic)", "deadline": "10 calendar days from the Processing Date of the pre-arbitration attempt" }, { "action": "arbitration filing", "by": "Issuer", "deadline": "10 calendar days from the Processing Date of the pre-arbitration response" } ], "applies_to": "All Visa Regions" }, "caveat": "Invalid under 13.5: a dispute only about quality (see 13.3); a Value-Added Tax dispute; the Cash-Back portion of a Visa Cash-Back Transaction; a Straight Through Processing Transaction (VR 11.10.6.3, Table 11-118, ID# 0030339). A T&E Transaction may be disputed under this condition only if the Transaction amount or the partial Dispute amount is at least USD 25 or the local equivalent; the minimum does not apply to Brazil domestic Installment Transactions (VR 11.4.3, Table 11-5, ID# 0030219). Day counts are calendar days unless stated, and the processing date of the event that starts a count is not itself counted (VR 11.2.1, ID# 0030211).", "related": [ "visa-dispute:13.3", "visa-dispute:13.2", "visa-dispute:13.1", "visa:return" ], "basis": { "sources": "Visa Core Rules and Visa Product and Service Rules, 18 April 2026 edition: VR 11.10.6.1 to 11.10.6.6 (ID# 0030337 to 0030342), Tables 11-116 to 11-121; VR 11.4.3, Table 11-5 (ID# 0030219); VR 11.2.1 (ID# 0030211); VR 11.2.3, Table 11-2 (ID# 0030213, stage deadlines and country notes); VR 5.10.1.2 (ID# 0003022); VR 11.6.1, Table 11-7 (ID# 0030222, region labels).", "confidence": "high" }, "currency": { "effective_since": "Before the current edition; start not stated in it", "effective_note": "Rules as in the 18 April 2026 edition of the Visa rules. Each rule cited carries its own last-updated month in its ID# footer, which the watch compares edition to edition. The next edition is expected in October 2026 [Inference].", "source_edition": "Visa Core Rules and Visa Product and Service Rules, 18 April 2026 edition (Visa Public), https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf", "source_class": "authoritative_primary", "source_title": "Visa Core Rules and Visa Product and Service Rules, 18 April 2026", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms the 120 day filing deadline from the transaction processing date or receipt date, the 60 day negotiation exception, the 540 day ceiling, and that this condition carries no waiting period (Table 11-119, VR 11.10.6.4), plus the category 12/13 process cycle with its country variants (Table 11-2, VR 11.2.3). Confirms the USD 25 T&E minimum with the Brazil Installment carve-out (Table 11-5, VR 11.4.3). Confirms the group is consumer-dispute category dispute resolution." } ] }, "rail_name": "Visa Disputes", "governing_authority": "Visa", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "visa-dispute:13.6", "id": "13.6", "rail": "visa-dispute", "kind": "reason-code", "name": "Credit Not Processed", "group": "consumer-dispute", "summary": "Consumer dispute where the cardholder holds a credit receipt or a voided receipt that the merchant never processed, or disputes an ATM adjustment (including an ATM Deposit Adjustment) because the original transaction was cancelled or reversed.", "triggers": [ "The cardholder received a credit or a voided Transaction Receipt and no credit was processed; a receipt marked void or cancelled supports the dispute (VR 11.10.7.2, Table 11-123, ID# 0030344)", "At an ATM, the cardholder disputes an Adjustment because the original Transaction had been cancelled or reversed" ], "actions": [ "Issuer: supply the Credit Transaction Receipt, the voided receipt, or another record proving a credit is due (VR 11.10.7.5, Table 11-126, ID# 0030347)", "Issuer: for disputes processed on or after 18 April 2026 more than 120 calendar days after the Transaction Processing Date, explain why the credit was requested late and give details of the cardholder's negotiations with the merchant" ], "retry": { "allowed": true, "rule": "Retry here means the Acquirer's right to contest. The Acquirer answers with a dispute response; the Issuer may reply with a pre-arbitration attempt, the Acquirer accepts it or declines it, and a case still open goes to arbitration filed by the Issuer (VR 11.2.3, Table 11-2, ID# 0030213). For 13.6 the dispute response may show only that the dispute fails this condition's rules, that the cardholder has withdrawn it, or that the Issuer left out a credit or reversal the merchant had already made (VR 11.10.7.6, Table 11-127, ID# 0030348). An Acquirer may answer a dispute only once, and a merchant must not put a disputed and returned transaction through again; it may still seek payment from the customer outside the Visa system (VR 11.2.1, ID# 0030211; VR 5.10.1.2, ID# 0003022)." }, "facts": { "return_windows": [ { "action": "dispute", "by": "Issuer", "deadline": "Not before 15 calendar days from the date on the Credit Transaction Receipt (no wait if the receipt is undated or the wait would pass the limit). Not later than 120 calendar days from that date, or, if undated, from the date the cardholder cancelled or returned; never beyond 540 calendar days from the Transaction Processing Date" }, { "action": "dispute", "by": "Issuer", "deadline": "For an ATM Transaction, not later than 120 calendar days from the Transaction Processing Date of the Adjustment, including an ATM Deposit Adjustment" }, { "action": "dispute response", "by": "Acquirer", "deadline": "30 calendar days from the Dispute Processing Date" }, { "action": "dispute response", "by": "Acquirer (CEMEA Region, Nigeria domestic)", "deadline": "2 business days from the Dispute Processing Date" }, { "action": "dispute response", "by": "Acquirer (CEMEA Region, Tanzania domestic)", "deadline": "20 calendar days from the Dispute Processing Date" }, { "action": "pre-arbitration attempt", "by": "Issuer", "deadline": "30 calendar days from the Dispute Response Processing Date" }, { "action": "pre-arbitration attempt", "by": "Issuer (CEMEA Region, Tanzania domestic)", "deadline": "10 calendar days from the Dispute Response Processing Date" }, { "action": "pre-arbitration response (accept or decline)", "by": "Acquirer", "deadline": "30 calendar days from the Processing Date of the pre-arbitration attempt" }, { "action": "pre-arbitration response (accept or decline)", "by": "Acquirer (CEMEA Region, Tanzania domestic)", "deadline": "10 calendar days from the Processing Date of the pre-arbitration attempt" }, { "action": "arbitration filing", "by": "Issuer", "deadline": "10 calendar days from the Processing Date of the pre-arbitration response" } ], "applies_to": "All Visa Regions" }, "caveat": "Invalid under 13.6: a claim that the transaction was fraud; an Automated Fuel Dispenser Transaction; the Cash-Back portion of a Visa Cash-Back Transaction; a Straight Through Processing Transaction; a Mobile Push Payment Transaction (VR 11.10.7.3, Table 11-124, ID# 0030345). Where the cardholder cancelled or returned but holds no credit receipt, 13.7 is the condition to consider [Inference]. A T&E Transaction may be disputed under this condition only if the Transaction amount or the partial Dispute amount is at least USD 25 or the local equivalent; the minimum does not apply to Brazil domestic Installment Transactions (VR 11.4.3, Table 11-5, ID# 0030219). Day counts are calendar days unless stated, and the processing date of the event that starts a count is not itself counted (VR 11.2.1, ID# 0030211).", "related": [ "visa-dispute:13.7", "visa-dispute:12.2", "visa:return", "visa:refund", "paypal-dispute:CREDIT_NOT_PROCESSED" ], "basis": { "sources": "Visa Core Rules and Visa Product and Service Rules, 18 April 2026 edition: VR 11.10.7.1 to 11.10.7.6 (ID# 0030343 to 0030348), Tables 11-122 to 11-127; VR 11.4.3, Table 11-5 (ID# 0030219); VR 11.2.1 (ID# 0030211); VR 11.2.3, Table 11-2 (ID# 0030213, stage deadlines and country notes); VR 5.10.1.2 (ID# 0003022); VR 11.6.1, Table 11-7 (ID# 0030222, region labels).", "confidence": "high" }, "currency": { "effective_since": "Before the current edition; start not stated in it", "effective_note": "Rules as in the 18 April 2026 edition of the Visa rules. Each rule cited carries its own last-updated month in its ID# footer, which the watch compares edition to edition. The next edition is expected in October 2026 [Inference].", "source_edition": "Visa Core Rules and Visa Product and Service Rules, 18 April 2026 edition (Visa Public), https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf", "source_class": "authoritative_primary", "source_title": "Visa Core Rules and Visa Product and Service Rules, 18 April 2026", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms the 15 day waiting period (waived when the credit receipt is undated), the 120 day filing deadline from the credit receipt date or the cancellation or return date, the 540 day ceiling, and the ATM adjustment variant counting from the adjustment processing date (Table 11-125, VR 11.10.7.4), plus the category 12/13 process cycle with its country variants (Table 11-2, VR 11.2.3). Confirms the USD 25 T&E minimum with the Brazil Installment carve-out (Table 11-5, VR 11.4.3). Confirms the group is consumer-dispute category dispute resolution." } ] }, "rail_name": "Visa Disputes", "governing_authority": "Visa", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "visa-dispute:13.7", "id": "13.7", "rail": "visa-dispute", "kind": "reason-code", "name": "Cancelled Merchandise/Services", "group": "consumer-dispute", "summary": "Consumer dispute where the cardholder cancelled or returned goods, or cancelled services, a timeshare or a Guaranteed Reservation, and got no credit because the merchant did not disclose, or did not apply, a limited return or cancellation policy; in Europe it also covers the 14-day right to cancel off-premises and distance contracts.", "triggers": [ "The cardholder cancelled or returned goods or cancelled services, a timeshare or a Guaranteed Reservation, and the merchant processed no credit or voided receipt", "The merchant had not properly disclosed a limited return or cancellation policy at the time of the Transaction, or disclosed it and then did not apply it", "Timeshare: cancelled within 14 calendar days of the contract date or of receiving the contract or related documents (later cancellations must follow a properly disclosed policy), or processed under the wrong MCC", "Guaranteed Reservation: billed as a No-Show after a cancellation that followed the policy, after a cancellation attempt within 24 hours of the confirmation, or for more than one day's stay or rental plus taxes", "Europe: cancellation within 14 days of an off-premises or distance contract under the EU directive, except for goods not in physical form such as downloads, sealed goods under health and safety rules, goods that spoil or expire quickly, made-to-measure goods, goods priced by financial markets, T&E Transactions, and Merchant Outlets in Israel, Switzerland or Türkiye (VR 11.10.8.2, Table 11-129, ID# 0030350)" ], "actions": [ "Cardholder: try to resolve it with the merchant or its liquidator (a cancellation counts as the attempt); return goods already shipped and received. The dispute still applies if the merchant refuses the returned goods. It is limited to the unused service or the value of goods returned", "Issuer: certify the facts for the case at hand. For ordinary goods and services: a description of the goods beyond the clearing data (unless Enhanced Data describes them), the expected or received date, the cancellation or return date, shipping details, or how the merchant refused or blocked a return and where the goods are. For a No-Show: the expected service date and the cancellation or overbilling. For a timeshare: cancellation and contract dates. In Europe for distance contracts, the contract start date and a cancellation inside 14 days (VR 11.10.8.5, Table 11-132, ID# 0030353)", "Merchant: goods held by customs in the merchant's own country remain the merchant's responsibility" ], "retry": { "allowed": true, "rule": "Retry here means the Acquirer's right to contest. The Acquirer answers with a dispute response; the Issuer may reply with a pre-arbitration attempt, the Acquirer accepts it or declines it, and a case still open goes to arbitration filed by the Issuer (VR 11.2.3, Table 11-2, ID# 0030213). For 13.7 the dispute response may show that the dispute fails this condition's rules, that the cardholder has withdrawn it, or that the Issuer left out a credit or reversal the merchant had already made, or prove with a receipt or record that the merchant properly disclosed a limited return or cancellation policy at the time (VR 5.4.2.5), or that the cardholder received the policy and did not cancel by it (VR 11.10.8.6, Table 11-133, ID# 0030354). The Issuer's pre-arbitration attempt may show the cardholder did not receive services the merchant says it rendered, for example a stay at another hotel on the same nights (VR 11.10.8.7, Table 11-134, ID# 0031087). An Acquirer may answer a dispute only once, and a merchant must not put a disputed and returned transaction through again; it may still seek payment from the customer outside the Visa system (VR 11.2.1, ID# 0030211; VR 5.10.1.2, ID# 0003022)." }, "facts": { "return_windows": [ { "action": "dispute", "by": "Issuer", "deadline": "Not before 15 calendar days after the goods were returned or the goods or services cancelled (no wait if it would pass the limit or the merchant refuses the cancellation or return). Not later than 120 calendar days from the Transaction Processing Date, from the date the cardholder received or expected the goods or services (never beyond 540 calendar days from the Transaction Processing Date), or, for an Adjustment of a PIN-Authenticated Visa Debit Transaction, from the date of the Adjustment" }, { "action": "dispute response", "by": "Acquirer", "deadline": "30 calendar days from the Dispute Processing Date" }, { "action": "dispute response", "by": "Acquirer (CEMEA Region, Nigeria domestic)", "deadline": "2 business days from the Dispute Processing Date" }, { "action": "dispute response", "by": "Acquirer (CEMEA Region, Tanzania domestic)", "deadline": "20 calendar days from the Dispute Processing Date" }, { "action": "pre-arbitration attempt", "by": "Issuer", "deadline": "30 calendar days from the Dispute Response Processing Date" }, { "action": "pre-arbitration attempt", "by": "Issuer (CEMEA Region, Tanzania domestic)", "deadline": "10 calendar days from the Dispute Response Processing Date" }, { "action": "pre-arbitration response (accept or decline)", "by": "Acquirer", "deadline": "30 calendar days from the Processing Date of the pre-arbitration attempt" }, { "action": "pre-arbitration response (accept or decline)", "by": "Acquirer (CEMEA Region, Tanzania domestic)", "deadline": "10 calendar days from the Processing Date of the pre-arbitration attempt" }, { "action": "arbitration filing", "by": "Issuer", "deadline": "10 calendar days from the Processing Date of the pre-arbitration response" } ], "applies_to": "All Visa Regions; Europe adds the 14-day off-premises and distance-selling right" }, "caveat": "Invalid under 13.7, grouped by Orca: (a) quality or Value-Added Tax complaints, unless a Credit Transaction Receipt is provided; (b) returned goods held by a customs agency other than the one in the merchant's country (not a bar for Europe distance-selling transactions); (c) a claim that the transaction was fraud; (d) types: ATM Cash Disbursement, Straight Through Processing Transaction, Automated Fuel Dispenser Transaction, the Cash-Back portion of a Visa Cash-Back Transaction (VR 11.10.8.3, Table 11-130, ID# 0030351). A T&E Transaction may be disputed under this condition only if the Transaction amount or the partial Dispute amount is at least USD 25 or the local equivalent; the minimum does not apply to Brazil domestic Installment Transactions (VR 11.4.3, Table 11-5, ID# 0030219). Day counts are calendar days unless stated, and the processing date of the event that starts a count is not itself counted (VR 11.2.1, ID# 0030211).", "related": [ "visa-dispute:13.6", "visa-dispute:13.1", "visa-dispute:13.2", "visa-dispute:13.3", "visa:return", "visa:refund" ], "basis": { "sources": "Visa Core Rules and Visa Product and Service Rules, 18 April 2026 edition: VR 11.10.8.1 to 11.10.8.7 (ID# 0030349 to 0030354, 0031087), Tables 11-128 to 11-134; VR 11.4.3, Table 11-5 (ID# 0030219); VR 11.2.1 (ID# 0030211); VR 11.2.3, Table 11-2 (ID# 0030213, stage deadlines and country notes); VR 5.10.1.2 (ID# 0003022); VR 11.6.1, Table 11-7 (ID# 0030222, region labels).", "confidence": "high" }, "currency": { "effective_since": "Before the current edition; start not stated in it", "effective_note": "Rules as in the 18 April 2026 edition of the Visa rules. Each rule cited carries its own last-updated month in its ID# footer, which the watch compares edition to edition. The next edition is expected in October 2026 [Inference].", "source_edition": "Visa Core Rules and Visa Product and Service Rules, 18 April 2026 edition (Visa Public), https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf", "source_class": "authoritative_primary", "source_title": "Visa Core Rules and Visa Product and Service Rules, 18 April 2026", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms the 15 day waiting period, the 120 day filing deadline from the transaction processing date, the receipt or expected receipt date (540 day ceiling), or a PIN-debit adjustment date (Table 11-131, VR 11.10.8.4), plus the category 12/13 process cycle with its country variants (Table 11-2, VR 11.2.3). Confirms the USD 25 T&E minimum with the Brazil Installment carve-out (Table 11-5, VR 11.4.3). Confirms the group is consumer-dispute category dispute resolution." } ] }, "rail_name": "Visa Disputes", "governing_authority": "Visa", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "visa-dispute:13.8", "id": "13.8", "rail": "visa-dispute", "kind": "reason-code", "name": "Original Credit Transaction Not Accepted", "group": "consumer-dispute", "summary": "Dispute by the recipient's Issuer when an Original Credit Transaction (a push of funds to a card) is not accepted, because the recipient refused it or because law bars Original Credit Transactions. Visa files it in category 13 although it is not a purchase dispute.", "triggers": [ "The recipient refused the Original Credit Transaction", "Applicable law or regulation prohibits Original Credit Transactions" ], "actions": [ "Issuer: certify which of the two applies (VR 11.10.9.4, Table 11-138, ID# 0030358)" ], "retry": { "allowed": true, "rule": "Retry here means the Acquirer's right to contest. The Acquirer answers with a dispute response; the Issuer may reply with a pre-arbitration attempt, the Acquirer accepts it or declines it, and a case still open goes to arbitration filed by the Issuer (VR 11.2.3, Table 11-2, ID# 0030213). For 13.8 the dispute response may show only that the dispute is invalid or that the Issuer left out a Reversal already made (VR 11.10.9.5, Table 11-139, ID# 0030359). An Acquirer may answer a dispute only once, and a merchant must not put a disputed and returned transaction through again; it may still seek payment from the customer outside the Visa system (VR 11.2.1, ID# 0030211; VR 5.10.1.2, ID# 0003022)." }, "facts": { "return_windows": [ { "action": "dispute", "by": "Issuer", "deadline": "120 calendar days from the Original Credit Transaction Processing Date" }, { "action": "dispute response", "by": "Acquirer", "deadline": "30 calendar days from the Dispute Processing Date" }, { "action": "dispute response", "by": "Acquirer (CEMEA Region, Nigeria domestic)", "deadline": "2 business days from the Dispute Processing Date" }, { "action": "dispute response", "by": "Acquirer (CEMEA Region, Tanzania domestic)", "deadline": "20 calendar days from the Dispute Processing Date" }, { "action": "pre-arbitration attempt", "by": "Issuer", "deadline": "30 calendar days from the Dispute Response Processing Date" }, { "action": "pre-arbitration attempt", "by": "Issuer (CEMEA Region, Tanzania domestic)", "deadline": "10 calendar days from the Dispute Response Processing Date" }, { "action": "pre-arbitration response (accept or decline)", "by": "Acquirer", "deadline": "30 calendar days from the Processing Date of the pre-arbitration attempt" }, { "action": "pre-arbitration response (accept or decline)", "by": "Acquirer (CEMEA Region, Tanzania domestic)", "deadline": "10 calendar days from the Processing Date of the pre-arbitration attempt" }, { "action": "arbitration filing", "by": "Issuer", "deadline": "10 calendar days from the Processing Date of the pre-arbitration response" } ], "applies_to": "All Visa Regions" }, "caveat": "The only invalid case listed is a Mobile Push Payment Transaction (VR 11.10.9.2, Table 11-136, ID# 0030553). The USD 25 T&E minimum dispute amount does not apply to this condition (VR 11.4.3, Table 11-5, ID# 0030219). In this condition the Acquirer's side is the one that originated the push [Inference]. Day counts are calendar days unless stated, and the processing date of the event that starts a count is not itself counted (VR 11.2.1, ID# 0030211).", "related": [ "visa:return" ], "basis": { "sources": "Visa Core Rules and Visa Product and Service Rules, 18 April 2026 edition: VR 11.10.9.1 to 11.10.9.5 (ID# 0030355, 0030553, 0030357, 0030358, 0030359), Tables 11-135 to 11-139; VR 11.4.3, Table 11-5 (ID# 0030219); VR 11.2.1 (ID# 0030211); VR 11.2.3, Table 11-2 (ID# 0030213, stage deadlines and country notes); VR 5.10.1.2 (ID# 0003022); VR 11.6.1, Table 11-7 (ID# 0030222, region labels).", "confidence": "high" }, "currency": { "effective_since": "Before the current edition; start not stated in it", "effective_note": "Rules as in the 18 April 2026 edition of the Visa rules. Each rule cited carries its own last-updated month in its ID# footer, which the watch compares edition to edition. The next edition is expected in October 2026 [Inference].", "source_edition": "Visa Core Rules and Visa Product and Service Rules, 18 April 2026 edition (Visa Public), https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf", "source_class": "authoritative_primary", "source_title": "Visa Core Rules and Visa Product and Service Rules, 18 April 2026", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms the 120 calendar day filing deadline from the Original Credit Transaction processing date (Table 11-137, VR 11.10.9.3), and the category 12/13 process cycle (Table 11-2, VR 11.2.3). Confirms the USD 25 T&E minimum dispute amount does not apply to this condition (Table 11-5, VR 11.4.3). Confirms the group is consumer-dispute category dispute resolution." } ] }, "rail_name": "Visa Disputes", "governing_authority": "Visa", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "visa-dispute:13.9", "id": "13.9", "rail": "visa-dispute", "kind": "reason-code", "name": "Non-Receipt of Cash at an ATM", "group": "consumer-dispute", "summary": "Consumer dispute where the cardholder used an ATM and received no cash or only part of the amount. The dispute covers only the amount not received.", "triggers": [ "The cardholder took part in an ATM Transaction and received no cash or a partial amount" ], "actions": [ "Issuer: dispute only the amount not received (VR 11.10.10.2, Table 11-141, ID# 0030361)", "Issuer: certify that no cash was received, or that part was and how much; supply a signed cardholder letter when the cardholder has disputed 3 or more non-receipt-of-cash transactions within one 30-day period (VR 11.10.10.5, Table 11-144, ID# 0030364)" ], "retry": { "allowed": true, "rule": "Retry here means the Acquirer's right to contest. The Acquirer answers with a dispute response; the Issuer may reply with a pre-arbitration attempt, the Acquirer accepts it or declines it, and a case still open goes to arbitration filed by the Issuer (VR 11.2.3, Table 11-2, ID# 0030213). For 13.9 the dispute response may supply the ATM Cash Disbursement record showing the credential, a time or sequence number for the transaction, and an indicator that the cash was dispensed, or show that the dispute fails this condition's rules, that the cardholder has withdrawn it, or that the Issuer left out a credit or reversal the merchant had already made (VR 11.10.10.6, Table 11-145, ID# 0030365). An Acquirer may answer a dispute only once, and a merchant must not put a disputed and returned transaction through again; it may still seek payment from the customer outside the Visa system (VR 11.2.1, ID# 0030211; VR 5.10.1.2, ID# 0003022)." }, "facts": { "return_windows": [ { "action": "dispute", "by": "Issuer", "deadline": "120 calendar days from the Transaction Processing Date" }, { "action": "dispute", "by": "Issuer (US domestic)", "deadline": "For an Adjustment of an ATM Cash Disbursement or a PIN-Authenticated Visa Debit Transaction, 120 calendar days from the Transaction Date of the Adjustment" }, { "action": "dispute response", "by": "Acquirer", "deadline": "30 calendar days from the Dispute Processing Date" }, { "action": "dispute response", "by": "Acquirer (AP Region, India domestic ATM Transaction)", "deadline": "6 calendar days from the Dispute Processing Date" }, { "action": "dispute response", "by": "Acquirer (CEMEA Region, Egypt domestic ATM Transaction)", "deadline": "10 calendar days from the Dispute Processing Date" }, { "action": "dispute response", "by": "Acquirer (Europe Region, Poland domestic ATM Transaction)", "deadline": "20 calendar days from the Dispute Processing Date" }, { "action": "dispute response", "by": "Acquirer (CEMEA Region, Nigeria domestic)", "deadline": "2 business days from the Dispute Processing Date" }, { "action": "dispute response", "by": "Acquirer (CEMEA Region, Tanzania domestic)", "deadline": "20 calendar days from the Dispute Processing Date" }, { "action": "pre-arbitration attempt", "by": "Issuer", "deadline": "30 calendar days from the Dispute Response Processing Date" }, { "action": "pre-arbitration attempt", "by": "Issuer (CEMEA Region, Tanzania domestic)", "deadline": "10 calendar days from the Dispute Response Processing Date" }, { "action": "pre-arbitration response (accept or decline)", "by": "Acquirer", "deadline": "30 calendar days from the Processing Date of the pre-arbitration attempt" }, { "action": "pre-arbitration response (accept or decline)", "by": "Acquirer (CEMEA Region, Tanzania domestic)", "deadline": "10 calendar days from the Processing Date of the pre-arbitration attempt" }, { "action": "arbitration filing", "by": "Issuer", "deadline": "10 calendar days from the Processing Date of the pre-arbitration response" } ], "applies_to": "All Visa Regions, with a US domestic row for adjustments and shorter dispute response limits for domestic ATM Transactions in Egypt, India and Poland" }, "caveat": "Invalid under 13.9: a transaction processed more than once, which belongs under 12.6; a claim that the transaction was fraud; a Cash-Out or Cash-In Transaction (VR 11.10.10.3, Table 11-142, ID# 0030362). The USD 25 T&E minimum dispute amount does not apply to this condition (VR 11.4.3, Table 11-5, ID# 0030219). Day counts are calendar days unless stated, and the processing date of the event that starts a count is not itself counted (VR 11.2.1, ID# 0030211).", "related": [ "visa-dispute:12.6", "visa:return" ], "basis": { "sources": "Visa Core Rules and Visa Product and Service Rules, 18 April 2026 edition: VR 11.10.10.1 to 11.10.10.6 (ID# 0030360 to 0030365), Tables 11-140 to 11-145; VR 11.4.3, Table 11-5 (ID# 0030219); VR 11.2.1 (ID# 0030211); VR 11.2.3, Table 11-2 (ID# 0030213, stage deadlines and country notes); VR 5.10.1.2 (ID# 0003022); VR 11.6.1, Table 11-7 (ID# 0030222, region labels).", "confidence": "high" }, "currency": { "effective_since": "Before the current edition; start not stated in it", "effective_note": "Rules as in the 18 April 2026 edition of the Visa rules. Each rule cited carries its own last-updated month in its ID# footer, which the watch compares edition to edition. The next edition is expected in October 2026 [Inference].", "source_edition": "Visa Core Rules and Visa Product and Service Rules, 18 April 2026 edition (Visa Public), https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf", "source_class": "authoritative_primary", "source_title": "Visa Core Rules and Visa Product and Service Rules, 18 April 2026", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms the 120 calendar day filing deadline from the transaction processing date, with the US domestic ATM cash and PIN-debit adjustment variant counting from the adjustment date instead (Table 11-143, VR 11.10.10.4), and the category 12/13 process cycle (Table 11-2, VR 11.2.3). Confirms the USD 25 T&E minimum dispute amount does not apply to this condition (Table 11-5, VR 11.4.3). Confirms the group is consumer-dispute category dispute resolution." } ] }, "rail_name": "Visa Disputes", "governing_authority": "Visa", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] } ], "facts": [ { "uid": "apple-pay:consumer-law", "id": "consumer-law", "rail": "apple-pay", "kind": "rail-fact", "facet": "consumer-law", "name": "What consumer protection reaches an Apple Pay payment?", "statement": "Whatever reaches the card, because the card is what pays. Apple Pay is a technology service from Apple Inc. affiliates, the provider differs by the cardholder's location and is Apple Payments Services LLC in the United States, and neither Apple Inc. nor the affiliate providing Apple Pay is a bank. Any card used in Apple Pay is offered by the card issuer, and the cardholder agreement, the user agreement, the merchant agreement and any other terms that apply keep governing the cards and their use in Apple Pay. Apple's privacy notice says it is in addition to whatever the bank tells the cardholder, not in place of it. So the protections are the card's, the issuer's and the law that reaches them, and none of them is created or removed by the wallet. No law was read for this rail.", "details": [ { "label": "Who provides Apple Pay, and that the provider is not a bank", "value": "Apple Pay is a technology service provided by Apple Inc. affiliates, which are responsible for the personal data it handles, and the provider differs by the cardholder's location: in the United States it is Apple Payments Services LLC, a subsidiary of Apple Inc. Neither Apple Inc. nor the affiliate providing Apple Pay is a bank, and any card used in Apple Pay is offered by the card issuer. In the Apple Pay API terms of the Developer Program License Agreement, Apple means Apple Payments Services LLC for a developer in the United States, with an Austin, Texas address.", "citation": "Apple Pay and privacy notice, who provides Apple Pay; closing paragraph; Apple Support article 118270, Get a refund for purchases made with credit or debit cards using Apple Pay, closing paragraph; Apple Pay developer overview page, footer; Apple Developer Program License Agreement (public copy, Agreement and Schedule 1 last updated 2026-08-18), 3.3.9(C), closing sentence", "rests_on": "rule" }, { "label": "The card, cardholder and merchant agreements keep governing", "value": "Any cardholder agreement, user agreement, merchant agreement or other terms that apply to the features of Apple Pay keep governing the cards and their use in Apple Pay, and those terms may carry privacy policies of their own. Apple's notice is in addition to whatever a bank tells the cardholder, not in place of it. So a cardholder's rights over a payment made with Apple Pay are the rights the card gives, and a merchant's duties are the duties its acquiring agreement and the network rules give.", "citation": "Apple Pay and privacy notice, closing paragraph", "rests_on": "rule" }, { "label": "Apple is not a party to the payment and is not responsible for it", "value": "Apple is not a party to any payment transaction facilitated through the Apple Pay APIs and is not responsible for one, and the agreement names the unavailability of an end user payment card and payment fraud among the things it is not responsible for. The payment runs between the developer and its own bank, acquirer, card networks and any other party it uses for transaction processing, and the developer must comply with whatever those agreements say, which may put rights, duties or limits on it that follow from its choice to use the Apple Pay APIs. For this part of the agreement, Apple means Apple Payments Services LLC where the developer is in the United States. Nothing in the wallet decides whether a payment is final, whether it can be undone, or who bears a loss; the card network, the issuer and the acquiring agreement decide all three.", "citation": "Apple Developer Program License Agreement (public copy, Agreement and Schedule 1 last updated 2026-08-18), 3.3.9(C)(i), not a party clause, and the closing sentence of 3.3.9(C)", "rests_on": "rule" }, { "label": "Apple publishes no dispute channel of its own for a merchant purchase", "value": "For a card purchase from a merchant, nothing in the pages read offers an Apple route to dispute the payment, claim it was unauthorised or force money back. Apple's published consumer guidance after such a purchase covers refunds by the merchant and nothing else. Apple's terms put the payment outside Apple, and the card, cardholder and merchant agreements keep governing, so a cardholder disputes the payment with the card issuer under the card's rules, and the merchant answers it under its acquiring agreement and the network's rules.", "citation": "Apple Support article 118270, Get a refund for purchases made with credit or debit cards using Apple Pay, whole article; Apple Pay and privacy notice, closing paragraph; Apple Developer Program License Agreement (public copy, Agreement and Schedule 1 last updated 2026-08-18), 3.3.9(C)(i), not a party clause", "rests_on": "guidance" } ], "exceptions": [ "Apple Pay handles personal data under its own privacy notice and, for a developer, under the payload rules of the Developer Program License Agreement; those are data duties, not payment protections." ], "applies_to": "Apple Pay used to pay a merchant with a credit, debit or prepaid card held in Wallet, in an app, on the web, or in a store. Not Apple Cash, not Apple Card, not Wallet passes, and not a purchase from Apple itself.", "caveat": "No statute, regulation or regulator publication was read for this rail. Everything here is what Apple states about its own status, so the record can say who is not a bank but cannot say what any particular law gives a cardholder.", "related": [ "visa:consumer-law", "mastercard:consumer-law", "google-pay:consumer-law" ], "basis": { "sources": "Apple Pay and privacy notice; support article 118270; Apple Pay developer overview; Developer Program License Agreement 3.3.9(C); read 2026-09-20.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the notice carries no date", "effective_to": null, "effective_note": "Drafted 2026-09-20 from the Apple pages saved that day. The date is the last-updated date the Developer Program License Agreement gives for itself and Schedule 1; the other pages carry no date, and each Rule dates its own source. Nothing here dates the card network's rules, which change with their own rulebooks and are held in the visa and mastercard rails.", "source_edition": "Apple Pay and privacy notice, undated page, read in full 2026-09-20 from the copy saved that day", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.apple.com/legal/privacy/data/en/apple-pay/", "source_class": "public_primary", "source_title": "Apple Pay and privacy notice", "checked_on": "2026-09-20", "checked_by": "validator-pass-through-wallets-2026-09-20", "notes": "Confirms Apple Pay is a technology service from Apple affiliates that is not a bank, that any card is offered by the card issuer, and that cardholder, user and merchant agreements keep governing the card's use in Apple Pay." } ] }, "rail_name": "Apple Pay (pass-through wallet)", "governing_authority": "Apple, through the Apple Developer Program License Agreement and the Acceptable Use Guidelines for Apple Pay on the Web, for the wallet's own rules; the card network, the card issuer and the merchant's acquirer for the payment itself", "snapshot": "2026-09-20", "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "apple-pay:decision-points", "id": "decision-points", "rail": "apple-pay", "kind": "rail-fact", "facet": "decision-points", "name": "Who decides what, and when, in an Apple Pay payment?", "statement": "Four decisions belong to someone other than the wallet, and two belong to Apple. The card issuer and the payment network decide whether a card may be set up in Wallet and what verification the cardholder must pass. The cardholder decides each payment by authenticating on the device. The merchant decides whether to accept the token: it verifies the signature, the certificate chain and the hashes, checks that the signing time is within five minutes of the transaction time, checks that no payment with the same transaction identifier has been processed, checks the currency, amount and application data against the original request, and then either processes the payment or ignores the transaction. The issuer decides the authorisation itself, under the network's rules. Apple's own decisions are narrow: it may disable Apple Pay on a website at any time for any reason it deems prudent, and it may require a developer to stop using a merchant that mishandles the payload.", "details": [ { "label": "The issuer and the payment network decide whether a card goes into the wallet", "value": "Setting a card up in Apple Pay is the card issuer's and payment network's decision, not Apple's. Card-related information, location, device settings and use patterns may go to Apple and be used with account information to give the issuer or network assessments for setting Apple Pay up and preventing fraud, and account and paired-device details may be shared with the issuer or bank to decide eligibility and against fraud. Where a card is added through a bank's own application, that application sends a card or account identifier to the device, which Apple and the issuer use to decide eligibility and prevent fraud. Apple checks feature eligibility by the country the card was issued in and whether the issuer takes part. Apple does not store the original card number; it stores a card reference against the Apple Account so a card can be re-added after the security code is entered. Where Apple suspects fraud, information about the account and transactions may go to the issuer or network.", "citation": "Apple Pay and privacy notice, setting up Apple Pay; adding a card from a third-party app; feature eligibility; closing paragraph", "rests_on": "rule" }, { "label": "The cardholder authenticates on the device before every payment", "value": "Every transaction on the customer's iPhone or iPad calls for Face ID, Touch ID or the passcode, and an Apple Watch has to have its passcode entered again each time it is taken off the wrist before it can be used. Apple presents this, with the merchant not receiving the real card number, as what makes accepting Apple Pay more secure than accepting a card directly. What that authentication is worth in a dispute is a card network question, not Apple's: the network decides whether and when authentication moves liability.", "citation": "Apple Pay developer overview page, Data is more secure", "rests_on": "guidance" }, { "label": "The checks a merchant runs on a payment token before it decrypts", "value": "Before it can use a payment token the merchant verifies the signature. It checks that the certificates carry the right custom object identifiers, 1.2.840.113635.100.6.29 on the leaf certificate and 1.2.840.113635.100.6.2.14 on the intermediate certificate authority, where only their presence counts and not their value. It checks that the root is the Apple Root CA G3, published by Apple's certificate authority. It checks that a valid X.509 chain of trust runs from the signature to that root. It checks the token's own signature: for EC_v1 an ECDSA signature with SHA-256 over the joined ephemeral public key, data, transaction identifier and application data values; for RSA_v1 an RSA signature with SHA-256 over the joined wrapped key, data, transaction identifier and application data values. Then it uses the public key hash to find which merchant public key Apple used, retrieves that certificate and its private key, restores the symmetric key, and decrypts the data value with AES-256 in GCM mode for EC_v1 or AES-128 in GCM mode for RSA_v1, in both cases with an initialisation vector of sixteen null bytes and no associated authentication data.", "citation": "Payment token format reference (PassKit documentation), steps 1 to 4", "rests_on": "rule" }, { "label": "The merchant checks the transaction details, then either processes or ignores it", "value": "After decryption the merchant checks the payment against what it knows about the request: that the currency code matches the currency of the original payment request, that the transaction amount matches the total charge, and that the application data field matches the hash of the data the original request used and that the data is right, for instance that an order number in it is the order the payment is being applied to. If the signature is valid, the hash values match and the merchant's own validation passes, it uses the decrypted payment data to process the payment. Otherwise it ignores the transaction. The same instruction closes the signature step: where the signature is invalid or a hash does not match, ignore the transaction.", "citation": "Payment token format reference (PassKit documentation), steps 1, 6 and 7", "rests_on": "rule" }, { "label": "A repeated transaction identifier means the payment was already credited", "value": "Before it credits a payment the merchant confirms that no payment carrying the same transaction identifier already shows as processed. The reference says it is enough to look at payments whose transaction time falls inside the same five minute window as the identifier being checked. The transaction identifier is generated on the device and travels in the token header.", "citation": "Payment token format reference (PassKit documentation), step 5; header keys and values, transactionId", "rests_on": "rule" }, { "label": "Apple may disable Apple Pay on a website at any time", "value": "Apple reserves the right, at any time, to disable Apple Pay transactions on a business's websites for any reason it deems prudent. No ground has to be shown and the prohibited-use list does not limit it. The guidelines set no notice, no procedure and no review.", "citation": "Acceptable Use Guidelines for Apple Pay on the Web, Prohibited Uses, closing sentence", "rests_on": "rule" }, { "label": "What an intermediary party owes", "value": "A party that passes an end user's payload to a merchant, or supplies an application that lets merchants take Tap to Pay payments or run customer engagement interactions, carries five duties. It may use the payload only to facilitate that payment between the merchant and the end user and for its own order management as part of that transaction. It may hold the data no longer than those purposes need. It may not combine data from the Apple Pay APIs with other data it holds about the end user, except so far as order management needs, and specifically may not use it to advertise, to market, to build or improve a user profile or to target the end user. It must tell end users it is an intermediary and name the merchant for the transaction on the Apple Pay payment sheet, alongside its own name. And where it uses a merchant, it must make sure that merchant uses the payload only to process the payment and for uses it has disclosed, must have a written agreement with that merchant at least as protective of Apple as its own, is treated as having taken whatever that merchant does, and can be required by Apple to stop using it.", "citation": "Apple Developer Program License Agreement (public copy, Agreement and Schedule 1 last updated 2026-08-18), 3.3.9(C)(ii), second case, items (a) to (e); definitions, Intermediary Party", "rests_on": "rule" } ], "exceptions": [ "Apple's right to disable Apple Pay on a site carries no notice period, no procedure and no review in the guidelines.", "Nothing in the pages read says what a merchant must tell the cardholder or Apple when it ignores a transaction." ], "applies_to": "Apple Pay used to pay a merchant with a credit, debit or prepaid card held in Wallet, in an app, on the web, or in a store. Not Apple Cash, not Apple Card, not Wallet passes, and not a purchase from Apple itself.", "caveat": "The decision that matters most to the payment, whether the issuer authorises it, is not on this rail at all. Read visa:decision-points or mastercard:decision-points for it.", "related": [ "visa:decision-points", "mastercard:decision-points", "google-pay:decision-points" ], "basis": { "sources": "Payment token format reference, steps 1 to 7; Acceptable Use Guidelines for Apple Pay on the Web; Apple Pay and privacy notice; Developer Program License Agreement 3.3.9(C)(ii); read 2026-09-20.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the reference carries no date", "effective_to": null, "effective_note": "Drafted 2026-09-20 from the Apple pages saved that day. The date is the last-updated date the Developer Program License Agreement gives for itself and Schedule 1; the other pages carry no date, and each Rule dates its own source. Nothing here dates the card network's rules, which change with their own rulebooks and are held in the visa and mastercard rails.", "source_edition": "Payment token format reference, PassKit documentation, undated page, read in full 2026-09-20 from the page data saved that day (the HTML is a script shell; the same page's JSON was read)", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "rail_name": "Apple Pay (pass-through wallet)", "governing_authority": "Apple, through the Apple Developer Program License Agreement and the Acceptable Use Guidelines for Apple Pay on the Web, for the wallet's own rules; the card network, the card issuer and the merchant's acquirer for the payment itself", "snapshot": "2026-09-20", "source_class": null, "effective_status": "draft", "effective_status_reason": null, "boundaries": [] }, { "uid": "apple-pay:finality", "id": "finality", "rail": "apple-pay", "kind": "rail-fact", "facet": "finality", "name": "When is an Apple Pay payment final, and can it be undone?", "statement": "Apple Pay decides neither. Apple's own agreement says Apple is not a party to a payment made through the Apple Pay APIs and is not responsible for one, and that the payment runs between the merchant and its bank, its acquirer and the card networks. So finality is the card network's question, answered by the visa and mastercard facts and by the issuer's and acquirer's agreements, and the wallet adds nothing to it and takes nothing from it. What Apple does rule is narrower: the credential it hands over is checked by the merchant before anything is presented for authorisation, and a token whose signature fails, whose signing time is more than five minutes from the transaction time, or whose transaction identifier has already been processed is ignored, so the payment never reaches the network at all. Once it does reach the network, nothing in the wallet can pull it back.", "details": [ { "label": "Apple is not a party to the payment and is not responsible for it", "value": "Apple is not a party to any payment transaction facilitated through the Apple Pay APIs and is not responsible for one, and the agreement names the unavailability of an end user payment card and payment fraud among the things it is not responsible for. The payment runs between the developer and its own bank, acquirer, card networks and any other party it uses for transaction processing, and the developer must comply with whatever those agreements say, which may put rights, duties or limits on it that follow from its choice to use the Apple Pay APIs. For this part of the agreement, Apple means Apple Payments Services LLC where the developer is in the United States. Nothing in the wallet decides whether a payment is final, whether it can be undone, or who bears a loss; the card network, the issuer and the acquiring agreement decide all three.", "citation": "Apple Developer Program License Agreement (public copy, Agreement and Schedule 1 last updated 2026-08-18), 3.3.9(C)(i), not a party clause, and the closing sentence of 3.3.9(C)", "rests_on": "rule" }, { "label": "The merchant processes the payment through its own bank, acquirer and networks", "value": "Processing an Apple Pay payment is the merchant's own arrangement. The agreement puts the payment between the developer and its bank, its acquirer, the card networks and any other party it uses for transaction processing, and makes the developer responsible for complying with each of those agreements. Apple supplies no acquiring, no clearing and no settlement, and a merchant that wants to accept Apple Pay needs a payment service provider that supports it.", "citation": "Apple Developer Program License Agreement (public copy, Agreement and Schedule 1 last updated 2026-08-18), 3.3.9(C)(i), not a party clause; Apple Pay developer overview page, Find a PSP that supports Apple Pay", "rests_on": "rule" }, { "label": "The merchant checks the transaction details, then either processes or ignores it", "value": "After decryption the merchant checks the payment against what it knows about the request: that the currency code matches the currency of the original payment request, that the transaction amount matches the total charge, and that the application data field matches the hash of the data the original request used and that the data is right, for instance that an order number in it is the order the payment is being applied to. If the signature is valid, the hash values match and the merchant's own validation passes, it uses the decrypted payment data to process the payment. Otherwise it ignores the transaction. The same instruction closes the signature step: where the signature is invalid or a hash does not match, ignore the transaction.", "citation": "Payment token format reference (PassKit documentation), steps 1, 6 and 7", "rests_on": "rule" }, { "label": "A token signed more than five minutes from the transaction time may be a replay", "value": "When it verifies an Apple Pay payment token, the merchant inspects the signing time of the cryptographic message syntax signature, as RFC 5652 section 11.3 defines it. If that time and the transaction time differ by more than five minutes, the token may be a replay attack. This is the only clock Apple sets for an Apple Pay payment: the wallet keeps no operating hours, no cut-off times and no settlement calendar, because it settles nothing.", "citation": "Payment token format reference (PassKit documentation), step 1, last bullet", "rests_on": "rule" }, { "label": "A repeated transaction identifier means the payment was already credited", "value": "Before it credits a payment the merchant confirms that no payment carrying the same transaction identifier already shows as processed. The reference says it is enough to look at payments whose transaction time falls inside the same five minute window as the identifier being checked. The transaction identifier is generated on the device and travels in the token header.", "citation": "Payment token format reference (PassKit documentation), step 5; header keys and values, transactionId", "rests_on": "rule" }, { "label": "The card, cardholder and merchant agreements keep governing", "value": "Any cardholder agreement, user agreement, merchant agreement or other terms that apply to the features of Apple Pay keep governing the cards and their use in Apple Pay, and those terms may carry privacy policies of their own. Apple's notice is in addition to whatever a bank tells the cardholder, not in place of it. So a cardholder's rights over a payment made with Apple Pay are the rights the card gives, and a merchant's duties are the duties its acquiring agreement and the network rules give.", "citation": "Apple Pay and privacy notice, closing paragraph", "rests_on": "rule" } ], "exceptions": [ "Before the payment is presented at all, a failed token check ends it: the merchant ignores the transaction and nothing goes to the network.", "Apple may disable Apple Pay on a website at any time, which stops future payments there but does nothing to payments already made." ], "applies_to": "Apple Pay used to pay a merchant with a credit, debit or prepaid card held in Wallet, in an app, on the web, or in a store. Not Apple Cash, not Apple Card, not Wallet passes, and not a purchase from Apple itself.", "caveat": "Do not answer whether an Apple Pay payment is final from this record. It says who answers. The answer is in visa:finality or mastercard:finality for the network the card runs on, and the channel matters there: a tap in a store and a payment in an app are different transactions under those rules.", "related": [ "visa:finality", "mastercard:finality", "google-pay:finality" ], "basis": { "sources": "Developer Program License Agreement 3.3.9(C)(i); payment token format reference steps 1, 5 and 7; Apple Pay and privacy notice; read 2026-09-20. No Visa or Mastercard document was read for this rail.", "confidence": "high" }, "currency": { "effective_since": "2026-08-18", "effective_to": null, "effective_note": "Drafted 2026-09-20 from the Apple pages saved that day. The date is the last-updated date the Developer Program License Agreement gives for itself and Schedule 1; the other pages carry no date, and each Rule dates its own source. Nothing here dates the card network's rules, which change with their own rulebooks and are held in the visa and mastercard rails.", "source_edition": "Apple Developer Program License Agreement, public copy; the page states the Agreement and its Schedule 1 were last updated 2026-08-18, Schedules 2 and 3 on 2025-12-17 and their exhibits on 2026-08-27, and that the version accepted in a developer account is the binding one; read 2026-09-20 from the copy saved that day", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://developer.apple.com/support/terms/apple-developer-program-license-agreement/", "source_class": "authoritative_primary", "source_title": "Apple Developer Program License Agreement (public copy, Agreement and Schedule 1 last updated 2026-08-18)", "checked_on": "2026-09-20", "checked_by": "validator-pass-through-wallets-2026-09-20", "notes": "Confirms Apple is not a party to a payment made through the Apple Pay APIs and that the payment runs between the merchant and its own bank, acquirer and card networks." } ] }, "rail_name": "Apple Pay (pass-through wallet)", "governing_authority": "Apple, through the Apple Developer Program License Agreement and the Acceptable Use Guidelines for Apple Pay on the Web, for the wallet's own rules; the card network, the card issuer and the merchant's acquirer for the payment itself", "snapshot": "2026-09-20", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "apple-pay:hours", "id": "hours", "rail": "apple-pay", "kind": "rail-fact", "facet": "hours", "name": "When does Apple Pay operate, and what deadlines does it set?", "statement": "Apple Pay keeps no operating hours, no cut-off times and no settlement calendar, because it settles nothing. It sets one clock, and it is a security clock rather than a timetable: when a merchant verifies a payment token it inspects the signing time of the cryptographic message syntax signature, and a difference of more than five minutes between that time and the transaction time means the token may be a replay. The same five minute window bounds the duplicate check, where the merchant looks for an already processed payment carrying the same transaction identifier. Every timing that decides a payment, from authorisation windows to presentment and dispute deadlines, belongs to the card network.", "details": [ { "label": "A token signed more than five minutes from the transaction time may be a replay", "value": "When it verifies an Apple Pay payment token, the merchant inspects the signing time of the cryptographic message syntax signature, as RFC 5652 section 11.3 defines it. If that time and the transaction time differ by more than five minutes, the token may be a replay attack. This is the only clock Apple sets for an Apple Pay payment: the wallet keeps no operating hours, no cut-off times and no settlement calendar, because it settles nothing.", "citation": "Payment token format reference (PassKit documentation), step 1, last bullet", "rests_on": "rule" }, { "label": "A repeated transaction identifier means the payment was already credited", "value": "Before it credits a payment the merchant confirms that no payment carrying the same transaction identifier already shows as processed. The reference says it is enough to look at payments whose transaction time falls inside the same five minute window as the identifier being checked. The transaction identifier is generated on the device and travels in the token header.", "citation": "Payment token format reference (PassKit documentation), step 5; header keys and values, transactionId", "rests_on": "rule" }, { "label": "The checks a merchant runs on a payment token before it decrypts", "value": "Before it can use a payment token the merchant verifies the signature. It checks that the certificates carry the right custom object identifiers, 1.2.840.113635.100.6.29 on the leaf certificate and 1.2.840.113635.100.6.2.14 on the intermediate certificate authority, where only their presence counts and not their value. It checks that the root is the Apple Root CA G3, published by Apple's certificate authority. It checks that a valid X.509 chain of trust runs from the signature to that root. It checks the token's own signature: for EC_v1 an ECDSA signature with SHA-256 over the joined ephemeral public key, data, transaction identifier and application data values; for RSA_v1 an RSA signature with SHA-256 over the joined wrapped key, data, transaction identifier and application data values. Then it uses the public key hash to find which merchant public key Apple used, retrieves that certificate and its private key, restores the symmetric key, and decrypts the data value with AES-256 in GCM mode for EC_v1 or AES-128 in GCM mode for RSA_v1, in both cases with an initialisation vector of sixteen null bytes and no associated authentication data.", "citation": "Payment token format reference (PassKit documentation), steps 1 to 4", "rests_on": "rule" } ], "exceptions": [ "The five minute window is guidance to the merchant on when a token looks like a replay, not a deadline anyone owes anyone. Nothing in the pages read says what happens if a merchant ignores it." ], "applies_to": "Apple Pay used to pay a merchant with a credit, debit or prepaid card held in Wallet, in an app, on the web, or in a store. Not Apple Cash, not Apple Card, not Wallet passes, and not a purchase from Apple itself.", "caveat": "Five minutes is not a Core time window in this record: the schema's smallest unit is an hour, so the figure lives in the Rule's statement and cannot be queried as a duration.", "related": [ "visa:hours", "mastercard:hours", "google-pay:hours" ], "basis": { "sources": "Payment token format reference, steps 1 and 5, read 2026-09-20.", "confidence": "high" }, "currency": { "effective_since": "Unknown: the reference carries no date", "effective_to": null, "effective_note": "Drafted 2026-09-20 from the Apple pages saved that day. The date is the last-updated date the Developer Program License Agreement gives for itself and Schedule 1; the other pages carry no date, and each Rule dates its own source. Nothing here dates the card network's rules, which change with their own rulebooks and are held in the visa and mastercard rails.", "source_edition": "Payment token format reference, PassKit documentation, undated page, read in full 2026-09-20 from the page data saved that day (the HTML is a script shell; the same page's JSON was read)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://developer.apple.com/documentation/passkit/payment-token-format-reference", "source_class": "authoritative_primary", "source_title": "Payment token format reference (PassKit documentation)", "checked_on": "2026-09-20", "checked_by": "validator-pass-through-wallets-2026-09-20", "notes": "Confirms the only timing rule Apple sets is the five minute window between a token's signing time and the transaction time, used both for the replay check and the duplicate transaction check." } ] }, "rail_name": "Apple Pay (pass-through wallet)", "governing_authority": "Apple, through the Apple Developer Program License Agreement and the Acceptable Use Guidelines for Apple Pay on the Web, for the wallet's own rules; the card network, the card issuer and the merchant's acquirer for the payment itself", "snapshot": "2026-09-20", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "apple-pay:liability", "id": "liability", "rail": "apple-pay", "kind": "rail-fact", "facet": "liability", "name": "Who bears the loss when an Apple Pay payment goes wrong?", "statement": "Not Apple, by its own terms, and the rest is the card network's. The agreement says Apple is not a party to a payment made through the Apple Pay APIs and is not responsible for one, naming the unavailability of an end user payment card and payment fraud among the things it is not responsible for. What Apple supplies is mechanism rather than a liability rule: every payment on an iPhone or iPad calls for Face ID, Touch ID or the passcode, an Apple Watch needs its passcode again each time it is put back on, the merchant never receives the real card number, and the credential travels encrypted and signed, with a cryptogram in the 3D Secure form. Whether that mechanism moves liability is decided by the card network, by the ECI value the network may put in the token, and by the dispute conditions, and the channel changes the answer. Merchants carry their own duties too: private keys held securely, no unencrypted payment data on an iPhone or iPad, and no decryption on those devices.", "details": [ { "label": "Apple is not a party to the payment and is not responsible for it", "value": "Apple is not a party to any payment transaction facilitated through the Apple Pay APIs and is not responsible for one, and the agreement names the unavailability of an end user payment card and payment fraud among the things it is not responsible for. The payment runs between the developer and its own bank, acquirer, card networks and any other party it uses for transaction processing, and the developer must comply with whatever those agreements say, which may put rights, duties or limits on it that follow from its choice to use the Apple Pay APIs. For this part of the agreement, Apple means Apple Payments Services LLC where the developer is in the United States. Nothing in the wallet decides whether a payment is final, whether it can be undone, or who bears a loss; the card network, the issuer and the acquiring agreement decide all three.", "citation": "Apple Developer Program License Agreement (public copy, Agreement and Schedule 1 last updated 2026-08-18), 3.3.9(C)(i), not a party clause, and the closing sentence of 3.3.9(C)", "rests_on": "rule" }, { "label": "The cardholder authenticates on the device before every payment", "value": "Every transaction on the customer's iPhone or iPad calls for Face ID, Touch ID or the passcode, and an Apple Watch has to have its passcode entered again each time it is taken off the wrist before it can be used. Apple presents this, with the merchant not receiving the real card number, as what makes accepting Apple Pay more secure than accepting a card directly. What that authentication is worth in a dispute is a card network question, not Apple's: the network decides whether and when authentication moves liability.", "citation": "Apple Pay developer overview page, Data is more secure", "rests_on": "guidance" }, { "label": "The merchant does not receive the card number", "value": "A business accepting Apple Pay does not receive the customer's actual credit or debit card number, so it is not holding that data in its systems. What it receives instead is a device-specific account number, and for a recurring or merchant-initiated charge a merchant-specific account number. Apple does not store the original card number either; it keeps a card reference so that a card can be added again on a new device after the security code is entered.", "citation": "Apple Pay developer overview page, Data is more secure; Apple Pay and privacy notice, paying in apps and on the web; setting up Apple Pay; Payment token format reference (PassKit documentation), payment data keys, applicationPrimaryAccountNumber", "rests_on": "rule" }, { "label": "An ECI indicator in the token must be passed on unchanged", "value": "The card network may add an ECI indicator to the payment data the payment token carries. Where a merchant receives one, it must pass it on to its payment processor; if it does not, the transaction fails. The indicator is the network's, not Apple's, and what a given value means for authorisation and liability is the network's rule.", "citation": "Payment token format reference (PassKit documentation), detailed payment data keys (3D Secure), eciIndicator", "rests_on": "rule" }, { "label": "Keys are held securely and payment data is never decrypted on the device", "value": "A developer using the Apple Pay APIs must hold any private keys it is given securely and as the documentation says, for example encrypted on a server. It must not store end user payment information unencrypted on an iPhone or iPad, and it may not decrypt that information on either of those devices. The decryption belongs on the merchant's or processor's own systems, where the merchant private key that matches the certificate identified by the token's public key hash lives.", "citation": "Apple Developer Program License Agreement (public copy, Agreement and Schedule 1 last updated 2026-08-18), 3.3.9(C)(i), second bullet; Payment token format reference (PassKit documentation), step 2", "rests_on": "rule" }, { "label": "The card, cardholder and merchant agreements keep governing", "value": "Any cardholder agreement, user agreement, merchant agreement or other terms that apply to the features of Apple Pay keep governing the cards and their use in Apple Pay, and those terms may carry privacy policies of their own. Apple's notice is in addition to whatever a bank tells the cardholder, not in place of it. So a cardholder's rights over a payment made with Apple Pay are the rights the card gives, and a merchant's duties are the duties its acquiring agreement and the network rules give.", "citation": "Apple Pay and privacy notice, closing paragraph", "rests_on": "rule" } ], "exceptions": [ "A merchant that receives an ECI indicator and does not pass it on fails the transaction outright, so the liability question never arises.", "The liability question for a payment made with a merchant-specific account number for a recurring charge was not read and is not answered here." ], "applies_to": "Apple Pay used to pay a merchant with a credit, debit or prepaid card held in Wallet, in an app, on the web, or in a store. Not Apple Cash, not Apple Card, not Wallet passes, and not a purchase from Apple itself.", "caveat": "Never read Apple's security description as a liability shift. Apple states a mechanism; the network states who pays. The two are different documents and only one of them governs, and which network condition applies depends on whether the payment was a tap in a store or a payment in an app or on the web.", "related": [ "visa:liability", "mastercard:liability", "visa-dispute:10.1", "visa-dispute:10.2", "visa-dispute:10.4", "google-pay:liability" ], "basis": { "sources": "Developer Program License Agreement 3.3.9(C)(i); Apple Pay developer overview; payment token format reference; Apple Pay and privacy notice; read 2026-09-20. No Visa or Mastercard document was read for this rail, so no network liability line is stated here; the linked records hold them.", "confidence": "medium" }, "currency": { "effective_since": "2026-08-18", "effective_to": null, "effective_note": "Drafted 2026-09-20 from the Apple pages saved that day. The date is the last-updated date the Developer Program License Agreement gives for itself and Schedule 1; the other pages carry no date, and each Rule dates its own source. Nothing here dates the card network's rules, which change with their own rulebooks and are held in the visa and mastercard rails.", "source_edition": "Apple Developer Program License Agreement, public copy; the page states the Agreement and its Schedule 1 were last updated 2026-08-18, Schedules 2 and 3 on 2025-12-17 and their exhibits on 2026-08-27, and that the version accepted in a developer account is the binding one; read 2026-09-20 from the copy saved that day", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://developer.apple.com/support/terms/apple-developer-program-license-agreement/", "source_class": "authoritative_primary", "source_title": "Apple Developer Program License Agreement (public copy, Agreement and Schedule 1 last updated 2026-08-18)", "checked_on": "2026-09-20", "checked_by": "validator-pass-through-wallets-2026-09-20", "notes": "Confirms Apple is not a party to a payment made through the Apple Pay APIs or responsible for an unavailable card or payment fraud, leaving the mechanism it supplies without a liability rule of its own." } ] }, "rail_name": "Apple Pay (pass-through wallet)", "governing_authority": "Apple, through the Apple Developer Program License Agreement and the Acceptable Use Guidelines for Apple Pay on the Web, for the wallet's own rules; the card network, the card issuer and the merchant's acquirer for the payment itself", "snapshot": "2026-09-20", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "apple-pay:limits", "id": "limits", "rail": "apple-pay", "kind": "rail-fact", "facet": "limits", "name": "What limits does Apple Pay put on a payment or a merchant?", "statement": "No amount limit of Apple's own was found in the pages read. The limits Apple does set are on who may accept it and how it is shown. A website may not use Apple Pay if it breaks the law or trades in the classes Apple names, among them tobacco and vaping, weapons, illegal drugs, pornography, counterfeit or stolen goods, unapproved fundraising, unapproved currency or cryptocurrency dealing, fraud, infringement, and content that shows Apple falsely. A staged digital wallet may not sit behind Apple Pay, meaning an arrangement where a second payment completes the first or a substitute merchant of record stands in. The APIs may be used only to facilitate payments made by or through the application, and only for goods and services used off the device, with attachments varying that for alternative app marketplaces in the European Union, Japan and Brazil. A page that takes other third-party payment methods must show Apple Pay at least on a par with them, and must make it the primary option where the site has learned a card is active in Wallet. Apple may disable Apple Pay on a site at any time for any reason it deems prudent.", "details": [ { "label": "The classes of website and trade that may not use Apple Pay", "value": "Apple names the classes of website that may not incorporate Apple Pay. Grouped by what each is about rather than as the page lists them, they come to five things. Unlawful trade: a site that breaks the law or fails a legal requirement, that commits fraud, that infringes another's intellectual property, publicity or privacy rights, that deals in counterfeit or stolen goods, or that sells items meant to be used in illegal activity. Restricted and harmful goods: tobacco, marijuana and vaping products; firearms, weapons and ammunition; illegal drugs and controlled substances that are not lawfully prescribed; items that create consumer safety risks; pornography; and a site whose main trade is drug paraphernalia or sexually oriented goods or services. Speech: a site promoting hate, violence or intolerance on the grounds Apple lists, which are race, age, gender, gender identity, ethnicity, religion and sexual orientation. Gated on Apple's approval rather than barred outright: personal fundraising and the collection of nonprofit donations, and the purchase or transfer of currency, cryptocurrency included. And Apple's own standing: a site that shows Apple or its products in a false or derogatory light.", "citation": "Acceptable Use Guidelines for Apple Pay on the Web, Prohibited Uses", "rests_on": "rule" }, { "label": "A staged wallet may not sit behind Apple Pay", "value": "A website may not use Apple Pay if what it runs is a staged digital wallet. Apple describes that as an arrangement where a second payment transaction is carried out in order to complete the first, or where a substitute merchant of record stands in the transaction. The point of the rule is that the party Apple Pay pays must be the party selling, and the credential must fund that sale directly rather than top up a balance that then pays the seller.", "citation": "Acceptable Use Guidelines for Apple Pay on the Web, Prohibited Uses, staged digital wallet item", "rests_on": "rule" }, { "label": "What the Apple Pay APIs may be used for", "value": "An application may use the Apple Pay APIs only to facilitate payments made by or through that application, and only to buy goods and services used outside an iPhone, iPad or Apple Watch, unless Apple permits otherwise in writing; the In-App Purchase rules are untouched by this. The APIs may not be called, and information may not be sought through them, for anything unrelated to facilitating an end user payment. The acceptable use guidelines say the same for a website: Apple Pay may be used for no purpose other than enabling or facilitating an Apple Pay transaction from that site. Attachments to the agreement vary the first limit for applications distributed through alternative app marketplaces in the European Union, Japan and Brazil, and for digital purchases offered through out-of-app offers or alternative payment processing.", "citation": "Apple Developer Program License Agreement (public copy, Agreement and Schedule 1 last updated 2026-08-18), 3.3.9(C)(i), first paragraph and third bullet; the European Union, Japan and Brazil attachments; Acceptable Use Guidelines for Apple Pay on the Web, Apple Pay APIs", "rests_on": "rule" }, { "label": "Display parity, and Apple Pay as the primary option where a card is provisioned", "value": "A webpage that accepts any other third-party payment method must also offer Apple Pay on that page, at least on a par with those methods, meaning shown with the same prominence. Where the business calls the canMakePaymentWithActiveCard API and learns that the user has an active card in Wallet, it must present Apple Pay as the primary displayed payment option, though not necessarily the only one; the guidelines give pre-selecting Apple Pay alongside other options as an example. Use of Apple Pay must also follow Apple's marketing and human interface guidelines, which were not read.", "citation": "Acceptable Use Guidelines for Apple Pay on the Web, Apple Pay APIs; Design", "rests_on": "rule" }, { "label": "Apple Cash as an option, and moving a stored balance to a provisioned card", "value": "Two further duties come with using the Apple Pay APIs in an application. The developer must use commercially reasonable efforts to include Apple Cash as a payment option wherever Apple Cash is available in the place the application is distributed. And where the application holds end user balances, it may use the Apple Pay APIs to move those funds to the cards the users have provisioned in Apple Pay with their issuers.", "citation": "Apple Developer Program License Agreement (public copy, Agreement and Schedule 1 last updated 2026-08-18), 3.3.9(C)(i), fourth and fifth bullets", "rests_on": "rule" }, { "label": "Apple may disable Apple Pay on a website at any time", "value": "Apple reserves the right, at any time, to disable Apple Pay transactions on a business's websites for any reason it deems prudent. No ground has to be shown and the prohibited-use list does not limit it. The guidelines set no notice, no procedure and no review.", "citation": "Acceptable Use Guidelines for Apple Pay on the Web, Prohibited Uses, closing sentence", "rests_on": "rule" } ], "exceptions": [ "Apple may approve personal fundraising, nonprofit collections and currency or cryptocurrency dealing case by case; the guidelines say so without saying how approval is sought.", "The regional attachments for the European Union, Japan and Brazil let the Apple Pay APIs be used for purchases, including digital ones, by applications distributed through alternative app marketplaces and, in the European Union, from the developer's own website, on condition the web acceptable use guidelines and the platform web terms are followed.", "Any amount limit on the payment itself is the card's and the network's, not the wallet's." ], "applies_to": "Apple Pay used to pay a merchant with a credit, debit or prepaid card held in Wallet, in an app, on the web, or in a store. Not Apple Cash, not Apple Card, not Wallet passes, and not a purchase from Apple itself.", "caveat": "No amount limit means none was found in these pages, not that none exists; the Apple Pay Platform Web Terms and Conditions, which a developer accepts in its account, were not read. Read the prohibited list as Apple's own categories described in Orca's structure, not as a reproduction of the page.", "related": [ "visa:limits", "mastercard:limits", "google-pay:limits" ], "basis": { "sources": "Acceptable Use Guidelines for Apple Pay on the Web, read in full; Developer Program License Agreement 3.3.9(C)(i) and its regional attachments; read 2026-09-20.", "confidence": "high" }, "currency": { "effective_since": "2026-09-20", "effective_to": null, "effective_note": "Drafted 2026-09-20 from the Apple pages saved that day. The date is the last-updated date the Developer Program License Agreement gives for itself and Schedule 1; the other pages carry no date, and each Rule dates its own source. Nothing here dates the card network's rules, which change with their own rulebooks and are held in the visa and mastercard rails. The limits facet has to carry an ISO effective_since, and the guidelines that most of this fact rests on carry no date, so the date is the day they were read; it dates the reading, not the rules [Unverified].", "source_edition": "Acceptable Use Guidelines for Apple Pay on the Web, undated page, read in full 2026-09-20 from the copy saved that day", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://developer.apple.com/apple-pay/acceptable-use-guidelines-for-websites/", "source_class": "authoritative_primary", "source_title": "Acceptable Use Guidelines for Apple Pay on the Web", "checked_on": "2026-09-20", "checked_by": "validator-pass-through-wallets-2026-09-20", "notes": "Confirms the classes of website barred from Apple Pay, the staged wallet prohibition, and the display parity and primary option duties; no amount limit of Apple's own is stated on the page." } ] }, "rail_name": "Apple Pay (pass-through wallet)", "governing_authority": "Apple, through the Apple Developer Program License Agreement and the Acceptable Use Guidelines for Apple Pay on the Web, for the wallet's own rules; the card network, the card issuer and the merchant's acquirer for the payment itself", "snapshot": "2026-09-20", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "apple-pay:messages", "id": "messages", "rail": "apple-pay", "kind": "rail-fact", "facet": "messages", "name": "What does an Apple Pay payment message carry?", "statement": "A payment token, made by the Secure Element when an app or website sends a payment request. The token carries four keys: the encrypted payment data, a header, a detached signature over the payment and header data, and a version that reads EC_v1 for elliptic curve encryption or RSA_v1 for RSA, the choice being made by the Secure Element from the merchant capabilities in the request. The header carries an optional application data hash, an ephemeral public key or a wrapped symmetric key depending on the version, the hash of the merchant certificate's public key, and a transaction identifier generated on the device. Decrypted, the data holds the device-specific account number, the expiry as YYMMDD, the ISO 4217 numeric currency code as a string, the amount, an optional cardholder name, a device manufacturer identifier and a payment data type of either 3DSecure or EMV, plus authentication responses for a multitoken request and a merchant token identifier and metadata for a merchant token request. The 3DSecure form carries an online payment cryptogram and optionally an ECI indicator, which must be passed on unaltered or the transaction fails; the EMV form carries the Secure Element's EMV structure and, for RSA_v1 only, a PIN encrypted under the bank's key. There is no Apple Pay reason code list; the authorisation message the merchant sends next is the network's.", "details": [ { "label": "The structure of an Apple Pay payment token", "value": "The Secure Element makes a payment object when an app or website using Apple Pay sends a payment request, and inside it sits the payment token. The token is a plaintext JSON dictionary carrying four keys: data, the encrypted payment data, base64 encoded; header, the version-dependent information needed to decrypt and verify; signature, a detached PKCS number 7 signature over the payment and header data, carrying the signing certificate, its intermediate certificate authority certificate and the signing algorithm; and version. Version reads EC_v1 where the data is encrypted with elliptic curve cryptography and RSA_v1 where it is encrypted with RSA. The Secure Element picks the algorithm from the merchant capabilities the payment request states; most regions use elliptic curve, and RSA is used where regulatory concerns make elliptic curve unavailable. The header carries an optional application data hash, an ephemeral public key for EC_v1 or a wrapped symmetric key for RSA_v1, the hash of the merchant certificate's public key, and the transaction identifier generated on the device.", "citation": "Payment token format reference (PassKit documentation), Overview; payment token structure; header keys and values", "rests_on": "rule" }, { "label": "What the decrypted payment data carries", "value": "Once decrypted, the data value holds the device-specific account number of the card funding the payment, the card expiration date written as YYMMDD, the ISO 4217 numeric currency code kept as a string so leading zeros survive, the transaction amount, an optional cardholder name, a hex-encoded device manufacturer identifier, and a payment data type of either 3DSecure or EMV with a matching detailed payment data dictionary. Where the request was a multitoken request it also holds a list of authentication responses, each naming a submerchant identifier given by the coordinator merchant, a payment network cryptogram for that submerchant and the amount authorised for it. Where it was a merchant token request it holds the merchant token identifier the payment network provisioned, and merchant token metadata carrying the card art and the token's last four digits and expiry.", "citation": "Payment token format reference (PassKit documentation), payment data keys; authentication response", "rests_on": "rule" }, { "label": "The two detailed payment data forms, 3D Secure and EMV", "value": "Where the payment data type is 3DSecure, the detailed payment data holds an online payment cryptogram as 3D Secure defines it, and optionally an ECI indicator. Where it is EMV, the detailed payment data holds the EMV payment structure as base64, which is output from the Secure Element, and for RSA_v1 only an encrypted PIN, encrypted under the bank's key.", "citation": "Payment token format reference (PassKit documentation), detailed payment data keys (3D Secure); detailed payment data keys (EMV)", "rests_on": "rule" }, { "label": "An ECI indicator in the token must be passed on unchanged", "value": "The card network may add an ECI indicator to the payment data the payment token carries. Where a merchant receives one, it must pass it on to its payment processor; if it does not, the transaction fails. The indicator is the network's, not Apple's, and what a given value means for authorisation and liability is the network's rule.", "citation": "Payment token format reference (PassKit documentation), detailed payment data keys (3D Secure), eciIndicator", "rests_on": "rule" }, { "label": "A merchant-specific account number stands behind recurring and merchant-initiated charges", "value": "Where a cardholder gives an eligible Apple Pay payment method to a participating merchant for recurring or other merchant-initiated charges, the issuer or the payment network approves and generates a merchant-specific account number for those charges. Only that number lets that merchant authorise a charge without the cardholder doing anything at the time. Apple knows which merchants hold which of a cardholder's merchant-specific account numbers, but not what was bought or for how much, and the cardholder manages them in Wallet through the card's details. In the payment token the counterpart field is the merchant token identifier, provisioned by the payment network, with metadata carrying the token's last four digits and expiry.", "citation": "Apple Pay and privacy notice, recurring and merchant-initiated charges; Payment token format reference (PassKit documentation), payment data keys, merchantTokenIdentifier and merchantTokenMetadata", "rests_on": "rule" }, { "label": "The checks a merchant runs on a payment token before it decrypts", "value": "Before it can use a payment token the merchant verifies the signature. It checks that the certificates carry the right custom object identifiers, 1.2.840.113635.100.6.29 on the leaf certificate and 1.2.840.113635.100.6.2.14 on the intermediate certificate authority, where only their presence counts and not their value. It checks that the root is the Apple Root CA G3, published by Apple's certificate authority. It checks that a valid X.509 chain of trust runs from the signature to that root. It checks the token's own signature: for EC_v1 an ECDSA signature with SHA-256 over the joined ephemeral public key, data, transaction identifier and application data values; for RSA_v1 an RSA signature with SHA-256 over the joined wrapped key, data, transaction identifier and application data values. Then it uses the public key hash to find which merchant public key Apple used, retrieves that certificate and its private key, restores the symmetric key, and decrypts the data value with AES-256 in GCM mode for EC_v1 or AES-128 in GCM mode for RSA_v1, in both cases with an initialisation vector of sixteen null bytes and no associated authentication data.", "citation": "Payment token format reference (PassKit documentation), steps 1 to 4", "rests_on": "rule" } ], "exceptions": [ "The application data hash is omitted where the original request carried no application data.", "The encrypted PIN appears only in the EMV form and only for RSA_v1.", "Apple's PassKit error codes, which an application sees when a payment fails, were not read and are not held here." ], "applies_to": "Apple Pay used to pay a merchant with a credit, debit or prepaid card held in Wallet, in an app, on the web, or in a store. Not Apple Cash, not Apple Card, not Wallet passes, and not a purchase from Apple itself.", "caveat": "These are the wallet's fields, not the network's. Nothing here says what an issuer sends back or what a decline means; that is visa:messages and mastercard:messages. Field and value names are Apple's defined terms and stay as Apple writes them.", "related": [ "visa:messages", "mastercard:messages", "google-pay:messages" ], "basis": { "sources": "Payment token format reference, read in full 2026-09-20; Apple Pay and privacy notice for the merchant-specific account number.", "confidence": "high" }, "currency": { "effective_since": "Unknown: the reference carries no date", "effective_to": null, "effective_note": "Drafted 2026-09-20 from the Apple pages saved that day. The date is the last-updated date the Developer Program License Agreement gives for itself and Schedule 1; the other pages carry no date, and each Rule dates its own source. Nothing here dates the card network's rules, which change with their own rulebooks and are held in the visa and mastercard rails.", "source_edition": "Payment token format reference, PassKit documentation, undated page, read in full 2026-09-20 from the page data saved that day (the HTML is a script shell; the same page's JSON was read)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://developer.apple.com/documentation/passkit/payment-token-format-reference", "source_class": "authoritative_primary", "source_title": "Payment token format reference (PassKit documentation)", "checked_on": "2026-09-20", "checked_by": "validator-pass-through-wallets-2026-09-20", "notes": "Confirms the payment token's structure, its header and payment data keys, and the 3DSecure and EMV detailed payment data forms." } ] }, "rail_name": "Apple Pay (pass-through wallet)", "governing_authority": "Apple, through the Apple Developer Program License Agreement and the Acceptable Use Guidelines for Apple Pay on the Web, for the wallet's own rules; the card network, the card issuer and the merchant's acquirer for the payment itself", "snapshot": "2026-09-20", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "apple-pay:participants", "id": "participants", "rail": "apple-pay", "kind": "rail-fact", "facet": "participants", "name": "Who takes part in an Apple Pay payment, and who does what?", "statement": "Start from what the wallet is not: Apple moves no money and is not a party to the payment. The cardholder holds a card the issuer offers and authenticates on the device. The issuer and the payment network decide whether the card can go into Wallet at all and what further verification the cardholder must pass, and one of them approves and generates the merchant-specific account number used for recurring charges. Apple, as the affiliate providing Apple Pay in that location, carries and re-encrypts the credential and sets conduct rules for developers and websites. The merchant sells, receives the payload, processes the payment through its own bank, acquirer and card networks, and answers to them. Two further parties exist only in Apple's agreement: an intermediary party, which passes the payload to a merchant and carries its own duties over it, and a party that merely displays a merchant's checkout page in a web view, which may not touch the payload at all. Who authorises, clears, settles and decides a dispute is the network's arrangement, not the wallet's.", "details": [ { "label": "Apple is not a party to the payment and is not responsible for it", "value": "Apple is not a party to any payment transaction facilitated through the Apple Pay APIs and is not responsible for one, and the agreement names the unavailability of an end user payment card and payment fraud among the things it is not responsible for. The payment runs between the developer and its own bank, acquirer, card networks and any other party it uses for transaction processing, and the developer must comply with whatever those agreements say, which may put rights, duties or limits on it that follow from its choice to use the Apple Pay APIs. For this part of the agreement, Apple means Apple Payments Services LLC where the developer is in the United States. Nothing in the wallet decides whether a payment is final, whether it can be undone, or who bears a loss; the card network, the issuer and the acquiring agreement decide all three.", "citation": "Apple Developer Program License Agreement (public copy, Agreement and Schedule 1 last updated 2026-08-18), 3.3.9(C)(i), not a party clause, and the closing sentence of 3.3.9(C)", "rests_on": "rule" }, { "label": "Who provides Apple Pay, and that the provider is not a bank", "value": "Apple Pay is a technology service provided by Apple Inc. affiliates, which are responsible for the personal data it handles, and the provider differs by the cardholder's location: in the United States it is Apple Payments Services LLC, a subsidiary of Apple Inc. Neither Apple Inc. nor the affiliate providing Apple Pay is a bank, and any card used in Apple Pay is offered by the card issuer. In the Apple Pay API terms of the Developer Program License Agreement, Apple means Apple Payments Services LLC for a developer in the United States, with an Austin, Texas address.", "citation": "Apple Pay and privacy notice, who provides Apple Pay; closing paragraph; Apple Support article 118270, Get a refund for purchases made with credit or debit cards using Apple Pay, closing paragraph; Apple Pay developer overview page, footer; Apple Developer Program License Agreement (public copy, Agreement and Schedule 1 last updated 2026-08-18), 3.3.9(C), closing sentence", "rests_on": "rule" }, { "label": "The issuer and the payment network decide whether a card goes into the wallet", "value": "Setting a card up in Apple Pay is the card issuer's and payment network's decision, not Apple's. Card-related information, location, device settings and use patterns may go to Apple and be used with account information to give the issuer or network assessments for setting Apple Pay up and preventing fraud, and account and paired-device details may be shared with the issuer or bank to decide eligibility and against fraud. Where a card is added through a bank's own application, that application sends a card or account identifier to the device, which Apple and the issuer use to decide eligibility and prevent fraud. Apple checks feature eligibility by the country the card was issued in and whether the issuer takes part. Apple does not store the original card number; it stores a card reference against the Apple Account so a card can be re-added after the security code is entered. Where Apple suspects fraud, information about the account and transactions may go to the issuer or network.", "citation": "Apple Pay and privacy notice, setting up Apple Pay; adding a card from a third-party app; feature eligibility; closing paragraph", "rests_on": "rule" }, { "label": "What a merchant may do with the Apple Pay Payload", "value": "Apple may hand an Apple Pay Payload to a party acting as the merchant, as an intermediary party, or merely displaying the merchant's checkout page. A party acting as the merchant may use the payload to process that end user payment, and for other uses it has disclosed to the end user, and only as the law allows. The payload is the customer data package the Apple software and the Apple Pay APIs pass through as part of a payment: the agreement's definition names the cardholder's name, email address, billing address, shipping address and device account number.", "citation": "Apple Developer Program License Agreement (public copy, Agreement and Schedule 1 last updated 2026-08-18), 3.3.9(C)(ii), opening and first case; definitions, Apple Pay Payload", "rests_on": "rule" }, { "label": "What an intermediary party owes", "value": "A party that passes an end user's payload to a merchant, or supplies an application that lets merchants take Tap to Pay payments or run customer engagement interactions, carries five duties. It may use the payload only to facilitate that payment between the merchant and the end user and for its own order management as part of that transaction. It may hold the data no longer than those purposes need. It may not combine data from the Apple Pay APIs with other data it holds about the end user, except so far as order management needs, and specifically may not use it to advertise, to market, to build or improve a user profile or to target the end user. It must tell end users it is an intermediary and name the merchant for the transaction on the Apple Pay payment sheet, alongside its own name. And where it uses a merchant, it must make sure that merchant uses the payload only to process the payment and for uses it has disclosed, must have a written agreement with that merchant at least as protective of Apple as its own, is treated as having taken whatever that merchant does, and can be required by Apple to stop using it.", "citation": "Apple Developer Program License Agreement (public copy, Agreement and Schedule 1 last updated 2026-08-18), 3.3.9(C)(ii), second case, items (a) to (e); definitions, Intermediary Party", "rests_on": "rule" }, { "label": "A party that only shows the checkout page may not touch the payload", "value": "Where a party displays the merchant's web page that carries out an Apple Pay payment but is neither the merchant nor an intermediary party, which the agreement illustrates with hosting a merchant checkout through a web view, two things follow. It may not access the Apple Pay Payload for any reason at all. And it may not use information derived from or relating to the payment for anything other than displaying that merchant web page.", "citation": "Apple Developer Program License Agreement (public copy, Agreement and Schedule 1 last updated 2026-08-18), 3.3.9(C)(ii), third case, items (a) and (b)", "rests_on": "rule" }, { "label": "The merchant processes the payment through its own bank, acquirer and networks", "value": "Processing an Apple Pay payment is the merchant's own arrangement. The agreement puts the payment between the developer and its bank, its acquirer, the card networks and any other party it uses for transaction processing, and makes the developer responsible for complying with each of those agreements. Apple supplies no acquiring, no clearing and no settlement, and a merchant that wants to accept Apple Pay needs a payment service provider that supports it.", "citation": "Apple Developer Program License Agreement (public copy, Agreement and Schedule 1 last updated 2026-08-18), 3.3.9(C)(i), not a party clause; Apple Pay developer overview page, Find a PSP that supports Apple Pay", "rests_on": "rule" } ], "exceptions": [ "An intermediary party that uses a merchant answers to Apple for what that merchant does with the payload, and must hold a written agreement with it at least as protective of Apple as its own.", "The Apple entity providing Apple Pay differs by location; Apple Payments Services LLC is named only for the United States." ], "applies_to": "Apple Pay used to pay a merchant with a credit, debit or prepaid card held in Wallet, in an app, on the web, or in a store. Not Apple Cash, not Apple Card, not Wallet passes, and not a purchase from Apple itself.", "caveat": "Do not read this rail as a payment system with participants of its own. Every party here except Apple is a party to a card payment, and the card network's participant rules, held in visa:participants and mastercard:participants, are what bind them.", "related": [ "visa:participants", "mastercard:participants", "google-pay:participants" ], "basis": { "sources": "Developer Program License Agreement 3.3.9(C) and its definitions; Apple Pay and privacy notice; support article 118270; read 2026-09-20.", "confidence": "high" }, "currency": { "effective_since": "2026-08-18", "effective_to": null, "effective_note": "Drafted 2026-09-20 from the Apple pages saved that day. The date is the last-updated date the Developer Program License Agreement gives for itself and Schedule 1; the other pages carry no date, and each Rule dates its own source. Nothing here dates the card network's rules, which change with their own rulebooks and are held in the visa and mastercard rails.", "source_edition": "Apple Developer Program License Agreement, public copy; the page states the Agreement and its Schedule 1 were last updated 2026-08-18, Schedules 2 and 3 on 2025-12-17 and their exhibits on 2026-08-27, and that the version accepted in a developer account is the binding one; read 2026-09-20 from the copy saved that day", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "rail_name": "Apple Pay (pass-through wallet)", "governing_authority": "Apple, through the Apple Developer Program License Agreement and the Acceptable Use Guidelines for Apple Pay on the Web, for the wallet's own rules; the card network, the card issuer and the merchant's acquirer for the payment itself", "snapshot": "2026-09-20", "source_class": null, "effective_status": "draft", "effective_status_reason": null, "boundaries": [] }, { "uid": "apple-pay:recall", "id": "recall", "rail": "apple-pay", "kind": "rail-fact", "facet": "recall", "name": "Can an Apple Pay payment be recalled or cancelled?", "statement": "Not through the wallet. Nothing in the pages read gives Apple, the cardholder or the merchant a way to recall, cancel or reverse an Apple Pay card payment once it is made, and Apple's terms put the payment outside Apple entirely. What Apple publishes after a purchase is a refund by the merchant, which is a new payment back to the card rather than the undoing of the first. Before the payment is presented there is one stopping point, and it belongs to the merchant, not to the wallet: a token that fails its checks is ignored and never reaches the network. Whether a presented payment can be recalled at all is the card network's question.", "details": [ { "label": "Apple publishes no way to recall or cancel a completed payment", "value": "Nothing in the pages read gives Apple, the cardholder or the merchant a route through the wallet to recall, cancel or reverse an Apple Pay card payment once it is made. Apple's only published consumer route after a purchase is a refund by the merchant, and Apple's own terms put the payment outside Apple. A completed payment is undone, if at all, on the card network, through the paths that rail holds.", "citation": "Apple Support article 118270, Get a refund for purchases made with credit or debit cards using Apple Pay, whole article; Apple Developer Program License Agreement (public copy, Agreement and Schedule 1 last updated 2026-08-18), 3.3.9(C)(i), not a party clause", "rests_on": "guidance" }, { "label": "Apple is not a party to the payment and is not responsible for it", "value": "Apple is not a party to any payment transaction facilitated through the Apple Pay APIs and is not responsible for one, and the agreement names the unavailability of an end user payment card and payment fraud among the things it is not responsible for. The payment runs between the developer and its own bank, acquirer, card networks and any other party it uses for transaction processing, and the developer must comply with whatever those agreements say, which may put rights, duties or limits on it that follow from its choice to use the Apple Pay APIs. For this part of the agreement, Apple means Apple Payments Services LLC where the developer is in the United States. Nothing in the wallet decides whether a payment is final, whether it can be undone, or who bears a loss; the card network, the issuer and the acquiring agreement decide all three.", "citation": "Apple Developer Program License Agreement (public copy, Agreement and Schedule 1 last updated 2026-08-18), 3.3.9(C)(i), not a party clause, and the closing sentence of 3.3.9(C)", "rests_on": "rule" }, { "label": "The merchant checks the transaction details, then either processes or ignores it", "value": "After decryption the merchant checks the payment against what it knows about the request: that the currency code matches the currency of the original payment request, that the transaction amount matches the total charge, and that the application data field matches the hash of the data the original request used and that the data is right, for instance that an order number in it is the order the payment is being applied to. If the signature is valid, the hash values match and the merchant's own validation passes, it uses the decrypted payment data to process the payment. Otherwise it ignores the transaction. The same instruction closes the signature step: where the signature is invalid or a hash does not match, ignore the transaction.", "citation": "Payment token format reference (PassKit documentation), steps 1, 6 and 7", "rests_on": "rule" } ], "exceptions": [ "A merchant can ignore a transaction whose token fails verification, which is the only stop in the wallet's own reach and works only before presentment." ], "applies_to": "Apple Pay used to pay a merchant with a credit, debit or prepaid card held in Wallet, in an app, on the web, or in a store. Not Apple Cash, not Apple Card, not Wallet passes, and not a purchase from Apple itself.", "caveat": "This is a statement that something does not exist, drawn from reading the saved pages and finding no such route. Orca has no way to record that a document was read in full and nothing was found, so the claim sits in prose and is marked [Inference].", "related": [ "visa:recall", "mastercard:recall", "google-pay:recall" ], "basis": { "sources": "Support article 118270; Developer Program License Agreement 3.3.9(C)(i); payment token format reference step 7; read 2026-09-20.", "confidence": "medium" }, "currency": { "effective_since": "2025-05-29", "effective_to": null, "effective_note": "Drafted 2026-09-20 from the Apple pages saved that day. The date is the last-updated date the Developer Program License Agreement gives for itself and Schedule 1; the other pages carry no date, and each Rule dates its own source. Nothing here dates the card network's rules, which change with their own rulebooks and are held in the visa and mastercard rails.", "source_edition": "Apple Support article 118270, Get a refund for purchases made with credit or debit cards using Apple Pay, published date 2025-05-29 as the page states, read in full 2026-09-20 from the copy saved that day", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://support.apple.com/en-us/118270", "source_class": "public_primary", "source_title": "Apple Support article 118270, Get a refund for purchases made with credit or debit cards using Apple Pay", "checked_on": "2026-09-20", "checked_by": "validator-pass-through-wallets-2026-09-20", "notes": "Confirms Apple's published consumer guidance after a purchase covers only merchant refunds, with no route to recall, cancel or reverse a completed payment." } ] }, "rail_name": "Apple Pay (pass-through wallet)", "governing_authority": "Apple, through the Apple Developer Program License Agreement and the Acceptable Use Guidelines for Apple Pay on the Web, for the wallet's own rules; the card network, the card issuer and the merchant's acquirer for the payment itself", "snapshot": "2026-09-20", "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "apple-pay:refund", "id": "refund", "rail": "apple-pay", "kind": "rail-fact", "facet": "refund", "name": "How is money returned to a cardholder after an Apple Pay purchase?", "statement": "By the merchant, to the card, under the merchant's own policy. Apple publishes no refund mechanism of its own. Returning an Apple Pay purchase works as returning a card purchase does: the receipt is generally enough, some merchants ask for more, and once the merchant processes the refund it goes back to the payment card by itself and may take several days to show on the statement. The one thing Apple Pay changes is the number. The Apple Pay card number differs from the number printed on the card, so a merchant may ask for the last four digits of the Apple Pay card number, which the cardholder reads in Wallet, or may ask the cardholder to open Wallet on the device used for the purchase, authenticate and hold it near the contactless reader. The refund itself runs on the card network.", "details": [ { "label": "A refund is the merchant's, and it goes back to the card", "value": "Returning an Apple Pay purchase works the way returning any card purchase does: the merchant's own policy decides, the cardholder can generally return by producing the receipt, and some merchants ask for more. When the merchant processes the refund it goes back to the payment card by itself, and it may take several days to appear on the card statement.", "citation": "Apple Support article 118270, Get a refund for purchases made with credit or debit cards using Apple Pay, opening paragraphs", "rests_on": "guidance" }, { "label": "The Apple Pay card number is not the card's number, which matters for refunds", "value": "The number the merchant sees for a card used in Apple Pay is not the number printed on the card. To process a refund a merchant may use the Apple Pay card number of the card in Wallet instead of the physical card's number, and may ask the cardholder for its last four digits; the cardholder finds them in Wallet by opening the card and its card number view on iPhone, or the card details view on Apple Watch. Some merchants need neither number. Where the merchant needs the card itself, the cardholder opens Wallet on the device used for the purchase, selects the card, double clicks the side button, authenticates with Face ID, Touch ID or the passcode, and holds the device near the contactless reader.", "citation": "Apple Support article 118270, Get a refund for purchases made with credit or debit cards using Apple Pay, Find your Apple Pay card number; Get a refund to a payment card that you use with Apple Pay; Apple Pay and privacy notice, paying in apps and on the web", "rests_on": "guidance" }, { "label": "The merchant does not receive the card number", "value": "A business accepting Apple Pay does not receive the customer's actual credit or debit card number, so it is not holding that data in its systems. What it receives instead is a device-specific account number, and for a recurring or merchant-initiated charge a merchant-specific account number. Apple does not store the original card number either; it keeps a card reference so that a card can be added again on a new device after the security code is entered.", "citation": "Apple Pay developer overview page, Data is more secure; Apple Pay and privacy notice, paying in apps and on the web; setting up Apple Pay; Payment token format reference (PassKit documentation), payment data keys, applicationPrimaryAccountNumber", "rests_on": "rule" } ], "exceptions": [ "Some merchants need neither the Apple Pay card number nor the physical card number.", "Where the merchant needs the card itself, the cardholder must use the same device the purchase was made on." ], "applies_to": "Apple Pay used to pay a merchant with a credit, debit or prepaid card held in Wallet, in an app, on the web, or in a store. Not Apple Cash, not Apple Card, not Wallet passes, and not a purchase from Apple itself.", "caveat": "Apple's article is consumer guidance, not a rule binding merchants: it says what generally happens, so nothing here obliges a merchant to refund anything. What obliges a merchant is its own policy, the law, and the card network's rules.", "related": [ "visa:refund", "mastercard:refund", "google-pay:refund" ], "basis": { "sources": "Support article 118270, read in full 2026-09-20; Apple Pay and privacy notice; Apple Pay developer overview.", "confidence": "medium" }, "currency": { "effective_since": "2025-05-29", "effective_to": null, "effective_note": "Drafted 2026-09-20 from the Apple pages saved that day. The date is the last-updated date the Developer Program License Agreement gives for itself and Schedule 1; the other pages carry no date, and each Rule dates its own source. Nothing here dates the card network's rules, which change with their own rulebooks and are held in the visa and mastercard rails.", "source_edition": "Apple Support article 118270, Get a refund for purchases made with credit or debit cards using Apple Pay, published date 2025-05-29 as the page states, read in full 2026-09-20 from the copy saved that day", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://support.apple.com/en-us/118270", "source_class": "public_primary", "source_title": "Apple Support article 118270, Get a refund for purchases made with credit or debit cards using Apple Pay", "checked_on": "2026-09-20", "checked_by": "validator-pass-through-wallets-2026-09-20", "notes": "Confirms a refund follows the merchant's own policy and is credited back to the payment card automatically, and that the Apple Pay card number a merchant may need differs from the physical card's." } ] }, "rail_name": "Apple Pay (pass-through wallet)", "governing_authority": "Apple, through the Apple Developer Program License Agreement and the Acceptable Use Guidelines for Apple Pay on the Web, for the wallet's own rules; the card network, the card issuer and the merchant's acquirer for the payment itself", "snapshot": "2026-09-20", "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "judgement", "label": "your bank's own terms", "needs": "whose terms decide it: the bank's, the participant's or the scheme's", "detail": "What obliges a merchant is its own policy, the law, and the card network's rules.", "from": "caveat" } ] }, { "uid": "apple-pay:return", "id": "return", "rail": "apple-pay", "kind": "rail-fact", "facet": "return", "name": "How is an Apple Pay payment disputed or returned?", "statement": "Not through Apple. Nothing in the pages read gives a cardholder an Apple route to dispute a card purchase from a merchant, claim it was unauthorised or force money back, and Apple's only published consumer guidance after such a purchase is about refunds by the merchant. Apple's own agreement puts the payment outside Apple, and Apple's privacy notice says the cardholder agreement, the user agreement and the merchant agreement keep governing the card and its use in Apple Pay. So a cardholder disputes with the card issuer under the card's rules, and the merchant answers under its acquiring agreement and the network's rules. Which dispute condition applies turns on the channel, because a tap in a store and a payment in an app are different transactions to the network.", "details": [ { "label": "Apple publishes no dispute channel of its own for a merchant purchase", "value": "For a card purchase from a merchant, nothing in the pages read offers an Apple route to dispute the payment, claim it was unauthorised or force money back. Apple's published consumer guidance after such a purchase covers refunds by the merchant and nothing else. Apple's terms put the payment outside Apple, and the card, cardholder and merchant agreements keep governing, so a cardholder disputes the payment with the card issuer under the card's rules, and the merchant answers it under its acquiring agreement and the network's rules.", "citation": "Apple Support article 118270, Get a refund for purchases made with credit or debit cards using Apple Pay, whole article; Apple Pay and privacy notice, closing paragraph; Apple Developer Program License Agreement (public copy, Agreement and Schedule 1 last updated 2026-08-18), 3.3.9(C)(i), not a party clause", "rests_on": "guidance" }, { "label": "The card, cardholder and merchant agreements keep governing", "value": "Any cardholder agreement, user agreement, merchant agreement or other terms that apply to the features of Apple Pay keep governing the cards and their use in Apple Pay, and those terms may carry privacy policies of their own. Apple's notice is in addition to whatever a bank tells the cardholder, not in place of it. So a cardholder's rights over a payment made with Apple Pay are the rights the card gives, and a merchant's duties are the duties its acquiring agreement and the network rules give.", "citation": "Apple Pay and privacy notice, closing paragraph", "rests_on": "rule" }, { "label": "Apple is not a party to the payment and is not responsible for it", "value": "Apple is not a party to any payment transaction facilitated through the Apple Pay APIs and is not responsible for one, and the agreement names the unavailability of an end user payment card and payment fraud among the things it is not responsible for. The payment runs between the developer and its own bank, acquirer, card networks and any other party it uses for transaction processing, and the developer must comply with whatever those agreements say, which may put rights, duties or limits on it that follow from its choice to use the Apple Pay APIs. For this part of the agreement, Apple means Apple Payments Services LLC where the developer is in the United States. Nothing in the wallet decides whether a payment is final, whether it can be undone, or who bears a loss; the card network, the issuer and the acquiring agreement decide all three.", "citation": "Apple Developer Program License Agreement (public copy, Agreement and Schedule 1 last updated 2026-08-18), 3.3.9(C)(i), not a party clause, and the closing sentence of 3.3.9(C)", "rests_on": "rule" }, { "label": "The Apple Pay card number is not the card's number, which matters for refunds", "value": "The number the merchant sees for a card used in Apple Pay is not the number printed on the card. To process a refund a merchant may use the Apple Pay card number of the card in Wallet instead of the physical card's number, and may ask the cardholder for its last four digits; the cardholder finds them in Wallet by opening the card and its card number view on iPhone, or the card details view on Apple Watch. Some merchants need neither number. Where the merchant needs the card itself, the cardholder opens Wallet on the device used for the purchase, selects the card, double clicks the side button, authenticates with Face ID, Touch ID or the passcode, and holds the device near the contactless reader.", "citation": "Apple Support article 118270, Get a refund for purchases made with credit or debit cards using Apple Pay, Find your Apple Pay card number; Get a refund to a payment card that you use with Apple Pay; Apple Pay and privacy notice, paying in apps and on the web", "rests_on": "guidance" } ], "exceptions": [ "A merchant refund is the one route Apple does describe, and it is not a dispute: the merchant decides it, and it runs back to the card.", "The cardholder may have to give the merchant the last four digits of the Apple Pay card number rather than the card's own, which is where support enquiries about an Apple Pay purchase usually fail." ], "applies_to": "Apple Pay used to pay a merchant with a credit, debit or prepaid card held in Wallet, in an app, on the web, or in a store. Not Apple Cash, not Apple Card, not Wallet passes, and not a purchase from Apple itself.", "caveat": "That Apple publishes no dispute channel is a finding of absence across the pages that were saved and read, not a statement Apple makes. Apple's wider consumer support site was not read [Unverified].", "related": [ "visa:return", "mastercard:return", "visa-dispute:10.1", "visa-dispute:10.2", "visa-dispute:10.4", "visa-dispute:13.1", "google-pay:return" ], "basis": { "sources": "Support article 118270; Apple Pay and privacy notice; Developer Program License Agreement 3.3.9(C)(i); read 2026-09-20. The linked Visa conditions and the Visa and Mastercard facts hold the network layer; no Visa or Mastercard document was read for this rail and none of their content is restated here.", "confidence": "medium" }, "currency": { "effective_since": "2025-05-29", "effective_to": null, "effective_note": "Drafted 2026-09-20 from the Apple pages saved that day. The date is the last-updated date the Developer Program License Agreement gives for itself and Schedule 1; the other pages carry no date, and each Rule dates its own source. Nothing here dates the card network's rules, which change with their own rulebooks and are held in the visa and mastercard rails.", "source_edition": "Apple Support article 118270, Get a refund for purchases made with credit or debit cards using Apple Pay, published date 2025-05-29 as the page states, read in full 2026-09-20 from the copy saved that day", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.apple.com/legal/privacy/data/en/apple-pay/", "source_class": "public_primary", "source_title": "Apple Pay and privacy notice", "checked_on": "2026-09-20", "checked_by": "validator-pass-through-wallets-2026-09-20", "notes": "Confirms cardholder, user and merchant agreements keep governing a card's use in Apple Pay, leaving a payment dispute with the card issuer and the merchant's acquiring agreement." } ] }, "rail_name": "Apple Pay (pass-through wallet)", "governing_authority": "Apple, through the Apple Developer Program License Agreement and the Acceptable Use Guidelines for Apple Pay on the Web, for the wallet's own rules; the card network, the card issuer and the merchant's acquirer for the payment itself", "snapshot": "2026-09-20", "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "apple-pay:settlement", "id": "settlement", "rail": "apple-pay", "kind": "rail-fact", "facet": "settlement", "name": "How does money actually move for an Apple Pay payment?", "statement": "On the card network, not through Apple. Apple's part ends at the credential: the payment information travels to Apple encrypted, is briefly decrypted there and re-encrypted with a merchant-specific key so that only the merchant, the developer or their payment processor can read it, and on a Mac that cannot hold the card the authorising device and the Mac talk over an encrypted channel through Apple's servers. From that point the merchant presents an ordinary card payment through its own bank, acquirer and card networks, under the agreements it holds with them, and a merchant that wants to accept Apple Pay needs a payment service provider that supports it. Apple holds no funds, runs no clearing and performs no settlement, and no settlement cycle, value date or netting rule of Apple's own was found in the pages read.", "details": [ { "label": "Apple re-encrypts the credential so only the merchant side can read it", "value": "To carry payment information through an app, a website or Business Chat, the credential goes to Apple encrypted, is briefly decrypted there and is re-encrypted with a merchant-specific key, so that only the merchant, the developer or their payment processor can decrypt it. Where a payment is made on a Mac that cannot hold the card, the Mac and the authorising device talk over an encrypted channel through Apple's servers. Apple does not keep any of this in a form that identifies the cardholder. Apple carries and re-wraps the credential; it does not carry the money.", "citation": "Apple Pay and privacy notice, transmitting payment information in apps, websites and Business Chat", "rests_on": "rule" }, { "label": "The merchant processes the payment through its own bank, acquirer and networks", "value": "Processing an Apple Pay payment is the merchant's own arrangement. The agreement puts the payment between the developer and its bank, its acquirer, the card networks and any other party it uses for transaction processing, and makes the developer responsible for complying with each of those agreements. Apple supplies no acquiring, no clearing and no settlement, and a merchant that wants to accept Apple Pay needs a payment service provider that supports it.", "citation": "Apple Developer Program License Agreement (public copy, Agreement and Schedule 1 last updated 2026-08-18), 3.3.9(C)(i), not a party clause; Apple Pay developer overview page, Find a PSP that supports Apple Pay", "rests_on": "rule" }, { "label": "Apple is not a party to the payment and is not responsible for it", "value": "Apple is not a party to any payment transaction facilitated through the Apple Pay APIs and is not responsible for one, and the agreement names the unavailability of an end user payment card and payment fraud among the things it is not responsible for. The payment runs between the developer and its own bank, acquirer, card networks and any other party it uses for transaction processing, and the developer must comply with whatever those agreements say, which may put rights, duties or limits on it that follow from its choice to use the Apple Pay APIs. For this part of the agreement, Apple means Apple Payments Services LLC where the developer is in the United States. Nothing in the wallet decides whether a payment is final, whether it can be undone, or who bears a loss; the card network, the issuer and the acquiring agreement decide all three.", "citation": "Apple Developer Program License Agreement (public copy, Agreement and Schedule 1 last updated 2026-08-18), 3.3.9(C)(i), not a party clause, and the closing sentence of 3.3.9(C)", "rests_on": "rule" }, { "label": "The merchant does not receive the card number", "value": "A business accepting Apple Pay does not receive the customer's actual credit or debit card number, so it is not holding that data in its systems. What it receives instead is a device-specific account number, and for a recurring or merchant-initiated charge a merchant-specific account number. Apple does not store the original card number either; it keeps a card reference so that a card can be added again on a new device after the security code is entered.", "citation": "Apple Pay developer overview page, Data is more secure; Apple Pay and privacy notice, paying in apps and on the web; setting up Apple Pay; Payment token format reference (PassKit documentation), payment data keys, applicationPrimaryAccountNumber", "rests_on": "rule" } ], "exceptions": [ "None of Apple's own: there is no settlement path in the wallet to make an exception to. Every exception that matters is the card network's, and sits in visa:settlement and mastercard:settlement." ], "applies_to": "Apple Pay used to pay a merchant with a credit, debit or prepaid card held in Wallet, in an app, on the web, or in a store. Not Apple Cash, not Apple Card, not Wallet passes, and not a purchase from Apple itself.", "caveat": "Apple re-encrypting the credential is not settlement and not even authorisation. It is transport. Nothing Apple does here puts Apple in the money flow.", "related": [ "visa:settlement", "mastercard:settlement", "google-pay:settlement" ], "basis": { "sources": "Apple Pay and privacy notice; Developer Program License Agreement 3.3.9(C)(i); Apple Pay developer overview; read 2026-09-20.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the notice carries no date", "effective_to": null, "effective_note": "Drafted 2026-09-20 from the Apple pages saved that day. The date is the last-updated date the Developer Program License Agreement gives for itself and Schedule 1; the other pages carry no date, and each Rule dates its own source. Nothing here dates the card network's rules, which change with their own rulebooks and are held in the visa and mastercard rails.", "source_edition": "Apple Pay and privacy notice, undated page, read in full 2026-09-20 from the copy saved that day", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.apple.com/legal/privacy/data/en/apple-pay/", "source_class": "public_primary", "source_title": "Apple Pay and privacy notice", "checked_on": "2026-09-20", "checked_by": "validator-pass-through-wallets-2026-09-20", "notes": "Confirms Apple re-encrypts the payment credential for the merchant, the developer or their payment processor, and does not itself hold funds or perform settlement." } ] }, "rail_name": "Apple Pay (pass-through wallet)", "governing_authority": "Apple, through the Apple Developer Program License Agreement and the Acceptable Use Guidelines for Apple Pay on the Web, for the wallet's own rules; the card network, the card issuer and the merchant's acquirer for the payment itself", "snapshot": "2026-09-20", "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "au-npp:consumer-law", "id": "consumer-law", "rail": "au-npp", "kind": "rail-fact", "facet": "consumer-law", "name": "What consumer law sits above the NPP?", "statement": "Three instruments and none of them is a payment services directive. The ePayments Code is voluntary, administered by the corporate regulator, and binds only the institutions that subscribe to it; it covers disclosure, liability for unauthorised transactions, the mistaken internet payment process and account switching. The Scams Prevention Framework, in Part IVF of the competition and consumer legislation, puts six principles on regulated entities, governance, prevent, detect, report, disrupt and respond, each backed by civil penalties, and for banking it reaches a service an authorised deposit-taking institution provides in the course of its banking business, with the corporate regulator as sector regulator. It arrives in stages: until before 1 September 2026 almost none of it applied to banking, from 1 September 2026 the duty to belong to an authorised external dispute resolution scheme applies, and from 31 March 2027 the whole of it does. The external dispute resolution scheme is also the route a customer already has when their institution mishandles a mistaken payment report.", "details": [ { "label": "The ePayments Code is voluntary and binds only the institutions that subscribe to it", "value": "Everything the Code requires is an obligation of a subscriber. It is administered by the corporate regulator and the rulebook's own definitions point at it, but it is not legislation and a record that says Australian law requires, where it means the Code requires of its subscribers, is wrong. Its mistaken payment chapter binds subscribers that are authorised deposit-taking institutions, other than providers of purchased payment facilities. Which institutions subscribe is not held.", "citation": "ePayments Code, clause 25.1, and the Code as a whole; Regulations for the New Payments Platform, v21.0, public version, the definition of ePayments Code", "rests_on": "guidance" }, { "label": "The external dispute resolution scheme hears a mistaken payment complaint about the sending institution", "value": "A customer who reports a mistaken payment may complain to their own institution about how it was handled, including that the institution was not satisfied a mistaken payment happened or did not follow the Code's processes and timeframes. The institution must deal with that through its internal dispute resolution and must not send the customer to the other institution instead. If the customer is not satisfied, they must be able to complain to the external dispute resolution scheme about their own institution, and both institutions must cooperate with it and comply with its decisions.", "citation": "ePayments Code, clauses 36.1 to 36.5 and clause 15.2", "rests_on": "guidance" }, { "label": "The Scams Prevention Framework puts six principles on a regulated entity, each backed by civil penalties", "value": "Australia's answer to scams is a set of duties rather than a payout rule. The framework's principles are governance, prevent, detect, report, disrupt and respond, and the provisions that carry them are civil penalty provisions. For banking, a regulated entity is one providing a service an authorised deposit-taking institution supplies in the course of its banking business in Australia, or a purchased payment facility it provides, and the corporate regulator is the sector regulator.", "citation": "Scams Prevention Framework Act 2025 (No. 15, 2025), Part IVF Division 2, Subdivisions B to G; Competition and Consumer (Scams Prevention Framework, Regulated Sectors) Designation 2026, sections 11 and 12", "rests_on": "law" }, { "label": "A regulated entity must run internal dispute resolution and have regard to any apportionment guidelines", "value": "Under the respond principle a regulated entity must have an accessible way for its customers to report activities that are or may be scams, and an accessible and transparent internal dispute resolution mechanism for complaints about them, and must publish information about both. When it handles such a complaint it must give a statement about whether it met its own obligations, and must have regard to any process and to any guidelines for apportioning liability that the framework rules prescribe. The Act says in terms that those guidelines need not be consistent with its own proportionate liability provisions, which makes them the closest thing Australia has to a reimbursement rule if they are ever made.", "citation": "Scams Prevention Framework Act 2025 (No. 15, 2025), sections 58BZB, 58BZC, 58BZD, 58BZE(1) and (1A) and 58BZF", "rests_on": "law" }, { "label": "Since 1 September 2026 a bank must belong to an authorised external dispute resolution scheme for scams", "value": "The first part of the framework to bite for banking. The Designation switched most of Part IVF off for covered banking services until before 1 September 2026, leaving only the sector code division and the section that lets the Minister authorise a dispute resolution scheme. From 1 September 2026 it also leaves on the section that makes it a civil penalty provision for a regulated entity to provide a regulated service while not a member of an authorised scheme, to fail to assist or cooperate with the scheme operator, or to break a related obligation in the sector code.", "citation": "Competition and Consumer (Scams Prevention Framework, Regulated Sectors) Designation 2026, provision 101(1) to (4); Scams Prevention Framework Act 2025 (No. 15, 2025), section 58BZG(1) to (4)", "rests_on": "law" }, { "label": "The whole of the framework reaches banking from 31 March 2027", "value": "The Designation's transitional rule for banking ends before 31 March 2027. From that date every principle and every civil penalty provision in the framework applies to covered banking services, not just the dispute resolution membership section. This is the largest dated change on this rail and the one a watch should track first.", "citation": "Competition and Consumer (Scams Prevention Framework, Regulated Sectors) Designation 2026, provision 101(3) and (4)", "rests_on": "law" } ], "exceptions": [ "The framework applies to telecommunications and digital platform services on the same staged timetable, so a scam loss may be apportioned against a telephone company or a platform as well as a bank.", "The Act was read as made rather than as a current compilation of Part IVF, so a later amendment to a cited section is not held." ], "applies_to": "institutions providing covered banking services in Australia, and separately the institutions that have chosen to subscribe to the ePayments Code", "caveat": "The largest dated change on this rail is 31 March 2027, when the whole of the Scams Prevention Framework reaches banking. Until then only the external dispute resolution membership duty and the sector code machinery are switched on.", "related": [ "uk-fps:consumer-law", "in-upi:consumer-law", "au-npp:liability", "au-npp:refund" ], "basis": { "sources": "ASIC's ePayments Code of 2 June 2022; the Scams Prevention Framework Act 2025 as made; and the Competition and Consumer (Scams Prevention Framework, Regulated Sectors) Designation 2026, sections 11, 12 and provision 101. All read 2026-09-21.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the rulebook dates individual amendments rather than provisions, and the current edition cannot be read", "effective_to": null, "effective_note": "Drafted 2026-09-21 in Orca Core form. Where this fact rests on the rulebook it rests on NPP Regulations v21.0 of 24 September 2024, because the current edition is published only as scanned page images. What moved between the two editions is not held [Unverified]. Where it rests on the ePayments Code or on the Scams Prevention Framework instruments it rests on current text that an agent can read.", "source_edition": "NPP Regulations v21.0 of 24 September 2024, the public redacted version and the newest readable edition of the rulebook; the NPP Payment Initiation Messages technical guidance v4.0 of 20 November 2025; ASIC's ePayments Code as published 2 June 2022; the Scams Prevention Framework Act 2025 as made and the Competition and Consumer (Scams Prevention Framework, Regulated Sectors) Designation 2026; the Reserve Bank of Australia's About RITS page; and Australian Payments Plus's PayTo FAQs. All read 2026-09-21. The current edition of the rulebook, NPP Product Rules v.31 of September 2026, was downloaded the same day and could not be read: 102 pages, no font resource on any page and no extractable character.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.legislation.gov.au/C2025A00015/asmade/2025-02-20/text/original/pdf", "source_class": "authoritative_primary", "source_title": "Scams Prevention Framework Act 2025 (No. 15, 2025)", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Confirms the Scams Prevention Framework's six principles, governance, prevent, detect, report, disrupt, respond, as civil penalty provisions in Part IVF Division 2." }, { "source_url": "https://www.legislation.gov.au/F2026L00627/asmade/2026-05-28/text/original/pdf", "source_class": "authoritative_primary", "source_title": "Competition and Consumer (Scams Prevention Framework, Regulated Sectors) Designation 2026", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Confirms covered banking services as a regulated sector with ASIC as sector regulator (sections 11, 12), and the transitional dates in provision 101: almost none of Part IVF applying to banking until before 1 September 2026, the EDR scheme membership duty from 1 September 2026, and the whole of Part IVF from 31 March 2027." }, { "source_url": "https://download.asic.gov.au/media/lloeicwb/epayments-code-published-02-june-2022.pdf", "source_class": "authoritative_primary", "source_title": "ePayments Code", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Confirms the ePayments Code as a voluntary code binding subscribers only, covering disclosure, unauthorised transaction liability, the mistaken internet payment process and account switching, with AFCA as the existing complaint route for a mishandled mistaken payment report." } ] }, "rail_name": "New Payments Platform (Australia)", "governing_authority": "NPP Australia Limited", "snapshot": "2026-09-20", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "au-npp:decision-points", "id": "decision-points", "rail": "au-npp", "kind": "rail-fact", "facet": "decision-points", "name": "Where does somebody decide something on the NPP?", "statement": "Ten places, and most of them are invisible to the person paying. The receiving institution decides whether to accept or reject, inside a timeout nobody outside the scheme can see. The paying institution screens for sanctions and financial crime before it sends, under frameworks it attests to annually rather than through any message. A payer who uses Confirmation of Payee decides what to do with the outcome, in a service that is compulsory for participants in two of its roles. On the PayTo side the payer decides almost everything: whether to authorise an agreement their institution must deliver to them in near real time, and afterwards whether to pause, resume, cancel or amend it in their own banking, which their institution must promptly act on, while a change to the amount or the frequency has to come from the business as a fresh agreement to authorise. A mandate can be moved to another institution on either party's instruction. And with a migrated direct debit mandate, which the business and its sponsor created without asking anybody, the payer's institution may choose to seek confirmation and must keep processing until it hears. After the money has gone, the decisions are the receiving institution's: whether it is satisfied a payment was misdirected, whether to return a duplicate at all, and under the ePayments Code how much to pursue where the money is not all there.", "details": [ { "label": "The receiving institution decides, inside a timeout nobody outside the scheme can see", "value": "The first decision on every payment belongs to the receiving institution, and it has to make it inside the configurable timeout the scheme operator prescribes. Accept, and the payment is cleared and heads for settlement. Reject, and it must put a reason code in the message and nothing happens at all. No public figure exists for how long it has.", "citation": "Regulations for the New Payments Platform, v21.0, public version, Regulation 6.3(a)", "rests_on": "rule" }, { "label": "The paying institution screens before it sends, and attests to its framework once a year", "value": "Sanctions and know your customer screening on this rail is an attestable obligation rather than a message. Each participant is responsible for its own compliance and for satisfying itself that each institution it sponsors has a framework, must maintain a sanctions compliance framework and a customer due diligence framework and review each at least annually, and must give the operator an annual attestation by a senior officer that each framework is in operation, is being implemented, and that daily customer screening is being carried out. The operator keeps a register of those attestations and makes it available to every participant.", "citation": "Regulations for the New Payments Platform, v21.0, public version, Regulation 6.1(d)(i) to (vi), (e) and (f)", "rests_on": "rule" }, { "label": "The payer decides what to do with a Confirmation of Payee outcome, and the service is compulsory for two roles", "value": "Confirmation of Payee lets a payer check a payee's name in real time before paying, through central matching against confirmed records, proprietary matching against observed records, or matching inside one institution. Taking part is mandatory for a participant and its sponsored institutions in two capacities, as a holder of confirmed data and as a requestor, and optional as a holder of observed data, for a connected institution and for an overlay service provider. The service is for domestic use only. What outcomes it returns, and the reason values behind them, sit in a procedures volume that is not public.", "citation": "Regulations for the New Payments Platform, v21.0, public version, Regulation 18.1(a), (b) and (f)", "rests_on": "rule" }, { "label": "A PayTo mandate is a record in a database the scheme operator runs, not a document a party keeps", "value": "The Mandate Management Service is a centralised, secure, access controlled database of mandates that the scheme operator established and runs. A mandate is a record in it of a payment authorisation the payer gave in favour of a business or a payment initiator, identified by a unique mandate identifier the database itself generates, which gives the holder the right to send requests instructing the payer's own institution to make payments within the mandate's terms. The database may also hold, at the payer institution's option, records of another kind of arrangement defined only in the procedures.", "citation": "Regulations for the New Payments Platform, v21.0, public version, Regulation 17.1(a) and (b), and Regulation 17.1(g)", "rests_on": "rule" }, { "label": "Offering PayTo is optional for a creditor's bank and compulsory for the payer's bank", "value": "The service is asymmetric by design. Taking part is optional for a participant acting as a provider of the service to businesses, optional for a connected institution, and optional for an overlay service provider, but it is mandatory for every participant and sponsored institution in its capacity as a payer participant and account servicer. A payer's institution must also provide the service for every account type that is enabled and eligible to make payments on the platform.", "citation": "Regulations for the New Payments Platform, v21.0, public version, Regulation 17.1(f)(i) to (iv) and Regulation 17.1(n)", "rests_on": "rule" }, { "label": "The payer's institution must deliver the authorisation request to the payer in near real time", "value": "Creating a mandate record is not the same as authorising it. The payer's institution must be able to receive authorisation requests from the operator's database, must associate each one with a payer by the account number in the record, must deliver it to that customer in near real time for authorisation to the standards the procedures set, must take any consents privacy law needs, and must record the confirmation in the database promptly after the customer authorises or rejects it. The mandate is active only once that confirmation is recorded.", "citation": "Regulations for the New Payments Platform, v21.0, public version, Regulation 17.6(c)(i) to (v), and the definition of Active", "rests_on": "rule" }, { "label": "No payment request may be sent unless the mandate is active", "value": "A participant or connected institution acting as the initiating participant must not send a mandate payment initiation request unless the associated mandate is active, and is responsible for each request it sends being properly built and consistent with the mandate's terms. Sending one against a suspended or cancelled mandate is one of the things the rulebook lists as not authorised, which is what turns the resulting payment into a claim. The payer's institution may look the mandate up before processing but is not obliged to.", "citation": "Regulations for the New Payments Platform, v21.0, public version, Regulations 17.8(a), (b) and (c), and 17.10(c)(i)(B)", "rests_on": "rule" }, { "label": "The payer decides on a PayTo agreement, and can pause, resume, amend or cancel it in their own banking", "value": "The payer's decisions about a mandate are real and the rulebook makes their institution provide for them. The payer authorises or rejects the agreement when it is delivered to them, and afterwards can view their agreements and instruct their institution to suspend, cancel or make permitted amendments, which the institution must promptly give effect to. The operator's parent puts the same thing to customers as pause, resume or cancel in online banking, and adds that pausing or cancelling does not change the payer's contract with the business.", "citation": "Regulations for the New Payments Platform, v21.0, public version, Regulation 17.6(c)(iii), (v) and (vii); Australian Payments Plus, PayTo FAQs, managing PayTo agreements", "rests_on": "rule" }, { "label": "The payer's institution must give the payer a way to view, suspend, cancel and amend their mandates", "value": "A payer participant must provide a facility that lets payers see the mandates they are a party to and give instructions to suspend or cancel them or make permitted amendments to them, and must promptly give effect to those instructions. Whoever performs any mandate maintenance function is responsible for making sure the particular mandate's terms allow it. The operator's parent describes the same thing to customers as pausing, resuming or cancelling in online banking, and says that doing so does not change the customer's contract with the business.", "citation": "Regulations for the New Payments Platform, v21.0, public version, Regulation 17.6(c)(vii) and 17.6(d); Australian Payments Plus, PayTo FAQs, can I change, pause, resume or cancel my PayTo agreement", "rests_on": "rule" }, { "label": "A change to the amount or the frequency has to come from the business as a fresh agreement", "value": "A payer can pause, resume and cancel, and can make the amendments the mandate's terms permit, but cannot simply raise or lower what they agreed to. The operator's parent says that for a change of amount or frequency the business has to make the change and send the payer an updated agreement to authorise. That keeps every change to the substance of the authorisation on the same footing as the original one.", "citation": "Australian Payments Plus, PayTo FAQs, can I change, pause, resume or cancel my PayTo agreement; Regulations for the New Payments Platform, v21.0, public version, Regulation 17.6(d), on a maintenance function being permitted by the mandate's terms", "rests_on": "guidance" }, { "label": "A mandate may be moved to another institution without the authorisation changing", "value": "A mandate can change custodian. The payer's institution must facilitate porting a mandate where necessary at the payer's request, and a mandate established for a payment initiator may be moved to another participant or connected institution on the initiator's instruction. An institution's right to read a mandate record is expressly subject to the other parties' right to port it away. All the porting provisions took effect on 5 May 2023.", "citation": "Regulations for the New Payments Platform, v21.0, public version, Regulations 17.6(c)(vi), 17.5(f) and 17.7(b)(iv), and the Part 17 drafting note on porting", "rests_on": "rule" }, { "label": "A mandate record is confidential to its parties and may be looked up only by them", "value": "Lookup rights are restricted to the parties to the mandate, and information in a mandate record must be treated as confidential to them and not disclosed to anybody else except as law requires. A lookup may be performed only for validating and processing requests and payments, resolving investigations and claims, fraud investigation and analytics, or giving effect to the parties' own instructions. Institutions must have systems to prevent unauthorised disclosure, to spot it promptly when it happens, and must tell the operator in writing when it does.", "citation": "Regulations for the New Payments Platform, v21.0, public version, Regulations 17.2(e) and 17.7(a) and (b)", "rests_on": "rule" }, { "label": "The mandate record is the evidence of the amount, the frequency and the beneficiary", "value": "The rulebook says out loud what most rails leave implicit: the mandate record is evidence of the quantum, the frequency and, where it is recorded, the beneficiary of the payments the payer authorised. That single sentence is why a claim that a payment fell outside the amount, frequency or beneficiary of an ordinary PayTo mandate is deemed substantiated simply by reference to the record.", "citation": "Regulations for the New Payments Platform, v21.0, public version, Regulation 17.10(d)", "rests_on": "rule" }, { "label": "A migrated direct debit mandate is created unilaterally and is active the moment it exists", "value": "The one mandate in the corpus nobody consented to. A participant that is a framework participant in the direct debit system may create mandate records for direct debit arrangements it already processes for the businesses it sponsors. Those records are designated migrated mandates, they are established unilaterally by the business and its sponsor, and they are deemed active in the operator's database immediately on creation. The business is deemed approved as a user of the service by the same act. The obligations to deliver an authorisation request to the payer and to facilitate porting are expressly switched off for them.", "citation": "Regulations for the New Payments Platform, v21.0, public version, Regulations 17.4(a), (b) and (d), and 17.6(c)(viii)", "rests_on": "rule" }, { "label": "A migrated mandate needs written notice to the payer first, at least 14 days ahead", "value": "The consent step is replaced by a notice step. Before the record is created, the business must have told each of its payers in writing that future debits will generally go through the platform rather than the direct debit system where their account can take them, and must have given whatever notice its direct debit service agreement requires or at least fourteen days. It must hold and be able to produce evidence of the original direct debit authorisation and of the notice. Direct debit processing of the same arrangement must stop from the migration date, except in a genuine outage. The operator's parent tells customers they may opt out during the notice period and stay on direct debit.", "citation": "Regulations for the New Payments Platform, v21.0, public version, Regulation 17.4(c)(i) to (iii); Australian Payments Plus, PayTo FAQs, what should I do if my direct debit is moving to PayTo, and do I have to agree", "rests_on": "rule" }, { "label": "A migrated mandate may not be used for a payment request until 5 days after it was created", "value": "The second safeguard is delay. A migrated mandate may be used to issue a mandate payment initiation request no earlier than five days after the time and date it was created. To let the payer's institution check the arrangement against its own customer's account status and transaction history, the record must carry the business's direct debit user identifier.", "citation": "Regulations for the New Payments Platform, v21.0, public version, Regulation 17.4(e)", "rests_on": "rule" }, { "label": "With a migrated mandate the payer's institution may ask its customer, and must keep processing until it hears", "value": "The one decision on this rail where doing nothing is the prescribed course. With a migrated mandate the payer's institution could optionally satisfy itself that the record matches its customer's existing direct debit and may ask the customer to confirm the authorisation; if the customer confirms, it must keep a record. If the customer says no authorisation was given, or instructs suspension or cancellation, it must act promptly. Pending any word at all, it must carry on processing requests against the mandate.", "citation": "Regulations for the New Payments Platform, v21.0, public version, Regulation 17.4(d)(i) to (iv)", "rests_on": "rule" }, { "label": "Until the payer says something, their institution must keep processing a migrated mandate", "value": "The payer's institution could optionally satisfy itself that a migrated mandate really matches its customer's existing direct debit and may ask the customer to confirm it, and must keep a record if the customer does. If the customer says authorisation was never given, or tells it to suspend or cancel, it must act promptly. But pending confirmation or any other instruction from the customer, it must continue to process payment requests against the mandate. Treating one of these as unauthorised by default would misstate the rule as badly as treating it as authorised.", "citation": "Regulations for the New Payments Platform, v21.0, public version, Regulation 17.4(d)(i) to (iv)", "rests_on": "rule" }, { "label": "Returning a duplicate or error payment is at the receiving institution's discretion", "value": "Where a settled payment is a duplicate, an error payment, or one the paying institution sent through its own mistake, the paying institution may ask for it back and the receiving institution must acknowledge and must assess. Whether it then returns the money is expressly its own decision, and the rulebook says in terms that the return of such a settled payment is at its discretion.", "citation": "Regulations for the New Payments Platform, v21.0, public version, Regulations 6.4(c)(i) and 6.5(c)(i) and (ii)", "rests_on": "rule" }, { "label": "Where the money is not all there, the receiving institution weighs both customers and decides how much to pursue", "value": "Where both institutions accept a mistaken payment happened but the recipient's account no longer holds the full amount, the receiving institution must exercise a discretion, weighing the interests of the payer and of the recipient and what it reasonably knows about the circumstances, and decide whether to pursue the whole amount, part of it, or none. The Code lists factors to guide that discretion and says it is not unfettered, and where the institution decides to pursue the money it must use reasonable endeavours to get it back, for example by accepting instalments. The same reporting tiers still apply.", "citation": "ePayments Code, clauses 34.1 to 34.6", "rests_on": "guidance" } ], "exceptions": [ "With a migrated direct debit mandate the prescribed course, pending any word from the customer, is to keep processing.", "What outcomes Confirmation of Payee returns, and the reason values behind them, are in a procedures volume that is not public." ], "applies_to": "payments on the New Payments Platform in Australia, in Australian dollars between Australian domiciled accounts: ordinary credit transfers, overlay service payments including Osko, the domestic leg of international transfers, and PayTo payments", "caveat": "The decision that matters most on this rail is one the payer never sees and cannot influence: the receiving institution's accept or reject, taken inside a timeout no public document states.", "related": [ "uk-fps:decision-points", "rtp:decision-points", "au-npp:liability", "au-npp:recall" ], "basis": { "sources": "NPP Regulations v21.0, Regulations 6.1(d), 6.3(a), 6.4(c)(i), 6.5(b) and (c), 17.4(d), 17.6(c) and 18.1(b); Australian Payments Plus's PayTo FAQs; ASIC's ePayments Code clause 34.2. All read 2026-09-21.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the rulebook dates individual amendments rather than provisions, and the current edition cannot be read", "effective_to": null, "effective_note": "Drafted 2026-09-21 in Orca Core form. Where this fact rests on the rulebook it rests on NPP Regulations v21.0 of 24 September 2024, because the current edition is published only as scanned page images. What moved between the two editions is not held [Unverified]. Where it rests on the ePayments Code or on the Scams Prevention Framework instruments it rests on current text that an agent can read.", "source_edition": "NPP Regulations v21.0 of 24 September 2024, the public redacted version and the newest readable edition of the rulebook; the NPP Payment Initiation Messages technical guidance v4.0 of 20 November 2025; ASIC's ePayments Code as published 2 June 2022; the Scams Prevention Framework Act 2025 as made and the Competition and Consumer (Scams Prevention Framework, Regulated Sectors) Designation 2026; the Reserve Bank of Australia's About RITS page; and Australian Payments Plus's PayTo FAQs. All read 2026-09-21. The current edition of the rulebook, NPP Product Rules v.31 of September 2026, was downloaded the same day and could not be read: 102 pages, no font resource on any page and no extractable character.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.auspayplus.com.au/wp-content/uploads/2024/10/NPP-Regulations-v21.0_Public_version.pdf", "source_class": "authoritative_primary", "source_title": "Regulations for the New Payments Platform, v21.0, public version", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Confirms the payee participant's accept or reject decision inside a configurable timeout (6.3(a)), the payer participant's annual sanctions and KYC attestation regime (6.1(d)), the payer customer's authorisation, pause, resume, cancel and amendment decisions over a Mandate (17.6(c)), the mandatory Confirmation of Payee roles (18.1(b)), the payer participant's optional confirmation step for a Migrated DDR Mandate with continued processing pending any word (17.4(d)), Mandate porting on either party's instruction (17.5(f), 17.6(c)(vi), 17.7(b)(iv)), and the receiving institution's satisfaction-based and discretionary return decisions for a Misdirected, Duplicate or Error Payment (6.5(b), 6.4(c), 6.5(c))." }, { "source_url": "https://download.asic.gov.au/media/lloeicwb/epayments-code-published-02-june-2022.pdf", "source_class": "authoritative_primary", "source_title": "ePayments Code", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Confirms the receiving institution's clause 34.2 discretion to pursue full, partial or no return where the unintended recipient's account does not hold the full amount of a mistaken internet payment." } ] }, "rail_name": "New Payments Platform (Australia)", "governing_authority": "NPP Australia Limited", "snapshot": "2026-09-20", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "au-npp:finality", "id": "finality", "rail": "au-npp", "kind": "rail-fact", "facet": "finality", "name": "When is an NPP payment final, and can it be undone?", "statement": "Three different moments, and confusing them is the commonest mistake on this rail. The paying institution loses control first: once the clearing request is in its own gateway it can neither cancel nor recall it. The payment becomes cleared second, when the receiving institution accepts it, and cleared is not final: nothing obliges the receiving institution to put the money on an account yet. It becomes irrevocable third, when the Fast Settlement Service settles it across the two institutions' accounts at the central bank, and settlement through that system is final and irrevocable as a matter of statute. Between the second moment and the third there is a state no deferred net settlement rail has: a cleared payment the settlement service rejects is deemed immediately void, the paying institution owes nothing for it, and it decides alone whether to send it again.", "details": [ { "label": "The paying institution cannot cancel or recall a payment once the message is in its own gateway", "value": "The point of no return on this rail is early and it is inside the sending institution. Once the clearing request has been input into the payer participant's own gateway, that participant may neither cancel it nor recall it. Nothing later moves that point, and there is no message in the scheme for taking a payment back.", "citation": "Regulations for the New Payments Platform, v21.0, public version, Regulation 6.2(a)", "rests_on": "rule" }, { "label": "Cleared means the receiving institution accepted it, and cleared is not settled", "value": "A payment is cleared at the moment the paying institution receives a clearing notification from the receiving institution carrying a status that indicates acceptance. That is a state of the message exchange, not of the money: nothing in the rules or the procedures obliges the receiving institution to put a cleared payment on an account before it settles.", "citation": "Regulations for the New Payments Platform, v21.0, public version, Regulations 6.2(b) and 6.2(f)(i)", "rests_on": "rule" }, { "label": "A cleared payment becomes irrevocable when the Fast Settlement Service settles it", "value": "Irrevocability arrives with settlement, not with acceptance. A cleared payment is irrevocable once the Fast Settlement Service has settled it, and both institutions learn that it has from the settlement notification the service sends them.", "citation": "Regulations for the New Payments Platform, v21.0, public version, Regulations 6.2(d) and 7.4(a)", "rests_on": "rule" }, { "label": "A cleared payment the settlement service rejects is void, and the paying institution owes nothing for it", "value": "This is the state a reader of most instant rails does not expect. If the settlement service rejects the settlement request for a payment the receiving institution has already accepted, that cleared payment is deemed immediately void, and the paying institution is not liable to discharge any obligation to the receiving institution or to the payee in respect of it.", "citation": "Regulations for the New Payments Platform, v21.0, public version, Regulations 6.2(e), 6.2(f)(ii)(A) and 7.4(b)", "rests_on": "rule" }, { "label": "After a settlement rejection the paying institution alone decides whether to replay or retry", "value": "Where the settlement service rejects a cleared payment, the payer participant is solely responsible for deciding whether to send it again. The two ways of doing that are not the same thing and the rulebook defines both: a replay is the same message sent again under the same transaction identifier, and a retry is a resend that marks itself as one in the thirty fifth character of the transaction or return identifier.", "citation": "Regulations for the New Payments Platform, v21.0, public version, Regulation 6.2(f)(ii)(B), and the definitions of Replay and Retry", "rests_on": "rule" }, { "label": "Settlement through RITS is final and irrevocable as a matter of statute", "value": "Underneath the scheme's own irrevocability rule sits a statutory one. The system the Fast Settlement Service is part of is an approved real time gross settlement system under the Payment Systems and Netting Act 1998, and the Reserve Bank states that transactions settled through it are final and irrevocable.", "citation": "Reserve Bank of Australia, About RITS, Real-time Gross Settlement", "rests_on": "law" } ], "exceptions": [ "A cleared payment can stop existing. If the settlement service rejects it, it is void and nothing is returned, because nothing settled.", "Money can still come back afterwards, as a return, or under the ePayments Code's mistaken payment process, or as an indemnity payment on a mandate claim. None of those undoes the original payment." ], "applies_to": "payments on the New Payments Platform in Australia, in Australian dollars between Australian domiciled accounts: ordinary credit transfers, overlay service payments including Osko, the domestic leg of international transfers, and PayTo payments", "caveat": "Do not read cleared as final. On this rail the two moments are seconds apart and can still come out differently, which is the opposite of a rail where clearing and settlement are hours or days apart but a cleared payment always settles.", "related": [ "rtp:finality", "fednow:finality", "uk-fps:finality", "ch-sic-ip:finality", "au-npp:settlement", "au-npp:recall" ], "basis": { "sources": "NPP Regulations v21.0, Regulations 6.2(a) to (f) and 7.4, and the Reserve Bank's About RITS page, both read 2026-09-21.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the rulebook dates individual amendments rather than provisions, and the current edition cannot be read", "effective_to": null, "effective_note": "Drafted 2026-09-21 in Orca Core form. Where this fact rests on the rulebook it rests on NPP Regulations v21.0 of 24 September 2024, because the current edition is published only as scanned page images. What moved between the two editions is not held [Unverified]. Where it rests on the ePayments Code or on the Scams Prevention Framework instruments it rests on current text that an agent can read.", "source_edition": "NPP Regulations v21.0 of 24 September 2024, the public redacted version and the newest readable edition of the rulebook; the NPP Payment Initiation Messages technical guidance v4.0 of 20 November 2025; ASIC's ePayments Code as published 2 June 2022; the Scams Prevention Framework Act 2025 as made and the Competition and Consumer (Scams Prevention Framework, Regulated Sectors) Designation 2026; the Reserve Bank of Australia's About RITS page; and Australian Payments Plus's PayTo FAQs. All read 2026-09-21. The current edition of the rulebook, NPP Product Rules v.31 of September 2026, was downloaded the same day and could not be read: 102 pages, no font resource on any page and no extractable character.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.auspayplus.com.au/wp-content/uploads/2024/10/NPP-Regulations-v21.0_Public_version.pdf", "source_class": "authoritative_primary", "source_title": "Regulations for the New Payments Platform, v21.0, public version", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Confirms the three moments the fact distinguishes: the point of no return once a Clearing Request enters the Payer Participant's gateway (6.2(a)), clearance on an accepting Clearing Notification without any obligation to credit an account first (6.2(b), (f)(i)), and irrevocability on FSS settlement (6.2(d), 7.4(a)), with a cleared payment the FSS rejects deemed immediately void (6.2(e), 7.4(b))." }, { "source_url": "https://www.rba.gov.au/payments-and-infrastructure/rits/about.html", "source_class": "authoritative_primary", "source_title": "Reserve Bank of Australia, About RITS", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Confirms RITS, of which the FSS is a component, is an approved RTGS system under the Payment Systems and Netting Act 1998 with settled transactions final and irrevocable." } ] }, "rail_name": "New Payments Platform (Australia)", "governing_authority": "NPP Australia Limited", "snapshot": "2026-09-20", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "au-npp:hours", "id": "hours", "rail": "au-npp", "kind": "rail-fact", "facet": "hours", "name": "When is the NPP open?", "statement": "Always. The platform was established to clear and settle payments in near real time 24 hours a day 7 days a week, and the Reserve Bank describes the settlement service the same way. There is no cut off, no settlement window, and no difference between a Tuesday morning and a Sunday night or a public holiday, for clearing or for settlement. What the public record does not contain is any number: every response timeout is a configurable value the scheme operator prescribes in a document Orca cannot read, and service availability is governed as a compliance requirement whose target is not published. When a receiving institution puts a cleared payment on an account is, above a minimum in the procedures, its own service standard rather than a scheme obligation.", "details": [ { "label": "Clearing and settlement both run 24 hours a day, every day of the year", "value": "There is no cut off to miss and no window to wait for. The infrastructure was established as a utility platform for near real time clearing and settlement on a basis that runs 24 hours a day 7 days a week, and the Reserve Bank describes the settlement service the same way. Weekends and public holidays make no difference to either leg, which is the sharpest single contrast between this rail and every deferred net settlement rail.", "citation": "Regulations for the New Payments Platform, v21.0, public version, Regulation 4.1(a); Reserve Bank of Australia, About RITS, About RITS", "rests_on": "rule" }, { "label": "Every response timeout is a configurable value the operator prescribes, and no figure is public", "value": "The rulebook obliges a receiving institution to answer a clearing request inside the configurable timeout values the scheme operator prescribes, and obliges a paying institution's gateway to submit a settlement request inside the configurable timeout values the procedures prescribe. Neither the rulebook nor any public document read gives a number for either. Any figure offered for an NPP response time has been invented.", "citation": "Regulations for the New Payments Platform, v21.0, public version, Regulations 6.3(a) and 7.2(a)", "rests_on": "rule" }, { "label": "Service availability is a compliance requirement and the target is not published", "value": "Availability on this rail is governed as a mandatory compliance requirement rather than as a rule with a number in it. The rulebook gives the scheme operator the power to designate such requirements and to act on non compliance with them, and no public document read states the availability percentage a participant has to meet. When a receiving institution puts a cleared payment on an account, and how quickly, is above a minimum in the procedures its own service standard rather than a scheme obligation.", "citation": "Regulations for the New Payments Platform, v21.0, public version, Regulations 3.8 as referred to in 17.1(h)(v) and 17.1(j)(v)(B), and Regulation 6.3(b)", "rests_on": "rule" } ], "exceptions": [ "Scheduled maintenance of the mandate service, and a temporary suspension of it to protect security or integrity, are both provided for and neither is dated or timed in any public document.", "An outage of the settlement service puts contingency arrangements from the procedures into effect." ], "applies_to": "payments on the New Payments Platform in Australia, in Australian dollars between Australian domiciled accounts: ordinary credit transfers, overlay service payments including Osko, the domestic leg of international transfers, and PayTo payments", "caveat": "Any figure offered for an NPP response time, a return window or an availability percentage has been invented. Not one of them is public.", "related": [ "rtp:hours", "fednow:hours", "uk-fps:hours", "au-npp:settlement" ], "basis": { "sources": "NPP Regulations v21.0, Regulations 4.1(a), 6.3(a) and (b), 7.2(a) and 17.1(j), and the Reserve Bank's About RITS page, both read 2026-09-21.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the rulebook dates individual amendments rather than provisions, and the current edition cannot be read", "effective_to": null, "effective_note": "Drafted 2026-09-21 in Orca Core form. Where this fact rests on the rulebook it rests on NPP Regulations v21.0 of 24 September 2024, because the current edition is published only as scanned page images. What moved between the two editions is not held [Unverified]. Where it rests on the ePayments Code or on the Scams Prevention Framework instruments it rests on current text that an agent can read.", "source_edition": "NPP Regulations v21.0 of 24 September 2024, the public redacted version and the newest readable edition of the rulebook; the NPP Payment Initiation Messages technical guidance v4.0 of 20 November 2025; ASIC's ePayments Code as published 2 June 2022; the Scams Prevention Framework Act 2025 as made and the Competition and Consumer (Scams Prevention Framework, Regulated Sectors) Designation 2026; the Reserve Bank of Australia's About RITS page; and Australian Payments Plus's PayTo FAQs. All read 2026-09-21. The current edition of the rulebook, NPP Product Rules v.31 of September 2026, was downloaded the same day and could not be read: 102 pages, no font resource on any page and no extractable character.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.auspayplus.com.au/wp-content/uploads/2024/10/NPP-Regulations-v21.0_Public_version.pdf", "source_class": "authoritative_primary", "source_title": "Regulations for the New Payments Platform, v21.0, public version", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Confirms the infrastructure was established for near real time clearing and settlement on a 24x7 basis (4.1(a)) and that response timeouts (6.3(a), 7.2(a)) and availability targets (3.8, referred to at 17.1(h)(v) and 6.3(b)) are configurable or designated values the Regulations do not themselves publish a figure for." }, { "source_url": "https://www.rba.gov.au/payments-and-infrastructure/rits/about.html", "source_class": "authoritative_primary", "source_title": "Reserve Bank of Australia, About RITS", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Confirms the FSS was designed to settle individual transactions 24 hours a day and 7 days a week." } ] }, "rail_name": "New Payments Platform (Australia)", "governing_authority": "NPP Australia Limited", "snapshot": "2026-09-20", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "au-npp:liability", "id": "liability", "rail": "au-npp", "kind": "rail-fact", "facet": "liability", "name": "Who bears the loss on an NPP payment?", "statement": "Three layers that must not be blended, and one absence that matters more than any of them. Between institutions the rulebook works by indemnity: the side that sent a mandate payment request indemnifies the operator and every other participant against substantiated mandate claims, a sponsor takes full risk on the users it puts into the mandate service, the institution that registered a PayID badly carries a misdirected payment, and a paying institution indemnifies a receiving institution that returns a payment properly while owing its own customer the value of a settled duplicate whatever happens. Between an institution and its customer the ePayments Code allocates loss on transactions the customer did not authorise: the customer is not liable at all where a payment could be made with an identifier and nothing else, is liable only where the institution proves on the balance of probability that they contributed and then only inside their own limits, and otherwise carries the least of 150 dollars, the available balance and the actual loss at reporting. And then the absence. A payment the customer made themselves because somebody deceived them is not an unauthorised transaction at all, and Australia has no mandatory scam reimbursement rule: no cap, no split between sending and receiving institution, no duty to pay without fault. What a victim has instead is a right to sue, within 6 years, proving that a contravention of the Scams Prevention Framework caused the loss, against liability apportioned among concurrent wrongdoers who may include a telecommunications provider or a digital platform.", "details": [ { "label": "The side that sent the mandate payment request indemnifies everybody else against substantiated claims", "value": "Liability for a PayTo payment the mandate did not cover runs back to the side that initiated it. A participant that approves users of the service and sends requests for them, and a connected institution that sends them as or for a payment initiator, each indemnifies the scheme operator and every other participant against the claims, liabilities, expenses and direct losses of a mandate claim. What the paying institution recovers from the receiving institution reduces that liability by the same amount.", "citation": "Regulations for the New Payments Platform, v21.0, public version, Regulation 17.10(a) and (b)", "rests_on": "rule" }, { "label": "A sponsor takes full risk on the users it puts into the mandate service", "value": "A participant that sponsors users into the Mandated Payments Service is responsible for and takes full risk on approving and sponsoring them. It must assess their creditworthiness and their ability to meet what they could owe, satisfy itself of their capability and compliance, do its own due diligence, oversee their use of the service, act where they stop qualifying or break the law or become insolvent, and give the indemnity for mandate claims arising out of what they do.", "citation": "Regulations for the New Payments Platform, v21.0, public version, Regulation 17.5(d)(i) to (ix)", "rests_on": "rule" }, { "label": "A badly registered PayID is the registering institution's indemnity, not the payer's", "value": "Where a payment goes to the wrong account because the institution that registered or maintained the alias did not register the alias information accurately, the indemnity for the misdirected payment is that institution's. This is the reason the rulebook keeps misdirected payments apart from mistaken payments as a defined term: the two describe whose mistake it was.", "citation": "Regulations for the New Payments Platform, v21.0, public version, the note to Regulation 6.5(b), which points at Regulation 8.4(i), and Regulation 8.3(c)", "rests_on": "rule" }, { "label": "The paying institution owes its own customer whatever the receiving institution decides", "value": "The scheme's discretion to refuse a return and the customer's right to be made whole are two separate things, and the rulebook keeps them separate. A paying institution bears full liability to compensate its payer for the value of any settled duplicate payment, or any payment sent as a result of its own error, whether or not the receiving institution ever sends the money back.", "citation": "Regulations for the New Payments Platform, v21.0, public version, Regulation 6.4(c)(ii)", "rests_on": "rule" }, { "label": "A claim about a migrated mandate is deemed substantiated unless the sponsor produces the evidence", "value": "This is where the missing consent shows up. Where a mandate claim relates to a migrated mandate, the claim is deemed to be substantiated unless the sponsoring participant produces written evidence both of the payer's authorisation of the direct debit request the mandate was based on and that the payment in question was authorised by the mandate's terms. The burden runs against the side that created the record without asking.", "citation": "Regulations for the New Payments Platform, v21.0, public version, Regulations 17.10(c)(ii) and 17.10(e)", "rests_on": "rule" }, { "label": "A claim about an ordinary mandate is tested against the record, or against evidence the initiator must produce", "value": "For an ordinary PayTo mandate the rulebook splits the claim in two. Where the payer's institution says the payment was not permitted by the mandate in amount, frequency or beneficiary, the claim is deemed substantiated by reference to the record in the operator's database itself, which is what makes that record the evidence. Where it says the payer did not authorise that particular payment at the time the request was sent, the claim is deemed substantiated unless the initiating side produces evidence that they did, and if the two of them disagree about the reliability of that evidence they may use the rulebook's own dispute resolution process.", "citation": "Regulations for the New Payments Platform, v21.0, public version, Regulation 17.10(f)(i) and (ii), and Regulation 17.10(c)(i)", "rests_on": "rule" }, { "label": "When a substantiated mandate claim has to be paid is in the procedures and is not public", "value": "A payer's institution seeking to recover under the indemnity must give the initiating participant written evidence of the amounts claimed and comply with the recovery procedures. The time in which the initiating participant must then discharge the obligation is prescribed in a volume of the procedures that is available to members and direct affiliates only, and no public figure for it exists.", "citation": "Regulations for the New Payments Platform, v21.0, public version, Regulation 17.10(g) and (h)", "rests_on": "rule" }, { "label": "A customer is not liable where a payment could be made with an identifier and nothing else", "value": "The Code's clearest allocation. A holder is not liable for loss from an unauthorised transaction that can be made using an identifier without a passcode or a device. Where a transaction needs a device, or a device and an identifier, but no passcode, the holder is liable only if the user unreasonably delayed reporting the device lost or stolen. Nor is the holder liable where the cause was fraud or negligence by the institution's own people or a third party in the network, a forged, faulty, expired or cancelled device, identifier or passcode, a transaction before the user got the device or passcode, a double debit, or anything after the institution was told of a loss or breach, or where it is clear the user did not contribute at all.", "citation": "ePayments Code, clauses 10.1, 10.2 and 10.3", "rests_on": "guidance" }, { "label": "A customer carries the loss only where the institution proves they contributed, and never above their own limits", "value": "Where the institution can prove on the balance of probability that the user contributed to the loss by fraud or by breaching the passcode security requirements, or by unreasonably delaying a report of a device or passcode being lost, stolen or misused, the holder is liable for the actual losses in the relevant period. Even then the holder is not liable for any part of the loss above an applicable daily or periodic transaction limit, above the balance and pre-arranged credit available, or on a facility the two of them had not agreed could be reached that way. Using the correct device or passcode is significant but is not by itself proof that the user contributed.", "citation": "ePayments Code, clauses 11.2, 11.3, 11.5, 11.6 and 11.8", "rests_on": "guidance" }, { "label": "Where nothing else applies and a passcode was needed, the customer's share is capped at 150 dollars", "value": "The residual rule. Where a passcode was required to perform the unauthorised transaction and none of the other liability provisions apply, the holder is liable for the least of three things: 150 dollars or any lower figure the institution sets, the balance of the facilities that could be reached with the device or passcode including pre-arranged credit, and the actual loss at the time the compromise was reported, leaving out any part of a day's losses above a relevant limit. Where the institution has not applied a reasonable daily or periodic limit, it or an external dispute resolution body may reduce the holder's liability further.", "citation": "ePayments Code, clauses 11.7 and 11.9", "rests_on": "guidance" }, { "label": "A payment the customer made because they were deceived is not an unauthorised transaction", "value": "The single most important sentence for anybody reading Australian scam liability. An unauthorised transaction does not include any transaction performed by a user themselves, or by anyone who performs a transaction with a user's knowledge and consent. A payment a person made because somebody tricked them into making it therefore falls outside the Code's liability chapter entirely, and so does the mistaken payment process, which is about the payer's own error in the account details rather than about deception.", "citation": "ePayments Code, clauses 9.2, 9.3 and the note to the definition of mistaken internet payment in clause 25.2", "rests_on": "guidance" }, { "label": "Australia has no mandatory scam reimbursement rule", "value": "There is no rule in Australia that obliges a bank to pay back a customer who was deceived into authorising a payment. No scheme rule does it, the ePayments Code excludes such a payment from its liability chapter by definition, and the Scams Prevention Framework creates duties, penalties and dispute routes rather than a duty to reimburse. There is no cap, no percentage split between the sending and receiving institution, and no no fault obligation to pay. A reader who arrives from a rail that has a reimbursement requirement and assumes the same shape here will produce a false answer.", "citation": "ePayments Code, clauses 9.2 and 9.3; Scams Prevention Framework Act 2025 (No. 15, 2025), Part IVF Division 2, the six principles, and Subdivision G, section 58FZC", "rests_on": "law" }, { "label": "A scam victim recovers by proving a contravention caused the loss, within 6 years, apportioned", "value": "What Australia gives a victim instead of reimbursement is a cause of action. A person who suffers loss by conduct done in contravention of a civil penalty provision of a framework principle or of a sector code may recover that loss by action against the person who did it, and a regulator may bring the claim for them with their written consent. The claim may be made at any time within 6 years after the cause of action accrued, and it is subject to the proportionate liability rules, so the loss is divided among the concurrent wrongdoers whose contraventions caused it. Where a court would order both a penalty and compensation and the defendant cannot pay both, it must prefer the compensation.", "citation": "Scams Prevention Framework Act 2025 (No. 15, 2025), sections 58FZC(1) to (4), 58FZD, 58FZF and 58FD", "rests_on": "law" } ], "exceptions": [ "The ePayments Code binds subscribers only, so its liability rules reach an institution only because that institution chose them.", "The Scams Prevention Framework rules may prescribe guidelines for apportioning liability in internal dispute resolution, and the Act says those guidelines need not be consistent with its own proportionate liability provisions. Whether any such instrument has been registered was not established, and if one exists this fact changes." ], "applies_to": "payments on the New Payments Platform in Australia, in Australian dollars between Australian domiciled accounts: ordinary credit transfers, overlay service payments including Osko, the domestic leg of international transfers, and PayTo payments", "caveat": "Australia deliberately did not build a reimbursement duty, and a reader arriving from a rail that has one will get this wrong in the most expensive possible direction. Nothing in this fact obliges any Australian institution to pay back a customer who authorised a payment because they were deceived.", "related": [ "uk-fps:liability", "us-ach:liability", "in-upi:liability", "rtp:liability", "au-npp:consumer-law", "au-npp:recall" ], "basis": { "sources": "NPP Regulations v21.0, Regulations 6.4(c), 6.5(a) and (c), 17.5(d), 17.10(a) to (h); ASIC's ePayments Code of 2 June 2022, clauses 9.2, 9.3, 10, 11; the Scams Prevention Framework Act 2025 as made, sections 58FD and 58FZC to 58FZF. All read 2026-09-21. That no reimbursement duty exists is a statement about what two named instruments do not contain rather than about Australian law as a whole [Inference].", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the rulebook dates individual amendments rather than provisions, and the current edition cannot be read", "effective_to": null, "effective_note": "Drafted 2026-09-21 in Orca Core form. Where this fact rests on the rulebook it rests on NPP Regulations v21.0 of 24 September 2024, because the current edition is published only as scanned page images. What moved between the two editions is not held [Unverified]. Where it rests on the ePayments Code or on the Scams Prevention Framework instruments it rests on current text that an agent can read.", "source_edition": "NPP Regulations v21.0 of 24 September 2024, the public redacted version and the newest readable edition of the rulebook; the NPP Payment Initiation Messages technical guidance v4.0 of 20 November 2025; ASIC's ePayments Code as published 2 June 2022; the Scams Prevention Framework Act 2025 as made and the Competition and Consumer (Scams Prevention Framework, Regulated Sectors) Designation 2026; the Reserve Bank of Australia's About RITS page; and Australian Payments Plus's PayTo FAQs. All read 2026-09-21. The current edition of the rulebook, NPP Product Rules v.31 of September 2026, was downloaded the same day and could not be read: 102 pages, no font resource on any page and no extractable character.", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "rail_name": "New Payments Platform (Australia)", "governing_authority": "NPP Australia Limited", "snapshot": "2026-09-20", "source_class": null, "effective_status": "draft", "effective_status_reason": null, "boundaries": [] }, { "uid": "au-npp:limits", "id": "limits", "rail": "au-npp", "kind": "rail-fact", "facet": "limits", "name": "Is there a limit on an NPP payment?", "statement": "Not from the scheme. The rulebook says what every payment must be, which is in Australian dollars, between Australian domiciled accounts, correctly formatted and carrying a transaction identifier, and it sets no maximum at all. The one value rule is at the bottom: a zero value payment may not be sent and the receiving institution is obliged to reject one, and a zero value return may not be sent either. Every limit a person actually meets belongs to their own institution, and the rulebook's own sample customer terms for the overlay service most people use leave transaction limits as a blank for each institution to fill in. The scheme operator can direct participants to impose value limits and volume controls, but that power is about keeping the infrastructure orderly rather than about what a payment may be worth.", "details": [ { "label": "The scheme sets no maximum payment value at all", "value": "The rulebook states what every payment must be, which is denominated in Australian dollars, between Australian domiciled accounts, correctly formatted and carrying a transaction identifier, and it states no ceiling. No public document read sets a maximum value for a payment on this rail. This is the strongest case in the corpus of an instant rail with no scheme value cap.", "citation": "Regulations for the New Payments Platform, v21.0, public version, Regulation 6.1(b)", "rests_on": "rule" }, { "label": "A zero value payment may not be sent and must be rejected", "value": "The one value rule the scheme does impose is at the bottom. A paying institution must not submit an ordinary credit transfer clearing request with a zero value amount, and a receiving institution is obliged to reject one if it arrives. The same rule forbids a zero value return.", "citation": "Regulations for the New Payments Platform, v21.0, public version, Regulation 6.1(c)(i) and (ii)", "rests_on": "rule" }, { "label": "Any limit a customer meets is their own institution's, not the scheme's", "value": "Because the scheme sets no ceiling, every limit a person runs into on this rail belongs to their institution. The rulebook's own sample customer terms for the overlay service most people use leave transaction limits as a blank for each institution to fill in, and note that an institution may set different limits for different payment types.", "citation": "Regulations for the New Payments Platform, v21.0, public version, Appendix C, clause C.3 and its note to participants", "rests_on": "rule" }, { "label": "The operator may direct value limits and volume controls to keep the platform orderly", "value": "There is one power to impose limits in the rulebook and it is about the infrastructure rather than about payments. The scheme operator may direct a connecting participant or a connected institution to impose value limits and volume controls on payments, non value messages and addressing activity, to ensure the orderly operation of the platform, and the institution must comply promptly and keep the controls until told otherwise. This is capacity management, not a payment rule.", "citation": "Regulations for the New Payments Platform, v21.0, public version, Regulation 14.4(a) and (b)", "rests_on": "rule" } ], "exceptions": [ "A payment can still fail for want of funds, which is a balance rather than a limit.", "A PayTo payment has three amount edges of its own: the agreement's minimum, the amount the agreement agreed or expected, and a limit the payer agreed with their own bank. The first two are in the agreement and the third is not." ], "applies_to": "payments on the New Payments Platform in Australia, in Australian dollars between Australian domiciled accounts: ordinary credit transfers, overlay service payments including Osko, the domestic leg of international transfers, and PayTo payments", "caveat": "The absence of a scheme cap is not the absence of a cap. What a person can send is whatever their institution allows, and the institution does not have to publish it either.", "related": [ "rtp:limits", "fednow:limits", "uk-fps:limits", "nct-inst:limits" ], "basis": { "sources": "NPP Regulations v21.0, Regulations 6.1(b) and (c), 14.4 and Appendix C clause C.3, read 2026-09-21.", "confidence": "medium" }, "currency": { "effective_since": "2017-07-01", "effective_to": null, "effective_note": "Effective since 2017-07-01: the commencement date the Regulations state on their own cover page. No drafting note in the edition read marks a later amendment to the value provisions. Drafted 2026-09-21 in Orca Core form. Where this fact rests on the rulebook it rests on NPP Regulations v21.0 of 24 September 2024, because the current edition is published only as scanned page images. What moved between the two editions is not held [Unverified]. Where it rests on the ePayments Code or on the Scams Prevention Framework instruments it rests on current text that an agent can read.", "source_edition": "NPP Regulations v21.0 of 24 September 2024, the public redacted version and the newest readable edition of the rulebook; the NPP Payment Initiation Messages technical guidance v4.0 of 20 November 2025; ASIC's ePayments Code as published 2 June 2022; the Scams Prevention Framework Act 2025 as made and the Competition and Consumer (Scams Prevention Framework, Regulated Sectors) Designation 2026; the Reserve Bank of Australia's About RITS page; and Australian Payments Plus's PayTo FAQs. All read 2026-09-21. The current edition of the rulebook, NPP Product Rules v.31 of September 2026, was downloaded the same day and could not be read: 102 pages, no font resource on any page and no extractable character.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.auspayplus.com.au/wp-content/uploads/2024/10/NPP-Regulations-v21.0_Public_version.pdf", "source_class": "authoritative_primary", "source_title": "Regulations for the New Payments Platform, v21.0, public version", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Confirms the Regulations state what every payment must be (6.1(b)) without setting a maximum, forbid a zero value payment or return (6.1(c)), leave transaction limits blank in the Osko sample customer terms for each institution to set (Appendix C.3), and give NPPA a capacity-only power to direct value limits and volume controls (14.4)." } ] }, "rail_name": "New Payments Platform (Australia)", "governing_authority": "NPP Australia Limited", "snapshot": "2026-09-20", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "au-npp:messages", "id": "messages", "rail": "au-npp", "kind": "rail-fact", "facet": "messages", "name": "What messages does the NPP use, and what codes do they carry?", "statement": "ISO 20022 natively, since launch, which makes this rail the opposite of one still running a card standard. A clearing request is a pacs.008, the clearing notification that answers it and the settlement notification are both pacs.002, a settlement request is a pacs.009, a return is a pacs.004 and a request for one is a camt.056. On the leg between a corporate customer and its own institution a payment instruction is a pain.001, a creditor payment initiation request under PayTo is a pain.013, and the status report back is a pain.002. Codes are where this rail divides in two. The interbank leg has an obligation and no published values: a rejected clearing request and a rejected mandate payment initiation request each must carry a valid and applicable reason code, and the rulebook lists none and points at the procedures. The customer to institution leg has 33 published reason code values and 4 status values, published by the authority itself, on a leg the authority says is proprietary and at each institution's discretion, with a note under each list saying an institution may offer alternative values.", "details": [ { "label": "The platform has used ISO 20022 natively since launch", "value": "Every message on this rail is an ISO 20022 message and always has been. A clearing request that starts a payment is a pacs.008, the clearing notification that answers it and the settlement notification the settlement service sends are both pacs.002, the settlement request is a pacs.009, a return is a pacs.004 and a request for one is a camt.056. On the customer to institution leg a payment instruction is a pain.001, a creditor payment initiation request under PayTo is a pain.013, and the status report back to a corporate customer is a pain.002.", "citation": "Regulations for the New Payments Platform, v21.0, public version, the definitions of Clearing Request, Clearing Notification, Settlement Request, Settlement Notification, NPP Payment Return and Request for Payment Return, and Regulation 17.1(c); NPP Payment Initiation Messages, technical guidance for corporates, government and third parties, v4.0, Background", "rests_on": "rule" }, { "label": "A receiving institution that rejects a clearing request must put a valid and applicable reason code in the message", "value": "The obligation exists and the values do not. A payee participant must answer every clearing request inside the configured timeout, either accepting it or rejecting it, and where it rejects it must include a valid and applicable reason code in the message. The rulebook does not list a single value and points at the procedures instead.", "citation": "Regulations for the New Payments Platform, v21.0, public version, Regulation 6.3(a)(i) and (ii)", "rests_on": "rule" }, { "label": "A rejected mandate payment initiation request must also carry a valid and applicable reason code", "value": "The same shape on the PayTo leg. A payer participant must respond to each mandate payment initiation request inside the timeframes the procedures prescribe with a status report indicating receipt and either acceptance or rejection, and where it rejects it must provide a valid and applicable reason code. Where it accepts and funds are available it then sends a clearing request for the amount claimed. Again no value is listed.", "citation": "Regulations for the New Payments Platform, v21.0, public version, Regulation 17.8(b)(i) and (ii)", "rests_on": "rule" }, { "label": "The interbank reason code values are in the procedures and are not published", "value": "Two regulations oblige a valid and applicable reason code and neither lists one, and the same is true of the values a return may carry. Every one of those lists sits in the NPP Procedures, which the parent scheme rules make available to members and direct affiliates only. No public document from the authority carries the interbank code set, so what Orca holds for this rail is the customer to institution leg and nothing else.", "citation": "Regulations for the New Payments Platform, v21.0, public version, Regulations 6.3(a)(ii), 6.6 and 17.8(b)(i)", "rests_on": "rule" }, { "label": "Whether an institution accepts a customer payment instruction at all is its own commercial matter", "value": "The leg the published code list describes is not a leg the scheme mandates. The authority's own guidance says that an institution's acceptance of customer payment instruction messages, and its provision of status report messages to corporate and government customers, are proprietary and at that institution's discretion, that the guidance rests on public message schema guidance and is subject to whatever additional proprietary requirements an institution sets, and that a reader must confirm requirements, validations, formats and supported features with their own institution.", "citation": "NPP Payment Initiation Messages, technical guidance for corporates, government and third parties, v4.0, Background, and the assumptions and conditions under Technical Guidance", "rests_on": "rule" }, { "label": "An institution may offer alternative status and reason codes, and the authority says so under each list", "value": "The single most important qualification on every code Orca holds for this rail. Under its status code appendix and again under its reason code appendix, the authority notes that an NPP financial institution may offer alternative values and that further guidance on how the codes are used comes from that institution. The published list is therefore the authority's own indicative list for a leg it does not mandate, which is a different thing from a scheme code set, and no record drawn from it may be read as saying an institution must use these values.", "citation": "NPP Payment Initiation Messages, technical guidance for corporates, government and third parties, v4.0, the notes under Appendix E and Appendix F", "rests_on": "rule" }, { "label": "The authority publishes four status code values for the payment initiation leg", "value": "The status appendix of the authority's guidance carries four values. ACTC says the initial file validation passed and transaction level validation has not started. ACSC says everything in the file has been processed at group level, or that the individual payment has settled and completed. RJCT says the initial file validation failed and transaction level validation was not done, or that the individual payment was rejected. PART says the file is being processed in portions because of its volume or because of processing difficulty. These are statuses rather than reason codes, and the same note about alternatives applies to them.", "citation": "NPP Payment Initiation Messages, technical guidance for corporates, government and third parties, v4.0, Appendix E and its note", "rests_on": "rule" }, { "label": "No public document says how long an institution has to answer a customer's payment instruction", "value": "An institution that accepts customer payment instructions answers them with status reports that acknowledge, reject or confirm settlement, and the authority's guidance says those reports are essential for tracking and reconciling the instructions. It gives no deadline for one. Nothing in the rulebook gives one either, because the scheme does not require the leg at all: the guidance says accepting these instructions and providing these reports is proprietary and at each institution's discretion. So the deadline for a rejection carrying any of the 33 published reason codes is whatever an institution has agreed with its own customer, and no public figure exists.", "citation": "NPP Payment Initiation Messages, technical guidance for corporates, government and third parties, v4.0, Background, and the assumptions and conditions under Technical Guidance", "rests_on": "practice" }, { "label": "A replay and a retry are different messages, and a duplicate is a third thing again", "value": "The rulebook defines all three and they are easy to confuse. A replay is the same message sent again carrying the same transaction identifier. A retry is a resend that marks itself as a retry in the thirty fifth character of the transaction or return identifier. A duplicate payment is a payment carrying the same transaction identifier as another one and that is not a replay. Both institutions must have procedures to keep duplicates out and to spot duplicates and replays inside a detection window the procedures define.", "citation": "Regulations for the New Payments Platform, v21.0, public version, the definitions of Replay, Retry and Duplicate Payment, and Regulations 6.4(a) and (b)", "rests_on": "rule" } ], "exceptions": [ "One participant publishes its own list of about 50 NPP return and reversal codes, which agrees with the authority's list on fifteen shared values and disagrees on five. Those five disagreements are in the conflict register and are not resolved.", "Mandate status reason codes and Confirmation of Payee reason codes have no published values at all." ], "applies_to": "payments on the New Payments Platform in Australia, in Australian dollars between Australian domiciled accounts: ordinary credit transfers, overlay service payments including Osko, the domestic leg of international transfers, and PayTo payments", "caveat": "The 33 published values are ISO 20022 externalised codes, and several of them carry Australian or PayTo specific meanings the ISO definition does not give. Never carry a meaning onto one of them from the ISO list or from another rail's list of the same string.", "related": [ "rtp:messages", "fednow:messages", "sepa-sct-inst:messages", "uk-fps:messages" ], "basis": { "sources": "NPP Regulations v21.0, the definitions of each message and Regulations 6.3(a)(ii), 6.6 and 17.8(b)(i); the NPP Payment Initiation Messages technical guidance v4.0, Background and Appendices E and F. Both read 2026-09-21.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the rulebook dates individual amendments rather than provisions, and the current edition cannot be read", "effective_to": null, "effective_note": "Drafted 2026-09-21 in Orca Core form. Where this fact rests on the rulebook it rests on NPP Regulations v21.0 of 24 September 2024, because the current edition is published only as scanned page images. What moved between the two editions is not held [Unverified]. Where it rests on the ePayments Code or on the Scams Prevention Framework instruments it rests on current text that an agent can read.", "source_edition": "NPP Regulations v21.0 of 24 September 2024, the public redacted version and the newest readable edition of the rulebook; the NPP Payment Initiation Messages technical guidance v4.0 of 20 November 2025; ASIC's ePayments Code as published 2 June 2022; the Scams Prevention Framework Act 2025 as made and the Competition and Consumer (Scams Prevention Framework, Regulated Sectors) Designation 2026; the Reserve Bank of Australia's About RITS page; and Australian Payments Plus's PayTo FAQs. All read 2026-09-21. The current edition of the rulebook, NPP Product Rules v.31 of September 2026, was downloaded the same day and could not be read: 102 pages, no font resource on any page and no extractable character.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.auspayplus.com.au/wp-content/uploads/2024/10/NPP-Regulations-v21.0_Public_version.pdf", "source_class": "authoritative_primary", "source_title": "Regulations for the New Payments Platform, v21.0, public version", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Confirms the ISO 20022 message definitions (Clearing Request as pacs.008, Clearing and Settlement Notification as pacs.002, Settlement Request as pacs.009, NPP Payment Return as pacs.004, Request for Payment Return as camt.056, and Mandate Payment Initiation Request types under 17.1(c)) and that a rejected Clearing Request or Mandate Payment Initiation Request must carry a reason code the Regulations do not themselves list (6.3(a)(ii), 17.8(b)(i))." }, { "source_url": "https://www.auspayplus.com.au/wp-content/uploads/2026/03/NPP-payment-initiation-V4.0.pdf", "source_class": "authoritative_primary", "source_title": "NPP Payment Initiation Messages, technical guidance for corporates, government and third parties, v4.0", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Confirms the 33 published reason code values and 4 status values on the customer to institution leg, published by the authority with a note under each appendix that an institution may offer alternative values, on a leg the Background section states is proprietary and at each institution's discretion." } ] }, "rail_name": "New Payments Platform (Australia)", "governing_authority": "NPP Australia Limited", "snapshot": "2026-09-20", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "au-npp:participants", "id": "participants", "rail": "au-npp", "kind": "rail-fact", "facet": "participants", "name": "Who takes part in the NPP?", "statement": "Three participant classes cutting across two capabilities, and three more kinds of institution that are not participants at all. Connecting directly to the infrastructure and being authorised by the central bank to settle are separate permissions: a Full Participant holds both, a Clearing Participant connects but settles through another participant, and a Settlement Participant is authorised to settle without connecting at all, and expressly need not be a bank. Alongside them sit connected institutions, which connect but may not clear or settle and whose only traffic is non value messages and mandate work, identified institutions, which do not connect and reach the platform through a sponsor, and overlay service providers. A participant that connects must be the central bank or an authorised deposit-taking institution, hold a registered eight character bank identifier code, contract with at least two vendor network partners and complete network onboarding. Joining makes the rules a contract under seal between that institution, the operator, and every other participant, connected institution and overlay service provider.", "details": [ { "label": "Three participant classes cut across two capabilities: connecting, and being authorised to settle", "value": "Access here is a matrix rather than a ladder. Connecting directly to the infrastructure and being authorised by the central bank to settle are two separate permissions. A Full Participant holds both. A Clearing Participant connects but is not authorised to settle and settles through another participant instead. A Settlement Participant is authorised to settle but does not connect at all. Every participant must also be able to comply with the rules, pay the fees, accept the rules as a contract, act in good faith, show its operations are sound and secure, and be solvent.", "citation": "Regulations for the New Payments Platform, v21.0, public version, Regulations 4.2, 4.3, 4.4 and 4.5, and the definitions of each class", "rests_on": "rule" }, { "label": "A settlement participant need not be a bank", "value": "A participant must be the central bank or an authorised deposit-taking institution, except that one that wishes to be a Settlement Participant may instead be a body corporate carrying on business at or through a permanent establishment in Australia. The rulebook then says for the avoidance of doubt that a Settlement Participant is not required to be an authorised deposit-taking institution. Australian access is wider than banks only in exactly this one place.", "citation": "Regulations for the New Payments Platform, v21.0, public version, Regulations 4.2(a) and 4.5", "rests_on": "rule" }, { "label": "A connected institution connects directly and may not clear or settle", "value": "A connected institution has a direct connection and no right under the rules to submit clearing or settlement messages. What it may do is send and receive non value messages, and take part in the mandate service as a payment initiator or for one: creating mandate records for the payer to authorise and, once authorisation is recorded, sending payment initiation requests to the payer's institution. It must meet the same connection requirements a connecting participant meets.", "citation": "Regulations for the New Payments Platform, v21.0, public version, Regulations 4.1(b)(ii), 4.6(h) and 17.5(e)(i)", "rests_on": "rule" }, { "label": "Most institutions reach the platform through a sponsor and are not participants at all", "value": "An identified institution does not connect and is not bound as a participant. It reaches the platform through a sponsoring participant, which provides its clearing or settlement services, must satisfy itself that the institution it sponsors has compliance frameworks in place, and is answerable for procuring its compliance with the obligations the rules write for participants.", "citation": "Regulations for the New Payments Platform, v21.0, public version, Regulations 6.1(d)(i)(B) and (iv)(B), 17.1(d), and the definition of Sponsor", "rests_on": "rule" }, { "label": "The rules take effect as a contract under seal between the operator and everybody else", "value": "Joining is not a licence, it is a contract. On becoming a participant or a connected institution, the rules and the procedures constitute a contract under seal between that institution and the scheme operator, and between it and every current and future participant, connected institution and overlay service provider. That is why the scheme's obligations reach sideways between institutions and not only up to the operator.", "citation": "Regulations for the New Payments Platform, v21.0, public version, Regulations 4.2(d) and 4.6(d)", "rests_on": "rule" }, { "label": "No public list of participants by class exists", "value": "Nothing public distinguishes the classes on the ground. The central bank's own membership list marks which institutions use the Fast Settlement Service, which covers Full Participants and Settlement Participants together, and there is no public source that identifies a Clearing Participant, a Connected Institution or an Identified Institution as such. A count of institutions reachable on the rail is not a count of participants.", "citation": "Regulations for the New Payments Platform, v21.0, public version, Regulations 4.3(f), 4.4(b), 4.5 and 4.6, which define the classes without naming any member", "rests_on": "rule" } ], "exceptions": [ "The central bank is itself a participant as well as the operator of the settlement service and the holder of the settlement accounts, and the rulebook carves out its position.", "No public source distinguishes a clearing participant, a connected institution or an identified institution, so a list of institutions reachable on the rail is not a list of participants." ], "applies_to": "payments on the New Payments Platform in Australia, in Australian dollars between Australian domiciled accounts: ordinary credit transfers, overlay service payments including Osko, the domestic leg of international transfers, and PayTo payments", "caveat": "Australian access is wider than banks only in exactly one direction, a settlement participant that is not a bank, and narrower in another, a connected institution that can connect and cannot clear.", "related": [ "uk-fps:participants", "rtp:participants", "fednow:participants" ], "basis": { "sources": "NPP Regulations v21.0, Regulations 4.1 to 4.6, 6.1(d), 17.5(e) and the definitions of Full Participant, Clearing Participant, Settlement Participant, Connected Institution and Sponsor, read 2026-09-21.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the rulebook dates individual amendments rather than provisions, and the current edition cannot be read", "effective_to": null, "effective_note": "Drafted 2026-09-21 in Orca Core form. Where this fact rests on the rulebook it rests on NPP Regulations v21.0 of 24 September 2024, because the current edition is published only as scanned page images. What moved between the two editions is not held [Unverified]. Where it rests on the ePayments Code or on the Scams Prevention Framework instruments it rests on current text that an agent can read.", "source_edition": "NPP Regulations v21.0 of 24 September 2024, the public redacted version and the newest readable edition of the rulebook; the NPP Payment Initiation Messages technical guidance v4.0 of 20 November 2025; ASIC's ePayments Code as published 2 June 2022; the Scams Prevention Framework Act 2025 as made and the Competition and Consumer (Scams Prevention Framework, Regulated Sectors) Designation 2026; the Reserve Bank of Australia's About RITS page; and Australian Payments Plus's PayTo FAQs. All read 2026-09-21. The current edition of the rulebook, NPP Product Rules v.31 of September 2026, was downloaded the same day and could not be read: 102 pages, no font resource on any page and no extractable character.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.auspayplus.com.au/wp-content/uploads/2024/10/NPP-Regulations-v21.0_Public_version.pdf", "source_class": "authoritative_primary", "source_title": "Regulations for the New Payments Platform, v21.0, public version", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Confirms the three participant classes and their two separable capabilities, connecting to the infrastructure and RBA authorisation to settle (4.2 to 4.5), that a Settlement Participant need not be an ADI (4.5), the Connected Institution and Identified Institution positions outside participation (4.6, 17.5(e), and the definitions of Identified Institution and Sponsor), the connection requirements of BIC8 holder, two Vendor Network Partner agreements and SWIFT onboarding (4.3), and that joining constitutes a contract under seal (4.2(d))." } ] }, "rail_name": "New Payments Platform (Australia)", "governing_authority": "NPP Australia Limited", "snapshot": "2026-09-20", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "au-npp:recall", "id": "recall", "rail": "au-npp", "kind": "rail-fact", "facet": "recall", "name": "Can an NPP payment be recalled?", "statement": "No. There is no recall and no cancellation message. Once the clearing request is in the paying institution's gateway it cannot be taken back, and what exists instead is a request that the receiving institution send a settled payment back. What the receiving institution then owes depends on which of four defined kinds of wrong payment it is, and the rulebook gives three different answers. For a mistaken payment, meaning the paying institution's own customer sent it to the wrong account by their own error, the paying institution must ask and the receiving institution must acknowledge, must assess with reasonable endeavours, must say whether and when, and must return. For a misdirected payment, meaning an alias was badly registered, it must acknowledge, must assess, and must return if satisfied. For a duplicate, an error payment or the paying institution's own mistake, it must acknowledge and must assess and then may return, at its discretion. Whatever it decides, the paying institution owes its own customer the value of a settled duplicate or of a payment its own error caused.", "details": [ { "label": "There is no recall and no cancellation message on this rail", "value": "Nothing in the scheme lets a sender stop a payment. The paying institution may not cancel or recall a clearing request once it is in its gateway, and the only message that reaches back toward a payment already made is a request that the receiving institution send the money back, which is a request rather than a right.", "citation": "Regulations for the New Payments Platform, v21.0, public version, Regulations 6.2(a) and 6.5, and the definition of Request for Payment Return", "rests_on": "rule" }, { "label": "A request for payment return asks the receiving institution to send a settled payment back", "value": "The one instrument for getting money back is a message the paying institution generates asking the receiving institution to return a settled payment. What the receiving institution then owes depends entirely on which of four defined kinds of wrong payment it is, and the rulebook gives three different answers: must, must if satisfied, and may.", "citation": "Regulations for the New Payments Platform, v21.0, public version, the definition of Request for Payment Return, and Regulation 6.5", "rests_on": "rule" }, { "label": "A mistaken payment must be asked back, assessed with reasonable endeavours and returned if needed", "value": "This is the strongest of the three routes and the only one with a must at both ends. Where a paying institution determines that a settled payment is or is likely to be a mistaken payment, meaning its own customer, being a user as the ePayments Code uses that word, sent it to the wrong account by their own error, it must ask for the payment back. The receiving institution must acknowledge the request, must use reasonable endeavours to assess whether it is one, must say whether and when it will return the money, and must effect any necessary return.", "citation": "Regulations for the New Payments Platform, v21.0, public version, Regulation 6.5(a)(i) and (ii), and the definition of Mistaken Payment", "rests_on": "rule" }, { "label": "A misdirected payment is returned if the receiving institution is satisfied that is what it is", "value": "A misdirected payment is one addressed by alias that went to the wrong account because the institution that registered or maintained that alias did not get it right. The paying institution may ask for it back. The receiving institution must acknowledge and must assess, and must effect a return if it is satisfied the payment was misdirected. The indemnity that follows sits with the registering institution.", "citation": "Regulations for the New Payments Platform, v21.0, public version, Regulation 6.5(b) and its note, and the definition of Misdirected Payment", "rests_on": "rule" }, { "label": "Returning a duplicate or error payment is at the receiving institution's discretion", "value": "Where a settled payment is a duplicate, an error payment, or one the paying institution sent through its own mistake, the paying institution may ask for it back and the receiving institution must acknowledge and must assess. Whether it then returns the money is expressly its own decision, and the rulebook says in terms that the return of such a settled payment is at its discretion.", "citation": "Regulations for the New Payments Platform, v21.0, public version, Regulations 6.4(c)(i) and 6.5(c)(i) and (ii)", "rests_on": "rule" }, { "label": "The paying institution indemnifies a receiving institution that returns a payment properly", "value": "A receiving institution that sends money back is protected, on conditions. Where it has used reasonable endeavours to assess a mistaken payment before returning it, and where it returns a duplicate or error payment in good faith and without negligence, the paying institution indemnifies it against what the return costs it, provided the receiving institution gives written evidence of the amounts claimed and makes commercially reasonable efforts to reduce its loss. A receiving institution that returns a mistaken payment without assessing properly gets no indemnity and carries the loss itself.", "citation": "Regulations for the New Payments Platform, v21.0, public version, Regulations 6.5(a)(iii) and (iv), and 6.5(c)(iii)", "rests_on": "rule" }, { "label": "The paying institution owes its own customer whatever the receiving institution decides", "value": "The scheme's discretion to refuse a return and the customer's right to be made whole are two separate things, and the rulebook keeps them separate. A paying institution bears full liability to compensate its payer for the value of any settled duplicate payment, or any payment sent as a result of its own error, whether or not the receiving institution ever sends the money back.", "citation": "Regulations for the New Payments Platform, v21.0, public version, Regulation 6.4(c)(ii)", "rests_on": "rule" } ], "exceptions": [ "Mistaken, misdirected, error and duplicate payment are four defined terms and only the first obliges a return. Collapsing them into one return rule loses most of the rail.", "Whether the payer is a user as the ePayments Code uses that word is what separates a mistaken payment from an error payment, and the two carry different obligations." ], "applies_to": "payments on the New Payments Platform in Australia, in Australian dollars between Australian domiciled accounts: ordinary credit transfers, overlay service payments including Osko, the domestic leg of international transfers, and PayTo payments", "caveat": "The scheme's discretion to refuse a return and the customer's right to be made whole are two different questions with two different answers, and the rulebook keeps them apart on purpose.", "related": [ "uk-fps:recall", "rtp:recall", "sepa-sct:recall", "au-npp:refund", "au-npp:return" ], "basis": { "sources": "NPP Regulations v21.0, Regulations 6.2(a), 6.4(c), 6.5(a) to (c), and the definitions of Mistaken Payment, Misdirected Payment, Error Payment and Duplicate Payment, read 2026-09-21.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the rulebook dates individual amendments rather than provisions, and the current edition cannot be read", "effective_to": null, "effective_note": "Drafted 2026-09-21 in Orca Core form. Where this fact rests on the rulebook it rests on NPP Regulations v21.0 of 24 September 2024, because the current edition is published only as scanned page images. What moved between the two editions is not held [Unverified]. Where it rests on the ePayments Code or on the Scams Prevention Framework instruments it rests on current text that an agent can read.", "source_edition": "NPP Regulations v21.0 of 24 September 2024, the public redacted version and the newest readable edition of the rulebook; the NPP Payment Initiation Messages technical guidance v4.0 of 20 November 2025; ASIC's ePayments Code as published 2 June 2022; the Scams Prevention Framework Act 2025 as made and the Competition and Consumer (Scams Prevention Framework, Regulated Sectors) Designation 2026; the Reserve Bank of Australia's About RITS page; and Australian Payments Plus's PayTo FAQs. All read 2026-09-21. The current edition of the rulebook, NPP Product Rules v.31 of September 2026, was downloaded the same day and could not be read: 102 pages, no font resource on any page and no extractable character.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.auspayplus.com.au/wp-content/uploads/2024/10/NPP-Regulations-v21.0_Public_version.pdf", "source_class": "authoritative_primary", "source_title": "Regulations for the New Payments Platform, v21.0, public version", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Confirms there is no cancel or recall once a Clearing Request is in the Payer Participant's gateway (6.2(a)), and that a Request for Payment Return carries three different obligations depending on payment type: must for a Mistaken Payment, must if satisfied for a Misdirected Payment, and may at the Payee Participant's discretion for a Duplicate Payment, Error Payment or Payer Participant error (6.5), with the Payer Participant liable to its own customer for a settled Duplicate Payment or its own error regardless of the outcome (6.4(c)(ii))." } ] }, "rail_name": "New Payments Platform (Australia)", "governing_authority": "NPP Australia Limited", "snapshot": "2026-09-20", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "au-npp:refund", "id": "refund", "rail": "au-npp", "kind": "rail-fact", "facet": "refund", "name": "Can a customer get an NPP payment refunded?", "statement": "Not under the scheme, which gives a customer no refund right of any kind: every route in the rulebook runs between institutions. The refund shaped right an Australian consumer actually has comes from the ePayments Code, which is voluntary and binds subscribers, and it is about the payer's own error in the account details rather than about deception. Its clocks run on when the customer reported it. The sending institution must investigate and, if satisfied, ask for the money back within 5 business days of the report; the receiving institution must acknowledge and say whether the money is there within 5 business days of the request. Reported inside 10 business days, the money simply comes back, within 5 business days if practicable and at most 10, and the recipient gets no say. Reported between 10 business days and 7 months, the receiving institution investigates within 10 business days, then freezes the money for 10 further business days while the recipient is told they can establish entitlement, and returns it within 2 business days after that if they do not. Reported after 7 months, it comes back only if the recipient consents. Where the money is not all there the receiving institution weighs both customers and decides how much to pursue. The customer is told the outcome in writing within 30 business days.", "details": [ { "label": "The scheme gives a customer no refund right of their own", "value": "Nothing in the rulebook gives a person a right to have a payment sent back. Every route it contains runs between institutions: one asks and the other must, may, or must if satisfied. The refund shaped right an Australian consumer actually has comes from the ePayments Code and is owed by institutions that subscribe to it.", "citation": "Regulations for the New Payments Platform, v21.0, public version, Regulations 6.5 and 6.6, and their notes", "rests_on": "rule" }, { "label": "A subscriber must warn the payer on screen to check the details, and that duty does not cover PayID", "value": "A subscriber must clearly warn users to check that the branch and account number are right, that funds sent to the wrong account may not be recoverable, and that if it does not match names to numbers then nothing will be checked. Where practicable the warning must appear on screen, while the user is making a pay anyone payment using a branch and account number, and before the payment is finally confirmed, at a point where the user can still stop or fix it. The Code's own note says the duty does not apply to a payment made using a PayID.", "citation": "ePayments Code, clauses 27.1, 27.2 and the note to clause 27.2", "rests_on": "guidance" }, { "label": "The sending institution must investigate, and if satisfied must ask for the money back within 5 business days", "value": "Where a customer reports that they paid the wrong account by their own error, their institution must investigate whether that is what happened. If it is satisfied that it is, it must ask the other institution for the funds back as soon as reasonably possible and no later than 5 business days from the report. If it is not satisfied, it need do nothing further.", "citation": "ePayments Code, clauses 29.1, 29.2(a) and 29.3", "rests_on": "guidance" }, { "label": "The receiving institution must acknowledge the request and say whether the money is there, within 5 business days", "value": "Within 5 business days of the request arriving, the receiving institution must acknowledge it and must tell the sending institution whether the recipient's account holds enough to cover the payment. Everything that happens after that turns on that answer and on how long ago the payment was made.", "citation": "ePayments Code, clause 29.2(b)", "rests_on": "guidance" }, { "label": "Reported inside 10 business days, and the money simply comes back", "value": "This is the fastest tier and the recipient gets no say in it. Where the customer reported the payment within 10 business days of making it, both institutions are satisfied it was a mistaken payment and the money is in the recipient's account, the receiving institution must return it to the sending institution within 5 business days of the request if practicable, or such longer period as is reasonably necessary up to a maximum of 10 business days. The sending institution must then return it to its own customer as soon as practicable.", "citation": "ePayments Code, clauses 30.1, 30.2 and 30.4", "rests_on": "guidance" }, { "label": "Reported between 10 business days and 7 months, and the recipient gets a chance to show entitlement first", "value": "Where the report comes between 10 business days and 7 months after the payment, the receiving institution must finish investigating within 10 business days of the request. If it is satisfied a mistaken payment happened it must stop the recipient withdrawing the money for a further 10 business days and tell the recipient it will take the money back unless they establish in that period that they are entitled to it. If they do not, the receiving institution must return the funds within 2 business days after that period ends.", "citation": "ePayments Code, clauses 31.1 to 31.6", "rests_on": "guidance" }, { "label": "Reported after 7 months, and the money comes back only if the recipient agrees", "value": "Past 7 months the recipient holds the decision. If the receiving institution is satisfied a mistaken payment happened it must seek the recipient's consent to return the money, and only if the recipient consents does the money travel back through the two institutions to the payer. Where the receiving institution is not satisfied, at any tier, it may still ask the recipient for consent but is not obliged to do anything more.", "citation": "ePayments Code, clauses 32.1 to 32.4, and clauses 30.3 and 31.5", "rests_on": "guidance" }, { "label": "Where the money is not all there, the receiving institution weighs both customers and decides how much to pursue", "value": "Where both institutions accept a mistaken payment happened but the recipient's account no longer holds the full amount, the receiving institution must exercise a discretion, weighing the interests of the payer and of the recipient and what it reasonably knows about the circumstances, and decide whether to pursue the whole amount, part of it, or none. The Code lists factors to guide that discretion and says it is not unfettered, and where the institution decides to pursue the money it must use reasonable endeavours to get it back, for example by accepting instalments. The same reporting tiers still apply.", "citation": "ePayments Code, clauses 34.1 to 34.6", "rests_on": "guidance" }, { "label": "The sending institution must tell the customer the outcome in writing within 30 business days", "value": "Whatever happens, the customer gets an answer. The sending institution must tell them the outcome of the reported mistaken payment in writing within 30 business days of the report, and the letter must say how they can complain about the way the report was handled. If they are not satisfied, they must be able to take the complaint to the external dispute resolution scheme, and the receiving institution's failure to cooperate is expressly not a reason the sending institution can offer for missing its own obligations.", "citation": "ePayments Code, clauses 35.1, 35.2, 36.1 to 36.3 and 36.5", "rests_on": "guidance" } ], "exceptions": [ "The Code binds subscribers only. Which Australian institutions subscribe was not established here, so whether a particular institution owes any of this is not held.", "A payment the customer made because they were deceived is not covered by any of this. The mistaken payment process is about wrong details, not about scams.", "Where the recipient is receiving certain government support payments, a separate code of operation governs how the money is recovered from them." ], "applies_to": "payments made through a pay anyone banking facility by a customer of an institution that subscribes to the ePayments Code and is an authorised deposit-taking institution, other than a provider of a purchased payment facility", "caveat": "The on screen warning duty the Code imposes covers a payment made with a branch and account number and, by its own note, does not cover a payment made with a PayID.", "related": [ "pix:refund", "sepa-sdd-core:refund", "uk-fps:refund", "au-npp:recall", "au-npp:consumer-law" ], "basis": { "sources": "ASIC's ePayments Code as published 2 June 2022, clauses 25.2, 27, 28 to 36, read 2026-09-21, and NPP Regulations v21.0 Regulations 6.5 and 6.6 for the absence of a scheme level right.", "confidence": "high" }, "currency": { "effective_since": "Unknown: the rulebook dates individual amendments rather than provisions, and the current edition cannot be read", "effective_to": null, "effective_note": "Drafted 2026-09-21 in Orca Core form. Where this fact rests on the rulebook it rests on NPP Regulations v21.0 of 24 September 2024, because the current edition is published only as scanned page images. What moved between the two editions is not held [Unverified]. Where it rests on the ePayments Code or on the Scams Prevention Framework instruments it rests on current text that an agent can read.", "source_edition": "NPP Regulations v21.0 of 24 September 2024, the public redacted version and the newest readable edition of the rulebook; the NPP Payment Initiation Messages technical guidance v4.0 of 20 November 2025; ASIC's ePayments Code as published 2 June 2022; the Scams Prevention Framework Act 2025 as made and the Competition and Consumer (Scams Prevention Framework, Regulated Sectors) Designation 2026; the Reserve Bank of Australia's About RITS page; and Australian Payments Plus's PayTo FAQs. All read 2026-09-21. The current edition of the rulebook, NPP Product Rules v.31 of September 2026, was downloaded the same day and could not be read: 102 pages, no font resource on any page and no extractable character.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://download.asic.gov.au/media/lloeicwb/epayments-code-published-02-june-2022.pdf", "source_class": "authoritative_primary", "source_title": "ePayments Code", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Confirms the ePayments Code's mistaken internet payment process as the refund-shaped right an Australian consumer actually has: the sending institution's 5 business day request window, the receiving institution's reporting-tier obligations at 10 business days, 10 business days to 7 months, and beyond 7 months, the insufficient funds discretion, and the 30 business day written outcome duty (clauses 27 to 36)." }, { "source_url": "https://www.auspayplus.com.au/wp-content/uploads/2024/10/NPP-Regulations-v21.0_Public_version.pdf", "source_class": "authoritative_primary", "source_title": "Regulations for the New Payments Platform, v21.0, public version", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Confirms Regulations 6.5 and 6.6 give the Payer Customer no refund right of their own, every return route running between the Payer Participant and the Payee Participant instead." } ] }, "rail_name": "New Payments Platform (Australia)", "governing_authority": "NPP Australia Limited", "snapshot": "2026-09-20", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "au-npp:return", "id": "return", "rail": "au-npp", "kind": "rail-fact", "facet": "return", "name": "How does money come back on the NPP?", "statement": "As a new payment going the other way. A return is a message the receiving institution sends to effect the return of a settled payment, and it settles in its own right, so after a return the ledger holds two payments rather than none and the original one is still settled and still final. The receiving institution may send one without being asked, and whether it tells its own account holder or asks them first is expressly its own matter. A payment that never cleared cannot be returned at all, because nothing moved: it was rejected instead. A zero value return may not be sent. Every clock in the process, the time to ask, to acknowledge, to answer and to return, sits in a volume of the procedures that is available to members and direct affiliates only, so Orca holds who must do what and not a single deadline.", "details": [ { "label": "A return is a new payment in the opposite direction, never a reversal", "value": "Money comes back on this rail as a fresh payment. The return message is the message a receiving institution sends to effect the return of a settled payment, whether it does so on its own initiative or because the paying institution asked, and it settles in its own right. The original payment stays settled and stays final.", "citation": "Regulations for the New Payments Platform, v21.0, public version, the definition of NPP Payment Return, and Regulations 6.5 and 6.6", "rests_on": "rule" }, { "label": "Only a cleared payment may be returned, and only by the return message", "value": "A receiving institution may return a cleared payment only by initiating a return message that complies with the requirements in the procedures. There is no other route and no other message, so a payment that never cleared cannot be returned at all: it was rejected instead, and nothing moved.", "citation": "Regulations for the New Payments Platform, v21.0, public version, Regulation 6.6", "rests_on": "rule" }, { "label": "A zero value return may not be sent", "value": "The same provision that forbids a zero value payment forbids a zero value return: a receiving institution must not submit one. A partial return is not addressed by any provision read, so whether one is permitted is not held.", "citation": "Regulations for the New Payments Platform, v21.0, public version, Regulation 6.1(c)(ii)", "rests_on": "rule" }, { "label": "An unsolicited return, and what the account holder is told about it, is the receiving institution's own matter", "value": "A receiving institution may return a settled payment without anybody asking. Whether and how it tells its account holder, and whether it asks them first, is expressly left to it beyond any obligation imposed on it by statute, the general law or the scheme's own documents. The same is true of what it tells a customer about a payment it returns at the paying institution's request.", "citation": "Regulations for the New Payments Platform, v21.0, public version, the note to Regulation 6.6, and the note to Regulation 6.5(c)", "rests_on": "rule" }, { "label": "Every return window, acknowledgement deadline and return deadline is in the procedures and is not public", "value": "The rulebook sets out who must do what in a return and then sends every clock to a volume of the procedures that is available to members and direct affiliates only. The time a paying institution has to ask, the time a receiving institution has to acknowledge, the time it has to say whether it will return, and the time it has to do it are all prescribed there. No public document read gives a figure for any of them.", "citation": "Regulations for the New Payments Platform, v21.0, public version, Regulations 6.5(a)(i) to (ii)(D), 6.5(b)(ii), 6.5(c)(ii) and 6.6", "rests_on": "rule" } ], "exceptions": [ "Whether a partial return is permitted is not addressed by any provision read and is not held.", "On the PayTo side, an initiating institution that has sent a duplicate or erroneous request must notify and return the funds through a separate unsolicited process in the procedures." ], "applies_to": "payments on the New Payments Platform in Australia, in Australian dollars between Australian domiciled accounts: ordinary credit transfers, overlay service payments including Osko, the domestic leg of international transfers, and PayTo payments", "caveat": "Do not read return as reversal. Nothing on this rail reverses a payment, and a return does not disturb the finality of the payment it answers.", "related": [ "uk-fps:return", "rtp:return", "au-npp:recall", "au-npp:refund" ], "basis": { "sources": "NPP Regulations v21.0, Regulations 6.1(c)(ii), 6.5, 6.6 and 17.9, and the definition of NPP Payment Return, read 2026-09-21.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the rulebook dates individual amendments rather than provisions, and the current edition cannot be read", "effective_to": null, "effective_note": "Drafted 2026-09-21 in Orca Core form. Where this fact rests on the rulebook it rests on NPP Regulations v21.0 of 24 September 2024, because the current edition is published only as scanned page images. What moved between the two editions is not held [Unverified]. Where it rests on the ePayments Code or on the Scams Prevention Framework instruments it rests on current text that an agent can read.", "source_edition": "NPP Regulations v21.0 of 24 September 2024, the public redacted version and the newest readable edition of the rulebook; the NPP Payment Initiation Messages technical guidance v4.0 of 20 November 2025; ASIC's ePayments Code as published 2 June 2022; the Scams Prevention Framework Act 2025 as made and the Competition and Consumer (Scams Prevention Framework, Regulated Sectors) Designation 2026; the Reserve Bank of Australia's About RITS page; and Australian Payments Plus's PayTo FAQs. All read 2026-09-21. The current edition of the rulebook, NPP Product Rules v.31 of September 2026, was downloaded the same day and could not be read: 102 pages, no font resource on any page and no extractable character.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.auspayplus.com.au/wp-content/uploads/2024/10/NPP-Regulations-v21.0_Public_version.pdf", "source_class": "authoritative_primary", "source_title": "Regulations for the New Payments Platform, v21.0, public version", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Confirms a return is a distinct pacs.004 NPP Payment Return the Payee Participant sends, whether unsolicited or requested (definition of NPP Payment Return, 6.5, 6.6), that only a Cleared payment may be returned (6.6), that a zero value return is forbidden (6.1(c)(ii)), and that every deadline in the process is set by reference to the non-public NPP Procedures Volume 9." } ] }, "rail_name": "New Payments Platform (Australia)", "governing_authority": "NPP Australia Limited", "snapshot": "2026-09-20", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "au-npp:settlement", "id": "settlement", "rail": "au-npp", "kind": "rail-fact", "facet": "settlement", "name": "How and when does an NPP payment settle?", "statement": "Every payment settles on its own, in central bank money, immediately, around the clock. The Fast Settlement Service is a component of the Reserve Bank's own real time gross settlement system, built and run by the Reserve Bank, and it settles each payment by debiting and crediting the two institutions' exchange settlement accounts. Nobody decides to settle: the paying institution's gateway generates the settlement request automatically for every cleared payment. The service tests whether the paying institution has the funds and either settles or rejects, with no queue and no liquidity management features at all, deliberately, so that processing is faster. An institution manages the liquidity question instead by splitting its settlement account funds between an amount available to this service and an amount available to everything else. Settling is a permission the central bank grants: a participant that is not authorised settles through a private arrangement with one that is.", "details": [ { "label": "Every payment settles on its own, in central bank money, across exchange settlement accounts", "value": "There is no netting and no settlement window on this rail. Each cleared payment is submitted for settlement through the Fast Settlement Service and settles by debiting and crediting the exchange settlement accounts of the institutions responsible for it, individually and in real time, subject to the Reserve Bank's own rules for the system.", "citation": "Regulations for the New Payments Platform, v21.0, public version, Regulation 7.3(a) to (c); Reserve Bank of Australia, About RITS, About RITS", "rests_on": "rule" }, { "label": "The paying institution's gateway generates a settlement request for every cleared payment by itself", "value": "Settlement is not a separate decision anybody makes. For each cleared payment the payer participant's gateway automatically generates a settlement request and submits it to the settlement service inside the configurable timeout values the procedures prescribe, and every participant that connects must configure its gateway to do that, to receive the notifications that come back, and to queue requests.", "citation": "Regulations for the New Payments Platform, v21.0, public version, Regulations 6.2(c) and 7.2(a) to (c)", "rests_on": "rule" }, { "label": "The settlement service tests the paying institution's funds and either settles or rejects", "value": "When the settlement request arrives, the service checks whether the paying institution has the funds on its settlement account and settles the payment if it does or rejects it if it does not. There is no queue that holds a payment until funds appear and no decision for a person to take.", "citation": "Reserve Bank of Australia, About RITS, About RITS, on how the Fast Settlement Service handles a settlement request", "rests_on": "rule" }, { "label": "The settlement service carries no liquidity management features, deliberately", "value": "The Reserve Bank says the Fast Settlement Service does not include liquidity management features, and that the reason is speed: leaving them out makes payment processing faster. A participant manages the liquidity question instead by how it allocates its own settlement account funds.", "citation": "Reserve Bank of Australia, About RITS, About RITS, on liquidity management features", "rests_on": "rule" }, { "label": "A participant may split its settlement account funds between the instant service and everything else", "value": "The Reserve Bank says the funds of a settlement account holder that takes part in the Fast Settlement Service may be allocated so as to be available either for testing and settling transactions in that service or for all other transactions. That allocation is how an institution keeps an instant rail that never closes from starving the rest of its settlement obligations.", "citation": "Reserve Bank of Australia, About RITS, About RITS, on the allocation of exchange settlement account funds", "rests_on": "rule" }, { "label": "Only an institution the Reserve Bank has authorised may settle, and it must stay authorised", "value": "Settling on this rail is a permission the central bank grants rather than a consequence of joining the scheme. A Full Participant and a Settlement Participant must be, and must remain, authorised by the Reserve Bank to use the Fast Settlement Service for the settlement of cleared payments.", "citation": "Regulations for the New Payments Platform, v21.0, public version, Regulations 7.1, 4.3(f) and 4.5", "rests_on": "rule" }, { "label": "A clearing participant settles through a private arrangement with another participant", "value": "An institution may connect and clear without being authorised to settle. To be a Clearing Participant it must meet all of the connection requirements a Full Participant meets and then enter a proprietary arrangement with another participant to have its payments settled. The arrangement is between the two of them and the scheme does not set its terms.", "citation": "Regulations for the New Payments Platform, v21.0, public version, Regulation 4.4(a) and (b)", "rests_on": "rule" }, { "label": "What happens when settlement fails or its status is unknown is in the procedures, and is not public", "value": "Two situations the rulebook names and does not describe. During an outage of the settlement service, connecting participants must run arrangements the incident response group establishes under a volume of the procedures. Where a cleared payment ends up with an indeterminate settlement status, the paying institution is obliged to settle for it under arrangements in another volume of the procedures. Both volumes are participant material and no figure, deadline or mechanism from either is public.", "citation": "Regulations for the New Payments Platform, v21.0, public version, Regulations 7.5 and 7.6", "rests_on": "rule" } ], "exceptions": [ "A settlement request can be rejected, and then the cleared payment behind it is void.", "During an outage of the settlement service, and where a payment ends up with an indeterminate settlement status, the arrangements that apply are in the procedures and are not public." ], "applies_to": "payments on the New Payments Platform in Australia, in Australian dollars between Australian domiciled accounts: ordinary credit transfers, overlay service payments including Osko, the domestic leg of international transfers, and PayTo payments", "caveat": "The absence of liquidity management features is a design choice with a consequence: an institution that has not allocated enough to the instant tranche of its settlement account will see payments rejected at settlement rather than queued, and the payments behind them were already accepted by the other side.", "related": [ "rtp:settlement", "fednow:settlement", "ch-sic-ip:settlement", "in-upi:settlement", "uk-fps:settlement", "au-npp:finality" ], "basis": { "sources": "NPP Regulations v21.0, Regulations 7.1 to 7.6, 4.3(f), 4.4(b) and 4.5, and the Reserve Bank's About RITS page, both read 2026-09-21.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the rulebook dates individual amendments rather than provisions, and the current edition cannot be read", "effective_to": null, "effective_note": "Drafted 2026-09-21 in Orca Core form. Where this fact rests on the rulebook it rests on NPP Regulations v21.0 of 24 September 2024, because the current edition is published only as scanned page images. What moved between the two editions is not held [Unverified]. Where it rests on the ePayments Code or on the Scams Prevention Framework instruments it rests on current text that an agent can read.", "source_edition": "NPP Regulations v21.0 of 24 September 2024, the public redacted version and the newest readable edition of the rulebook; the NPP Payment Initiation Messages technical guidance v4.0 of 20 November 2025; ASIC's ePayments Code as published 2 June 2022; the Scams Prevention Framework Act 2025 as made and the Competition and Consumer (Scams Prevention Framework, Regulated Sectors) Designation 2026; the Reserve Bank of Australia's About RITS page; and Australian Payments Plus's PayTo FAQs. All read 2026-09-21. The current edition of the rulebook, NPP Product Rules v.31 of September 2026, was downloaded the same day and could not be read: 102 pages, no font resource on any page and no extractable character.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.auspayplus.com.au/wp-content/uploads/2024/10/NPP-Regulations-v21.0_Public_version.pdf", "source_class": "authoritative_primary", "source_title": "Regulations for the New Payments Platform, v21.0, public version", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Confirms settlement occurs via the FSS by debiting and crediting the ESAs of the responsible participants (7.3), that the Payer Participant's gateway automatically generates the Settlement Request for every Cleared payment (6.2(c), 7.2), and that Full and Settlement Participants must be authorised by the RBA to use the FSS (7.1, 4.3(f), 4.5), with a Clearing Participant settling through another participant instead (4.4)." }, { "source_url": "https://www.rba.gov.au/payments-and-infrastructure/rits/about.html", "source_class": "authoritative_primary", "source_title": "Reserve Bank of Australia, About RITS", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Confirms the FSS tests the paying ESA holder's funds and settles or rejects, carries no liquidity management features so that processing is faster, and that ESA holders split their funds between an FSS-available tranche and everything else." } ] }, "rail_name": "New Payments Platform (Australia)", "governing_authority": "NPP Australia Limited", "snapshot": "2026-09-20", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "bancontact:consumer-law", "id": "consumer-law", "rail": "bancontact", "kind": "rail-fact", "facet": "consumer-law", "name": "What law protects the payer, and what must the merchant do?", "statement": "A Bancontact Pro merchant must comply with EU consumer law, the Interchange Fee Regulation, the GDPR and PSD2 (or the Payment Services Regulation once it applies), and with the Wero and Bancontact scheme rules; it may not surcharge, and must disclose any restriction on returns, refunds or cancellation before the payer pays. For card and app payments the payer's rights sit in the card issuer's terms and payment services law, and an unauthorised Wero payment is a matter for the payer's bank rather than the chargeback route. No law itself was read.", "details": [ { "label": "Merchant must follow EU payment, data, interchange and consumer law, and both schemes' rules", "value": "A Bancontact Pro merchant must keep to European and local law, naming European consumer protection law, the GDPR, the Interchange Fee Regulation and PSD2 (or the Payment Services Regulation once it applies), even where it sits outside the EU or the law would not otherwise reach it. It must also follow the scheme rules of EPI and of Bancontact, notably on trademarks, risk management and processing, and deliver age-restricted goods only to adults.", "citation": "Bancontact Company, General Terms and Conditions, Merchants (version date 2026-03-01), article 6.1 III and IV", "rests_on": "rule" }, { "label": "No surcharge on Bancontact Pro payments", "value": "A merchant may not charge the payer extra for paying through Bancontact Pro. The 2014 scheme answer said surcharging on the card scheme was allowed; that predates the EU surcharge ban and should not be read as current.", "citation": "Bancontact Company, General Terms and Conditions, Merchants (version date 2026-03-01), article 6.6; Response of the Bancontact/Mister Cash Card Scheme to the Eurosystem questionnaire on SEPA compliance of card schemes (May 2014), question 2 a", "rests_on": "rule" }, { "label": "Disclose return, refund and cancellation limits before payment", "value": "If a merchant restricts returns, refunds or cancellations, it must say so before the payer pays: in store by telling the payer, online through a linked policy or text in the checkout that the consumer actively acknowledges, such as by ticking a box. An online merchant's site must also show how to reach its customer service, its privacy policy, any restrictive refund and cancellation policy, and its registered address.", "citation": "Bancontact Company, General Terms and Conditions, Merchants (version date 2026-03-01), article 6.1 V; Bancontact Company, General Terms and Conditions, Merchants (version date 2026-03-01), article 6.7", "rests_on": "rule" }, { "label": "The cardholder's rights sit in the card issuer's terms", "value": "The card and every Mobile Bancontact Transaction made with it are governed by the card issuer's terms, not the app terms, including how the payer authorises a payment. Payment questions, problems and complaints go to the issuer, and Bancontact Company may pass a complaint about a payment to the bank. The rights a consumer has on an unauthorised or wrongly executed card payment therefore come from the issuer's terms and payment services law [Inference].", "citation": "Bancontact Pay App Terms and Conditions, version 8.0, articles 1.4, 6.2.2, 6.2.4 and 21", "rests_on": "rule" }, { "label": "A payer's claim of no authorisation is not a Wero chargeback", "value": "The Merchant T&C carve out one kind of dispute from the Wero chargeback route: a payer saying the payment was never authorised. Such a claim is for the payer's bank to handle with its customer under payment services law [Inference: the terms do not say where it goes].", "citation": "Bancontact Company, General Terms and Conditions, Merchants (version date 2026-03-01), article 8", "rests_on": "rule" } ], "exceptions": [ "The scheme's 2014 answer allowed surcharging; that no longer describes consumer card payments in the EU [Inference]." ], "applies_to": "Bancontact in Belgium, in euro: Bancontact card payments at terminals and online, Mobile Bancontact Transactions in the Bancontact Pay app (person to merchant and person to person), and Bancontact Pro payments settled by Bancontact or by Wero", "caveat": "Orca holds no consumer-law text for Belgium; the rights named here are what the operator's terms point to.", "related": [ "sepa-sct-inst:consumer-law", "bancontact:liability" ], "basis": { "sources": "Merchant T&C articles 6.1, 6.6, 6.7 and 8; App T&C articles 1.4, 6.2 and 21; SCF response question 2 a (May 2014); read 2026-09-19.", "confidence": "medium" }, "currency": { "effective_since": "2026-03-01", "effective_to": null, "effective_note": "Drafted 2026-09-19 in Orca Core form. The date is the version date of the Merchant T&C and the start date of App T&C version 8.0; lines from the 2014 scheme answer, the developer guides and processors carry their own dates in their Rules.", "source_edition": "Merchant T&C version date 2026-03-01; Bancontact Pay App T&C version 8.0; the scheme's May 2014 SEPA compliance answer; bancontact.com pages; Bancontact Pro developer guides versioned 052025; Stripe and Adyen Bancontact pages; all read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://assets-us-01.kc-usercontent.com:443/0d76cd9b-cf9d-007c-62ee-e50e20111691/461a17b0-b853-4420-838c-4732627c1de0/260129%20Merchant%20T_C%20ENG%20-%20FINAL.pdf", "source_class": "authoritative_primary", "source_title": "Bancontact Company, General Terms and Conditions, Merchants (version date 2026-03-01)", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms the merchant's legal-compliance, no-surcharge and disclosure duties, articles 6.1, 6.6, 6.7 and 8." } ] }, "rail_name": "Bancontact (Belgian debit card scheme and Bancontact Pro)", "governing_authority": "Bancontact Company SA/NV (card scheme rules, not public; Bancontact Pro and Bancontact Pay terms, public)", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "bancontact:decision-points", "id": "decision-points", "rail": "bancontact", "kind": "rail-fact", "facet": "decision-points", "name": "Where does the rail stop and someone decide?", "statement": "The card issuer or payer's bank approves or declines each payment. Bancontact Company decides, before SUCCEEDED, whether to refuse or suspend a Bancontact Pro payment, and may block or end a merchant's service on security, fraud, chargeback, breach or instruction grounds, including instructions from the acquirer or EPI. After a Wero chargeback it decides whether to represent. In the app, three wrong PINs block access, Card Stop blocks the app or cards on the user's call, and Bancontact Company may block the app for security or suspected misuse.", "details": [ { "label": "The issuer or payer's bank decides whether a payment goes through", "value": "Only payments the payer's bank approves are credited to a Bancontact Pro merchant, and a bank-side decline shows as AUTHORIZATION_FAILED, for instance for lack of funds or card limits. For card payments the scheme said in 2014 that every transaction is authorised online by the issuer, and the app terms make no promise that an issuer will honour a payment the app has authenticated.", "citation": "Bancontact Company, General Terms and Conditions, Merchants (version date 2026-03-01), article 7.2.1; Bancontact Pro Developer Portal, API Errors, Statuses, and Responses (052025), Payment Statuses, AUTHORIZATION_FAILED; Bancontact Pay App Terms and Conditions, version 8.0, article 6.2.4; Response of the Bancontact/Mister Cash Card Scheme to the Eurosystem questionnaire on SEPA compliance of card schemes (May 2014), question 16", "rests_on": "rule" }, { "label": "When Bancontact Company may refuse or suspend a payment", "value": "Before a payment is SUCCEEDED, Bancontact Company may refuse or suspend it, wholly or in part. Its grounds, in Orca's grouping: risk (suspected fraud or misuse of the service, or chargeback or fraud levels it judges too high or likely to become so); the order itself (reasonable doubt about its validity or about who gave it, an incorrect or incomplete order, a payer limit exceeded); law and contract (a legal breach, a restricted activity, a breach of the agreement); an instruction from the acquirer, EPI or a competent authority; or another urgent, justified reason. Unless the law forbids it, it tells the merchant of the refusal and, where reasonable, why and how to correct it.", "citation": "Bancontact Company, General Terms and Conditions, Merchants (version date 2026-03-01), articles 12.1.1 to 12.1.3", "rests_on": "rule" }, { "label": "Blocking the merchant's service and ending it at once", "value": "Bancontact Company may block the Merchant Portal, API keys, the payment function or the whole service when a government body tells it to, when chargebacks are excessive, when it suspects misuse or security requires it, or for invoices left unpaid after notice; only as far as the problem needs, with advance notice where possible, and lifting it once the reason ends. It may also end or suspend the agreement at once, among other grounds on material breach or fraud, many payer complaints, reversal, refund or chargeback levels abnormal for the sector, insolvency, six months without a payment, instructions from a supervisor, the acquirer or EPI, suspected illegal or reputation-damaging use, or where serving the merchant has become unlawful. Otherwise either side may end it with a month's notice.", "citation": "Bancontact Company, General Terms and Conditions, Merchants (version date 2026-03-01), articles 12.2.1 to 12.2.3; Bancontact Company, General Terms and Conditions, Merchants (version date 2026-03-01), articles 16.2 and 16.3", "rests_on": "rule" }, { "label": "Representment: Bancontact Company decides, the merchant has 15 days to send evidence", "value": "The merchant never starts a chargeback or a representment itself. After a chargeback Bancontact Company examines the case and decides whether it can contest it with a representment; it may ask the merchant for more evidence, which the merchant must provide promptly and within 15 days at most. Once Bancontact Company sends a representment to the payer's bank, it owes the merchant the amount, which by default is added to that working day's payout.", "citation": "Bancontact Company, General Terms and Conditions, Merchants (version date 2026-03-01), article 1, definition of Representment; Bancontact Company, General Terms and Conditions, Merchants (version date 2026-03-01), article 7.5", "rests_on": "rule" }, { "label": "Blocking the app or a card", "value": "Three wrong Mobile PINs in a row block the app until the user resets it. A user who suspects the app, the PIN or the phone is compromised, or sees payments made by someone else, must call Card Stop and Bancontact's support at once; Card Stop then blocks either the app alone or one or more cards, which blocks the physical card too. Bancontact Company may block, disable or restrict the app for security, suspected fraud or misuse, breach of the terms or an instruction from the law or an authority, notifying in advance where it can.", "citation": "Bancontact Pay App Terms and Conditions, version 8.0, articles 4, 7.3, 8 and 18.3; Bancontact, Bancontact card, lost card section", "rests_on": "rule" } ], "exceptions": [ "After SUCCEEDED, Bancontact Company may no longer refuse or suspend the payment." ], "applies_to": "Bancontact in Belgium, in euro: Bancontact card payments at terminals and online, Mobile Bancontact Transactions in the Bancontact Pay app (person to merchant and person to person), and Bancontact Pro payments settled by Bancontact or by Wero", "caveat": "The thresholds Bancontact Company applies to chargeback and fraud levels are its own judgment and not published.", "related": [ "sepa-sct-inst:decision-points", "bancontact:limits" ], "basis": { "sources": "Merchant T&C articles 7.2.1, 7.5, 12 and 16; App T&C articles 4, 6.2.4, 7.3, 8 and 18.3; errors and statuses guide; SCF response question 16 (May 2014); read 2026-09-19.", "confidence": "medium" }, "currency": { "effective_since": "2026-03-01", "effective_to": null, "effective_note": "Drafted 2026-09-19 in Orca Core form. The date is the version date of the Merchant T&C and the start date of App T&C version 8.0; lines from the 2014 scheme answer, the developer guides and processors carry their own dates in their Rules.", "source_edition": "Merchant T&C version date 2026-03-01; Bancontact Pay App T&C version 8.0; the scheme's May 2014 SEPA compliance answer; bancontact.com pages; Bancontact Pro developer guides versioned 052025; Stripe and Adyen Bancontact pages; all read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://assets-us-01.kc-usercontent.com:443/0d76cd9b-cf9d-007c-62ee-e50e20111691/461a17b0-b853-4420-838c-4732627c1de0/260129%20Merchant%20T_C%20ENG%20-%20FINAL.pdf", "source_class": "authoritative_primary", "source_title": "Bancontact Company, General Terms and Conditions, Merchants (version date 2026-03-01)", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms who approves a payment, who refuses or suspends it, and who decides on blocking, termination and representment, articles 7.2.1, 7.5, 12 and 16." } ] }, "rail_name": "Bancontact (Belgian debit card scheme and Bancontact Pro)", "governing_authority": "Bancontact Company SA/NV (card scheme rules, not public; Bancontact Pro and Bancontact Pay terms, public)", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "bancontact:finality", "id": "finality", "rail": "bancontact", "kind": "rail-fact", "facet": "finality", "name": "When is a Bancontact payment final, and can it be undone?", "statement": "Three things share the name, and finality differs. Under Bancontact Pro, a payment is settled for the merchant once Bancontact Company reports it SUCCEEDED: it then guarantees the payout and can no longer refuse the payment, and a final API status never changes. The Bancontact leg of Bancontact Pro cannot be charged back, and processors say the same of Bancontact card and app payments online. The Wero leg is a SEPA instant credit transfer, final between banks as SCT Inst is, but the payer's bank can still charge it back under EPI's rules. The card scheme's own finality rules are not public.", "details": [ { "label": "SUCCEEDED binds Bancontact Company to pay the merchant", "value": "Once Bancontact Company reports a payment as SUCCEEDED, in the API or the Merchant Portal, it guarantees that the gross amount reaches the merchant's Payout IBAN through its own account. Only two things break the guarantee: a regulatory bar on paying out, or the merchant's bank blocking the credit. From that point Bancontact Company may no longer refuse or suspend the payment, and it takes on no further duty for how the payment itself was executed.", "citation": "Bancontact Company, General Terms and Conditions, Merchants (version date 2026-03-01), article 7.2.3; Bancontact Company, General Terms and Conditions, Merchants (version date 2026-03-01), article 12.1.2", "rests_on": "rule" }, { "label": "The Bancontact leg of Bancontact Pro cannot be charged back", "value": "In the Merchant T&C only a Wero payment can be charged back; the definition of chargeback says in terms that a Bancontact payment cannot be. A dispute over a Bancontact payment therefore has no chargeback route through Bancontact Company.", "citation": "Bancontact Company, General Terms and Conditions, Merchants (version date 2026-03-01), article 1, definition of Chargeback; Bancontact Company, General Terms and Conditions, Merchants (version date 2026-03-01), article 8", "rests_on": "rule" }, { "label": "Processors: Bancontact card and app payments have no chargebacks", "value": "Two processors that acquire Bancontact online say it has no dispute path that ends in a chargeback: Stripe lists dispute support as no and explains that the payer authenticates with the bank, and Adyen's feature table marks chargebacks as not supported for Bancontact card and Bancontact mobile payments. Neither is the scheme's own text, which is not public; nothing read covers card payments at a terminal. The operator's own merchant terms say the same for the Bancontact leg of Bancontact Pro.", "citation": "Stripe Docs, Bancontact payments, payment method properties; Disputes; Adyen Docs, Bancontact card, feature table, Chargebacks column", "rests_on": "rule" }, { "label": "Ten payment statuses; a final status never changes", "value": "Bancontact's public APIs report a payment in one of ten statuses, in create, get and search responses and in callbacks. Four are intermediary: PENDING (created, not yet started by the payer), IDENTIFIED (the payer has interacted, for example scanned the QR code), AUTHORIZED (passed first checks) and PENDING_MERCHANT_AKNOWLEDGMENT (confirmed by the payer and waiting for the merchant, void service only). Six are final: SUCCEEDED, AUTHORIZATION_FAILED (declined on the bank side, for instance funds or card limits), FAILED (technical or logical error), CANCELLED, EXPIRED (not completed in time) and VOIDED (void service only). Once final, a status does not change.", "citation": "Bancontact Pro Developer Portal, API Errors, Statuses, and Responses (052025), Payment Statuses", "rests_on": "rule" }, { "label": "The Wero leg is a SEPA instant credit transfer under EPI's scheme", "value": "A Wero payment accepted through Bancontact Pro is a SEPA instant credit transfer from the payer's bank to Bancontact Company, under Wero's scheme manager EPI. Its execution, finality between banks, amount limits, hours and the payer's rights against its own bank are therefore those of SEPA Instant Credit Transfer and of payment services law, not Bancontact's [Inference from the definition of Wero]. What Bancontact Company adds by contract is the payout, the chargeback and representment handling, and the void and refund services.", "citation": "Bancontact Company, General Terms and Conditions, Merchants (version date 2026-03-01), article 1, definitions of Wero, EPI and Acceptance Service; Bancontact Company, General Terms and Conditions, Merchants (version date 2026-03-01), article 6.1 III; Bancontact Pro Developer Portal, Payouts, Bulking and Remittance Information (052025), Remittance Information", "rests_on": "rule" }, { "label": "Wero payments can be charged back for any dispute except an unauthorised one", "value": "When a payer disputes a settled Wero payment, for example a debit taken twice or for the wrong amount, or goods that never came or were not as described, the payer's bank may raise a chargeback under EPI's rules. Bancontact Company credits the payer's bank and the merchant owes the amount as soon as the chargeback arrives: Bancontact Company may net the day's chargebacks from that day's payments, carry a negative balance to later working days until incoming payments cover it, or send a payment request instead. Each chargeback also costs the merchant a fee that is not refunded, and Bancontact Company may recover chargebacks and fees after the agreement ends, for as long as EPI's rules allow chargebacks on payments made during it. The merchant must keep chargeback risk low.", "citation": "Bancontact Company, General Terms and Conditions, Merchants (version date 2026-03-01), article 1, definition of Chargeback; Bancontact Company, General Terms and Conditions, Merchants (version date 2026-03-01), article 7.5; Bancontact Company, General Terms and Conditions, Merchants (version date 2026-03-01), article 8", "rests_on": "rule" } ], "exceptions": [ "The payout guarantee on SUCCEEDED does not hold if regulation forbids the payout or the merchant's bank blocks it.", "A Wero payment through Bancontact Pro can be charged back after settlement for any dispute except a claim that it was not authorised.", "With the void service, a payment is held and can still be voided until the merchant confirms it or 168 hours pass." ], "applies_to": "Bancontact in Belgium, in euro: Bancontact card payments at terminals and online, Mobile Bancontact Transactions in the Bancontact Pay app (person to merchant and person to person), and Bancontact Pro payments settled by Bancontact or by Wero", "caveat": "Do not answer can a Bancontact payment be charged back without saying which leg: the Bancontact leg cannot, the Wero leg can. A co-badged card run on Visa or Mastercard follows that network instead [Inference].", "related": [ "sepa-sct-inst:finality", "bancontact:return", "bancontact:recall" ], "basis": { "sources": "Merchant T&C articles 1, 7.2.3, 8 and 12.1.2; errors and statuses guide; Stripe and Adyen Bancontact pages; read 2026-09-19. Card scheme finality is not public.", "confidence": "medium" }, "currency": { "effective_since": "2026-03-01", "effective_to": null, "effective_note": "Drafted 2026-09-19 in Orca Core form. The date is the version date of the Merchant T&C and the start date of App T&C version 8.0; lines from the 2014 scheme answer, the developer guides and processors carry their own dates in their Rules.", "source_edition": "Merchant T&C version date 2026-03-01; Bancontact Pay App T&C version 8.0; the scheme's May 2014 SEPA compliance answer; bancontact.com pages; Bancontact Pro developer guides versioned 052025; Stripe and Adyen Bancontact pages; all read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://assets-us-01.kc-usercontent.com:443/0d76cd9b-cf9d-007c-62ee-e50e20111691/461a17b0-b853-4420-838c-4732627c1de0/260129%20Merchant%20T_C%20ENG%20-%20FINAL.pdf", "source_class": "authoritative_primary", "source_title": "Bancontact Company, General Terms and Conditions, Merchants (version date 2026-03-01)", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms the SUCCEEDED payout guarantee, the Bancontact leg's no-chargeback rule, and the Wero leg's chargeback route, articles 1, 7.2.3, 8 and 12.1.2." } ] }, "rail_name": "Bancontact (Belgian debit card scheme and Bancontact Pro)", "governing_authority": "Bancontact Company SA/NV (card scheme rules, not public; Bancontact Pro and Bancontact Pay terms, public)", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "bancontact:hours", "id": "hours", "rail": "bancontact", "kind": "rail-fact", "facet": "hours", "name": "What clock do Bancontact Pro payouts and deadlines run on?", "statement": "Payouts run on a bulk period from closing time to closing time, 00:00 CET unless the merchant sets another, and a bulk goes out on the next Belgian working day; weekend payments may reach the merchant only on Monday or Tuesday, depending on its bank. The void service holds a payment for up to 168 hours, and a merchant asked for evidence to contest a Wero chargeback has at most 15 days. No card scheme hours are public, and the Wero leg follows SEPA Instant's hours.", "details": [ { "label": "Bulk period runs from closing time to closing time", "value": "The bulk closing time is 00:00 CET unless the merchant sets another. Payments that succeed between one closing time and the next are paid out on the following day; payments on Friday, Saturday and Sunday follow the same logic, but since execution depends on the merchant's bank the money may only arrive on Monday or Tuesday.", "citation": "Bancontact Pro Developer Portal, Payouts, Bulking and Remittance Information (052025), Payment Bulking", "rests_on": "rule" }, { "label": "Bulked payout by SEPA credit transfer on the next working day", "value": "Unless agreed otherwise, Bancontact Company pays merchants in bulk: everything that succeeded in the 24 hours following each bulk closing time is sent by SEPA credit transfer to the Payout IBAN on the following Belgian working day. Refunds, chargebacks and representments of the same working day are netted into the same payout. Payments are grouped into a payout by a bulk instruction made of the merchant's company ID, Payout IBAN and closing time, plus a Bulk ID if the merchant sets one per payment. Bancontact Company may change the payout frequency after notice.", "citation": "Bancontact Company, General Terms and Conditions, Merchants (version date 2026-03-01), article 1, definitions of Bulk Instruction and Working Day; Bancontact Company, General Terms and Conditions, Merchants (version date 2026-03-01), article 7.4; Bancontact Pro Developer Portal, Payouts, Bulking and Remittance Information (052025), Payouts; Payment Bulking", "rests_on": "rule" }, { "label": "Void service: funds held up to 168 hours", "value": "A merchant that activates the void service and integrates the Void API has its bulked payments held by Bancontact Company until it confirms or cancels each one, or until 168 hours after the payment was created in Bancontact Company's systems. Confirmation makes the payment SUCCEEDED. A cancellation, or the time-out, voids it: Bancontact Company makes reasonable efforts to return the money to the payer and confirms the void to the merchant.", "citation": "Bancontact Company, General Terms and Conditions, Merchants (version date 2026-03-01), article 9.2; Bancontact Pro Developer Portal, API Errors, Statuses, and Responses (052025), Payment Statuses, PENDING_MERCHANT_AKNOWLEDGMENT and VOIDED", "rests_on": "rule" }, { "label": "Representment: Bancontact Company decides, the merchant has 15 days to send evidence", "value": "The merchant never starts a chargeback or a representment itself. After a chargeback Bancontact Company examines the case and decides whether it can contest it with a representment; it may ask the merchant for more evidence, which the merchant must provide promptly and within 15 days at most. Once Bancontact Company sends a representment to the payer's bank, it owes the merchant the amount, which by default is added to that working day's payout.", "citation": "Bancontact Company, General Terms and Conditions, Merchants (version date 2026-03-01), article 1, definition of Representment; Bancontact Company, General Terms and Conditions, Merchants (version date 2026-03-01), article 7.5", "rests_on": "rule" } ], "exceptions": [ "A merchant with individual payouts is paid per payment rather than per bulk period." ], "applies_to": "Bancontact in Belgium, in euro: Bancontact card payments at terminals and online, Mobile Bancontact Transactions in the Bancontact Pay app (person to merchant and person to person), and Bancontact Pro payments settled by Bancontact or by Wero", "caveat": "The payouts guide says CET; whether it means Belgian local time including summer time is [Inference].", "related": [ "sepa-sct-inst:hours", "sepa-sct:hours", "bancontact:settlement" ], "basis": { "sources": "Merchant T&C articles 1, 7.4, 7.5 and 9.2; payouts guide; read 2026-09-19.", "confidence": "high" }, "currency": { "effective_since": "2026-03-01", "effective_to": null, "effective_note": "Drafted 2026-09-19 in Orca Core form. The date is the version date of the Merchant T&C and the start date of App T&C version 8.0; lines from the 2014 scheme answer, the developer guides and processors carry their own dates in their Rules.", "source_edition": "Merchant T&C version date 2026-03-01; Bancontact Pay App T&C version 8.0; the scheme's May 2014 SEPA compliance answer; bancontact.com pages; Bancontact Pro developer guides versioned 052025; Stripe and Adyen Bancontact pages; all read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://assets-us-01.kc-usercontent.com:443/0d76cd9b-cf9d-007c-62ee-e50e20111691/461a17b0-b853-4420-838c-4732627c1de0/260129%20Merchant%20T_C%20ENG%20-%20FINAL.pdf", "source_class": "authoritative_primary", "source_title": "Bancontact Company, General Terms and Conditions, Merchants (version date 2026-03-01)", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms the bulking, void-hold and representment-evidence deadlines, articles 1, 7.4, 7.5 and 9.2." }, { "source_url": "https://docs.bancontactpro.com/guides/general/payoutremittance052025", "source_class": "authoritative_primary", "source_title": "Bancontact Pro Developer Portal, Payouts, Bulking and Remittance Information (052025)", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms the 00:00 CET default closing time and the weekend payout delay to Monday or Tuesday." } ] }, "rail_name": "Bancontact (Belgian debit card scheme and Bancontact Pro)", "governing_authority": "Bancontact Company SA/NV (card scheme rules, not public; Bancontact Pro and Bancontact Pay terms, public)", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "bancontact:liability", "id": "liability", "rail": "bancontact", "kind": "rail-fact", "facet": "liability", "name": "Who bears the loss when a Bancontact payment goes wrong?", "statement": "Under Bancontact Pro, Bancontact Company owes the merchant every SUCCEEDED payment, answers in a dispute only against a signed SUCCEEDED confirmation, and each side's liability to the other is capped at twelve months' fees, with no indirect loss and no cap for wilful misconduct or gross negligence. The merchant bears a wrong Payout IBAN and repays wrong credits. In the app, Bancontact Company excludes liability for how card transactions are executed and for unauthorised use of the device or PIN; the card issuer's terms govern the payment. For card payments the scheme described chip and PIN and strong authentication with no magnetic stripe fall-back in 2014; its liability rules are not public.", "details": [ { "label": "SUCCEEDED binds Bancontact Company to pay the merchant", "value": "Once Bancontact Company reports a payment as SUCCEEDED, in the API or the Merchant Portal, it guarantees that the gross amount reaches the merchant's Payout IBAN through its own account. Only two things break the guarantee: a regulatory bar on paying out, or the merchant's bank blocking the credit. From that point Bancontact Company may no longer refuse or suspend the payment, and it takes on no further duty for how the payment itself was executed.", "citation": "Bancontact Company, General Terms and Conditions, Merchants (version date 2026-03-01), article 7.2.3; Bancontact Company, General Terms and Conditions, Merchants (version date 2026-03-01), article 12.1.2", "rests_on": "rule" }, { "label": "In a dispute, Bancontact Company answers only against a signed SUCCEEDED", "value": "If the merchant and Bancontact Company disagree on whether a payment or refund went through, Bancontact Company accepts liability only if the merchant shows the digitally signed confirmation carrying the SUCCEEDED status described in the integration guide. For a QR sticker or a fixed amount QR code, the SUCCEEDED status shown in the Merchant Portal is enough.", "citation": "Bancontact Company, General Terms and Conditions, Merchants (version date 2026-03-01), article 7.3", "rests_on": "rule" }, { "label": "Liability between Bancontact Company and the merchant", "value": "Each side answers for damage its own failure to perform causes the other, up to a total equal to the fees paid in the 12 months before the event giving rise to the claim, and neither answers for indirect or consequential loss such as lost profit or reputation. The cap and exclusion do not cover wilful misconduct or gross negligence. Bancontact Company is not liable for loss that follows from the merchant's own breach, its equipment or software, or its integrator. The merchant indemnifies Bancontact Company for direct costs arising from fraud the merchant commits or supports, the merchant's breach of the terms, its integrator, recovering overdue sums, and Bancontact Company being drawn into the merchant's disputes with others.", "citation": "Bancontact Company, General Terms and Conditions, Merchants (version date 2026-03-01), article 11.2; Bancontact Company, General Terms and Conditions, Merchants (version date 2026-03-01), articles 13.1 to 13.6", "rests_on": "rule" }, { "label": "Wrong or wrongly credited Payout IBAN", "value": "The merchant guarantees that it owns its Payout IBANs; if one is not the merchant's account, Bancontact Company is not liable for money paid to it. If a technical or administrative error credits a Payout IBAN wrongly or unduly, the merchant must repay Bancontact Company at once. Bancontact Company may also set off any claim it has on the merchant against what it owes the merchant.", "citation": "Bancontact Company, General Terms and Conditions, Merchants (version date 2026-03-01), article 6.4; Bancontact Company, General Terms and Conditions, Merchants (version date 2026-03-01), article 7.2.4; Bancontact Company, General Terms and Conditions, Merchants (version date 2026-03-01), article 24.3", "rests_on": "rule" }, { "label": "Bancontact Company is not liable for how card transactions are executed", "value": "Bancontact Company provides the app and authenticates Mobile Bancontact Transactions on the card issuer's behalf; it does not issue cards and does not promise that an issuer will honour a payment. It excludes liability for non-execution or faulty execution of Mobile Bancontact Transactions, for unauthorised use of the user's device, app, Mobile PIN or biometrics, and for indirect loss, except for its own intentional act or fraud. The user answers for every charge to the card that results from app payments.", "citation": "Bancontact Pay App Terms and Conditions, version 8.0, articles 3, 6.2.4, 9.1 to 9.3", "rests_on": "rule" }, { "label": "Card scheme: issuer authorisation, chip and PIN, strong authentication online", "value": "In 2014 the scheme said every transaction is authorised by the issuer online, card present payments use chip with PIN, card not present payments need strong authentication, and there is no fall-back to the magnetic stripe, so an EMV liability shift did not apply. Adyen's current page agrees for online payments: 3D Secure is mandatory and there is no card security code, although a co-badged card may show one. Who bears a fraud loss between issuer and acquirer is not public.", "citation": "Response of the Bancontact/Mister Cash Card Scheme to the Eurosystem questionnaire on SEPA compliance of card schemes (May 2014), questions 16, 23 a and 26; Adyen Docs, Bancontact card, introduction", "rests_on": "guidance" } ], "exceptions": [ "The app exclusions do not cover Bancontact Company's own intentional act or fraud.", "A payer's rights on an unauthorised card payment come from the issuer's terms and payment services law [Inference]." ], "applies_to": "Bancontact in Belgium, in euro: Bancontact card payments at terminals and online, Mobile Bancontact Transactions in the Bancontact Pay app (person to merchant and person to person), and Bancontact Pro payments settled by Bancontact or by Wero", "caveat": "Liability between issuers and acquirers is in the scheme rules, which are not public.", "related": [ "sepa-sct-inst:liability", "bancontact:consumer-law" ], "basis": { "sources": "Merchant T&C articles 6.4, 7.2, 7.3, 11.2, 13 and 24.3; App T&C articles 3, 6.2.4 and 9; SCF response questions 16, 23 a and 26 (May 2014); Adyen Bancontact card page; read 2026-09-19.", "confidence": "medium" }, "currency": { "effective_since": "2026-03-01", "effective_to": null, "effective_note": "Drafted 2026-09-19 in Orca Core form. The date is the version date of the Merchant T&C and the start date of App T&C version 8.0; lines from the 2014 scheme answer, the developer guides and processors carry their own dates in their Rules.", "source_edition": "Merchant T&C version date 2026-03-01; Bancontact Pay App T&C version 8.0; the scheme's May 2014 SEPA compliance answer; bancontact.com pages; Bancontact Pro developer guides versioned 052025; Stripe and Adyen Bancontact pages; all read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://assets-us-01.kc-usercontent.com:443/0d76cd9b-cf9d-007c-62ee-e50e20111691/461a17b0-b853-4420-838c-4732627c1de0/260129%20Merchant%20T_C%20ENG%20-%20FINAL.pdf", "source_class": "authoritative_primary", "source_title": "Bancontact Company, General Terms and Conditions, Merchants (version date 2026-03-01)", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms the SUCCEEDED payout guarantee, the signed-SUCCEEDED dispute rule, the twelve-month liability cap, and the Payout IBAN duty, articles 6.4, 7.2, 7.3, 11.2, 13 and 24.3." } ] }, "rail_name": "Bancontact (Belgian debit card scheme and Bancontact Pro)", "governing_authority": "Bancontact Company SA/NV (card scheme rules, not public; Bancontact Pro and Bancontact Pay terms, public)", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "bancontact:limits", "id": "limits", "rail": "bancontact", "kind": "rail-fact", "facet": "limits", "name": "What amount limits apply to a Bancontact payment?", "statement": "App payments are held to the card's own limits and to separate app-level limits that Bancontact Company publishes on its FAQ and may change at will; the lower applies, and the app disables a card that has hit its limit. The operator says contactless card payments need no PIN up to 50 euro. A Bancontact Pro merchant may not set its own minimum or maximum amount, and Bancontact Company may refuse merchants in restricted lines of business. A refund is refused if it would take the day's balance below zero. The Wero leg is subject to SEPA Instant limits.", "details": [ { "label": "App limits apply on top of card limits; the lower wins", "value": "A Mobile Bancontact Transaction is subject to the limits of the card and to separate limits set at app level, which Bancontact Company publishes on its FAQ and may change on its own at any time. Whichever is lower applies. The app disables a card whose app-level limit is used up or would be exceeded by the payment, and every payment sent or received through the app reduces the available limits of the payer, and of the payee for person to person payments. The figures themselves were not read.", "citation": "Bancontact Pay App Terms and Conditions, version 8.0, article 6.2.3", "rests_on": "rule" }, { "label": "Contactless without PIN up to 50 euro", "value": "The operator tells cardholders that a contactless tap needs no PIN up to 50 euro, and that above that the terminal asks for the PIN after the tap. A payment with a Bancontact card in Apple Pay, confirmed with Face ID or Touch ID, is not held to the usual contactless limits. The scheme rule behind the figure is not public.", "citation": "Bancontact, Bancontact card, contactless and Apple Pay sections", "rests_on": "rule" }, { "label": "No merchant minimum or maximum under Bancontact Pro", "value": "A Bancontact Pro merchant may not tell payers that a payment must be at least or at most some amount, beyond whatever limits the payment schemes themselves set. The operator also tells cardholders that there is no minimum amount for card payments at a terminal.", "citation": "Bancontact Company, General Terms and Conditions, Merchants (version date 2026-03-01), article 6.6; Bancontact, Bancontact card, section on small purchases", "rests_on": "rule" }, { "label": "Activities that let Bancontact Company refuse or restrict a merchant", "value": "Bancontact Company may decline to serve a merchant, or refuse, block or end its service, if it has reason to think the merchant sells in certain restricted areas. In Orca's grouping: financial products that are hard to trace (crypto assets, e-money, prepaid value) and gambling without the required licence; goods such as weapons and military equipment, drugs, counterfeit or infringing products, health products sold on unfounded claims, human organs and anything else illegal locally; and content or services that are sexual or adult, promote hatred, violence or abuse, or arrange partners commercially. A merchant must report material business changes at once and changes to its information within 30 days.", "citation": "Bancontact Company, General Terms and Conditions, Merchants (version date 2026-03-01), article 6.2", "rests_on": "rule" }, { "label": "Refunds come out of the day's payout and fail on a negative balance", "value": "Bancontact Company keeps a running balance per bulking period of succeeded payments less refunds. The day's refunds are deducted from the day's payments and only the net is paid out; a refund that would push the balance of the current period below zero is declined.", "citation": "Bancontact Company, General Terms and Conditions, Merchants (version date 2026-03-01), article 9.3.2; Bancontact Pro Developer Portal, Refunds (052025), Introduction", "rests_on": "rule" }, { "label": "The Wero leg is a SEPA instant credit transfer under EPI's scheme", "value": "A Wero payment accepted through Bancontact Pro is a SEPA instant credit transfer from the payer's bank to Bancontact Company, under Wero's scheme manager EPI. Its execution, finality between banks, amount limits, hours and the payer's rights against its own bank are therefore those of SEPA Instant Credit Transfer and of payment services law, not Bancontact's [Inference from the definition of Wero]. What Bancontact Company adds by contract is the payout, the chargeback and representment handling, and the void and refund services.", "citation": "Bancontact Company, General Terms and Conditions, Merchants (version date 2026-03-01), article 1, definitions of Wero, EPI and Acceptance Service; Bancontact Company, General Terms and Conditions, Merchants (version date 2026-03-01), article 6.1 III; Bancontact Pro Developer Portal, Payouts, Bulking and Remittance Information (052025), Remittance Information", "rests_on": "rule" } ], "exceptions": [ "A Bancontact card in Apple Pay, confirmed with Face ID or Touch ID, is not held to the usual contactless limits.", "The card-level limits are set by each issuer [Inference]." ], "applies_to": "Bancontact in Belgium, in euro: Bancontact card payments at terminals and online, Mobile Bancontact Transactions in the Bancontact Pay app (person to merchant and person to person), and Bancontact Pro payments settled by Bancontact or by Wero", "caveat": "The app-level figures were not read (the FAQ answers did not load), and the 50 euro figure rests on the operator's consumer page alone [Unverified].", "related": [ "sepa-sct-inst:limits", "bancontact:decision-points" ], "basis": { "sources": "App T&C article 6.2.3; Bancontact card page; Merchant T&C articles 6.2, 6.6 and 9.3.2; read 2026-09-19.", "confidence": "medium" }, "currency": { "effective_since": "2026-03-01", "effective_to": null, "effective_note": "The date is the version date of the Merchant T&C and the start of App T&C version 8.0; the 50 euro contactless figure is undated. When any limit first applied was not traced [Unverified].", "source_edition": "Merchant T&C version date 2026-03-01; Bancontact Pay App T&C version 8.0; the scheme's May 2014 SEPA compliance answer; bancontact.com pages; Bancontact Pro developer guides versioned 052025; Stripe and Adyen Bancontact pages; all read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://assets-us-01.kc-usercontent.com:443/0d76cd9b-cf9d-007c-62ee-e50e20111691/062432ac-5aee-4723-9e6d-1d6ac7e97dac/260301%20-%20T_C%20Bancontact%20Pay%20ENG.pdf", "source_class": "authoritative_primary", "source_title": "Bancontact Pay App Terms and Conditions, version 8.0", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms app-level limits apply on top of card limits with the lower prevailing, article 6.2.3." }, { "source_url": "https://www.bancontact.com/en/consumer/bancontact-card", "source_class": "public_primary", "source_title": "Bancontact, Bancontact card", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms the operator's own statement that contactless needs no PIN up to 50 euro, flagged in the record as resting on this one source." }, { "source_url": "https://assets-us-01.kc-usercontent.com:443/0d76cd9b-cf9d-007c-62ee-e50e20111691/461a17b0-b853-4420-838c-4732627c1de0/260129%20Merchant%20T_C%20ENG%20-%20FINAL.pdf", "source_class": "authoritative_primary", "source_title": "Bancontact Company, General Terms and Conditions, Merchants (version date 2026-03-01)", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms the merchant minimum and maximum restriction, restricted business activities, and the negative-balance refund refusal, articles 6.2, 6.6 and 9.3.2." } ] }, "rail_name": "Bancontact (Belgian debit card scheme and Bancontact Pro)", "governing_authority": "Bancontact Company SA/NV (card scheme rules, not public; Bancontact Pro and Bancontact Pay terms, public)", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "bancontact:messages", "id": "messages", "rail": "bancontact", "kind": "rail-fact", "facet": "messages", "name": "What messages and codes does Bancontact use?", "statement": "Orca found no public payment reason code list. The Bancontact Pro APIs report ten payment statuses, four intermediary and six final, and thirteen common error codes with HTTP status codes; these describe the integration, not bank returns, so they live here and not in a code directory. Refund and reconciliation data are signed with JSON Web Signatures, payouts and refunds carry remittance information within the EPC's 140 characters, and the API URLs changed from 2026-05-11 when the Payconiq brand was retired. Payouts themselves are SEPA credit transfers.", "details": [ { "label": "Ten payment statuses; a final status never changes", "value": "Bancontact's public APIs report a payment in one of ten statuses, in create, get and search responses and in callbacks. Four are intermediary: PENDING (created, not yet started by the payer), IDENTIFIED (the payer has interacted, for example scanned the QR code), AUTHORIZED (passed first checks) and PENDING_MERCHANT_AKNOWLEDGMENT (confirmed by the payer and waiting for the merchant, void service only). Six are final: SUCCEEDED, AUTHORIZATION_FAILED (declined on the bank side, for instance funds or card limits), FAILED (technical or logical error), CANCELLED, EXPIRED (not completed in time) and VOIDED (void service only). Once final, a status does not change.", "citation": "Bancontact Pro Developer Portal, API Errors, Statuses, and Responses (052025), Payment Statuses", "rests_on": "rule" }, { "label": "API error codes and how to react to them", "value": "The APIs answer with conventional HTTP codes (200, 201, 204; 400, 401, 403, 404, 409, 422, 429, 500, 503) and, on error, a body with a code, a message, a traceId and a spanId. Thirteen common error codes cover authentication and access (UNAUTHORIZED, ACCESS_DENIED), missing records (PAYMENT_NOT_FOUND, REFUND_NOT_FOUND), request form (BODY_MISSING, FIELD_REQUIRED), payment state (PAYMENT_NOT_PENDING, PAYMENT_CONFLICT, CALLER_NOT_ALLOWED_TO_CANCEL, QR_NO_LONGER_IN_USE), a failed payout to the merchant (UNABLE_TO_PAY_CREDITOR) and temporary failures (TECHNICAL_ERROR, TRY_AGAIN_LATER). The guide advises fixing the request on a 4xx, retrying with exponential backoff on a 5xx and honouring 429 rate limits. These are integration errors, not reasons a bank gives for a returned payment, so Orca holds no code directory for them.", "citation": "Bancontact Pro Developer Portal, API Errors, Statuses, and Responses (052025), HTTP Status Codes; Error Response Structure; Common Error Codes; Best Practices; Bancontact Pro Developer Portal, Refunds (052025), Get Refund IBAN, error codes", "rests_on": "rule" }, { "label": "API keys and JSON Web Signatures", "value": "A merchant or its integrator integrates with an API key issued in the Merchant Portal, which Bancontact Company may also give the integrator directly. Refund and reconciliation data are secured with JSON Web Signatures, for which the two sides exchange JSON Web Key Set endpoints; the create refund call needs a signature and separate activation.", "citation": "Bancontact Company, General Terms and Conditions, Merchants (version date 2026-03-01), article 1, definitions of API Key(s), Digital signatures and JSON Web Key Sets; Bancontact Company, General Terms and Conditions, Merchants (version date 2026-03-01), article 5.1; Bancontact Pro Developer Portal, Refunds (052025), Introduction", "rests_on": "rule" }, { "label": "Remittance information on payouts and refunds within 140 characters", "value": "Payouts and API refunds carry remittance information within the 140 character limit set by the European Payments Council. A bulked payout's text identifies the merchant, the bulk payout, the date the bulk period began, the merchant's Bulk ID (or NONE) and a fixed bulk reconciliation marker. An individual payout carries the merchant name, the payment ID, a description, the merchant's reference and the issuing entity, or structured remittance for the invoice product. A refund names the merchant's reference, the merchant, the refund ID and a description. The texts still use the Payconiq-era name in places.", "citation": "Bancontact Pro Developer Portal, Payouts, Bulking and Remittance Information (052025), Remittance Information", "rests_on": "rule" }, { "label": "New API URLs after the Payconiq brand was retired", "value": "With the Payconiq brand decommissioned in Belgium, Bancontact Company changed its API URLs to the Bancontact Pro identity. The change was in pre-production first and in production from 2026-05-11; integrators had to adapt to keep accepting Bancontact Pay and Wero payments.", "citation": "Bancontact Pro Developer Portal, API Errors, Statuses, and Responses (052025), notice at the top of the guide", "rests_on": "rule" } ], "exceptions": [ "The refunds guide uses REFUND_NOT_AVAILABLE, which the common error list does not name." ], "applies_to": "Bancontact in Belgium, in euro: Bancontact card payments at terminals and online, Mobile Bancontact Transactions in the Bancontact Pay app (person to merchant and person to person), and Bancontact Pro payments settled by Bancontact or by Wero", "caveat": "Status names are spelled as the publisher spells them, including PENDING_MERCHANT_AKNOWLEDGMENT.", "related": [ "sepa-sct:messages", "bancontact:refund" ], "basis": { "sources": "Errors and statuses, refunds and payouts guides (052025); Merchant T&C articles 1 and 5.1; read 2026-09-19.", "confidence": "high" }, "currency": { "effective_since": "2026-03-01", "effective_to": null, "effective_note": "Drafted 2026-09-19 in Orca Core form. The date is the version date of the Merchant T&C and the start date of App T&C version 8.0; lines from the 2014 scheme answer, the developer guides and processors carry their own dates in their Rules.", "source_edition": "Merchant T&C version date 2026-03-01; Bancontact Pay App T&C version 8.0; the scheme's May 2014 SEPA compliance answer; bancontact.com pages; Bancontact Pro developer guides versioned 052025; Stripe and Adyen Bancontact pages; all read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://docs.bancontactpro.com/guides/general/errorsandstatuses052025", "source_class": "authoritative_primary", "source_title": "Bancontact Pro Developer Portal, API Errors, Statuses, and Responses (052025)", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms the ten payment statuses and thirteen common error codes described here as the integration's messages, not bank return reasons." }, { "source_url": "https://assets-us-01.kc-usercontent.com:443/0d76cd9b-cf9d-007c-62ee-e50e20111691/461a17b0-b853-4420-838c-4732627c1de0/260129%20Merchant%20T_C%20ENG%20-%20FINAL.pdf", "source_class": "authoritative_primary", "source_title": "Bancontact Company, General Terms and Conditions, Merchants (version date 2026-03-01)", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms JSON Web Signatures secure refund and reconciliation data, article 1 and article 5.1." } ] }, "rail_name": "Bancontact (Belgian debit card scheme and Bancontact Pro)", "governing_authority": "Bancontact Company SA/NV (card scheme rules, not public; Bancontact Pro and Bancontact Pay terms, public)", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "bancontact:participants", "id": "participants", "rail": "bancontact", "kind": "rail-fact", "facet": "participants", "name": "Who takes part in Bancontact, and in what role?", "statement": "Three things share the name. The Bancontact card scheme, whose rules Bancontact Company writes and does not publish, joins issuers and acquirers; in 2014 membership was open to any payment service provider with separate issuing and acquiring licences. The Bancontact Pay app lets a user register up to five cards and authenticate card payments, with person to person receipt for private use only. Bancontact Pro is Bancontact Company's own acceptance service: one QR code or link paid by Wero first or Bancontact, with MultiSafepay as acquirer of the Bancontact leg, EPI as Wero's scheme manager and merchants registered in the EU acting for their own account. Bancontact Company is a payment institution supervised by the National Bank of Belgium. Many Bancontact cards are co-badged with another network.", "details": [ { "label": "Bancontact Pro: one QR code or link, Wero first, Bancontact as fallback", "value": "Bancontact Pro lets a merchant take a payment through a single QR code or payment link that the payer can settle with more than one mobile solution. The terms put Wero first and Bancontact where Wero is not possible; which one is used depends on what the payer's chosen app supports. The operator's merchant page presents it as accepting both Bancontact and Wero, through the Bancontact Pay app and the main bank apps.", "citation": "Bancontact Company, General Terms and Conditions, Merchants (version date 2026-03-01), article 1, definitions of Acceptance Service, Bancontact and Wero; Bancontact Company, General Terms and Conditions, Merchants (version date 2026-03-01), article 7.1; Bancontact, What is Bancontact Pro, introduction and feature list", "rests_on": "rule" }, { "label": "Who runs Bancontact Pro and who acquires its Bancontact leg", "value": "Bancontact Company, a Belgian payment institution supervised by the National Bank of Belgium, contracts with Bancontact Pro merchants. It in turn contracts a Bancontact scheme member as acquirer for Bancontact payments; the edition of 2026-03-01 names MultiSafepay B.V., a Dutch payment institution supervised by De Nederlandsche Bank. EPI is Wero's scheme manager. Bancontact Company may assign the agreement to a third party with the merchant's advance consent.", "citation": "Bancontact Company, General Terms and Conditions, Merchants (version date 2026-03-01), article 1, definitions of Acquirer, BC and EPI; Bancontact Company, General Terms and Conditions, Merchants (version date 2026-03-01), article 17.1; Bancontact, About us, company statement on supervision", "rests_on": "rule" }, { "label": "Who may be a Bancontact Pro merchant", "value": "A merchant must pass Bancontact Company's know-your-merchant and anti-money laundering checks: it gives the information and documents asked for, keeps them current, and its beneficial owners and representatives may not be on sanctions lists or resident in high-risk countries. It needs a registered address in an EU country where Bancontact Company is licensed, EU billing and payout IBANs, and shops in Belgium or such a country, and it must act for its own account, never collecting for third parties. Bancontact Company may decline or suspend the agreement if information is missing.", "citation": "Bancontact Company, General Terms and Conditions, Merchants (version date 2026-03-01), article 2.2; Bancontact Company, General Terms and Conditions, Merchants (version date 2026-03-01), article 6.1 I, II and VI to IX; Bancontact Company, General Terms and Conditions, Merchants (version date 2026-03-01), article 6.3", "rests_on": "rule" }, { "label": "Card scheme: membership and licences", "value": "In 2014 the scheme said membership was open on the same criteria to any payment service provider under the Payment Services Directive, not only banks and payment institutions, that members chose their licences freely (issuing, ATM acquiring, point of sale acquiring and others), that one licence covered SEPA, and that no member had to use a particular processor. Its fees manual went to members and, under a non-disclosure agreement, to candidates; its fall-back interchange fees were public.", "citation": "Response of the Bancontact/Mister Cash Card Scheme to the Eurosystem questionnaire on SEPA compliance of card schemes (May 2014), questions 11 to 15, 19 a and 21.1; Bancontact, Legal and administrative specifications, fall-back interchange and service fees", "rests_on": "guidance" }, { "label": "App: up to five cards, person to person for private use only", "value": "A user may register up to five Bancontact cards, from several issuers, in the Bancontact Pay app, one of them the default. Receiving person to person payments is allowed only to individuals acting privately, not for business. The app is offered in the app stores of EU member states, and a user must keep an accurate personal account. The operator also reaches payers through bank apps that integrate Bancontact.", "citation": "Bancontact Pay App Terms and Conditions, version 8.0, articles 5, 6.1.1, 6.1.2 and 6.2.1; Bancontact, About us, Bancontact Pay brand description", "rests_on": "rule" }, { "label": "Display the Bancontact Pro brands on equal terms", "value": "A Bancontact Pro merchant must show the acceptance marks prominently in the shop or online, following the operator's brand instructions, which may change after a month's notice. The brands may not be treated worse than other accepted payment methods: same size, colour, position and prominence.", "citation": "Bancontact Company, General Terms and Conditions, Merchants (version date 2026-03-01), article 6.5", "rests_on": "rule" }, { "label": "Co-badged Bancontact cards can run on the other scheme", "value": "Many Bancontact cards carry a second brand: from early 2021 a major Belgian bank issued cards co-badged with Visa Debit in place of Maestro [Inference: Maestro is Mastercard's debit brand, which the page does not say]. Such a card can be taken in the Bancontact card flow or as a generic card on the other scheme, and the cardholder should be able to choose. A payment routed to Visa or Mastercard follows that network's rules, including its chargebacks, not Bancontact's [Inference].", "citation": "Adyen Docs, Issues processing co-badged Bancontact cards, introduction; which transactions are impacted; routing issues; Adyen Docs, Bancontact card, introduction, co-badged cards", "rests_on": "rule" } ], "exceptions": [ "The acquirer named in the Merchant T&C is dated to the edition of 2026-03-01 and may change.", "The developer portal and remittance texts still say Bancontact Payconiq Company." ], "applies_to": "Bancontact in Belgium, in euro: Bancontact card payments at terminals and online, Mobile Bancontact Transactions in the Bancontact Pay app (person to merchant and person to person), and Bancontact Pro payments settled by Bancontact or by Wero", "caveat": "Payconiq was a brand of the same operator, not a separate scheme [Inference]; Wero is EPI's scheme, not Bancontact's.", "related": [ "sepa-sct-inst:participants", "visa:participants", "mastercard:participants" ], "basis": { "sources": "Merchant T&C articles 1, 2.2, 6.1, 6.5 and 17.1; App T&C articles 5 and 6; SCF response questions 11 to 15 (May 2014); About us, What is Bancontact Pro and legal specifications pages; Adyen co-badged cards page; read 2026-09-19.", "confidence": "medium" }, "currency": { "effective_since": "2026-03-01", "effective_to": null, "effective_note": "Drafted 2026-09-19 in Orca Core form. The date is the version date of the Merchant T&C and the start date of App T&C version 8.0; lines from the 2014 scheme answer, the developer guides and processors carry their own dates in their Rules.", "source_edition": "Merchant T&C version date 2026-03-01; Bancontact Pay App T&C version 8.0; the scheme's May 2014 SEPA compliance answer; bancontact.com pages; Bancontact Pro developer guides versioned 052025; Stripe and Adyen Bancontact pages; all read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://assets-us-01.kc-usercontent.com:443/0d76cd9b-cf9d-007c-62ee-e50e20111691/461a17b0-b853-4420-838c-4732627c1de0/260129%20Merchant%20T_C%20ENG%20-%20FINAL.pdf", "source_class": "authoritative_primary", "source_title": "Bancontact Company, General Terms and Conditions, Merchants (version date 2026-03-01)", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms MultiSafepay as acquirer, EPI as Wero's scheme manager, and the merchant eligibility and own-account duty, articles 1, 2.2, 6.1, 6.5 and 17.1." } ] }, "rail_name": "Bancontact (Belgian debit card scheme and Bancontact Pro)", "governing_authority": "Bancontact Company SA/NV (card scheme rules, not public; Bancontact Pro and Bancontact Pay terms, public)", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "bancontact:recall", "id": "recall", "rail": "bancontact", "kind": "rail-fact", "facet": "recall", "name": "Can a payer or merchant pull a Bancontact payment back?", "statement": "The app terms give a payer no way to recall a Mobile Bancontact Transaction once confirmed; questions go to the card issuer. A Bancontact Pro merchant that uses the void service can hold bulked funds and cancel a payment before confirming it, within 168 hours of its creation, and Bancontact Company then tries to return the money to the payer. After that the merchant's only path is a refund. A Wero payment's recall between banks follows SEPA Instant.", "details": [ { "label": "Void service: funds held up to 168 hours", "value": "A merchant that activates the void service and integrates the Void API has its bulked payments held by Bancontact Company until it confirms or cancels each one, or until 168 hours after the payment was created in Bancontact Company's systems. Confirmation makes the payment SUCCEEDED. A cancellation, or the time-out, voids it: Bancontact Company makes reasonable efforts to return the money to the payer and confirms the void to the merchant.", "citation": "Bancontact Company, General Terms and Conditions, Merchants (version date 2026-03-01), article 9.2; Bancontact Pro Developer Portal, API Errors, Statuses, and Responses (052025), Payment Statuses, PENDING_MERCHANT_AKNOWLEDGMENT and VOIDED", "rests_on": "rule" }, { "label": "The app terms give the payer no way to recall a payment", "value": "Nothing in the Bancontact Pay App T&C lets a payer cancel or recall a Mobile Bancontact Transaction once confirmed with the Mobile PIN or biometrics: the confirmation is the payer's signature and the transaction is binding. Questions and complaints about a transaction go to the card issuer, whose own terms govern it.", "citation": "Bancontact Pay App Terms and Conditions, version 8.0, articles 6.2.1, 6.2.2, 6.2.4 and 21", "rests_on": "rule" }, { "label": "The Wero leg is a SEPA instant credit transfer under EPI's scheme", "value": "A Wero payment accepted through Bancontact Pro is a SEPA instant credit transfer from the payer's bank to Bancontact Company, under Wero's scheme manager EPI. Its execution, finality between banks, amount limits, hours and the payer's rights against its own bank are therefore those of SEPA Instant Credit Transfer and of payment services law, not Bancontact's [Inference from the definition of Wero]. What Bancontact Company adds by contract is the payout, the chargeback and representment handling, and the void and refund services.", "citation": "Bancontact Company, General Terms and Conditions, Merchants (version date 2026-03-01), article 1, definitions of Wero, EPI and Acceptance Service; Bancontact Company, General Terms and Conditions, Merchants (version date 2026-03-01), article 6.1 III; Bancontact Pro Developer Portal, Payouts, Bulking and Remittance Information (052025), Remittance Information", "rests_on": "rule" } ], "exceptions": [ "A payment the merchant does not confirm within 168 hours is voided automatically." ], "applies_to": "Bancontact in Belgium, in euro: Bancontact card payments at terminals and online, Mobile Bancontact Transactions in the Bancontact Pay app (person to merchant and person to person), and Bancontact Pro payments settled by Bancontact or by Wero", "caveat": "That no payer recall exists is inferred from the app terms read in full; issuers' terms were not read [Inference].", "related": [ "sepa-sct-inst:recall", "bancontact:refund" ], "basis": { "sources": "Merchant T&C article 9.2; App T&C articles 6.2 and 21; errors and statuses guide; read 2026-09-19.", "confidence": "medium" }, "currency": { "effective_since": "2026-03-01", "effective_to": null, "effective_note": "Drafted 2026-09-19 in Orca Core form. The date is the version date of the Merchant T&C and the start date of App T&C version 8.0; lines from the 2014 scheme answer, the developer guides and processors carry their own dates in their Rules.", "source_edition": "Merchant T&C version date 2026-03-01; Bancontact Pay App T&C version 8.0; the scheme's May 2014 SEPA compliance answer; bancontact.com pages; Bancontact Pro developer guides versioned 052025; Stripe and Adyen Bancontact pages; all read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://assets-us-01.kc-usercontent.com:443/0d76cd9b-cf9d-007c-62ee-e50e20111691/461a17b0-b853-4420-838c-4732627c1de0/260129%20Merchant%20T_C%20ENG%20-%20FINAL.pdf", "source_class": "authoritative_primary", "source_title": "Bancontact Company, General Terms and Conditions, Merchants (version date 2026-03-01)", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms the void service's 168-hour hold and Bancontact Company's attempt to return funds after cancellation or time-out, article 9.2." }, { "source_url": "https://assets-us-01.kc-usercontent.com:443/0d76cd9b-cf9d-007c-62ee-e50e20111691/062432ac-5aee-4723-9e6d-1d6ac7e97dac/260301%20-%20T_C%20Bancontact%20Pay%20ENG.pdf", "source_class": "authoritative_primary", "source_title": "Bancontact Pay App Terms and Conditions, version 8.0", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms the app terms describe no payer recall mechanism, and that transaction complaints go to the card issuer, articles 6.2 and 21." } ] }, "rail_name": "Bancontact (Belgian debit card scheme and Bancontact Pro)", "governing_authority": "Bancontact Company SA/NV (card scheme rules, not public; Bancontact Pro and Bancontact Pay terms, public)", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "bancontact:refund", "id": "refund", "rail": "bancontact", "kind": "rail-fact", "facet": "refund", "name": "How does a merchant refund a Bancontact Pro payment?", "statement": "Through the Refund API, fully or partly and for any reason, for a SUCCEEDED, bulked payment created within the last year, once JSON Web Signatures are in place and the endpoint is activated. Refunds are netted from the day's payout and declined if they would make the bulking period's balance negative. The API can look up the payer's IBAN, except for person to person payments. Merchants that restrict refunds must say so before payment.", "details": [ { "label": "When a merchant may refund through the API", "value": "A merchant may refund a payment through the Refund API only if its payments are bulked, it has implemented JSON Web Signatures, and Bancontact Company's support has activated the create refund endpoint. The payment must be SUCCEEDED and created no more than one year before; the refund may be full or partial and needs no reason. The merchant sets an idempotency key per refund: the same key when retrying after a 4xx or 5xx error, a new one for a deliberate second refund of the same payment.", "citation": "Bancontact Company, General Terms and Conditions, Merchants (version date 2026-03-01), article 1, definition of Refund; Bancontact Company, General Terms and Conditions, Merchants (version date 2026-03-01), articles 9.3.1 to 9.3.3; Bancontact Pro Developer Portal, Refunds (052025), Introduction; Create Refund", "rests_on": "rule" }, { "label": "Refunds come out of the day's payout and fail on a negative balance", "value": "Bancontact Company keeps a running balance per bulking period of succeeded payments less refunds. The day's refunds are deducted from the day's payments and only the net is paid out; a refund that would push the balance of the current period below zero is declined.", "citation": "Bancontact Company, General Terms and Conditions, Merchants (version date 2026-03-01), article 9.3.2; Bancontact Pro Developer Portal, Refunds (052025), Introduction", "rests_on": "rule" }, { "label": "Looking up the payer's IBAN for a refund", "value": "The API can return the IBAN of the payer of an original payment, for refund processing, checks or audit; the call moves no money and needs only the API key. It is refused for a person to person payment or where the payer's details are not available.", "citation": "Bancontact Pro Developer Portal, Refunds (052025), Get Refund IBAN", "rests_on": "rule" }, { "label": "Disclose return, refund and cancellation limits before payment", "value": "If a merchant restricts returns, refunds or cancellations, it must say so before the payer pays: in store by telling the payer, online through a linked policy or text in the checkout that the consumer actively acknowledges, such as by ticking a box. An online merchant's site must also show how to reach its customer service, its privacy policy, any restrictive refund and cancellation policy, and its registered address.", "citation": "Bancontact Company, General Terms and Conditions, Merchants (version date 2026-03-01), article 6.1 V; Bancontact Company, General Terms and Conditions, Merchants (version date 2026-03-01), article 6.7", "rests_on": "rule" } ], "exceptions": [ "A payment older than one year cannot be refunded through the API.", "Individual payout merchants and non-bulked payments cannot use the Refund API under the terms." ], "applies_to": "Bancontact in Belgium, in euro: Bancontact card payments at terminals and online, Mobile Bancontact Transactions in the Bancontact Pay app (person to merchant and person to person), and Bancontact Pro payments settled by Bancontact or by Wero", "caveat": "A processor such as Stripe may allow a different refund window for Bancontact payments it acquires; that is the processor's term, not the operator's.", "related": [ "bancontact:recall", "sepa-sct-inst:refund" ], "basis": { "sources": "Merchant T&C articles 1, 6.7 and 9.3; refunds guide; read 2026-09-19.", "confidence": "high" }, "currency": { "effective_since": "2026-03-01", "effective_to": null, "effective_note": "Drafted 2026-09-19 in Orca Core form. The date is the version date of the Merchant T&C and the start date of App T&C version 8.0; lines from the 2014 scheme answer, the developer guides and processors carry their own dates in their Rules.", "source_edition": "Merchant T&C version date 2026-03-01; Bancontact Pay App T&C version 8.0; the scheme's May 2014 SEPA compliance answer; bancontact.com pages; Bancontact Pro developer guides versioned 052025; Stripe and Adyen Bancontact pages; all read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://assets-us-01.kc-usercontent.com:443/0d76cd9b-cf9d-007c-62ee-e50e20111691/461a17b0-b853-4420-838c-4732627c1de0/260129%20Merchant%20T_C%20ENG%20-%20FINAL.pdf", "source_class": "authoritative_primary", "source_title": "Bancontact Company, General Terms and Conditions, Merchants (version date 2026-03-01)", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms the refund definition, the pre-payment disclosure duty, and the refund conditions, articles 1, 6.7 and 9.3." }, { "source_url": "https://docs.bancontactpro.com/guides/general/refunds052025", "source_class": "authoritative_primary", "source_title": "Bancontact Pro Developer Portal, Refunds (052025)", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms the refund API's conditions, the IBAN lookup and its P2P exclusion." } ] }, "rail_name": "Bancontact (Belgian debit card scheme and Bancontact Pro)", "governing_authority": "Bancontact Company SA/NV (card scheme rules, not public; Bancontact Pro and Bancontact Pay terms, public)", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "bancontact:return", "id": "return", "rail": "bancontact", "kind": "rail-fact", "facet": "return", "name": "Can a Bancontact payment be charged back or sent back?", "statement": "It depends on the leg. The Merchant T&C say a Bancontact payment cannot be charged back, and Stripe and Adyen list no chargebacks for Bancontact card and app payments online. A Wero payment through Bancontact Pro can be: the payer's bank raises it under EPI's rules, the merchant owes the amount at once plus a fee, and Bancontact Company decides whether to contest it with a representment, with the merchant's evidence due within 15 days. A payer's claim that a Wero payment was not authorised is outside that route.", "details": [ { "label": "The Bancontact leg of Bancontact Pro cannot be charged back", "value": "In the Merchant T&C only a Wero payment can be charged back; the definition of chargeback says in terms that a Bancontact payment cannot be. A dispute over a Bancontact payment therefore has no chargeback route through Bancontact Company.", "citation": "Bancontact Company, General Terms and Conditions, Merchants (version date 2026-03-01), article 1, definition of Chargeback; Bancontact Company, General Terms and Conditions, Merchants (version date 2026-03-01), article 8", "rests_on": "rule" }, { "label": "Processors: Bancontact card and app payments have no chargebacks", "value": "Two processors that acquire Bancontact online say it has no dispute path that ends in a chargeback: Stripe lists dispute support as no and explains that the payer authenticates with the bank, and Adyen's feature table marks chargebacks as not supported for Bancontact card and Bancontact mobile payments. Neither is the scheme's own text, which is not public; nothing read covers card payments at a terminal. The operator's own merchant terms say the same for the Bancontact leg of Bancontact Pro.", "citation": "Stripe Docs, Bancontact payments, payment method properties; Disputes; Adyen Docs, Bancontact card, feature table, Chargebacks column", "rests_on": "rule" }, { "label": "Wero payments can be charged back for any dispute except an unauthorised one", "value": "When a payer disputes a settled Wero payment, for example a debit taken twice or for the wrong amount, or goods that never came or were not as described, the payer's bank may raise a chargeback under EPI's rules. Bancontact Company credits the payer's bank and the merchant owes the amount as soon as the chargeback arrives: Bancontact Company may net the day's chargebacks from that day's payments, carry a negative balance to later working days until incoming payments cover it, or send a payment request instead. Each chargeback also costs the merchant a fee that is not refunded, and Bancontact Company may recover chargebacks and fees after the agreement ends, for as long as EPI's rules allow chargebacks on payments made during it. The merchant must keep chargeback risk low.", "citation": "Bancontact Company, General Terms and Conditions, Merchants (version date 2026-03-01), article 1, definition of Chargeback; Bancontact Company, General Terms and Conditions, Merchants (version date 2026-03-01), article 7.5; Bancontact Company, General Terms and Conditions, Merchants (version date 2026-03-01), article 8", "rests_on": "rule" }, { "label": "Representment: Bancontact Company decides, the merchant has 15 days to send evidence", "value": "The merchant never starts a chargeback or a representment itself. After a chargeback Bancontact Company examines the case and decides whether it can contest it with a representment; it may ask the merchant for more evidence, which the merchant must provide promptly and within 15 days at most. Once Bancontact Company sends a representment to the payer's bank, it owes the merchant the amount, which by default is added to that working day's payout.", "citation": "Bancontact Company, General Terms and Conditions, Merchants (version date 2026-03-01), article 1, definition of Representment; Bancontact Company, General Terms and Conditions, Merchants (version date 2026-03-01), article 7.5", "rests_on": "rule" }, { "label": "A payer's claim of no authorisation is not a Wero chargeback", "value": "The Merchant T&C carve out one kind of dispute from the Wero chargeback route: a payer saying the payment was never authorised. Such a claim is for the payer's bank to handle with its customer under payment services law [Inference: the terms do not say where it goes].", "citation": "Bancontact Company, General Terms and Conditions, Merchants (version date 2026-03-01), article 8", "rests_on": "rule" }, { "label": "Co-badged Bancontact cards can run on the other scheme", "value": "Many Bancontact cards carry a second brand: from early 2021 a major Belgian bank issued cards co-badged with Visa Debit in place of Maestro [Inference: Maestro is Mastercard's debit brand, which the page does not say]. Such a card can be taken in the Bancontact card flow or as a generic card on the other scheme, and the cardholder should be able to choose. A payment routed to Visa or Mastercard follows that network's rules, including its chargebacks, not Bancontact's [Inference].", "citation": "Adyen Docs, Issues processing co-badged Bancontact cards, introduction; which transactions are impacted; routing issues; Adyen Docs, Bancontact card, introduction, co-badged cards", "rests_on": "rule" } ], "exceptions": [ "A co-badged Bancontact card processed as Visa or Mastercard follows that network's dispute rules [Inference].", "Chargebacks on Wero payments can still arrive after the merchant agreement ends, within EPI's window." ], "applies_to": "Bancontact in Belgium, in euro: Bancontact card payments at terminals and online, Mobile Bancontact Transactions in the Bancontact Pay app (person to merchant and person to person), and Bancontact Pro payments settled by Bancontact or by Wero", "caveat": "EPI's chargeback windows and grounds were not read; whether the card scheme gives any dispute right for payments at a terminal is not public.", "related": [ "sepa-sct-inst:return", "visa:return", "mastercard:return", "bancontact:finality" ], "basis": { "sources": "Merchant T&C articles 1, 7.5 and 8; Stripe and Adyen Bancontact pages; Adyen co-badged cards page; read 2026-09-19.", "confidence": "medium" }, "currency": { "effective_since": "2026-03-01", "effective_to": null, "effective_note": "Drafted 2026-09-19 in Orca Core form. The date is the version date of the Merchant T&C and the start date of App T&C version 8.0; lines from the 2014 scheme answer, the developer guides and processors carry their own dates in their Rules.", "source_edition": "Merchant T&C version date 2026-03-01; Bancontact Pay App T&C version 8.0; the scheme's May 2014 SEPA compliance answer; bancontact.com pages; Bancontact Pro developer guides versioned 052025; Stripe and Adyen Bancontact pages; all read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://assets-us-01.kc-usercontent.com:443/0d76cd9b-cf9d-007c-62ee-e50e20111691/461a17b0-b853-4420-838c-4732627c1de0/260129%20Merchant%20T_C%20ENG%20-%20FINAL.pdf", "source_class": "authoritative_primary", "source_title": "Bancontact Company, General Terms and Conditions, Merchants (version date 2026-03-01)", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms the Bancontact leg cannot be charged back, the Wero chargeback and representment process, and the unauthorised-claim carve-out, articles 1, 7.5 and 8." } ] }, "rail_name": "Bancontact (Belgian debit card scheme and Bancontact Pro)", "governing_authority": "Bancontact Company SA/NV (card scheme rules, not public; Bancontact Pro and Bancontact Pay terms, public)", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "bancontact:settlement", "id": "settlement", "rail": "bancontact", "kind": "rail-fact", "facet": "settlement", "name": "How and when does money reach the merchant?", "statement": "Under Bancontact Pro the payer's bank pays each successful payment into Bancontact Company's segregated account, and Bancontact Company pays the merchant by SEPA credit transfer: by default in one bulk per closing-time period on the next Belgian working day, net of refunds, chargebacks and representments, or one transfer per payment for the invoice product. The Wero leg itself settles between banks as a SEPA instant credit transfer. For card payments the scheme said in 2014 that authorisation, clearing and settlement may run on different providers and that it offers its own outsourced service; the current settlement model is not public.", "details": [ { "label": "The payer's bank pays Bancontact Company, which keeps the funds apart", "value": "Under Bancontact Pro only payments the payer's bank approves are credited to the merchant. Each successful payment is paid by the payer's bank into a Bancontact Company account, held separately from Bancontact Company's own money; the payouts guide describes it as a credit transfer from the consumer's account to a segregated account. The merchant reconciles through a report from the API or the Merchant Portal.", "citation": "Bancontact Company, General Terms and Conditions, Merchants (version date 2026-03-01), article 7.2.1; Bancontact Pro Developer Portal, Payouts, Bulking and Remittance Information (052025), Remittance Information", "rests_on": "rule" }, { "label": "Bulked payout by SEPA credit transfer on the next working day", "value": "Unless agreed otherwise, Bancontact Company pays merchants in bulk: everything that succeeded in the 24 hours following each bulk closing time is sent by SEPA credit transfer to the Payout IBAN on the following Belgian working day. Refunds, chargebacks and representments of the same working day are netted into the same payout. Payments are grouped into a payout by a bulk instruction made of the merchant's company ID, Payout IBAN and closing time, plus a Bulk ID if the merchant sets one per payment. Bancontact Company may change the payout frequency after notice.", "citation": "Bancontact Company, General Terms and Conditions, Merchants (version date 2026-03-01), article 1, definitions of Bulk Instruction and Working Day; Bancontact Company, General Terms and Conditions, Merchants (version date 2026-03-01), article 7.4; Bancontact Pro Developer Portal, Payouts, Bulking and Remittance Information (052025), Payouts; Payment Bulking", "rests_on": "rule" }, { "label": "Individual payouts, and the invoice product", "value": "A merchant may instead be paid one SEPA credit transfer per SUCCEEDED payment, sent straight away. Bulking is the default for all merchants except the invoice product, which supports only individual payouts and usually carries structured remittance information passed in the payment's reference.", "citation": "Bancontact Pro Developer Portal, Payouts, Bulking and Remittance Information (052025), Payouts; Individual Payout Remittance Information", "rests_on": "rule" }, { "label": "The Wero leg is a SEPA instant credit transfer under EPI's scheme", "value": "A Wero payment accepted through Bancontact Pro is a SEPA instant credit transfer from the payer's bank to Bancontact Company, under Wero's scheme manager EPI. Its execution, finality between banks, amount limits, hours and the payer's rights against its own bank are therefore those of SEPA Instant Credit Transfer and of payment services law, not Bancontact's [Inference from the definition of Wero]. What Bancontact Company adds by contract is the payout, the chargeback and representment handling, and the void and refund services.", "citation": "Bancontact Company, General Terms and Conditions, Merchants (version date 2026-03-01), article 1, definitions of Wero, EPI and Acceptance Service; Bancontact Company, General Terms and Conditions, Merchants (version date 2026-03-01), article 6.1 III; Bancontact Pro Developer Portal, Payouts, Bulking and Remittance Information (052025), Remittance Information", "rests_on": "rule" }, { "label": "Card scheme: authorisation, clearing and settlement may run on different providers", "value": "In its 2014 answer the scheme said that its brand governance is separate from processing, that authorisation, clearing and settlement can be done by different systems and providers, and that to keep every member reachable it offers its own authorisation, clearing and settlement service, outsourced to a third party. It had built a scheme switch, independent of issuing and acquiring processors, so new processors could connect, and a member need not use any particular processor. How and when card transactions settle between members today is not public.", "citation": "Response of the Bancontact/Mister Cash Card Scheme to the Eurosystem questionnaire on SEPA compliance of card schemes (May 2014), questions 6 a, 9 a and 15", "rests_on": "guidance" } ], "exceptions": [ "Bancontact Company may change the payout frequency after notice.", "A negative balance after chargebacks stops the payout and carries forward until later payments cover it." ], "applies_to": "Bancontact in Belgium, in euro: Bancontact card payments at terminals and online, Mobile Bancontact Transactions in the Bancontact Pay app (person to merchant and person to person), and Bancontact Pro payments settled by Bancontact or by Wero", "caveat": "A SUCCEEDED status means Bancontact Company owes the merchant; the money itself arrives with the next payout, later over weekends.", "related": [ "sepa-sct:settlement", "sepa-sct-inst:settlement", "bancontact:hours" ], "basis": { "sources": "Merchant T&C articles 7.2.1 and 7.4; payouts guide; SCF response questions 6 a, 9 a and 15 (May 2014); read 2026-09-19.", "confidence": "medium" }, "currency": { "effective_since": "2026-03-01", "effective_to": null, "effective_note": "Drafted 2026-09-19 in Orca Core form. The date is the version date of the Merchant T&C and the start date of App T&C version 8.0; lines from the 2014 scheme answer, the developer guides and processors carry their own dates in their Rules.", "source_edition": "Merchant T&C version date 2026-03-01; Bancontact Pay App T&C version 8.0; the scheme's May 2014 SEPA compliance answer; bancontact.com pages; Bancontact Pro developer guides versioned 052025; Stripe and Adyen Bancontact pages; all read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://assets-us-01.kc-usercontent.com:443/0d76cd9b-cf9d-007c-62ee-e50e20111691/461a17b0-b853-4420-838c-4732627c1de0/260129%20Merchant%20T_C%20ENG%20-%20FINAL.pdf", "source_class": "authoritative_primary", "source_title": "Bancontact Company, General Terms and Conditions, Merchants (version date 2026-03-01)", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms the payer bank credits Bancontact Company's segregated account and Bancontact Company bulks payouts by SEPA credit transfer, articles 7.2.1 and 7.4." }, { "source_url": "https://docs.bancontactpro.com/guides/general/payoutremittance052025", "source_class": "authoritative_primary", "source_title": "Bancontact Pro Developer Portal, Payouts, Bulking and Remittance Information (052025)", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms the default bulked payout the working day after, and the individual payout option for the invoice product." } ] }, "rail_name": "Bancontact (Belgian debit card scheme and Bancontact Pro)", "governing_authority": "Bancontact Company SA/NV (card scheme rules, not public; Bancontact Pro and Bancontact Pay terms, public)", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "blik:consumer-law", "id": "consumer-law", "rail": "blik", "kind": "rail-fact", "facet": "consumer-law", "name": "How does BLIK relate to consumer protection law?", "statement": "The BLIK scheme is a payment scheme under the Payment Services Act and the BLIK system a payment system under the Settlement Finality Act. Toward the user the issuer is the payment service provider and the acquirer only intermediates, so users complain to the bank whose app they used. For recurring payments the user sees every consent in the app and can delete it there, though that may not end the contract with the merchant.", "details": [ { "label": "The issuer is the user's payment service provider", "value": "The BLIK scheme is a payment scheme under the Payment Services Act of 19 August 2011 and the BLIK system a payment system under the Settlement Finality Act of 24 August 2001, both run by PSP. Toward the user, the payment service (making the payment instrument available and executing transactions) is the issuer's; the acquirer only takes part as an intermediary. The user's statutory rights therefore run against the issuer [Inference: the Act itself was not read].", "citation": "Regulamin Systemu Płatności Mobilnych BLIK, single-session edition approved 15 April 2026, §1.1; §3.11; §28.1", "rests_on": "rule" }, { "label": "Users complain to their own bank", "value": "PSP tells users to complain about a BLIK transaction, including contactless and recurring ones, to the bank whose app they used, since that bank holds the transaction details and can act. PSP itself deals only with participants.", "citation": "BLIK FAQ (blik.com/faq), where to complain", "rests_on": "guidance" }, { "label": "Recurring payment: consent started at the merchant, confirmed in the bank app", "value": "A BLIK recurring payment is the user's consent for a merchant to start later transactions. The user starts it in the merchant's site or app, typically by choosing BLIK recurring payment and entering a BLIK code, and confirms it in the banking app, which shows the merchant, amount, frequency and expiry. Setting it up charges nothing by itself; each later charge is a separate recurring transaction, though the first charge may be taken at set-up. The rulebook's definition of a merchant already covers one that starts a BLIK transaction under authority the user gave it earlier.", "citation": "BLIK Recurring Payments: Introduction, Recurring Payment and Recurring Transaction; BLIK Recurring Payments: Model A, how it works; information displayed in the banking app; Regulamin Systemu Płatności Mobilnych BLIK, single-session edition approved 15 April 2026, §2 (definition of Akceptant a, second indent)", "rests_on": "rule" }, { "label": "Recurring payment: the user sees and cancels it in the bank app", "value": "The user can see every recurring payment in the banking app, including whether it charges automatically or needs confirmation, and can cancel one by deleting it there. Deleting it stops BLIK charges but does not necessarily end the user's contract with the merchant. A recurring payment does not move with the user to another bank; it has to be set up again there.", "citation": "BLIK Recurring Payments: Introduction, Recurring Payment; BLIK FAQ (blik.com/faq), recurring payment questions", "rests_on": "guidance" } ], "exceptions": [ "The Acts themselves were not read; any statutory right stated here is [Inference] from the rulebook's references." ], "applies_to": "BLIK in Poland, in PLN: code payments, cash, refunds to the user, contactless BLIK-C, phone transfers and transfer requests, and recurring payments, among PSP's participants", "caveat": "Read this as who the user deals with, not as a statement of the user's statutory rights.", "related": [ "mastercard:consumer-law", "blik:liability" ], "basis": { "sources": "BLIK rulebook §1.1, §3.11 and §28.1; BLIK FAQ; recurring payments introduction page; read 2026-09-19.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the rulebook edition read does not say when each provision took effect", "effective_to": null, "effective_note": "Drafted 2026-09-19 in Orca Core form from the BLIK rulebook editions approved on 15 April 2026 and PSP's public pages. The rulebook prints no effective date, so when each provision first applied is [Unverified].", "source_edition": "BLIK rulebook single-session and multi-session editions approved 15 April 2026; BLIK FAQ and recurring payments pages; Express Elixir rulebook 1.91; Stripe and Adyen BLIK pages; all read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.blik.com/download/pobierz/regulamin", "source_class": "authoritative_primary", "source_title": "Regulamin Systemu Płatności Mobilnych BLIK, single-session edition approved 15 April 2026", "checked_on": "2026-09-19", "checked_by": "blik-validator-2026-09-19", "notes": "Confirms BLIK is a payment scheme under the Payment Services Act and a payment system under the Settlement Finality Act, and that the issuer, not the acquirer, is the party providing the payment service to the user." }, { "source_url": "https://www.blik.com/faq", "source_class": "public_primary", "source_title": "BLIK FAQ (blik.com/faq)", "checked_on": "2026-09-19", "checked_by": "blik-validator-2026-09-19", "notes": "Confirms users complain to the bank whose app they used." }, { "source_url": "https://www.blik.com/lp/reccuring-payments/Introduction.141951041.html", "source_class": "authoritative_primary", "source_title": "BLIK Recurring Payments: Introduction", "checked_on": "2026-09-19", "checked_by": "blik-validator-2026-09-19", "notes": "Confirms the user sees and can cancel every recurring payment consent in the banking app." } ] }, "rail_name": "BLIK", "governing_authority": "Polski Standard Płatności S.A. (PSP)", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "blik:decision-points", "id": "decision-points", "rail": "blik", "kind": "rail-fact", "facet": "decision-points", "name": "Where do BLIK's rules leave a decision to a person or an institution?", "statement": "The issuer decides each authorisation and may ignore an acquirer's hint to skip user confirmation. PSP decides before the issuer on fraud monitoring and gambling blocks, decides who is at fault in complaints, and may block, suspend or exclude participants on stated triggers. For recurring payments the bank retries for 72 hours after a shortfall unless the merchant sets NODELAY, and PSP recommends 24 hours between manual retries.", "details": [ { "label": "The issuer decides; an acquirer's no-confirmation hint is only advice", "value": "Whether a BLIK transaction can go ahead is the issuer's decision. At an acquirer's request PSP may let it send issuers a recommendation to authorise without asking the user to confirm in the app; the issuer may ignore it, and the acquirer using it must put measures in place against unauthorised transactions.", "citation": "Regulamin Systemu Płatności Mobilnych BLIK, single-session edition approved 15 April 2026, §11.3 e; §11.7", "rests_on": "rule" }, { "label": "PSP rejects on fraud monitoring and blocks illegal gambling domains", "value": "PSP's system itself stops two kinds of transaction before the issuer decides. It rejects one when PSP's monitoring shows the participant would refuse it because fraud is likely. It halts, and never sends to the issuer, a payment for a service offered through a domain on Poland's register of domains offering gambling unlawfully; that block does not relieve participants of their own legal duties on gambling payments. PSP monitors BLIK transactions for rule breaches, unauthorised use and fraud under the Payment Services Act, alongside the participants' own monitoring.", "citation": "Regulamin Systemu Płatności Mobilnych BLIK, single-session edition approved 15 April 2026, §5.1 q; §5.2; §14.2 to §14.4", "rests_on": "rule" }, { "label": "In a complaint the party at fault pays, PSP decides doubt, silence means fault", "value": "When a complaint carries a concrete claim by a user, institutional user, merchant or participant that arose because PSP or a participant broke its obligations, that party bears the cost of the claim. PSP tells the participants involved who caused the event and the account into which that participant must transfer the claimed amount. PSP resolves any doubt over who is responsible. A participant that does not answer a complaint within the deadline in the complaints procedure is treated as accepting that it was at fault.", "citation": "Regulamin Systemu Płatności Mobilnych BLIK, single-session edition approved 15 April 2026, §9.5 to §9.7", "rests_on": "rule" }, { "label": "PSP may block a participant temporarily", "value": "PSP may cut a participant off from BLIK for a time on three kinds of ground. Conduct: a breach of PSP's security rules, behaviour that endangers BLIK's continuity, or a finding PSP asked it to fix still open after the deadline. Faulty traffic: messages in a format the Technical Specification does not allow, or messages BLIK does not expect at that stage of a transaction. Failure at scale: no timely answer to any authorisation request sent in the last 15 minutes, or refusals making up half or more of its authorisation answers where neither the user nor PSP caused them. Once the participant e-mails PSP that the cause is removed, the block is lifted.", "citation": "Regulamin Systemu Płatności Mobilnych BLIK, single-session edition approved 15 April 2026, §21", "rests_on": "rule" }, { "label": "Suspension and exclusion of a participant", "value": "PSP starts excluding a participant, beginning with a suspension that stops all its BLIK transactions, when the financial supervisor (KNF) or another authority suspends it, when the settlement guarantee is triggered by an issuer's lack of funds, or when it persistently breaks the rules; after a month it is excluded unless it has cured the cause. An issuer whose current account at NBP is closed is suspended that day and excluded after a month unless it opens another NBP settlement account, and indirect participants depending on it follow. For other breaches PSP first sends a written warning with a date to fix, then may suspend a function, suspend the participant or exclude it. PSP tells all participants and NBP of its decisions. Suspending a participant as issuer does not suspend it as acquirer, or the other way round.", "citation": "Regulamin Systemu Płatności Mobilnych BLIK, single-session edition approved 15 April 2026, §17 to §19", "rests_on": "rule" }, { "label": "Recurring transaction short of funds: 72 hours of bank retries", "value": "When a recurring transaction cannot be authorised because funds are short or a limit is exceeded, the bank has the next 72 hours to tell the user why and ask for funds or a limit change, and tries again to authorise; if the problem remains it declines. In models A and O the merchant can skip that period with the NODELAY flag, and the transaction is marked unsuccessful at once; the merchant may then retry manually, and PSP recommends leaving 24 hours between attempts. PSP's FAQ adds that a recurring payment not made for lack of funds may be retried by the bank or the merchant.", "citation": "BLIK Recurring Payments: Introduction, unsuccessful recurring transactions; NODELAY flag; BLIK FAQ (blik.com/faq), no money on the account when a recurring payment is due", "rests_on": "guidance" } ], "exceptions": [ "The criteria for fraud rejection and the complaint deadlines are in non-public annexes." ], "applies_to": "BLIK in Poland, in PLN: code payments, cash, refunds to the user, contactless BLIK-C, phone transfers and transfer requests, and recurring payments, among PSP's participants", "caveat": "Orca's reading of where judgment lies; the non-public annexes may narrow it.", "related": [ "blik:limits" ], "basis": { "sources": "BLIK rulebook §9.6, §11.7, §14, §17 to §21; recurring payments introduction page; read 2026-09-19.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the rulebook edition read does not say when each provision took effect", "effective_to": null, "effective_note": "Drafted 2026-09-19 in Orca Core form from the BLIK rulebook editions approved on 15 April 2026 and PSP's public pages. The rulebook prints no effective date, so when each provision first applied is [Unverified].", "source_edition": "BLIK rulebook single-session and multi-session editions approved 15 April 2026; BLIK FAQ and recurring payments pages; Express Elixir rulebook 1.91; Stripe and Adyen BLIK pages; all read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.blik.com/download/pobierz/regulamin", "source_class": "authoritative_primary", "source_title": "Regulamin Systemu Płatności Mobilnych BLIK, single-session edition approved 15 April 2026", "checked_on": "2026-09-19", "checked_by": "blik-validator-2026-09-19", "notes": "Confirms the synthesis: the issuer decides each authorisation and may ignore an acquirer's no-confirmation hint, PSP decides ahead of the issuer on fraud and gambling blocks and decides complaint fault, and PSP's temporary block and suspension or exclusion triggers." }, { "source_url": "https://www.blik.com/lp/reccuring-payments/Introduction.141951041.html", "source_class": "authoritative_primary", "source_title": "BLIK Recurring Payments: Introduction", "checked_on": "2026-09-19", "checked_by": "blik-validator-2026-09-19", "notes": "Confirms the bank's 72 hour retry period after a shortfall unless the merchant sets NODELAY, and PSP's recommended 24 hour interval between manual merchant retries." } ] }, "rail_name": "BLIK", "governing_authority": "Polski Standard Płatności S.A. (PSP)", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "blik:finality", "id": "finality", "rail": "blik", "kind": "rail-fact", "facet": "finality", "name": "When is a BLIK payment final, and can it be undone?", "statement": "A BLIK payment is fixed the moment the user's bank authorises it: the authorisation is irrevocable, nobody can withdraw the order, and PSP's registration of the positive answer is the settlement order that later settles in SORBNET3 and that the rulebook places under the Settlement Finality Act. What the user sees as instant is the bank's commitment; the money between banks moves in the next net settlement on a business day. The only ways back are a separate refund, a cancellation or correction for a technical error within 13 months, or a complaint. Phone transfers sent over Express Elixir follow KIR's rule instead: irrevocable once KIR registers them.", "details": [ { "label": "When a BLIK order is in and when it can no longer be withdrawn", "value": "A BLIK transaction order counts as entered into PSP's system as soon as the BLIK code and the transaction data reach PSP. Once the issuer authorises it, the authorisation is irrevocable: neither a participant nor anyone else can withdraw the order. By authorising a transaction that goes to clearing, the issuer takes on the duty to pay the acquirer, or Mastercard for BLIK-C, through the BLIK system; for a transfer to the user's account the duty runs the other way, from the acquirer to the issuer. Issuer and acquirer must both keep a durable record of every authorisation decision.", "citation": "Regulamin Systemu Płatności Mobilnych BLIK, single-session edition approved 15 April 2026, §12.1 to §12.3", "rests_on": "rule" }, { "label": "The settlement order is entered and fixed at positive authorisation", "value": "The moment PSP's system registers the issuer's positive authorisation is the moment the settlement order enters the BLIK system; for an indirect participant, the order counts as entered by the direct participant that settles for it. From then on the settlement order cannot be revoked. The payment orders PSP later places in SORBNET3 on participants' behalf have the effect of settlement orders under the Settlement Finality Act (article 1 point 12), which is what protects them in an insolvency.", "citation": "Regulamin Systemu Płatności Mobilnych BLIK, single-session edition approved 15 April 2026, §29.2 to §29.4; §31.3", "rests_on": "rule" }, { "label": "Phone transfers over Express Elixir: irrevocable once entered", "value": "When a BLIK phone transfer or accepted transfer request goes through Express Elixir, KIR's rules govern that leg: the order is entered when KIR's designated computer registers it and cannot be revoked after that; the receiving bank's authorisation is an irrevocable commitment to credit the payee as soon as it gets the settlement information. A transfer booked inside one bank, or settled in the BLIK system, does not pass through Express Elixir.", "citation": "Regulamin systemu Express Elixir, wersja 1.91, §18.1, §18.2, §18.6; Regulamin Systemu Płatności Mobilnych BLIK, single-session edition approved 15 April 2026, §23.1 c; §23.2 d", "rests_on": "rule" }, { "label": "Cancellation or correction within 13 months", "value": "After the issuer has authorised a mobile transaction, PSP or the acquirer may cancel it when a technical error occurred. A mobile transaction can be cancelled or corrected for 13 months from the day it was authorised. Corrections of amounts under complaint are made by PSP under the non-public complaints procedure. There is no recall by the user.", "citation": "Regulamin Systemu Płatności Mobilnych BLIK, single-session edition approved 15 April 2026, §10; §12.4; §12.5", "rests_on": "rule" } ], "exceptions": [ "BLIK-C runs on Mastercard's network as well; whether Mastercard's own finality and chargeback rules reach a BLIK-C payment is not stated in the BLIK rulebook [Unverified].", "A phone transfer booked inside one bank never enters Express Elixir or BLIK settlement; its finality is that bank's own [Inference]." ], "applies_to": "BLIK in Poland, in PLN: code payments, cash, refunds to the user, contactless BLIK-C, phone transfers and transfer requests, and recurring payments, among PSP's participants", "caveat": "Do not read BLIK as instant settlement. Authorisation is real time and irrevocable, but interbank settlement of code payments is deferred and net, and only a phone transfer over Express Elixir is an instant credit transfer.", "related": [ "mastercard:finality", "blik:settlement", "blik:recall" ], "basis": { "sources": "BLIK rulebook §12, §29 and §31.3; Express Elixir rulebook 1.91 §18; read 2026-09-19.", "confidence": "high" }, "currency": { "effective_since": "Unknown: the rulebook edition read does not say when each provision took effect", "effective_to": null, "effective_note": "Drafted 2026-09-19 in Orca Core form from the BLIK rulebook editions approved on 15 April 2026 and PSP's public pages. The rulebook prints no effective date, so when each provision first applied is [Unverified].", "source_edition": "BLIK rulebook single-session and multi-session editions approved 15 April 2026; BLIK FAQ and recurring payments pages; Express Elixir rulebook 1.91; Stripe and Adyen BLIK pages; all read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.blik.com/download/pobierz/regulamin", "source_class": "authoritative_primary", "source_title": "Regulamin Systemu Płatności Mobilnych BLIK, single-session edition approved 15 April 2026", "checked_on": "2026-09-19", "checked_by": "blik-validator-2026-09-19", "notes": "Confirms the synthesis: authorisation is irrevocable and fixes the payment, PSP's registered positive authorisation is the settlement order under the Settlement Finality Act, interbank movement happens in the next net settlement, and the only ways back are refund, cancellation or correction within 13 months, or a complaint." }, { "source_url": "https://www.kir.pl/storage/file/core_files/2026/2/2/0d257c823cd5118be54ea9aaef7b2858/Regulamin%20systemu%20Express%20Elixir%20wersja%201.91_sig.pdf", "source_class": "authoritative_primary", "source_title": "Regulamin systemu Express Elixir, wersja 1.91", "checked_on": "2026-09-19", "checked_by": "blik-validator-2026-09-19", "notes": "Confirms that phone transfers routed over Express Elixir follow KIR's own irrevocability rule, fixed once KIR registers the order, distinct from BLIK's own finality rule." } ] }, "rail_name": "BLIK", "governing_authority": "Polski Standard Płatności S.A. (PSP)", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "blik:hours", "id": "hours", "rail": "blik", "kind": "rail-fact", "facet": "hours", "name": "When can BLIK be used, and how long do codes and approvals last?", "statement": "Users can pay with BLIK at any hour of any day except planned technical breaks, which PSP must announce at least five days ahead; transaction time is PSP's system time. Settlement runs only on Polish business days. PSP says a one-time code is valid for 2 minutes; how long the user then has to approve in the app is not in any public PSP text, and processors give different figures.", "details": [ { "label": "The scheme runs around the clock", "value": "The BLIK scheme works every day of the year, around the clock, apart from planned technical breaks, and users may start transactions whenever it is running. For registering a transaction the date and time of PSP's system count. Settlement is different: it runs only on Polish business days.", "citation": "Regulamin Systemu Płatności Mobilnych BLIK, single-session edition approved 15 April 2026, §3.1; §3.3; §15; §31.5", "rests_on": "rule" }, { "label": "Notice of planned breaks and failures", "value": "PSP must announce planned technical unavailability of the BLIK system at least five days ahead and report failures without delay. Participants owe PSP the same: five days' notice of planned maintenance of their own systems, and prompt word when a failure starts and when it is fixed.", "citation": "Regulamin Systemu Płatności Mobilnych BLIK, single-session edition approved 15 April 2026, §6 g, h; §7.1 d, e", "rests_on": "rule" }, { "label": "How long a one-time BLIK code lives", "value": "The rulebook leaves a one-time code's validity to the non-public Technical Specification. PSP's own FAQ tells users a code is valid for 2 minutes; Stripe also says 2 minutes and Adyen 120 seconds. A code serves one transaction only, and PSP generates and manages codes centrally.", "citation": "Regulamin Systemu Płatności Mobilnych BLIK, single-session edition approved 15 April 2026, §2 (definition of Kod Jednorazowy); §6 i; BLIK FAQ (blik.com/faq), is BLIK safe; Stripe Docs: BLIK payments, overview; Adyen Docs: BLIK, shopper flow, BLIK with code", "rests_on": "guidance" }, { "label": "Time the user has to approve in the app: processors disagree", "value": "No PSP document read states how long the user has to confirm a code payment in the banking app. Two processors state different figures: Stripe says 60 seconds from the start of the payment, after which the user needs a new code; Adyen says 45 seconds. Treat both as the processor's own description, not a BLIK rule.", "citation": "Stripe Docs: BLIK payments, overview; Adyen Docs: BLIK, shopper flow, BLIK with code", "rests_on": "practice" } ], "exceptions": [ "Express Elixir, which carries most phone transfers, also runs around the clock including holidays, per KIR's page." ], "applies_to": "BLIK in Poland, in PLN: code payments, cash, refunds to the user, contactless BLIK-C, phone transfers and transfer requests, and recurring payments, among PSP's participants", "caveat": "The code life and approval window come from PSP's FAQ and processors, not from rule text; the rulebook leaves them to the non-public Technical Specification.", "related": [ "blik:settlement" ], "basis": { "sources": "BLIK rulebook §3.1, §3.3, §6, §7.1, §15 and §31.5; BLIK FAQ; Stripe and Adyen pages; read 2026-09-19.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the rulebook edition read does not say when each provision took effect", "effective_to": null, "effective_note": "Drafted 2026-09-19 in Orca Core form from the BLIK rulebook editions approved on 15 April 2026 and PSP's public pages. The rulebook prints no effective date, so when each provision first applied is [Unverified].", "source_edition": "BLIK rulebook single-session and multi-session editions approved 15 April 2026; BLIK FAQ and recurring payments pages; Express Elixir rulebook 1.91; Stripe and Adyen BLIK pages; all read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.blik.com/download/pobierz/regulamin", "source_class": "authoritative_primary", "source_title": "Regulamin Systemu Płatności Mobilnych BLIK, single-session edition approved 15 April 2026", "checked_on": "2026-09-19", "checked_by": "blik-validator-2026-09-19", "notes": "Confirms the synthesis: continuous operation apart from announced planned breaks, PSP system time for transaction timing, and settlement restricted to Polish business days." }, { "source_url": "https://www.blik.com/faq", "source_class": "public_primary", "source_title": "BLIK FAQ (blik.com/faq)", "checked_on": "2026-09-19", "checked_by": "blik-validator-2026-09-19", "notes": "Confirms PSP's public statement that a one-time code is valid for 2 minutes, and that the user approval window itself is not stated in any PSP text read." } ] }, "rail_name": "BLIK", "governing_authority": "Polski Standard Płatności S.A. (PSP)", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "blik:liability", "id": "liability", "rail": "blik", "kind": "rail-fact", "facet": "liability", "name": "Who bears the loss on a BLIK payment that goes wrong?", "statement": "Each party bears the consequences of its own breach. The acquirer answers for bad-faith or criminal transactions that it or its merchants entered, including intrusions into their systems; the issuer for those its users entered or that came through its systems or app. In a complaint the party at fault pays, PSP decides doubt, and silence past the deadline counts as accepting fault. Issuers report unauthorised transactions to PSP within two business days, PSP alerts a participant whose complaint rate passes 3 percent, issuers jointly guarantee settlement, and cash-deposit acquirers and Kasa Krajowa post security deposits.", "details": [ { "label": "Who answers for bad-faith, criminal or intruder transactions", "value": "The acquirer answers to other participants and PSP for BLIK transactions that it or its merchant put into PSP's system in bad faith or through a crime, including unauthorised acts of third parties in the acquirer's or merchant's systems. The issuer answers in the same way for such transactions put in by itself or its users, including intrusions into its systems or its mobile app. Every participant must work to reduce users' and other participants' exposure to crime, and answers for subcontractors as for itself.", "citation": "Regulamin Systemu Płatności Mobilnych BLIK, single-session edition approved 15 April 2026, §7.4; §8.2 to §8.4", "rests_on": "rule" }, { "label": "In a complaint the party at fault pays, PSP decides doubt, silence means fault", "value": "When a complaint carries a concrete claim by a user, institutional user, merchant or participant that arose because PSP or a participant broke its obligations, that party bears the cost of the claim. PSP tells the participants involved who caused the event and the account into which that participant must transfer the claimed amount. PSP resolves any doubt over who is responsible. A participant that does not answer a complaint within the deadline in the complaints procedure is treated as accepting that it was at fault.", "citation": "Regulamin Systemu Płatności Mobilnych BLIK, single-session edition approved 15 April 2026, §9.5 to §9.7", "rests_on": "rule" }, { "label": "Goods and services disputes stay between user and merchant", "value": "PSP and each participant answer only for their own failure to follow the participation agreement or the rulebook. None of them answers for whether the merchant delivered, or delivered what was agreed; such claims are settled directly between the user and the merchant. Whatever PSP does as a result of a complaint leaves that relationship untouched and is no proof that the user took part in the transaction or received anything from it.", "citation": "Regulamin Systemu Płatności Mobilnych BLIK, single-session edition approved 15 April 2026, §8.1; §9.9", "rests_on": "rule" }, { "label": "Issuers report unauthorised transactions within two business days", "value": "Each issuer must run a procedure to monitor unauthorised BLIK transactions, meaning transactions started by someone not entitled to, and report each case it identifies to PSP within two business days. It must also warn users about the risks of paying online and with mobile apps. PSP reports unauthorised transactions to NBP and other authorities as the law requires.", "citation": "Regulamin Systemu Płatności Mobilnych BLIK, single-session edition approved 15 April 2026, §7.2 o, p; §24.4", "rests_on": "rule" }, { "label": "Alert when complaints pass 3 percent", "value": "PSP alerts a participant when complaints about mobile transactions for reasons on that participant's side exceed 3 percent of its BLIK transactions of the last 30 days, and number at least 50. Other alerts cover a ready settlement report, a guarantee run caused by an issuer's shortfall, and events the Technical Specification lists.", "citation": "Regulamin Systemu Płatności Mobilnych BLIK, single-session edition approved 15 April 2026, §20", "rests_on": "rule" }, { "label": "Settlement guarantee among issuers", "value": "If an issuer lacks funds on its NBP account in the main settlement run, or in a first reserve run held after technical errors, every BLIK order in that run is withdrawn and the run does not settle. PSP blocks the short issuer (and with it the secured acquirers and indirect participants that settle through it) and tells NBP. The other issuers stand behind the shortfall: PSP recomputes settlement with their obligations raised by a formula in a non-public procedure and settles in a reserve run. If that also fails, nothing settles through SORBNET3; issuers instead pay acquirers, Mastercard and each other bilaterally on PSP's instructions, and NBP is told. The issuer that caused it must promptly repay the others with statutory interest.", "citation": "Regulamin Systemu Płatności Mobilnych BLIK, single-session edition approved 15 April 2026, §3.10; §7.2 e, f; §31.11 to §31.16", "rests_on": "rule" }, { "label": "Security deposits: cash-deposit acquirers and Kasa Krajowa", "value": "Two participants post cash with PSP against what they may owe. An acquirer that takes BLIK cash deposits outside its own issuing network without a securing issuer keeps a deposit worth twice its average daily volume of settled withdrawals for the first three full months, then twice its average daily settled deposits, never below 400,000 PLN; PSP computes it by the fifth day of each month, notifies it by the seventh, may draw on it to cover what the acquirer owes issuers or PSP after bilateral settlement, and the acquirer tops it up within one business day after a draw or within three business days of a shortfall notice. Kasa Krajowa (the national credit union bank) keeps a deposit worth five times the average daily value of settled transactions from its apps in the prior month, 100,000 PLN until the first full month after connection, paid within three business days of connection and before it may transact. Failing to fund either lets PSP act under §19.", "citation": "Regulamin Systemu Płatności Mobilnych BLIK, single-session edition approved 15 April 2026, §7¹; §7²", "rests_on": "rule" } ], "exceptions": [ "The user's own liability for unauthorised payments comes from the Payment Services Act through the issuer, which Orca has not read [Unverified]." ], "applies_to": "BLIK in Poland, in PLN: code payments, cash, refunds to the user, contactless BLIK-C, phone transfers and transfer requests, and recurring payments, among PSP's participants", "caveat": "This is liability between PSP and participants; it says nothing directly about what a consumer can recover from their bank.", "related": [ "mastercard:liability", "blik:consumer-law", "blik:return" ], "basis": { "sources": "BLIK rulebook §7¹, §7², §7.2 o, §8, §9.5 to §9.7, §20 and §31.11 to §31.15; read 2026-09-19.", "confidence": "high" }, "currency": { "effective_since": "Unknown: the rulebook edition read does not say when each provision took effect", "effective_to": null, "effective_note": "Drafted 2026-09-19 in Orca Core form from the BLIK rulebook editions approved on 15 April 2026 and PSP's public pages. The rulebook prints no effective date, so when each provision first applied is [Unverified].", "source_edition": "BLIK rulebook single-session and multi-session editions approved 15 April 2026; BLIK FAQ and recurring payments pages; Express Elixir rulebook 1.91; Stripe and Adyen BLIK pages; all read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.blik.com/download/pobierz/regulamin", "source_class": "authoritative_primary", "source_title": "Regulamin Systemu Płatności Mobilnych BLIK, single-session edition approved 15 April 2026", "checked_on": "2026-09-19", "checked_by": "blik-validator-2026-09-19", "notes": "Confirms the synthesis: each party answers for its own breach, bad-faith or criminal liability follows the acquirer or issuer whose merchant or user caused it, the fault-pays complaint rule, the two business day unauthorised transaction report, the 3 percent alert threshold, the settlement guarantee, and the security deposit duties." } ] }, "rail_name": "BLIK", "governing_authority": "Polski Standard Płatności S.A. (PSP)", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "blik:limits", "id": "limits", "rail": "blik", "kind": "rail-fact", "facet": "limits", "name": "What amount limits apply to a BLIK payment?", "statement": "The scheme has a per-transaction limit, and PSP rejects anything above it, but the figure is in the non-public Technical Specification. In practice each bank sets its users' amount and count limits, and PSP's FAQ says payments and withdrawals above 50 PLN also need the user's PIN unless the bank lets users manage that. PSP also stops payments flagged by its fraud monitoring and payments to listed illegal gambling domains. A phone transfer over Express Elixir may not exceed 100,000 PLN.", "details": [ { "label": "Scheme per-transaction limit: set, but not public", "value": "To contain operational risk, a participant may send for authorisation only transactions up to the single-transaction limit the Technical Specification sets, and PSP's system rejects a larger one with an error code. The figure and the code are in the non-public specification.", "citation": "Regulamin Systemu Płatności Mobilnych BLIK, single-session edition approved 15 April 2026, §13; §14.1", "rests_on": "rule" }, { "label": "Each bank sets its users' BLIK limits", "value": "Amount and count limits for BLIK are set by each bank for its own users, including limits for contactless BLIK; whether recurring transactions count toward them also depends on the bank.", "citation": "BLIK FAQ (blik.com/faq), whether BLIK works the same in every bank; contactless limits; recurring payment limits", "rests_on": "guidance" }, { "label": "PIN confirmation above 50 PLN", "value": "PSP's FAQ says ATM withdrawals, online payments and in-store payments above 50 PLN must also be confirmed with the user's PIN, unless the bank lets its customers manage that limit themselves.", "citation": "BLIK FAQ (blik.com/faq), is BLIK safe", "rests_on": "guidance" }, { "label": "PSP rejects on fraud monitoring and blocks illegal gambling domains", "value": "PSP's system itself stops two kinds of transaction before the issuer decides. It rejects one when PSP's monitoring shows the participant would refuse it because fraud is likely. It halts, and never sends to the issuer, a payment for a service offered through a domain on Poland's register of domains offering gambling unlawfully; that block does not relieve participants of their own legal duties on gambling payments. PSP monitors BLIK transactions for rule breaches, unauthorised use and fraud under the Payment Services Act, alongside the participants' own monitoring.", "citation": "Regulamin Systemu Płatności Mobilnych BLIK, single-session edition approved 15 April 2026, §5.1 q; §5.2; §14.2 to §14.4", "rests_on": "rule" }, { "label": "Phone transfers over Express Elixir: 100,000 PLN per transfer", "value": "An Express Elixir payment order with the MP2P code, the code BLIK phone transfers use, may not exceed the system transaction limit of 100,000 PLN. Each bank also sets its own transaction limit per order code, which may not go above that ceiling.", "citation": "Regulamin systemu Express Elixir, wersja 1.91, definitions 14, 15 and 36; Express Elixir, KIR page for banks, limits paragraph", "rests_on": "rule" } ], "exceptions": [ "The 50 PLN PIN threshold is from PSP's consumer FAQ and may be a bank practice rather than a scheme rule [Unverified]." ], "applies_to": "BLIK in Poland, in PLN: code payments, cash, refunds to the user, contactless BLIK-C, phone transfers and transfer requests, and recurring payments, among PSP's participants", "caveat": "No public source gives the scheme limit; a figure quoted by a processor or bank is that party's statement.", "related": [ "blik:decision-points" ], "basis": { "sources": "BLIK rulebook §5.1 q, §13 and §14; BLIK FAQ; Express Elixir rulebook 1.91 definitions 14, 15 and 36; read 2026-09-19.", "confidence": "medium" }, "currency": { "effective_since": "2026-04-15", "effective_to": null, "effective_note": "The date is the approval date of the rulebook edition read; the provisions are older and when they first applied is [Unverified].", "source_edition": "BLIK rulebook single-session and multi-session editions approved 15 April 2026; BLIK FAQ and recurring payments pages; Express Elixir rulebook 1.91; Stripe and Adyen BLIK pages; all read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.blik.com/download/pobierz/regulamin", "source_class": "authoritative_primary", "source_title": "Regulamin Systemu Płatności Mobilnych BLIK, single-session edition approved 15 April 2026", "checked_on": "2026-09-19", "checked_by": "blik-validator-2026-09-19", "notes": "Confirms the synthesis: the scheme's own per-transaction limit is set but not published, PSP stops fraud-flagged and illegal-gambling-domain payments, and each bank sets its own user limits." }, { "source_url": "https://www.kir.pl/storage/file/core_files/2026/2/2/0d257c823cd5118be54ea9aaef7b2858/Regulamin%20systemu%20Express%20Elixir%20wersja%201.91_sig.pdf", "source_class": "authoritative_primary", "source_title": "Regulamin systemu Express Elixir, wersja 1.91", "checked_on": "2026-09-19", "checked_by": "blik-validator-2026-09-19", "notes": "Confirms the 100,000 PLN Express Elixir system transaction limit applying to phone transfers routed with the MP2P order code." } ] }, "rail_name": "BLIK", "governing_authority": "Polski Standard Płatności S.A. (PSP)", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "blik:messages", "id": "messages", "rail": "blik", "kind": "rail-fact", "facet": "messages", "name": "Which messages carry a BLIK payment and its outcome?", "statement": "Every BLIK transaction is authorised by the issuer on a BLIK code: a PSP-generated one-time code, a code the issuer registers from the acceptance device, a standing alias, or for contactless a Mastercard token. PSP routes the request and returns the accept or reject to the device. Phone transfers resolve the payee through PSP's alias base and travel on Express Elixir as MP2P. Recurring payments add the refuseNoPayId and NODELAY flags and the one public error code, ER_PAYID_UNHANDLED. All message formats and error codes are in PSP's non-public Technical Specification.", "details": [ { "label": "Four ways a BLIK authorisation travels", "value": "Issuers authorise every BLIK transaction with a BLIK code. With a code PSP generated, the issuer asks PSP for it on the user's request, the user types it into the acceptance device, the acquirer sends it with the transaction data to PSP, and PSP finds the mobile account and issuer and asks for authorisation. With a code the acceptance device shows, the user pulls it into the app, the issuer registers it with PSP, and the rest runs the same way. With an alias, a standing code the issuer registered, the acceptance device obtains the alias as the Technical Specification sets. For BLIK-C, PSP obtains a Mastercard token for the alias, the phone passes it to the terminal, Mastercard's tokenisation system forwards it to PSP, and the answer goes back through Mastercard. In every flow the issuer's accept or reject goes back to PSP and then to the acceptance device. Adyen's BLIK OneClick, paying without a code at a shop the user saved as trusted in the bank app, appears to use the alias flow [Inference].", "citation": "Regulamin Systemu Płatności Mobilnych BLIK, single-session edition approved 15 April 2026, §7.2 j, l, m; §11.2 to §11.6; Adyen Docs: BLIK, BLIK OneClick", "rests_on": "rule" }, { "label": "Message formats and error codes live in the Technical Specification", "value": "PSP sets the technical standards for the scheme and for communication with participants and Mastercard, checks each transaction against the Technical Specification for Participants, and tells a participant when its messages do not conform. Message formats, error codes, code validity and the transaction limit are in that specification, Annex 3 to the rulebook, which PSP does not publish. Participants must report doubts about a transaction to PSP at once, in the way the specification sets.", "citation": "Regulamin Systemu Płatności Mobilnych BLIK, single-session edition approved 15 April 2026, §2 (definition of Specyfikacja Techniczna dla Uczestników); §5.1 g, h, m; §6 b, c; §22; list of annexes", "rests_on": "rule" }, { "label": "How a phone transfer finds the payee", "value": "For a phone transfer the payer names an alias already linked to the payee's mobile account, plus an amount. The payer's bank asks PSP's mobile account base for the account number behind that alias; if there is none, PSP returns an error and the bank tells the payer the transfer cannot be made. With the number the bank completes the transfer and books it internally, or sends it through an instant payment system (with MP2P as service type in Express Elixir) or through the BLIK system, as the Technical Specification sets. For a transfer request the requester's bank sends the request, the requester's name and phone number, amount and optional title to PSP, which finds the payer's bank by alias and passes it on; an unknown alias again returns an error. Only issuers that can use MP2P in Express Elixir, or that settle through one that can, may offer these services.", "citation": "Regulamin Systemu Płatności Mobilnych BLIK, single-session edition approved 15 April 2026, §3.13; §23.1 to §23.3; Regulamin systemu Express Elixir, wersja 1.91, definition 15", "rests_on": "rule" }, { "label": "Recurring payment models A, M and O", "value": "PSP offers three models. In model A later transactions go through without the user confirming, for a fixed amount at a fixed frequency until an expiry the merchant must set, at most 10 years ahead; only one automatic transaction per frequency period is allowed, and a charge with another amount, or a second one in the same period, needs the user's confirmation in the app. In model M the user confirms every recurring transaction, and amounts and frequency may vary; the consent may run to a date or until cancelled. In model O transactions go through without confirmation even though amount and frequency may vary; it too may run to a date or until cancelled. Not every bank supports recurring payments, and merchants must say which do.", "citation": "BLIK Recurring Payments: Introduction, implementation models; supporting banks management; BLIK Recurring Payments: Model A, how it works; frequency; invitation data", "rests_on": "rule" }, { "label": "Recurring payment flags and the one public BLIK error code", "value": "A merchant can send refuseNoPayId set to true so BLIK rejects the transaction when the user's bank does not support recurring payments, and handle the error. Without that flag, and with such a bank, a set-up carried on a transaction above zero is shown to the user as a plain payment without the recurring invitation, while a zero-amount set-up is rejected by BLIK with error code ER_PAYID_UNHANDLED and never reaches the bank. The NODELAY flag (models A and O) skips the 72 hour retry period. Every acquirer must support both flags.", "citation": "BLIK Recurring Payments: Introduction, refuseNoPayID mechanism; NODELAY flag", "rests_on": "rule" } ], "exceptions": [ "Processors expose BLIK through their own APIs and error sets, which are not BLIK's codes." ], "applies_to": "BLIK in Poland, in PLN: code payments, cash, refunds to the user, contactless BLIK-C, phone transfers and transfer requests, and recurring payments, among PSP's participants", "caveat": "No public BLIK code list exists; Orca holds no BLIK reason code records.", "related": [ "mastercard:messages" ], "basis": { "sources": "BLIK rulebook §2, §3.13, §5.1, §6, §11, §22 and §23; recurring payments pages; Express Elixir rulebook 1.91 definition 15; Adyen page; read 2026-09-19.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the rulebook edition read does not say when each provision took effect", "effective_to": null, "effective_note": "Drafted 2026-09-19 in Orca Core form from the BLIK rulebook editions approved on 15 April 2026 and PSP's public pages. The rulebook prints no effective date, so when each provision first applied is [Unverified].", "source_edition": "BLIK rulebook single-session and multi-session editions approved 15 April 2026; BLIK FAQ and recurring payments pages; Express Elixir rulebook 1.91; Stripe and Adyen BLIK pages; all read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.blik.com/download/pobierz/regulamin", "source_class": "authoritative_primary", "source_title": "Regulamin Systemu Płatności Mobilnych BLIK, single-session edition approved 15 April 2026", "checked_on": "2026-09-19", "checked_by": "blik-validator-2026-09-19", "notes": "Confirms the synthesis: the four authorisation flows, PSP routing the accept or reject to the device, the alias-based phone transfer routing over Express Elixir as MP2P, and that all message formats and error codes sit in the non-public Technical Specification." }, { "source_url": "https://www.blik.com/lp/reccuring-payments/Introduction.141951041.html", "source_class": "authoritative_primary", "source_title": "BLIK Recurring Payments: Introduction", "checked_on": "2026-09-19", "checked_by": "blik-validator-2026-09-19", "notes": "Confirms the refuseNoPayId and NODELAY flags and the ER_PAYID_UNHANDLED error code for recurring payments." } ] }, "rail_name": "BLIK", "governing_authority": "Polski Standard Płatności S.A. (PSP)", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "blik:participants", "id": "participants", "rail": "blik", "kind": "rail-fact", "facet": "participants", "name": "Who takes part in BLIK, and in what roles?", "statement": "PSP runs both the scheme and the system. Participants are issuers, which offer BLIK in their apps, and acquirers, which connect merchants' devices; both must be EEA-based institutions entitled to operate in Poland, and issuers need SORBNET3 membership and an NBP account unless they settle indirectly. Settlement entities settle for themselves or others, Mastercard is the Cooperating Scheme for contactless BLIK, and NBP authorised the system and runs SORBNET3. PSP's FAQ lists 21 banks and institutions offering BLIK, Revolut and Kasa Krajowa among them. PSP may change the rulebook on two months' notice.", "details": [ { "label": "Who may join BLIK", "value": "Who: an institution seated in the European Economic Area and entitled to operate in Poland, of one of these kinds: bank or credit institution (or a branch of one), payment or electronic money institution including hybrid ones, small payment institution with legal personality, or Kasa Krajowa, the national credit union bank, which may take part only for credit unions' apps. Standing: not under legal restrictive measures such as sanctions, not on the financial supervisor's (KNF) public warning list, no threat to BLIK's stability, and working fraud and anti money laundering checks on users and merchants. Money: a participant account, and either its own SORBNET3 link as a settlement entity or a named settlement entity; an issuer also needs SORBNET3 membership and an NBP account, unless it settles indirectly through another issuer. Formalities: the licence its role needs (issuing, or acquiring and cash services), a signed participation agreement as issuer or acquirer, the joining fee, passed technical tests, and going live no later than 18 months after signing. Joining the scheme means joining the system too. PSP checks all this before admission, periodically and whenever a breach is suspected, and gives each participant an MID (ACQID for acquirers, ISSID for issuers).", "citation": "Regulamin Systemu Płatności Mobilnych BLIK, single-session edition approved 15 April 2026, §3.8; §4", "rests_on": "rule" }, { "label": "What issuers and acquirers must do", "value": "Issuers: give users the app or another code-based function and authenticate them in it; get one-time codes from PSP, and register with PSP the mobile accounts and any codes they create themselves; authorise only on a code PSP issued or registered; update a mobile account's status at once, for example when a user leaves; and keep sanctioned persons out. Acquirers: tag each merchant with an ISO merchant category code and offer BLIK only to merchants that act lawfully and ethically, are not on sanctions lists and do not use the BLIK mark misleadingly. Everyone: run BLIK and connect to it as the Technical Specification sets, submit to tests and audits, follow anti money laundering law, and promote BLIK with its mark. Securing issuers, secured acquirers and indirect participants carry extra account and funding duties, and each category must offer the functions Annex 5 marks mandatory for it.", "citation": "Regulamin Systemu Płatności Mobilnych BLIK, single-session edition approved 15 April 2026, §7.1; §7.2 h to n, q, r; §27.5", "rests_on": "rule" }, { "label": "What PSP must do as operator", "value": "PSP answers for BLIK being lawful, secure and working. Day to day it issues and registers codes, keeps the base of mobile accounts, prepares the files settlement runs on, handles complaints and triggers the settlement guarantee when needed. As rule maker it writes the security, acceptance, clearing and complaint standards, the technical and communication standards, and the terms of participation. As gatekeeper it decides who joins and which functions each participant gets, approves banking apps against uniform, non-discriminatory criteria, audits participants periodically and is itself audited.", "citation": "Regulamin Systemu Płatności Mobilnych BLIK, single-session edition approved 15 April 2026, §5.1; §6", "rests_on": "rule" }, { "label": "PSP changes the rulebook and fees on its own", "value": "PSP may amend the rulebook unilaterally; notice to participants with a two-month adjustment period makes the change effective, and a change that only grants a participant rights without affecting others may bind earlier through an annex to the participation agreement. PSP sets on its own, and may vary on objective criteria, the fees due to issuers and acquirers and the fees participants pay it. Where the participation agreement and the rulebook conflict, the rulebook wins.", "citation": "Regulamin Systemu Płatności Mobilnych BLIK, single-session edition approved 15 April 2026, §27.1 to §27.3; §27.6; §27.7; §32.1", "rests_on": "rule" }, { "label": "Where contactless BLIK is accepted", "value": "BLIK-C can be used at contactless terminals of the BLIK-C acceptance network, marked with the BLIK or the Mastercard mark, in Poland or abroad. PSP's FAQ says any terminal that takes Mastercard contactless payments will do, the slip may read MASTERCARD CONTACTLESS, and a merchant abroad may offer to charge in złoty, in which case the terminal should show the rate. No payment card is needed, only the bank app on an Android phone with NFC.", "citation": "Regulamin Systemu Płatności Mobilnych BLIK, single-session edition approved 15 April 2026, §2 (definition of Sieć Akceptacji Transakcji BLIK-C); BLIK FAQ (blik.com/faq), contactless BLIK questions", "rests_on": "rule" } ], "exceptions": [ "Kasa Krajowa takes part only for apps of credit unions." ], "applies_to": "BLIK in Poland, in PLN: code payments, cash, refunds to the user, contactless BLIK-C, phone transfers and transfer requests, and recurring payments, among PSP's participants", "caveat": "In BLIK documents PSP is the operator's name, not a payment service provider, and the acquirer's Polish name (Agent Rozliczeniowy) does not mean settlement agent.", "related": [ "mastercard:participants" ], "basis": { "sources": "BLIK rulebook §2, §3.8, §4 to §7, §27 and §32; BLIK FAQ; read 2026-09-19.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the rulebook edition read does not say when each provision took effect", "effective_to": null, "effective_note": "Drafted 2026-09-19 in Orca Core form from the BLIK rulebook editions approved on 15 April 2026 and PSP's public pages. The rulebook prints no effective date, so when each provision first applied is [Unverified].", "source_edition": "BLIK rulebook single-session and multi-session editions approved 15 April 2026; BLIK FAQ and recurring payments pages; Express Elixir rulebook 1.91; Stripe and Adyen BLIK pages; all read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.blik.com/download/pobierz/regulamin", "source_class": "authoritative_primary", "source_title": "Regulamin Systemu Płatności Mobilnych BLIK, single-session edition approved 15 April 2026", "checked_on": "2026-09-19", "checked_by": "blik-validator-2026-09-19", "notes": "Confirms the synthesis: PSP runs both scheme and system, issuer and acquirer eligibility and SORBNET3 membership requirements, settlement entities, Mastercard as Cooperating Scheme, NBP's authorisation and SORBNET3 role, and PSP's two-month notice for rulebook changes." }, { "source_url": "https://www.blik.com/faq", "source_class": "public_primary", "source_title": "BLIK FAQ (blik.com/faq)", "checked_on": "2026-09-19", "checked_by": "blik-validator-2026-09-19", "notes": "Confirms the FAQ lists 21 banks and institutions offering BLIK, including Revolut and Kasa Krajowa." } ] }, "rail_name": "BLIK", "governing_authority": "Polski Standard Płatności S.A. (PSP)", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "blik:recall", "id": "recall", "rail": "blik", "kind": "rail-fact", "facet": "recall", "name": "Can a BLIK payment be cancelled or recalled after it is sent?", "statement": "Not by the user. Once the issuer authorises, the order is irrevocable. PSP or the merchant's acquirer may cancel an authorised transaction when a technical error occurred, and a transaction may be cancelled or corrected for 13 months from authorisation.", "details": [ { "label": "When a BLIK order is in and when it can no longer be withdrawn", "value": "A BLIK transaction order counts as entered into PSP's system as soon as the BLIK code and the transaction data reach PSP. Once the issuer authorises it, the authorisation is irrevocable: neither a participant nor anyone else can withdraw the order. By authorising a transaction that goes to clearing, the issuer takes on the duty to pay the acquirer, or Mastercard for BLIK-C, through the BLIK system; for a transfer to the user's account the duty runs the other way, from the acquirer to the issuer. Issuer and acquirer must both keep a durable record of every authorisation decision.", "citation": "Regulamin Systemu Płatności Mobilnych BLIK, single-session edition approved 15 April 2026, §12.1 to §12.3", "rests_on": "rule" }, { "label": "Cancellation or correction within 13 months", "value": "After the issuer has authorised a mobile transaction, PSP or the acquirer may cancel it when a technical error occurred. A mobile transaction can be cancelled or corrected for 13 months from the day it was authorised. Corrections of amounts under complaint are made by PSP under the non-public complaints procedure. There is no recall by the user.", "citation": "Regulamin Systemu Płatności Mobilnych BLIK, single-session edition approved 15 April 2026, §10; §12.4; §12.5", "rests_on": "rule" } ], "exceptions": [ "A phone transfer sent over Express Elixir is irrevocable under KIR's rules once entered; the BLIK rulebook's cancellation right covers mobile transactions [Inference: whether it reaches the Express Elixir leg is not stated]." ], "applies_to": "BLIK in Poland, in PLN: code payments, cash, refunds to the user, contactless BLIK-C, phone transfers and transfer requests, and recurring payments, among PSP's participants", "caveat": "The 13 month window is for cancellation or correction by PSP or the acquirer, not a consumer right to recall.", "related": [ "mastercard:recall", "blik:finality" ], "basis": { "sources": "BLIK rulebook §12, read 2026-09-19.", "confidence": "high" }, "currency": { "effective_since": "Unknown: the rulebook edition read does not say when each provision took effect", "effective_to": null, "effective_note": "Drafted 2026-09-19 in Orca Core form from the BLIK rulebook editions approved on 15 April 2026 and PSP's public pages. The rulebook prints no effective date, so when each provision first applied is [Unverified].", "source_edition": "BLIK rulebook single-session and multi-session editions approved 15 April 2026; BLIK FAQ and recurring payments pages; Express Elixir rulebook 1.91; Stripe and Adyen BLIK pages; all read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.blik.com/download/pobierz/regulamin", "source_class": "authoritative_primary", "source_title": "Regulamin Systemu Płatności Mobilnych BLIK, single-session edition approved 15 April 2026", "checked_on": "2026-09-19", "checked_by": "blik-validator-2026-09-19", "notes": "Confirms the synthesis: no user recall once the issuer authorises, and that PSP or the acquirer may cancel or correct an authorised transaction for a technical error within 13 months." } ] }, "rail_name": "BLIK", "governing_authority": "Polski Standard Płatności S.A. (PSP)", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "blik:refund", "id": "refund", "rail": "blik", "kind": "rail-fact", "facet": "refund", "name": "How does a merchant refund a BLIK payment?", "statement": "By sending a refund: a separate credit transaction to the user's account through the merchant's acquirer, or through Mastercard for BLIK-C, started in the app or with the original transaction's identifier. Full and partial refunds are possible per processors. Disputes over the goods themselves stay between user and merchant; PSP and the banks answer only for their own processing, and users take complaints to their own bank.", "details": [ { "label": "Merchant refunds are new credit transactions", "value": "A merchant returns money by starting a refund to the user, a transaction type of its own that credits the user's account through the merchant's acquirer (or through Mastercard for BLIK-C), started in the app or with the original transaction's unique identifier. The acquirer owes the issuer the refunded amount through BLIK clearing. Stripe and Adyen say full and partial refunds are supported, Adyen also several partial refunds; Stripe says the bank posts them at once or within a few hours. For a contactless purchase returned in store, PSP's FAQ says the refund is usually made by tapping the same phone on the terminal.", "citation": "Regulamin Systemu Płatności Mobilnych BLIK, single-session edition approved 15 April 2026, §2 (definition of Transakcja Mobilna c); §12.2; §29.13; Stripe Docs: BLIK payments, refunds; Adyen Docs: BLIK, feature table; BLIK FAQ (blik.com/faq), returning goods paid with contactless BLIK", "rests_on": "rule" }, { "label": "Goods and services disputes stay between user and merchant", "value": "PSP and each participant answer only for their own failure to follow the participation agreement or the rulebook. None of them answers for whether the merchant delivered, or delivered what was agreed; such claims are settled directly between the user and the merchant. Whatever PSP does as a result of a complaint leaves that relationship untouched and is no proof that the user took part in the transaction or received anything from it.", "citation": "Regulamin Systemu Płatności Mobilnych BLIK, single-session edition approved 15 April 2026, §8.1; §9.9", "rests_on": "rule" }, { "label": "Users complain to their own bank", "value": "PSP tells users to complain about a BLIK transaction, including contactless and recurring ones, to the bank whose app they used, since that bank holds the transaction details and can act. PSP itself deals only with participants.", "citation": "BLIK FAQ (blik.com/faq), where to complain", "rests_on": "guidance" } ], "exceptions": [ "A BLIK-C refund joins BLIK clearing only after Mastercard reports it." ], "applies_to": "BLIK in Poland, in PLN: code payments, cash, refunds to the user, contactless BLIK-C, phone transfers and transfer requests, and recurring payments, among PSP's participants", "caveat": "A refund is a new transaction the merchant chooses to make; nothing in the rulebook obliges a merchant to refund.", "related": [ "mastercard:refund", "blik:return" ], "basis": { "sources": "BLIK rulebook §2, §8.1, §9.9, §12.2 and §29.13; BLIK FAQ; Stripe and Adyen pages; read 2026-09-19.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the rulebook edition read does not say when each provision took effect", "effective_to": null, "effective_note": "Drafted 2026-09-19 in Orca Core form from the BLIK rulebook editions approved on 15 April 2026 and PSP's public pages. The rulebook prints no effective date, so when each provision first applied is [Unverified].", "source_edition": "BLIK rulebook single-session and multi-session editions approved 15 April 2026; BLIK FAQ and recurring payments pages; Express Elixir rulebook 1.91; Stripe and Adyen BLIK pages; all read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.blik.com/download/pobierz/regulamin", "source_class": "authoritative_primary", "source_title": "Regulamin Systemu Płatności Mobilnych BLIK, single-session edition approved 15 April 2026", "checked_on": "2026-09-19", "checked_by": "blik-validator-2026-09-19", "notes": "Confirms the synthesis: a refund is a separate credit transaction through the merchant's acquirer or Mastercard, goods disputes stay outside the scheme, and users complain to their own bank." }, { "source_url": "https://www.blik.com/faq", "source_class": "public_primary", "source_title": "BLIK FAQ (blik.com/faq)", "checked_on": "2026-09-19", "checked_by": "blik-validator-2026-09-19", "notes": "Confirms PSP's FAQ statement that users complain to their own bank and that a contactless BLIK refund is usually made by tapping the same phone at the terminal." } ] }, "rail_name": "BLIK", "governing_authority": "Polski Standard Płatności S.A. (PSP)", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "blik:return", "id": "return", "rail": "blik", "kind": "rail-fact", "facet": "return", "name": "Can a BLIK payment be sent back?", "statement": "No. BLIK has no return message: a declined transaction never settles, and a settled one comes back only as a new refund transaction, a cancellation or correction, or through an interbank complaint that PSP decides. Processors present that complaint to merchants as a dispute: Stripe describes claims for fraud, double payment or a wrong amount with 12 days for merchant evidence, while Adyen lists chargebacks as unsupported.", "details": [ { "label": "A declined transaction never settles", "value": "A settlement order exists only once PSP registers a positive authorisation from the issuer, so a transaction the issuer declines, or PSP rejects before authorisation, never enters clearing and moves no money. BLIK has no return message for a settled payment; money goes back through a separate refund, a cancellation or correction, or a complaint.", "citation": "Regulamin Systemu Płatności Mobilnych BLIK, single-session edition approved 15 April 2026, §11.3 f; §14; §29.2", "rests_on": "rule" }, { "label": "Complaints run from participant to PSP through a ticket system", "value": "Complaints and other reports about BLIK go from a participant to PSP through PSP's ticket system, or by e-mail or another agreed channel when the ticket system is down. PSP investigates. It charges a complaint fee from Annex 1 to the participant whose failure caused the event, or to the filer when nobody was at fault, and waives it in cases the complaints procedure lists. For a BLIK-C complaint handled with Mastercard, PSP also collects Mastercard's fee from the issuer or passes on a fee Mastercard pays. The detailed steps, required documents and deadlines are in a non-public operating procedure. PSP keeps complaints for 6 years from the end of the year they close.", "citation": "Regulamin Systemu Płatności Mobilnych BLIK, single-session edition approved 15 April 2026, §6 f, n; §9.1 to §9.4; §9.8; §24.3", "rests_on": "rule" }, { "label": "Processors' account of BLIK disputes", "value": "Stripe tells merchants that BLIK has a claims process a customer can open for suspected fraud, a double payment or an amount that differs from the order; Stripe holds the amount, asks the merchant for evidence within 12 calendar days, and the outcome is BLIK's. Adyen's feature table marks chargebacks as not supported for BLIK. The rulebook itself knows only complaints between participants run by PSP; that Stripe's claims are those complaints seen from the merchant side is [Inference].", "citation": "Stripe Docs: BLIK payments, disputes; Adyen Docs: BLIK, feature table", "rests_on": "practice" } ], "exceptions": [ "For BLIK-C, whether Mastercard's chargeback rules also apply is not stated; the rulebook only prices BLIK-C complaints handled with Mastercard [Unverified]." ], "applies_to": "BLIK in Poland, in PLN: code payments, cash, refunds to the user, contactless BLIK-C, phone transfers and transfer requests, and recurring payments, among PSP's participants", "caveat": "A complaint (reklamacja) is not a chargeback: it runs between participants and PSP, with fees and deemed acceptance of fault, and carries no public reason codes.", "related": [ "mastercard:return", "blik:refund", "blik:liability" ], "basis": { "sources": "BLIK rulebook §9, §11.3 f, §14 and §29.2; Stripe and Adyen pages; read 2026-09-19.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the rulebook edition read does not say when each provision took effect", "effective_to": null, "effective_note": "Drafted 2026-09-19 in Orca Core form from the BLIK rulebook editions approved on 15 April 2026 and PSP's public pages. The rulebook prints no effective date, so when each provision first applied is [Unverified].", "source_edition": "BLIK rulebook single-session and multi-session editions approved 15 April 2026; BLIK FAQ and recurring payments pages; Express Elixir rulebook 1.91; Stripe and Adyen BLIK pages; all read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.blik.com/download/pobierz/regulamin", "source_class": "authoritative_primary", "source_title": "Regulamin Systemu Płatności Mobilnych BLIK, single-session edition approved 15 April 2026", "checked_on": "2026-09-19", "checked_by": "blik-validator-2026-09-19", "notes": "Confirms the synthesis: no return message exists, a declined transaction never settles, and a settled one comes back only through a refund, a cancellation or correction, or a complaint that PSP decides." }, { "source_url": "https://docs.stripe.com/payments/blik", "source_class": "secondary", "source_title": "Stripe Docs: BLIK payments", "checked_on": "2026-09-19", "checked_by": "blik-validator-2026-09-19", "notes": "Confirms Stripe's description of BLIK's claims process (fraud, double payment, wrong amount, 12 day merchant evidence deadline)." }, { "source_url": "https://docs.adyen.com/payment-methods/blik", "source_class": "secondary", "source_title": "Adyen Docs: BLIK", "checked_on": "2026-09-19", "checked_by": "blik-validator-2026-09-19", "notes": "Confirms Adyen's feature table marks chargebacks unsupported for BLIK." } ] }, "rail_name": "BLIK", "governing_authority": "Polski Standard Płatności S.A. (PSP)", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "blik:settlement", "id": "settlement", "rail": "blik", "kind": "rail-fact", "facet": "settlement", "name": "How and when do BLIK participants settle with each other?", "statement": "PSP clears every mobile transaction net, fees included, and settles in central bank money in NBP's SORBNET3: one net debit per issuer and credits to acquirers and Mastercard from PSP's auxiliary account, in one run, within one business day, Monday to Friday except Polish public holidays. Single-session participants close each clearing session at midnight; multi-session participants follow a non-public timetable. If an issuer cannot pay, the other issuers cover it in a reserve run, and failing that the banks settle bilaterally on PSP's instructions. Contactless BLIK settles with Mastercard as a party; transfer requests credit the requester as soon as the payer accepts.", "details": [ { "label": "Net clearing of BLIK transactions, fees included", "value": "PSP clears BLIK mobile transactions in net amounts: for each issuer one net obligation to the BLIK system, for each acquirer and for Mastercard one net claim, all after the fees due to issuers, acquirers and Mastercard, which PSP sets in Annex 2. Orders are handled first in, first out, so transactions are cleared in the order they entered. In the single-session edition PSP clears on every business day and settlement data sets and files are produced on business days; the multi-session edition leaves the business day wording out of those sentences and puts the timing in its session timetable.", "citation": "Regulamin Systemu Płatności Mobilnych BLIK, single-session edition approved 15 April 2026, §3.4; §11.1; §16.2; §29.5; §29.8; §29.9; §31.7; Regulamin Systemu Płatności Mobilnych BLIK, multi-session edition approved 15 April 2026, §16.2; §29.5; §29.9", "rests_on": "rule" }, { "label": "Settlement in SORBNET3 through PSP's auxiliary account", "value": "BLIK settles in central bank money in NBP's SORBNET3 system, with BLIK attached as an external system under SORBNET3's settlement procedure A. From PSP's clearing data PSP enters one net debit order per issuer (covering the indirect participants it settles for, and for a securing issuer its secured acquirers), then, in the same session, credits each acquirer and Mastercard with single orders from PSP's auxiliary account at NBP. Settlement is one run, completes within one business day except when the guarantee forces bilateral settlement, happens Monday to Friday except Polish public holidays, and leaves the auxiliary account at zero before and after. Issuers must manage liquidity on their NBP accounts so the run can settle.", "citation": "Regulamin Systemu Płatności Mobilnych BLIK, single-session edition approved 15 April 2026, §2 (definition of Rachunek Pomocniczy PSP, Rozrachunek); §7.2 a, g; §31.1; §31.4 to §31.10", "rests_on": "rule" }, { "label": "Clearing sessions, single-session model", "value": "For participants in the single-session model, each PSP clearing session ends at midnight (24:00). Transactions authorised on a Polish public holiday go into the session cleared on the next business day. PSP publishes each participant's settlement and reconciliation files promptly after the session closes; the participant must check them and report discrepancies at once, and PSP regenerates the files if needed. BLIK-C refunds are the exception: they join a session only when Mastercard reports them.", "citation": "Regulamin Systemu Płatności Mobilnych BLIK, single-session edition approved 15 April 2026, §29.5 to §29.7; §29.9 to §29.13", "rests_on": "rule" }, { "label": "Clearing and settlement sessions, multi-session model", "value": "For participants in the multi-session model, several clearing sessions are grouped into settlement sessions that settle together in SORBNET3, and the timetable of both sits in the non-public operating procedure for clearing and settlement. Transactions authorised on a Polish public holiday go into the settlement session processed on the next business day. The duties to publish, check and correct settlement files are as in the single-session model.", "citation": "Regulamin Systemu Płatności Mobilnych BLIK, multi-session edition approved 15 April 2026, §2 (definition of Sesja Rozrachunkowa PSP); §29.6; §29.7; §29.9 to §29.12", "rests_on": "rule" }, { "label": "Settlement guarantee among issuers", "value": "If an issuer lacks funds on its NBP account in the main settlement run, or in a first reserve run held after technical errors, every BLIK order in that run is withdrawn and the run does not settle. PSP blocks the short issuer (and with it the secured acquirers and indirect participants that settle through it) and tells NBP. The other issuers stand behind the shortfall: PSP recomputes settlement with their obligations raised by a formula in a non-public procedure and settles in a reserve run. If that also fails, nothing settles through SORBNET3; issuers instead pay acquirers, Mastercard and each other bilaterally on PSP's instructions, and NBP is told. The issuer that caused it must promptly repay the others with statutory interest.", "citation": "Regulamin Systemu Płatności Mobilnych BLIK, single-session edition approved 15 April 2026, §3.10; §7.2 e, f; §31.11 to §31.16", "rests_on": "rule" }, { "label": "Every participant settles through a settlement entity", "value": "A participant either is itself a settlement entity, with its SORBNET3 account linked to BLIK as an external system, or names another settlement entity to receive what clearing owes it. A settlement entity that settles for another participant must credit that participant's account after the run with the amount of its position. An indirect participant uses the account of a direct issuer that has agreed to pass on its settlement orders.", "citation": "Regulamin Systemu Płatności Mobilnych BLIK, single-session edition approved 15 April 2026, §4.1 f to h; §4.3; §31.2", "rests_on": "rule" }, { "label": "BLIK-C settles with Mastercard as a party", "value": "For contactless BLIK the issuer's payment runs to Mastercard, the Cooperating Scheme, through the BLIK system: Mastercard has its own position in BLIK clearing, receives fees set in Annex 2, and is credited from PSP's auxiliary account in the same settlement as acquirers. The merchant side is settled inside Mastercard's scheme. A BLIK-C refund is cleared in BLIK only after Mastercard reports it has sent it for clearing in its own scheme.", "citation": "Regulamin Systemu Płatności Mobilnych BLIK, single-session edition approved 15 April 2026, §2 (definitions of Rozliczenie, Rozrachunek, Transakcja Mobilna d); §12.2; §29.5; §29.13; §31.7; §31.8", "rests_on": "rule" }, { "label": "Transfer request: the requester is credited on acceptance", "value": "Whichever route settles a transfer request, the requester's bank credits the requester right after PSP tells it the payer accepted. A phone transfer or transfer request settles in the BLIK system only if both banks involved have implemented the BLIK-system route set in the Technical Specification; otherwise it goes internal or through an instant payment system.", "citation": "Regulamin Systemu Płatności Mobilnych BLIK, single-session edition approved 15 April 2026, §23.2 d", "rests_on": "rule" } ], "exceptions": [ "Phone transfers settle internally or through Express Elixir unless both banks implemented the BLIK-system route.", "Transactions authorised on a public holiday wait for the first business day's session." ], "applies_to": "BLIK in Poland, in PLN: code payments, cash, refunds to the user, contactless BLIK-C, phone transfers and transfer requests, and recurring payments, among PSP's participants", "caveat": "The two rulebook editions differ only on sessions; cite the one that binds the participant's model when timing matters.", "related": [ "mastercard:settlement", "blik:finality" ], "basis": { "sources": "BLIK rulebook single-session §3.4, §4, §7.2, §16.2, §23.2, §29 and §31, and multi-session §2, §16.2 and §29; read 2026-09-19.", "confidence": "high" }, "currency": { "effective_since": "Unknown: the rulebook edition read does not say when each provision took effect", "effective_to": null, "effective_note": "Drafted 2026-09-19 in Orca Core form from the BLIK rulebook editions approved on 15 April 2026 and PSP's public pages. The rulebook prints no effective date, so when each provision first applied is [Unverified].", "source_edition": "BLIK rulebook single-session and multi-session editions approved 15 April 2026; BLIK FAQ and recurring payments pages; Express Elixir rulebook 1.91; Stripe and Adyen BLIK pages; all read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.blik.com/download/pobierz/regulamin", "source_class": "authoritative_primary", "source_title": "Regulamin Systemu Płatności Mobilnych BLIK, single-session edition approved 15 April 2026", "checked_on": "2026-09-19", "checked_by": "blik-validator-2026-09-19", "notes": "Confirms the synthesis: net clearing including fees, SORBNET3 settlement through PSP's auxiliary account within one business day Monday to Friday except public holidays, midnight single-session close, the settlement guarantee and bilateral fallback, BLIK-C settling with Mastercard as a party, and transfer requests crediting the requester on acceptance." }, { "source_url": "https://www.blik.com/download/pobierz/regulamin-1", "source_class": "authoritative_primary", "source_title": "Regulamin Systemu Płatności Mobilnych BLIK, multi-session edition approved 15 April 2026", "checked_on": "2026-09-19", "checked_by": "blik-validator-2026-09-19", "notes": "Confirms the multi-session edition groups clearing sessions into settlement sessions with a non-public timetable, differing from the single-session edition's midnight close." } ] }, "rail_name": "BLIK", "governing_authority": "Polski Standard Płatności S.A. (PSP)", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "eligibility", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "The rule this rests on, Clearing sessions, single-session model, applies to participants in the single-session settlement model only.", "from": "blik:rule.sessions-single-session-edition" }, { "kind": "eligibility", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "The rule this rests on, Clearing and settlement sessions, multi-session model, applies to participants in the multi-session settlement model only.", "from": "blik:rule.sessions-multi-session-edition" } ] }, { "uid": "boleto:consumer-law", "id": "consumer-law", "rail": "boleto", "kind": "rail-fact", "facet": "consumer-law", "name": "What protections does the payer have?", "statement": "The regulation's payer protections concern how a boleto reaches the payer. A boleto may be presented electronically only with the payer's agreement. A proposal boleto may be sent only to someone who asked for it, and must show that paying is optional and not paying has no consequences, that full information is available first, and that paying means accepting. Every boleto must identify payer, beneficiary, issuer and any enabler, with amount, due date and early payment discounts.", "details": [ { "label": "Electronic presentment needs the payer's consent", "value": "Every boleto follows the model the convention sets and may reach the payer on paper or electronically, but the issuing institution must have the payer's agreement before presenting a boleto electronically. One shared route for doing so is DDA, which Núclea runs. Its membership terms describe it as an electronic system for presenting and looking up boletos, a store of collection data that the member institutions fill and draw on, so a payer with DDA is shown the boletos drawn on it and still pays each one; nothing in that description makes DDA a standing authority to debit the payer [Inference]. An institution may join DDA only if it is already a SILOC participant.", "citation": "Resolução BCB nº 443, arranjo de pagamento do boleto (consolidated), art. 6 and §1; Termo de Adesão ao Sistema de Débito Direto Autorizado, DDA, CIP, clause 1 and clause 2", "rests_on": "rule" }, { "label": "A proposal boleto only after the payer asks for it", "value": "A proposal boleto may be issued and shown to a payer only if the payer has first said they want to receive it. An issuer whose contract lets a beneficiary send proposal boletos must write into that contract the beneficiary's duty to obtain this prior wish.", "citation": "Resolução BCB nº 443, arranjo de pagamento do boleto (consolidated), art. 8; art. 22 sole paragraph", "rests_on": "rule" }, { "label": "What a proposal boleto must make plain", "value": "A proposal boleto's layout and content must let the payer see, clearly and without ambiguity, that paying is a choice and not paying leads to no protest, no court or out-of-court collection and no credit bureau listing; that the payer may get all the information on the product, service or contract terms before paying; and that the slip concerns an offer, proposal or invitation the beneficiary had already put to the payer.", "citation": "Resolução BCB nº 443, arranjo de pagamento do boleto (consolidated), art. 9, I to III", "rests_on": "rule" }, { "label": "Paying a proposal boleto accepts the offer", "value": "Paying a proposal boleto is the payer's acceptance of the obligation offered, and its due date is, for all legal purposes, the last day to accept. A paid proposal boleto has therefore formed the contract, and getting money back is a matter between payer and beneficiary under that contract and general law, not a refund inside the arrangement [Inference: Res. 443 provides no refund].", "citation": "Resolução BCB nº 443, arranjo de pagamento do boleto (consolidated), art. 4, II; art. 9, IV", "rests_on": "rule" }, { "label": "What every boleto must show", "value": "Every boleto must show at least its amount and due date; the payer's name and CPF or CNPJ; the beneficiary's name, address and CPF or CNPJ, also when a third-party enabler brought the beneficiary in; the issuing institution and any enabler; and any discount the underlying obligation grants for early payment. A dynamic boleto linked to an asset also shows the asset's type and unique identifier, the system where it is recorded, registered or deposited, the destination institution, and the rights holder's name, address and CPF or CNPJ, kept current and shown electronically in the receiving institution's app or website; its discount terms must match those held in the asset's system.", "citation": "Resolução BCB nº 443, arranjo de pagamento do boleto (consolidated), art. 7 and sole paragraph; art. 10 and sole paragraph", "rests_on": "rule" } ], "exceptions": [ "DDA, the electronic presentment of boletos to a payer who is the bank's client, is not a direct debit: its membership terms cast it as a presentment and look-up system over a shared store of collection data, so the payer still pays each boleto [Inference; DDA's own convention and manual of operations were not read].", "General consumer law (Lei 8.078/1990) was not read." ], "applies_to": "The boleto de pagamento in Brazil, in reais: common and dynamic cobrança boletos, proposal boletos and deposit boletos, among institutions authorised by the BCB", "caveat": "A proposal boleto is an offer, not a bill: paying it creates the obligation.", "related": [ "pix:consumer-law", "boleto:refund" ], "basis": { "sources": "Res. BCB 443 arts. 4, 6, 7, 8, 9, 10 and 22; CNAB240 v11.0 C044; read 2026-09-19. CIP DDA membership terms, clauses 1 and 2, read 2026-09-20.", "confidence": "medium" }, "currency": { "effective_since": "2025-02-03", "effective_to": null, "effective_note": "Redrafted 2026-09-20 to rest the DDA line on DDA's own membership terms rather than on CNAB240 movement codes alone. The date stays the day Res. BCB 443 entered into force (art. 26); lines from the 2021 convention, CNAB240 and Núclea carry their own dates in their Rules.", "source_edition": "Res. BCB 443 consolidated version 3.0 and IN BCB 611; the 2021 Convenção da Cobrança; CNAB240 version 11.0 (preliminary); Febraban's Nova Plataforma de Boletos page; Núclea's SILOC page and PFMI report version 4; all read 2026-09-19; Termo de Adesão ao Sistema de Débito Direto Autorizado DDA, signed 2017-10-02, read 2026-09-20", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.bcb.gov.br/estabilidadefinanceira/exibenormativo?tipo=Resolução%20BCB&numero=443", "source_class": "authoritative_primary", "source_title": "Resolução BCB nº 443, arranjo de pagamento do boleto (consolidated)", "checked_on": "2026-09-20", "checked_by": "validator-boleto-2026-09-20", "notes": "Confirms a boleto may be presented electronically only with the payer's agreement, that a proposal boleto goes only to a payer who asked for it and must disclose that paying is optional, that non-payment carries no protest or credit-bureau consequence, that full information is available before payment, and that paying means accepting, and that every boleto must state the payer, the beneficiary, the issuing institution and any enabler, the amount, the due date and any early payment discount." } ] }, "rail_name": "Boleto (Brazil payment slip arrangement)", "governing_authority": "Banco Central do Brasil (BCB)", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "boleto:decision-points", "id": "decision-points", "rail": "boleto", "kind": "rail-fact", "facet": "decision-points", "name": "Where do the rules leave a decision to an institution or a person?", "statement": "The receiving institution chooses STR or netting below the VR-Boleto and may hold an STR transfer to check for irregularity. The issuer must find out, by asking the asset systems, whether a boleto has to be dynamic. The beneficiary decides payer claims. The associations' governance structure decides changes to the convention by simple majority, subject to BCB approval.", "details": [ { "label": "The receiving institution may hold an STR transfer to check for irregularity", "value": "The receiving institution may let an individual STR transfer run past the 60 minute limit, for no longer than it strictly needs to take the legal and regulatory steps to investigate signs of irregularity and act on the result. What counts as a sign, and how long the check takes, is its judgment; Res. 443 sets no outer limit.", "citation": "Resolução BCB nº 443, arranjo de pagamento do boleto (consolidated), art. 16 §2", "rests_on": "rule" }, { "label": "Below the VR-Boleto: multilateral netting or STR, at the receiving institution's choice", "value": "A common cobrança, proposal or deposit boleto under R$250,000.00 may be settled by multilateral netting in a settlement system the BCB has authorised, or over STR as a large boleto would be; the receiving institution picks. On the netting route, the receiving institution's notice of payments to the destination institution and any notice of devolução coming back both follow the procedures and hours in that settlement system's own rules. The 2021 convention names SILOC as the netting system.", "citation": "Resolução BCB nº 443, arranjo de pagamento do boleto (consolidated), art. 16, II and §3; Convenção da Cobrança, FB-0061/2021 (boleto convention of 5 February 2021), art. 27, I and II and §2", "rests_on": "rule" }, { "label": "When the issuer must issue a dynamic boleto", "value": "An issuing institution must issue a cobrança boleto as dynamic when the beneficiary, as original creditor, has a contract with a recording, registry or depository system for an asset representing the billed debt, and it must ask those systems whether such a contract exists. It may not favour one such system over another, may not charge more for a dynamic boleto than for a common one until an asset is linked, and may not make issuance depend on the asset being traded only through itself. The settlement system's operator must see that the rule is kept and tells the issuer when a common boleto was registered where a dynamic one was due.", "citation": "Resolução BCB nº 443, arranjo de pagamento do boleto (consolidated), art. 11 and §§1 and 2; art. 12-A, I", "rests_on": "rule" }, { "label": "Payer claim: the beneficiary decides", "value": "A payer who disagrees with a title can lodge a claim (alegação) with the beneficiary's bank, on paper at a branch or electronically if the payer is that bank's client under the claims agreement. The bank forwards the claim to the beneficiary, who decides whether to accept it and instructs the bank. The bank does not rule on it, and nothing in Res. 443 makes anyone reverse a paid boleto [Inference: no such provision was found].", "citation": "Layout Padrão Febraban 240 posições (CNAB240), version 11.0, 3.2.1, information flow (p. 65) and payer claim events (p. 67)", "rests_on": "guidance" }, { "label": "How the convention is changed", "value": "A change to the convention needs a simple majority of the votes in the governance structure and then BCB approval. Seats and votes go to associations in proportion to the yearly number of boletos their members issue or receive, first on 2024 volumes and then reviewed at the end of each term; no association may hold more than half the votes, an association in which one member accounts for over 90 percent of its members' boletos has no seat, and associations may share a seat. The BCB publishes the minimum representativeness, the associations and their votes. Changes that Res. 443 itself required had to reach the BCB within 150 days of 2025-02-03.", "citation": "Resolução BCB nº 443, arranjo de pagamento do boleto (consolidated), art. 20 §§3 and 4; art. 21 §§1 to 7", "rests_on": "rule" } ], "exceptions": [ "Res. 443 sets no outer limit on how long an irregularity hold may last." ], "applies_to": "The boleto de pagamento in Brazil, in reais: common and dynamic cobrança boletos, proposal boletos and deposit boletos, among institutions authorised by the BCB", "caveat": null, "related": [], "basis": { "sources": "Res. BCB 443 arts. 11, 12-A, 16, 20 and 21; CNAB240 v11.0 3.2.1; read 2026-09-19.", "confidence": "medium" }, "currency": { "effective_since": "2025-02-03", "effective_to": null, "effective_note": "Drafted 2026-09-19 in Orca Core form. The date is the day Res. BCB 443 entered into force (art. 26); lines from the 2021 convention, CNAB240 and Núclea carry their own dates in their Rules.", "source_edition": "Res. BCB 443 consolidated version 3.0 and IN BCB 611; the 2021 Convenção da Cobrança; CNAB240 version 11.0 (preliminary); Febraban's Nova Plataforma de Boletos page; Núclea's SILOC page and PFMI report version 4; all read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.bcb.gov.br/estabilidadefinanceira/exibenormativo?tipo=Resolução%20BCB&numero=443", "source_class": "authoritative_primary", "source_title": "Resolução BCB nº 443, arranjo de pagamento do boleto (consolidated)", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms the receiving institution's route choice and irregularity hold, the issuer's duty to ask about dynamic issuance, and the governance structure's simple-majority vote, arts. 11, 12-A, 16, 20 and 21." }, { "source_url": "https://cmsarquivos.febraban.org.br/Arquivos/documentos/PDF/Layout%20padrao%20CNAB240%20V%2011_0%20-%202026_09_11.pdf", "source_class": "public_primary", "source_title": "Layout Padrão Febraban 240 posições (CNAB240), version 11.0", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms the beneficiary decides a payer claim after the beneficiary's bank forwards it, 3.2.1." } ] }, "rail_name": "Boleto (Brazil payment slip arrangement)", "governing_authority": "Banco Central do Brasil (BCB)", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "boleto:finality", "id": "finality", "rail": "boleto", "kind": "rail-fact", "facet": "finality", "name": "When is a boleto payment final, and can it be undone?", "statement": "The payer cannot undo a boleto: once paid, nothing in the regulation lets the payer pull the money back. Between institutions, a common, proposal or deposit boleto of R$250,000.00 or more settles gross over STR the same day, sent within 60 minutes of payment; smaller ones net in SILOC or go over STR at the receiving institution's choice, every dynamic boleto nets, and SILOC settlement is final when Núclea's STR account pays out the net credits. A settled payment can come back only as a devolução between institutions, through the system that settled it. A boleto paid by Pix is a Pix, and its finality is Pix's.", "details": [ { "label": "Boletos at or above the VR-Boleto settle gross over STR the same day", "value": "For a common cobrança, proposal or deposit boleto of R$250,000.00 or more, the receiving institution passes the amount and the payment data straight to the destination institution through the BCB's STR on the day it takes the payment, one by one or aggregated, in a dedicated message of the SFN service catalog. Which catalog message that is was not identified [Unverified].", "citation": "Resolução BCB nº 443, arranjo de pagamento do boleto (consolidated), art. 16, I; art. 19", "rests_on": "rule" }, { "label": "STR boleto transfers go to settlement within 60 minutes of payment", "value": "On the STR route, each credit transfer must be sent to the settlement system so that it settles no more than sixty minutes after the payer pays. The 2021 convention put the same one hour limit on each STR transfer, bounded by the close of the STR day.", "citation": "Resolução BCB nº 443, arranjo de pagamento do boleto (consolidated), art. 16 §1; Convenção da Cobrança, FB-0061/2021 (boleto convention of 5 February 2021), art. 27 §1", "rests_on": "rule" }, { "label": "Below the VR-Boleto: multilateral netting or STR, at the receiving institution's choice", "value": "A common cobrança, proposal or deposit boleto under R$250,000.00 may be settled by multilateral netting in a settlement system the BCB has authorised, or over STR as a large boleto would be; the receiving institution picks. On the netting route, the receiving institution's notice of payments to the destination institution and any notice of devolução coming back both follow the procedures and hours in that settlement system's own rules. The 2021 convention names SILOC as the netting system.", "citation": "Resolução BCB nº 443, arranjo de pagamento do boleto (consolidated), art. 16, II and §3; Convenção da Cobrança, FB-0061/2021 (boleto convention of 5 February 2021), art. 27, I and II and §2", "rests_on": "rule" }, { "label": "SILOC settlement is final when Núclea's STR account pays out", "value": "Núclea states that, under Res. BCB 304/2023, interbank settlement is final once the resulting entries are made in reserve or settlement accounts at the BCB. For SILOC that moment is each funds transfer step at settlement, when the balance in Núclea's STR settlement account moves to the participants in net credit. Núclea's SILOC rulebook carries the same point in its own terms: it defines the settlement moment as the point in the funds transfer stage at which Núclea requests that movement, and, setting out the boleto cycle, says the operation may no longer be reversed once that stage has finished. Participants fund their debit positions first; one that does not is dropped from that cycle, the multilateral positions are recalculated, and it may take part in later cycles while it stays authorised. Res. BCB 304/2023 itself was not read.", "citation": "Regulamento Operacional do SILOC, Núclea, art. 1, the definition of the settlement moment; art. 9, item 4(b) of the boleto cycle; Relatório Divulgação PFMI CPSS-IOSCO, Núclea, version 4, principle 8, KC 1 (p. 17); principle 3, KC 2 (p. 15); principle 13, KC 1 (p. 19)", "rests_on": "rule" }, { "label": "Early payment data given to a beneficiary is informative only", "value": "Under the 2021 convention a destination institution may show its beneficiaries the data on an interbank receipt of their boleto, but that data is for information and is not an irrevocable confirmation of the payment. The receiving institution sends an operational write-off (baixa operacional) to the central database as soon as it takes the payment, and the destination institution sends the effective write-off (baixa efetiva) once interbank clearing is complete.", "citation": "Convenção da Cobrança, FB-0061/2021 (boleto convention of 5 February 2021), art. 27 §§4, 5 and 7", "rests_on": "rule" }, { "label": "Devoluções and adjustments run through the system that settled the original", "value": "When the destination institution sends money back to the receiving institution (devolução), or the two settle a difference in amount (acerto de diferença), they must use the same system that settled the original payment, STR or the netting system, under that system's procedures and hours.", "citation": "Resolução BCB nº 443, arranjo de pagamento do boleto (consolidated), art. 18", "rests_on": "rule" }, { "label": "A boleto paid through another BCB arrangement follows that arrangement's rules", "value": "A boleto may be presented so that it can be paid through another payment arrangement the BCB authorises or operates, as the convention provides, and the laws, regulations and rulebooks of each arrangement involved then apply. The Febraban file standard lets a bank register and distribute a boleto with a Pix QR code and report a title settled via Pix. So when a boleto is paid by Pix, the payment is a Pix and its finality, returns and refunds are Pix's, while the write-off of the title stays on the boleto side [Inference: Res. 443 states the deferral in general terms and does not name Pix].", "citation": "Resolução BCB nº 443, arranjo de pagamento do boleto (consolidated), art. 6 §2; Layout Padrão Febraban 240 posições (CNAB240), version 11.0, C010 values P and Q (pp. 172 to 173); C047 list C, code 61 (p. 182)", "rests_on": "rule" } ], "exceptions": [ "A boleto paid through another BCB arrangement, such as Pix, follows that arrangement's finality rules (pix:finality).", "The receiving institution may hold an STR transfer past 60 minutes while it checks signs of irregularity." ], "applies_to": "The boleto de pagamento in Brazil, in reais: common and dynamic cobrança boletos, proposal boletos and deposit boletos, among institutions authorised by the BCB", "caveat": "Do not treat a beneficiary's early notice of payment as final: under the 2021 convention that data is informative, and the beneficiary's own credit depends on its contract with its bank.", "related": [ "pix:finality", "boleto:settlement", "boleto:return" ], "basis": { "sources": "Res. BCB 443 arts. 6, 16, 17, 18 and 19; 2021 convention art. 27; Núclea PFMI report v4 principle 8; CNAB240 v11.0 C010 and C047; read 2026-09-19. That the payer has no reversal right is [Inference] from its absence.", "confidence": "medium" }, "currency": { "effective_since": "2025-02-03", "effective_to": null, "effective_note": "Drafted 2026-09-19 in Orca Core form. The date is the day Res. BCB 443 entered into force (art. 26); lines from the 2021 convention, CNAB240 and Núclea carry their own dates in their Rules.", "source_edition": "Res. BCB 443 consolidated version 3.0 and IN BCB 611; the 2021 Convenção da Cobrança; CNAB240 version 11.0 (preliminary); Febraban's Nova Plataforma de Boletos page; Núclea's SILOC page and PFMI report version 4; all read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.bcb.gov.br/estabilidadefinanceira/exibenormativo?tipo=Resolução%20BCB&numero=443", "source_class": "authoritative_primary", "source_title": "Resolução BCB nº 443, arranjo de pagamento do boleto (consolidated)", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms the STR and netting settlement routes, the payer's lack of a reversal right, and the deferral to another arrangement's finality, arts. 6, 16, 17, 18 and 19." } ] }, "rail_name": "Boleto (Brazil payment slip arrangement)", "governing_authority": "Banco Central do Brasil (BCB)", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "boleto:hours", "id": "hours", "rail": "boleto", "kind": "rail-fact", "facet": "hours", "name": "What times and deadlines govern boleto payments?", "statement": "Res. 443 sets three clocks: an STR-routed boleto goes to settlement within 60 minutes of payment, STR devoluções and adjustments go by 12:00, and devoluções and adjustments on automatable grounds are due by the business day after settlement. SILOC's own rulebook adds a fourth: on the netting route the net credits leave Núclea's account at the BCB at 08:20 in the first cycle of a business day and at 16:10 in the second, each after a deposit window that opens at 07:00 and 15:20 and closes at 08:00 and 15:50. Núclea's SILOC manual of operations puts the afternoon cycle on the date its payments were processed and the morning cycle on the business day after; the exact processing cut-off between them, and SILOC's data transmission hours, are in a processing manual Orca has not read. A boleto due on a non-business day can be paid on the next business day without charges.", "details": [ { "label": "STR boleto transfers go to settlement within 60 minutes of payment", "value": "On the STR route, each credit transfer must be sent to the settlement system so that it settles no more than sixty minutes after the payer pays. The 2021 convention put the same one hour limit on each STR transfer, bounded by the close of the STR day.", "citation": "Resolução BCB nº 443, arranjo de pagamento do boleto (consolidated), art. 16 §1; Convenção da Cobrança, FB-0061/2021 (boleto convention of 5 February 2021), art. 27 §1", "rests_on": "rule" }, { "label": "The receiving institution may hold an STR transfer to check for irregularity", "value": "The receiving institution may let an individual STR transfer run past the 60 minute limit, for no longer than it strictly needs to take the legal and regulatory steps to investigate signs of irregularity and act on the result. What counts as a sign, and how long the check takes, is its judgment; Res. 443 sets no outer limit.", "citation": "Resolução BCB nº 443, arranjo de pagamento do boleto (consolidated), art. 16 §2", "rests_on": "rule" }, { "label": "STR devoluções and adjustments by 12:00", "value": "A devolução or acerto de diferença sent through STR must go by twelve noon, in a dedicated message of the SFN service catalog. Res. 443 does not state the time zone; the STR runs on Brasília time [Inference]. The 2021 convention places STR devoluções on automatable grounds at 12:00 of the business day after settlement.", "citation": "Resolução BCB nº 443, arranjo de pagamento do boleto (consolidated), art. 18 §2; Convenção da Cobrança, FB-0061/2021 (boleto convention of 5 February 2021), art. 31, I", "rests_on": "rule" }, { "label": "Automatable devoluções and adjustments by the next business day", "value": "Where the problem behind a devolução or an acerto de diferença is one that can be detected automatically, the transfer must be made no later than the business day after the original settlement.", "citation": "Resolução BCB nº 443, arranjo de pagamento do boleto (consolidated), art. 18 §1", "rests_on": "rule" }, { "label": "SILOC settles boletos in two cycles: 16:10 the same business day, 08:20 the next", "value": "Núclea's SILOC rulebook gives boleto settlement two cycles on a business day. Money reaches the institutions in net credit at 08:20 in the first cycle and at 16:10 in the second, transferred over the STR out of Núclea's own settlement account at the BCB. Each transfer is preceded by Núclea asking the institutions in net debit to fund their positions, at 07:00 for the first cycle and 15:20 for the second, and by a deposit window that closes at 08:00 and 15:50. Núclea's SILOC manual of operations says which day's payments each cycle carries. The afternoon cycle settles on the same date its payments were processed: its last partial clearing result goes out at 15:00 and the final one by 15:05, and the money moves at 16:10. The morning cycle settles on the business day after processing: its partial clearing result goes out by 01:00 (02:00 after a national holiday) and its final one by 05:10, ahead of the 08:20 transfer. So a boleto on the netting route settles the same day when its payment is processed in time for the afternoon cycle, and the next business day morning otherwise. The exact clock time at which a payment stops counting for the afternoon cycle is left by the manual to a separate SILOC processing manual, which Orca has not read; that the afternoon partials close at about 15:00 is [Inference] from the clearing timetable.", "citation": "Regulamento Operacional do SILOC, Núclea, art. 14, the boleto funds transfer stage table; arts. 8, 9, 13 and 38 on the stages and where their routines and deadlines sit; Manual de Operações do SILOC (MAPX-OP002-2004), Núclea, section 11.1, the boleto (Cobrança) settlement cycle and its stages, and 11.1.1, the timetable split between the settlement stages that fall on the next business day and those on the date of processing (pp. 20 to 25); Liquidação de Operações de Crédito, SILOC (Núclea product page), Formas de Liquidação; Relatório Divulgação PFMI CPSS-IOSCO, Núclea, version 4, principle 8, KC 2 (p. 17)", "rests_on": "rule" }, { "label": "A due date on a non-business day moves to the next business day without charges", "value": "If the due date registered in the central database falls on a day that is not a business day where the payer pays, the boleto can be paid on the next business day with no interest or fine, at any receiving institution. The 2021 convention rests this on Lei 7.089/1983, which was not read.", "citation": "Convenção da Cobrança, FB-0061/2021 (boleto convention of 5 February 2021), art. 22", "rests_on": "rule" } ], "exceptions": [ "The receiving institution may run past the 60 minutes for as long as it needs to check for irregularity.", "Res. 443 does not state the time zone of the 12:00 limit, and neither does the SILOC rulebook for its cycle times; Brasília time is assumed [Inference].", "A failure to fund a SILOC position pushes the deposit window and the credit transfer back by 15 minutes at a time, with the BCB's agreement, and in an emergency Núclea may move the times or settle on a later business day." ], "applies_to": "The boleto de pagamento in Brazil, in reais: common and dynamic cobrança boletos, proposal boletos and deposit boletos, among institutions authorised by the BCB", "caveat": "SILOC's funds transfer times and the day each cycle falls on are held; the processing cut-off that decides whether a given payment joins the same day afternoon cycle or the next morning's is not.", "related": [ "pix:hours", "boleto:settlement" ], "basis": { "sources": "Res. BCB 443 arts. 16 and 18; 2021 convention arts. 22, 27 and 31; Núclea SILOC page and PFMI report v4; read 2026-09-19. Núclea SILOC operating rulebook, edition 02.01.2026, arts. 14, 18 and 31, read 2026-09-20. Núclea SILOC manual of operations MAPX-OP002-2004, version 31.0, sections 11.1 and 11.1.1, read 2026-09-22.", "confidence": "medium" }, "currency": { "effective_since": "2025-02-03", "effective_to": null, "effective_note": "Redrafted 2026-09-20 to carry SILOC's own cycle times, from Núclea's SILOC operating rulebook, version 4.0 of 2026-01-02. The date stays the day Res. BCB 443 entered into force (art. 26); lines from the 2021 convention, CNAB240 and Núclea carry their own dates in their Rules.", "source_edition": "Res. BCB 443 consolidated version 3.0 and IN BCB 611; the 2021 Convenção da Cobrança; CNAB240 version 11.0 (preliminary); Febraban's Nova Plataforma de Boletos page; Núclea's SILOC page and PFMI report version 4; all read 2026-09-19; Regulamento Operacional do SILOC, version 4.0, dated 02.01.2026, read 2026-09-20", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www2.nuclea.com.br/ProdutosIMF/Regulamento%20Operacional%20do%20SILOC.pdf", "source_class": "authoritative_primary", "source_title": "Regulamento Operacional do SILOC, Núclea", "checked_on": "2026-09-20", "checked_by": "validator-boleto-2026-09-20", "notes": "Confirms the netting route's timing: a deposit window from 07:00 to 08:00 and from 15:20 to 15:50, and net credits transferred at 08:20 and 16:10, with the SILOC rulebook fixing no cut-off for which business day's payments a cycle carries." }, { "source_url": "https://www2.nuclea.com.br/Compliance/MAPX-OP002-2004%20-%20Manual%20de%20Opera%C3%A7%C3%B5es%20do%20SILOC.pdf", "source_class": "public_primary", "source_title": "Manual de Operações do SILOC (MAPX-OP002-2004), Núclea", "checked_on": "2026-09-23", "checked_by": "validator-opus-2026-09-23", "notes": "Confirms from version 31.0 sections 11.1 and 11.1.1 the SILOC boleto deposit windows of 07:00 to 08:00 and 15:20 to 15:50 and credit transfers at 08:20 and 16:10, that the afternoon cycle falls on the date of processing and the morning cycle on the next business day, and that the clearing stage detail is left to the SILOC processing manual; it gives no data transmission hours in those sections." } ] }, "rail_name": "Boleto (Brazil payment slip arrangement)", "governing_authority": "Banco Central do Brasil (BCB)", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "boleto:liability", "id": "liability", "rail": "boleto", "kind": "rail-fact", "facet": "liability", "name": "Who answers for what when a boleto goes wrong?", "statement": "Res. 443 sends each question to a relationship: the issuer and beneficiary's contract, the interbank rules between receiving and destination institution, or the issuer and enabler's contract. The issuer must manage the risk that a species is misused, that a billed obligation is unsound and that enablers fall short, and must vet its enablers. The 2021 convention puts defective slips and failed registrations on the destination institution, and wrong or late data and funds on the receiving institution, with claims open for five years.", "details": [ { "label": "Three relationships carry the rights and duties over a boleto", "value": "Res. 443 sends rights and duties over a boleto to three places. Between receiving and destination institution: Res. 443 first, then the convention and the rules of the settlement system used, where they do not conflict with it. Between issuing institution and beneficiary: their contract, including when the beneficiary is credited; where the issuer lets the beneficiary send proposal boletos, that contract must oblige the beneficiary to obtain the payer's prior wish to receive them. Between issuing institution and any third-party enabler: their contract, including when the enabler is credited and what information it gives the issuer for its legal duties.", "citation": "Resolução BCB nº 443, arranjo de pagamento do boleto (consolidated), art. 22 and sole paragraph", "rests_on": "rule" }, { "label": "The issuer's risk management duties", "value": "An issuing institution's risk management must include procedures that ensure each boleto species is used for what it is for, that the obligation being billed is sound, and that it monitors the information it needs to meet its legal and regulatory duties; the first and the last also reach beneficiaries brought in through a third-party enabler.", "citation": "Resolução BCB nº 443, arranjo de pagamento do boleto (consolidated), art. 24", "rests_on": "rule" }, { "label": "Checks an issuer owes on a third-party enabler", "value": "An issuing institution that contracts a third party to onboard beneficiaries must satisfy itself that the enabler meets the technical, operational, cyber-security and reputation requirements of regulation and follows the issuer's risk policies, including its rules against money laundering and terrorist financing and on asset freezes. The contract must give the issuer access to the documents and information that identify each beneficiary the enabler brings in.", "citation": "Resolução BCB nº 443, arranjo de pagamento do boleto (consolidated), art. 14 and sole paragraph", "rests_on": "rule" }, { "label": "The destination institution answers for defective slips and failed registration", "value": "Under the 2021 convention the destination institution is responsible for errors caused by poor printing material or by not following the slip's specifications, whether it or the beneficiary produced the slip. It must validate the data of slips printed outside its own environment, and a beneficiary that issues slips without that validation bears the consequences. If the destination institution fails to register a boleto in the central database, it must accept payment in its own channels until the fault is fixed and bears the late charges if a payment elsewhere fails before the due date because of it.", "citation": "Convenção da Cobrança, FB-0061/2021 (boleto convention of 5 February 2021), arts. 13, 16 and 17 §3", "rests_on": "rule" }, { "label": "The receiving institution answers for the data it passes on and for late transfers", "value": "Under the 2021 convention the receiving institution must reproduce the central database's data exactly in its SILOC files and STR messages and bears the consequences of errors, charges included, unless it took the payment during a declared outage. If it misses the regulation's or SILOC's deadlines for passing on data or funds, it pays the charges the destination institution claims on the beneficiary's instruction. An amount taken and not passed on can be claimed with charges for up to five years from receipt.", "citation": "Convenção da Cobrança, FB-0061/2021 (boleto convention of 5 February 2021), arts. 27 §3, 29 sole paragraph, 30 and 33 §2", "rests_on": "rule" }, { "label": "Every boleto is registered in the central database before it is presented", "value": "The central database (base centralizada) is part of the arrangement: a store of data on boletos used to register and look them up. Under the 2021 convention the destination institution must register each boleto there, with the payer's CPF or CNPJ and what is needed to recompute the amount before and after the due date, and may present it only after registration. Between institutions the registered conditions prevail over what the slip shows, except while the database is unavailable, and a receiving institution other than the destination must accept a registered boleto that follows the models, also after its due date. Núclea runs the database, which it calls the Plataforma Centralizada de Recebíveis. Membership of it is what lets an institution settle boletos at all: Núclea's SILOC rulebook partially suspends from SILOC any participant that has not joined the database, leaving it unable to move boleto funds there, drops a participant that later asks to leave the database out of SILOC for boletos at the same time, and suspends or excludes an institution from the database the moment SILOC suspends or excludes it.", "citation": "Resolução BCB nº 443, arranjo de pagamento do boleto (consolidated), art. 3, VIII and §2; Convenção da Cobrança, FB-0061/2021 (boleto convention of 5 February 2021), arts. 5, 11 and 17 §§1 and 2; Relatório Divulgação PFMI CPSS-IOSCO, Núclea, version 4, section 4, b.6 (p. 5); Regulamento Operacional do SILOC, Núclea, art. 1, the definition of a partially suspended participant; art. 22 and its §1", "rests_on": "rule" } ], "exceptions": [ "The allocations taken from the 2021 convention may differ in the edition in force [Unverified]." ], "applies_to": "The boleto de pagamento in Brazil, in reais: common and dynamic cobrança boletos, proposal boletos and deposit boletos, among institutions authorised by the BCB", "caveat": "General consumer law (Lei 8.078/1990) was not read; this covers the arrangement's own allocation only.", "related": [], "basis": { "sources": "Res. BCB 443 arts. 14, 22 and 24; 2021 convention arts. 5, 11, 13, 16, 17, 27, 29, 30 and 33; read 2026-09-19.", "confidence": "medium" }, "currency": { "effective_since": "2025-02-03", "effective_to": null, "effective_note": "Drafted 2026-09-19 in Orca Core form. The date is the day Res. BCB 443 entered into force (art. 26); lines from the 2021 convention, CNAB240 and Núclea carry their own dates in their Rules.", "source_edition": "Res. BCB 443 consolidated version 3.0 and IN BCB 611; the 2021 Convenção da Cobrança; CNAB240 version 11.0 (preliminary); Febraban's Nova Plataforma de Boletos page; Núclea's SILOC page and PFMI report version 4; all read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.bcb.gov.br/estabilidadefinanceira/exibenormativo?tipo=Resolução%20BCB&numero=443", "source_class": "authoritative_primary", "source_title": "Resolução BCB nº 443, arranjo de pagamento do boleto (consolidated)", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms the three relationships that carry rights and duties, and the issuer's risk-management and enabler-vetting duties, arts. 14, 22 and 24." }, { "source_url": "https://cmsarquivos.febraban.org.br/Arquivos/documentos/PDF/Conven%C3%A7%C3%A3o%20da%20Cobran%C3%A7a%20-%2005_02_2021_f.pdf", "source_class": "authoritative_primary", "source_title": "Convenção da Cobrança, FB-0061/2021 (boleto convention of 5 February 2021)", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms the destination institution's liability for defective slips and registration failure, and the receiving institution's liability for wrong or late data and funds, with the five-year claim window, arts. 5, 11, 13, 16, 17, 27, 29, 30 and 33." } ] }, "rail_name": "Boleto (Brazil payment slip arrangement)", "governing_authority": "Banco Central do Brasil (BCB)", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "boleto:limits", "id": "limits", "rail": "boleto", "kind": "rail-fact", "facet": "limits", "name": "What amount limits apply to a boleto?", "statement": "The regulation's one figure, the VR-Boleto of R$250,000.00, is a routing threshold, not a cap; no maximum boleto amount was found. The 2021 convention bars cash payment of boletos of R$10,000.00 or more, and a title can be registered to accept or refuse partial payment within set minimum and maximum amounts.", "details": [ { "label": "VR-Boleto: the R$250,000.00 routing threshold", "value": "Res. 443 fixes the reference value VR-Boleto at R$250,000.00. It does not cap a boleto's amount: it decides the settlement route, same-day STR at or above it and netting or STR below it, for every species except the dynamic boleto, which always nets. No maximum amount for a boleto was found in the sources read [Unverified].", "citation": "Resolução BCB nº 443, arranjo de pagamento do boleto (consolidated), art. 19; art. 16, I and II; art. 17", "rests_on": "rule" }, { "label": "No cash payment of boletos of R$10,000.00 or more", "value": "Since 2018-05-28 the associations have agreed, to fight money laundering, that a boleto of R$10,000.00 or more cannot be paid in cash; it must come from the payer's account, a cheque, a card or another source that shows where the money came from and who finally paid. Receiving institutions must stop such cash payments in their channels and warn customers, and a beneficiary may not break one obligation into smaller boletos for the same payer and due date to avoid the rule. A cash payment below the threshold taken by another institution is flagged to the destination institution, and the receiving institution identifies the actual payer, by name and CPF or CNPJ, for every payment not made in cash and for cash payments over R$2,000.00.", "citation": "Convenção da Cobrança, FB-0061/2021 (boleto convention of 5 February 2021), arts. 18 to 21", "rests_on": "rule" }, { "label": "Partial payment and minimum and maximum amounts are set per title", "value": "In the Febraban file standard a beneficiary's bank can register a title as accepting or refusing partial payment and with a minimum and a maximum amount or percentage. The bank confirms changes to the minimum and the maximum with return movement codes 64 and 65, and list A of the occurrence reasons carries the related codes A9, B1, B4 and B5. How a receiving institution applies these bounds at the counter or in an app is in the central database manuals, which were not read [Unverified].", "citation": "Layout Padrão Febraban 240 posições (CNAB240), version 11.0, C044 (pp. 177 to 178); C047 list A (p. 181)", "rests_on": "guidance" } ], "exceptions": [ "The R$10,000.00 cash rule comes from the 2021 convention; whether the convention in force keeps it is [Unverified]." ], "applies_to": "The boleto de pagamento in Brazil, in reais: common and dynamic cobrança boletos, proposal boletos and deposit boletos, among institutions authorised by the BCB", "caveat": "The R$50,000 figure in Febraban's history of the new boleto platform is the first rollout stage of July 2017, not a limit.", "related": [], "basis": { "sources": "Res. BCB 443 arts. 16, 17 and 19; 2021 convention arts. 18 to 21; CNAB240 v11.0 C044 and C047; Febraban's Nova Plataforma de Boletos page for the 2017 rollout; read 2026-09-19.", "confidence": "medium" }, "currency": { "effective_since": "2025-02-03", "effective_to": null, "effective_note": "Drafted 2026-09-19 in Orca Core form. The date is the day Res. BCB 443, which sets the VR-Boleto, entered into force (art. 26); the cash rule dates from 2018-05-28 and the file standard edition from 2026-09-11, as their Rules say.", "source_edition": "Res. BCB 443 consolidated version 3.0 and IN BCB 611; the 2021 Convenção da Cobrança; CNAB240 version 11.0 (preliminary); Febraban's Nova Plataforma de Boletos page; Núclea's SILOC page and PFMI report version 4; all read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.bcb.gov.br/estabilidadefinanceira/exibenormativo?tipo=Resolução%20BCB&numero=443", "source_class": "authoritative_primary", "source_title": "Resolução BCB nº 443, arranjo de pagamento do boleto (consolidated)", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms the VR-Boleto is a routing threshold with no maximum amount found, arts. 16, 17 and 19." }, { "source_url": "https://cmsarquivos.febraban.org.br/Arquivos/documentos/PDF/Conven%C3%A7%C3%A3o%20da%20Cobran%C3%A7a%20-%2005_02_2021_f.pdf", "source_class": "authoritative_primary", "source_title": "Convenção da Cobrança, FB-0061/2021 (boleto convention of 5 February 2021)", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms the R10,000.00 cash ceiling, arts. 18 to 21." }, { "source_url": "https://cmsarquivos.febraban.org.br/Arquivos/documentos/PDF/Layout%20padrao%20CNAB240%20V%2011_0%20-%202026_09_11.pdf", "source_class": "public_primary", "source_title": "Layout Padrão Febraban 240 posições (CNAB240), version 11.0", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms the file standard's partial-payment and value-limit registration fields, C044 and C047." }, { "source_url": "https://portal.febraban.org.br/pagina/3150/1094/pt-br/servicos-novo-plataforma-boletos", "source_class": "public_primary", "source_title": "Nova Plataforma de Boletos de Pagamento, Cobrança Registrada", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms the R50,000 figure was the July 2017 first rollout stage of the Nova Plataforma, not a limit." } ] }, "rail_name": "Boleto (Brazil payment slip arrangement)", "governing_authority": "Banco Central do Brasil (BCB)", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "boleto:messages", "id": "messages", "rail": "boleto", "kind": "rail-fact", "facet": "messages", "name": "What messages and files carry a boleto?", "statement": "Three layers. Between a company and its bank, Febraban's CNAB240 files register titles and report payments, write-offs and rejections, and the slip carries a barcode and typed line to a specification traced to the BCB. Every boleto is registered in the central database Núclea runs before it is presented, and between institutions the registration prevails over the slip. Between institutions, large boletos move in a dedicated STR message and the rest in SILOC files of write-offs and returns of write-offs, whose layouts sit in a boleto clearing module manual Núclea does not publish. Núclea does publish the SILOC layouts manual, but it covers only the participant relation file and the message that reports a participant's multilateral result. A boleto may also carry a Pix QR code.", "details": [ { "label": "What every boleto must show", "value": "Every boleto must show at least its amount and due date; the payer's name and CPF or CNPJ; the beneficiary's name, address and CPF or CNPJ, also when a third-party enabler brought the beneficiary in; the issuing institution and any enabler; and any discount the underlying obligation grants for early payment. A dynamic boleto linked to an asset also shows the asset's type and unique identifier, the system where it is recorded, registered or deposited, the destination institution, and the rights holder's name, address and CPF or CNPJ, kept current and shown electronically in the receiving institution's app or website; its discount terms must match those held in the asset's system.", "citation": "Resolução BCB nº 443, arranjo de pagamento do boleto (consolidated), art. 7 and sole paragraph; art. 10 and sole paragraph", "rests_on": "rule" }, { "label": "Every boleto is registered in the central database before it is presented", "value": "The central database (base centralizada) is part of the arrangement: a store of data on boletos used to register and look them up. Under the 2021 convention the destination institution must register each boleto there, with the payer's CPF or CNPJ and what is needed to recompute the amount before and after the due date, and may present it only after registration. Between institutions the registered conditions prevail over what the slip shows, except while the database is unavailable, and a receiving institution other than the destination must accept a registered boleto that follows the models, also after its due date. Núclea runs the database, which it calls the Plataforma Centralizada de Recebíveis. Membership of it is what lets an institution settle boletos at all: Núclea's SILOC rulebook partially suspends from SILOC any participant that has not joined the database, leaving it unable to move boleto funds there, drops a participant that later asks to leave the database out of SILOC for boletos at the same time, and suspends or excludes an institution from the database the moment SILOC suspends or excludes it.", "citation": "Resolução BCB nº 443, arranjo de pagamento do boleto (consolidated), art. 3, VIII and §2; Convenção da Cobrança, FB-0061/2021 (boleto convention of 5 February 2021), arts. 5, 11 and 17 §§1 and 2; Relatório Divulgação PFMI CPSS-IOSCO, Núclea, version 4, section 4, b.6 (p. 5); Regulamento Operacional do SILOC, Núclea, art. 1, the definition of a partially suspended participant; art. 22 and its §1", "rests_on": "rule" }, { "label": "The boleto barcode and typed line", "value": "The barcode on a boleto's payment stub (ficha de compensação) follows the specification the Febraban standard traces to BCB Carta-Circular 2.926 of 2000-07-25 (layout CADOC 24044-4). Under the 2021 convention the printed barcode and the typed line of digits (linha digitável) must carry exactly the same data. Whether Carta-Circular 2.926 is still in force was not checked [Unverified].", "citation": "Layout Padrão Febraban 240 posições (CNAB240), version 11.0, G063 (p. 208); Convenção da Cobrança, FB-0061/2021 (boleto convention of 5 February 2021), art. 14", "rests_on": "guidance" }, { "label": "Company-to-bank files: the Febraban CNAB240 standard", "value": "Between a beneficiary company and its bank, boleto data moves in Febraban's 240-position files. The company's remittance file registers titles and sends instructions and changes, using detail segments P, Q, R, S, Y and X (X carries the tax Split Payment); the bank's return file confirms or rejects them and reports payments, write-offs, fees and other occurrences in segments T, U, Y and X. Other services in the same standard carry electronic boleto presentment to a payer who is the bank's client, and payer claims. Each service needs its own agreement between bank and client. Version 11.0 of 2026-09-11 is marked preliminary, with a revision promised within three weeks.", "citation": "Layout Padrão Febraban 240 posições (CNAB240), version 11.0, 1.1 (p. 6); 3.2.1 events and closing note (pp. 66 to 67); 5.2 (p. 252)", "rests_on": "guidance" }, { "label": "Boletos at or above the VR-Boleto settle gross over STR the same day", "value": "For a common cobrança, proposal or deposit boleto of R$250,000.00 or more, the receiving institution passes the amount and the payment data straight to the destination institution through the BCB's STR on the day it takes the payment, one by one or aggregated, in a dedicated message of the SFN service catalog. Which catalog message that is was not identified [Unverified].", "citation": "Resolução BCB nº 443, arranjo de pagamento do boleto (consolidated), art. 16, I; art. 19", "rests_on": "rule" }, { "label": "SILOC runs on file exchange under Núclea's manuals", "value": "Participants clear through SILOC by sending and receiving standard files of transaction data. In the boleto processing stage the receiving institution sends Núclea its write-offs of paid boletos for forwarding to the destination institutions, and a destination institution sends back its returns of those write-offs; those write-offs are what the files of boletos to be settled are built from. Núclea's rulebook makes its correlated manuals part of itself and prevails over them where they disagree, and names among them a security and connectivity manual, a personal data policy, layouts manuals for the boleto clearing module and for the card service, and manuals of operations and of processing. Only two of those are published: the SILOC layouts manual, which covers no boleto transaction layout and describes just the participant relation file, sent over FTP on the national financial system network, and the GEN0015 message, which reports a participant's multilateral result and its bilateral composition after each cycle and carries both a clearing house timestamp and a movement date. The boleto layouts sit in the clearing module manual, which is not public. The 2021 convention adds that the receiving institution must mark the payment channel in the SILOC file or STR message, and treats the central database's operations and layout manuals as trade secrets given to participants on formal request.", "citation": "Regulamento Operacional do SILOC, Núclea, art. 1, the definition of correlated documents; art. 2 and its sole paragraph; art. 9, the boleto processing stage; art. 13; Manual de Leiautes do SILOC, MAPX-OP082-2019, Núclea, sections 1, 5, 9, 10 and 11; Liquidação de Operações de Crédito, SILOC (Núclea product page), FAQ; Convenção da Cobrança, FB-0061/2021 (boleto convention of 5 February 2021), art. 2 §§1 and 2; art. 72", "rests_on": "rule" }, { "label": "A Pix QR code on a boleto", "value": "The Febraban file standard lets a beneficiary's bank register a boleto with a Pix QR code. The distribution field has one value for the bank registering while the client distributes the QR-coded boleto and another for the bank doing both. The Pix key type, the key or QR code URL and the transaction identifier travel in the optional segment Y-04. The return file reports whether the title was registered with or without a QR code, rejects keys that are invalid, absent from the DICT directory or incompatible with the CNPJ, and duplicate or unknown transaction identifiers (list A, P1 to P9), and reports a title settled via Pix (list C, 61).", "citation": "Layout Padrão Febraban 240 posições (CNAB240), version 11.0, C010 (pp. 172 to 173); segment Y-04 (p. 74); C047 lists A and C (pp. 181 to 182)", "rests_on": "guidance" } ], "exceptions": [ "The STR message code used for boletos was not identified [Unverified]." ], "applies_to": "The boleto de pagamento in Brazil, in reais: common and dynamic cobrança boletos, proposal boletos and deposit boletos, among institutions authorised by the BCB", "caveat": "CNAB240 codes are bank-to-client file codes, not interbank reason codes.", "related": [ "pix:messages" ], "basis": { "sources": "Res. BCB 443 arts. 3, 7, 10 and 16; 2021 convention arts. 2, 5, 11, 14, 17 and 72; CNAB240 v11.0 1.1, 3.2.1, C010, C047, G063, segment Y-04 and 5.2; Núclea SILOC page and PFMI report v4; read 2026-09-19. Núclea SILOC operating rulebook, edition 02.01.2026, arts. 1, 2 and 9, and SILOC layouts manual version 9.0, read 2026-09-20.", "confidence": "medium" }, "currency": { "effective_since": "2025-02-03", "effective_to": null, "effective_note": "Redrafted 2026-09-20 to say what the SILOC files carry and which of Núclea's layout manuals are public, from its SILOC operating rulebook version 4.0 of 2026-01-02 and its SILOC layouts manual version 9.0. The date stays the day Res. BCB 443 entered into force (art. 26); lines from the 2021 convention, CNAB240 and Núclea carry their own dates in their Rules.", "source_edition": "Res. BCB 443 consolidated version 3.0 and IN BCB 611; the 2021 Convenção da Cobrança; CNAB240 version 11.0 (preliminary); Febraban's Nova Plataforma de Boletos page; Núclea's SILOC page and PFMI report version 4; all read 2026-09-19; Regulamento Operacional do SILOC version 4.0 of 02.01.2026 and Manual de Leiautes do SILOC version 9.0 of 2026-02-27, read 2026-09-20", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www2.nuclea.com.br/Compliance/MAPX-OP082-2019%20-%20Manual%20de%20Leiautes%20do%20SILOC.pdf", "source_class": "authoritative_primary", "source_title": "Manual de Leiautes do SILOC, MAPX-OP082-2019, Núclea", "checked_on": "2026-09-20", "checked_by": "validator-boleto-2026-09-20", "notes": "Confirms the published SILOC layouts manual covers only the participant relation file and the GEN0015 multilateral result message, and carries no boleto transaction layout." } ] }, "rail_name": "Boleto (Brazil payment slip arrangement)", "governing_authority": "Banco Central do Brasil (BCB)", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "boleto:participants", "id": "participants", "rail": "boleto", "kind": "rail-fact", "facet": "participants", "name": "Who takes part in the boleto arrangement?", "statement": "Institutions authorised by the BCB: those offering accounts may issue, receive and be destination; others may only receive or be destination for cobrança boletos they are beneficiary of. The parties are payer, beneficiary, the rights holder of a dynamic boleto and third-party enablers. Núclea runs SILOC and the central database, the BCB runs STR and regulates, and associations write the convention under a governance structure the BCB oversees. Dynamic boletos link to recording and registry systems for electronic duplicatas and real-estate receivables.", "details": [ { "label": "Who may take part, and in which roles", "value": "Only institutions the BCB authorises may take part. Those offering deposit or prepaid payment accounts may be issuing, receiving and destination institutions; those offering neither may be only receiving or destination institution, and only for cobrança boletos on which they are the beneficiary. For common cobrança, proposal and deposit boletos the destination institution is the issuer. An authorised institution not represented by the associations that made the convention must accept its terms to take part.", "citation": "Resolução BCB nº 443, arranjo de pagamento do boleto (consolidated), art. 2; art. 3 §1; art. 20 §1", "rests_on": "rule" }, { "label": "Settling directly or through a representative", "value": "A participant settles its boleto obligations directly only if it also takes part in the settlement systems concerned, STR and the netting system; otherwise it may hire an institution to represent it there. Núclea admits to SILOC institutions authorised by the BCB that hold a reserve or settlement account, after they adhere and pass technical onboarding, including mandatory tests in Núclea's test environment.", "citation": "Resolução BCB nº 443, arranjo de pagamento do boleto (consolidated), art. 15 and sole paragraph; Liquidação de Operações de Crédito, SILOC (Núclea product page), FAQ, who may take part and certification", "rests_on": "rule" }, { "label": "Dynamic boletos and the asset registries", "value": "Two asset types may be linked to a dynamic boleto: receivables from contracts for the sale or promised sale of a property unit or lot between a developer or subdivider and a buyer, with or without a real-estate credit note; and duplicatas issued in electronic form under Lei 13.775/2018. Dynamic boleto data flows centrally between the operator of the boleto settlement system and a shared platform set up by the recording, registry and depository systems, on equal terms for each, within a deadline the convention sets, covering every change including write-off, in both directions, with records that trace each link to an asset. The obligations start for each asset type 180 days after the BCB approves the first system for it, on a schedule the settlement operator agrees with the asset systems and sends to the BCB.", "citation": "Resolução BCB nº 443, arranjo de pagamento do boleto (consolidated), arts. 12, 12-A and 23; Instrução Normativa BCB nº 611, assets eligible for dynamic boletos, arts. 1 to 3", "rests_on": "rule" }, { "label": "What the participants' convention governs", "value": "Res. 443 leaves the operating detail to a convention the participants agree through their national associations, binding on every participant: devolução and acerto de diferença procedures and deadlines, data transmission hours, operating procedures, the fee and cost recovery model including central database fees, participants' rights and duties, the standards for each species and modality, and services built on data from settlement or the central database. For the dynamic boleto, the bodies that sign the asset systems' own conventions take part. The only edition found in public is the 2021 convention, made under the regulation Res. 443 replaced [Unverified: whether it is the edition in force].", "citation": "Resolução BCB nº 443, arranjo de pagamento do boleto (consolidated), art. 20, caput and §§1 and 2; Convenção da Cobrança, FB-0061/2021 (boleto convention of 5 February 2021), arts. 4 and 36; Nova Plataforma de Boletos de Pagamento, Cobrança Registrada, link to Convenção da Cobrança of 05.02.2021", "rests_on": "rule" } ], "exceptions": [ "Dynamic boleto duties start per asset type 180 days after the BCB approves the first system for that asset; the dates the BCB set by Comunicado were not read." ], "applies_to": "The boleto de pagamento in Brazil, in reais: common and dynamic cobrança boletos, proposal boletos and deposit boletos, among institutions authorised by the BCB", "caveat": "There is no single scheme owner: the BCB regulates, the participants write the convention, and Núclea operates.", "related": [ "pix:participants" ], "basis": { "sources": "Res. BCB 443 arts. 2, 3, 12, 12-A, 15, 20 and 23; IN BCB 611; 2021 convention; Núclea SILOC page; read 2026-09-19.", "confidence": "medium" }, "currency": { "effective_since": "2025-02-03", "effective_to": null, "effective_note": "Drafted 2026-09-19 in Orca Core form. The date is the day Res. BCB 443 entered into force (art. 26); lines from the 2021 convention, CNAB240 and Núclea carry their own dates in their Rules.", "source_edition": "Res. BCB 443 consolidated version 3.0 and IN BCB 611; the 2021 Convenção da Cobrança; CNAB240 version 11.0 (preliminary); Febraban's Nova Plataforma de Boletos page; Núclea's SILOC page and PFMI report version 4; all read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.bcb.gov.br/estabilidadefinanceira/exibenormativo?tipo=Resolução%20BCB&numero=443", "source_class": "authoritative_primary", "source_title": "Resolução BCB nº 443, arranjo de pagamento do boleto (consolidated)", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms the participation categories, the roles of payer, beneficiary, rights holder and enabler, the dynamic-boleto asset links, and the convention delegation, arts. 2, 3, 12, 12-A, 15, 20 and 23." }, { "source_url": "https://www.bcb.gov.br/api/conteudo/app/normativos/exibenormativo?p1=Instru%C3%A7%C3%A3o%20Normativa%20BCB&p2=611", "source_class": "authoritative_primary", "source_title": "Instrução Normativa BCB nº 611, assets eligible for dynamic boletos", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms the two eligible asset types for dynamic-boleto links, art. 1." }, { "source_url": "https://cmsarquivos.febraban.org.br/Arquivos/documentos/PDF/Conven%C3%A7%C3%A3o%20da%20Cobran%C3%A7a%20-%2005_02_2021_f.pdf", "source_class": "authoritative_primary", "source_title": "Convenção da Cobrança, FB-0061/2021 (boleto convention of 5 February 2021)", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms the associations that write the convention and CIP as the processor chosen to run SILOC and the central database, preamble." }, { "source_url": "https://www.nuclea.com.br/liquidacao-de-operacoes-de-credito-siloc/", "source_class": "public_primary", "source_title": "Liquidação de Operações de Crédito, SILOC (Núclea product page)", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms Nuclea operates SILOC and admits BCB-authorised institutions." } ] }, "rail_name": "Boleto (Brazil payment slip arrangement)", "governing_authority": "Banco Central do Brasil (BCB)", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "boleto:recall", "id": "recall", "rail": "boleto", "kind": "rail-fact", "facet": "recall", "name": "Can a boleto be withdrawn, or a payment recalled?", "statement": "Before payment, the beneficiary can withdraw a boleto by having its bank write it off, and an unpaid title lapses after the number of days set when it was registered. After payment the payer has no recall. Where a payment was taken out of conformity with the rules, the payer goes to the receiving institution, which asks the destination institution to try to reverse it; the money comes back only if it can be recovered.", "details": [ { "label": "Write-off (baixa) of an unpaid title", "value": "Before payment a title can leave collection in two ways. The beneficiary can order the bank to write it off, which the return file confirms with movement code 09 and a list C reason saying whether the order came by file or online. Or it lapses: at entry the beneficiary sets whether an unpaid title is to be written off and returned, and after how many calendar days past the due date (segment P fields 38 and 39, descriptions C028 and C029), and the return file then reports a write-off for lapse of time at the client's or the bank's term (list C, 12 and 13). A write-off withdraws the bill; it moves no money and cannot recall a payment already made.", "citation": "Layout Padrão Febraban 240 posições (CNAB240), version 11.0, segment P fields 38 and 39 (p. 69); C028 and C029 (pp. 175 to 176); C044 (p. 177); C047 list C (p. 182)", "rests_on": "guidance" }, { "label": "Payment taken out of conformity: a reversal attempt through the receiving institution", "value": "When a receiving institution has taken a boleto payment that does not conform to the convention or the central database manual, the payer is sent back to that receiving institution, which contacts the destination institution to try to reverse (estornar) the payment. If some or all of it can be recovered, the destination institution returns the money to the receiving institution, which repays the payer against a signed discharge; if not, the receiving institution answers the payer under its own procedure. The destination institution that received the settlement is responsible for returning the funds, and the amount and charges can be claimed for up to five years. Checking the boleto's data against what the receiving institution shows before paying is the payer's own responsibility.", "citation": "Convenção da Cobrança, FB-0061/2021 (boleto convention of 5 February 2021), art. 34, I to III and §§1, 3 and 5", "rests_on": "rule" } ], "exceptions": [ "A write-off withdraws the bill but moves no money." ], "applies_to": "The boleto de pagamento in Brazil, in reais: common and dynamic cobrança boletos, proposal boletos and deposit boletos, among institutions authorised by the BCB", "caveat": "Write-off codes are Febraban file codes between a bank and its client, and a bank may use its own variant [Inference].", "related": [ "boleto:return", "boleto:refund" ], "basis": { "sources": "CNAB240 v11.0 segment P, C028, C029, C044 and C047; 2021 convention art. 34; read 2026-09-19.", "confidence": "medium" }, "currency": { "effective_since": "2025-02-03", "effective_to": null, "effective_note": "Drafted 2026-09-19 in Orca Core form. The date is the day Res. BCB 443 entered into force (art. 26); lines from the 2021 convention, CNAB240 and Núclea carry their own dates in their Rules.", "source_edition": "Res. BCB 443 consolidated version 3.0 and IN BCB 611; the 2021 Convenção da Cobrança; CNAB240 version 11.0 (preliminary); Febraban's Nova Plataforma de Boletos page; Núclea's SILOC page and PFMI report version 4; all read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://cmsarquivos.febraban.org.br/Arquivos/documentos/PDF/Layout%20padrao%20CNAB240%20V%2011_0%20-%202026_09_11.pdf", "source_class": "public_primary", "source_title": "Layout Padrão Febraban 240 posições (CNAB240), version 11.0", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms the write-off mechanism and its entry-time lapse setting, segment P, C028, C029, C044 and C047." }, { "source_url": "https://cmsarquivos.febraban.org.br/Arquivos/documentos/PDF/Conven%C3%A7%C3%A3o%20da%20Cobran%C3%A7a%20-%2005_02_2021_f.pdf", "source_class": "authoritative_primary", "source_title": "Convenção da Cobrança, FB-0061/2021 (boleto convention of 5 February 2021)", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms the reversal-attempt procedure for a non-conforming payment, art. 34." } ] }, "rail_name": "Boleto (Brazil payment slip arrangement)", "governing_authority": "Banco Central do Brasil (BCB)", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "boleto:refund", "id": "refund", "rail": "boleto", "kind": "rail-fact", "facet": "refund", "name": "Is there a refund process for boletos?", "statement": "The arrangement has no refund process. Paying a proposal boleto accepts the offer, so getting money back is between payer and beneficiary. A payer who disputes a title can lodge a claim with the beneficiary's bank, which passes it to the beneficiary to decide. A payment taken out of conformity can be reversed through the institutions only if the funds can be recovered.", "details": [ { "label": "Paying a proposal boleto accepts the offer", "value": "Paying a proposal boleto is the payer's acceptance of the obligation offered, and its due date is, for all legal purposes, the last day to accept. A paid proposal boleto has therefore formed the contract, and getting money back is a matter between payer and beneficiary under that contract and general law, not a refund inside the arrangement [Inference: Res. 443 provides no refund].", "citation": "Resolução BCB nº 443, arranjo de pagamento do boleto (consolidated), art. 4, II; art. 9, IV", "rests_on": "rule" }, { "label": "Payer claim: the beneficiary decides", "value": "A payer who disagrees with a title can lodge a claim (alegação) with the beneficiary's bank, on paper at a branch or electronically if the payer is that bank's client under the claims agreement. The bank forwards the claim to the beneficiary, who decides whether to accept it and instructs the bank. The bank does not rule on it, and nothing in Res. 443 makes anyone reverse a paid boleto [Inference: no such provision was found].", "citation": "Layout Padrão Febraban 240 posições (CNAB240), version 11.0, 3.2.1, information flow (p. 65) and payer claim events (p. 67)", "rests_on": "guidance" }, { "label": "Payment taken out of conformity: a reversal attempt through the receiving institution", "value": "When a receiving institution has taken a boleto payment that does not conform to the convention or the central database manual, the payer is sent back to that receiving institution, which contacts the destination institution to try to reverse (estornar) the payment. If some or all of it can be recovered, the destination institution returns the money to the receiving institution, which repays the payer against a signed discharge; if not, the receiving institution answers the payer under its own procedure. The destination institution that received the settlement is responsible for returning the funds, and the amount and charges can be claimed for up to five years. Checking the boleto's data against what the receiving institution shows before paying is the payer's own responsibility.", "citation": "Convenção da Cobrança, FB-0061/2021 (boleto convention of 5 February 2021), art. 34, I to III and §§1, 3 and 5", "rests_on": "rule" } ], "exceptions": [ "A boleto paid by Pix can use Pix's own refund routes (pix:refund)." ], "applies_to": "The boleto de pagamento in Brazil, in reais: common and dynamic cobrança boletos, proposal boletos and deposit boletos, among institutions authorised by the BCB", "caveat": "There is no chargeback: no provision read obliges anyone to reverse a paid boleto [Inference].", "related": [ "pix:refund", "boleto:return", "boleto:consumer-law" ], "basis": { "sources": "Res. BCB 443 arts. 4 and 9; CNAB240 v11.0 3.2.1; 2021 convention art. 34; read 2026-09-19.", "confidence": "medium" }, "currency": { "effective_since": "2025-02-03", "effective_to": null, "effective_note": "Drafted 2026-09-19 in Orca Core form. The date is the day Res. BCB 443 entered into force (art. 26); lines from the 2021 convention, CNAB240 and Núclea carry their own dates in their Rules.", "source_edition": "Res. BCB 443 consolidated version 3.0 and IN BCB 611; the 2021 Convenção da Cobrança; CNAB240 version 11.0 (preliminary); Febraban's Nova Plataforma de Boletos page; Núclea's SILOC page and PFMI report version 4; all read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.bcb.gov.br/estabilidadefinanceira/exibenormativo?tipo=Resolução%20BCB&numero=443", "source_class": "authoritative_primary", "source_title": "Resolução BCB nº 443, arranjo de pagamento do boleto (consolidated)", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms paying a proposal boleto is acceptance of the offer, so no refund route exists in the regulation, arts. 4 and 9." }, { "source_url": "https://cmsarquivos.febraban.org.br/Arquivos/documentos/PDF/Layout%20padrao%20CNAB240%20V%2011_0%20-%202026_09_11.pdf", "source_class": "public_primary", "source_title": "Layout Padrão Febraban 240 posições (CNAB240), version 11.0", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms the payer's claim route through the beneficiary's bank, 3.2.1." }, { "source_url": "https://cmsarquivos.febraban.org.br/Arquivos/documentos/PDF/Conven%C3%A7%C3%A3o%20da%20Cobran%C3%A7a%20-%2005_02_2021_f.pdf", "source_class": "authoritative_primary", "source_title": "Convenção da Cobrança, FB-0061/2021 (boleto convention of 5 February 2021)", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms a non-conforming payment can only be reversed if the funds can be recovered, art. 34." } ] }, "rail_name": "Boleto (Brazil payment slip arrangement)", "governing_authority": "Banco Central do Brasil (BCB)", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "boleto:return", "id": "return", "rail": "boleto", "kind": "rail-fact", "facet": "return", "name": "Can a boleto payment be returned, and who returns it?", "statement": "There is no return the payer can start. A boleto's devolução runs between institutions: the destination institution sends the money back to the receiving institution through the system that settled it, by the next business day where the problem can be caught automatically (a boleto settled twice, a non-conforming payment, or a payment during a database outage that the registration does not support), and within five business days where the receiving institution itself asks, or at any time for fraud. The receiving institution then repays the payer. Before payment, a bank can reject a beneficiary's title at entry, so it never becomes payable.", "details": [ { "label": "Devoluções and adjustments run through the system that settled the original", "value": "When the destination institution sends money back to the receiving institution (devolução), or the two settle a difference in amount (acerto de diferença), they must use the same system that settled the original payment, STR or the netting system, under that system's procedures and hours.", "citation": "Resolução BCB nº 443, arranjo de pagamento do boleto (consolidated), art. 18", "rests_on": "rule" }, { "label": "Automatable devoluções and adjustments by the next business day", "value": "Where the problem behind a devolução or an acerto de diferença is one that can be detected automatically, the transfer must be made no later than the business day after the original settlement.", "citation": "Resolução BCB nº 443, arranjo de pagamento do boleto (consolidated), art. 18 §1", "rests_on": "rule" }, { "label": "Grounds and deadlines for devolução under the 2021 convention", "value": "The 2021 convention sorts devoluções into two groups. Grounds that can be caught automatically must be sent back through the original system by the business day after settlement: a payment taken during a declared outage of the central database for a boleto the database does not hold or holds with different data, a boleto settled twice, or a payment the convention treats as non-conforming. Payments taken at a teller or a banking correspondent during such an outage, within the outage parameters, cannot be sent back. Separately, the receiving institution may ask for the amount of a boleto paid in its own network to come back, within five business days of the payment, or at any time where there is evidence of fraud. After a devolução the receiving institution makes the money available to the payer within one business day and, where it can, tells the payer what happened.", "citation": "Convenção da Cobrança, FB-0061/2021 (boleto convention of 5 February 2021), arts. 24 §3, 25 §2, 31 and 32; annexes VI and VII", "rests_on": "rule" }, { "label": "The issuing bank may reject a title at entry", "value": "When a beneficiary registers a title through a CNAB240 remittance file, the bank answers in its return file with movement code 02 (entry confirmed) or 03 (entry rejected); a rejection names up to five occurrence reasons from list A of field C047, such as invalid data, a duplicate number or a setting the portfolio does not allow. A rejected title is not registered, and under the 2021 convention a boleto may be presented only after registration, so it cannot be paid. Each bank offers the standard under its own agreement with the client, so a bank's codes may differ [Inference]; these are not interbank devolução reasons.", "citation": "Layout Padrão Febraban 240 posições (CNAB240), version 11.0, 3.2.1 events (p. 66) and closing note (p. 67); C044 (p. 177); C047 list A (pp. 179 to 181); Convenção da Cobrança, FB-0061/2021 (boleto convention of 5 February 2021), art. 11 §2", "rests_on": "guidance" } ], "exceptions": [ "A boleto paid by Pix is returned under Pix's rules (pix:return).", "Under the 2021 convention a payment taken at a teller or a banking correspondent during a declared database outage cannot be sent back." ], "applies_to": "The boleto de pagamento in Brazil, in reais: common and dynamic cobrança boletos, proposal boletos and deposit boletos, among institutions authorised by the BCB", "caveat": "A boleto devolução is not a Pix devolução: on Pix the recipient makes a new payment back; for a boleto the settlement itself is returned between institutions.", "related": [ "pix:return", "boleto:recall", "boleto:refund" ], "basis": { "sources": "Res. BCB 443 art. 18; 2021 convention arts. 11, 24, 25, 31 and 32 and annexes VI and VII; CNAB240 v11.0 3.2.1, C044 and C047; read 2026-09-19.", "confidence": "medium" }, "currency": { "effective_since": "2025-02-03", "effective_to": null, "effective_note": "Drafted 2026-09-19 in Orca Core form. The date is the day Res. BCB 443 entered into force (art. 26); lines from the 2021 convention, CNAB240 and Núclea carry their own dates in their Rules.", "source_edition": "Res. BCB 443 consolidated version 3.0 and IN BCB 611; the 2021 Convenção da Cobrança; CNAB240 version 11.0 (preliminary); Febraban's Nova Plataforma de Boletos page; Núclea's SILOC page and PFMI report version 4; all read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.bcb.gov.br/estabilidadefinanceira/exibenormativo?tipo=Resolução%20BCB&numero=443", "source_class": "authoritative_primary", "source_title": "Resolução BCB nº 443, arranjo de pagamento do boleto (consolidated)", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms the interbank devolucao runs from destination to receiving institution through the original settlement system, art. 18." }, { "source_url": "https://cmsarquivos.febraban.org.br/Arquivos/documentos/PDF/Conven%C3%A7%C3%A3o%20da%20Cobran%C3%A7a%20-%2005_02_2021_f.pdf", "source_class": "authoritative_primary", "source_title": "Convenção da Cobrança, FB-0061/2021 (boleto convention of 5 February 2021)", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms the automatable and receiving-institution devolucao grounds and deadlines, arts. 11, 24, 25, 31 and 32 and annexes VI and VII." } ] }, "rail_name": "Boleto (Brazil payment slip arrangement)", "governing_authority": "Banco Central do Brasil (BCB)", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "boleto:settlement", "id": "settlement", "rail": "boleto", "kind": "rail-fact", "facet": "settlement", "name": "How and when does a boleto settle between institutions?", "statement": "The route depends on amount and species. Common, proposal and deposit boletos of R$250,000.00 or more settle gross over the BCB's STR the same day. Below that the receiving institution chooses STR or multilateral netting, and dynamic boletos always net. Netting is SILOC, run by Núclea, which settles net positions in central bank money through the STR. SILOC gives boletos two cycles a business day: the afternoon one pays net credits out at 16:10 on the date its payments were processed, and the morning one at 08:20 on the business day after. An institution that does not fund its debit position is dropped from that cycle rather than holding it up. When the beneficiary is credited is up to its contract with its bank.", "details": [ { "label": "Boletos at or above the VR-Boleto settle gross over STR the same day", "value": "For a common cobrança, proposal or deposit boleto of R$250,000.00 or more, the receiving institution passes the amount and the payment data straight to the destination institution through the BCB's STR on the day it takes the payment, one by one or aggregated, in a dedicated message of the SFN service catalog. Which catalog message that is was not identified [Unverified].", "citation": "Resolução BCB nº 443, arranjo de pagamento do boleto (consolidated), art. 16, I; art. 19", "rests_on": "rule" }, { "label": "Below the VR-Boleto: multilateral netting or STR, at the receiving institution's choice", "value": "A common cobrança, proposal or deposit boleto under R$250,000.00 may be settled by multilateral netting in a settlement system the BCB has authorised, or over STR as a large boleto would be; the receiving institution picks. On the netting route, the receiving institution's notice of payments to the destination institution and any notice of devolução coming back both follow the procedures and hours in that settlement system's own rules. The 2021 convention names SILOC as the netting system.", "citation": "Resolução BCB nº 443, arranjo de pagamento do boleto (consolidated), art. 16, II and §3; Convenção da Cobrança, FB-0061/2021 (boleto convention of 5 February 2021), art. 27, I and II and §2", "rests_on": "rule" }, { "label": "Dynamic boletos always settle by multilateral netting", "value": "A dynamic cobrança boleto has no STR route: whatever its amount, it settles by multilateral netting in a BCB-authorised settlement system. When it is linked to an asset, the settlement flow takes the current destination institution, beneficiary and receiving account from the system where the asset is recorded, registered or deposited, and tells that system when the boleto is settled or anything else happens to it. The asset systems may not charge for either step.", "citation": "Resolução BCB nº 443, arranjo de pagamento do boleto (consolidated), art. 17 and §§1 and 2", "rests_on": "rule" }, { "label": "SILOC nets multilaterally and settles in central bank money", "value": "SILOC, operating since 2004, clears interbank boleto items, together with card and ATM items: participants exchange files of transaction data, SILOC works out each institution's net position against all the others, and each institution pays or receives only that net amount. Settlement is in central bank money, through settlement accounts held at the BCB and the STR.", "citation": "Liquidação de Operações de Crédito, SILOC (Núclea product page), O que é o SILOC; Como funciona o processo; FAQ; Relatório Divulgação PFMI CPSS-IOSCO, Núclea, version 4, section 4, a.2 (p. 4); principle 9, KC 1 (p. 18)", "rests_on": "guidance" }, { "label": "SILOC settles boletos in two cycles: 16:10 the same business day, 08:20 the next", "value": "Núclea's SILOC rulebook gives boleto settlement two cycles on a business day. Money reaches the institutions in net credit at 08:20 in the first cycle and at 16:10 in the second, transferred over the STR out of Núclea's own settlement account at the BCB. Each transfer is preceded by Núclea asking the institutions in net debit to fund their positions, at 07:00 for the first cycle and 15:20 for the second, and by a deposit window that closes at 08:00 and 15:50. Núclea's SILOC manual of operations says which day's payments each cycle carries. The afternoon cycle settles on the same date its payments were processed: its last partial clearing result goes out at 15:00 and the final one by 15:05, and the money moves at 16:10. The morning cycle settles on the business day after processing: its partial clearing result goes out by 01:00 (02:00 after a national holiday) and its final one by 05:10, ahead of the 08:20 transfer. So a boleto on the netting route settles the same day when its payment is processed in time for the afternoon cycle, and the next business day morning otherwise. The exact clock time at which a payment stops counting for the afternoon cycle is left by the manual to a separate SILOC processing manual, which Orca has not read; that the afternoon partials close at about 15:00 is [Inference] from the clearing timetable.", "citation": "Regulamento Operacional do SILOC, Núclea, art. 14, the boleto funds transfer stage table; arts. 8, 9, 13 and 38 on the stages and where their routines and deadlines sit; Manual de Operações do SILOC (MAPX-OP002-2004), Núclea, section 11.1, the boleto (Cobrança) settlement cycle and its stages, and 11.1.1, the timetable split between the settlement stages that fall on the next business day and those on the date of processing (pp. 20 to 25); Liquidação de Operações de Crédito, SILOC (Núclea product page), Formas de Liquidação; Relatório Divulgação PFMI CPSS-IOSCO, Núclea, version 4, principle 8, KC 2 (p. 17)", "rests_on": "rule" }, { "label": "A participant that does not fund its SILOC position is dropped from that cycle", "value": "A cycle is not held up for an institution that fails to fund its net debit position in full and on time. That institution is taken out of the cycle, Núclea reports it to the BCB and tells every other participant, and the multilateral positions are worked out again with everything the defaulter sent and was to receive left out. The institutions still in the cycle then have 15 minutes after the ordinary deposit deadline to pay or top up whatever the new positions ask of them, and if one of them also fails the whole procedure repeats, with the BCB's agreement extending both the deposit window and the credit transfer by a further 15 minutes each time. An institution that deposits less than it was asked gets that money back at the credit transfer step, and so does one that deposits more. Núclea also fines it. The first breach draws a warning letter. The second draws a fine of a tenth of the institution's processing fees for the previous month or R$60,000.00, whichever is larger; the third, that same tenth or twice the second fine, whichever is larger; the fourth and any after it, that same tenth or twice the third fine, whichever is larger, with up to two business days of suspension available in place of the fine. Breaches are counted over the previous 12 months. The institution also owes Núclea the cost of recomputing everyone else's positions. An appeal goes to Núclea's board within 7 business days and suspends the penalty while it is heard.", "citation": "Regulamento Operacional do SILOC, Núclea, arts. 12, 17 and 18; art. 32 and its §§1 and 2; art. 33", "rests_on": "rule" }, { "label": "Three relationships carry the rights and duties over a boleto", "value": "Res. 443 sends rights and duties over a boleto to three places. Between receiving and destination institution: Res. 443 first, then the convention and the rules of the settlement system used, where they do not conflict with it. Between issuing institution and beneficiary: their contract, including when the beneficiary is credited; where the issuer lets the beneficiary send proposal boletos, that contract must oblige the beneficiary to obtain the payer's prior wish to receive them. Between issuing institution and any third-party enabler: their contract, including when the enabler is credited and what information it gives the issuer for its legal duties.", "citation": "Resolução BCB nº 443, arranjo de pagamento do boleto (consolidated), art. 22 and sole paragraph", "rests_on": "rule" } ], "exceptions": [ "A netting-route boleto processed too late for the afternoon SILOC cycle waits for the next business day's morning cycle; the exact cut-off sits in a SILOC processing manual Orca has not read.", "In an emergency, and with the BCB's agreement, Núclea may move a cycle's times or settle it on a later business day while holding the system's reference date.", "A boleto paid by Pix settles as a Pix (pix:settlement)." ], "applies_to": "The boleto de pagamento in Brazil, in reais: common and dynamic cobrança boletos, proposal boletos and deposit boletos, among institutions authorised by the BCB", "caveat": "The VR-Boleto routes a boleto between STR and netting; it does not cap its amount.", "related": [ "pix:settlement", "boleto:finality", "boleto:hours" ], "basis": { "sources": "Res. BCB 443 arts. 16, 17, 19 and 22; 2021 convention art. 27; Núclea SILOC page and PFMI report v4; read 2026-09-19. Núclea SILOC operating rulebook, edition 02.01.2026, arts. 9, 14, 17, 18 and 31, read 2026-09-20. Núclea SILOC manual of operations MAPX-OP002-2004, version 31.0, sections 11.1 and 11.1.1, read 2026-09-22.", "confidence": "medium" }, "currency": { "effective_since": "2025-02-03", "effective_to": null, "effective_note": "Redrafted 2026-09-20 on Núclea's SILOC operating rulebook, version 4.0 of 2026-01-02, which gives the cycle times and the treatment of a participant that does not fund its position. The date stays the day Res. BCB 443 entered into force (art. 26); lines from the 2021 convention, CNAB240 and Núclea carry their own dates in their Rules.", "source_edition": "Res. BCB 443 consolidated version 3.0 and IN BCB 611; the 2021 Convenção da Cobrança; CNAB240 version 11.0 (preliminary); Febraban's Nova Plataforma de Boletos page; Núclea's SILOC page and PFMI report version 4; all read 2026-09-19; Regulamento Operacional do SILOC, version 4.0, dated 02.01.2026, read 2026-09-20", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www2.nuclea.com.br/ProdutosIMF/Regulamento%20Operacional%20do%20SILOC.pdf", "source_class": "authoritative_primary", "source_title": "Regulamento Operacional do SILOC, Núclea", "checked_on": "2026-09-20", "checked_by": "validator-boleto-2026-09-20", "notes": "Confirms SILOC settles boletos in two cycles a business day, paying net credits at 08:20 and 16:10 through Núclea's STR settlement account, and that a participant failing to fund its debit position is dropped from the cycle rather than holding up the others." }, { "source_url": "https://www2.nuclea.com.br/Compliance/MAPX-OP002-2004%20-%20Manual%20de%20Opera%C3%A7%C3%B5es%20do%20SILOC.pdf", "source_class": "public_primary", "source_title": "Manual de Operações do SILOC (MAPX-OP002-2004), Núclea", "checked_on": "2026-09-23", "checked_by": "validator-opus-2026-09-23", "notes": "Confirms from version 31.0 sections 11.1 and 11.1.1 that SILOC runs two boleto cycles a business day, the afternoon one paying net credits at 16:10 on the date of processing and the morning one at 08:20 on the next business day, so a payment that misses the afternoon cycle waits for the next morning; that a participant which does not fund its debit position is excluded and the others' positions recalculated without it; and that the clearing stage detail, where the processing cut-off would sit, is left to the SILOC processing manual." } ] }, "rail_name": "Boleto (Brazil payment slip arrangement)", "governing_authority": "Banco Central do Brasil (BCB)", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "ca-acss:consumer-law", "id": "consumer-law", "rail": "ca-acss", "kind": "rail-fact", "facet": "consumer-law", "name": "What consumer protection law applies to AFT and pre-authorized debits?", "statement": "Unverified in the main. The payor's refund rights come from Payments Canada's own Rule H1, which states that it and every PAD agreement are subject to applicable consumer protection law, without naming any. No federal statute read governs AFT the way a consumer payments law might. Provincial consumer protection statutes and the federal financial consumer protection framework for banks were not read.", "details": [ { "label": "The rule defers to consumer law", "value": "Rule H1 and its appendices, and each PAD agreement, are subject to all applicable law, including consumer protection law.", "citation": "Payments Canada Rule H1, as amended in force 2026-07-27, s.2 and Appendix II introduction", "rests_on": "rule" }, { "label": "Authorization is defined by reference to law", "value": "An authorization is a payor's consent given in accordance with applicable law, from a payor whose identity was checked by commercially reasonable methods.", "citation": "Payments Canada Rule H1, as amended in force 2026-07-27, s.5(a) and (e)", "rests_on": "rule" }, { "label": "The rules' own consumer-facing rights", "value": "Personal PADs cover household payments such as utilities, mortgages, loans and card bills, and carry the 90 day reimbursement claim; every agreement must tell the payor about it and about their right to cancel.", "citation": "Payments Canada Rule H1, as amended in force 2026-07-27, ss.5(n) and 24(a); Appendix II, mandatory cancellation and recourse elements", "rests_on": "rule" }, { "label": "Users' interests in the statute", "value": "The Canadian Payments Act tells the Association to take users' interests into account while promoting efficient, safe and sound systems; it gives users no direct right of action [Inference].", "citation": "Canadian Payments Act, R.S.C. 1985, c. C-21, Justice Laws text current to 2026-07-21, s.5(2)", "rests_on": "law" }, { "label": "Government oversight of the rules", "value": "A new or amended rule cannot take effect until 30 days after a copy goes to the Minister of Finance, unless the Minister brings it in sooner; the Minister may extend that review and may disallow all or part of a rule.", "citation": "Canadian Payments Act, R.S.C. 1985, c. C-21, Justice Laws text current to 2026-07-21, s.19.2(1) to (3)", "rests_on": "law" } ], "exceptions": [ "Quebec and other provinces have consumer protection statutes that may reach pre-authorized debits; none were read [Unverified].", "The Bank Act financial consumer protection framework and the Financial Consumer Agency of Canada's guidance were not read [Unverified].", "Business PADs are defined by commercial purpose, so a business payor's rights may rest on the rule alone [Inference]." ], "applies_to": "payors and payees who are consumers, in Canadian dollar AFT and pre-authorized debits", "caveat": "Do not read the absence of law here as an absence of rights. This facet is a known gap; the rule's own refund claim is in the refund fact.", "related": [ "ca-acss:refund", "ca-acss:participants", "ca-acss:916" ], "basis": { "sources": "Payments Canada Rule H1, as amended in force 2026-07-27 ss.2, 5, 24 and Appendix II; Canadian Payments Act, R.S.C. 1985, c. C-21, Justice Laws text current to 2026-07-21 ss.5(2) and 19.2, read on Justice Laws 2026-09-18. No provincial statute and no Bank Act provision was read.", "confidence": "low" }, "currency": { "effective_since": "Long-standing", "effective_note": "The provisions cited are in the editions listed in source_edition, which were the posted versions on 2026-09-18; Payments Canada's rules index states that posted versions are those in force. The date each provision first applied was not established [Unverified].", "source_edition": "Payments Canada Rule H1, as amended in force 2026-07-27; Canadian Payments Act, R.S.C. 1985, c. C-21, Justice Laws text current to 2026-07-21", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.payments.ca/sites/default/files/h1eng.pdf", "source_class": "authoritative_primary", "source_title": "Payments Canada Rule H1, Pre-Authorized Debits (PADs), as amended, in force 2026-07-27", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms Rule H1 and every PAD agreement are subject to all applicable law, including consumer protection law, without naming any specific statute; confirms an authorization must be given in accordance with applicable law by a payor whose identity was checked by commercially reasonable methods; and confirms Personal PADs carry the 90 calendar day reimbursement claim referenced elsewhere in Rule H1. Does not name or describe any specific federal or provincial consumer protection statute." }, { "source_url": "https://laws-lois.justice.gc.ca/eng/acts/C-21/FullText.html", "source_class": "authoritative_primary", "source_title": "Canadian Payments Act, R.S.C. 1985, c. C-21, Justice Laws consolidated text current to 2026-07-21", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the Association must, in pursuing its objects, take the interests of users into account while promoting the efficiency, safety and soundness of its clearing and settlement systems (s.5(2)), and confirms a new or amended rule is held back 30 days after being sent to the Minister of Finance, who may extend that review or disallow the rule (s.19.2). Does not give users a direct right of action; none is stated in the sections read." } ] }, "rail_name": "Canada ACSS (Automated Funds Transfer)", "governing_authority": "Payments Canada", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "ca-acss:decision-points", "id": "decision-points", "rail": "ca-acss", "kind": "rail-fact", "facet": "decision-points", "name": "Where do the rules leave the outcome to an institution or a person?", "statement": "Canadian AFT is heavily rule-bound, but several steps turn on judgement. The payor's institution decides how fast 'best efforts' is and whether a claim fits a declared ground; the payee has no rules route to contest a refund; a sponsoring institution decides whether to offer recourse on Funds Transfer PADs; and receiving institutions choose whether to reject stale debits, check names or answer small traces.", "details": [ { "label": "How fast a refund is paid", "value": "The payor's institution must refund a claim on a best efforts basis at once, which leaves the pace to its judgement.", "citation": "Payments Canada Rule H1, as amended in force 2026-07-27, s.24(a)", "rests_on": "rule" }, { "label": "Whether a claim fits a ground", "value": "The payor's institution must accept a claim made under one of the declared conditions; [Inference] whether a particular complaint fits one is its call, on the payor's signed or recorded claim.", "citation": "Payments Canada Rule H1, as amended in force 2026-07-27, s.24(b) and (c)", "rests_on": "rule" }, { "label": "Whether the payee can fight back", "value": "A payee that disputes a payor's claim has no route inside the rules; the outcome is settled between payor and payee.", "citation": "Payments Canada Rule H1, as amended in force 2026-07-27, s.27", "rests_on": "rule" }, { "label": "Whether evidence of an agreement is requested", "value": "The payor's institution may ask for a copy of a PAD agreement on reasonable grounds, and the sponsor must make every reasonable effort to supply it within a reasonable time.", "citation": "Payments Canada Rule H1, as amended in force 2026-07-27, s.13", "rests_on": "rule" }, { "label": "What counts as a proper identity check", "value": "Commercially reasonable methods of verifying a payor are measured against what is usual for similar business in the circumstances, such as the size of the payment or how practised the parties are, not against a fixed standard.", "citation": "Payments Canada Rule H1, as amended in force 2026-07-27, s.5(e)", "rests_on": "rule" }, { "label": "Whether Funds Transfer PADs carry recourse", "value": "An institution issuing Funds Transfer PADs may opt out of recourse by coding them 650.", "citation": "Payments Canada Rule H1, as amended in force 2026-07-27, s.25(a)", "rests_on": "rule" }, { "label": "Whether a stale debit is rejected", "value": "A receiving direct clearer may, but need not, reject a debit dated more than 173 days before its file.", "citation": "Payments Canada Rule F1, as amended in force 2026-07-27, Part II, 'Transaction Edit, Account Validation and Rejected Transactions' (d)(ii)", "rests_on": "rule" }, { "label": "Whether to stop at the first file error", "value": "A receiving direct clearer may stop processing a file once it finds any reason to reject it.", "citation": "Payments Canada Standard 005, as amended in force 2024-07-22, Section D, para 4(c)", "rests_on": "rule" }, { "label": "Whether to answer a trace", "value": "A receiving direct clearer need not answer traces under $20 or after 12 months, and may accept a trace by telephone.", "citation": "Payments Canada Rule F1, as amended in force 2026-07-27, Part IV, 'Trace Requests, Tracing Limits and Tracing Procedures'", "rests_on": "rule" }, { "label": "Whether to check the name", "value": "The payor or payee name on an AFT item is for information only, so whether a mismatch leads to a 914 return is the receiving institution's choice [Inference].", "citation": "Payments Canada Standard 005, as amended in force 2024-07-22, amendment list item 9", "rests_on": "rule" }, { "label": "How a default is shared", "value": "Default contributions are calculated after consultation between Payments Canada's President and the Bank of Canada, and the President may set a different interest rate on them.", "citation": "Payments Canada Rule L1, as amended in force 2026-02-09, ss.13 and 17", "rests_on": "rule" } ], "exceptions": [ "This is Orca's reading of where the texts leave judgement open, not a list any authority publishes, and it caps at medium confidence for that reason.", "Decisions inside By-law No. 3 and the unread rules (A4, A6, D1 to D3, J10) are not listed [Unverified]." ], "applies_to": "points in the Canadian dollar AFT flow where a rule leaves the outcome to an institution's judgement or to the parties", "caveat": "None of these decisions has a published timetable or an appeal inside the rules for the payee or the payment originator.", "related": [ "ca-acss:refund", "ca-acss:return", "ca-acss:liability", "ca-acss:limits", "ca-acss:settlement", "ca-acss:914" ], "basis": { "sources": "Payments Canada Rule H1, as amended in force 2026-07-27 ss.5, 13, 24, 25 and 27; Payments Canada Rule F1, as amended in force 2026-07-27 Parts II and IV; Payments Canada Standard 005, as amended in force 2024-07-22 Section D and amendment list; Payments Canada Rule L1, as amended in force 2026-02-09 ss.13 and 17. Payments Canada PDFs fetched 2026-09-18 with a plain compressed GET and read with pypdf.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_note": "The provisions cited are in the editions listed in source_edition, which were the posted versions on 2026-09-18; Payments Canada's rules index states that posted versions are those in force. The date each provision first applied was not established [Unverified].", "source_edition": "Payments Canada Rule H1, as amended in force 2026-07-27; Payments Canada Rule F1, as amended in force 2026-07-27; Payments Canada Standard 005, as amended in force 2024-07-22; Payments Canada Rule L1, as amended in force 2026-02-09", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.payments.ca/sites/default/files/h1eng.pdf", "source_class": "authoritative_primary", "source_title": "Payments Canada Rule H1, Pre-Authorized Debits (PADs), as amended, in force 2026-07-27", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the payor's institution must reimburse a claim on a best efforts basis at once (s.24(a)); confirms it must accept a claim under one of the declared conditions on the payor's completed Reimbursement Claim (s.24(b) and (c)); confirms a payee disputing a payor's claim has no route inside the rules and must settle it with the payor directly (s.27); confirms a Processing Member may request a copy of a Payor's PAD Agreement on reasonable grounds, and the Sponsoring Member must make every reasonable effort to supply it within a reasonable time (s.13); and confirms a Member issuing Funds Transfer PADs may opt out of recourse, other than for a no-agreement claim, by coding them 650 or 83 (s.25)." }, { "source_url": "https://www.payments.ca/sites/default/files/f1eng.pdf", "source_class": "authoritative_primary", "source_title": "Payments Canada Rule F1, Rules Applicable to Automated Funds Transfer (AFT) Transactions, as amended, in force 2026-07-27", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms a debit transaction due more than 173 calendar days before the file creation date may, at the receiving direct clearer's option, be rejected; and confirms a Processing Direct Clearer need not respond to a trace request for an item under 20 dollars or received more than 12 months after the settlement date, and may accept a trace request by telephone." }, { "source_url": "https://www.payments.ca/sites/default/files/standard005eng.pdf", "source_class": "authoritative_primary", "source_title": "Payments Canada Standard 005, Standards for the Exchange of Financial Data on AFT Files, as amended, in force 2024-07-22", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms it is the option of the Processing Direct Clearer to stop processing a file upon identifying any reason for rejecting it, and confirms an amendment effective August 18, 2008 clarified that the Payor/Payee name field on an AFT credit or debit is for information purposes only." }, { "source_url": "https://www.payments.ca/sites/default/files/l1eng.pdf", "source_class": "authoritative_primary", "source_title": "Payments Canada Rule L1, Procedures Pertaining to the Default of a Direct Clearer, as amended, in force 2026-02-09", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms default contributions are calculated by the Association following consultation between the President and the Bank of Canada, and confirms amounts paid for default and additional contributions bear interest at the lower end of the Bank of Canada's overnight operating band, or such other rate as the President establishes in consultation with Direct Clearers and the Bank of Canada." } ] }, "rail_name": "Canada ACSS (Automated Funds Transfer)", "governing_authority": "Payments Canada", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "ca-acss:finality", "id": "finality", "rail": "ca-acss", "kind": "rail-fact", "facet": "finality", "name": "When is an AFT payment final, and what can still undo it?", "statement": "There is no single moment. Settlement between institutions happens on the morning after the due date and, because the ACSS is a designated system, the law protects payments made under its settlement rules from being unwound. For the customers, though, the payment stays open: an institution can return an item the next Business Day, a payee can refuse a credit for 90 days, and a payor can claim back a pre-authorized debit for up to 90 days, or 10 Business Days for a Business PAD. Rule F1 itself does not state when an AFT item becomes irrevocable.", "details": [ { "label": "Interbank settlement", "value": "Items settle on the Business Day after their due date, on the Bank of Canada's books.", "citation": "Payments Canada Rule F1, as amended in force 2026-07-27, s.40(d); Payments Canada web page 'Retail batch payment system' (payments.ca), read 2026-09-18", "rests_on": "rule" }, { "label": "Statutory protection of settlement", "value": "Payments made under the settlement rules of a designated system need not be reversed, despite other law, and the ACSS is designated. [Inference] Which ACSS rules count as its settlement rules was not confirmed.", "citation": "Payment Clearing and Settlement Act, S.C. 1996, c. 6, Sch., Justice Laws text current to 2026-07-21, s.8(1)(c); Bank of Canada web page 'Oversight of designated clearing and settlement systems' (bankofcanada.ca), read 2026-09-18", "rests_on": "law" }, { "label": "Next day returns by the institution", "value": "The payor's or payee's institution can dishonour or refuse an item until the Business Day after the first unit able to decide received it.", "citation": "Payments Canada Rule F1, as amended in force 2026-07-27, Part III, 'Time Limitation for Return'; Payments Canada Rule H1, as amended in force 2026-07-27, s.22(a)", "rests_on": "rule" }, { "label": "A payee can refuse a credit for 90 days", "value": "A payee may refuse a credit up to and including 90 calendar days after it reached their account.", "citation": "Payments Canada Rule F1, as amended in force 2026-07-27, s.19", "rests_on": "rule" }, { "label": "A payor can reclaim a PAD for up to 90 days", "value": "Where no agreement existed, 90 calendar days from the statement posting date; for a claim under an existing agreement, 90 calendar days after the debit for Personal and most Funds Transfer PADs, and 10 Business Days for Business PADs.", "citation": "Payments Canada Rule H1, as amended in force 2026-07-27, ss.23(b) and 24(a)", "rests_on": "rule" }, { "label": "Error corrections stay open too", "value": "An originating institution may correct certain errors until 3 Business Days after settlement, and the customer may refuse that correction within 90 calendar days of posting.", "citation": "Payments Canada Rule F1, as amended in force 2026-07-27, Part III, 'Time Frames for Error Correction' and 'Time Limit for Error Correction Refusal'", "rests_on": "rule" }, { "label": "A return is itself final in the clearing", "value": "Once a returned item is accepted in the receiving direct clearer's file edit, it cannot be sent back again through the clearing; any disagreement becomes an item in dispute.", "citation": "Payments Canada Rule F1, as amended in force 2026-07-27, Part III, 'Unposted/Dishonoured Transactions/Transactions Refused by Payor/Payee'", "rests_on": "rule" } ], "exceptions": [ "Cash Management PADs carry no reimbursement right except where no agreement existed (Rule H1, s.26).", "Funds Transfer PADs coded 650 may be issued with no recourse except where no agreement existed (Rule H1, s.25).", "After each window closes, a dispute moves outside the rules rather than ending; the payment can still be contested between the parties (Rule H1, ss.23(c), 24(g) and 27; Rule F1, s.19)." ], "applies_to": "Canadian dollar AFT credits and pre-authorized debits after exchange", "caveat": "Read 'final' here as final between institutions only. An agent that treats a settled PAD as safe money is wrong for up to 90 days.", "related": [ "ca-acss:settlement", "ca-acss:hours", "ca-acss:915", "ca-acss:916", "ca-acss:919", "ca-acss:922" ], "basis": { "sources": "Payments Canada Rule F1, as amended in force 2026-07-27 Parts III and V; Payments Canada Rule H1, as amended in force 2026-07-27 ss.22 to 27; Payment Clearing and Settlement Act, S.C. 1996, c. 6, Sch., Justice Laws text current to 2026-07-21 s.8, read on Justice Laws 2026-09-18; Bank of Canada web page 'Oversight of designated clearing and settlement systems' (bankofcanada.ca), read 2026-09-18; Payments Canada web page 'Retail batch payment system' (payments.ca), read 2026-09-18. No Payments Canada text read states the moment an AFT item becomes irrevocable.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_note": "The provisions cited are in the editions listed in source_edition, which were the posted versions on 2026-09-18; Payments Canada's rules index states that posted versions are those in force. The date each provision first applied was not established [Unverified].", "source_edition": "Payments Canada Rule F1, as amended in force 2026-07-27; Payments Canada Rule H1, as amended in force 2026-07-27; Payment Clearing and Settlement Act, S.C. 1996, c. 6, Sch., Justice Laws text current to 2026-07-21; Bank of Canada web page 'Oversight of designated clearing and settlement systems' (bankofcanada.ca), read 2026-09-18", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.payments.ca/sites/default/files/f1eng.pdf", "source_class": "authoritative_primary", "source_title": "Payments Canada Rule F1, Rules Applicable to Automated Funds Transfer (AFT) Transactions, as amended, in force 2026-07-27", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms an AFT item settles on the Business Day after its due date, or after the exchange date if delivered late; confirms the general return window for an institution dishonour is the Business Day after the first organizational unit able to decide received the item; confirms a payee may refuse a credit up to and including 90 calendar days after it was processed; confirms an Error Correction Transaction may be sent no later than 3 Business Days after settlement, and a customer may refuse it within 90 calendar days of posting; and confirms a returned item accepted in the file edit cannot be returned again and becomes an item in dispute. Rule F1 does not state a single moment at which an AFT item becomes irrevocable." }, { "source_url": "https://laws-lois.justice.gc.ca/eng/acts/P-4.4/FullText.html", "source_class": "authoritative_primary", "source_title": "Payment Clearing and Settlement Act, S.C. 1996, c. 6, Sch., Justice Laws consolidated text current to 2026-07-21", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms that where a payment is made in accordance with the settlement rules of a designated clearing and settlement system, the payment is not required to be reversed, repaid or set aside, despite any other statute or law of Canada or a province (s.8(1)(c)); does not state which specific ACSS rules are its settlement rules for this purpose." } ] }, "rail_name": "Canada ACSS (Automated Funds Transfer)", "governing_authority": "Payments Canada", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "ca-acss:hours", "id": "hours", "rail": "ca-acss", "kind": "rail-fact", "facet": "hours", "name": "When can AFT files be exchanged, and on which days?", "statement": "Direct clearers exchange AFT files in three periods each Business Day, closing at 09:30, 16:30 and 21:00 Eastern time, with the first period running overnight. There is no weekend or holiday exchange. When credit funds must reach the payee depends on the receiving branch's serviceability code and on which period the file arrived in.", "details": [ { "label": "Three exchange periods", "value": "The periods close at 09:30, 16:30 and 21:00 Eastern on Business Days. The 09:30 period opens just after 21:00 on the previous Business Day, so a file sent overnight counts in the morning period.", "citation": "Payments Canada Rule F1, as amended in force 2026-07-27, Part II, 'Exchange Deadlines and Periods'", "rests_on": "rule" }, { "label": "Eastern time follows Ottawa", "value": "Eastern means standard or daylight time, whichever is in force in Ottawa.", "citation": "Payments Canada Rule F1, as amended in force 2026-07-27, Introduction", "rests_on": "rule" }, { "label": "Business Days", "value": "A Business Day is any day that is not an ACSS Holiday. ACSS Holidays are every Saturday and Sunday plus ten national holidays, from New Year's Day through Boxing Day and including the National Day for Truth and Reconciliation.", "citation": "Payments Canada Introduction to the ACSS Rules, as amended in force 2026-07-27, definitions of Business Day and ACSS Holiday", "rests_on": "rule" }, { "label": "When a credit must be usable", "value": "For a branch with serviceability code 0, the payee's funds must be available within 2 hours of the exchange deadline the credit arrived by. For codes 1 and 2, and for any credit that arrives the Business Day before its due date, funds must be available when business opens on the due date. For an indirect clearer's code 0 branch, the 2 hours run from a cut-off 2 hours after the period closes.", "citation": "Payments Canada Rule F1, as amended in force 2026-07-27, s.8 and definition of IC Cut-off", "rests_on": "rule" }, { "label": "Lead time for credits", "value": "A credit to a code 0 branch goes on the due date, or the Business Day before if it is ready; code 1 and code 2 branches need it 1 or 2 Business Days early.", "citation": "Payments Canada Rule F1, as amended in force 2026-07-27, Part II, 'Credit Transaction Lead Times and Exchange'", "rests_on": "rule" }, { "label": "Debits wait for their date", "value": "A debit may not be delivered to the payor's direct clearer before its due date.", "citation": "Payments Canada Rule F1, as amended in force 2026-07-27, Part II, 'Debit Transaction Exchange Dates'", "rests_on": "rule" }, { "label": "Missing files are flagged within the hour", "value": "If an expected file has not arrived by the morning or afternoon deadline, the receiving direct clearer must say so within an hour of that deadline; for the evening period, before the next morning's deadline.", "citation": "Payments Canada Rule F1, as amended in force 2026-07-27, s.11(b) and (c)", "rests_on": "rule" } ], "exceptions": [ "A credit to an account other than a demand deposit account may be treated as if its branch had serviceability code 1 (Rule F1, s.8(d)(ii)).", "After a regional or civic holiday, settlement entries may be made until 09:30 rather than 05:00 (Rule F1, 'ACSS Entries').", "Payments Canada's system closure schedule, which lists each year's dates, was not read; the specific dates for a given year are [Unverified]." ], "applies_to": "exchange of Canadian dollar AFT files between direct clearers, and credit funds availability at the payee's institution", "caveat": "These are interbank deadlines. When a payor's or payee's own institution posts an item, and what cut-off it gives its customers, is set by that institution and was not researched.", "related": [ "ca-acss:settlement", "ca-acss:participants" ], "basis": { "sources": "Payments Canada Rule F1, as amended in force 2026-07-27 Part II (exchange periods, serviceability, lead times, funds availability s.8, debit exchange dates, file receipt s.11) and definitions; Payments Canada Introduction to the ACSS Rules, as amended in force 2026-07-27 definitions of Business Day and ACSS Holiday. Payments Canada PDFs fetched 2026-09-18 with a plain compressed GET and read with pypdf.", "confidence": "high" }, "currency": { "effective_since": "2018-09-17", "effective_note": "The third daily exchange and the current funds availability requirements came with the AFT enhancements approved 2017-06-22, in force 2018-09-17, with section 13 in force 2018-10-15 (Rule F1 amendment list). The National Day for Truth and Reconciliation is in the ACSS Holiday list as read; when it was added was not established [Unverified].", "source_edition": "Payments Canada Rule F1, as amended in force 2026-07-27; Payments Canada Introduction to the ACSS Rules, as amended in force 2026-07-27", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.payments.ca/sites/default/files/f1eng.pdf", "source_class": "authoritative_primary", "source_title": "Payments Canada Rule F1, Rules Applicable to Automated Funds Transfer (AFT) Transactions, as amended, in force 2026-07-27", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the three exchange periods close at 09:30, 16:30 and 21:00 Eastern on Business Days, with the first period running from 21:00:01 on the prior Business Day; confirms funds availability timeframes of 2 hours after the exchange deadline for serviceability code 0 branches, opening of business on the due date for codes 1 and 2 and for any credit received the prior Business Day, and 2 hours after the IC cut-off for an indirect clearer's code 0 branch, unless a prior restriction on the payee's account applies; confirms credit lead times of on or one Business Day before the due date for code 0, 1 Business Day before for code 1, and 2 Business Days before for code 2; and confirms a debit transaction may not be delivered before its due date." }, { "source_url": "https://www.payments.ca/sites/default/files/a_introduction_eng.pdf", "source_class": "authoritative_primary", "source_title": "Payments Canada Introduction to the ACSS Rules, as amended, in force 2026-07-27", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms a Business Day is any day other than an ACSS Holiday, and that an ACSS Holiday is every Saturday and Sunday plus ten named national holidays: New Year's Day, Good Friday, Victoria Day, Canada Day, Labour Day, National Day for Truth and Reconciliation, Thanksgiving Day, Remembrance Day, Christmas Day and Boxing Day. Does not address the specific calendar dates for a given year." } ] }, "rail_name": "Canada ACSS (Automated Funds Transfer)", "governing_authority": "Payments Canada", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "ca-acss:liability", "id": "liability", "rail": "ca-acss", "kind": "rail-fact", "facet": "liability", "name": "Who bears the loss when something goes wrong?", "statement": "The rules put loss on the institution that sent the item. Each member answers for every PAD it exchanges, each direct clearer for every credit it delivers, and a sponsoring institution answers for its payees' agreements and conduct. A wrong return or a wrong correction is paid back by whoever sent it. The customer relationship sits outside the rules: they allocate loss between institutions and leave institution to customer liability to agreements and the law.", "details": [ { "label": "The sender of a PAD answers for it", "value": "Each member is responsible for every PAD, or item claiming to be one, that it exchanges, and indemnifies the Association and other members for direct loss, unless the payor's institution caused the loss.", "citation": "Payments Canada Rule H1, as amended in force 2026-07-27, s.6", "rests_on": "rule" }, { "label": "The sponsor answers for its payees", "value": "An institution sponsoring a payee must get a letter of undertaking from it, check its PAD agreement forms, and indemnify others for loss from a deviating agreement, a payee that skipped commercially reasonable identity checks, or any payee breach of Rule H1.", "citation": "Payments Canada Rule H1, as amended in force 2026-07-27, ss.8, 9 and 11", "rests_on": "rule" }, { "label": "The sender of a credit answers for it", "value": "Each direct clearer is responsible for every credit, or item claiming to be one, that it delivers, and indemnifies the Association and members for loss from its own breach of the rules.", "citation": "Payments Canada Rule F1, as amended in force 2026-07-27, Part I, 'Registration' (e)", "rests_on": "rule" }, { "label": "Wrong returns and wrong corrections", "value": "The direct clearer that sends an incorrect debit return, or an incorrect error correction, pays the receiver back the value plus service or interest charges.", "citation": "Payments Canada Rule F1, as amended in force 2026-07-27, Part III, 'Accuracy and Delivery of Returned Transactions' and 'Accuracy of Error Correction Transactions'", "rests_on": "rule" }, { "label": "Re-routing is at the re-router's risk", "value": "An institution that re-routes an item bears any liability that comes directly from doing so.", "citation": "Payments Canada Rule F1, as amended in force 2026-07-27, Part III, 'Re-Routing of Transactions'", "rests_on": "rule" }, { "label": "Account change notices", "value": "A sponsoring institution is responsible to its payee for the accuracy of any notice of change it passes on.", "citation": "Payments Canada Rule H1, as amended in force 2026-07-27, s.8(c)", "rests_on": "rule" }, { "label": "A failed direct clearer's losses are shared", "value": "When a direct clearer defaults, the survivors and the Bank of Canada make contributions so the cycle can settle, within a cap set by the collateral pool.", "citation": "Payments Canada Rule L1, as amended in force 2026-02-09, ss.11 and 13", "rests_on": "rule" } ], "exceptions": [ "Losses between a payor or payee and their own institution are governed by account agreements and law, not by these rules [Inference from the rules' scope].", "Where a payee disputes a payor's refund claim, the rules give no allocation; the parties settle it themselves (Rule H1, s.27).", "By-law No. 3's default provisions, which the default contribution scheme rests on, were not read [Unverified]." ], "applies_to": "allocation of loss between institutions taking part in Canadian dollar AFT", "caveat": null, "related": [ "ca-acss:participants", "ca-acss:refund", "ca-acss:return", "ca-acss:recall", "ca-acss:settlement" ], "basis": { "sources": "Payments Canada Rule H1, as amended in force 2026-07-27 ss.6, 8, 9, 11 and 27; Payments Canada Rule F1, as amended in force 2026-07-27 Parts I and III; Payments Canada Rule L1, as amended in force 2026-02-09 ss.11 and 13. Payments Canada PDFs fetched 2026-09-18 with a plain compressed GET and read with pypdf.", "confidence": "high" }, "currency": { "effective_since": "Long-standing", "effective_note": "The provisions cited are in the editions listed in source_edition, which were the posted versions on 2026-09-18; Payments Canada's rules index states that posted versions are those in force. The date each provision first applied was not established [Unverified].", "source_edition": "Payments Canada Rule H1, as amended in force 2026-07-27; Payments Canada Rule F1, as amended in force 2026-07-27; Payments Canada Rule L1, as amended in force 2026-02-09", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.payments.ca/sites/default/files/h1eng.pdf", "source_class": "authoritative_primary", "source_title": "Payments Canada Rule H1, Pre-Authorized Debits (PADs), as amended, in force 2026-07-27", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms each Member is responsible and liable for every PAD and every Payment Item purporting to be a PAD that it exchanges, and must indemnify the Association and its Members for direct loss, costs or damages, unless caused by the Payor's institution (s.6); confirms a Sponsoring Member must obtain a Payee Letter of Undertaking and indemnify others for loss from a deviating agreement or a Payee's breach; confirms a Sponsoring Member is responsible to its Payee for the accuracy of a Notice of Change it passes on (s.8(c)); and confirms a Payee disputing a Payor's claim must settle it outside the rules (s.27)." }, { "source_url": "https://www.payments.ca/sites/default/files/f1eng.pdf", "source_class": "authoritative_primary", "source_title": "Payments Canada Rule F1, Rules Applicable to Automated Funds Transfer (AFT) Transactions, as amended, in force 2026-07-27", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms each Direct Clearer is responsible and liable for every Credit Transaction, and every Payment Item purporting to be one, that it delivers, and must indemnify the Association and its Members for direct loss, costs or damages from its own breach of the rules (Part I, Registration (e)); confirms an Originating Direct Clearer that sends an incorrect debit return or an incorrect Error Correction Transaction must reimburse the receiver its value plus service or interest charges; and confirms an institution that re-routes a transaction bears any liability that results directly from doing so." }, { "source_url": "https://www.payments.ca/sites/default/files/l1eng.pdf", "source_class": "authoritative_primary", "source_title": "Payments Canada Rule L1, Procedures Pertaining to the Default of a Direct Clearer, as amended, in force 2026-02-09", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms that on a Direct Clearer's default, surviving Direct Clearers and the Bank of Canada make Default Contributions and Additional Contributions to permit the affected cycle to settle, with the aggregate contribution from surviving Direct Clearers capped at the ACSS Collateral Pool less the defaulting clearer's own Collateral Pool Pledge." } ] }, "rail_name": "Canada ACSS (Automated Funds Transfer)", "governing_authority": "Payments Canada", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "ca-acss:limits", "id": "limits", "rail": "ca-acss", "kind": "rail-fact", "facet": "limits", "name": "Is there a maximum amount or other limit on an AFT item?", "statement": "No rule read sets a network maximum amount for an AFT item. The limits that do appear are on age and on tracing: a credit dated more than 30 days before its file must be rejected, a debit dated more than 173 days back may be, and an institution need not trace items under $20 or older than 12 months. Any amount ceiling a customer meets is set by their own institution or by the format's field size.", "details": [ { "label": "No network amount limit found", "value": "Rules F1, F4 and H1 and Standards 005 and 007 were read for this record and none sets a maximum value for an AFT credit or debit [Unverified: an absence, not a stated rule].", "citation": "Payments Canada Rule F1, as amended in force 2026-07-27; Payments Canada Rule F4, as amended in force 2026-07-27; Payments Canada Rule H1, as amended in force 2026-07-27; Payments Canada Standard 005, as amended in force 2024-07-22; Payments Canada Standard 007, amendment 10 in force 2026-07-03", "rests_on": "rule" }, { "label": "Field size", "value": "In a Standard 005 record the amount field is 10 digits long. [Inference] With two implied decimal places that caps a single item just under 100 million dollars; the decimal convention was not confirmed.", "citation": "Payments Canada Standard 005, as amended in force 2024-07-22, Section D record layouts, data element 05 'Amount'", "rests_on": "rule" }, { "label": "Old credits must be rejected", "value": "A credit whose due date is more than 30 calendar days before the file creation date must be rejected.", "citation": "Payments Canada Rule F1, as amended in force 2026-07-27, Part II, 'Transaction Edit, Account Validation and Rejected Transactions' (d)(i)", "rests_on": "rule" }, { "label": "Old debits may be rejected", "value": "A debit whose due date is more than 173 calendar days before the file creation date may be rejected, at the receiving direct clearer's option.", "citation": "Payments Canada Rule F1, as amended in force 2026-07-27, Part II, 'Transaction Edit, Account Validation and Rejected Transactions' (d)(ii)", "rests_on": "rule" }, { "label": "Tracing floor and horizon", "value": "A receiving direct clearer need not answer a trace request for an item under $20, or one received more than 12 months after settlement.", "citation": "Payments Canada Rule F1, as amended in force 2026-07-27, Part IV, 'Trace Requests, Tracing Limits and Tracing Procedures' (b) and (c)", "rests_on": "rule" } ], "exceptions": [ "Institutions set their own limits for customers and payees; none were researched.", "US dollar AFT under Rule K8 was not read." ], "applies_to": "individual Canadian dollar AFT credits and debits", "caveat": "This is an absence finding. Before relying on it for a large payment, check with the institutions involved.", "related": [ "ca-acss:messages", "ca-acss:hours", "ca-acss:900" ], "basis": { "sources": "Payments Canada Rule F1, as amended in force 2026-07-27 Parts II and IV; Payments Canada Rule F4, as amended in force 2026-07-27; Payments Canada Rule H1, as amended in force 2026-07-27; Payments Canada Standard 005, as amended in force 2024-07-22 Section D record layouts; Payments Canada Standard 007, amendment 10 in force 2026-07-03. Payments Canada PDFs fetched 2026-09-18 with a plain compressed GET and read with pypdf.", "confidence": "medium" }, "currency": { "effective_since": "2026-07-27", "effective_note": "2026-07-27 is the in-force date of the Rule F1 edition read, not the date these provisions began; their first effective dates were not established [Unverified]. The tracing wording was clarified by amendments in force 2025-04-28 (Rule F1 amendment list).", "source_edition": "Payments Canada Rule F1, as amended in force 2026-07-27; Payments Canada Rule F4, as amended in force 2026-07-27; Payments Canada Rule H1, as amended in force 2026-07-27; Payments Canada Standard 005, as amended in force 2024-07-22; Payments Canada Standard 007, amendment 10 in force 2026-07-03", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.payments.ca/sites/default/files/f1eng.pdf", "source_class": "authoritative_primary", "source_title": "Payments Canada Rule F1, Rules Applicable to Automated Funds Transfer (AFT) Transactions, as amended, in force 2026-07-27", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms no maximum value for an AFT credit or debit was stated in the Parts of Rule F1 read; confirms a credit transaction with a due date more than 30 calendar days before the file creation date must be rejected, and a debit transaction with a due date more than 173 calendar days before may be rejected; and confirms a Processing Direct Clearer need not respond to a trace request for an item under 20 dollars or received more than 12 months after the settlement date." }, { "source_url": "https://www.payments.ca/sites/default/files/standard005eng.pdf", "source_class": "authoritative_primary", "source_title": "Payments Canada Standard 005, Standards for the Exchange of Financial Data on AFT Files, as amended, in force 2024-07-22", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the Amount data element in a Standard 005 logical record is a 10 position numeric field. Does not state the number of implied decimal places." } ] }, "rail_name": "Canada ACSS (Automated Funds Transfer)", "governing_authority": "Payments Canada", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "ca-acss:messages", "id": "messages", "rail": "ca-acss", "kind": "rail-fact", "facet": "messages", "name": "What files and messages carry AFT payments and returns?", "statement": "AFT runs in two formats side by side. The older one is the Standard 005 file of fixed-length records, governed by Rule F1; the newer one is ISO 20022 messages, governed by Rule F4 and Payments Canada's ISO AFT Usage Guidelines. In both, a return carries a three-digit Standard 007 reason code, and every payment carries a three-digit transaction code telling the customer what kind of payment it is.", "details": [ { "label": "Two formats, two rules", "value": "Rule F1 covers AFT exchanged as Standard 005 files; Rule F4 covers the same payments exchanged as ISO 20022 messages built to the ISO AFT Usage Guidelines. Standard 007 applies to both.", "citation": "Payments Canada Rule F1, as amended in force 2026-07-27, Introduction and Scope; Payments Canada Rule F4, as amended in force 2026-07-27, Part III; Payments Canada Standard 007, amendment 10 in force 2026-07-03, paras 1 and 2", "rests_on": "rule" }, { "label": "What the Standard 005 records do", "value": "Payments go as credit records (type C) and PAD records (type D). Corrections go as type E, a debit that reverses a credit, and type F, a credit that reverses a PAD. Returns go as type I for credits and type J for debits. Notices of change to account details use type S inside their own U and V header and trailer, and every payment file opens with an A record and closes with a Z.", "citation": "Payments Canada Standard 005, as amended in force 2024-07-22, Section D, purpose statement of each logical record type", "rests_on": "rule" }, { "label": "Where the return code sits in a Standard 005 return", "value": "On a return record the transaction type field holds the 900-series reason code, and the original transaction code moves to the stored transaction type field.", "citation": "Payments Canada Standard 005, as amended in force 2024-07-22, Section D data element dictionary, 'Transaction Type' and 'Stored Transaction Type'", "rests_on": "rule" }, { "label": "Where the return code sits in an ISO return", "value": "The ISO return is a restricted pacs.004.001.06. The Standard 007 code goes in the proprietary reason element of each transaction's return reason, drawn from a Payments Canada code list; the ISO external code element is removed.", "citation": "Payments Canada ISO AFT Usage Guidelines Part C (Payment Return), portfolio dated 2017-01-31, sections 5.82.1, 5.82.2 and 6.20", "rests_on": "rule" }, { "label": "Correction and account-change messages have ISO twins", "value": "Rule F1's error correction is the ISO AFT payment reversal, and its notice of change is the ISO identification modification advice.", "citation": "Payments Canada Rule F1, as amended in force 2026-07-27, definitions of Error Correction Transaction and Notice of Change (NOC), with their notes", "rests_on": "rule" }, { "label": "Transaction codes tell the customer what the payment is", "value": "A payment originator marks each payment with a three-digit transaction code; the originating direct clearer must pass it on unchanged, and any description given to the customer must show at least the generic type. The codes also mark which PADs are Business, Cash Management or opted-out Funds Transfer PADs, which changes the payor's rights.", "citation": "Payments Canada Standard 007, amendment 10 in force 2026-07-03, paras 3 and 4; Payments Canada Standard 005, as amended in force 2024-07-22, data element dictionary, 'Transaction Type'; Payments Canada Rule H1, as amended in force 2026-07-27, s.20(a)", "rests_on": "rule" } ], "exceptions": [ "The ISO AFT Usage Guidelines Part C code list (2017) omits 990 and gives 912 the wrong label; Standard 007 governs.", "Only Part C of the ISO AFT Usage Guidelines was read. The message identifiers of Parts A, B, D and E are not asserted [Unverified].", "Paper PADs travel as paper items under the A rules and Standard 006, not as AFT, and stop being exchangeable on 2028-12-01 (Rule H1, s.2 note and s.20(b))." ], "applies_to": "Canadian dollar AFT exchanged between direct clearers in Standard 005 files or ISO 20022 AFT messages", "caveat": null, "related": [ "ca-acss:participants", "ca-acss:900", "ca-acss:915", "ca-acss:922" ], "basis": { "sources": "Payments Canada Standard 005, as amended in force 2024-07-22, Sections B and D (record purposes and data element dictionary); Payments Canada Standard 007, amendment 10 in force 2026-07-03 paras 1 to 5; Payments Canada Rule F1, as amended in force 2026-07-27 definitions, Introduction and Scope; Payments Canada Rule F4, as amended in force 2026-07-27 Part III; Payments Canada ISO AFT Usage Guidelines Part C (Payment Return), portfolio dated 2017-01-31; Payments Canada Rule H1, as amended in force 2026-07-27 s.20. Payments Canada PDFs fetched 2026-09-18 with a plain compressed GET and read with pypdf.", "confidence": "high" }, "currency": { "effective_since": "Long-standing", "effective_note": "The provisions cited are in the editions listed in source_edition, which were the posted versions on 2026-09-18; Payments Canada's rules index states that posted versions are those in force. The date each provision first applied was not established [Unverified]. ISO 20022 AFT formats were admitted by amendments in force 2016-04-18 (Rule F1 and Rule H1 amendment lists).", "source_edition": "Payments Canada Standard 005, as amended in force 2024-07-22; Payments Canada Standard 007, amendment 10 in force 2026-07-03; Payments Canada Rule F1, as amended in force 2026-07-27; Payments Canada Rule F4, as amended in force 2026-07-27; Payments Canada ISO AFT Usage Guidelines Part C (Payment Return), portfolio dated 2017-01-31", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.payments.ca/sites/default/files/standard005eng.pdf", "source_class": "authoritative_primary", "source_title": "Payments Canada Standard 005, Standards for the Exchange of Financial Data on AFT Files, as amended, in force 2024-07-22", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the purpose of each Standard 005 logical record type: A opens a file, C records deposit (credit) data, D records pre-authorized debit data, E reverses deposit data (Logical Record Type C) as an error correction, F reverses pre-authorized debit data (Logical Record Type D) as an error correction, I returns deposit data and J returns debit data, and S carries a notice of change inside its own U header and V trailer." }, { "source_url": "https://www.payments.ca/sites/default/files/standard007eng.pdf", "source_class": "authoritative_primary", "source_title": "Payments Canada Standard 007, Standards for the Use of Transaction Codes and Return Reason Codes in AFT Files, amendment 10, in force 2026-07-03", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms Standard 007 states it is read together with Section F of the ACSS Rules Manual, Standard 005 and the ISO AFT Usage Guidelines, that transaction codes are three digit codes a payment originator uses to mark a payment for the customer, and that the 700 series marks Business PADs, with code 717 marking Commercial Cash Management. Does not address the ISO 20022 AFT message identifiers, which rest on Rule F4 and the ISO AFT Usage Guidelines." } ] }, "rail_name": "Canada ACSS (Automated Funds Transfer)", "governing_authority": "Payments Canada", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "ca-acss:participants", "id": "participants", "rail": "ca-acss", "kind": "rail-fact", "facet": "participants", "name": "Who takes part in Canadian AFT, and in what role?", "statement": "One body both writes the rules and runs the system: the Canadian Payments Association, which trades as Payments Canada. Institutions that belong to it take part in one of two ways. A direct clearer exchanges AFT files itself and settles across its own account at the Bank of Canada; an indirect clearer reaches the system through a direct clearer acting as its clearing agent. Inside a pre-authorized debit there are four parties: the payor and the payee, and the institution holding each one's account.", "details": [ { "label": "Rule maker and operator are one body", "value": "The Association's statutory objects include setting up and running national clearing and settlement systems, and its board makes the rules on payment items, exchange and clearing standards and settlement. Every Payments Canada rule states that the legal name is still Canadian Payments Association.", "citation": "Canadian Payments Act, R.S.C. 1985, c. C-21, Justice Laws text current to 2026-07-21, ss.5(1)(a) and 19(1); cover page of Payments Canada Rule F1, as amended in force 2026-07-27", "rests_on": "law" }, { "label": "Who can be a member", "value": "Membership is automatic for the Bank of Canada, banks, authorized foreign banks and any institution designated as a bridge institution under the deposit insurance statute. Others are entitled to apply if they meet the regulations and by-laws, among them payment service providers under the Retail Payment Activities Act (in the current consolidated text), securities dealers, life insurers and deposit-taking trust, loan and cooperative institutions. [Unverified] whether any payment service provider has joined.", "citation": "Canadian Payments Act, R.S.C. 1985, c. C-21, Justice Laws text current to 2026-07-21, s.4(1) and (2)", "rests_on": "law" }, { "label": "Direct clearers", "value": "A direct clearer exchanges AFT files through the Association's own network, must register at least 90 calendar days before it starts, names which of the four exchange points it will use (Montreal, Toronto, Calgary, Vancouver), and must test with every other direct clearer first. It must hold a settlement account at the Bank of Canada.", "citation": "Payments Canada Rule F1, as amended in force 2026-07-27, Part I, 'Participation' and 'Registration' (a) and (c); Payments Canada web page 'Retail batch payment system' (payments.ca), read 2026-09-18", "rests_on": "rule" }, { "label": "Indirect clearers", "value": "An indirect clearer settles through an account with its clearing agent rather than at the Bank of Canada. Its branches can be given one or two days of extra lead time for incoming credits, which a direct clearer's own branches never get.", "citation": "Payments Canada Rule L1, as amended in force 2026-02-09, s.3(m); Payments Canada Rule F1, as amended in force 2026-07-27, s.6 (Serviceability Code Assignment)", "rests_on": "rule" }, { "label": "Access to direct clearing was opened up", "value": "Payments Canada removed the 0.5 per cent volume test for direct clearing in August 2020, and the first new direct clearer in the system's history joined in June 2022.", "citation": "Payments Canada web page 'Retail batch payment system' (payments.ca), read 2026-09-18", "rests_on": "guidance" }, { "label": "The four parties inside a PAD", "value": "The payor is the account holder debited; the payee is the one credited; the sponsoring member holds the payee's account and sends the debit; the processing member holds the payor's account. A member can also issue PADs as payee itself.", "citation": "Payments Canada Rule H1, as amended in force 2026-07-27, s.5(h), (j), (l), (q) and (u)", "rests_on": "rule" }, { "label": "Payment originators", "value": "The business, government or other body that starts an AFT payment on its customer's authority is the payment originator; it reaches the system only through its institution.", "citation": "Payments Canada Rule F1, as amended in force 2026-07-27, definition of Payment Originator", "rests_on": "rule" } ], "exceptions": [ "Membership is not clearing status: which members may clear directly is set by By-law No. 3 and Rules D1 to D3, which were not read [Unverified].", "Payments Canada publishes the current list of direct clearers separately; it was not read and no count is asserted.", "US dollar AFT through the US Bulk Exchange has its own arrangements under Rule K8 and is outside this rail (Rule F1, Scope)." ], "applies_to": "institutions and customers taking part in Canadian dollar AFT on the ACSS", "caveat": null, "related": [], "basis": { "sources": "Canadian Payments Act, R.S.C. 1985, c. C-21, Justice Laws text current to 2026-07-21 ss.4, 5 and 19, read on Justice Laws 2026-09-18; Payments Canada Rule F1, as amended in force 2026-07-27 Parts I and II and definitions; Payments Canada Rule H1, as amended in force 2026-07-27 s.5; Payments Canada Rule L1, as amended in force 2026-02-09 s.3; Payments Canada web page 'Retail batch payment system' (payments.ca), read 2026-09-18. Payments Canada PDFs fetched 2026-09-18 with a plain compressed GET and read with pypdf.", "confidence": "high" }, "currency": { "effective_since": "Long-standing", "effective_note": "The provisions cited are in the editions listed in source_edition, which were the posted versions on 2026-09-18; Payments Canada's rules index states that posted versions are those in force. The date each provision first applied was not established [Unverified]. The payment service provider entitlement in CPA s.4(2)(i) arrived with the 2024 amendments recorded against s.4 (2024, c. 15, s.220) [Inference from the amendment citation].", "source_edition": "Canadian Payments Act, R.S.C. 1985, c. C-21, Justice Laws text current to 2026-07-21; Payments Canada Rule F1, as amended in force 2026-07-27; Payments Canada Rule H1, as amended in force 2026-07-27; Payments Canada Rule L1, as amended in force 2026-02-09; Payments Canada web page 'Retail batch payment system' (payments.ca), read 2026-09-18", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://laws-lois.justice.gc.ca/eng/acts/C-21/FullText.html", "source_class": "authoritative_primary", "source_title": "Canadian Payments Act, R.S.C. 1985, c. C-21, Justice Laws consolidated text current to 2026-07-21", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms membership is automatic for the Bank of Canada, every bank, every authorized foreign bank, and any institution designated as a bridge institution under the Canada Deposit Insurance Corporation Act (s.4(1)), and that others, including a payment service provider under the Retail Payment Activities Act, a securities dealer, a life insurance company, and a deposit-taking trust, loan or cooperative credit institution, are entitled to apply if they meet the regulations and by-laws (s.4(2)); confirms the Association's objects include establishing and operating national clearing and settlement systems while taking users' interests into account (s.5); and confirms the Board's rule-making and by-law powers (ss.18 and 19) and that a new or amended rule is held back 30 days after being sent to the Minister of Finance, who may extend that review or disallow the rule (s.19.2). Does not state whether any payment service provider has in fact joined." }, { "source_url": "https://www.payments.ca/sites/default/files/f1eng.pdf", "source_class": "authoritative_primary", "source_title": "Payments Canada Rule F1, Rules Applicable to Automated Funds Transfer (AFT) Transactions, as amended, in force 2026-07-27", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms a Direct Clearer must register with the Association at least 90 calendar days before participating in AFT Exchange and must state which of the four AFT Exchange Points it will use (10 Montreal, 20 Toronto, 90 Calgary, 00 Vancouver); confirms it must mutually exchange test files with all other Direct Clearers before starting; and confirms each Direct Clearer is responsible and liable for every credit transaction it delivers. Does not address indirect clearer settlement arrangements, which rest on Rule L1, or the current list of direct clearers, which was not read." } ] }, "rail_name": "Canada ACSS (Automated Funds Transfer)", "governing_authority": "Payments Canada", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "ca-acss:recall", "id": "recall", "rail": "ca-acss", "kind": "rail-fact", "facet": "recall", "name": "Can the sender recall or cancel an AFT payment?", "statement": "Not as a recall. Rule F1 gives no general right or message to call a payment back once exchanged. The nearest tool is the error correction (a payment reversal in ISO terms), which an originating institution may send only to fix a short, closed set of mistakes and only until 3 Business Days after settlement. The customer on the other end can refuse it within 90 days.", "details": [ { "label": "Error correction is the only sender-side undo", "value": "An originator's institution may send an error correction only for a closed set of mistakes: to undo a PAD that should not have been drawn, because its agreement had ended or the debit broke its terms, or to put right a payment that went twice, for the wrong amount or to the wrong account. Any other reason is outside the rule.", "citation": "Payments Canada Rule F1, as amended in force 2026-07-27, Part III, 'Error Correction Transactions'; Payments Canada Rule F4, as amended in force 2026-07-27, Part III, 'Payment Reversal Transactions'", "rests_on": "rule" }, { "label": "Three Business Days after settlement", "value": "The correction must go as soon as possible after the original was exchanged and no later than 3 Business Days after the settlement date.", "citation": "Payments Canada Rule F1, as amended in force 2026-07-27, Part III, 'Time Frames for Error Correction'", "rests_on": "rule" }, { "label": "Not a shield against a failing originator", "value": "An institution may not use error corrections to protect itself from a payment originator that has become insolvent.", "citation": "Payments Canada Rule F1, as amended in force 2026-07-27, Part III, 'Error Correction Transactions'", "rests_on": "rule" }, { "label": "Returns cannot be corrected", "value": "Returned items are not eligible for error correction.", "citation": "Payments Canada Rule F1, as amended in force 2026-07-27, Part III, 'Error Correction Transactions'", "rests_on": "rule" }, { "label": "The customer can say no", "value": "A customer may refuse an error correction within 90 calendar days of posting; it then comes back as 915 if it debited them or 922 if it credited them.", "citation": "Payments Canada Rule F1, as amended in force 2026-07-27, Part III, 'Time Limit for Error Correction Refusal'; Payments Canada Rule F4, as amended in force 2026-07-27, same heading for ISO payment reversals", "rests_on": "rule" }, { "label": "A wrong correction costs its sender", "value": "An originating direct clearer that sends an incorrect error correction must pay back its value plus service or interest charges; a rejected correction may not be resubmitted.", "citation": "Payments Canada Rule F1, as amended in force 2026-07-27, Part III, 'Accuracy of Error Correction Transactions' and 'Rejected Error Correction Transactions'", "rests_on": "rule" } ], "exceptions": [ "The label of return code 903 mentions a recall, but no rule read defines a recall procedure for AFT [Unverified].", "A payor can stop future PADs by revoking the agreement, and a payee can terminate it, but neither undoes a debit already exchanged (Rule H1, ss.30 and 31).", "Rule F1's appendices, beyond those cited, were not read; an absence of any other recall route rests on the Parts read [Unverified]." ], "applies_to": "Canadian dollar AFT credits and debits after exchange, from the sending side", "caveat": "An error correction is a new item in the opposite direction, not a cancellation. If the receiving account is empty or closed, it can itself be dishonoured [Inference].", "related": [ "ca-acss:return", "ca-acss:finality", "ca-acss:messages", "ca-acss:915", "ca-acss:922", "ca-acss:903" ], "basis": { "sources": "Payments Canada Rule F1, as amended in force 2026-07-27 Part III (error correction headings) and definitions; Payments Canada Rule F4, as amended in force 2026-07-27 Part III (payment reversal headings); Payments Canada Rule H1, as amended in force 2026-07-27 ss.30 and 31. Payments Canada PDFs fetched 2026-09-18 with a plain compressed GET and read with pypdf. This fact states an absence, so it rests on the Parts read, not on the whole rule set.", "confidence": "medium" }, "currency": { "effective_since": "2020-11-23", "effective_note": "The current error correction time frame wording came in with amendments in force 2020-11-23, and the list of permitted reasons with amendments in force 2017-04-24 (Rule F1 amendment list).", "source_edition": "Payments Canada Rule F1, as amended in force 2026-07-27; Payments Canada Rule F4, as amended in force 2026-07-27; Payments Canada Rule H1, as amended in force 2026-07-27", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.payments.ca/sites/default/files/f1eng.pdf", "source_class": "authoritative_primary", "source_title": "Payments Canada Rule F1, Rules Applicable to Automated Funds Transfer (AFT) Transactions, as amended, in force 2026-07-27", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms an Error Correction Transaction may only be initiated for a closed list of errors: duplicate payment, incorrect amount, incorrect account number, a cancelled PAD agreement, and a transaction not in accordance with the PAD agreement; confirms it must be delivered as soon as possible after the original exchange and no later than 3 Business Days after the settlement date; confirms it may not be used to protect a Member from an insolvent Payment Originator; confirms returned items are not eligible for error correction; confirms a customer may refuse an error correction within 90 calendar days of the posting date, returned as code 915 for a Logical Record Type E or code 922 for a Logical Record Type F; and confirms an Originating Direct Clearer that delivers an incorrect Error Correction Transaction must reimburse the Processing Direct Clearer its value plus any service or interest charges, and a rejected Error Correction Transaction may not be resubmitted." }, { "source_url": "https://www.payments.ca/sites/default/files/h1eng.pdf", "source_class": "authoritative_primary", "source_title": "Payments Canada Rule H1, Pre-Authorized Debits (PADs), as amended, in force 2026-07-27", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms a Payee may terminate a Payor's PAD Agreement under its terms or, where the agreement is silent, with the Payor's authorization or at least 30 calendar days' written notice, and confirms a Payor may revoke authorization to issue PADs, with the Payee required to cease issuing new PADs within 30 calendar days of the notice. Neither termination nor revocation undoes a debit already exchanged. Does not define a recall procedure for AFT anywhere in the Parts read." } ] }, "rail_name": "Canada ACSS (Automated Funds Transfer)", "governing_authority": "Payments Canada", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "ca-acss:refund", "id": "refund", "rail": "ca-acss", "kind": "rail-fact", "facet": "refund", "name": "What right does a payor have to get money back from a pre-authorized debit?", "statement": "Rule H1 gives the payor a claim against their own institution, which must pay them back quickly and return the debit; the payee cannot block it through the clearing. The window depends on the ground and the PAD category: 90 calendar days where no agreement existed at all, and, where an agreement existed but was broken, revoked or not properly notified, 90 calendar days for Personal PADs or 10 Business Days for Business PADs. Cash Management PADs and opted-out Funds Transfer PADs have no such claim unless there was no agreement.", "details": [ { "label": "No agreement at all: 90 days from the statement", "value": "The payor's institution must promptly refund and return the debit where the claim comes within 90 calendar days of the posting date on the payor's statement. This covers every PAD category and any debit posted in error.", "citation": "Payments Canada Rule H1, as amended in force 2026-07-27, s.23(a) and (b)", "rests_on": "rule" }, { "label": "An agreement existed: three grounds", "value": "The payor's institution must accept a claim that the PAD broke its agreement, came after the agreement was revoked, or came without a required Confirmation, Pre-notification or notice.", "citation": "Payments Canada Rule H1, as amended in force 2026-07-27, s.24(b)", "rests_on": "rule" }, { "label": "How long the payor has", "value": "90 calendar days after the debit for Personal PADs and for Funds Transfer PADs not coded 650, even where a Personal PAD was miscoded as Business; 10 Business Days after the debit for Business PADs.", "citation": "Payments Canada Rule H1, as amended in force 2026-07-27, s.24(a)", "rests_on": "rule" }, { "label": "Refund first, argue later", "value": "The payor's institution refunds on a best efforts basis at once, takes a Reimbursement Claim from the payor and keeps it at least 12 months; the payee's institution must honour the return; a payee who disputes the claim must take it up with the payor outside the rules.", "citation": "Payments Canada Rule H1, as amended in force 2026-07-27, ss.24(a), (c), (e) and 27; Payments Canada Rule F1, as amended in force 2026-07-27, Part III, 'Reimbursement Claim'", "rests_on": "rule" }, { "label": "Categories with no claim", "value": "Cash Management PADs (codes 420 and 717) have no claim except for no agreement. A sponsoring institution may opt out of recourse for Funds Transfer PADs by coding them 650, and must then give the payor a written statement to take to the issuer instead.", "citation": "Payments Canada Rule H1, as amended in force 2026-07-27, ss.25 and 26; Payments Canada Standard 007, amendment 10 in force 2026-07-03, Appendix I note 4", "rests_on": "rule" }, { "label": "Every agreement tells the payor this", "value": "Except for opted-out Funds Transfer PADs, every PAD agreement must carry a set statement of the payor's recourse rights and point them to their institution or Payments Canada's website.", "citation": "Payments Canada Rule H1, as amended in force 2026-07-27, Appendix II, mandatory recourse and reimbursement element", "rests_on": "rule" }, { "label": "Interest is separate", "value": "Interest is dealt with outside the rules for a claim on an existing agreement; for a no-agreement claim it may be claimed separately under Rule J10.", "citation": "Payments Canada Rule H1, as amended in force 2026-07-27, ss.23(d) and 24(d)", "rests_on": "rule" }, { "label": "Which code carries which claim", "value": "[Inference] The no-agreement claim returns as 915, and the three grounds as 916, 917 and 918 for Personal PADs and 919, 920 and 921 for Business PADs, matched by the code names; neither Rule H1 nor Standard 007 states the pairing.", "citation": "Payments Canada Standard 007, amendment 10 in force 2026-07-03, Appendix I; Payments Canada Rule H1, as amended in force 2026-07-27, ss.23 and 24", "rests_on": "rule" } ], "exceptions": [ "After the window closes the claim leaves the rules and the PAD may not be returned through the clearing; the payor must deal with the payee directly (Rule H1, ss.23(c) and 24(g)).", "Rule H1 Appendix III states the no-agreement window from the processing date, while s.23(b) uses the statement posting date [Unverified which governs].", "Consumer protection law may give a payor further rights; Rule H1 is subject to it, and it was not read (Rule H1, s.2)." ], "applies_to": "payors whose accounts were debited with a pre-authorized debit through the ACSS", "caveat": "The claim is against the payor's own institution and needs no proof from the payee. For a payee, 90 days of Personal PAD revenue is contestable after settlement, and the payee's only answer is outside the rules.", "related": [ "ca-acss:return", "ca-acss:finality", "ca-acss:915", "ca-acss:916", "ca-acss:917", "ca-acss:918", "ca-acss:919", "ca-acss:920", "ca-acss:921" ], "basis": { "sources": "Payments Canada Rule H1, as amended in force 2026-07-27 ss.1, 2, 5, 20, 23 to 27 and Appendices II, III and V; Payments Canada Rule F1, as amended in force 2026-07-27 Part III, 'Reimbursement Claim'; Payments Canada Standard 007, amendment 10 in force 2026-07-03 Appendix I and note 4. Payments Canada PDFs fetched 2026-09-18 with a plain compressed GET and read with pypdf. Rule J10 was not read.", "confidence": "high" }, "currency": { "effective_since": "2022-10-03", "effective_note": "The current structure of Rule H1 comes from the holistic review in force 2022-10-03, with its grace period ending 2023-12-31, and recourse clarifications in force 2025-04-28 (Rule H1 amendment list, items 10 to 12). The 90 day and 10 Business Day windows may be older [Unverified].", "source_edition": "Payments Canada Rule H1, as amended in force 2026-07-27; Payments Canada Rule F1, as amended in force 2026-07-27; Payments Canada Standard 007, amendment 10 in force 2026-07-03", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.payments.ca/sites/default/files/h1eng.pdf", "source_class": "authoritative_primary", "source_title": "Payments Canada Rule H1, Pre-Authorized Debits (PADs), as amended, in force 2026-07-27", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the payor's institution must promptly reimburse and return a debit where a no-agreement claim is made within 90 calendar days of the posting date shown on the payor's statement, covering every PAD category and any debit processed in error; confirms a claim under an existing agreement (not drawn per the agreement, agreement revoked, or a missing Confirmation, Pre-notification or notice) must be accepted within 90 calendar days after the debit for Personal and most Funds Transfer PADs, or 10 Business Days for Business PADs, even where a Personal PAD was miscoded as Business; confirms the institution reimburses on a best efforts basis at once, takes a Reimbursement Claim and keeps it at least 12 months, the payee's institution must honour the return, and a disputing payee must settle outside the rules; confirms Cash Management PADs and Funds Transfer PADs coded 650 or 83 carry no such claim except where no agreement existed; and confirms interest is handled outside the rules for an existing-agreement claim and separately under Rule J10 for a no-agreement claim. Does not state which return reason code carries each of these grounds; Standard 007 and Rule H1 never name that pairing, so it remains an inference from the code names." }, { "source_url": "https://www.payments.ca/sites/default/files/standard007eng.pdf", "source_class": "authoritative_primary", "source_title": "Payments Canada Standard 007, Standards for the Use of Transaction Codes and Return Reason Codes in AFT Files, amendment 10, in force 2026-07-03", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms Appendix I note 4 gives all 700 series transaction codes a 10 Business Day recourse period, with the exception of Cash Management code 717, which has no recourse under Rule H1. Does not state which return reason code carries a Rule H1 reimbursement claim." } ] }, "rail_name": "Canada ACSS (Automated Funds Transfer)", "governing_authority": "Payments Canada", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "ca-acss:return", "id": "return", "rail": "ca-acss", "kind": "rail-fact", "facet": "return", "name": "How does an AFT item come back, and within what time?", "statement": "An institution that cannot post an item, or whose customer refuses it, returns it through the clearing with a Standard 007 reason code. Institution dishonours go back by the next Business Day. Customer-initiated returns follow their own longer windows: Rule H1 for pre-authorized debits, and 90 days for a payee refusing a credit. Only two codes allow the debit to be tried again.", "details": [ { "label": "Every return carries a code", "value": "An item that passed the first file edit and was then unposted, dishonoured or refused must go back with the fitting Standard 007 code.", "citation": "Payments Canada Rule F1, as amended in force 2026-07-27, Part III, 'Unposted/Dishonoured Transactions/Transactions Refused by Payor/Payee'; Payments Canada Rule F4, as amended in force 2026-07-27, Part III, same heading", "rests_on": "rule" }, { "label": "Four families of code", "value": "Standard 007 sorts the codes into institution dishonours (900 to 914), customer-initiated debit returns (915 to 921), a customer-initiated credit return (922) and default (990). Code 900 is for edit rejects only.", "citation": "Payments Canada Standard 007, amendment 10 in force 2026-07-03, paras 5 and 6", "rests_on": "rule" }, { "label": "Institution dishonours: next Business Day", "value": "The item must go back no later than the Business Day after the first unit able to decide on it received it.", "citation": "Payments Canada Rule F1, as amended in force 2026-07-27, Part III, 'Time Limitation for Return'; Payments Canada Rule F4, as amended in force 2026-07-27, s.26; Payments Canada Rule H1, as amended in force 2026-07-27, s.22(a)", "rests_on": "rule" }, { "label": "Customer claims on debits: Rule H1 windows", "value": "A debit returned because the payor claimed reimbursement follows Rule H1's time limits rather than the next day rule.", "citation": "Payments Canada Rule F1, as amended in force 2026-07-27, s.18; Payments Canada Rule F4, as amended in force 2026-07-27, s.27; Payments Canada Rule H1, as amended in force 2026-07-27, ss.23 and 24", "rests_on": "rule" }, { "label": "Customer refusal of credits: 90 days", "value": "A payee may refuse a credit up to and including 90 calendar days after it was processed to the account; later refusals are dealt with outside the clearing.", "citation": "Payments Canada Rule F1, as amended in force 2026-07-27, s.19", "rests_on": "rule" }, { "label": "One more try, and only after two codes", "value": "A debit returned for insufficient funds (901) or uncleared funds (908) may be presented once more within 30 calendar days, for the same amount with nothing added. No other code allows re-presentment.", "citation": "Payments Canada Rule F1, as amended in force 2026-07-27, s.22; Payments Canada Rule H1, as amended in force 2026-07-27, s.22(c)", "rests_on": "rule" }, { "label": "Where a returned PAD goes", "value": "A dishonoured PAD goes back to the branch of the institution that sent it, or, if the payee's account details were wrong, to the originating branch.", "citation": "Payments Canada Rule H1, as amended in force 2026-07-27, s.22(b)", "rests_on": "rule" }, { "label": "No return of a return", "value": "A returned item accepted in the file edit cannot be returned again through the clearing; it becomes an item in dispute. A rejected return may not be resubmitted.", "citation": "Payments Canada Rule F1, as amended in force 2026-07-27, Part III, 'Unposted/Dishonoured Transactions/Transactions Refused by Payor/Payee' and 'Re-presentment and Rejected Returned Transactions'", "rests_on": "rule" }, { "label": "A wrong return costs its sender", "value": "The direct clearer that sends an incorrect debit return must pay the receiving direct clearer back its value plus any service or interest charges.", "citation": "Payments Canada Rule F1, as amended in force 2026-07-27, Part III, 'Accuracy and Delivery of Returned Transactions'", "rests_on": "rule" } ], "exceptions": [ "Items caught by a direct or indirect clearer's default are purged under Rules L1 and L2 rather than returned within a stated window; the default code's window is [Unverified].", "Cash Management PADs and Funds Transfer PADs coded 650 cannot be returned for a customer claim except where no agreement existed (Rule H1, ss.25 and 26)." ], "applies_to": "returns of Canadian dollar AFT credits and debits between institutions", "caveat": null, "related": [ "ca-acss:messages", "ca-acss:finality", "ca-acss:900", "ca-acss:901", "ca-acss:908", "ca-acss:915", "ca-acss:922", "ca-acss:990" ], "basis": { "sources": "Payments Canada Standard 007, amendment 10 in force 2026-07-03 paras 5 and 6 and Appendix I; Payments Canada Rule F1, as amended in force 2026-07-27 Part III; Payments Canada Rule F4, as amended in force 2026-07-27 Part III; Payments Canada Rule H1, as amended in force 2026-07-27 ss.22 to 26. Payments Canada PDFs fetched 2026-09-18 with a plain compressed GET and read with pypdf.", "confidence": "high" }, "currency": { "effective_since": "Long-standing", "effective_note": "The provisions cited are in the editions listed in source_edition, which were the posted versions on 2026-09-18; Payments Canada's rules index states that posted versions are those in force. The date each provision first applied was not established [Unverified].", "source_edition": "Payments Canada Standard 007, amendment 10 in force 2026-07-03; Payments Canada Rule F1, as amended in force 2026-07-27; Payments Canada Rule F4, as amended in force 2026-07-27; Payments Canada Rule H1, as amended in force 2026-07-27", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.payments.ca/sites/default/files/standard007eng.pdf", "source_class": "authoritative_primary", "source_title": "Payments Canada Standard 007, Standards for the Use of Transaction Codes and Return Reason Codes in AFT Files, amendment 10, in force 2026-07-03", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms Standard 007 sorts return reason codes into four categories: 900 to 914 FI Dishonoured Transaction, 915 to 921 Customer Initiated Returns (Debits Only), 922 Credit Return (Customer Initiated) and 990 Default, and that code 900 is reserved for edit rejects only." }, { "source_url": "https://www.payments.ca/sites/default/files/f1eng.pdf", "source_class": "authoritative_primary", "source_title": "Payments Canada Rule F1, Rules Applicable to Automated Funds Transfer (AFT) Transactions, as amended, in force 2026-07-27", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms an item unposted, dishonoured or refused after passing the initial file edit must be returned with the applicable Standard 007 code; confirms the general return window is the Business Day after the first organizational unit able to decide received the item, subject to Rule H1 for a payor's reimbursement claim; confirms a payee may refuse a credit up to and including 90 calendar days after it was processed; confirms only codes 901 and 908 allow a single re-presentment within 30 calendar days for the same amount with no added charges; confirms a returned item accepted in the file edit cannot be returned again and becomes an item in dispute; and confirms a direct clearer that sends an incorrect debit return must reimburse the receiving direct clearer its value plus any service or interest charges." } ] }, "rail_name": "Canada ACSS (Automated Funds Transfer)", "governing_authority": "Payments Canada", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "ca-acss:settlement", "id": "settlement", "rail": "ca-acss", "kind": "rail-fact", "facet": "settlement", "name": "How and when does AFT settle between institutions?", "statement": "The ACSS is a deferred net settlement system. Each direct clearer enters what the others owe it for the items it exchanged, the system nets these across all participants and all ACSS streams, and the net positions settle across settlement accounts at the Bank of Canada on the morning of the next business day. Indirect clearers settle with their clearing agents, not at the Bank of Canada.", "details": [ { "label": "Settlement date", "value": "An AFT item settles on the Business Day after its due date, or, if it was delivered after the due date, on the Business Day after the day it was exchanged.", "citation": "Payments Canada Rule F1, as amended in force 2026-07-27, s.40(d)", "rests_on": "rule" }, { "label": "Entries by 05:00 Eastern", "value": "The direct clearer that received credits, and the one that sent debits, each enters a claim against the other direct clearer for the volume and value involved, by 05:00 Eastern on the settlement date, or 09:30 after a regional or civic holiday.", "citation": "Payments Canada Rule F1, as amended in force 2026-07-27, Part V, 'ACSS Entries' (a) and (b)", "rests_on": "rule" }, { "label": "Netting and final settlement at the Bank of Canada", "value": "The system combines these totals with cheque and other paper figures to give each direct clearer one net position, and the previous day's positions settle in the morning through payments to and from the Bank of Canada.", "citation": "Payments Canada web page 'Retail batch payment system' (payments.ca), read 2026-09-18; Bank of Canada web page 'Oversight of designated clearing and settlement systems' (bankofcanada.ca), read 2026-09-18", "rests_on": "guidance" }, { "label": "What does and does not settle", "value": "Nothing in a rejected AFT file settles. Rejected items inside an accepted file do settle, like any other item.", "citation": "Payments Canada Rule F1, as amended in force 2026-07-27, s.40(b) and (c)", "rests_on": "rule" }, { "label": "If a direct clearer cannot settle", "value": "Items from the cycle in which the default happened still settle, with the surviving direct clearers and the Bank of Canada putting in contributions to cover the shortfall. The survivors' share is capped at the collateral pool less the defaulter's own pledge. Items for later cycles do not go through the ACSS.", "citation": "Payments Canada Rule L1, as amended in force 2026-02-09, ss.11 and 13", "rests_on": "rule" }, { "label": "Legal protection for settlement", "value": "The Bank of Canada has designated the ACSS a prominent payment system. For a designated system the statute makes the settlement rules binding despite other law, and a payment made under them need not be reversed. [Inference] That the ACSS rules cited here are 'settlement rules' in the statute's sense was not confirmed from a Bank of Canada or Payments Canada text.", "citation": "Bank of Canada web page 'Oversight of designated clearing and settlement systems' (bankofcanada.ca), read 2026-09-18; Payment Clearing and Settlement Act, S.C. 1996, c. 6, Sch., Justice Laws text current to 2026-07-21, ss.3, 4(1) and 8(1)", "rests_on": "law" } ], "exceptions": [ "US dollar items through the US Bulk Exchange settle through correspondent banks in New York, not at the Bank of Canada (Payments Canada retail batch payment system page).", "An indirect clearer's default is handled between it and its clearing agent, which answers only for that clearer's items in the cycle of default (Rule L2, s.9)." ], "applies_to": "interbank settlement of Canadian dollar AFT items between direct clearers, and through them for indirect clearers", "caveat": "Settlement between institutions is not the end of the payment for customers: returns and PAD claims keep running for days or months after settlement.", "related": [ "ca-acss:participants", "ca-acss:messages", "ca-acss:990", "ca-acss:900" ], "basis": { "sources": "Payments Canada Rule F1, as amended in force 2026-07-27 Part V (s.40 and 'ACSS Entries'); Payments Canada Rule L1, as amended in force 2026-02-09 ss.11 and 13; Payments Canada Rule L2, as amended in force 2025-11-24 s.9; Payments Canada web page 'Retail batch payment system' (payments.ca), read 2026-09-18; Bank of Canada web page 'Oversight of designated clearing and settlement systems' (bankofcanada.ca), read 2026-09-18; Payment Clearing and Settlement Act, S.C. 1996, c. 6, Sch., Justice Laws text current to 2026-07-21 ss.3, 4 and 8, read on Justice Laws 2026-09-18. By-law No. 3, which establishes the ACSS and the default contribution scheme, was not read.", "confidence": "high" }, "currency": { "effective_since": "Long-standing", "effective_note": "The provisions cited are in the editions listed in source_edition, which were the posted versions on 2026-09-18; Payments Canada's rules index states that posted versions are those in force. The date each provision first applied was not established [Unverified].", "source_edition": "Payments Canada Rule F1, as amended in force 2026-07-27; Payments Canada Rule L1, as amended in force 2026-02-09; Payments Canada Rule L2, as amended in force 2025-11-24; Payment Clearing and Settlement Act, S.C. 1996, c. 6, Sch., Justice Laws text current to 2026-07-21; Payments Canada web page 'Retail batch payment system' (payments.ca), read 2026-09-18; Bank of Canada web page 'Oversight of designated clearing and settlement systems' (bankofcanada.ca), read 2026-09-18", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.payments.ca/sites/default/files/f1eng.pdf", "source_class": "authoritative_primary", "source_title": "Payments Canada Rule F1, Rules Applicable to Automated Funds Transfer (AFT) Transactions, as amended, in force 2026-07-27", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms an AFT item settles on the Business Day after its due date, or after the exchange date if delivered late; confirms each direct clearer enters a debit entry against the others by 05:00 Eastern on the settlement date, or by 09:30 Eastern where the settlement date follows a regional or civic holiday; confirms nothing in a rejected AFT file settles while rejected items inside an accepted file settle normally; and confirms that in a default, AFT transactions are returned or rejected under Rules L1 or L2." }, { "source_url": "https://www.payments.ca/sites/default/files/l1eng.pdf", "source_class": "authoritative_primary", "source_title": "Payments Canada Rule L1, Procedures Pertaining to the Default of a Direct Clearer, as amended, in force 2026-02-09", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms that on the default of a direct clearer, obligations for the ACSS cycle in which default occurred are settled under By-law No. 3, with surviving direct clearers and the Bank of Canada making default contributions capped at the ACSS Collateral Pool less the defaulting clearer's own pledge, while obligations for later cycles are not cleared or settled through the ACSS and may be purged with listings sent to the liquidator or trustee." } ] }, "rail_name": "Canada ACSS (Automated Funds Transfer)", "governing_authority": "Payments Canada", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "ch-sic:consumer-law", "id": "consumer-law", "rail": "ch-sic", "kind": "rail-fact", "facet": "consumer-law", "name": "What consumer protections apply to a payment that settles in the SIC RTGS service?", "statement": "SIC is an interbank system and gives consumers no rights of its own. No Swiss statute read sets payment-service rights comparable to the EU's; what a customer has comes from its contract with its bank, the Code of Obligations, and the banks' voluntary Swiss Payment Standards, which leave processing rules to each bank.", "details": [ { "label": "SIC binds banks, not customers", "value": "SIC participation rests on contracts among the participant, the SNB and SIC Ltd plus the SIC Handbook; customers are not party to them. The SNB oversees SIC under the National Bank Act and Ordinance as a systemically important system, which is system-stability oversight, not consumer protection; FINMA does not supervise SIC.", "citation": "SNB, The Swiss Interbank Clearing (SIC) payment system: Report on the SIC System and Disclosure Report 2025 (published May 2026), chapter 5 and Disclosure Report principle 1; Financial Market Infrastructure Act (SR 958.1), art. 4 para. 3, consolidated status 1 February 2024, unofficial English translation", "rests_on": "law" }, { "label": "When a customer's order becomes irrevocable", "value": "A cashless payment instruction becomes irrevocable once the amount has been debited from the customer's account, unless a payment system's rules provide otherwise. [Inference: before that debit the customer may generally still revoke the order as against its bank, subject to the condition in para. 2 about notice of acceptance to the payee.]", "citation": "Code of Obligations (SR 220), art. 470 paras. 2 and 2bis, consolidated status 1 January 2026, unofficial English translation on fedlex", "rests_on": "law" }, { "label": "Timing is the bank's offer", "value": "Retail payments are delivered to SIC when the customer's bank decides, often only the next bank working day. The Swiss Payment Standards state that cut-off times, error handling and similar processing rules are part of each bank's own customer offering and may differ between banks.", "citation": "SNB Report and Disclosure Report 2025, chapter 2 'Services in SIC system'; SIX, Swiss Payment Standards Business Rules v3.3 (20 February 2026, valid from 14 November 2026), section 1.4.2", "rests_on": "practice" }, { "label": "Standards are voluntary", "value": "The Swiss Payment Standards are described by their publisher as a voluntary market practice. All Swiss institutions back the recommendations, apart from services flagged as optional, but they create no rights a customer can enforce against the scheme. [Inference: no enforcement mechanism is described.]", "citation": "SIX, Swiss Payment Standards Business Rules v3.3, sections 1.4.2 and 1.4.4", "rests_on": "practice" }, { "label": "Mistaken payments", "value": "A customer who paid money not owed can claim restitution from the recipient under unjust enrichment, within three years of knowing of the claim and at most ten years.", "citation": "Code of Obligations (SR 220), arts. 62, 63 and 67", "rests_on": "law" } ], "exceptions": [ "No Swiss statute giving payment-service users EU-style rights on unauthorised payments, execution times or refunds was found. [Unverified: the search covered only the laws cited here; the Banking Act, the Unfair Competition Act and any Swiss Bankers Association self-regulation were not read.]", "Liechtenstein is domestic for SIC admission but applies its own law, and as an EEA state it may give its customers EU-derived payment rights. [Unverified: Liechtenstein law not read.] (SNB Instruction sheet on admission to the SIC system and sight deposit accounts, 17 November 2023 updated 27 February 2025, section 3 footnote 4)", "The Swiss Payment Standards Business Rules v3.3 read apply from 2026-11-14; the edition in force before then was not compared." ], "applies_to": "customers, consumer or business, whose Swiss franc payments settle in the SIC RTGS service, and their banks, under Swiss law", "caveat": "Low confidence because the finding is largely an absence: the laws read do not set payment-specific consumer rights, and the wider Swiss legal landscape was not searched. English texts of Swiss laws on fedlex are unofficial translations without legal force.", "related": [ "ch-sic:finality", "ch-sic:refund", "ch-sic:liability", "ch-sic:decision-points", "ch-sic-ip:consumer-law" ], "basis": { "sources": "SNB, Report on the SIC System and Disclosure Report 2025 (May 2026), chapters 2 and 5 and Disclosure Report principle 1. Financial Market Infrastructure Act (SR 958.1) art. 4, unofficial English consolidation of 1 February 2024. Code of Obligations (SR 220) arts. 62, 63, 67 and 470, unofficial English consolidation of 1 January 2026. SIX Swiss Payment Standards Business Rules v3.3 (valid from 14 November 2026), sections 1.4.2 and 1.4.4. SNB instruction sheet on admission, section 3.", "confidence": "low" }, "currency": { "effective_since": "2025-11-21", "effective_note": "2025-11-21 is the start of the SIC release in force when this was drafted; the legal provisions cited are older. Code of Obligations art. 470 para. 2bis has applied since 1 October 2009. The Business Rules v3.3 cited take effect on 2026-11-14.", "source_edition": "SNB Report on the SIC System and Disclosure Report 2025 (May 2026); Financial Market Infrastructure Act status 2024-02-01; Code of Obligations status 2026-01-01; SPS Business Rules v3.3 (2026-02-20)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.snb.ch/public/asset/en/www-snb-ch/publications/sicsystem-disclosure/sicsystem-disclosure-all/sicsystem_disclosure_2025/publications0_en/sic_disclosure_2025.en.pdf", "source_class": "public_primary", "source_title": "SNB Report on the SIC System and Disclosure Report 2025, chapters 2 and 5", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms FinMIA art. 4 para. 3 (SIC not subject to FINMA authorisation or supervision), retail payments often delivered next bank working day at the bank's choice, and SIC's contractual basis among participant, SNB and SIC Ltd." }, { "source_url": "https://www.fedlex.admin.ch/eli/cc/27/317_321_377/en", "source_class": "secondary", "source_title": "Swiss Code of Obligations (SR 220), unofficial English translation, fedlex consolidated text", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms art. 470 para. 2bis (irrevocability on debit unless system rules provide otherwise) and arts. 62/63/67 (unjust enrichment restitution, three-year/ten-year prescription). Unofficial translation, treated as secondary per validator guidance." }, { "source_url": "https://www.six-group.com/dam/download/banking-services/standardization/sps/business-rules-sps-2026-en.pdf", "source_class": "authoritative_primary", "source_title": "SIX, Swiss Payment Standards Business Rules v3.3", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms section 1.4.2 (voluntary market practice; cut-off times and processing rules are part of each bank's own offering) and 1.4.4 (recommendations supported by all Swiss financial institutions, AOS marked separately)." } ] }, "rail_name": "Swiss Interbank Clearing (SIC)", "governing_authority": "SIX Interbank Clearing on behalf of the Swiss National Bank", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "ch-sic:decision-points", "id": "decision-points", "rail": "ch-sic", "kind": "rail-fact", "facet": "decision-points", "name": "Where in a SIC RTGS payment does a bank or a person decide the outcome, rather than the system?", "statement": "Most of the judgement in SIC sits with the sending bank before settlement: when to deliver a customer's payment, at what priority, and whether to cancel it while it waits. After settlement the judgement moves to the receiving bank, which decides whether to send money back. The SNB decides who takes part at all.", "details": [ { "label": "When a retail payment enters SIC", "value": "The customer's bank decides when to hand a retail payment to the RTGS service, and it often does so only on the next bank working day. The customer does not control this unless the bank offers a faster option.", "citation": "SNB, The Swiss Interbank Clearing (SIC) payment system: Report on the SIC System and Disclosure Report 2025 (published May 2026), chapter 2 'Services in SIC system'", "rests_on": "guidance" }, { "label": "Order in the queue", "value": "The sending bank chooses a priority level and may set an earliest settlement time, and can change the priority of a waiting payment or reserve liquidity for some payments. These choices decide which of its payments settle first when cover is short.", "citation": "SIX Interbank Clearing, Implementation Guidelines SIC RTGS, Customer Payments (pacs.008) v2.6 (valid from 21 November 2025), settlement priority and time elements; Base Document v2.5 (valid from 21 November 2025), section 3.8; SNB Report and Disclosure Report 2025, chapter 6 'Settlement algorithm'", "rests_on": "rule" }, { "label": "Cancel or wait", "value": "Until 17.00 the sending bank alone may cancel a payment still waiting for cover; the recipient has no say. If it does nothing and cover never arrives, the payment is deleted at day end and the recipient may charge a penalty fee.", "citation": "SNB Report and Disclosure Report 2025, chapter 6 'Settlement algorithm' and footnote 14; SIX Interbank Clearing, Implementation Guidelines SIC RTGS, Cancellation (camt.008) v2.1 (valid from 21 November 2025), chapter 2", "rests_on": "guidance" }, { "label": "Answering a return request", "value": "When the sending bank asks for a settled payment back, the receiving bank must reply but decides the answer: return the money or reject the request with a reason. Whether it needs its customer's consent to debit the account is a matter for that bank's customer contract. [Inference: no public SIC rule addresses the customer's consent.]", "citation": "SIX Interbank Clearing, Implementation Guidelines SIC RTGS, Return Request (camt.056) v2.4 (valid from 21 November 2025), section 3.1; Return Request Rejection (camt.029) v2.3 (valid from 21 November 2025), section 3.1", "rests_on": "rule" }, { "label": "Returning on its own initiative", "value": "A receiving bank may also send a payment back without any request, choosing the ISO reason code; no public rule says when it must.", "citation": "SIX Interbank Clearing, Implementation Guidelines SIC RTGS, Payment Returns (pacs.004) v2.4 (valid from 21 November 2025), reason code element", "rests_on": "rule" }, { "label": "Who may take part", "value": "The SNB decides admission, suspension and exclusion, and is not bound by its own instruction sheet; one ground for exclusion is a case the SNB itself judges a particular risk to SIC or to its reputation.", "citation": "SNB Instruction sheet on admission to the SIC system and sight deposit accounts (17 November 2023, updated 27 February 2025), sections 1 and 6", "rests_on": "rule" } ], "exceptions": [ "Settlement itself involves no judgement: a covered payment settles automatically in submission order within its priority, and the gridlock routine runs by itself (SNB Report and Disclosure Report 2025, chapter 6 'Settlement algorithm' and footnotes 12 and 13).", "Splitting a large money market payment is a duty the service does not police, so in practice whether it happens is the participant's call (SIX Interbank Clearing, Implementation Guidelines Base Document v2.5, section 4.6).", "In a system-wide failure the SNB, as system manager, runs crisis management and can act in SIC on a participant's behalf (SNB Report and Disclosure Report 2025, Disclosure Report principle 17).", "This list is Orca's reading of where the public texts leave the outcome to a bank or the SNB; it is not a list published by SIX or the SNB." ], "applies_to": "points before and after a Swiss franc payment in the SIC RTGS service where a participant, its customer or the SNB decides the outcome rather than the system", "caveat": "The pattern to design around is that the sender holds the decisions until settlement and loses them at settlement. A customer wanting to stop a payment has to reach its own bank before the bank delivers it to SIC, or at the latest before settlement; afterwards everything depends on the receiving bank.", "related": [ "ch-sic:finality", "ch-sic:recall", "ch-sic:return", "ch-sic:settlement", "ch-sic:participants", "ch-sic:hours", "ch-sic:limits", "ch-sic-ip:decision-points" ], "basis": { "sources": "SNB, Report on the SIC System and Disclosure Report 2025 (May 2026), chapters 2 and 6, footnotes 12 to 14 and Disclosure Report principle 17. SNB Instruction sheet on admission (2023, updated 2025), sections 1 and 6. SIX Interbank Clearing Implementation Guidelines release 4.12 (in force from 21 November 2025): Base Document v2.5 sections 3.8 and 4.6; SIC RTGS pacs.008 v2.6, pacs.004 v2.4, camt.008 v2.1, camt.056 v2.4 and camt.029 v2.3. The reading of these provisions as decision points is Orca's.", "confidence": "medium" }, "currency": { "effective_since": "2025-11-21", "effective_note": "2025-11-21 is when the release 4.12 guidelines cited took effect. Release 5.3 on 2026-11-13 migrates the RTGS service to SIC5 with minor process changes described only in an extranet document. The facet caps at medium confidence because the reading of provisions as decision points is Orca's.", "source_edition": "SNB Report on the SIC System and Disclosure Report 2025 (May 2026); SNB instruction sheet on admission (2023-11-17, updated 2025-02-27); SIX Implementation Guidelines release 4.12", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.snb.ch/public/asset/en/www-snb-ch/publications/sicsystem-disclosure/sicsystem-disclosure-all/sicsystem_disclosure_2025/publications0_en/sic_disclosure_2025.en.pdf", "source_class": "public_primary", "source_title": "SNB Report on the SIC System and Disclosure Report 2025, chapters 2 and 6", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms retail delivery timing at the sending bank's choice, the 17.00 cancellation deadline, and the gridlock/settlement-order mechanics that operate without participant judgement." }, { "source_url": "https://www.snb.ch/dam/jcr:76cdd7c1-828e-47eb-8d5f-d580fdc1881e/sicgiro_access_2023.en.pdf", "source_class": "authoritative_primary", "source_title": "SNB Instruction sheet on admission to the SIC system and sight deposit accounts (17 November 2023, updated 27 February 2025)", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms that admission, suspension and exclusion are SNB decisions under sections 1 and 6, including exclusion for a case the SNB judges a particular risk to SIC or its reputation." } ] }, "rail_name": "Swiss Interbank Clearing (SIC)", "governing_authority": "SIX Interbank Clearing on behalf of the Swiss National Bank", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "ch-sic:finality", "id": "finality", "rail": "ch-sic", "kind": "rail-fact", "facet": "finality", "name": "When does a payment in the SIC RTGS service become final, and can it be reversed?", "statement": "A SIC RTGS payment becomes final at the moment the service debits the sender's settlement account, and settlement is in central bank money, so between the two banks nothing is left to unwind. Before that moment the payment sits in a wait file and the sending bank can still pull it. After it, the only ways back are a request to the receiving bank, which that bank may refuse, or a new payment in the other direction.", "details": [ { "label": "The final moment", "value": "The SNB, as system manager, reports that a SIC payment counts as executed irrevocably and with finality once the debit to the sender's settlement account has been made. It gives this as the point the system's rules fix to meet the National Bank Ordinance.", "citation": "SNB, The Swiss Interbank Clearing (SIC) payment system: Report on the SIC System and Disclosure Report 2025 (published May 2026), chapter 2 'Settlement finality' and footnote 3; Disclosure Report principle 8", "rests_on": "guidance" }, { "label": "Why a rule has to name that moment", "value": "Swiss law requires a systemically important payment system to state in its own rules when a participant's order becomes unconditional and irrevocable and when a payment counts as settled, and to settle in real time, with the end of the value day as the outer limit. The SIC rules that fix the moment are in the SIC Handbook, which only participants can read.", "citation": "National Bank Ordinance (SR 951.131), art. 25a paras. 1 and 2, consolidated status 1 July 2024, unofficial English translation on fedlex; the Handbook's role from the SNB Report and Disclosure Report 2025, chapter 5 and Disclosure Report principle 23", "rests_on": "law" }, { "label": "What settles, and in what money", "value": "Each payment settles on its own, gross and in real time, against balances that are sight deposits at the SNB. The receiving bank therefore holds a claim on the central bank, not on the sending bank, and the SNB states there is no credit risk between SIC participants.", "citation": "SNB Report and Disclosure Report 2025, chapter 2 'Real-time gross settlement' and 'Settlement in central bank money'; Disclosure Report principles 4 and 9", "rests_on": "guidance" }, { "label": "Before the moment: the wait file", "value": "A submitted payment waits until the sender's account covers it. While it waits, the sending bank may cancel it without asking the recipient, up to clearing stop 1 at 17.00; the cancellation message is camt.008. A payment still uncovered at the end of the clearing day is deleted by the service and has to be sent again.", "citation": "SNB Report and Disclosure Report 2025, chapter 6 'Settlement algorithm'; SIX Interbank Clearing, Implementation Guidelines SIC RTGS, Cancellation (camt.008) v2.1 (valid from 21 November 2025), chapter 2", "rests_on": "guidance" }, { "label": "The customer's order", "value": "Between a customer and its bank, Swiss contract law makes a cashless payment instruction irrevocable once the amount is debited from the customer's account, unless the rules of the payment system say otherwise. That debit is the bank's booking, which can come before or after the SIC settlement debit; the two moments are different layers.", "citation": "Code of Obligations (SR 220), art. 470 para. 2bis, consolidated status 1 January 2026, unofficial English translation on fedlex", "rests_on": "law" }, { "label": "Insolvency of a participant", "value": "Federal law protects orders already entered into a payment system from insolvency measures later ordered against the participant, if the orders were by then unalterable under the system's rules or were executed on the business day the rules define. [Inference: the article names payment systems without limiting it to those FINMA authorises, so it should reach SIC; the SNB report does not cite it.]", "citation": "Financial Market Infrastructure Act (SR 958.1), art. 89 paras. 1 and 2, consolidated status 1 February 2024, unofficial English translation on fedlex", "rests_on": "law" }, { "label": "After the moment: requests and new payments", "value": "Once settled, a payment can come back only as a payment return (pacs.004), which is itself a new payment that settles again. The sending bank can ask for one with a return request (camt.056); the receiving bank has to answer, either with the return or with a rejection (camt.029), and the service only passes those messages on.", "citation": "SIX Interbank Clearing, Implementation Guidelines SIC RTGS, Return Request (camt.056) v2.4 (valid from 21 November 2025), section 3.1; Base Document v2.5 (valid from 21 November 2025), section 3.3", "rests_on": "rule" } ], "exceptions": [ "A payment that never finds cover is never final. It is deleted at the end of the clearing day, and the intended recipient may charge the sender a penalty fee for the payment it expected (SNB Report and Disclosure Report 2025, chapter 6 'Settlement algorithm' and footnote 14).", "Retail payments usually reach SIC only when the sending bank chooses to deliver them, often the next bank working day, so a customer's payment can be booked by its bank long before it is final in SIC (SNB Report and Disclosure Report 2025, chapter 2 'Services in SIC system').", "Payments sent by a third-party system operator, such as the securities settlement system SECOM, debit and credit participants' accounts under a one-off authorisation from each participant; the finality point is the same debit, but the order comes from the operator (SNB Report and Disclosure Report 2025, chapter 3; SNB Instruction sheet on admission to the SIC system and sight deposit accounts, 17 November 2023 updated 27 February 2025, section 2.2).", "A customer who paid by mistake has a civil claim in unjust enrichment against the recipient; that claim runs outside SIC and does not undo the settled payment (Code of Obligations, arts. 62, 63 and 67)." ], "applies_to": "Swiss franc payments settled in the SIC RTGS service, the real-time gross settlement service of the Swiss Interbank Clearing system, between its direct participants in Switzerland and Liechtenstein, under Swiss law", "caveat": "Two finality moments are easy to confuse here: the customer-bank moment in the Code of Obligations (the debit to the customer's account) and the system moment (the debit to the bank's SIC settlement account). The SNB report describes the system moment; the rule that fixes it is in the participant-only SIC Handbook, which was not read. The English texts of Swiss laws on fedlex are unofficial and have no legal force; the SNB report's English is a translation of an authoritative German original.", "related": [ "ch-sic:settlement", "ch-sic:hours", "ch-sic:recall", "ch-sic:return", "ch-sic:refund", "ch-sic:liability", "ch-sic:consumer-law", "ch-sic:decision-points", "ch-sic-ip:finality" ], "basis": { "sources": "SNB, The Swiss Interbank Clearing (SIC) payment system: Report on the SIC System and Disclosure Report 2025 (published May 2026), chapters 2, 3, 5, 6 and Disclosure Report principles 4, 8, 9 and 23, read in full. National Bank Ordinance (SR 951.131) art. 25a, Financial Market Infrastructure Act (SR 958.1) arts. 4 and 89, Code of Obligations (SR 220) arts. 62, 63, 67 and 470, read in the unofficial English consolidations on fedlex. SIX Interbank Clearing Implementation Guidelines, release 4.12 (in force from 21 November 2025): Base Document v2.5 chapter 3; SIC RTGS Cancellation (camt.008) v2.1 chapter 2; Return Request (camt.056) v2.4 section 3.1. The SIC Handbook was not read; it is participant-only.", "confidence": "high" }, "currency": { "effective_since": "2025-11-21", "effective_note": "2025-11-21 is the date the release 4.12 interbank guidelines cited here took effect; it is not the date SIC finality was first defined, which the public sources do not give. National Bank Ordinance art. 25a has had its current wording since 1 January 2016. Release 5.3 on 2026-11-13 moves the RTGS service to the SIC5 platform; the release notes (v1.3, dated 21 September 2026) describe no change to the finality point, but the process changes are in an extranet document that was not read.", "source_edition": "SNB Report on the SIC System and Disclosure Report 2025 (May 2026); SIX Implementation Guidelines release 4.12 (Base Document v2.5; camt.008 v2.1; camt.056 v2.4); National Bank Ordinance status 2024-07-01; Financial Market Infrastructure Act status 2024-02-01; Code of Obligations status 2026-01-01", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.snb.ch/public/asset/en/www-snb-ch/publications/sicsystem-disclosure/sicsystem-disclosure-all/sicsystem_disclosure_2025/publications0_en/sic_disclosure_2025.en.pdf", "source_class": "public_primary", "source_title": "SNB Report on the SIC System and Disclosure Report 2025, chapters 2 and 6", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms finality at the debit to the sender's settlement account (footnote 3 cites NBO art. 25a para. 1), settlement in central bank money, the wait file, and the 17.00 cancellation deadline." }, { "source_url": "https://www.fedlex.admin.ch/eli/cc/27/317_321_377/en", "source_class": "secondary", "source_title": "Swiss Code of Obligations (SR 220), unofficial English translation, fedlex consolidated text", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms art. 470 para. 2bis: a cashless payment instruction becomes irrevocable once the amount is debited from the customer's account unless a payment system's rules provide otherwise. Unofficial translation, treated as secondary per validator guidance, not as authoritative_primary." } ] }, "rail_name": "Swiss Interbank Clearing (SIC)", "governing_authority": "SIX Interbank Clearing on behalf of the Swiss National Bank", "snapshot": "2026-09-18", "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "ch-sic:hours", "id": "hours", "rail": "ch-sic", "kind": "rail-fact", "facet": "hours", "name": "When is the SIC RTGS service open, and how does its clearing day run?", "statement": "The SIC RTGS service settles almost around the clock on weekdays, closing for about half an hour at roughly 18.15 to end the clearing day, and the SNB reports that it has also been open at weekends since April 2025. The clearing day is not the calendar day: each one starts the previous evening, and clearing day Monday starts on Friday evening. Three clearing stops at 17.00, 18.00 and 18.15 narrow what may still be sent at the end of each day.", "details": [ { "label": "Weekday operation", "value": "Open on weekdays nearly all day and night, with a pause of about 30 minutes around 18.15 while the previous clearing day is closed off.", "citation": "SNB, The Swiss Interbank Clearing (SIC) payment system: Report on the SIC System and Disclosure Report 2025 (published May 2026), chapter 6 'Operating hours' and chart 8", "rests_on": "guidance" }, { "label": "Weekends", "value": "Open at weekends since April 2025, according to the 2025 edition of the SNB report. SIC may close for a few hours at a weekend, with notice beforehand, mainly for maintenance.", "citation": "SNB Report and Disclosure Report 2025, chapter 6 'Operating hours'", "rests_on": "guidance" }, { "label": "Clearing days", "value": "Five clearing days a week. The day changes after day-end processing, shortly after 18.15; clearing days Tuesday to Friday begin the evening before, and clearing day Monday begins on Friday evening, so weekend payments carry Monday's clearing day.", "citation": "SNB Report and Disclosure Report 2025, chapter 6 'Clearing days' and chart 8", "rests_on": "guidance" }, { "label": "End-of-day stops", "value": "Up to clearing stop 1 at 17.00 any kind of payment is accepted. Between 17.00 and clearing stop 2 at 18.00 only interbank payments are accepted, so banks can borrow on the money market to clear what is still pending. From 18.00 to clearing stop 3 at 18.15 participants can also borrow from the SNB before day-end processing begins.", "citation": "SNB Report and Disclosure Report 2025, chapter 6 'Clearing day process' and footnote 11", "rests_on": "guidance" }, { "label": "Timed payments", "value": "A sender may set an earliest settlement time, as a calendar date and time, because a clearing day spans more than one calendar day; a time later than that clearing day's first stop gets the payment rejected. A settlement date in the message is ignored; the service stamps the clearing day itself.", "citation": "SIX Interbank Clearing, Implementation Guidelines SIC RTGS, Customer Payments (pacs.008) v2.6 (valid from 21 November 2025), elements Interbank Settlement Date and Settlement Time Indication / Debit Date Time", "rests_on": "rule" }, { "label": "Time stamps", "value": "Times the service generates are Swiss local time (CET or CEST) with the UTC offset. Dates carry no time zone and are read as Swiss local or system dates.", "citation": "SIX Interbank Clearing, Implementation Guidelines Base Document v2.5 (valid from 21 November 2025), sections 4.3.1 and 4.3.2", "rests_on": "rule" }, { "label": "Who sets the hours", "value": "The SNB as system manager sets when operations begin and end; SIC Ltd runs the service.", "citation": "SNB Report and Disclosure Report 2025, chapter 4 'Shared responsibility'", "rests_on": "guidance" } ], "exceptions": [ "The previous edition of the SNB report, published in September 2025, still described the RTGS service as closed from Saturday 12.00 to Sunday 18.00, which conflicts with the 2025 edition's statement that weekend opening began in April 2025. [Unverified: which reflects current practice; the governing times are in the participant-only SIC Handbook.]", "Retail payments are often delivered to SIC only on the next bank working day, at the sending bank's choice, so being open does not mean a customer payment settles that day (SNB Report and Disclosure Report 2025, chapter 2 'Services in SIC system').", "Swiss public holidays: which calendar days open no clearing day is set in the SIX clearing calendar, which was not read. [Unverified]", "The instant payments service has different hours: it runs around the clock every day and changes clearing day together with the RTGS service (SNB Report and Disclosure Report 2025, chapter 6 'Operating hours' and 'Clearing day process')." ], "applies_to": "the operating times and clearing day of the SIC RTGS service for Swiss franc payments; times are Swiss local time", "caveat": "Everything here comes from the SNB report and the interbank guidelines; the binding operating times are in the SIC Handbook, which only participants can read. The clock times are the SNB's round figures ('approximately', 'about'); the exact start-up time is not given in any public source read.", "related": [ "ch-sic:settlement", "ch-sic:finality", "ch-sic:decision-points", "ch-sic-ip:hours" ], "basis": { "sources": "SNB, Report on the SIC System and Disclosure Report 2025 (May 2026), chapters 2, 4 and 6 with chart 8 and footnote 11, read in full; the 2024 edition (published September 2025), chapter 6, read for comparison. SIX Interbank Clearing Implementation Guidelines release 4.12 (in force from 21 November 2025): Base Document v2.5 sections 4.3.1 and 4.3.2; SIC RTGS Customer Payments (pacs.008) v2.6, settlement date and time elements.", "confidence": "medium" }, "currency": { "effective_since": "2025-11-21", "effective_note": "2025-11-21 is when the release 4.12 guidelines cited took effect. The SNB dates weekend opening to April 2025 without a day. The clearing stops and clearing day structure are older and their start is not dated in public sources. Release 5.3 on 2026-11-13 moves the RTGS service to the SIC5 platform; the release notes do not announce new operating times.", "source_edition": "SNB Report on the SIC System and Disclosure Report 2025 (May 2026) and 2024 (September 2025); SIX Implementation Guidelines release 4.12 (Base Document v2.5; pacs.008 v2.6)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.snb.ch/public/asset/en/www-snb-ch/publications/sicsystem-disclosure/sicsystem-disclosure-all/sicsystem_disclosure_2025/publications0_en/sic_disclosure_2025.en.pdf", "source_class": "public_primary", "source_title": "SNB Report on the SIC System and Disclosure Report 2025, chapter 6", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms weekday near round-the-clock operation with an about 18.15 pause, the three clearing stops at 17.00, 18.00 and 18.15 with their payment-type restrictions, five clearing days with Monday starting Friday evening, and the weekend wording conflict: this 2025 edition states weekend opening since April 2025 while the 2024 edition (checked_by same session) describes a Saturday 12.00 to Sunday 18.00 closure, matching the record's stated conflict." }, { "source_url": "https://www.snb.ch/public/asset/en/www-snb-ch/publications/sicsystem-disclosure/sicsystem-disclosure-all/sicsystem_disclosure_2024/publications0_en/sicsystem_disclosure_2024.en.pdf", "source_class": "public_primary", "source_title": "SNB Report on the SIC System and Disclosure Report 2024 (published September 2025), chapter 6", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the earlier edition's Saturday 12.00 to Sunday 18.00 weekend closure wording, which conflicts with the 2025 edition's statement that weekend opening began in April 2025; the record's exceptions correctly state both." } ] }, "rail_name": "Swiss Interbank Clearing (SIC)", "governing_authority": "SIX Interbank Clearing on behalf of the Swiss National Bank", "snapshot": "2026-09-18", "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "ch-sic:liability", "id": "liability", "rail": "ch-sic", "kind": "rail-fact", "facet": "liability", "name": "Who bears the loss when something goes wrong with a SIC RTGS payment?", "statement": "The public record says little. Liability among the SNB, SIC Ltd and each participant is set in their contracts and the SIC Handbook, none of which is public. What can be read is that settlement leaves no credit exposure between banks, that SIC Ltd disclaims responsibility for how participants apply its schemas, identifiers and split rules, and that a bank's duty to its own customer falls under general Swiss contract law.", "details": [ { "label": "Where the allocation lives", "value": "Participation rests on agreements between each participant and the SNB and between each participant and SIC Ltd, filled out by the SIC Handbook and other technical rules, with the SNB's Terms of Business also applying. The contracts are under Swiss law with jurisdiction in Zurich. Only participants can read the Handbook.", "citation": "SNB, The Swiss Interbank Clearing (SIC) payment system: Report on the SIC System and Disclosure Report 2025 (published May 2026), chapter 5 'Legal framework' and Disclosure Report principles 1 and 23; SNB Instruction sheet on admission to the SIC system and sight deposit accounts (17 November 2023, updated 27 February 2025), section 2.1", "rests_on": "guidance" }, { "label": "No credit risk between banks", "value": "Because each payment settles gross, only with cover and in central bank money, the SNB states there is no credit risk between participants and none for SIC Ltd beyond lost fees.", "citation": "SNB Report and Disclosure Report 2025, Disclosure Report principles 4 and 7", "rests_on": "guidance" }, { "label": "What SIC Ltd disclaims", "value": "SIC Ltd takes no liability for how users interpret its freely published XML schemas, takes no responsibility for unpublished BICs forwarded from Swift, and leaves the correct splitting of large payments wholly to the participants, stating it only transports message content.", "citation": "SIX Interbank Clearing, Implementation Guidelines Base Document v2.5 (valid from 21 November 2025), sections 2.1, 4.5 and 4.6", "rests_on": "rule" }, { "label": "Cost of a payment that never settles", "value": "When an expected payment is deleted at day end for lack of cover, the recipient may charge the sender a penalty fee, because it may have planned its own payments around the incoming one.", "citation": "SNB Report and Disclosure Report 2025, chapter 6 'Settlement algorithm' and footnote 14", "rests_on": "guidance" }, { "label": "The bank and its customer", "value": "Under the Code of Obligations, a party that fails to perform must pay damages unless it shows it was not at fault, an agent owes careful and faithful performance, and a clause excluding liability in advance for intent or gross negligence is void. [Inference: Swiss banks' transfer services are generally treated as mandates or payment instructions under these articles; no Swiss case law or commentary was read.]", "citation": "Code of Obligations (SR 220), arts. 97 para. 1, 100 para. 1 and 398 paras. 1 and 2, consolidated status 1 January 2026, unofficial English translation on fedlex", "rests_on": "law" } ], "exceptions": [ "If a participant's cross-network message needs character conversion into another network, getting that right is entirely the institutions' own responsibility (SIX Interbank Clearing, Implementation Guidelines Base Document v2.5, section 4.4).", "The SNB may suspend or exclude a participant, for instance after insolvency measures or a breach of its contract or the Handbook (SNB instruction sheet on admission, section 6).", "Liechtenstein customers deal with banks under Liechtenstein law, which was not read. [Unverified]" ], "applies_to": "allocation of loss and responsibility among SIC participants, the SNB and SIC Ltd, and between a participant bank and its customer, for Swiss franc payments in the SIC RTGS service", "caveat": "Low confidence on purpose: the documents that actually allocate liability among the SNB, SIC Ltd and the participants are private contracts and the participant-only SIC Handbook. The public guidelines contain only disclaimers by SIC Ltd, and the customer-level lines rest on general contract law read in an unofficial English translation, without case law.", "related": [ "ch-sic:finality", "ch-sic:settlement", "ch-sic:limits", "ch-sic:consumer-law", "ch-sic:participants", "ch-sic-ip:liability" ], "basis": { "sources": "SNB, Report on the SIC System and Disclosure Report 2025 (May 2026), chapters 5 and 6, footnote 14 and Disclosure Report principles 1, 4, 7 and 23. SNB Instruction sheet on admission to the SIC system and sight deposit accounts (2023, updated 2025), sections 2.1 and 6. SIX Interbank Clearing Implementation Guidelines Base Document v2.5 (in force from 21 November 2025), sections 2.1, 4.4, 4.5 and 4.6. Code of Obligations (SR 220) arts. 97, 100 and 398, unofficial English consolidation of 1 January 2026. Participant contracts, SNB Terms of Business and the SIC Handbook not read.", "confidence": "low" }, "currency": { "effective_since": "2025-11-21", "effective_note": "2025-11-21 is when Base Document v2.5 took effect. In Base Document v2.7, in force from 2026-11-13, the same disclaimers sit in sections 2.1, 3.3, 3.4 and 3.5.", "source_edition": "SNB Report on the SIC System and Disclosure Report 2025 (May 2026); SNB instruction sheet on admission (2023-11-17, updated 2025-02-27); SIX Implementation Guidelines Base Document v2.5; Code of Obligations status 2026-01-01", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.snb.ch/public/asset/en/www-snb-ch/publications/sicsystem-disclosure/sicsystem-disclosure-all/sicsystem_disclosure_2025/publications0_en/sic_disclosure_2025.en.pdf", "source_class": "public_primary", "source_title": "SNB Report on the SIC System and Disclosure Report 2025, chapters 5 and 6", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the contractual basis of participation, no credit risk between participants from gross real-time settlement, and the day-end penalty fee footnote." }, { "source_url": "https://www.six-group.com/dam/download/banking-services/standardization/sic-eurosic/4-12-5-2/ig-base-document-ch-interbank-2025-en.pdf", "source_class": "authoritative_primary", "source_title": "SIX Interbank Clearing, Implementation Guidelines for ISO 20022 Interbank Messages, Base Document v2.5", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms SIC Ltd's disclaimers on XML schema interpretation, unpublished BICs, and that correct application of the amount-split rule is the participants' full responsibility (sections 4.4 to 4.6)." }, { "source_url": "https://www.fedlex.admin.ch/eli/cc/27/317_321_377/en", "source_class": "secondary", "source_title": "Swiss Code of Obligations (SR 220), unofficial English translation, fedlex consolidated text", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms art. 97 para. 1 (damages absent proof of no fault), art. 100 para. 1 (advance exclusion of liability for intent or gross negligence is void) and art. 398 paras. 1 and 2 (mandatee's duty of careful and faithful performance). Unofficial translation, treated as secondary." } ] }, "rail_name": "Swiss Interbank Clearing (SIC)", "governing_authority": "SIX Interbank Clearing on behalf of the Swiss National Bank", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "ch-sic:limits", "id": "limits", "rail": "ch-sic", "kind": "rail-fact", "facet": "limits", "name": "What amount limits apply to a payment in the SIC RTGS service?", "statement": "The SIC RTGS service sets no business maximum for a Swiss franc payment. The only published ceiling is the size of the amount field, just under CHF 100 billion. What actually limits a payment is the sender's cover, and money market payments above CHF 100 million must be split into smaller ones.", "details": [ { "label": "Field ceiling", "value": "An amount must be greater than zero, with at most 13 digits of which 2 may be decimals, which caps a single message at CHF 99,999,999,999.99. This applies to customer payments (pacs.008) and to bank payments (pacs.009) alike.", "citation": "SIX Interbank Clearing, Implementation Guidelines SIC RTGS, Customer Payments (pacs.008) v2.6 (valid from 21 November 2025), element Interbank Settlement Amount; same element in Bank and Third-Party System Payments (pacs.009) v2.4", "rests_on": "rule" }, { "label": "Split rule for large money market payments", "value": "Money market payments between participants above CHF 100 million have to be broken into partial payments; each part carries the code SPLI, its own UETR and the original end-to-end reference. The guidelines add that the method can be used for any payment, and the SNB describes the rule as a request to split payments over CHF 100 million wherever possible, to avoid gridlock.", "citation": "SIX Interbank Clearing, Implementation Guidelines Base Document v2.5 (valid from 21 November 2025), section 4.6; SNB, The Swiss Interbank Clearing (SIC) payment system: Report on the SIC System and Disclosure Report 2025 (published May 2026), Disclosure Report principle 7", "rests_on": "rule" }, { "label": "Cover is the working limit", "value": "A payment settles only if the sender's RTGS settlement account covers it; otherwise it waits. How much a bank can send in a day therefore depends on its sight deposits, incoming payments and SNB intraday liquidity, not on a published cap.", "citation": "SNB Report and Disclosure Report 2025, chapter 6 'Settlement algorithm' and Disclosure Report principle 7", "rests_on": "guidance" }, { "label": "Currency", "value": "Swiss francs only in the SIC RTGS service; the same message format carries euro only in the separate euroSIC service.", "citation": "SIX Interbank Clearing, Implementation Guidelines SIC RTGS, Customer Payments (pacs.008) v2.6, element Interbank Settlement Amount, currency attribute", "rests_on": "rule" }, { "label": "Bank and customer limits", "value": "Any cap a bank puts on its customers' payments belongs to that bank's own offering. The Swiss Payment Standards leave customer processing rules to each institution.", "citation": "SIX, Swiss Payment Standards Business Rules v3.3 (20 February 2026, valid from 14 November 2026), section 1.4.2", "rests_on": "practice" } ], "exceptions": [ "The split rule is not checked by the service; a payment over CHF 100 million that is not split is not rejected for that reason, and correct application is the participants' responsibility (Base Document v2.5, section 4.6).", "euroSIC applies its own split threshold of EUR 50 million, and euroSIC is due to close in November 2027 (Base Document v2.5, section 4.6; SIX Interbank Clearing, SIC Platform Release Notes 2026 v1.3, section 1.1).", "The instant payments service has a separate, much lower limit per payment; see its own profile (SNB Report and Disclosure Report 2025, Disclosure Report principle 7)." ], "applies_to": "the amount of a single Swiss franc payment in the SIC RTGS service", "caveat": "'No maximum' here means none in the public guidelines or the SNB report. The SIC Handbook, which is participant-only, could hold operating limits not visible from outside; it was not read. The split rule is described in the guidelines as coming from 'the regulations' of the RTGS service, which are also not public.", "related": [ "ch-sic:settlement", "ch-sic:decision-points", "ch-sic-ip:limits" ], "basis": { "sources": "SIX Interbank Clearing Implementation Guidelines release 4.12 (in force from 21 November 2025): Base Document v2.5 section 4.6; SIC RTGS Customer Payments (pacs.008) v2.6 and Bank and Third-Party System Payments (pacs.009) v2.4, amount elements. SNB, Report on the SIC System and Disclosure Report 2025 (May 2026), chapter 6 and Disclosure Report principle 7. SIX Swiss Payment Standards Business Rules v3.3, section 1.4.2. SIC Platform Release Notes 2026 v1.3, section 1.1.", "confidence": "medium" }, "currency": { "effective_since": "2025-11-21", "effective_note": "2025-11-21 is when the release 4.12 guidelines stating the field ceiling and the split rule took effect; neither rule's first introduction is dated in public sources. In Base Document v2.7, in force from 2026-11-13 with release 5.3, the split rule moves to section 3.5 unchanged in substance. The Business Rules v3.3 cited apply from 2026-11-14; the edition in force before then was not read.", "source_edition": "SIX Implementation Guidelines release 4.12 (Base Document v2.5; pacs.008 v2.6; pacs.009 v2.4); SNB Report on the SIC System and Disclosure Report 2025 (May 2026); SPS Business Rules v3.3", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.six-group.com/dam/download/banking-services/standardization/sic-eurosic/4-12-5-2/ig-base-document-ch-interbank-2025-en.pdf", "source_class": "authoritative_primary", "source_title": "SIX Interbank Clearing, Implementation Guidelines for ISO 20022 Interbank Messages, Base Document v2.5", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the CHF 100 million money market split threshold, the SPLI service level code, new UETR and preserved end-to-end reference requirement, and that the service does not validate the split and full responsibility sits with participants, in section 4.6." }, { "source_url": "https://www.snb.ch/public/asset/en/www-snb-ch/publications/sicsystem-disclosure/sicsystem-disclosure-all/sicsystem_disclosure_2025/publications0_en/sic_disclosure_2025.en.pdf", "source_class": "public_primary", "source_title": "SNB Report on the SIC System and Disclosure Report 2025, Disclosure Report principle 7", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms that SIC only executes payments with sufficient cover, and separately confirms the CHF 20,000 per instant payment limit used in the sibling ch-sic-ip:limits record." } ] }, "rail_name": "Swiss Interbank Clearing (SIC)", "governing_authority": "SIX Interbank Clearing on behalf of the Swiss National Bank", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "ch-sic:messages", "id": "messages", "rail": "ch-sic", "kind": "rail-fact", "facet": "messages", "name": "Which messages does the SIC RTGS service use, and on which standard?", "statement": "The SIC RTGS service runs on ISO 20022, using Swiss schemas restricted from the 2019 message versions, and SIX's interbank implementation guidelines for them bind every participant. Customer payments travel as pacs.008, bank and third-party system payments as pacs.009, returns as pacs.004, and every payment message is acknowledged with pacs.002; a set of camt and acmt messages covers return requests, queue management, liquidity and reporting.", "details": [ { "label": "Binding guidelines", "value": "The message definitions in the interbank implementation guidelines are binding on all participants, and the services check incoming messages against the published Swiss XML schemas, which carry a CH-specific namespace on top of the ISO base.", "citation": "SIX Interbank Clearing, Implementation Guidelines for ISO 20022 Interbank Messages, Base Document v2.5 (28 February 2025, valid from 21 November 2025), sections 2.1 and 2.2", "rests_on": "rule" }, { "label": "Payment messages and their versions", "value": "Customer credit transfers are pacs.008.001.08, financial institution transfers pacs.009.001.08, returns pacs.004.001.09 and status reports pacs.002.001.10. Payment types inside them are set by proprietary codes, for example CSTPMT for a generic customer payment and CSTRTN for its return.", "citation": "SIX Interbank Clearing, Base Document v2.5, section 2.6 table 8 and section 4.7.1", "rests_on": "rule" }, { "label": "Acknowledgements", "value": "Every pacs message is answered with pacs.002: the service acknowledges what the sender submitted, and the receiving participant acknowledges what the service delivered. Rejections use three-digit SIC error codes in a proprietary field, not ISO reason codes; the full list of those codes is in the participant-only SIC Handbook.", "citation": "SIX Interbank Clearing, Implementation Guidelines SIC RTGS, Payment Receipts (pacs.002) v2.3 (valid from 21 November 2025), sections 3.1, 3.2 and 3.5; Base Document v2.5, section 3.2", "rests_on": "rule" }, { "label": "Investigations and queue control", "value": "Return requests travel as camt.056 and their rejection as camt.029. Waiting payments are cancelled with camt.008 and reprioritised with camt.007, and liquidity is reserved with camt.048; the service confirms each of these with camt.025.", "citation": "SIX Interbank Clearing, Base Document v2.5, sections 2.5.1, 3.3 and 3.8", "rests_on": "rule" }, { "label": "Identifying participants", "value": "Participants are addressed by a six-digit SIC IID, with clearing system code CHSIC, or by BIC where a message allows; BICs must be published ones, and for the previous instructing agents only the first eight characters are checked.", "citation": "SIX Interbank Clearing, Implementation Guidelines SIC RTGS, Cancellation (camt.008) v2.1 (valid from 21 November 2025), section 3.3.1; Payment Receipts (pacs.002) v2.3, section 3.6; Base Document v2.5, section 4.5", "rests_on": "rule" }, { "label": "Access networks", "value": "Participants reach SIC either through the SIX messaging gateway over the closed Secure Swiss Finance Network or over Swift, with a web portal for balance checks and priority changes; data carriers and SIX file transfer serve as emergency routes for the RTGS service. Messages are protected with SIX's own security component, SASS.", "citation": "SNB, The Swiss Interbank Clearing (SIC) payment system: Report on the SIC System and Disclosure Report 2025 (published May 2026), chapter 6 'Communication and messaging standards' and Disclosure Report principle 22", "rests_on": "guidance" }, { "label": "Character set and formats", "value": "Messages are UTF-8 without a byte order mark, limited to Latin characters in three Unicode blocks plus a handful of extra letters and the euro sign, the same range as the Swiss customer-to-bank standards. Times must be UTC or local with offset, with milliseconds.", "citation": "SIX Interbank Clearing, Base Document v2.5, sections 4.3.2 and 4.4", "rests_on": "rule" } ], "exceptions": [ "A message that cannot be read at all, or breaks the schema, is rejected with generic SIC error codes (118 and 221) rather than a specific reason (Payment Receipts (pacs.002) v2.3, section 3.2).", "Some messages in the RTGS set, such as camt.027 and camt.087, are used only for SEPA traffic in euroSIC, not in the Swiss franc RTGS service (Base Document v2.5, section 2.5.1 table 4 note).", "All SIC RTGS and SIC IP messages are to move to the ISO 20022 2024/2025 message versions in November 2027 under change request CR2026-SIC-0002 (SIX Interbank Clearing, SIC Platform Release Notes 2026 v1.3, dated 21 September 2026, section 1.2).", "Release 5.3 on 2026-11-13 keeps the same message versions and schemas (Base Document v2.7, 20 May 2026, section 2.6 table 8), but its planned discontinuation of unstructured addresses was withdrawn by SIC circular A27/2026 of 1 September 2026 (Release Notes 2026 v1.3, change history and section 1.1)." ], "applies_to": "ISO 20022 interbank messages exchanged between participants and the SIC RTGS service for Swiss franc payments", "caveat": "The guidelines are the public, binding message layer; the three-digit error codes, test cases and message flow detail beyond what the base document shows are in the participant-only SIC Handbook and on the SIC extranet. SIX reserves copyright in the guidelines; nothing here reproduces their tables.", "related": [ "ch-sic:return", "ch-sic:recall", "ch-sic:settlement", "ch-sic-ip:messages" ], "basis": { "sources": "SIX Interbank Clearing Implementation Guidelines release 4.12 (in force from 21 November 2025): Base Document v2.5, sections 2.1, 2.2, 2.5.1, 2.6, 3.2, 3.3, 3.8, 4.3.2, 4.4, 4.5 and 4.7.1; SIC RTGS Payment Receipts (pacs.002) v2.3 sections 3.1, 3.2, 3.5 and 3.6; Cancellation (camt.008) v2.1 section 3.3.1. Release 5.3: Base Document v2.7 section 2.6; SIC Platform Release Notes 2026 v1.3 sections 1.1 and 1.2. SNB, Report on the SIC System and Disclosure Report 2025 (May 2026), chapter 6 and Disclosure Report principle 22.", "confidence": "high" }, "currency": { "effective_since": "2025-11-21", "effective_note": "2025-11-21 is when release 4.12 of the interbank guidelines took effect. Release 5.3 takes effect on 2026-11-13 with the same ISO message versions. A move to the ISO 20022 2024/2025 versions is announced for November 2027; the exact date is not yet published.", "source_edition": "SIX Implementation Guidelines release 4.12 (Base Document v2.5; pacs.002 v2.3; camt.008 v2.1); Base Document v2.7 (release 5.3); SIC Platform Release Notes 2026 v1.3 (dated 2026-09-21); SNB Report on the SIC System and Disclosure Report 2025 (May 2026)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.six-group.com/dam/download/banking-services/standardization/sic-eurosic/4-12-5-2/ig-base-document-ch-interbank-2025-en.pdf", "source_class": "authoritative_primary", "source_title": "SIX Interbank Clearing, Implementation Guidelines for ISO 20022 Interbank Messages, Base Document v2.5", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the binding status of the interbank guidelines, the pacs.008/pacs.009/pacs.004/pacs.002 message set and versions, camt.056/camt.029/camt.008/camt.007/camt.048/camt.025 for investigations and queue control, and UTF-8/Latin character rules." }, { "source_url": "https://www.snb.ch/public/asset/en/www-snb-ch/publications/sicsystem-disclosure/sicsystem-disclosure-all/sicsystem_disclosure_2025/publications0_en/sic_disclosure_2025.en.pdf", "source_class": "public_primary", "source_title": "SNB Report on the SIC System and Disclosure Report 2025, chapter 6", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms access over the SIX messaging gateway on SSFN or Swift, and the SASS security component, under 'Communication and messaging standards'." } ] }, "rail_name": "Swiss Interbank Clearing (SIC)", "governing_authority": "SIX Interbank Clearing on behalf of the Swiss National Bank", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "ch-sic:participants", "id": "participants", "rail": "ch-sic", "kind": "rail-fact", "facet": "participants", "name": "Who can take part in the SIC RTGS service, and on what terms?", "statement": "The SNB decides who joins SIC, and it admits participants only directly: each one holds its own settlement account and sight deposit account at the SNB, with no sponsoring bank between it and the system. Most of the 290 participants at the end of 2025 were banks, and six third-party system operators such as the securities settlement system also debit and credit accounts without holding one.", "details": [ { "label": "Who decides", "value": "Admission, suspension and exclusion are the SNB's decisions, taken under its published instruction sheet. The general test is that a participant must contribute significantly to the SNB's tasks without posing major risks, and the SNB is not bound by the sheet: it may widen or narrow admission, for monetary policy reasons in particular.", "citation": "SNB Instruction sheet on admission to the SIC system and sight deposit accounts (17 November 2023, updated 27 February 2025), section 1; SNB, The Swiss Interbank Clearing (SIC) payment system: Report on the SIC System and Disclosure Report 2025 (published May 2026), chapter 5 and Disclosure Report principle 18", "rests_on": "rule" }, { "label": "Main admission type", "value": "Participation with a sight deposit account is direct, with no other participant as intermediary, and normally gives one sight deposit account and one settlement account per service. It is governed by contracts with the SNB and SIC Ltd, the SIC Handbook and the SNB's Terms of Business.", "citation": "SNB Instruction sheet on admission, section 2.1", "rests_on": "rule" }, { "label": "Who is eligible", "value": "Banks, including branches of foreign banks, are the core. The sheet also lets in licensed fintech companies focused on Swiss franc payments, authorised financial market infrastructures, securities firms that settle in SECOM, and, where they add to secured franc money market liquidity, insurers and collective investment vehicles, along with a few other named institutions. Liechtenstein firms count as domestic, and the SNB may admit foreign ones.", "citation": "SNB Instruction sheet on admission, section 3 and footnote 4", "rests_on": "rule" }, { "label": "Third-party system operators", "value": "A second admission type, for the RTGS service only, lets a Swiss-domiciled third-party system operator debit and credit other participants' settlement accounts once each has authorised it, without an account of its own. The SNB reported six such operators at the end of 2025, among them SIX SIS for securities settlement.", "citation": "SNB Instruction sheet on admission, sections 2.2 and 4; SNB Report and Disclosure Report 2025, chapter 3", "rests_on": "rule" }, { "label": "No tiering, one exception", "value": "The SNB permits only direct participation, with a single exception: a FINMA-recognised clearing house that acts as an interface for its member banks, all of which hold banking licences.", "citation": "SNB Report and Disclosure Report 2025, chapter 3 footnote 6 and Disclosure Report principle 19", "rests_on": "guidance" }, { "label": "How many", "value": "290 participants at the end of 2025, most of them banks, plus 6 third-party system operators; some participants are domiciled abroad.", "citation": "SNB Report and Disclosure Report 2025, chapter 3 and chart 7", "rests_on": "guidance" }, { "label": "Duty tied to retail payments", "value": "Any participant with retail payments in the RTGS service has to be reachable for incoming instant payments; SNB texts word the deadline two ways, November 2026 at the latest in the admission instruction sheet and the report's main part, and by the end of 2026 in the report's disclosure chapter. A participant that deselects retail payments in RTGS escapes the duty.", "citation": "SNB Instruction sheet on admission, section 2.1 and footnote 2; SNB Report and Disclosure Report 2025, chapter 3 and footnote 5", "rests_on": "rule" } ], "exceptions": [ "Suspension or exclusion is possible at the SNB's decision, for example after insolvency measures against the participant or a breach of its contract or the Handbook (SNB Instruction sheet on admission, section 6; SNB Report and Disclosure Report 2025, Disclosure Report principle 13).", "A bank that holds a sight deposit account but has no transaction activity may keep the account without joining SIC; once it transacts, it must join (SNB Instruction sheet on admission, sections 2.3 and 5).", "Participants may connect through a service bureau, which must meet SIX requirements and go through an attestation process. [Unverified: the SIX requirements for SIC service bureaus (2026-03-13) were fetched by the rail brief but not read.] (SNB Report and Disclosure Report 2025, chapter 6 'Communication and messaging standards'; SNB web page on the SIC system, read 2026-09-18, which links the service bureau requirements and attestation process)", "Firms outside SIC have no participant status of any kind; there is no indirect participant class [Inference: they reach SIC only as customers of a participant] (SNB Report and Disclosure Report 2025, chapter 3)." ], "applies_to": "admission to, and participation in, the SIC RTGS service of the Swiss Interbank Clearing system", "caveat": "The instruction sheet is the SNB's own public admission instrument; its English is a translation and only the German original is authoritative. Counts are the SNB's figures at the end of 2025 and move over time.", "related": [ "ch-sic:settlement", "ch-sic:liability", "ch-sic:decision-points", "ch-sic-ip:participants" ], "basis": { "sources": "SNB Instruction sheet on admission to the SIC system and sight deposit accounts (17 November 2023, updated 27 February 2025), read in full. SNB, Report on the SIC System and Disclosure Report 2025 (May 2026), chapters 3, 5 and 6 and Disclosure Report principles 13, 18 and 19.", "confidence": "high" }, "currency": { "effective_since": "2025-02-27", "effective_note": "2025-02-27 is the date of the last update to the SNB admission instruction sheet (first issued 17 November 2023). The participant counts are as at the end of 2025. The retail participants' duty to receive instant payments applies from November 2026 at the latest.", "source_edition": "SNB instruction sheet on admission (2023-11-17, updated 2025-02-27); SNB Report on the SIC System and Disclosure Report 2025 (May 2026)", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "rail_name": "Swiss Interbank Clearing (SIC)", "governing_authority": "SIX Interbank Clearing on behalf of the Swiss National Bank", "snapshot": "2026-09-18", "source_class": null, "effective_status": "draft", "effective_status_reason": null, "boundaries": [] }, { "uid": "ch-sic:recall", "id": "recall", "rail": "ch-sic", "kind": "rail-fact", "facet": "recall", "name": "Can the sending bank stop or recall a SIC RTGS payment?", "statement": "Before settlement, yes: a payment still waiting for cover can be cancelled by the sending bank on its own say-so until 17.00. After settlement the sending bank can only ask. It sends a return request, and the receiving bank must answer it, but may answer no; the money comes back only if that bank chooses to send a return.", "details": [ { "label": "Cancelling an unsettled payment", "value": "A sender withdraws a queued, unsettled payment with a cancel transaction message (camt.008). The SNB report adds that this needs no consent from the recipient and is possible up to clearing stop 1 at 17.00. The service confirms or refuses the cancellation with a receipt (camt.025).", "citation": "SIX Interbank Clearing, Implementation Guidelines SIC RTGS, Cancellation (camt.008) v2.1 (valid from 21 November 2025), chapter 2; Base Document v2.5 (valid from 21 November 2025), section 3.8; SNB, The Swiss Interbank Clearing (SIC) payment system: Report on the SIC System and Disclosure Report 2025 (published May 2026), chapter 6 'Settlement algorithm'", "rests_on": "rule" }, { "label": "Changing instead of cancelling", "value": "A sender can also change a waiting payment's priority (camt.007) or move liquidity reservations (camt.048), which may be enough to get it settled or held back without cancelling it.", "citation": "SIX Interbank Clearing, Implementation Guidelines Base Document v2.5, section 3.8; SNB Report and Disclosure Report 2025, chapter 6 'Communication and messaging standards' and Disclosure Report principle 7", "rests_on": "rule" }, { "label": "Asking for a settled payment back", "value": "After settlement the debtor's bank sends a return request (camt.056). The service checks its form and forwards it at once; it does not check that the payment it refers to was ever processed. The request can be raised between banks or on behalf of the originating customer.", "citation": "SIX Interbank Clearing, Implementation Guidelines SIC RTGS, Return Request (camt.056) v2.4 (valid from 21 November 2025), section 3.1 and element Cancellation Reason Information / Code", "rests_on": "rule" }, { "label": "The answer is compulsory, the outcome is not", "value": "The creditor's bank is obliged to respond: by returning the money (pacs.004, reason FOCR) or by rejecting the request with a stated reason (camt.029, status RJCR). The service passes these on without processing them.", "citation": "SIX Interbank Clearing, Implementation Guidelines SIC RTGS, Return Request (camt.056) v2.4, section 3.1; Return Request Rejection (camt.029) v2.3 (valid from 21 November 2025), sections 3.1 and 3.1.1; Base Document v2.5, section 3.3", "rests_on": "rule" }, { "label": "Reason codes on the request", "value": "The guideline recommends a short set of codes for each variant (interbank or customer-driven), with FRAD and TECH usable in both, but the RTGS service does not check them, and other codes may be used when a request is forwarded from another network.", "citation": "SIX Interbank Clearing, Implementation Guidelines SIC RTGS, Return Request (camt.056) v2.4, element Cancellation Reason Information / Code", "rests_on": "rule" }, { "label": "Deadlines", "value": "None published: no public source read says how soon the creditor's bank must answer, or how late after settlement a request may be sent. [Unverified: any deadline would be in the participant-only SIC Handbook.]", "citation": "Absence across SIX Interbank Clearing Implementation Guidelines release 4.12 (camt.056 v2.4; camt.029 v2.3; Base Document v2.5) and the SNB Report and Disclosure Report 2025", "rests_on": "guidance" } ], "exceptions": [ "After clearing stop 1 at 17.00 the SNB report no longer describes a right to cancel; a payment still uncovered at the end of the clearing day is deleted by the service anyway (SNB Report and Disclosure Report 2025, chapter 6 'Settlement algorithm').", "Cancelling a payment the recipient was counting on can cost the sender: the SNB report describes a penalty fee the designated recipient may charge when an expected payment is deleted unsettled. [Unverified: whether that fee also applies to a payment the sender cancels, which the report does not say.] (SNB Report and Disclosure Report 2025, footnote 14)", "A customer who wants a settled payment back has no claim against SIC. Between customer and bank, the Code of Obligations makes the payment instruction irrevocable once the customer's account is debited unless the system's rules say otherwise, and a claim against the recipient runs in unjust enrichment (Code of Obligations (SR 220), arts. 470 para. 2bis and 62, consolidated status 1 January 2026, unofficial English translation).", "The instant payments service has its own return request with a closed and service-checked code list; see its profile (SIX Interbank Clearing, Implementation Guidelines SIC IP Service, IP Return Request (camt.056) v2.3, element Cancellation Reason Information / Code)." ], "applies_to": "cancellation of unsettled payments and return requests for settled Swiss franc payments between participants in the SIC RTGS service", "caveat": "The two routes are different in kind. Cancellation acts on the sender's own queued order and needs nobody's agreement; a return request only asks, and whether money comes back is the receiving bank's decision.", "related": [ "ch-sic:finality", "ch-sic:return", "ch-sic:settlement", "ch-sic:hours", "ch-sic:decision-points", "ch-sic-ip:recall" ], "basis": { "sources": "SIX Interbank Clearing Implementation Guidelines release 4.12 (in force from 21 November 2025): Base Document v2.5 sections 3.3 and 3.8; SIC RTGS Cancellation (camt.008) v2.1 chapter 2; Return Request (camt.056) v2.4 section 3.1 and reason code element; Return Request Rejection (camt.029) v2.3 sections 3.1 and 3.1.1 and status elements. SNB, Report on the SIC System and Disclosure Report 2025 (May 2026), chapter 6 and footnote 14. Code of Obligations (SR 220) arts. 62 and 470, unofficial English consolidation of 1 January 2026.", "confidence": "medium" }, "currency": { "effective_since": "2025-11-21", "effective_note": "2025-11-21 is when the release 4.12 guidelines cited took effect. From 2026-11-13 (release 5.3) the cancellation guideline is camt.008 v2.2; the return request and rejection guidelines (camt.056 v2.4, camt.029 v2.3) stay the same versions.", "source_edition": "SIX Implementation Guidelines release 4.12 (Base Document v2.5; camt.008 v2.1; camt.056 v2.4; camt.029 v2.3); SNB Report on the SIC System and Disclosure Report 2025 (May 2026); Code of Obligations status 2026-01-01", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.six-group.com/dam/download/banking-services/standardization/sic-eurosic/4-12-5-2/ig-base-document-ch-interbank-2025-en.pdf", "source_class": "authoritative_primary", "source_title": "SIX Interbank Clearing, Implementation Guidelines for ISO 20022 Interbank Messages, Base Document v2.5", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the RTGS return request message flow structure (section 3.3, camt.056 and camt.029 listed for RTGS participants in table 4) and camt.008 cancellation as part of the module set; does not itself state the DUPL/TECH/FRAD recommended reason codes, which sit in the camt.056 module document, corroborated separately against the RTGS module documents archive." }, { "source_url": "https://www.snb.ch/public/asset/en/www-snb-ch/publications/sicsystem-disclosure/sicsystem-disclosure-all/sicsystem_disclosure_2025/publications0_en/sic_disclosure_2025.en.pdf", "source_class": "public_primary", "source_title": "SNB Report on the SIC System and Disclosure Report 2025, chapter 6", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the 17.00 cancellation deadline for a queued payment and the penalty-fee footnote for a payment deleted unsettled at day end." }, { "source_url": "https://www.six-group.com/dam/download/banking-services/standardization/sic-eurosic/4-12-5-2/ig-module-docs-sic-rtgs-2025-4.12-en.zip", "source_class": "authoritative_primary", "source_title": "SIX Interbank Clearing, Implementation Guidelines SIC RTGS, Return Request (camt.056) v2.4, in the SIC RTGS module documents archive, release 4.12", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the camt.056 recommended reason codes: DUPL, TECH and FRAD for an interbank request, CUST, TECH and FRAD for a request by the originator, and that the RTGS service does not validate these codes." } ] }, "rail_name": "Swiss Interbank Clearing (SIC)", "governing_authority": "SIX Interbank Clearing on behalf of the Swiss National Bank", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "ch-sic:refund", "id": "refund", "rail": "ch-sic", "kind": "rail-fact", "facet": "refund", "name": "Does the SIC RTGS service give a payer any right to a refund?", "statement": "No refund right exists in SIC itself. SIC settles payments that the sending bank pushes, and its public rules provide only a cancellation before settlement, a return request after it, and a return sent at the receiving bank's choice. Refund rights for Swiss direct debits, which also settle through SIC, belong to the direct debit schemes and were not read.", "details": [ { "label": "What the rail offers instead", "value": "The only interbank tools for money going back are a return (pacs.004), a return request (camt.056) and its rejection (camt.029). None of them gives the payer or the payer's bank an entitlement; each return is a new payment the receiving side decides to make.", "citation": "SIX Interbank Clearing, Implementation Guidelines Base Document v2.5 (valid from 21 November 2025), sections 2.5.1 and 3.3; SIC RTGS Return Request (camt.056) v2.4 (valid from 21 November 2025), section 3.1", "rests_on": "rule" }, { "label": "Direct debits pass through, their rules do not", "value": "Swiss direct debit collections settle in the RTGS service as customer payments of their own payment types, but the SIC guidelines carry no refund process for them. [Unverified: the refund and objection rights of the LSV+ and CH-DD schemes are set in those schemes' own rules, which were not read.]", "citation": "SIX Interbank Clearing, Implementation Guidelines Base Document v2.7 (valid from 13 November 2026), table 11, direct debit payment types ESRDEB and IPIDEB", "rests_on": "rule" }, { "label": "What a payer can do under general law", "value": "A payer who paid money that was not owed can claim it back from the recipient under the Code of Obligations' rules on unjust enrichment, within three years of learning of the claim and ten years at most. This is a civil claim against the recipient, not a payment system process.", "citation": "Code of Obligations (SR 220), arts. 62, 63 and 67, consolidated status 1 January 2026, unofficial English translation on fedlex", "rests_on": "law" } ], "exceptions": [ "A bank may agree with its own customer to reimburse in cases such as an unauthorised payment; any such promise is in the customer contract and differs between banks. [Unverified: no Swiss statute read gives a payer a refund right equivalent to the EU's for unauthorised payments.]", "Liechtenstein is inside SIC and treated as domestic for admission, but it is a separate legal jurisdiction and in the European Economic Area, so a Liechtenstein customer may have statutory refund rights a Swiss customer does not. [Unverified: Liechtenstein law was not read.] (SNB Instruction sheet on admission to the SIC system and sight deposit accounts, 17 November 2023 updated 27 February 2025, section 3 footnote 4)" ], "applies_to": "payments settled in the SIC RTGS service, from the payer's point of view; Swiss direct debit scheme rules are outside this record", "caveat": "This record asserts an absence: no refund path appears in the public SIC guidelines or the SNB report. Absence in public documents is weaker evidence than a rule that says so, and the participant-only SIC Handbook was not read.", "related": [ "ch-sic:return", "ch-sic:recall", "ch-sic:finality", "ch-sic:consumer-law", "ch-sic-ip:refund" ], "basis": { "sources": "SIX Interbank Clearing Implementation Guidelines release 4.12 (in force from 21 November 2025): Base Document v2.5 sections 2.5.1 and 3.3 (message set and return request flow); SIC RTGS Return Request (camt.056) v2.4 section 3.1. Base Document v2.7 (release 5.3) table 11 for direct debit payment types. Code of Obligations (SR 220) arts. 62, 63 and 67, unofficial English consolidation of 1 January 2026. SNB instruction sheet on admission, section 3. LSV+ and CH-DD scheme rules not read; Liechtenstein law not read.", "confidence": "low" }, "currency": { "effective_since": "2025-11-21", "effective_note": "2025-11-21 is when the release 4.12 guidelines cited took effect. No change to the return or return request tools is announced for release 5.3 on 2026-11-13. Code of Obligations art. 67 took its current three-year wording from an amendment of 15 June 2018; its date of entry into force was not checked.", "source_edition": "SIX Implementation Guidelines release 4.12 (Base Document v2.5; camt.056 v2.4); Base Document v2.7; Code of Obligations status 2026-01-01; SNB instruction sheet on admission (2023-11-17, updated 2025-02-27)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.six-group.com/dam/download/banking-services/standardization/sic-eurosic/4-12-5-2/ig-base-document-ch-interbank-2025-en.pdf", "source_class": "authoritative_primary", "source_title": "SIX Interbank Clearing, Implementation Guidelines for ISO 20022 Interbank Messages, Base Document v2.5", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the message set offers only return (pacs.004), return request (camt.056) and rejection (camt.029) as tools for money moving back, listed under sections 2.5.1 and 3.3; no refund entitlement is described." }, { "source_url": "https://www.fedlex.admin.ch/eli/cc/27/317_321_377/en", "source_class": "secondary", "source_title": "Swiss Code of Obligations (SR 220), unofficial English translation, fedlex consolidated text", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms arts. 62, 63 and 67 on unjust enrichment restitution and the three-year/ten-year prescription period. Unofficial translation, treated as secondary." } ] }, "rail_name": "Swiss Interbank Clearing (SIC)", "governing_authority": "SIX Interbank Clearing on behalf of the Swiss National Bank", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "ch-sic:return", "id": "return", "rail": "ch-sic", "kind": "rail-fact", "facet": "return", "name": "Can a receiving bank send a settled SIC RTGS payment back, and how?", "statement": "Yes. After settlement, the receiving bank sends money back with a payment return (pacs.004), which the RTGS service settles as a fresh payment to the original sender's bank. The return can answer a return request or stand on its own, and it may carry any ISO return reason, with fixed usage for three codes. No public source read sets a deadline for it or obliges a bank to return a payment it cannot credit.", "details": [ { "label": "The message", "value": "A payment return (pacs.004, payment type CSTRTN for Swiss franc returns) goes from the original creditor's bank to the service and on to the original debtor's bank. The service settles it and then delivers it, exactly as it does a new payment, so it needs cover and waits in the wait file like one.", "citation": "SIX Interbank Clearing, Implementation Guidelines SIC RTGS, Payment Returns (pacs.004) v2.4 (valid from 21 November 2025), chapter 2 and section 3.2; Base Document v2.5 (valid from 21 November 2025), sections 3.2 and 3.3 step 8", "rests_on": "rule" }, { "label": "Reasons it may carry", "value": "Any code from the ISO external return reason list is allowed. Three have fixed uses: FOCR marks a positive answer to a return request and must carry that request's identification; NARR needs a written explanation; CUST must be used when the original creditor asked for the return, though the service does not check that.", "citation": "SIX Interbank Clearing, Implementation Guidelines SIC RTGS, Payment Returns (pacs.004) v2.4, element Return Reason Information / Reason / Code and Additional Information", "rests_on": "rule" }, { "label": "Link to the original payment", "value": "The return must name the original payment's settlement amount and settlement date and its transaction reference, so the debtor's bank can match it. The returned amount is carried separately and is subject to the same field ceiling as any payment.", "citation": "SIX Interbank Clearing, Implementation Guidelines SIC RTGS, Payment Returns (pacs.004) v2.4, sections 3.9.2, 3.11.2 and 3.11.3 and element Returned Interbank Settlement Amount", "rests_on": "rule" }, { "label": "Deadline", "value": "Not published. Neither the interbank guidelines nor the SNB report give a time within which a return must or may be sent. [Unverified: any time limit would sit in the participant-only SIC Handbook.]", "citation": "Absence across SIX Interbank Clearing Implementation Guidelines release 4.12 (Base Document v2.5; pacs.004 v2.4; camt.056 v2.4) and SNB, The Swiss Interbank Clearing (SIC) payment system: Report on the SIC System and Disclosure Report 2025 (published May 2026)", "rests_on": "guidance" }, { "label": "Finality of the return", "value": "A return settles individually and irrevocably like any other SIC payment, so a return that turns out to be wrong can only be corrected by yet another payment.", "citation": "SNB Report and Disclosure Report 2025, chapter 2 'Settlement finality'", "rests_on": "guidance" } ], "exceptions": [ "Unsettled payments are never returned: a payment still in the wait file is cancelled by the sender (camt.008) or deleted at day end instead (SNB Report and Disclosure Report 2025, chapter 6 'Settlement algorithm').", "SEPA returns in euro (payment type SEPRTN) follow the SEPA implementation guidelines and belong to euroSIC, not to the Swiss franc RTGS service (Payment Returns (pacs.004) v2.4, section 3.2 and reason code element).", "Unlike ACH-style schemes, no public source gives a receiving bank a right to return on a fixed reason list within a fixed window; the return is a tool, and when to use it is left to the banks. [Inference from the open reason list and the missing deadline]", "From 2026-11-13 the pacs.004 guideline v2.6 applies; it keeps the same reason code rules and adds address rules for returns (Payment Returns (pacs.004) v2.6, 20 May 2026, change history and reason code element)." ], "applies_to": "returns of settled Swiss franc payments between participants in the SIC RTGS service", "caveat": "The return is a separate, new payment. Its reason code tells the original sender why, but it has no legal force beyond what the banks agree; a customer's rights to the money are a matter between the customer and its bank under Swiss contract law.", "related": [ "ch-sic:finality", "ch-sic:settlement", "ch-sic:recall", "ch-sic:refund", "ch-sic:messages", "ch-sic-ip:return" ], "basis": { "sources": "SIX Interbank Clearing Implementation Guidelines release 4.12 (in force from 21 November 2025): SIC RTGS Payment Returns (pacs.004) v2.4, chapter 2, sections 3.2 and 3.11 and the reason and amount elements; Base Document v2.5, sections 3.2 and 3.3. Release 5.3 Payment Returns (pacs.004) v2.6 (20 May 2026) compared. SNB, Report on the SIC System and Disclosure Report 2025 (May 2026), chapters 2 and 6.", "confidence": "medium" }, "currency": { "effective_since": "2025-11-21", "effective_note": "2025-11-21 is when pacs.004 v2.4 took effect. Whether earlier editions already carried the open reason list with the FOCR, NARR and CUST rules was not checked. Release 5.3 brings pacs.004 v2.6 on 2026-11-13 with unchanged reason code rules.", "source_edition": "SIX Implementation Guidelines release 4.12 (Base Document v2.5; SIC RTGS pacs.004 v2.4); release 5.3 pacs.004 v2.6; SNB Report on the SIC System and Disclosure Report 2025 (May 2026)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.six-group.com/dam/download/banking-services/standardization/sic-eurosic/4-12-5-2/ig-module-docs-sic-rtgs-2025-4.12-en.zip", "source_class": "authoritative_primary", "source_title": "SIX Interbank Clearing, Implementation Guidelines SIC RTGS, Payment Returns (pacs.004) v2.4, in the SIC RTGS module documents archive, release 4.12", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms FOCR marks a positive answer to a return request and must carry the request's identification, CUST must be used when the original creditor asked for the return (not checked by the service), and NARR needs additional information, matching the record's reason-code detail." }, { "source_url": "https://www.snb.ch/public/asset/en/www-snb-ch/publications/sicsystem-disclosure/sicsystem-disclosure-all/sicsystem_disclosure_2025/publications0_en/sic_disclosure_2025.en.pdf", "source_class": "public_primary", "source_title": "SNB Report on the SIC System and Disclosure Report 2025, chapters 2 and 6", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms settlement finality applies equally to a return as to any other SIC payment, and that an uncovered payment is deleted rather than returned." } ] }, "rail_name": "Swiss Interbank Clearing (SIC)", "governing_authority": "SIX Interbank Clearing on behalf of the Swiss National Bank", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "ch-sic:settlement", "id": "settlement", "rail": "ch-sic", "kind": "rail-fact", "facet": "settlement", "name": "How and in what money does the SIC RTGS service settle, and what happens when a sender lacks funds?", "statement": "The SIC RTGS service settles every payment one by one, in real time, across settlement accounts funded each morning from the participants' sight deposits at the SNB. A payment the sender cannot cover waits in a queue ordered by priority and arrival, and anything still waiting when the clearing day ends is deleted.", "details": [ { "label": "The money used", "value": "Settlement uses sight deposits held at the SNB, which the SNB describes as legal tender and a claim on the central bank. Each participant has one sight deposit account and, per service, one settlement account; the SNB treats them as one legal unit.", "citation": "SNB, The Swiss Interbank Clearing (SIC) payment system: Report on the SIC System and Disclosure Report 2025 (published May 2026), chapter 2 'Settlement in central bank money' and Disclosure Report principle 9; SNB Instruction sheet on admission to the SIC system and sight deposit accounts (17 November 2023, updated 27 February 2025), section 2.1", "rests_on": "guidance" }, { "label": "Start and end of a clearing day", "value": "At the daily start-up the SNB moves each participant's sight deposits into its RTGS settlement account; at day-end processing the balances go back to the sight deposit accounts.", "citation": "SNB Report and Disclosure Report 2025, chapter 6 'Clearing day process'", "rests_on": "guidance" }, { "label": "No cover, no settlement", "value": "A new payment first enters a wait file and settles as soon as the sender's settlement account covers it, normally within seconds. Without cover it keeps waiting. The system never settles on credit, so SIC Ltd carries no liquidity risk from settlement.", "citation": "SNB Report and Disclosure Report 2025, chapter 6 'Settlement algorithm' and Disclosure Report principle 7", "rests_on": "guidance" }, { "label": "Order of settlement", "value": "Payments settle in the order submitted unless the sender gives them a priority. The customer payment message offers three levels (normal, high, urgent), with normal the default, and a sender may also name an earliest settlement time on the same clearing day, before clearing stop 1. A gridlock routine offsets a pair of opposite payments bilaterally when each sits at the front of the other's queue and cover allows.", "citation": "SNB Report and Disclosure Report 2025, chapter 6 'Settlement algorithm' and footnotes 12 and 13; SIX Interbank Clearing, Implementation Guidelines SIC RTGS, Customer Payments (pacs.008) v2.6 (valid from 21 November 2025), elements Settlement Priority and Settlement Time Indication / Debit Date Time", "rests_on": "rule" }, { "label": "Liquidity sources", "value": "Participants can draw interest-free intraday liquidity from the SNB through repo, which must be repaid the same clearing day, and between clearing stops 2 and 3 they can borrow overnight under the SNB liquidity-shortage financing facility. Both need collateral. They can also reserve liquidity for chosen payments (camt.048).", "citation": "SNB Report and Disclosure Report 2025, chapter 6 'SNB standing facilities' and Disclosure Report principles 5 and 7; SIX Interbank Clearing, Implementation Guidelines Base Document v2.5 (valid from 21 November 2025), section 3.8", "rests_on": "guidance" }, { "label": "Large amounts", "value": "Money market payments between participants over CHF 100 million must be split into smaller payments, each marked with the service level code SPLI and a new UETR while keeping the original end-to-end reference. The service does not check this; getting it right is on the participants.", "citation": "SIX Interbank Clearing, Implementation Guidelines Base Document v2.5 (valid from 21 November 2025), section 4.6; SNB Report and Disclosure Report 2025, Disclosure Report principle 7", "rests_on": "rule" }, { "label": "Link to the instant service", "value": "Participants move liquidity between their RTGS and IP settlement accounts with transfer payments (pacs.009 types IPLQTT and IPLQTF); an IP account can be topped up from RTGS only while the RTGS service is open.", "citation": "SNB Report and Disclosure Report 2025, chapter 6 'Clearing day process', IP service; SIX Interbank Clearing, Implementation Guidelines Base Document v2.7 (valid from 13 November 2026), table 11", "rests_on": "guidance" } ], "exceptions": [ "Payments still uncovered at the end of the clearing day are deleted rather than carried over, and the sender must resubmit them (SNB Report and Disclosure Report 2025, chapter 6 'Settlement algorithm').", "Third-party system operators such as SIX SIS for SECOM hold no account of their own; they debit and credit other participants' RTGS settlement accounts under a one-off authorisation, which is how securities settle delivery versus payment (SNB Report and Disclosure Report 2025, chapter 3).", "In an outage the RTGS service can run from a cold-standby second data centre or in a batch mode (miniSIC), and a single participant can exchange payments on a backup data carrier (SNB Report and Disclosure Report 2025, Disclosure Report principle 17).", "From the end of 2027 the SNB plans a secured liquidity facility available at any time, the Payment System Support Facility (SNB Report and Disclosure Report 2025, chapter 6 'SNB standing facilities')." ], "applies_to": "settlement of Swiss franc payments in the SIC RTGS service between SIC participants holding settlement accounts, and of payments triggered by admitted third-party system operators", "caveat": "The SNB report describes the settlement rules; the SNB 'issues' them and SIC Ltd writes the operating detail into the participant-only SIC Handbook, which was not read. The interest, penalty and collateral terms of the SNB facilities sit in SNB instruction sheets that were not read.", "related": [ "ch-sic:finality", "ch-sic:limits", "ch-sic:hours", "ch-sic-ip:settlement" ], "basis": { "sources": "SNB, Report on the SIC System and Disclosure Report 2025 (May 2026), chapters 2, 3, 4 and 6 and Disclosure Report principles 5, 7, 9 and 17, read in full. SNB Instruction sheet on admission to the SIC system and sight deposit accounts (2023, updated 2025), section 2.1. SIX Interbank Clearing Implementation Guidelines release 4.12 (in force from 21 November 2025): Base Document v2.5 sections 3.8 and 4.6; SIC RTGS Customer Payments (pacs.008) v2.6, settlement elements. Base Document v2.7 (release 5.3) table 11 for the transfer payment types.", "confidence": "high" }, "currency": { "effective_since": "2025-11-21", "effective_note": "2025-11-21 is when the release 4.12 guidelines cited took effect, not when these settlement features began, which the public sources do not date. In Base Document v2.7, in force from 2026-11-13 with release 5.3, the split rule moves to section 3.5 with the same content. Release 5.3 also migrates the RTGS service to the SIC5 platform; the release notes say some processes change to a minor extent and put the detail in an extranet document that was not read.", "source_edition": "SNB Report on the SIC System and Disclosure Report 2025 (May 2026); SNB instruction sheet on admission (2023-11-17, updated 2025-02-27); SIX Implementation Guidelines release 4.12 (Base Document v2.5; pacs.008 v2.6); Base Document v2.7 (release 5.3)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.snb.ch/public/asset/en/www-snb-ch/publications/sicsystem-disclosure/sicsystem-disclosure-all/sicsystem_disclosure_2025/publications0_en/sic_disclosure_2025.en.pdf", "source_class": "public_primary", "source_title": "SNB Report on the SIC System and Disclosure Report 2025, chapters 2, 3, 4 and 6", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms settlement in sight deposits at the SNB, the daily start-up and day-end account movements, no-cover-no-settlement, gridlock offsetting, and SNB intraday/liquidity-shortage facilities." }, { "source_url": "https://www.six-group.com/dam/download/banking-services/standardization/sic-eurosic/4-12-5-2/ig-base-document-ch-interbank-2025-en.pdf", "source_class": "authoritative_primary", "source_title": "SIX Interbank Clearing, Implementation Guidelines for ISO 20022 Interbank Messages, Base Document v2.5", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the CHF 100 million money market split rule and SPLI code (section 4.6) referenced under 'Large amounts'." } ] }, "rail_name": "Swiss Interbank Clearing (SIC)", "governing_authority": "SIX Interbank Clearing on behalf of the Swiss National Bank", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "ch-sic-ip:consumer-law", "id": "consumer-law", "rail": "ch-sic-ip", "kind": "rail-fact", "facet": "consumer-law", "name": "What consumer protections apply to a SIC instant payment?", "statement": "Few that are specific to instant payments. No Swiss statute read gives a customer a right to send instant payments, a price cap, or a payee check of the EU kind. What exists is an SNB admission condition that banks settling retail payments have to be reachable for instant payments by November 2026, a duty on the sending bank to tell the payer whether the payment worked, and general contract law.", "details": [ { "label": "Offering instant payments is the bank's choice", "value": "A customer can choose between an instant and an ordinary payment only if its bank offers instant payments; the obligation the SNB imposes is to be able to receive them, not to offer sending. [Inference: neither SNB text read obliges a participant to send or offer instant payments.]", "citation": "SNB, The Swiss Interbank Clearing (SIC) payment system: Report on the SIC System and Disclosure Report 2025 (published May 2026), chapter 2 'Services in SIC system' and chapter 3; SNB Instruction sheet on admission to the SIC system and sight deposit accounts (17 November 2023, updated 27 February 2025), section 2.1 and footnote 2", "rests_on": "rule" }, { "label": "Being told the outcome", "value": "The sending bank must tell the payer that an instant payment succeeded; if it failed, the bank tells the customer at once and, as the law requires, the reason.", "citation": "SNB Report and Disclosure Report 2025, chapter 6 'Settlement algorithm', IP service, footnotes 15 and 16", "rests_on": "guidance" }, { "label": "Fallback to an ordinary payment", "value": "Under the Swiss Payment Standards a bank may offer to push an order that failed as instant through the ordinary route instead, telling the customer through its status report; whether it does is part of its offer.", "citation": "SIX, Swiss Payment Standards Business Rules v3.3 (20 February 2026, valid from 14 November 2026), sections 1.4.2 and 2.1.3", "rests_on": "practice" }, { "label": "Irrevocable at the debit", "value": "Between customer and bank a cashless payment instruction is irrevocable once the customer's account is debited, unless a payment system's rules provide otherwise; for an instant payment that debit comes within seconds.", "citation": "Code of Obligations (SR 220), art. 470 para. 2bis, consolidated status 1 January 2026, unofficial English translation on fedlex", "rests_on": "law" }, { "label": "Mistaken payments", "value": "A payer who paid what was not owed may claim it back from the recipient in unjust enrichment, within three years of knowing and ten at most.", "citation": "Code of Obligations (SR 220), arts. 62, 63 and 67", "rests_on": "law" }, { "label": "Oversight is not consumer protection", "value": "The SNB oversees SIC as a systemically important payment system, and FINMA does not supervise it; that oversight concerns system stability, not customers' rights.", "citation": "SNB Report and Disclosure Report 2025, chapter 5; Financial Market Infrastructure Act (SR 958.1), art. 4 para. 3, consolidated status 1 February 2024, unofficial English translation", "rests_on": "law" } ], "exceptions": [ "No Swiss equivalent of the EU Instant Payments Regulation, with its duty to offer sending, price parity and payee verification, was found. [Unverified: only the laws cited were read; the Banking Act, the Unfair Competition Act and Swiss Bankers Association self-regulation were not.]", "Liechtenstein, domestic for SIC admission and part of the EEA, may apply EU-derived payment rules to its banks and customers. [Unverified: Liechtenstein law not read.] (SNB Instruction sheet on admission, section 3 footnote 4)", "The Swiss Payment Standards Business Rules v3.3 read apply from 2026-11-14; the edition in force before then was not compared." ], "applies_to": "customers, consumer or business, sending or receiving Swiss franc instant payments through the SIC IP service, and their banks, under Swiss law", "caveat": "Low confidence because much of this is an absence. The duty to inform the payer is reported by the SNB with a pointer to 'legal requirements' it does not name. Do not write that Swiss banks must offer instant payments: the November 2026 obligation is to receive.", "related": [ "ch-sic-ip:finality", "ch-sic-ip:refund", "ch-sic-ip:liability", "ch-sic:consumer-law", "ch-sic-ip:participants", "ch-sic-ip:decision-points" ], "basis": { "sources": "SNB, Report on the SIC System and Disclosure Report 2025 (May 2026), chapters 2, 3, 5 and 6 with footnotes 15 and 16. SNB Instruction sheet on admission (2023, updated 2025), sections 2.1 and 3. SIX Swiss Payment Standards Business Rules v3.3 (valid from 14 November 2026), sections 1.4.2 and 2.1.3. Code of Obligations (SR 220) arts. 62, 63, 67 and 470 and Financial Market Infrastructure Act (SR 958.1) art. 4, unofficial English consolidations on fedlex.", "confidence": "low" }, "currency": { "effective_since": "2025-11-21", "effective_note": "2025-11-21 is the start of the SIC release in force when this was drafted. The duty for retail participants to be able to receive instant payments applies by November 2026 at the latest per the SNB instruction sheet; the SNB report's first chapter of its disclosure part says by the end of 2026. The Business Rules v3.3 cited take effect on 2026-11-14.", "source_edition": "SNB Report on the SIC System and Disclosure Report 2025 (May 2026); SNB instruction sheet on admission (2023-11-17, updated 2025-02-27); SPS Business Rules v3.3 (2026-02-20); Code of Obligations status 2026-01-01; Financial Market Infrastructure Act status 2024-02-01", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.snb.ch/public/asset/en/www-snb-ch/publications/sicsystem-disclosure/sicsystem-disclosure-all/sicsystem_disclosure_2025/publications0_en/sic_disclosure_2025.en.pdf", "source_class": "public_primary", "source_title": "SNB Report on the SIC System and Disclosure Report 2025, chapters 2, 3, 5 and 6", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the duty to inform the payer of an instant payment's success or failure, the November 2026/end of 2026 wording conflict on the receive obligation (already corroborated for the sibling participants record), and that FINMA does not supervise SIC under FinMIA art. 4 para. 3." }, { "source_url": "https://www.six-group.com/dam/download/banking-services/standardization/sps/business-rules-sps-2026-en.pdf", "source_class": "authoritative_primary", "source_title": "SIX, Swiss Payment Standards Business Rules v3.3", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms section 2.1.3: an instant payment order that cannot be executed is rejected and acknowledged with a pain.002 status report, and a bank may offer to fall back to an ordinary payment flagged with local instrument ITP and status ACWC, matching the record's fallback detail exactly." }, { "source_url": "https://www.fedlex.admin.ch/eli/cc/27/317_321_377/en", "source_class": "secondary", "source_title": "Swiss Code of Obligations (SR 220), unofficial English translation, fedlex consolidated text", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms art. 470 para. 2bis and arts. 62/63/67. Unofficial translation, treated as secondary." } ] }, "rail_name": "SIC Instant Payments (SIC IP)", "governing_authority": "SIX Interbank Clearing on behalf of the Swiss National Bank", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "ch-sic-ip:decision-points", "id": "decision-points", "rail": "ch-sic-ip", "kind": "rail-fact", "facet": "decision-points", "name": "Where in a SIC instant payment does a bank or a person decide the outcome, rather than the system?", "statement": "The decisive judgement in SIC IP belongs to the receiving bank, twice: within seconds it accepts or refuses each incoming payment, and after settlement it decides whether to honour a return request. The sending bank's decisions come earlier: whether to offer instant payments at all, what limits to set, and whether to fall back to an ordinary payment. The customer's only choice is to pick instant when the bank offers it.", "details": [ { "label": "Accept or refuse, in seconds", "value": "Each incoming instant payment is put to the receiving bank, which answers with a positive or a negative feedback; a negative answer must give one of the permitted reasons and cancels the payment. Among the allowed reasons are regulatory grounds and an unspecified reason the customer or the bank itself generated, so the refusal can rest on the bank's own judgement.", "citation": "SIX Interbank Clearing, Implementation Guidelines SIC IP Service, IP Status Report (pacs.002) v2.3 (valid from 21 November 2025), sections 3.1.3 and 3.1.4; SNB, The Swiss Interbank Clearing (SIC) payment system: Report on the SIC System and Disclosure Report 2025 (published May 2026), chapter 6 and footnote 15", "rests_on": "rule" }, { "label": "Answering a return request", "value": "After settlement the creditor's bank chooses between sending an IP return and rejecting the request with a checked reason, one of which is that its customer declined. [Inference: whether it needs its customer's consent to debit the account is a matter of its customer contract; no public SIC rule addresses it.]", "citation": "SIX Interbank Clearing, Implementation Guidelines SIC IP Service, IP Return Request Rejection (camt.029) v2.3 (valid from 21 November 2025), section 3.1 and reason element; IP Returns (pacs.004) v2.3, reason element", "rests_on": "rule" }, { "label": "Returning unasked", "value": "A receiving bank may send an IP return without any request, choosing the ISO reason; no public rule says when it must.", "citation": "IP Returns (pacs.004) v2.3, change history entry for version 2.2 and reason code element", "rests_on": "rule" }, { "label": "Per-payment ceilings and debit stops", "value": "Each participant decides its own per-payment defence limits for incoming and outgoing instant payments, down to zero, and may stop debits to its IP account. Above the CHF 20,000 limit the SNB reports, pairs of participants decide bilaterally whether to allow more.", "citation": "SIX Interbank Clearing, Implementation Guidelines SIC IP Service, IP Limit Management (camt.011) v2.1 (valid from 21 November 2025), section 3.3.1; Individual IP Debit Stop (acmt.015) v1.1, chapter 2; SNB Report and Disclosure Report 2025, Disclosure Report principle 7", "rests_on": "rule" }, { "label": "Offer and fallback", "value": "The sending bank decides whether to offer instant payments and, under the Swiss Payment Standards, whether to run an order that fails as instant as an ordinary payment instead. The customer chooses instant only where the bank offers it.", "citation": "SNB Report and Disclosure Report 2025, chapter 2 'Services in SIC system'; SIX, Swiss Payment Standards Business Rules v3.3 (valid from 14 November 2026), section 2.1.3", "rests_on": "practice" } ], "exceptions": [ "Settlement is automatic once the receiving bank says yes and cover exists; time-outs and failed settlement cancel payments without anyone deciding (IP Status Report (pacs.002) v2.3, section 3.1.6).", "The sending bank has no in-flight decision: there is no message to cancel an instant payment once submitted (SIX Interbank Clearing, Implementation Guidelines Base Document v2.5, valid from 21 November 2025, sections 2.5.2 and 2.6). [Inference from the message set]", "Retail participants have no choice about being able to receive instant payments from November 2026, unless they deselect retail payments in RTGS altogether (SNB Instruction sheet on admission to the SIC system and sight deposit accounts, 17 November 2023 updated 27 February 2025, section 2.1 and footnote 2).", "This list is Orca's reading of where the public texts leave the outcome to a bank or a customer; neither SIX nor the SNB publishes such a list." ], "applies_to": "points before and after a Swiss franc instant payment in the SIC IP service where a participant, its customer or the SNB decides the outcome rather than the system", "caveat": "The receiving bank holds the key decisions on both sides of settlement. That is the opposite of the RTGS service, where the sender controls the payment until it settles.", "related": [ "ch-sic-ip:finality", "ch-sic-ip:recall", "ch-sic-ip:return", "ch-sic-ip:limits", "ch-sic-ip:participants", "ch-sic:decision-points" ], "basis": { "sources": "SIX Interbank Clearing Implementation Guidelines release 5.2 (in force from 21 November 2025): SIC IP Service IP Status Report (pacs.002) v2.3 sections 3.1.3, 3.1.4 and 3.1.6; IP Return Request Rejection (camt.029) v2.3; IP Returns (pacs.004) v2.3; IP Limit Management (camt.011) v2.1; Individual IP Debit Stop (acmt.015) v1.1; Base Document v2.5 sections 2.5.2 and 2.6. SNB, Report on the SIC System and Disclosure Report 2025 (May 2026), chapters 2 and 6 and Disclosure Report principle 7. SNB instruction sheet on admission, section 2.1. SIX Swiss Payment Standards Business Rules v3.3, section 2.1.3. The reading of these provisions as decision points is Orca's.", "confidence": "medium" }, "currency": { "effective_since": "2025-11-21", "effective_note": "2025-11-21 is when the release 5.2 guidelines cited took effect; the provisions carry over into release 5.3 on 2026-11-13. The facet caps at medium confidence because the reading of provisions as decision points is Orca's.", "source_edition": "SIX SIC IP Implementation Guidelines release 5.2; SNB Report on the SIC System and Disclosure Report 2025 (May 2026); SNB instruction sheet on admission (2023-11-17, updated 2025-02-27); SPS Business Rules v3.3", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.six-group.com/dam/download/banking-services/standardization/sic-eurosic/4-12-5-2/ig-module-docs-sic-ip-2025-5.2-en.zip", "source_class": "authoritative_primary", "source_title": "SIX Interbank Clearing, Implementation Guidelines SIC IP Service, IP Status Report (pacs.002) v2.3 and IP Limit Management (camt.011) v2.1, in the SIC IP module documents archive, release 5.2", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the receiving bank's accept/refuse decision within the pacs.002 flow (sections 3.1.3 and 3.1.4) and the participant-set per-payment defence limits down to zero (camt.011 section 3.3.1)." }, { "source_url": "https://www.snb.ch/public/asset/en/www-snb-ch/publications/sicsystem-disclosure/sicsystem-disclosure-all/sicsystem_disclosure_2025/publications0_en/sic_disclosure_2025.en.pdf", "source_class": "public_primary", "source_title": "SNB Report on the SIC System and Disclosure Report 2025, chapter 6 and Disclosure Report principle 7", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the CHF 20,000 bilateral-increase mechanism referenced as a participant decision point." } ] }, "rail_name": "SIC Instant Payments (SIC IP)", "governing_authority": "SIX Interbank Clearing on behalf of the Swiss National Bank", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "ch-sic-ip:finality", "id": "finality", "rail": "ch-sic-ip", "kind": "rail-fact", "facet": "finality", "name": "When does a SIC instant payment become final, and can it be reversed?", "statement": "A SIC instant payment is final within seconds: the service reserves the amount, the receiving bank confirms it has made the funds available to its customer, and the service then settles in central bank money and confirms the settlement. A payment that is refused or runs out of time is cancelled instead and never settles. After settlement nothing can be undone by the system; the sending bank can only ask for the money back, and the receiving bank decides.", "details": [ { "label": "Four steps in seconds", "value": "The service first reserves the amount on the sender's IP settlement account, then passes the payment to the receiving bank. That bank answers yes or no; on yes the service settles and confirms. The SNB puts the whole cycle, in principle, within ten seconds, and a payment that takes too long is cancelled.", "citation": "SNB, The Swiss Interbank Clearing (SIC) payment system: Report on the SIC System and Disclosure Report 2025 (published May 2026), chapter 6 'Settlement algorithm', IP service, and footnote 15", "rests_on": "guidance" }, { "label": "What the receiving bank's yes means", "value": "The positive answer (pacs.002 type POS002, status ACCP) tells the service that the receiving bank has accepted the payment and made the funds available to its customer. So on this rail the payee's bank credits first and interbank settlement follows at once on its answer.", "citation": "SIX Interbank Clearing, Implementation Guidelines SIC IP Service, IP Status Report (pacs.002) v2.3 (valid from 21 November 2025), section 3.1.3", "rests_on": "rule" }, { "label": "The final moment", "value": "The SNB reports that every SIC payment, instant ones included, is final once the debit to the sender's settlement account is made; for instant payments that is the IP settlement account. The service then sends an execution confirmation (EXC002, status ACSC) carrying the settlement time stamp and the clearing day.", "citation": "SNB Report and Disclosure Report 2025, chapter 2 'Settlement finality' and footnote 3, and Disclosure Report principle 8; IP Status Report (pacs.002) v2.3, section 3.1.5", "rests_on": "guidance" }, { "label": "Why the moment is fixed in rules", "value": "Swiss law obliges a systemically important payment system to say in its rules when an order becomes irrevocable and when a payment is settled, and to settle in real time or by the end of the value day at the latest. The SIC rules that do this are in the participant-only SIC Handbook.", "citation": "National Bank Ordinance (SR 951.131), art. 25a paras. 1 and 2, consolidated status 1 July 2024, unofficial English translation on fedlex", "rests_on": "law" }, { "label": "Refused or timed out", "value": "If the receiving bank says no (NEG002) or the time limit passes, the service cancels the payment and tells the sender with a cancellation message (CNC002, status CANC), copying the receiver's reason or adding its own. Cover is also a hard condition: without enough on the IP settlement account the service cancels rather than queues.", "citation": "IP Status Report (pacs.002) v2.3, sections 3.1.4 and 3.1.6; SNB Report and Disclosure Report 2025, chapter 6 and Disclosure Report principle 7", "rests_on": "rule" }, { "label": "The customer's order", "value": "Between customer and bank, a cashless payment instruction is irrevocable once the amount is debited from the customer's account, unless a payment system's rules provide otherwise.", "citation": "Code of Obligations (SR 220), art. 470 para. 2bis, consolidated status 1 January 2026, unofficial English translation on fedlex", "rests_on": "law" }, { "label": "After settlement", "value": "The sending bank may send an IP return request (camt.056). The receiving bank can agree by sending an IP return (pacs.004, reason FOCR), which settles as a new instant transaction, or refuse with a rejection (camt.029). A receiving bank may also return a payment without being asked.", "citation": "SIX Interbank Clearing, Implementation Guidelines SIC IP Service, IP Return Request (camt.056) v2.3 and IP Return Request Rejection (camt.029) v2.3 (both valid from 21 November 2025), section 3.1; IP Returns (pacs.004) v2.3 (valid from 21 November 2025), change history entry 2.2 and reason code element", "rests_on": "rule" } ], "exceptions": [ "A payment submitted just before the clearing day changes can settle after the change and then carries the next clearing day; the execution confirmation shows the day that applied (IP Status Report (pacs.002) v2.3, section 3.1.5 case c).", "A positive answer from the receiving bank does not guarantee settlement: the service can still cancel the payment for failed settlement (reason ED05), which the guideline's change history describes as a cancellation despite a positive feedback. By then the receiving bank has told the service the funds are available to its customer. [Unverified: how that case is unwound and who bears it is not public.] (SIX Interbank Clearing, Implementation Guidelines SIC IP Service, IP Status Report (pacs.002) v2.3, section 3.1.6 and change history entry for version 2.3)", "The time-out after which the service cancels a payment, and the time a receiving bank has to answer, are not in any public source read; the SNB gives only the ten-second aim. [Unverified: the values are in the participant-only SIC Handbook.]", "Insolvency of a participant: federal law protects orders already unalterable under a payment system's rules from later insolvency measures. [Inference: whether this reaches SIC, which is exempt from FINMA authorisation, is not confirmed by any source read.] (Financial Market Infrastructure Act (SR 958.1), arts. 4 para. 3 and 89, consolidated status 1 February 2024, unofficial English translation)", "A customer who paid by mistake has a civil claim in unjust enrichment against the recipient, outside the rail (Code of Obligations, arts. 62, 63 and 67)." ], "applies_to": "Swiss franc instant customer payments settled in the SIC IP service between SIC participants, to an IBAN in Switzerland or Liechtenstein, under Swiss law", "caveat": "Unlike the RTGS service, there is no wait file and so no window in which the sender can cancel: an instant payment either settles within seconds or is cancelled by the system. The detailed time limits live in the participant-only SIC Handbook and SIC IP Service Handbook, which were not read.", "related": [ "ch-sic:finality", "ch-sic-ip:settlement", "ch-sic-ip:hours", "ch-sic-ip:limits", "ch-sic-ip:return", "ch-sic-ip:recall", "ch-sic-ip:refund", "ch-sic-ip:liability", "ch-sic-ip:consumer-law", "ch-sic-ip:decision-points" ], "basis": { "sources": "SNB, The Swiss Interbank Clearing (SIC) payment system: Report on the SIC System and Disclosure Report 2025 (May 2026), chapters 2 and 6, footnotes 3 and 15, Disclosure Report principles 7 and 8, read in full. SIX Interbank Clearing Implementation Guidelines SIC IP Service, release 5.2 (in force from 21 November 2025): IP Status Report (pacs.002) v2.3 sections 3.1.3 to 3.1.6; IP Returns (pacs.004) v2.3 change history and reason element; IP Return Request (camt.056) v2.3 and IP Return Request Rejection (camt.029) v2.3 section 3.1. National Bank Ordinance art. 25a, Financial Market Infrastructure Act arts. 4 and 89 and Code of Obligations arts. 62, 63, 67 and 470, in unofficial English consolidations on fedlex.", "confidence": "high" }, "currency": { "effective_since": "2025-11-21", "effective_note": "2025-11-21 is when release 5.2 of the SIC IP guidelines took effect; [Inference: the reserve, feedback and settle cycle has applied since the service started, which the SNB report places in November 2023.] Release 5.3 on 2026-11-13 brings IP Status Report v2.4, which restricts cancellation messages to customer payments and does not change this cycle.", "source_edition": "SNB Report on the SIC System and Disclosure Report 2025 (May 2026); SIX SIC IP Implementation Guidelines release 5.2 (pacs.002 v2.3; pacs.004 v2.3; camt.056 v2.3; camt.029 v2.3); National Bank Ordinance status 2024-07-01; Financial Market Infrastructure Act status 2024-02-01; Code of Obligations status 2026-01-01", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.snb.ch/public/asset/en/www-snb-ch/publications/sicsystem-disclosure/sicsystem-disclosure-all/sicsystem_disclosure_2025/publications0_en/sic_disclosure_2025.en.pdf", "source_class": "public_primary", "source_title": "SNB Report on the SIC System and Disclosure Report 2025, chapters 2 and 6", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the reserve-feedback-settle cycle, the in-principle ten-second settlement aim, finality at the debit to the sender's IP settlement account, and cancellation on a negative answer or time-out." }, { "source_url": "https://www.six-group.com/dam/download/banking-services/standardization/sic-eurosic/4-12-5-2/ig-module-docs-sic-ip-2025-5.2-en.zip", "source_class": "authoritative_primary", "source_title": "SIX Interbank Clearing, Implementation Guidelines SIC IP Service, IP Status Report (pacs.002) v2.3, in the SIC IP module documents archive, release 5.2", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms sections 3.1.3 to 3.1.6 (positive feedback means funds made available to the payee; execution confirmation EXC002/ACSC), and the ED05 change-history entry correcting the definition to 'cancellation despite a positive IP feedback', matching the record's exceptions on that point without claiming who bears the resulting loss." }, { "source_url": "https://www.fedlex.admin.ch/eli/cc/27/317_321_377/en", "source_class": "secondary", "source_title": "Swiss Code of Obligations (SR 220), unofficial English translation, fedlex consolidated text", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms art. 470 para. 2bis on irrevocability at debit unless system rules provide otherwise. Unofficial translation, treated as secondary." } ] }, "rail_name": "SIC Instant Payments (SIC IP)", "governing_authority": "SIX Interbank Clearing on behalf of the Swiss National Bank", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "ch-sic-ip:hours", "id": "hours", "rail": "ch-sic-ip", "kind": "rail-fact", "facet": "hours", "name": "When is the SIC IP service open?", "statement": "The SIC IP service is open around the clock, every day of the year, and is built so that maintenance does not stop it. It has no clearing stops, but it does have clearing days, which change together with the RTGS service's shortly after 18.15, so an instant payment carries a clearing day that is not always the calendar day.", "details": [ { "label": "Always on", "value": "Available round the clock, with an architecture that lets maintenance run during operating hours. SIX describes the customer offer as 24x7x365 from account to account, including nights, weekends and holidays.", "citation": "SNB, The Swiss Interbank Clearing (SIC) payment system: Report on the SIC System and Disclosure Report 2025 (published May 2026), chapter 6 'Operating hours', IP service, and chart 8; SIX web page 'SIC System, Swiss Franc Payments', section on instant payments, read 2026-09-18", "rests_on": "guidance" }, { "label": "Speed", "value": "In principle within ten seconds end to end, according to both the SNB and SIX. A payment that exceeds the service's time limit is cancelled.", "citation": "SNB Report and Disclosure Report 2025, chapter 6 'Settlement algorithm', IP service; SIX web page 'SIC System, Swiss Franc Payments', read 2026-09-18", "rests_on": "guidance" }, { "label": "Start time stamp", "value": "The sending bank must stamp each instant payment with an acceptance time, which starts the clock for the maximum end-to-end execution time for everyone in the chain; the service tolerates 100 milliseconds of difference from its own reference time at submission.", "citation": "SIX Interbank Clearing, Implementation Guidelines SIC IP Service, IP Customer Payments (pacs.008) v2.2 (valid from 21 November 2025), element Acceptance Date Time", "rests_on": "rule" }, { "label": "Clearing day", "value": "The IP clearing day changes right after the RTGS service's day-end processing, shortly after 18.15, so both services always share one clearing day. The payment message's settlement date is ignored on input; the clearing day that counts is the one in the service's execution confirmation. That day can differ from what the sender expected, most often for a payment sent just before the day change and settled just after it, or for one dated on a weekend.", "citation": "SNB Report and Disclosure Report 2025, chapter 6 'Clearing days' and 'Clearing day process', IP service; SIX Interbank Clearing, Implementation Guidelines SIC IP Service, IP Status Report (pacs.002) v2.3 (valid from 21 November 2025), section 3.1.5; IP Customer Payments (pacs.008) v2.2, element Interbank Settlement Date", "rests_on": "rule" }, { "label": "Time stamps", "value": "Times the service generates are Swiss local time with the UTC offset; participants may send UTC or local-with-offset, with milliseconds.", "citation": "SIX Interbank Clearing, Implementation Guidelines Base Document v2.5 (valid from 21 November 2025), section 4.3.2", "rests_on": "rule" } ], "exceptions": [ "Funding is not always on: an IP settlement account can be topped up from the RTGS service only while RTGS is open, so the IP service's availability does not guarantee a given bank can send (SNB Report and Disclosure Report 2025, chapter 6 'Clearing day process').", "Being open does not mean every bank offers instant payments to its customers around the clock; a customer can use the service only if its bank offers it (SNB Report and Disclosure Report 2025, chapter 2 'Services in SIC system').", "The exact time-out values are in the participant-only SIC Handbook and were not read. [Unverified]", "On the release day, 13 November 2026, both business versions 5.2 and 5.3 are valid in the IP service at the same time, and SIX scheduled test days to simulate this (SIX Interbank Clearing, SIC Platform Release Notes 2026 v1.3, dated 21 September 2026, section 1.4.2)." ], "applies_to": "the operating times and clearing day of the SIC IP service for Swiss franc instant payments; times are Swiss local time", "caveat": "'Always on' describes the interbank service. Customer access depends on each bank's channels, and banks were only obliged to be able to receive instant payments from November 2026.", "related": [ "ch-sic-ip:finality", "ch-sic-ip:settlement", "ch-sic:hours", "ch-sic-ip:messages" ], "basis": { "sources": "SNB, Report on the SIC System and Disclosure Report 2025 (May 2026), chapters 2 and 6 with chart 8. SIX web page 'SIC System, Swiss Franc Payments' (six-group.com), read 2026-09-18. SIX Interbank Clearing Implementation Guidelines release 5.2 (in force from 21 November 2025): Base Document v2.5 section 4.3.2; SIC IP Customer Payments (pacs.008) v2.2, Acceptance Date Time and Interbank Settlement Date elements; IP Status Report (pacs.002) v2.3 section 3.1.5. SIC Platform Release Notes 2026 v1.3 section 1.4.2.", "confidence": "high" }, "currency": { "effective_since": "2025-11-21", "effective_note": "2025-11-21 is when release 5.2 of the guidelines took effect; round-the-clock operation dates from the service's start, which the SNB report places in November 2023. Release 5.3 on 2026-11-13 brings IP Customer Payments v2.3 and IP Status Report v2.4 with no change to hours.", "source_edition": "SNB Report on the SIC System and Disclosure Report 2025 (May 2026); SIX SIC IP Implementation Guidelines release 5.2 (pacs.008 v2.2; pacs.002 v2.3; Base Document v2.5); SIC Platform Release Notes 2026 v1.3", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.snb.ch/public/asset/en/www-snb-ch/publications/sicsystem-disclosure/sicsystem-disclosure-all/sicsystem_disclosure_2025/publications0_en/sic_disclosure_2025.en.pdf", "source_class": "public_primary", "source_title": "SNB Report on the SIC System and Disclosure Report 2025, chapters 2 and 6", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms 24/7/365 operation, the ten-second settlement aim, and that the IP clearing day changes together with the RTGS service shortly after 18.15." }, { "source_url": "https://www.six-group.com/dam/download/banking-services/standardization/sic-eurosic/4-12-5-2/ig-module-docs-sic-ip-2025-5.2-en.zip", "source_class": "authoritative_primary", "source_title": "SIX Interbank Clearing, Implementation Guidelines SIC IP Service, IP Customer Payments (pacs.008) v2.2 and IP Status Report (pacs.002) v2.3, in the SIC IP module documents archive, release 5.2", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the Acceptance Date Time element starting the execution-time clock and the clearing day assignment rule in pacs.002 section 3.1.5." } ] }, "rail_name": "SIC Instant Payments (SIC IP)", "governing_authority": "SIX Interbank Clearing on behalf of the Swiss National Bank", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "ch-sic-ip:liability", "id": "liability", "rail": "ch-sic-ip", "kind": "rail-fact", "facet": "liability", "name": "Who bears the loss when something goes wrong with a SIC instant payment?", "statement": "The public texts do not allocate loss in the SIC IP service. The contracts and the SIC Handbook that do are participant-only. What the public guidelines show is where risk sits: the receiving bank gives its customer the money before settlement, and the service can still cancel a payment for failed settlement after that bank has said yes; who bears that gap is not public.", "details": [ { "label": "Where the allocation lives", "value": "Participation in both SIC services rests on agreements with the SNB and with SIC Ltd, the SIC Handbook and the SNB's Terms of Business, under Swiss law with jurisdiction in Zurich; the Handbook is available only to participants.", "citation": "SNB, The Swiss Interbank Clearing (SIC) payment system: Report on the SIC System and Disclosure Report 2025 (published May 2026), chapter 5 and Disclosure Report principles 1 and 23; SNB Instruction sheet on admission to the SIC system and sight deposit accounts (17 November 2023, updated 27 February 2025), section 2.1", "rests_on": "guidance" }, { "label": "The receiving bank pays out first", "value": "A positive answer from the receiving bank (POS002) states that it has accepted the payment and made the funds available to the payee, and settlement follows on that answer.", "citation": "SIX Interbank Clearing, Implementation Guidelines SIC IP Service, IP Status Report (pacs.002) v2.3 (valid from 21 November 2025), section 3.1.3", "rests_on": "rule" }, { "label": "Cancellation after a yes", "value": "The service's cancellation message can carry a failed-settlement reason (ED05), which the guideline's own change history defines as a cancellation despite a positive answer from the receiving bank; a hard time-out (TM01) also cancels. [Unverified: who bears the loss when a receiving bank has already credited its customer is not stated in any public source read.]", "citation": "IP Status Report (pacs.002) v2.3, section 3.1.6, change history entry for version 2.3 and element Status Reason Information / Reason / Code for CNC002", "rests_on": "rule" }, { "label": "No credit risk between banks at settlement", "value": "Each payment settles gross, only with cover and in central bank money, so settled instant payments leave no credit exposure between participants; the service cancels instead of settling without cover.", "citation": "SNB Report and Disclosure Report 2025, Disclosure Report principles 4 and 7", "rests_on": "guidance" }, { "label": "Duty to tell the payer", "value": "The sending bank must tell the payer when an instant payment succeeds, and when it fails it must tell the customer at once and, in line with legal requirements, why.", "citation": "SNB Report and Disclosure Report 2025, chapter 6 'Settlement algorithm', IP service, and footnotes 15 and 16", "rests_on": "guidance" }, { "label": "The bank and its customer", "value": "A party that fails to perform owes damages unless it shows no fault, an agent owes careful and faithful performance, and advance exclusion of liability for intent or gross negligence is void. [Inference: that these articles govern a bank's instant payment service to its customer; no case law or commentary read.]", "citation": "Code of Obligations (SR 220), arts. 97 para. 1, 100 para. 1 and 398 paras. 1 and 2, consolidated status 1 January 2026, unofficial English translation on fedlex", "rests_on": "law" } ], "exceptions": [ "SIC Ltd disclaims liability for how participants read its published XML schemas and for unpublished BICs, the same as for the RTGS service (SIX Interbank Clearing, Implementation Guidelines Base Document v2.5, valid from 21 November 2025, sections 2.1 and 4.5).", "A participant can block all incoming or all outgoing instant customer payments by setting its per-payment defence limit to zero, or stop debits to its IP settlement account (acmt.015), which shifts outcome, and any resulting loss, to its own choices (SIX Interbank Clearing, Implementation Guidelines SIC IP Service, IP Limit Management (camt.011) v2.1, section 3.3.1; Individual IP Debit Stop (acmt.015) v1.1, chapter 2).", "Liechtenstein customers deal with their banks under Liechtenstein law, which was not read. [Unverified]" ], "applies_to": "allocation of loss among SIC IP participants, the SNB and SIC Ltd, and between a participant bank and its customer, for Swiss franc instant payments", "caveat": "Low confidence on purpose. The gap between a receiving bank's positive answer and a cancellation for failed settlement is visible in the public guidelines, but the rule on who carries it is not public. Do not read the order of the messages as a liability rule.", "related": [ "ch-sic-ip:finality", "ch-sic-ip:settlement", "ch-sic:liability", "ch-sic-ip:decision-points", "ch-sic-ip:consumer-law", "ch-sic-ip:limits" ], "basis": { "sources": "SIX Interbank Clearing Implementation Guidelines release 5.2 (in force from 21 November 2025): SIC IP Service IP Status Report (pacs.002) v2.3 sections 3.1.3 and 3.1.6, change history and reason element; IP Limit Management (camt.011) v2.1 section 3.3.1; Individual IP Debit Stop (acmt.015) v1.1 chapter 2; Base Document v2.5 sections 2.1 and 4.5. SNB, Report on the SIC System and Disclosure Report 2025 (May 2026), chapters 5 and 6, footnotes 15 and 16, Disclosure Report principles 1, 4, 7 and 23. SNB instruction sheet on admission, section 2.1. Code of Obligations arts. 97, 100 and 398, unofficial English consolidation of 1 January 2026. Participant contracts, SNB Terms of Business and the SIC Handbook not read.", "confidence": "low" }, "currency": { "effective_since": "2025-11-21", "effective_note": "2025-11-21 is when the release 5.2 guidelines cited took effect; the ED05 definition was corrected to 'despite a positive IP feedback' in IP Status Report v2.3 for that release. Release 5.3 on 2026-11-13 brings IP Status Report v2.4, which limits cancellation messages to customer payments.", "source_edition": "SIX SIC IP Implementation Guidelines release 5.2 (pacs.002 v2.3; camt.011 v2.1; acmt.015 v1.1; Base Document v2.5); SNB Report on the SIC System and Disclosure Report 2025 (May 2026); SNB instruction sheet on admission (2023-11-17, updated 2025-02-27); Code of Obligations status 2026-01-01", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.snb.ch/public/asset/en/www-snb-ch/publications/sicsystem-disclosure/sicsystem-disclosure-all/sicsystem_disclosure_2025/publications0_en/sic_disclosure_2025.en.pdf", "source_class": "public_primary", "source_title": "SNB Report on the SIC System and Disclosure Report 2025, chapters 5 and 6", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the contractual basis of participation, no credit risk between participants at settlement, and the duty to inform the payer of success or failure." }, { "source_url": "https://www.six-group.com/dam/download/banking-services/standardization/sic-eurosic/4-12-5-2/ig-module-docs-sic-ip-2025-5.2-en.zip", "source_class": "authoritative_primary", "source_title": "SIX Interbank Clearing, Implementation Guidelines SIC IP Service, IP Status Report (pacs.002) v2.3, in the SIC IP module documents archive, release 5.2", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the positive answer (POS002) states funds have been made available to the payee, and the ED05 change history describes cancellation despite a positive answer, without stating who bears the resulting loss; the record correctly marks that gap as unverified rather than asserting an allocation." }, { "source_url": "https://www.fedlex.admin.ch/eli/cc/27/317_321_377/en", "source_class": "secondary", "source_title": "Swiss Code of Obligations (SR 220), unofficial English translation, fedlex consolidated text", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms arts. 97, 100 and 398 on breach damages, void advance exclusion for intent or gross negligence, and the mandatee's duty of care. Unofficial translation, treated as secondary." } ] }, "rail_name": "SIC Instant Payments (SIC IP)", "governing_authority": "SIX Interbank Clearing on behalf of the Swiss National Bank", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "ch-sic-ip:limits", "id": "limits", "rail": "ch-sic-ip", "kind": "rail-fact", "facet": "limits", "name": "What amount limits apply to a SIC instant payment?", "statement": "According to the SNB, each instant payment in the SIC IP service is capped at CHF 20,000, which participants can raise between themselves by bilateral agreement. That figure rests only on the SNB's disclosure report: the public interbank guidelines do not state it, and the governing text is not public. On top of it each participant can set its own per-payment ceiling for sending and for receiving, and every payment needs cover on the IP settlement account.", "details": [ { "label": "The CHF 20,000 limit", "value": "Currently CHF 20,000 per instant payment, with higher limits possible by bilateral agreement between SIC participants. The SNB's disclosure report is the only public source read that states this; the same figure appears in the edition published in September 2025 and in the one published in May 2026.", "citation": "SNB, The Swiss Interbank Clearing (SIC) payment system: Report on the SIC System and Disclosure Report 2025 (published May 2026), Disclosure Report principle 7; same principle in the 2024 edition (published September 2025)", "rests_on": "guidance" }, { "label": "Not in the public guidelines", "value": "The instant customer payment guideline sets only a field ceiling of CHF 99,999,999,999.99 (13 digits, 2 decimals, greater than zero), the same as in RTGS, and does not mention CHF 20,000. [Inference: the limit and the bilateral increase are set in the participant-only SIC Handbook or participant agreements, which were not read.]", "citation": "SIX Interbank Clearing, Implementation Guidelines SIC IP Service, IP Customer Payments (pacs.008) v2.2 (valid from 21 November 2025), element Interbank Settlement Amount", "rests_on": "rule" }, { "label": "Each participant's own ceiling", "value": "A participant can set a per-payment 'defence limit' for outgoing and, separately, for incoming instant customer payments. Setting it to zero blocks all such payments in that direction; setting the maximum value removes it. A new setting overwrites the old one.", "citation": "SIX Interbank Clearing, Implementation Guidelines SIC IP Service, IP Limit Management (camt.011) v2.1 (valid from 21 November 2025), sections 3.2, 3.3 and 3.3.1", "rests_on": "rule" }, { "label": "Cover", "value": "An instant payment settles only if the sender's IP settlement account covers it; otherwise it is cancelled. The account can be replenished from RTGS only while RTGS is open.", "citation": "SNB Report and Disclosure Report 2025, chapter 6 'Settlement algorithm' and 'Clearing day process', IP service, and Disclosure Report principle 7", "rests_on": "guidance" }, { "label": "Currency and account", "value": "Swiss francs only, and only to an account identified by a valid IBAN (a QR-IBAN is not allowed as the debtor account).", "citation": "SIX Interbank Clearing, Implementation Guidelines SIC IP Service, IP Customer Payments (pacs.008) v2.2, section on use of account information and amount currency attribute; SIX, Swiss Payment Standards Business Rules v3.3 (valid from 14 November 2026), section 2.1.3", "rests_on": "rule" } ], "exceptions": [ "Bilateral agreements can lift the CHF 20,000 limit between two participants; which pairs have done so, and to what amount, is not public (SNB Report and Disclosure Report 2025, Disclosure Report principle 7).", "A bank may set lower limits for its customers as part of its own offering, and, where it offers this, may push an order that failed as instant through the ordinary route instead (SIX, Swiss Payment Standards Business Rules v3.3, sections 1.4.2 and 2.1.3).", "The SNB system manager has its own emergency limit message for the IP service, whose effect is described only in a guideline for the system manager (SIX Interbank Clearing, Implementation Guidelines Base Document v2.5, valid from 21 November 2025, section 2.5.4). [Unverified: what an emergency limit does was not read.]", "Whether the CHF 20,000 limit also applies to IP returns is not stated in any public source read. [Unverified]" ], "applies_to": "the amount of a single Swiss franc instant customer payment in the SIC IP service", "caveat": "Treat CHF 20,000 as a dated figure from the SNB's own description, not as a rule text: the SNB report calls it the current limit, the interbank guidelines are silent, and the governing document is not public. It can change without any public guideline changing.", "related": [ "ch-sic-ip:settlement", "ch-sic:limits", "ch-sic-ip:decision-points", "ch-sic-ip:participants" ], "basis": { "sources": "SNB, Report on the SIC System and Disclosure Report 2025 (May 2026), chapter 6 and Disclosure Report principle 7; the 2024 edition (September 2025), Disclosure Report principle 7. SIX Interbank Clearing Implementation Guidelines release 5.2 (in force from 21 November 2025): SIC IP Customer Payments (pacs.008) v2.2 amount and account elements; IP Limit Management (camt.011) v2.1 sections 3.2 and 3.3; Base Document v2.5 section 2.5.4. SIX Swiss Payment Standards Business Rules v3.3, sections 1.4.2 and 2.1.3.", "confidence": "medium" }, "currency": { "effective_since": "2025-11-21", "effective_note": "2025-11-21 is when the release 5.2 guidelines cited took effect. The CHF 20,000 limit has no public start date: it is stated as current in the SNB disclosure report editions published in September 2025 and May 2026. Release 5.3 on 2026-11-13 brings IP Customer Payments v2.3 with the same amount element; the SNB report is the watch input for any change to the limit.", "source_edition": "SNB Report on the SIC System and Disclosure Report 2025 (May 2026) and 2024 (September 2025); SIX SIC IP Implementation Guidelines release 5.2 (pacs.008 v2.2; camt.011 v2.1; Base Document v2.5); SPS Business Rules v3.3", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.snb.ch/public/asset/en/www-snb-ch/publications/sicsystem-disclosure/sicsystem-disclosure-all/sicsystem_disclosure_2025/publications0_en/sic_disclosure_2025.en.pdf", "source_class": "public_primary", "source_title": "SNB Report on the SIC System and Disclosure Report 2025, Disclosure Report principle 7", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the CHF 20,000 per instant payment limit with bilateral increase, stated in the paragraph immediately before Principle 8; the record's claim that this figure rests only on the SNB report is correct, since the interbank guidelines do not state it." }, { "source_url": "https://www.snb.ch/public/asset/en/www-snb-ch/publications/sicsystem-disclosure/sicsystem-disclosure-all/sicsystem_disclosure_2024/publications0_en/sicsystem_disclosure_2024.en.pdf", "source_class": "public_primary", "source_title": "SNB Report on the SIC System and Disclosure Report 2024 (published September 2025), Disclosure Report principle 7", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the same CHF 20,000 limit appears in the prior edition, supporting the record's claim that the figure is stated identically across both editions." }, { "source_url": "https://www.six-group.com/dam/download/banking-services/standardization/sic-eurosic/4-12-5-2/ig-module-docs-sic-ip-2025-5.2-en.zip", "source_class": "authoritative_primary", "source_title": "SIX Interbank Clearing, Implementation Guidelines SIC IP Service, IP Customer Payments (pacs.008) v2.2 and IP Limit Management (camt.011) v2.1, in the SIC IP module documents archive, release 5.2", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the pacs.008 field ceiling of CHF 99,999,999,999.99 with no CHF 20,000 figure stated, and the camt.011 per-payment defence limit mechanism for incoming and outgoing instant payments." } ] }, "rail_name": "SIC Instant Payments (SIC IP)", "governing_authority": "SIX Interbank Clearing on behalf of the Swiss National Bank", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "ch-sic-ip:messages", "id": "messages", "rail": "ch-sic-ip", "kind": "rail-fact", "facet": "messages", "name": "Which messages does the SIC IP service use, and on which standard?", "statement": "SIC IP uses the same ISO 20022 message versions and Swiss schemas as the RTGS service, under separate, binding guidelines for the IP service. An instant payment is a pacs.008; the receiving bank answers with a pacs.002 carrying a positive or negative feedback, and the service answers with a pacs.002 that either confirms execution or reports cancellation. Returns, return requests and their rejections, status requests, limits and debit stops each have their own message.", "details": [ { "label": "Binding guidelines and versions", "value": "The interbank guidelines bind every participant, and the IP service checks incoming messages against published Swiss schemas. The IP service uses pacs.008.001.08, pacs.002.001.10, pacs.004.001.09, camt.056.001.08 and camt.029.001.09 among others, the same versions as RTGS.", "citation": "SIX Interbank Clearing, Implementation Guidelines for ISO 20022 Interbank Messages, Base Document v2.5 (28 February 2025, valid from 21 November 2025), sections 2.1, 2.5.2 and 2.6 table 8", "rests_on": "rule" }, { "label": "One status message, six uses", "value": "The IP pacs.002 comes in six types, marked by a code in the clearing system reference: the service's execution confirmation and cancellation notice, the receiving bank's positive or negative feedback on a payment, and plain acknowledgements (OK or not OK) in either direction. The receiving bank must answer a pacs.008 with feedback, never with a plain OK acknowledgement.", "citation": "SIX Interbank Clearing, Implementation Guidelines SIC IP Service, IP Status Report (pacs.002) v2.3 (valid from 21 November 2025), sections 3.1 to 3.1.6", "rests_on": "rule" }, { "label": "Reason codes by message", "value": "A negative feedback must carry one of a closed list of ISO reason codes that the service checks; a cancellation either copies that reason or gives a service code for time-out or failed settlement; a not-OK acknowledgement carries a three-digit SIC error code from the participant-only Handbook. Return requests and their rejections also use closed, checked lists; IP returns may use any ISO return reason.", "citation": "IP Status Report (pacs.002) v2.3, sections 3.1.2, 3.1.4, 3.1.6 and 3.4; SIC IP Service IP Return Request (camt.056) v2.3, IP Return Request Rejection (camt.029) v2.3 and IP Returns (pacs.004) v2.3 (all valid from 21 November 2025), reason code elements", "rests_on": "rule" }, { "label": "Payment content", "value": "The instant customer payment has payment type IPCPMT, clearing system SIP, CHF only, a valid IBAN for the creditor, a mandatory start time stamp, and no priority or settlement time fields. Participants are identified only by their six-digit SIC IID with clearing system code CHSIC.", "citation": "SIX Interbank Clearing, Implementation Guidelines SIC IP Service, IP Customer Payments (pacs.008) v2.2 (valid from 21 November 2025), sections 3.2 and on account information, and settlement elements; IP Status Report (pacs.002) v2.3, section 3.5", "rests_on": "rule" }, { "label": "Service management messages", "value": "Participants manage per-payment defence limits and balance alerts with camt.011, stop debits to their IP account with acmt.015, query balances and messages with camt.003 and camt.005, and receive clearing day information and recapitulations with camt.019 and camt.052. Liquidity moves between RTGS and IP with a cross-service pacs.009.", "citation": "SIX Interbank Clearing, Base Document v2.5, sections 2.5.2 and 2.5.3", "rests_on": "rule" }, { "label": "Access", "value": "Participants connect through the SIX messaging gateway over the Secure Swiss Finance Network, and since November 2025 also over Swift.", "citation": "SNB, The Swiss Interbank Clearing (SIC) payment system: Report on the SIC System and Disclosure Report 2025 (published May 2026), chapter 6 'Communication and messaging standards' and footnote 17", "rests_on": "guidance" } ], "exceptions": [ "From 2026-11-13 (release 5.3) the service no longer sends cancellation information for transfer payments out of the IP service, so its service code for that case (ED06) falls away (SIX Interbank Clearing, Implementation Guidelines SIC IP Service, IP Status Report (pacs.002) v2.4, 27 February 2026, change history).", "Release 5.3 deactivates deprecated IP service addresses under change request CR2026-SIC-0004 (SIX Interbank Clearing, SIC Platform Release Notes 2026 v1.3, dated 21 September 2026, section 4.2.2).", "All SIC IP messages are to move to the ISO 20022 2024/2025 message versions in November 2027 under CR2026-SIC-0002 (Release Notes 2026 v1.3, section 1.2).", "The IP message flow diagrams are in the SIC IP Service Handbook, which is participant-only and was not read (Base Document v2.5, section 3.1)." ], "applies_to": "ISO 20022 interbank messages exchanged between participants and the SIC IP service for Swiss franc instant payments", "caveat": "The individual IP codes belong in reason-code records of their own, not in this fact, which only says which message carries which kind of code. SIX reserves copyright in the guidelines; nothing here reproduces their tables.", "related": [ "ch-sic-ip:finality", "ch-sic-ip:return", "ch-sic-ip:recall", "ch-sic:messages" ], "basis": { "sources": "SIX Interbank Clearing Implementation Guidelines release 5.2 (in force from 21 November 2025): Base Document v2.5 sections 2.1, 2.5.2, 2.5.3, 2.6 and 3.1; SIC IP Service IP Status Report (pacs.002) v2.3 sections 3.1 to 3.5; IP Customer Payments (pacs.008) v2.2; IP Returns (pacs.004) v2.3; IP Return Request (camt.056) v2.3; IP Return Request Rejection (camt.029) v2.3. Release 5.3: IP Status Report v2.4 change history; SIC Platform Release Notes 2026 v1.3 sections 1.2 and 4.2.2. SNB, Report on the SIC System and Disclosure Report 2025 (May 2026), chapter 6.", "confidence": "high" }, "currency": { "effective_since": "2025-11-21", "effective_note": "2025-11-21 is when release 5.2 of the SIC IP guidelines took effect. Release 5.3 applies from 2026-11-13 with the same ISO versions and new guideline editions for pacs.002 (v2.4), pacs.004 (v2.4) and pacs.008 (v2.3). The move to 2024/2025 ISO versions is announced for November 2027 without a day.", "source_edition": "SIX SIC IP Implementation Guidelines release 5.2 (Base Document v2.5; pacs.002 v2.3; pacs.008 v2.2; pacs.004 v2.3; camt.056 v2.3; camt.029 v2.3); pacs.002 v2.4 (release 5.3); SIC Platform Release Notes 2026 v1.3; SNB Report on the SIC System and Disclosure Report 2025 (May 2026)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.six-group.com/dam/download/banking-services/standardization/sic-eurosic/4-12-5-2/ig-base-document-ch-interbank-2025-en.pdf", "source_class": "authoritative_primary", "source_title": "SIX Interbank Clearing, Implementation Guidelines for ISO 20022 Interbank Messages, Base Document v2.5", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the IP service uses the same ISO 20022 message versions as RTGS (section 2.6 table 8), binding guidelines status (section 2.1), and the module document list for IP participants (section 2.5.2)." }, { "source_url": "https://www.six-group.com/dam/download/banking-services/standardization/sic-eurosic/4-12-5-2/ig-module-docs-sic-ip-2025-5.2-en.zip", "source_class": "authoritative_primary", "source_title": "SIX Interbank Clearing, Implementation Guidelines SIC IP Service, IP Status Report (pacs.002) v2.3, in the SIC IP module documents archive, release 5.2", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the pacs.002 message carries positive/negative feedback (NEG002), execution confirmation (EXC002) and cancellation (CNC002), that a receiving bank must answer a pacs.008 with feedback rather than a plain acknowledgement, and the six-digit SIC IID with clearing system code CHSIC used to identify participants." } ] }, "rail_name": "SIC Instant Payments (SIC IP)", "governing_authority": "SIX Interbank Clearing on behalf of the Swiss National Bank", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "ch-sic-ip:participants", "id": "participants", "rail": "ch-sic-ip", "kind": "rail-fact", "facet": "participants", "name": "Who takes part in the SIC IP service, and who must?", "statement": "SIC IP is open to SIC participants, which the SNB admits directly; there is no separate admission to the instant service. Participants that settle retail payments in the RTGS service, which the SNB takes to include all banks and licensed fintech companies, must be able to receive instant payments by November 2026. The obligation is to receive, not to send, and it lapses for a participant that deselects retail payments in RTGS.", "details": [ { "label": "Same admission as SIC", "value": "SIC comprises two services under one admission regime. A participant with a sight deposit account normally gets one settlement account per service, so an instant payments participant has an IP settlement account beside its RTGS one; any participant, not only banks, may use the IP service.", "citation": "SNB Instruction sheet on admission to the SIC system and sight deposit accounts (17 November 2023, updated 27 February 2025), sections 1 and 2.1; SNB, The Swiss Interbank Clearing (SIC) payment system: Report on the SIC System and Disclosure Report 2025 (published May 2026), chapter 3", "rests_on": "rule" }, { "label": "The duty to receive", "value": "Any participant using the RTGS service for retail payments has to be reachable for incoming instant payments no later than November 2026. The SNB treats banks and licensed fintech companies as active in retail payments.", "citation": "SNB Instruction sheet on admission, section 2.1 and footnote 2; SNB Report and Disclosure Report 2025, chapter 3 and footnote 5", "rests_on": "rule" }, { "label": "How to be outside it", "value": "A participant that settles only interbank payments can deselect retail payments in the RTGS service, and the duty then no longer applies to it.", "citation": "SNB Report and Disclosure Report 2025, chapter 3", "rests_on": "guidance" }, { "label": "No third-party system operators", "value": "Admission without a sight deposit account, for third-party system operators, is to the RTGS service only; such operators do not take part in SIC IP.", "citation": "SNB Instruction sheet on admission, section 2.2", "rests_on": "rule" }, { "label": "Reach so far", "value": "More than 70 banks could receive instant payments at the end of 2025, which the SNB describes as almost complete coverage of Swiss retail payments. In 2025 the IP service averaged about 14,000 payments a day out of about 4.1 million in SIC.", "citation": "SNB Report and Disclosure Report 2025, Disclosure Report chapter 1 'Instant payments'; chapter 2 table 2", "rests_on": "guidance" }, { "label": "Only direct participants submit", "value": "Payment providers outside SIC may in future reach the IP service through a proposed Instant Payments Bridge, but payments would still be submitted only by direct participants. The SNB said a decision on building it was due by mid-2026.", "citation": "SNB Report and Disclosure Report 2025, Disclosure Report chapter 1 'Instant payments bridge'", "rests_on": "guidance" } ], "exceptions": [ "The deadline is worded differently in two SNB texts: the instruction sheet and the report's main part say November 2026 at the latest, while the report's disclosure part says by the end of 2026 (SNB Instruction sheet on admission, footnote 2; SNB Report and Disclosure Report 2025, footnote 5 and Disclosure Report chapter 1). [Unverified: which date the SNB will enforce.]", "No text read obliges any participant to send instant payments or to offer them to customers; a bank customer can choose instant payment only if the bank offers it (SNB Report and Disclosure Report 2025, chapter 2 'Services in SIC system'). [Inference from the wording of the obligation]", "Whether the Instant Payments Bridge was approved in 2026 is not established. [Unverified]", "The SNB and the ECB are studying a link between SIC IP and the Eurosystem's TIPS for cross-currency instant payments; no decision is reported (SNB Report and Disclosure Report 2025, Disclosure Report chapter 1)." ], "applies_to": "participation in the SIC IP service by SIC participants admitted by the SNB, including the duty of retail participants to be able to receive instant payments", "caveat": "The duty sits in an SNB admission instrument, not in a statute, and it binds SIC participants, not customers. Do not read it as 'Swiss banks must offer instant payments'.", "related": [ "ch-sic:participants", "ch-sic-ip:consumer-law", "ch-sic-ip:settlement", "ch-sic-ip:decision-points" ], "basis": { "sources": "SNB Instruction sheet on admission to the SIC system and sight deposit accounts (17 November 2023, updated 27 February 2025), sections 1, 2.1 and 2.2 with footnote 2, read in full. SNB, Report on the SIC System and Disclosure Report 2025 (May 2026), chapters 2 and 3 with table 2 and footnote 5, and Disclosure Report chapter 1.", "confidence": "medium" }, "currency": { "effective_since": "2025-02-27", "effective_note": "2025-02-27 is the date of the last update to the SNB admission instruction sheet, which carries the November 2026 duty to receive. The counts are as at the end of 2025. The duty takes effect by November 2026 at the latest, after this record's snapshot date of 2026-09-18.", "source_edition": "SNB instruction sheet on admission (2023-11-17, updated 2025-02-27); SNB Report on the SIC System and Disclosure Report 2025 (May 2026)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.snb.ch/dam/jcr:76cdd7c1-828e-47eb-8d5f-d580fdc1881e/sicgiro_access_2023.en.pdf", "source_class": "authoritative_primary", "source_title": "SNB Instruction sheet on admission to the SIC system and sight deposit accounts (17 November 2023, updated 27 February 2025)", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms section 2.1 and footnote 2: participants settling retail payments in RTGS must be able to receive instant payments, worded 'by November 2026 at the latest'; confirms the deselection escape and that third-party system operators (section 2.2) are RTGS-only." }, { "source_url": "https://www.snb.ch/public/asset/en/www-snb-ch/publications/sicsystem-disclosure/sicsystem-disclosure-all/sicsystem_disclosure_2025/publications0_en/sic_disclosure_2025.en.pdf", "source_class": "public_primary", "source_title": "SNB Report on the SIC System and Disclosure Report 2025, chapters 1, 2, 3 and footnote 5", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms footnote 5 in chapter 3 also says 'November 2026 at the latest', while chapter 1 of the Disclosure Report ('most important developments in 2025') states retail participants must be able to receive instant payments 'by the end of 2026', a genuine wording conflict within the same document; also confirms more than 70 banks able to receive instant payments at end 2025 and the 14,000-of-4.1-million daily average from table 2. The record's exceptions correctly state the conflict rather than picking one wording." } ] }, "rail_name": "SIC Instant Payments (SIC IP)", "governing_authority": "SIX Interbank Clearing on behalf of the Swiss National Bank", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "ch-sic-ip:recall", "id": "recall", "rail": "ch-sic-ip", "kind": "rail-fact", "facet": "recall", "name": "Can the sending bank stop or recall a SIC instant payment?", "statement": "Not before settlement: the SIC IP service has no cancel message for a sender, because a payment settles or is cancelled by the system within seconds. After settlement the sending bank can send an IP return request, using a short list of reasons that the service checks. The receiving bank then either sends the money back as an IP return or rejects the request with one of a fixed set of reasons.", "details": [ { "label": "No sender cancellation", "value": "The IP message set has no cancellation or modification message like the RTGS service's camt.008 and camt.007. What a sender can do while a payment is in flight is ask for its status (pacs.028). [Inference from the message sets: the IP guideline list carries no cancel message.]", "citation": "SIX Interbank Clearing, Implementation Guidelines Base Document v2.5 (valid from 21 November 2025), sections 2.5.2 and 2.6 table 8; SIC IP Service, IP Status Request (pacs.028) v2.3 (valid from 21 November 2025), chapter 2", "rests_on": "rule" }, { "label": "The return request", "value": "An IP return request (camt.056) lets the debtor's bank ask for an already executed instant payment back. The service checks the message's form, confirms receipt, and delivers it at once to the creditor's bank, which also confirms receipt; the service does not check that the payment referred to was ever processed.", "citation": "SIX Interbank Clearing, Implementation Guidelines SIC IP Service, IP Return Request (camt.056) v2.3 (valid from 21 November 2025), section 3.1", "rests_on": "rule" }, { "label": "Reasons on the request", "value": "Six reason codes are allowed and the service rejects others. The guideline expects one group of three for a request between banks (fraud, a duplicate, or a technical problem) and another three for a request driven by the originating customer, but it does not police which group is used.", "citation": "IP Return Request (camt.056) v2.3, element Cancellation Reason Information / Code", "rests_on": "rule" }, { "label": "The creditor's bank answers", "value": "Agreement takes the form of an IP return (pacs.004) with reason FOCR carrying the request's identification. Refusal takes the form of an IP return request rejection (camt.029, status RJCR) with one of seven reasons the service checks, among them that the customer declined, the account is closed, or the money went back already.", "citation": "SIX Interbank Clearing, Implementation Guidelines SIC IP Service, IP Return Request Rejection (camt.029) v2.3 (valid from 21 November 2025), section 3.1 and element Cancellation Status Reason / Code; IP Returns (pacs.004) v2.3 (valid from 21 November 2025), reason code element", "rests_on": "rule" }, { "label": "Following up", "value": "The debtor's bank can ask the service to pass a status request on an earlier return request to the creditor's bank (pacs.028).", "citation": "IP Status Request (pacs.028) v2.3, chapter 2", "rests_on": "rule" }, { "label": "Deadlines and obligation", "value": "The IP guidelines do not state that the creditor's bank must answer, unlike the RTGS return request guideline, and no public source read sets a time for answering or a latest date for asking. [Unverified: both may be in the participant-only SIC Handbook.]", "citation": "Comparison of IP Return Request (camt.056) v2.3 section 3.1 with SIX Interbank Clearing, Implementation Guidelines SIC RTGS, Return Request (camt.056) v2.4 (valid from 21 November 2025), section 3.1", "rests_on": "rule" } ], "exceptions": [ "The receiving bank's negative feedback before settlement (NEG002) is not a recall; it is the receiver declining, and the payment is cancelled before it settles (SIX Interbank Clearing, Implementation Guidelines SIC IP Service, IP Status Report (pacs.002) v2.3, section 3.1.4).", "A customer who wants a settled instant payment back has no claim against SIC. Between customer and bank the instruction is irrevocable once the account is debited, unless system rules say otherwise, and a claim against the recipient runs in unjust enrichment (Code of Obligations (SR 220), arts. 470 para. 2bis and 62, consolidated status 1 January 2026, unofficial English translation).", "The RTGS service uses the same messages for return requests but does not check the reason codes, and there a sender can cancel a waiting payment until 17.00 (SIX Interbank Clearing, Implementation Guidelines SIC RTGS, Return Request (camt.056) v2.4, reason code element; SNB, Report on the SIC System and Disclosure Report 2025, published May 2026, chapter 6)." ], "applies_to": "stopping and recalling Swiss franc instant customer payments between participants in the SIC IP service", "caveat": "Once an instant payment is out, a recall depends entirely on the receiving bank. The IP code lists are closed and checked by the service, which makes the answer machine-readable, but they give the sender no right to the money.", "related": [ "ch-sic-ip:finality", "ch-sic-ip:return", "ch-sic:recall", "ch-sic-ip:refund", "ch-sic-ip:decision-points", "ch-sic-ip:messages" ], "basis": { "sources": "SIX Interbank Clearing Implementation Guidelines release 5.2 (in force from 21 November 2025): Base Document v2.5 sections 2.5.2 and 2.6; SIC IP Service IP Return Request (camt.056) v2.3 section 3.1 and reason element; IP Return Request Rejection (camt.029) v2.3 section 3.1 and reason element; IP Returns (pacs.004) v2.3 reason element; IP Status Request (pacs.028) v2.3 chapter 2; IP Status Report (pacs.002) v2.3 section 3.1.4. SIC RTGS Return Request (camt.056) v2.4 section 3.1 for comparison. SNB, Report on the SIC System and Disclosure Report 2025 (May 2026), chapter 6. Code of Obligations arts. 62 and 470, unofficial English consolidation of 1 January 2026.", "confidence": "medium" }, "currency": { "effective_since": "2025-11-21", "effective_note": "2025-11-21 is when the release 5.2 guidelines cited took effect. The IP return request and rejection guidelines (camt.056 v2.3, camt.029 v2.3) carry over unchanged into release 5.3 on 2026-11-13.", "source_edition": "SIX Implementation Guidelines release 5.2 (Base Document v2.5; SIC IP camt.056 v2.3, camt.029 v2.3, pacs.004 v2.3, pacs.028 v2.3, pacs.002 v2.3); SIC RTGS camt.056 v2.4; SNB Report on the SIC System and Disclosure Report 2025 (May 2026); Code of Obligations status 2026-01-01", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.six-group.com/dam/download/banking-services/standardization/sic-eurosic/4-12-5-2/ig-module-docs-sic-ip-2025-5.2-en.zip", "source_class": "authoritative_primary", "source_title": "SIX Interbank Clearing, Implementation Guidelines SIC IP Service, IP Return Request (camt.056) v2.3 and IP Return Request Rejection (camt.029) v2.3, in the SIC IP module documents archive, release 5.2", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the IP message set has no sender cancellation message; the six checked camt.056 reason codes DUPL, TECH, FRAD, CUST, AC03, AM09, split by interbank versus originator request; and the seven checked camt.029 rejection reasons ARDT, AC04, AM04, CUST, LEGL, NOAS, NOOR, matching the record's counts exactly." }, { "source_url": "https://www.fedlex.admin.ch/eli/cc/27/317_321_377/en", "source_class": "secondary", "source_title": "Swiss Code of Obligations (SR 220), unofficial English translation, fedlex consolidated text", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms art. 470 para. 2bis and art. 62 on irrevocability and unjust enrichment. Unofficial translation, treated as secondary." } ] }, "rail_name": "SIC Instant Payments (SIC IP)", "governing_authority": "SIX Interbank Clearing on behalf of the Swiss National Bank", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "ch-sic-ip:refund", "id": "refund", "rail": "ch-sic-ip", "kind": "rail-fact", "facet": "refund", "name": "Does the SIC IP service give a payer any right to a refund?", "statement": "No. SIC IP carries only instant credit transfers pushed by the payer's bank, and its public rules offer no refund process: money comes back only if the receiving bank chooses to send an IP return, with or without a request. A payer's remedies lie outside the rail, with its own bank or against the recipient under general law.", "details": [ { "label": "Only credit transfers", "value": "The only customer payment type in the IP service is the instant customer payment (IPCPMT); there are no direct debits and so no debit-side refund right in the service.", "citation": "SIX Interbank Clearing, Implementation Guidelines SIC IP Service, IP Customer Payments (pacs.008) v2.2 (valid from 21 November 2025), sections 3.1 and 3.2; SNB, The Swiss Interbank Clearing (SIC) payment system: Report on the SIC System and Disclosure Report 2025 (published May 2026), chapter 2 'Unified settlement'", "rests_on": "rule" }, { "label": "What exists instead", "value": "An IP return request (camt.056) that the receiving bank may reject (camt.029), and an IP return (pacs.004) that the receiving bank decides to send. None of these gives the payer or its bank a right to the money.", "citation": "SIX Interbank Clearing, Implementation Guidelines SIC IP Service, IP Return Request (camt.056) v2.3 and IP Return Request Rejection (camt.029) v2.3 (valid from 21 November 2025), section 3.1; IP Returns (pacs.004) v2.3, chapter 2", "rests_on": "rule" }, { "label": "General law", "value": "Money paid without a valid reason can be claimed back from the recipient in unjust enrichment, within three years of learning of the claim and ten at most; this is a civil claim, not a payment process.", "citation": "Code of Obligations (SR 220), arts. 62, 63 and 67, consolidated status 1 January 2026, unofficial English translation on fedlex", "rests_on": "law" } ], "exceptions": [ "A bank may promise its own customers reimbursement, for example for unauthorised instant payments, in its account terms; such promises differ by bank. [Unverified: no Swiss statute read gives such a right.]", "A Liechtenstein customer may have statutory rights under Liechtenstein law, which was not read. [Unverified]", "Because the receiving bank answers within seconds before settlement, a payment to an invalid account is refused and never needs a refund [Inference: the SNB gives an invalid account number as an example of a refusal] (SIX Interbank Clearing, Implementation Guidelines SIC IP Service, IP Status Report (pacs.002) v2.3, section 3.1.4; SNB Report and Disclosure Report 2025, footnote 15)." ], "applies_to": "instant Swiss franc payments settled in the SIC IP service, from the payer's point of view", "caveat": "An absence in the public rules, not a rule saying so; the participant-only SIC Handbook was not read, and neither were Swiss bank account terms.", "related": [ "ch-sic-ip:return", "ch-sic-ip:recall", "ch-sic:refund", "ch-sic-ip:consumer-law", "ch-sic-ip:finality" ], "basis": { "sources": "SIX Interbank Clearing Implementation Guidelines SIC IP Service release 5.2 (in force from 21 November 2025): IP Customer Payments (pacs.008) v2.2 sections 3.1 and 3.2; IP Return Request (camt.056) v2.3 and IP Return Request Rejection (camt.029) v2.3 section 3.1; IP Returns (pacs.004) v2.3 chapter 2; IP Status Report (pacs.002) v2.3 section 3.1.4. SNB, Report on the SIC System and Disclosure Report 2025 (May 2026), chapter 2 and footnote 15. Code of Obligations arts. 62, 63 and 67, unofficial English consolidation of 1 January 2026.", "confidence": "low" }, "currency": { "effective_since": "2025-11-21", "effective_note": "2025-11-21 is when the release 5.2 guidelines cited took effect; release 5.3 on 2026-11-13 adds no refund process.", "source_edition": "SIX SIC IP Implementation Guidelines release 5.2 (pacs.008 v2.2; camt.056 v2.3; camt.029 v2.3; pacs.004 v2.3; pacs.002 v2.3); SNB Report on the SIC System and Disclosure Report 2025 (May 2026); Code of Obligations status 2026-01-01", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.six-group.com/dam/download/banking-services/standardization/sic-eurosic/4-12-5-2/ig-module-docs-sic-ip-2025-5.2-en.zip", "source_class": "authoritative_primary", "source_title": "SIX Interbank Clearing, Implementation Guidelines SIC IP Service, IP Customer Payments (pacs.008) v2.2, in the SIC IP module documents archive, release 5.2", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the only IP customer payment type is the instant customer payment (IPCPMT), a credit transfer with no direct debit type, so no debit-side refund right exists in the service." }, { "source_url": "https://www.fedlex.admin.ch/eli/cc/27/317_321_377/en", "source_class": "secondary", "source_title": "Swiss Code of Obligations (SR 220), unofficial English translation, fedlex consolidated text", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms arts. 62, 63 and 67 on unjust enrichment restitution. Unofficial translation, treated as secondary." } ] }, "rail_name": "SIC Instant Payments (SIC IP)", "governing_authority": "SIX Interbank Clearing on behalf of the Swiss National Bank", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "ch-sic-ip:return", "id": "return", "rail": "ch-sic-ip", "kind": "rail-fact", "facet": "return", "name": "Can a receiving bank send a settled SIC instant payment back, and how?", "statement": "Yes. The receiving bank sends an IP return (pacs.004), which the SIC IP service settles as a new transaction from its IP settlement account to the original sender's bank, with no accept-or-reject step on the other side. A return may answer a return request or be sent unasked, and it may carry any ISO return reason. No public source read sets a deadline.", "details": [ { "label": "The message", "value": "An IP return (pacs.004, return type IPCRTN) goes from the original creditor's bank through the service to the original debtor's bank, in order to send back an instant customer payment it received.", "citation": "SIX Interbank Clearing, Implementation Guidelines SIC IP Service, IP Returns (pacs.004) v2.3 (valid from 21 November 2025), chapter 2 and sections 3.1 and 3.2", "rests_on": "rule" }, { "label": "How it settles", "value": "The service confirms a settled IP return to the sender with an execution confirmation (EXC002). The original debtor's bank acknowledges the delivered return with a plain OK acknowledgement (OKA002); the positive or negative feedback used for instant customer payments does not apply to returns. [Inference: so a return cannot be refused by the bank receiving it.]", "citation": "SIX Interbank Clearing, Implementation Guidelines SIC IP Service, IP Status Report (pacs.002) v2.3 (valid from 21 November 2025), sections 3.1.1, 3.1.3 and 3.1.5", "rests_on": "rule" }, { "label": "With or without a request", "value": "Since the release 5.1 version of the guideline, an IP return can be sent without a prior IP return request, aligning SIC IP with the RTGS service. When it does answer a request, it carries reason FOCR and the request's identification.", "citation": "IP Returns (pacs.004) v2.3, change history entry for version 2.2 (28 February 2024, release 5.1), section 3.10 and element Return Reason Information / Additional Information", "rests_on": "rule" }, { "label": "Reasons it may carry", "value": "Any ISO external return reason code is accepted. FOCR and NARR must come with additional information; CUST must be used when the original creditor asked for the return, which the service does not check.", "citation": "IP Returns (pacs.004) v2.3, element Return Reason Information / Reason / Code", "rests_on": "rule" }, { "label": "Deadline", "value": "Not published: no public source read limits how long after the original payment an IP return may be sent. [Unverified: any limit would be in the participant-only SIC Handbook.]", "citation": "Absence across SIX Interbank Clearing SIC IP Implementation Guidelines release 5.2 (pacs.004 v2.3; camt.056 v2.3; camt.029 v2.3) and SNB, The Swiss Interbank Clearing (SIC) payment system: Report on the SIC System and Disclosure Report 2025 (published May 2026)", "rests_on": "guidance" } ], "exceptions": [ "A payment the receiving bank does not want is normally refused inside the seconds before settlement with a negative feedback (NEG002), so it never needs returning; the return is for money already settled (IP Status Report (pacs.002) v2.3, section 3.1.4).", "An IP return is a new settled payment and final like any other SIC payment; a mistaken return is undone only by another payment (SNB Report and Disclosure Report 2025, chapter 2 'Settlement finality').", "Whether the CHF 20,000 per payment limit the SNB reports also caps IP returns is not stated in public sources. [Unverified]", "From 2026-11-13 IP Returns v2.4 applies; its reason code rules are the same (IP Returns (pacs.004) v2.4, 27 February 2026, reason code element)." ], "applies_to": "returns of settled Swiss franc instant customer payments between participants in the SIC IP service", "caveat": "A return moves money back but carries no rights of its own; whether the original payer gets the money depends on its bank, and on the receiving bank having chosen to return it.", "related": [ "ch-sic-ip:finality", "ch-sic-ip:settlement", "ch-sic:return", "ch-sic-ip:recall", "ch-sic-ip:refund", "ch-sic-ip:messages" ], "basis": { "sources": "SIX Interbank Clearing Implementation Guidelines SIC IP Service release 5.2 (in force from 21 November 2025): IP Returns (pacs.004) v2.3, change history, chapter 2, sections 3.1, 3.2 and 3.10 and reason elements; IP Status Report (pacs.002) v2.3 sections 3.1.1 to 3.1.5. Release 5.3 IP Returns (pacs.004) v2.4 compared. SNB, Report on the SIC System and Disclosure Report 2025 (May 2026), chapter 2.", "confidence": "medium" }, "currency": { "effective_since": "2025-11-21", "effective_note": "2025-11-21 is when IP Returns v2.3 took effect. Returns without a prior request and the open reason list came with guideline version 2.2 for release 5.1, published 2024-02-28; the go-live date of release 5.1 was not read. IP Returns v2.4 applies from 2026-11-13 with unchanged reason rules.", "source_edition": "SIX SIC IP Implementation Guidelines release 5.2 (pacs.004 v2.3; pacs.002 v2.3); release 5.3 pacs.004 v2.4; SNB Report on the SIC System and Disclosure Report 2025 (May 2026)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.six-group.com/dam/download/banking-services/standardization/sic-eurosic/4-12-5-2/ig-module-docs-sic-ip-2025-5.2-en.zip", "source_class": "authoritative_primary", "source_title": "SIX Interbank Clearing, Implementation Guidelines SIC IP Service, IP Returns (pacs.004) v2.3, in the SIC IP module documents archive, release 5.2", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms an IP return can be sent without a prior return request since guideline version 2.2 (release 5.1), that FOCR must carry the request's identification, and that CUST must be used when the original creditor asked for the return, unchecked by the service." }, { "source_url": "https://www.snb.ch/public/asset/en/www-snb-ch/publications/sicsystem-disclosure/sicsystem-disclosure-all/sicsystem_disclosure_2025/publications0_en/sic_disclosure_2025.en.pdf", "source_class": "public_primary", "source_title": "SNB Report on the SIC System and Disclosure Report 2025, chapter 2", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms settlement finality applies equally to an IP return as to any other SIC payment." } ] }, "rail_name": "SIC Instant Payments (SIC IP)", "governing_authority": "SIX Interbank Clearing on behalf of the Swiss National Bank", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "ch-sic-ip:settlement", "id": "settlement", "rail": "ch-sic-ip", "kind": "rail-fact", "facet": "settlement", "name": "How and in what money does the SIC IP service settle instant payments, and how is it funded?", "statement": "The SIC IP service settles each instant payment individually in central bank money, on a separate IP settlement account each participant holds alongside its RTGS account. Participants fund that account by transferring liquidity from RTGS while RTGS is open; balances stay on it overnight and at weekends, and a payment the account cannot cover is cancelled, not queued.", "details": [ { "label": "Money and accounts", "value": "Settlement is in sight deposits at the SNB, as in the RTGS service. Each participant using the service has an IP settlement account, and the balances on it count as part of the participant's sight deposits.", "citation": "SNB, The Swiss Interbank Clearing (SIC) payment system: Report on the SIC System and Disclosure Report 2025 (published May 2026), chapter 2 'Settlement in central bank money', chapter 3 and chapter 6 'Clearing day process', IP service; Disclosure Report principle 9", "rests_on": "guidance" }, { "label": "Funding the account", "value": "Liquidity moves into the IP account from the RTGS settlement account, and back, by transfer payments the participant sends; that is possible only during RTGS operating hours. Participants who use both services use the cross-service transfer message (pacs.009) for this.", "citation": "SNB Report and Disclosure Report 2025, chapter 6 'Clearing day process', IP service; SIX Interbank Clearing, Implementation Guidelines Base Document v2.5 (valid from 21 November 2025), section 2.5.3 (whose table labels the guideline pacs.002); cross-service guideline IP Transfer Payments (pacs.009) v2.3 (valid from 13 November 2026), chapter 2", "rests_on": "guidance" }, { "label": "Reserve, then settle", "value": "On a new payment the service reserves the amount on the sender's IP account and settles only after the receiving bank's positive answer. It settles in submission order, but only if cover is there; otherwise it cancels the payment.", "citation": "SNB Report and Disclosure Report 2025, chapter 6 'Settlement algorithm', IP service, and Disclosure Report principle 7", "rests_on": "guidance" }, { "label": "Across the clearing day change", "value": "The IP service has no clearing stops. It changes clearing day right after the RTGS day-end processing, so both services share the same clearing day, and IP balances stay in place through the change so settlement never pauses.", "citation": "SNB Report and Disclosure Report 2025, chapter 6 'Clearing day process', IP service", "rests_on": "guidance" }, { "label": "Watching the balance", "value": "A participant can set an upper and a lower threshold on its available IP balance; crossing either triggers a balance notification (camt.004). It can also set a per-payment ceiling for outgoing and for incoming instant payments.", "citation": "SIX Interbank Clearing, Implementation Guidelines SIC IP Service, IP Limit Management (camt.011) v2.1 (valid from 21 November 2025), sections 3.2, 3.3.1 and 3.3.2", "rests_on": "rule" } ], "exceptions": [ "Outside RTGS hours a participant cannot top up its IP account from RTGS, so its capacity to send overnight or at a weekend is whatever it left there, plus incoming instant payments (SNB Report and Disclosure Report 2025, chapter 6 'Clearing day process'). [Inference: the SNB names the lack of an always-available liquidity facility as the reason for its planned Payment System Support Facility, due from the end of 2027.]", "The IP service runs permanently in both data centres, unlike the RTGS service, whose second instance is a cold standby (SNB Report and Disclosure Report 2025, Disclosure Report principle 17).", "The SNB's system manager can distribute liquidity in the IP service with its own message (pacs.009 IP liquidity distribution) and set emergency limits (camt.011), under guidelines for the system manager only (SIX Interbank Clearing, Base Document v2.5, section 2.5.4)." ], "applies_to": "settlement of Swiss franc instant customer payments and IP returns in the SIC IP service between participants holding IP settlement accounts", "caveat": "The SNB report describes these rules and the SIC IP Service Handbook holds the operating detail; the Handbook is participant-only and was not read. The per-payment limit set with camt.011 is the participant's own control and is separate from the CHF 20,000 limit the SNB reports.", "related": [ "ch-sic-ip:finality", "ch-sic:settlement", "ch-sic-ip:hours", "ch-sic-ip:limits", "ch-sic-ip:liability" ], "basis": { "sources": "SNB, Report on the SIC System and Disclosure Report 2025 (May 2026), chapters 2, 3 and 6 and Disclosure Report principles 7, 9 and 17. SIX Interbank Clearing Implementation Guidelines, release 5.2 (in force from 21 November 2025): Base Document v2.5 sections 2.5.3 and 2.5.4; SIC IP Limit Management (camt.011) v2.1 sections 3.2 and 3.3.", "confidence": "high" }, "currency": { "effective_since": "2025-11-21", "effective_note": "2025-11-21 is when the release 5.2 guidelines cited took effect; camt.011 v2.1 carries over unchanged into release 5.3 on 2026-11-13. The Payment System Support Facility is announced by the SNB from the end of 2027.", "source_edition": "SNB Report on the SIC System and Disclosure Report 2025 (May 2026); SIX Implementation Guidelines release 5.2 (Base Document v2.5; SIC IP camt.011 v2.1)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.snb.ch/public/asset/en/www-snb-ch/publications/sicsystem-disclosure/sicsystem-disclosure-all/sicsystem_disclosure_2025/publications0_en/sic_disclosure_2025.en.pdf", "source_class": "public_primary", "source_title": "SNB Report on the SIC System and Disclosure Report 2025, chapters 2, 3 and 6", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms settlement in central bank money on a separate IP settlement account, funding by transfer from RTGS only while RTGS is open, reserve-then-settle mechanics, and the clearing day change shared with RTGS shortly after 18.15." }, { "source_url": "https://www.six-group.com/dam/download/banking-services/standardization/sic-eurosic/4-12-5-2/ig-module-docs-sic-ip-2025-5.2-en.zip", "source_class": "authoritative_primary", "source_title": "SIX Interbank Clearing, Implementation Guidelines SIC IP Service, IP Limit Management (camt.011) v2.1, in the SIC IP module documents archive, release 5.2", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the upper/lower balance threshold notification (camt.004 via camt.011) and the per-payment defence limit mechanism for incoming and outgoing instant payments, sections 3.2 and 3.3." } ] }, "rail_name": "SIC Instant Payments (SIC IP)", "governing_authority": "SIX Interbank Clearing on behalf of the Swiss National Bank", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "eps:consumer-law", "id": "consumer-law", "rail": "eps", "kind": "rail-fact", "facet": "consumer-law", "name": "What consumer law applies to an eps payment?", "statement": "eps adds no consumer rights of its own. The buyer logs in and authorises the payment at their own bank, with payee, amount and reference filled in and locked, so an eps payment is a transfer the buyer ordered from their own account. A claim over an unauthorised or wrongly executed transfer therefore runs between the buyer and their bank under payment services law, and a claim over the goods runs against the merchant [Inference; PSD2 and the Austrian ZaDiG 2018 were not read].", "details": [ { "label": "The buyer authorises in their own bank, with the payment locked", "value": "The buyer always authenticates directly with their own bank, in online banking or a banking app, with the bank's usual methods. The payee, amount, currency and payment reference arrive filled in and cannot be changed by the buyer, and eps messages pass none of the buyer's banking data to the merchant or any third party, apart from the optional IBAN, BIC and name a confirmation carries for refunds.", "citation": "eps e-payment standard, Standard Implementation Guideline, version 2.7, sections 1.1, 6.2.1.1.2, 6.2.1.1.3, 6.2.2.9 to 6.2.2.11, 8; eps-Überweisung, Privatkunden page and FAQ, Häufig gestellte Fragen", "rests_on": "rule" }, { "label": "Consumer rights sit outside eps", "value": "The eps documents give the buyer no rights of their own. Because the buyer orders the transfer from their own account in their own bank, a claim over an unauthorised or wrongly executed transfer runs against that bank under payment services law, and a claim over the goods runs against the merchant [Inference; PSD2 and the Austrian ZaDiG 2018 were not read].", "citation": "eps e-payment standard, Standard Implementation Guideline, version 2.7, sections 1.1, 7.1.7; eps-Überweisung, Privatkunden page and FAQ, Häufig gestellte Fragen", "rests_on": "law" } ], "exceptions": [ "The merchant's refund is voluntary, not a consumer right.", "PSA says no banking data of the buyer passes to the merchant or a third party through eps, apart from optional refund data in the confirmation." ], "applies_to": "eps payments (eps-Überweisung) routed through PSA's Scheme Operator under eps protocol versions 2.4 to 2.7, and eps refunds from protocol 2.6", "caveat": "The law lines stay inference until the statutes are read; the linked SEPA consumer-law facts set out the EU framework.", "related": [ "sepa-sct:consumer-law", "sepa-sct-inst:consumer-law", "eps:refund" ], "basis": { "sources": "PSA, eps Standard Implementation Guideline version 2.7, sections 1.1, 6.2.1.1.3, 6.2.2.9 to 6.2.2.11, 7.1.7 and 8, and the PSA Privatkunden page, read 2026-09-19. No statute was read.", "confidence": "low" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Drafted on 2026-09-19 from PSA's eps documents as published that day. The SEPA layer is dated in the linked sepa-sct and sepa-sct-inst facts.", "source_edition": "eps Standard Implementation Guideline version 2.7 (file listed 2026-03-25), eps Refundierung version 1.0.1 and Technisches Beiblatt version 1.8 as the Rules cite them, read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://eps-ueberweisung.at/de/download/eps-ueberweisung-dokumentation/send/2-eps-ueberweisung-dokumentation/31-eps-standard-implementation-guideline-v2-7", "source_class": "authoritative_primary", "source_title": "eps e-payment standard, Standard Implementation Guideline, version 2.7", "checked_on": "2026-09-19", "checked_by": "validator-2026-09-19", "notes": "Confirms the buyer authenticates and orders the transfer directly at their own bank, with eps itself stating no consumer right of its own." }, { "source_url": "https://eps-ueberweisung.at/de/privatkunden", "source_class": "public_primary", "source_title": "eps-Überweisung, Privatkunden page and FAQ", "checked_on": "2026-09-19", "checked_by": "validator-2026-09-19", "notes": "Confirms PSA's consumer FAQ directs a buyer with a question to their own bank rather than to PSA." } ] }, "rail_name": "Austria eps-Überweisung", "governing_authority": "PSA Payment Services Austria GmbH", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "eps:decision-points", "id": "decision-points", "rail": "eps", "kind": "rail-fact", "facet": "decision-points", "name": "Who decides at each step of an eps payment?", "statement": "Four parties decide. The Scheme Operator decides whether an initiation passes its checks and may stop a payment for a possible fraud check. The debtor bank decides whether to execute and answers OK or NOK. The merchant decides whether a confirmation validates, and must acknowledge it or answer with an error. For refunds, the merchant's bank decides whether the merchant may refund at all and whether each refund order is carried out. The buyer's only decision is to authorise or cancel.", "details": [ { "label": "The Scheme Operator validates each initiation", "value": "Before anything reaches a bank the Scheme Operator checks the initiation: that the merchant is authorised, that the credited IBAN is the one registered for the merchant, that the merchant may use a future date if it set one, that the expiration time is no more than 60 minutes out, and that the message is valid XML with the right content type. A failed check is answered with an error code and ends the transaction.", "citation": "eps e-payment standard, Standard Implementation Guideline, version 2.7, sections 7.1.2, 7.2.3", "rests_on": "rule" }, { "label": "The Scheme Operator may abort for a possible fraud check", "value": "At any point before the payment completes, the routing service may abort a transaction for a possible fraud check, which the confirmation reports with status reason 115. The guideline gives no criteria [Unverified].", "citation": "eps e-payment standard, Standard Implementation Guideline, version 2.7, section 6.2.2.8 (ReasonCode 115)", "rests_on": "rule" }, { "label": "The debtor bank decides whether to execute", "value": "The debtor bank decides whether to carry out the transfer and answers with OK or NOK. It must send NOK, without a vitality check first, when the buyer cancels before or after logging in or an error occurs in online banking, and it must inform the buyer.", "citation": "eps e-payment standard, Standard Implementation Guideline, version 2.7, sections 6.2.2.7, 7.1.7, 7.1.11", "rests_on": "rule" }, { "label": "The merchant must acknowledge the confirmation", "value": "On receiving the payment confirmation the merchant must answer the Scheme Operator at once: with a ShopResponseDetails that returns the session ID, status code and payment reference it received, or, if it cannot validate the confirmation (bad XML, bad signature), with an error text. The guideline advises marking the order paid on the confirmation itself, not on the buyer's return to the shop.", "citation": "eps e-payment standard, Standard Implementation Guideline, version 2.7, sections 6.4 (epsp:ConfirmationUrl, epsp:TransactionOkUrl), 6.8, 7.1.13.1, 7.1.13.2", "rests_on": "rule" }, { "label": "Refunds must be agreed with and enabled by the merchant's bank", "value": "Refunding eps payments has to be agreed in the merchant's contract with its bank, which must enable the merchant for the service at the Scheme Operator and itself support refunds. The account debited for a refund must be an IBAN registered for the merchant at the SO; it need not be the account the original payment credited.", "citation": "eps Refundierung, version 1.0.1, sections 3.2, 7.1.3, 8.1", "rests_on": "rule" }, { "label": "A successful refund answer is not a guarantee of payment", "value": "Code 000 in the refund response confirms only that the merchant's bank accepted the payment order. It is no guarantee the money is paid: limit and block checks on the merchant's account can still reject the order.", "citation": "eps Refundierung, version 1.0.1, sections 7.2, 7.2.1, 8.3", "rests_on": "rule" } ], "exceptions": [ "An error written by the Scheme Operator carries the prefix SO: in its message, which tells the merchant whether the SO or the bank refused.", "The Scheme Operator's fraud criteria are not published [Unverified]." ], "applies_to": "eps payments (eps-Überweisung) routed through PSA's Scheme Operator under eps protocol versions 2.4 to 2.7, and eps refunds from protocol 2.6", "caveat": "Where the eps documents leave a choice to a bank or the SO without criteria, this fact can only name who decides, not how.", "related": [ "sepa-sct:decision-points", "eps:participants" ], "basis": { "sources": "PSA, eps Standard Implementation Guideline version 2.7, sections 4.10, 6.2.2.7, 6.2.2.8, 7.1.2, 7.1.7, 7.1.11 and 7.1.13; eps Refundierung version 1.0.1, sections 3.2, 7.2 and 8.3; read 2026-09-19.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Drafted on 2026-09-19 from PSA's eps documents as published that day. The SEPA layer is dated in the linked sepa-sct and sepa-sct-inst facts.", "source_edition": "eps Standard Implementation Guideline version 2.7 (file listed 2026-03-25), eps Refundierung version 1.0.1 and Technisches Beiblatt version 1.8 as the Rules cite them, read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://eps-ueberweisung.at/de/download/eps-ueberweisung-dokumentation/send/2-eps-ueberweisung-dokumentation/31-eps-standard-implementation-guideline-v2-7", "source_class": "authoritative_primary", "source_title": "eps e-payment standard, Standard Implementation Guideline, version 2.7", "checked_on": "2026-09-19", "checked_by": "validator-2026-09-19", "notes": "Confirms the debtor bank decides whether to execute and answer OK or NOK, the Scheme Operator validates initiations and may abort for a possible fraud check, and the merchant must validate or answer an error to the confirmation." }, { "source_url": "https://eps-ueberweisung.at/de/download/eps-ueberweisung-dokumentation/send/2-eps-ueberweisung-dokumentation/16-eps-refundierung-dokumentation", "source_class": "authoritative_primary", "source_title": "eps Refundierung, version 1.0.1", "checked_on": "2026-09-19", "checked_by": "validator-2026-09-19", "notes": "Confirms the merchant's bank decides whether to enable refunds for the merchant at the Scheme Operator." } ] }, "rail_name": "Austria eps-Überweisung", "governing_authority": "PSA Payment Services Austria GmbH", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "eps:finality", "id": "finality", "rail": "eps", "kind": "rail-fact", "facet": "finality", "name": "When is an eps payment final, and can it be reversed?", "statement": "eps makes nothing final; it reports. The debtor bank may send status OK only after the buyer has authorised the transfer, the merchant has answered the vitality check and the bank has executed the transfer, so an OK says the money has already left the buyer's account. Under a guaranteed merchant contract the bank also stands behind that OK. eps has no message to undo a payment once OK is sent. From there the payment is an ordinary SEPA credit transfer, and its finality, return and recall are the SCT scheme's, or SCT Inst's where the bank executes instantly.", "details": [ { "label": "Status OK only after authorisation, vitality check and execution", "value": "The debtor bank may send status OK only once three things have happened in order: the buyer has authorised the transfer in online banking, the merchant has answered the vitality check through the Scheme Operator, and the bank has executed the credit transfer. An OK therefore reports a transfer already carried out.", "citation": "eps e-payment standard, Standard Implementation Guideline, version 2.7, sections 7.1.7, 7.1.10, 7.1.11", "rests_on": "rule" }, { "label": "Debtor bank guarantee on status OK", "value": "Where the merchant's eps contract is a guaranteed one, the debtor bank takes on the guarantee for a credit transfer it confirms with status OK. The guarantee comes from the merchant contract alone: the field in which a merchant could ask for a guarantee payment by payment (atrul:Realization, code GAR) is reserved for future use and not supported.", "citation": "eps e-payment standard, Standard Implementation Guideline, version 2.7, section 1.2 (Guaranteed Payment); section 6.3.1; section 7.1.12", "rests_on": "rule" }, { "label": "VOK where the contract is not guaranteed or the date is in the future", "value": "The status table for a payment that will be executed gives OK under a guaranteed merchant contract with no future option date, and VOK where the contract is not guaranteed or a future option date is set; a payment the buyer stops or that is not executed gets NOK either way. The same guideline says the debtor bank itself sends only OK or NOK, so which party writes VOK is not stated [Unverified].", "citation": "eps e-payment standard, Standard Implementation Guideline, version 2.7, section 7.1.12 (overview of eps status codes); section 6.2.2.7", "rests_on": "rule" }, { "label": "No eps message undoes a payment after OK", "value": "Once the debtor bank has sent OK, eps offers no way back: none of the messages the guideline defines lets the merchant, the Scheme Operator or the bank withdraw or cancel a confirmed payment [Inference from the absence of any such message]. PSA's merchant page presents it the same way: orders the bank's system has checked and accepted are confirmed online at once and carried out irrevocably.", "citation": "eps e-payment standard, Standard Implementation Guideline, version 2.7, sections 5, 6.4 to 6.13, 7.1; eps-Überweisung, Händler page and FAQ, section on the real-time execution guarantee", "rests_on": "rule" }, { "label": "The money moves as a SEPA credit transfer", "value": "eps moves no money itself. The buyer's own bank executes a SEPA credit transfer from the buyer's account to the merchant's IBAN, which the buyer authorised in their online banking; the guideline maps each payment field onto the SCT interbank message pacs.008. Finality, returns, recalls and liability for the transfer are therefore the SCT scheme's [Inference: no eps document says so in terms]. Whether a bank runs it as an SCT Inst payment is not stated in any eps document read [Unverified].", "citation": "eps e-payment standard, Standard Implementation Guideline, version 2.7, sections 1.1, 3.1, 7.1.7, 7.1.10, 9.1 (mapping table eps to SCT pacs.008)", "rests_on": "rule" } ], "exceptions": [ "UNKNOWN is not a refusal: the Scheme Operator writes it when the bank's confirmation is late, and the transfer may already have been executed.", "VOK, given where the merchant contract is not guaranteed or a future date is set, reports a payment that will be executed but carries no bank guarantee [Inference from IG section 7.1.12].", "If the bank cannot deliver its confirmation in three attempts, the transfer stands even though the merchant was not told." ], "applies_to": "eps payments (eps-Überweisung) routed through PSA's Scheme Operator under eps protocol versions 2.4 to 2.7, and eps refunds from protocol 2.6", "caveat": "The guarantee is contractual: it depends on the merchant's eps contract, which is not public, so a processor summary that calls EPS guaranteed without that condition says more than the standard does. The guideline says the bank sends only OK or NOK, yet its status table gives VOK; who writes VOK is not stated [Unverified].", "related": [ "sepa-sct:finality", "sepa-sct-inst:finality", "eps:liability", "eps:recall", "eps:settlement" ], "basis": { "sources": "PSA, eps Standard Implementation Guideline version 2.7 (file listed 2026-03-25), sections 1.2, 5, 6.2.2.7, 6.3.1, 6.4 to 6.13 and 7.1, read 2026-09-19. The SCT layer rests on the linked SEPA facts and their own sources.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Drafted on 2026-09-19 from PSA's eps documents as published that day. The SEPA layer is dated in the linked sepa-sct and sepa-sct-inst facts.", "source_edition": "eps Standard Implementation Guideline version 2.7 (file listed 2026-03-25), eps Refundierung version 1.0.1 and Technisches Beiblatt version 1.8 as the Rules cite them, read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://eps-ueberweisung.at/de/download/eps-ueberweisung-dokumentation/send/2-eps-ueberweisung-dokumentation/31-eps-standard-implementation-guideline-v2-7", "source_class": "authoritative_primary", "source_title": "eps e-payment standard, Standard Implementation Guideline, version 2.7", "checked_on": "2026-09-19", "checked_by": "validator-2026-09-19", "notes": "Confirms OK follows authorisation, vitality check and execution in that order, that a guaranteed contract has the bank stand behind an OK, and that no eps message undoes a confirmed payment." } ] }, "rail_name": "Austria eps-Überweisung", "governing_authority": "PSA Payment Services Austria GmbH", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "eps:hours", "id": "hours", "rail": "eps", "kind": "rail-fact", "facet": "hours", "name": "When can an eps payment be made, and what clocks run on it?", "statement": "The eps documents set no operating hours; the clocks that matter run per payment. The merchant may give an initiation an expiration time from 5 to 60 minutes out, and 60 applies if it sets none; after that the debtor bank may not send OK and must send NOK. Every connection to the Scheme Operator gives up after 20 seconds to connect and 20 seconds without data. The SO rejects an initiation whose creation time is more than 3 minutes off its clock, and a refund request more than 3 hours off. From protocol 2.6 a merchant can ask for a payment's status for 42 days after processing.", "details": [ { "label": "Expiration time: 5 to 60 minutes", "value": "Within the expiration time: the merchant may set it between 5 and 60 minutes after the initiation, and without one the Scheme Operator applies 60 minutes. The debtor bank checks it when the buyer authorises; once it has passed the bank may not send OK and must tell the buyer and send NOK.", "citation": "eps e-payment standard, Standard Implementation Guideline, version 2.7, sections 6.3.5, 7.1.2; EPS/EMS/EID Technisches Beiblatt, version 1.8, section 6.1", "rests_on": "rule" }, { "label": "Connection and read timeouts of 20 seconds", "value": "Every connection to or from the Scheme Operator times out after 20 seconds to connect and after 20 seconds without data, for all of PSA's eServices. A debtor bank that does not answer an initiation in time draws error 008 for the merchant, and one that cannot be reached draws 014.", "citation": "EPS/EMS/EID Technisches Beiblatt, version 1.8, sections 5.2.1, 5.2.2; eps e-payment standard, Standard Implementation Guideline, version 2.7, sections 4.5, 7.1.3, 7.1.5", "rests_on": "rule" }, { "label": "Initiation refused beyond 3 minutes of clock difference", "value": "The Scheme Operator actively rejects an initiation whose creation time, as the merchant wrote it in the XML, differs by more than 3 minutes from the time the SO processes it; PSA strongly recommends automatic time synchronisation. Which error code the rejection carries is not stated [Unverified].", "citation": "EPS/EMS/EID Technisches Beiblatt, version 1.8, section 3.1", "rests_on": "rule" }, { "label": "Refund request refused beyond 3 hours of clock difference", "value": "The Scheme Operator checks the creation time in a refund request against its own server time and refuses the request with code 012 when they are more than 3 hours apart.", "citation": "eps Refundierung, version 1.0.1, sections 4.6 (code 012), 7.1.1", "rests_on": "rule" }, { "label": "Status can be asked for up to 42 days", "value": "From protocol version 2.6 a merchant can ask the Scheme Operator for the status of a payment, with a confirmation status request, up to 42 days after the payment was processed; it is meant for when the confirmation did not reach the merchant. Up to version 2.5 there is no such request and the confirmation is only pushed.", "citation": "EPS/EMS/EID Technisches Beiblatt, version 1.8, section 6.2.1; eps e-payment standard, Standard Implementation Guideline, version 2.7, sections 6.12, 6.13", "rests_on": "rule" } ], "exceptions": [ "The expiration time is checked when the buyer authorises, not when the initiation arrives (IG section 6.3.5).", "Up to protocol 2.5 there is no status request; the confirmation is only pushed to the merchant (Beiblatt section 6.2.1)." ], "applies_to": "eps payments (eps-Überweisung) routed through PSA's Scheme Operator under eps protocol versions 2.4 to 2.7, and eps refunds from protocol 2.6", "caveat": "Operating hours for the Scheme Operator and for each bank's online banking are not stated in the documents read [Unverified]; error 014 shows a bank can be out of reach during maintenance. The transfer itself runs on the SCT or SCT Inst clock.", "related": [ "sepa-sct:hours", "sepa-sct-inst:hours", "eps:refund" ], "basis": { "sources": "PSA, eps Standard Implementation Guideline version 2.7, sections 4.5, 6.3.5, 6.12 and 7.1; Technisches Beiblatt version 1.8, sections 3.1, 5.2, 6.1 and 6.2.1; eps Refundierung version 1.0.1, section 7.1.1; read 2026-09-19.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Drafted on 2026-09-19 from PSA's eps documents as published that day. The SEPA layer is dated in the linked sepa-sct and sepa-sct-inst facts.", "source_edition": "eps Standard Implementation Guideline version 2.7 (file listed 2026-03-25), eps Refundierung version 1.0.1 and Technisches Beiblatt version 1.8 as the Rules cite them, read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://eps-ueberweisung.at/de/download/eps-ueberweisung-dokumentation/send/2-eps-ueberweisung-dokumentation/31-eps-standard-implementation-guideline-v2-7", "source_class": "authoritative_primary", "source_title": "eps e-payment standard, Standard Implementation Guideline, version 2.7", "checked_on": "2026-09-19", "checked_by": "validator-2026-09-19", "notes": "Confirms the merchant may set an expiration time from 5 to 60 minutes, and that a status request works up to 42 days after processing from protocol version 2.6." }, { "source_url": "https://eps-ueberweisung.at/de/download/eps-ueberweisung-dokumentation/send/2-eps-ueberweisung-dokumentation/3-e-services-technisches-beiblatt", "source_class": "authoritative_primary", "source_title": "EPS/EMS/EID Technisches Beiblatt, version 1.8", "checked_on": "2026-09-19", "checked_by": "validator-2026-09-19", "notes": "Confirms the Scheme Operator's connection and read timeouts are 20 seconds each, the initiation clock skew tolerance is 3 minutes, and status requests reach up to 42 days back." }, { "source_url": "https://eps-ueberweisung.at/de/download/eps-ueberweisung-dokumentation/send/2-eps-ueberweisung-dokumentation/16-eps-refundierung-dokumentation", "source_class": "authoritative_primary", "source_title": "eps Refundierung, version 1.0.1", "checked_on": "2026-09-19", "checked_by": "validator-2026-09-19", "notes": "Confirms a refund request is refused when its creation time differs from the Scheme Operator's server time by more than 3 hours." } ] }, "rail_name": "Austria eps-Überweisung", "governing_authority": "PSA Payment Services Austria GmbH", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "eps:liability", "id": "liability", "rail": "eps", "kind": "rail-fact", "facet": "liability", "name": "Who bears the loss when an eps payment goes wrong?", "statement": "The public eps documents say little about loss. The one money rule is the guarantee: under a guaranteed merchant contract the debtor bank stands behind a payment it has confirmed with OK. If the bank cannot get its confirmation through in three attempts, the transfer stands, the buyer is told it was executed, and buyer and merchant settle the rest between them. A refund accepted by the merchant's bank can still be stopped by that bank. Everything else sits in contracts that are not public, in the SCT rulebook and in payment services law.", "details": [ { "label": "Debtor bank guarantee on status OK", "value": "Where the merchant's eps contract is a guaranteed one, the debtor bank takes on the guarantee for a credit transfer it confirms with status OK. The guarantee comes from the merchant contract alone: the field in which a merchant could ask for a guarantee payment by payment (atrul:Realization, code GAR) is reserved for future use and not supported.", "citation": "eps e-payment standard, Standard Implementation Guideline, version 2.7, section 1.2 (Guaranteed Payment); section 6.3.1; section 7.1.12", "rests_on": "rule" }, { "label": "VOK where the contract is not guaranteed or the date is in the future", "value": "The status table for a payment that will be executed gives OK under a guaranteed merchant contract with no future option date, and VOK where the contract is not guaranteed or a future option date is set; a payment the buyer stops or that is not executed gets NOK either way. The same guideline says the debtor bank itself sends only OK or NOK, so which party writes VOK is not stated [Unverified].", "citation": "eps e-payment standard, Standard Implementation Guideline, version 2.7, section 7.1.12 (overview of eps status codes); section 6.2.2.7", "rests_on": "rule" }, { "label": "Three attempts to deliver the confirmation", "value": "Within the timeout the debtor bank has up to three attempts to hand its payment confirmation to the Scheme Operator. After the third, the bank tells the buyer in online banking that the transfer was executed but the merchant could not be informed, and any further steps are for buyer and merchant to agree.", "citation": "eps e-payment standard, Standard Implementation Guideline, version 2.7, section 7.1.13", "rests_on": "rule" }, { "label": "A successful refund answer is not a guarantee of payment", "value": "Code 000 in the refund response confirms only that the merchant's bank accepted the payment order. It is no guarantee the money is paid: limit and block checks on the merchant's account can still reject the order.", "citation": "eps Refundierung, version 1.0.1, sections 7.2, 7.2.1, 8.3", "rests_on": "rule" }, { "label": "Merchants need an eps merchant contract", "value": "To offer eps a merchant must conclude an eps merchant contract with an eps bank, usually the bank holding its account, or with an eps acquirer; the bank or acquirer quotes the price. The contract decides whether payments are guaranteed. Its terms are not public.", "citation": "eps e-payment standard, Standard Implementation Guideline, version 2.7, preamble; sections 1.2, 3.4, 7.1.12; eps-Überweisung, Händler page and FAQ, Häufig gestellte Fragen", "rests_on": "rule" }, { "label": "Banks join under PSA's eServices legal framework", "value": "A bank that wants to offer eps must sign an eServices legal framework agreement with PSA as Scheme Operator and accept the eps product sheet in it; the SO then registers the bank for testing or production. The agreement is not public.", "citation": "eps e-payment standard, Standard Implementation Guideline, version 2.7, sections 1.2 (eService legal framework), 3.2, 3.3", "rests_on": "rule" } ], "exceptions": [ "No guarantee attaches to VOK or to a payment with a future option date (IG section 7.1.12).", "The per-payment guarantee request field is not in use (IG section 6.3.1)." ], "applies_to": "eps payments (eps-Überweisung) routed through PSA's Scheme Operator under eps protocol versions 2.4 to 2.7, and eps refunds from protocol 2.6", "caveat": "The eServices legal framework agreement and the merchant contracts were not read; they are not public.", "related": [ "sepa-sct:liability", "sepa-sct-inst:liability", "eps:finality" ], "basis": { "sources": "PSA, eps Standard Implementation Guideline version 2.7, sections 1.2, 3.2, 3.4, 6.3.1, 7.1.12 and 7.1.13; eps Refundierung version 1.0.1, section 7.2; read 2026-09-19.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Drafted on 2026-09-19 from PSA's eps documents as published that day. The SEPA layer is dated in the linked sepa-sct and sepa-sct-inst facts.", "source_edition": "eps Standard Implementation Guideline version 2.7 (file listed 2026-03-25), eps Refundierung version 1.0.1 and Technisches Beiblatt version 1.8 as the Rules cite them, read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://eps-ueberweisung.at/de/download/eps-ueberweisung-dokumentation/send/2-eps-ueberweisung-dokumentation/31-eps-standard-implementation-guideline-v2-7", "source_class": "authoritative_primary", "source_title": "eps e-payment standard, Standard Implementation Guideline, version 2.7", "checked_on": "2026-09-19", "checked_by": "validator-2026-09-19", "notes": "Confirms the debtor bank's guarantee on OK depends on a guaranteed merchant contract, and that if the bank cannot deliver its confirmation after three attempts the transfer stands and buyer and merchant must sort it out themselves." }, { "source_url": "https://eps-ueberweisung.at/de/download/eps-ueberweisung-dokumentation/send/2-eps-ueberweisung-dokumentation/16-eps-refundierung-dokumentation", "source_class": "authoritative_primary", "source_title": "eps Refundierung, version 1.0.1", "checked_on": "2026-09-19", "checked_by": "validator-2026-09-19", "notes": "Confirms a successful refund answer is not a guarantee of payment, since limit and block checks at the merchant's bank can still stop it." } ] }, "rail_name": "Austria eps-Überweisung", "governing_authority": "PSA Payment Services Austria GmbH", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "eps:limits", "id": "limits", "rail": "eps", "kind": "rail-fact", "facet": "limits", "name": "What limits apply to an eps payment, and who sets them?", "statement": "The eps standard sets no amount limit. What it caps is data: URLs at 512 characters, the structured payment reference at 35 and the unstructured one at 140, and a beneficiary name that Austrian online banking shows only to 70 characters. Refunds are capped at the original amount in total and are in euro only. Any per-payment or daily limit a buyer meets comes from their own bank [Unverified: no eps document states one], and the SCT scheme's own data limits apply to the transfer.", "details": [ { "label": "No amount limit in the eps standard", "value": "The eps standard sets no maximum or minimum amount: the instructed amount is a decimal with an ISO 4217 currency code, and neither the guideline nor the Scheme Operator's validation names a limit. Any limit a buyer meets comes from their own bank or the merchant contract [Unverified: no eps document states one].", "citation": "eps e-payment standard, Standard Implementation Guideline, version 2.7, sections 6.2.1.1.3 (epi:InstructedAmount), 7.1.2", "rests_on": "rule" }, { "label": "Data caps: URLs, references and names", "value": "URLs in eps messages are capped at 512 characters. The structured payment reference holds up to 35 characters and the unstructured one up to 140, each passed unchanged into the SCT remittance information. The beneficiary name field allows more, but Austrian online banking shows only 70 characters of it.", "citation": "eps e-payment standard, Standard Implementation Guideline, version 2.7, sections 4.6, 6.1, 6.2.1.1.2 (epi:BeneficiaryNameAddressText), 6.2.1.1.3", "rests_on": "rule" }, { "label": "Refunds may not exceed the original amount", "value": "A refund may be for all or part of the original amount, and several partial refunds of one payment are allowed, but the new refund plus every earlier refund of that payment may not exceed the original eps amount; a request that would is refused with code 022. Refunds are in euro only.", "citation": "eps Refundierung, version 1.0.1, sections 4.6 (code 022), 7.1.4, 8.1", "rests_on": "rule" } ], "exceptions": [ "Refunds accept only EUR (eps Refundierung section 7.1.4).", "The 13-month refund window is a time limit set by the Scheme Operator, not an amount limit." ], "applies_to": "eps payments (eps-Überweisung) routed through PSA's Scheme Operator under eps protocol versions 2.4 to 2.7, and eps refunds from protocol 2.6", "caveat": "No limit here means none in the eps documents read, not none at all: the buyer's bank and the merchant contract may set them.", "related": [ "sepa-sct:limits", "sepa-sct-inst:limits", "eps:refund" ], "basis": { "sources": "PSA, eps Standard Implementation Guideline version 2.7, sections 4.6, 6.1, 6.2.1.1.2, 6.2.1.1.3 and 7.1.2; eps Refundierung version 1.0.1, sections 4.6, 7.1.4 and 8.1; read 2026-09-19.", "confidence": "medium" }, "currency": { "effective_since": "2026-03-25", "effective_to": null, "effective_note": "Drafted on 2026-09-19 from PSA's eps documents as published that day. The SEPA layer is dated in the linked sepa-sct and sepa-sct-inst facts. The limits facet needs an ISO date; 2026-03-25 is the listing date of the guideline version 2.7 read, not an effective date [Unverified].", "source_edition": "eps Standard Implementation Guideline version 2.7 (file listed 2026-03-25), eps Refundierung version 1.0.1 and Technisches Beiblatt version 1.8 as the Rules cite them, read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://eps-ueberweisung.at/de/download/eps-ueberweisung-dokumentation/send/2-eps-ueberweisung-dokumentation/31-eps-standard-implementation-guideline-v2-7", "source_class": "authoritative_primary", "source_title": "eps e-payment standard, Standard Implementation Guideline, version 2.7", "checked_on": "2026-09-19", "checked_by": "validator-2026-09-19", "notes": "Confirms the guideline sets no amount minimum or maximum, and that URL fields are capped at 512 characters and remittance references at 35 or 140 characters." }, { "source_url": "https://eps-ueberweisung.at/de/download/eps-ueberweisung-dokumentation/send/2-eps-ueberweisung-dokumentation/16-eps-refundierung-dokumentation", "source_class": "authoritative_primary", "source_title": "eps Refundierung, version 1.0.1", "checked_on": "2026-09-19", "checked_by": "validator-2026-09-19", "notes": "Confirms a refund plus every earlier refund of the same payment may not exceed the original eps amount." } ] }, "rail_name": "Austria eps-Überweisung", "governing_authority": "PSA Payment Services Austria GmbH", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "eps:messages", "id": "messages", "rail": "eps", "kind": "rail-fact", "facet": "messages", "name": "What messages and formats does eps use?", "statement": "eps is an XML standard grown from the ECBS ePI of 2002. A payment runs through a set sequence: the merchant's initiation, the bank response with a redirect URL or an error code, a vitality check proving the merchant can receive the confirmation, the bank's signed confirmation with status OK, VOK, NOK or UNKNOWN and an optional status reason, and the merchant's acknowledgement. Status and transaction details requests and a status message serve status retrieval and the eps4mobile QR and app flows, and refunds have their own request and response. Redirect errors ERROR1 to ERROR3 travel as a URL parameter. The guideline maps the payment onto SCT pacs.008.", "details": [ { "label": "Status values OK, VOK, NOK and UNKNOWN", "value": "The payment confirmation carries one of four status values: OK, VOK, NOK or UNKNOWN. The debtor bank sends only OK or NOK; UNKNOWN is written by the Scheme Operator. A declined payment may add an eps:StatusReason with a ReasonCode and text, and 100 is the reason code for no error.", "citation": "eps e-payment standard, Standard Implementation Guideline, version 2.7, sections 6.2.2.7, 6.2.2.8, 7.1.12", "rests_on": "rule" }, { "label": "UNKNOWN when the bank's confirmation is late", "value": "When the debtor bank's confirmation is late: the Scheme Operator gives the bank its own redirect URLs, and if no confirmation has reached it in time it sends the merchant a confirmation with status UNKNOWN and lets the buyer be redirected to the shop. A bank confirmation arriving after that redirect is refused with HTTP 412.", "citation": "eps e-payment standard, Standard Implementation Guideline, version 2.7, sections 6.2.2.11 (usage of status code UNKNOWN), 6.3.5", "rests_on": "rule" }, { "label": "Redirect error values ERROR1 to ERROR3", "value": "When the buyer is sent back to the merchant's NOK URL, the debtor bank adds a parameter epserrorcode: ERROR1 when the merchant could not be reached with the confirmation, ERROR2 for faulty XML or a broken signature, ERROR3 when the buyer cancelled in online banking. With the Scheme Operator's central bank selection, the SO also uses ERROR3 when the chosen bank did not answer the initiation or failed while processing it.", "citation": "eps e-payment standard, Standard Implementation Guideline, version 2.7, sections 4.10, 7.1.15.2, 7.1.16, 7.2.5, 7.2.7", "rests_on": "rule" }, { "label": "The merchant must acknowledge the confirmation", "value": "On receiving the payment confirmation the merchant must answer the Scheme Operator at once: with a ShopResponseDetails that returns the session ID, status code and payment reference it received, or, if it cannot validate the confirmation (bad XML, bad signature), with an error text. The guideline advises marking the order paid on the confirmation itself, not on the buyer's return to the shop.", "citation": "eps e-payment standard, Standard Implementation Guideline, version 2.7, sections 6.4 (epsp:ConfirmationUrl, epsp:TransactionOkUrl), 6.8, 7.1.13.1, 7.1.13.2", "rests_on": "rule" }, { "label": "The bank signs its confirmation and names itself", "value": "The debtor bank's confirmation must be digitally signed and must include the original initiation; with status OK it must name the bank by BIC, and with NOK by BIC or another identifier. A confirmation without that identifier, unsigned, or with broken XML is refused by the Scheme Operator with HTTP 412 and never reaches the merchant. The SO forwards a valid confirmation unchanged, so the merchant can check the bank's signature itself.", "citation": "eps e-payment standard, Standard Implementation Guideline, version 2.7, sections 4.10 (mapping eps confirmation), 6.2.2, 6.7, 7.1.7, 7.1.11, 7.1.12", "rests_on": "rule" }, { "label": "Errors come back in the answer to the request", "value": "In the response to the request itself: the Scheme Operator or the debtor bank puts the ErrorCode and an ErrorMsg in its answer (for an initiation, epsp:BankResponseDetails, forwarded to the merchant), with the prefix SO: when the SO wrote it. An initiation that draws an error is ended there.", "citation": "eps e-payment standard, Standard Implementation Guideline, version 2.7, sections 4.10, 6.5, 7.1.2, 7.1.4, 7.1.5", "rests_on": "rule" }, { "label": "Error 013 is the Scheme Operator's alone", "value": "Error 013, no cross-border transactions allowed, may be sent only by the Scheme Operator, never by a debtor bank. The guideline does not define which cross-border case it covers [Unverified].", "citation": "eps e-payment standard, Standard Implementation Guideline, version 2.7, sections 6.5, 7.1.4", "rests_on": "rule" }, { "label": "eps fields map onto the SCT pacs.008", "value": "The guideline's annex maps the initiation onto the SCT interbank message pacs.008: the beneficiary's BIC, name and IBAN become the creditor agent, creditor and creditor account; the structured and unstructured references become the remittance information; the amount and currency carry over. eps asks the merchant for charge code SHA, where SCT uses SLEV.", "citation": "eps e-payment standard, Standard Implementation Guideline, version 2.7, sections 6.2.1.1.3, 9.1", "rests_on": "rule" }, { "label": "eps4mobile: QR code and app switch", "value": "For mobile banking apps the Scheme Operator gives each initiation a TransactionId and a QRCodeUrl with the epspayment scheme, returned to the merchant and passed to the bank. They let the buyer approve in a banking app by scanning a QR code on the bank's login page or at a point of sale, or by switching from the merchant's app. The bank fetches the payment with a transaction details request, and a merchant that opts in receives a status message once the bank has done so. The buyer still authorises with the bank's own methods.", "citation": "eps e-payment standard, Standard Implementation Guideline, version 2.7, sections 6.4 (epsp:TransactionID, epsp:QRCodeUrl), 6.9, 6.10, 6.11, 8", "rests_on": "rule" } ], "exceptions": [ "The same number means different things in different lists: 012 and 021 differ between the error list, the status reason list and the refund error list, so a code is read with its list.", "With the Scheme Operator's central bank selection, ERROR3 also marks a bank that did not answer the initiation, not only a buyer cancel (IG section 7.2.5)." ], "applies_to": "eps payments (eps-Überweisung) routed through PSA's Scheme Operator under eps protocol versions 2.4 to 2.7, and eps refunds from protocol 2.6", "caveat": "Merchants must support the latest schema (IG section 4.2), yet the Scheme Operator still lists endpoints for versions 2.4 to 2.7 (Beiblatt section 4.1.1); how long old versions stay open is not stated [Unverified]. XML namespaces still sit under stuzza.at; they are identifiers, not a statement of who operates eps.", "related": [ "sepa-sct:messages", "eps:return", "eps:refund" ], "basis": { "sources": "PSA, eps Standard Implementation Guideline version 2.7, preamble and sections 4.2, 4.10, 5, 6.2.2, 6.4 to 6.13, 7.1, 7.2, 8 and 9.1; eps Refundierung version 1.0.1, section 7; Technisches Beiblatt version 1.8, section 4.1.1; read 2026-09-19.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Drafted on 2026-09-19 from PSA's eps documents as published that day. The SEPA layer is dated in the linked sepa-sct and sepa-sct-inst facts.", "source_edition": "eps Standard Implementation Guideline version 2.7 (file listed 2026-03-25), eps Refundierung version 1.0.1 and Technisches Beiblatt version 1.8 as the Rules cite them, read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://eps-ueberweisung.at/de/download/eps-ueberweisung-dokumentation/send/2-eps-ueberweisung-dokumentation/31-eps-standard-implementation-guideline-v2-7", "source_class": "authoritative_primary", "source_title": "eps e-payment standard, Standard Implementation Guideline, version 2.7", "checked_on": "2026-09-19", "checked_by": "validator-2026-09-19", "notes": "Confirms the named eps XML messages (initiation, bank response, vitality check, confirmation, shop response, details and status requests), the OK, VOK, NOK and UNKNOWN status values, the ERROR1 to ERROR3 redirect values, and the mapping to SCT pacs.008." }, { "source_url": "https://eps-ueberweisung.at/de/download/eps-ueberweisung-dokumentation/send/2-eps-ueberweisung-dokumentation/16-eps-refundierung-dokumentation", "source_class": "authoritative_primary", "source_title": "eps Refundierung, version 1.0.1", "checked_on": "2026-09-19", "checked_by": "validator-2026-09-19", "notes": "Confirms the EpsRefundRequest and EpsRefundResponse messages carry the refund workflow." } ] }, "rail_name": "Austria eps-Überweisung", "governing_authority": "PSA Payment Services Austria GmbH", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "eps:participants", "id": "participants", "rail": "eps", "kind": "rail-fact", "facet": "participants", "name": "Who takes part in eps, and on what terms?", "statement": "PSA Payment Services Austria GmbH maintains the standard and runs the Scheme Operator every message passes through. Banks join by signing PSA's eServices legal framework agreement and its eps product sheet. Merchants, including e-government bodies, sign an eps merchant contract with their own bank or an eps acquirer, which also sets the price, and must let the buyer choose from all eps banks. The buyer needs only online banking at a bank that offers eps. PSA counts more than 11,000 web shops in Austria that accept it.", "details": [ { "label": "Every eps message goes through the Scheme Operator", "value": "Since protocol version 2.4 the whole eps workflow runs through the central Scheme Operator: merchants send to its routing URL, and toward the debtor bank the SO acts as the merchant, replacing the merchant's ID and URLs with its own and signing what it sends. It keeps every incoming and outgoing message.", "citation": "eps e-payment standard, Standard Implementation Guideline, version 2.7, preamble; sections 3.1, 7.1.3, 7.2.5", "rests_on": "rule" }, { "label": "Banks join under PSA's eServices legal framework", "value": "A bank that wants to offer eps must sign an eServices legal framework agreement with PSA as Scheme Operator and accept the eps product sheet in it; the SO then registers the bank for testing or production. The agreement is not public.", "citation": "eps e-payment standard, Standard Implementation Guideline, version 2.7, sections 1.2 (eService legal framework), 3.2, 3.3", "rests_on": "rule" }, { "label": "Merchants need an eps merchant contract", "value": "To offer eps a merchant must conclude an eps merchant contract with an eps bank, usually the bank holding its account, or with an eps acquirer; the bank or acquirer quotes the price. The contract decides whether payments are guaranteed. Its terms are not public.", "citation": "eps e-payment standard, Standard Implementation Guideline, version 2.7, preamble; sections 1.2, 3.4, 7.1.12; eps-Überweisung, Händler page and FAQ, Häufig gestellte Fragen", "rests_on": "rule" }, { "label": "The buyer chooses the bank, from all eps banks", "value": "The merchant must let the buyer choose their own bank: through the Scheme Operator's central bank selection, the SO's bank selection widget, or a list in the shop. A shop that keeps its own list must offer every registered eps debtor bank, taken from the list the SO provides.", "citation": "eps e-payment standard, Standard Implementation Guideline, version 2.7, sections 3.5, 7.1, 7.2, 7.3", "rests_on": "rule" }, { "label": "The buyer authorises in their own bank, with the payment locked", "value": "The buyer always authenticates directly with their own bank, in online banking or a banking app, with the bank's usual methods. The payee, amount, currency and payment reference arrive filled in and cannot be changed by the buyer, and eps messages pass none of the buyer's banking data to the merchant or any third party, apart from the optional IBAN, BIC and name a confirmation carries for refunds.", "citation": "eps e-payment standard, Standard Implementation Guideline, version 2.7, sections 1.1, 6.2.1.1.2, 6.2.1.1.3, 6.2.2.9 to 6.2.2.11, 8; eps-Überweisung, Privatkunden page and FAQ, Häufig gestellte Fragen", "rests_on": "rule" } ], "exceptions": [ "STUZZA built the standard with the Austrian banks, the finance ministry and the federal CIO; PSA is its successor, and older documents and processors (Adyen) still name STUZZA.", "In the eps4mobile flows the buyer approves in a banking app by QR code or app switch; the parties are the same." ], "applies_to": "eps payments (eps-Überweisung) routed through PSA's Scheme Operator under eps protocol versions 2.4 to 2.7, and eps refunds from protocol 2.6", "caveat": "The bank and merchant contracts are not public. Whether eps is a payment arrangement overseen by the Oesterreichische Nationalbank was not established [Unverified].", "related": [ "sepa-sct:participants", "eps:decision-points" ], "basis": { "sources": "PSA, eps Standard Implementation Guideline version 2.7, preamble and sections 1.1, 1.2, 3.1 to 3.5 and 5; PSA Händler and Privatkunden pages; Adyen Docs EPS page (secondary) for the STUZZA naming; read 2026-09-19.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Drafted on 2026-09-19 from PSA's eps documents as published that day. The SEPA layer is dated in the linked sepa-sct and sepa-sct-inst facts.", "source_edition": "eps Standard Implementation Guideline version 2.7 (file listed 2026-03-25), eps Refundierung version 1.0.1 and Technisches Beiblatt version 1.8 as the Rules cite them, read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://eps-ueberweisung.at/de/download/eps-ueberweisung-dokumentation/send/2-eps-ueberweisung-dokumentation/31-eps-standard-implementation-guideline-v2-7", "source_class": "authoritative_primary", "source_title": "eps e-payment standard, Standard Implementation Guideline, version 2.7", "checked_on": "2026-09-19", "checked_by": "validator-2026-09-19", "notes": "Confirms PSA as Scheme Operator, eps banks under the eServices agreement, and merchants or e-government bodies as the named participants." }, { "source_url": "https://eps-ueberweisung.at/de/privatkunden", "source_class": "public_primary", "source_title": "eps-Überweisung, Privatkunden page and FAQ", "checked_on": "2026-09-19", "checked_by": "validator-2026-09-19", "notes": "Confirms the consumer FAQ's claim of more than 11,000 web shops accepting eps in Austria." }, { "source_url": "https://docs.adyen.com/payment-methods/eps", "source_class": "secondary", "source_title": "Adyen Docs, EPS", "checked_on": "2026-09-19", "checked_by": "validator-2026-09-19", "notes": "Confirms Adyen's own documentation still names Stuzza as operating EPS, showing the older name persists outside PSA's own materials." } ] }, "rail_name": "Austria eps-Überweisung", "governing_authority": "PSA Payment Services Austria GmbH", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "eps:recall", "id": "recall", "rail": "eps", "kind": "rail-fact", "facet": "recall", "name": "Can a sent eps payment be recalled, and who decides?", "statement": "Not within eps. None of the messages PSA defines lets the merchant, the buyer or a bank pull a payment back once the bank has sent OK. A buyer who wants money back can ask the merchant for a refund, which only the merchant can start, or ask their own bank, whose interbank route is the SCT recall on the grounds that scheme allows, decided by the merchant's bank [Inference].", "details": [ { "label": "eps defines no return and no recall", "value": "Neither the guideline nor the refund specification defines a message by which a completed eps payment is returned by a bank or recalled by the payer's side. The only way eps itself moves money back is the merchant's refund, a new transfer [Inference from the absence of any such message].", "citation": "eps e-payment standard, Standard Implementation Guideline, version 2.7, sections 5, 6.4 to 6.13; eps Refundierung, version 1.0.1, section 7", "rests_on": "rule" }, { "label": "No eps message undoes a payment after OK", "value": "Once the debtor bank has sent OK, eps offers no way back: none of the messages the guideline defines lets the merchant, the Scheme Operator or the bank withdraw or cancel a confirmed payment [Inference from the absence of any such message]. PSA's merchant page presents it the same way: orders the bank's system has checked and accepted are confirmed online at once and carried out irrevocably.", "citation": "eps e-payment standard, Standard Implementation Guideline, version 2.7, sections 5, 6.4 to 6.13, 7.1; eps-Überweisung, Händler page and FAQ, section on the real-time execution guarantee", "rests_on": "rule" }, { "label": "Only the merchant starts a refund, through the Scheme Operator", "value": "After an eps payment has completed, the merchant, and only the merchant, may ask for a refund by sending an XML refund request to the Scheme Operator, whatever workflow the payment used. The merchant authorises it with its PIN in a SHA-256 fingerprint or with an XML signature. The SO checks the payment and the amount and sends a payment order to the merchant's bank for the buyer's account. Refunds need eps protocol version 2.6.", "citation": "eps Refundierung, version 1.0.1, sections 1, 2.2, 7.1.6", "rests_on": "rule" }, { "label": "The money moves as a SEPA credit transfer", "value": "eps moves no money itself. The buyer's own bank executes a SEPA credit transfer from the buyer's account to the merchant's IBAN, which the buyer authorised in their online banking; the guideline maps each payment field onto the SCT interbank message pacs.008. Finality, returns, recalls and liability for the transfer are therefore the SCT scheme's [Inference: no eps document says so in terms]. Whether a bank runs it as an SCT Inst payment is not stated in any eps document read [Unverified].", "citation": "eps e-payment standard, Standard Implementation Guideline, version 2.7, sections 1.1, 3.1, 7.1.7, 7.1.10, 9.1 (mapping table eps to SCT pacs.008)", "rests_on": "rule" } ], "exceptions": [ "Before OK, the buyer can still cancel in online banking, which ends the payment with NOK [Inference: status reason 030 names a buyer cancel, and section 7.1.7 requires NOK on a cancel, but the guideline does not tie the two]." ], "applies_to": "eps payments (eps-Überweisung) routed through PSA's Scheme Operator under eps protocol versions 2.4 to 2.7, and eps refunds from protocol 2.6", "caveat": "The recall route is Orca's reading: the eps documents neither describe nor exclude a bank using the SCT recall on an eps payment.", "related": [ "sepa-sct:recall", "sepa-sct-inst:recall", "sepa-sct:DUPL", "sepa-sct:TECH", "sepa-sct:FRAD", "sepa-sct:CUST", "eps:refund" ], "basis": { "sources": "PSA, eps Standard Implementation Guideline version 2.7, sections 5, 6.4 to 6.13 and 7.1.7; eps Refundierung version 1.0.1, sections 2.2 and 7; read 2026-09-19. The SCT recall is in the linked SEPA records.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Drafted on 2026-09-19 from PSA's eps documents as published that day. The SEPA layer is dated in the linked sepa-sct and sepa-sct-inst facts.", "source_edition": "eps Standard Implementation Guideline version 2.7 (file listed 2026-03-25), eps Refundierung version 1.0.1 and Technisches Beiblatt version 1.8 as the Rules cite them, read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://eps-ueberweisung.at/de/download/eps-ueberweisung-dokumentation/send/2-eps-ueberweisung-dokumentation/31-eps-standard-implementation-guideline-v2-7", "source_class": "authoritative_primary", "source_title": "eps e-payment standard, Standard Implementation Guideline, version 2.7", "checked_on": "2026-09-19", "checked_by": "validator-2026-09-19", "notes": "Confirms eps's message set has no recall message, so a buyer wanting a completed payment back has only the merchant refund or their own bank's channels outside eps." } ] }, "rail_name": "Austria eps-Überweisung", "governing_authority": "PSA Payment Services Austria GmbH", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "eps:refund", "id": "refund", "rail": "eps", "kind": "rail-fact", "facet": "refund", "name": "Can the buyer get money back, and on what grounds?", "statement": "eps has a refund, and only the merchant can start it. After a completed eps payment the merchant sends the Scheme Operator a refund request, authorised with its PIN, for all or part of the amount; several partial refunds are allowed while their total stays within the original. The SO checks that the payment completed less than 13 months ago, that the merchant and its bank are set up for refunds and that the paying account is registered, then writes a new SEPA credit transfer order from the merchant's account to the buyer's and hands it to the merchant's bank. A success answer means only that the bank accepted the order. None of this is a buyer right.", "details": [ { "label": "Only the merchant starts a refund, through the Scheme Operator", "value": "After an eps payment has completed, the merchant, and only the merchant, may ask for a refund by sending an XML refund request to the Scheme Operator, whatever workflow the payment used. The merchant authorises it with its PIN in a SHA-256 fingerprint or with an XML signature. The SO checks the payment and the amount and sends a payment order to the merchant's bank for the buyer's account. Refunds need eps protocol version 2.6.", "citation": "eps Refundierung, version 1.0.1, sections 1, 2.2, 7.1.6", "rests_on": "rule" }, { "label": "Refunds must be agreed with and enabled by the merchant's bank", "value": "Refunding eps payments has to be agreed in the merchant's contract with its bank, which must enable the merchant for the service at the Scheme Operator and itself support refunds. The account debited for a refund must be an IBAN registered for the merchant at the SO; it need not be the account the original payment credited.", "citation": "eps Refundierung, version 1.0.1, sections 3.2, 7.1.3, 8.1", "rests_on": "rule" }, { "label": "Refund only of a completed payment under 13 months old", "value": "The Scheme Operator refunds only an eps payment that has completed, and only if the original payment was made less than 13 months earlier. A payment not yet completed draws code 021; which code a payment older than 13 months draws is not stated [Unverified].", "citation": "eps Refundierung, version 1.0.1, sections 4.6 (code 021), 8.1", "rests_on": "rule" }, { "label": "Refunds may not exceed the original amount", "value": "A refund may be for all or part of the original amount, and several partial refunds of one payment are allowed, but the new refund plus every earlier refund of that payment may not exceed the original eps amount; a request that would is refused with code 022. Refunds are in euro only.", "citation": "eps Refundierung, version 1.0.1, sections 4.6 (code 022), 7.1.4, 8.1", "rests_on": "rule" }, { "label": "A refund is a new SEPA credit transfer order", "value": "For each accepted refund the Scheme Operator builds a SEPA credit transfer file (pain.001) from the merchant's account to the buyer's account, taking the buyer's name and IBAN from the original bank confirmation and the payment references from the original initiation, marked with category purpose EPAY, and uploads it to the merchant's bank by SFTP. The bank processes it from there and may require a manual release.", "citation": "eps Refundierung, version 1.0.1, sections 8.2, 8.3; eps e-payment standard, Standard Implementation Guideline, version 2.7, sections 6.2.2.9 to 6.2.2.11", "rests_on": "rule" }, { "label": "A successful refund answer is not a guarantee of payment", "value": "Code 000 in the refund response confirms only that the merchant's bank accepted the payment order. It is no guarantee the money is paid: limit and block checks on the merchant's account can still reject the order.", "citation": "eps Refundierung, version 1.0.1, sections 7.2, 7.2.1, 8.3", "rests_on": "rule" }, { "label": "Processor refund windows and options", "value": "Processors set their own refund terms for EPS: Stripe allows refunds and partial refunds up to 180 days after the payment, and Adyen supports refunds, partial refunds and multiple partial refunds. These are each processor's terms, shorter or different from the Scheme Operator's 13 months.", "citation": "Stripe Docs, EPS payments, Refunds section; payment method properties; Adyen Docs, EPS, feature table (Refunds, Partial refunds, Multiple partial refunds)", "rests_on": "practice" } ], "exceptions": [ "Refunds need eps protocol 2.6 or later (eps Refundierung section 1).", "The buyer's IBAN, BIC and name reach the merchant in the confirmation for refunds; the fields are optional (IG sections 6.2.2.9 to 6.2.2.11).", "Processor windows differ: Stripe allows refunds up to 180 days after the payment." ], "applies_to": "eps payments (eps-Überweisung) routed through PSA's Scheme Operator under eps protocol versions 2.4 to 2.7, and eps refunds from protocol 2.6", "caveat": "The 13-month limit is the Scheme Operator's check and Stripe's 180 days is Stripe's; neither is a consumer right, and the SCT rulebook gives nobody a refund right. Which error code a payment older than 13 months draws is not stated [Unverified].", "related": [ "sepa-sct:refund", "sepa-sct-inst:refund", "eps:return", "eps:consumer-law" ], "basis": { "sources": "PSA, eps Refundierung version 1.0.1, sections 1, 2.2, 3.2, 4.6, 7.1 to 7.2 and 8.1 to 8.3 (German, paraphrased in English); eps Standard Implementation Guideline version 2.7, sections 6.2.2.9 to 6.2.2.11; read 2026-09-19. Stripe Docs and Adyen Docs EPS pages (secondary) for processor terms.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Drafted on 2026-09-19 from PSA's eps documents as published that day. The SEPA layer is dated in the linked sepa-sct and sepa-sct-inst facts.", "source_edition": "eps Standard Implementation Guideline version 2.7 (file listed 2026-03-25), eps Refundierung version 1.0.1 and Technisches Beiblatt version 1.8 as the Rules cite them, read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://eps-ueberweisung.at/de/download/eps-ueberweisung-dokumentation/send/2-eps-ueberweisung-dokumentation/16-eps-refundierung-dokumentation", "source_class": "authoritative_primary", "source_title": "eps Refundierung, version 1.0.1", "checked_on": "2026-09-19", "checked_by": "validator-2026-09-19", "notes": "Confirms a refund is merchant-initiated only, checked by the Scheme Operator against completion, the 13 month age limit and the original amount, and paid as a new SCT order from a registered merchant IBAN, with acceptance not a guarantee of execution." }, { "source_url": "https://docs.stripe.com/payments/eps", "source_class": "secondary", "source_title": "Stripe Docs, EPS payments", "checked_on": "2026-09-19", "checked_by": "validator-2026-09-19", "notes": "Confirms Stripe's own EPS refund window runs up to 180 days after the original payment, shorter than the Scheme Operator's 13 months." } ] }, "rail_name": "Austria eps-Überweisung", "governing_authority": "PSA Payment Services Austria GmbH", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "eps:return", "id": "return", "rail": "eps", "kind": "rail-fact", "facet": "return", "name": "Is there a return, and what stops an eps payment before money moves?", "statement": "eps has no return. A payment that does not go through ends before any money moves: the debtor bank closes it with status NOK, optionally with a status reason such as a cancel by the buyer or the bank, a timeout, a technical or signature fault, or a fraud stop by the Scheme Operator. An initiation can also be refused outright with an error code before the buyer ever reaches their bank. Once a payment has been executed, the only return is the SCT one, raised by the merchant's bank on the transfer [Inference]. Stripe and Adyen report no chargebacks on EPS.", "details": [ { "label": "A failed payment ends with NOK, not a return", "value": "A payment that is not carried out never reaches the money: the debtor bank ends it with status NOK in the confirmation, which may carry an eps:StatusReason code explaining the decline. Because nothing was debited, nothing needs to be sent back.", "citation": "eps e-payment standard, Standard Implementation Guideline, version 2.7, sections 6.2.2.7, 6.2.2.8, 7.1.7, 7.1.11", "rests_on": "rule" }, { "label": "The debtor bank decides whether to execute", "value": "The debtor bank decides whether to carry out the transfer and answers with OK or NOK. It must send NOK, without a vitality check first, when the buyer cancels before or after logging in or an error occurs in online banking, and it must inform the buyer.", "citation": "eps e-payment standard, Standard Implementation Guideline, version 2.7, sections 6.2.2.7, 7.1.7, 7.1.11", "rests_on": "rule" }, { "label": "Errors come back in the answer to the request", "value": "In the response to the request itself: the Scheme Operator or the debtor bank puts the ErrorCode and an ErrorMsg in its answer (for an initiation, epsp:BankResponseDetails, forwarded to the merchant), with the prefix SO: when the SO wrote it. An initiation that draws an error is ended there.", "citation": "eps e-payment standard, Standard Implementation Guideline, version 2.7, sections 4.10, 6.5, 7.1.2, 7.1.4, 7.1.5", "rests_on": "rule" }, { "label": "eps defines no return and no recall", "value": "Neither the guideline nor the refund specification defines a message by which a completed eps payment is returned by a bank or recalled by the payer's side. The only way eps itself moves money back is the merchant's refund, a new transfer [Inference from the absence of any such message].", "citation": "eps e-payment standard, Standard Implementation Guideline, version 2.7, sections 5, 6.4 to 6.13; eps Refundierung, version 1.0.1, section 7", "rests_on": "rule" }, { "label": "Processors report no chargebacks on EPS", "value": "Stripe says EPS payments cannot turn into disputes that end in chargebacks, because the buyer authenticates the payment with their bank; Adyen marks chargebacks as not supported for EPS. This is how two processors run their own EPS acceptance, not an eps rule.", "citation": "Stripe Docs, EPS payments, Disputes section and payment method properties (dispute support); Adyen Docs, EPS, feature table (Chargebacks column)", "rests_on": "practice" } ], "exceptions": [ "UNKNOWN is not a failure; the payment may have gone through.", "A merchant that wants to give money back after OK uses an eps refund, which is a new transfer." ], "applies_to": "eps payments (eps-Überweisung) routed through PSA's Scheme Operator under eps protocol versions 2.4 to 2.7, and eps refunds from protocol 2.6", "caveat": "No chargeback is what two processors report for their own EPS acceptance; it is practice, not an eps rule.", "related": [ "sepa-sct:return", "sepa-sct-inst:return", "sepa-sct:AC04", "sepa-sct:AC06", "sepa-sct:AC01", "eps:refund" ], "basis": { "sources": "PSA, eps Standard Implementation Guideline version 2.7, sections 4.10, 5, 6.2.2.7, 6.2.2.8, 6.4 to 6.13, 7.1.7 and 7.1.11, read 2026-09-19; Stripe Docs and Adyen Docs EPS pages (secondary) for chargebacks.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Drafted on 2026-09-19 from PSA's eps documents as published that day. The SEPA layer is dated in the linked sepa-sct and sepa-sct-inst facts.", "source_edition": "eps Standard Implementation Guideline version 2.7 (file listed 2026-03-25), eps Refundierung version 1.0.1 and Technisches Beiblatt version 1.8 as the Rules cite them, read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://eps-ueberweisung.at/de/download/eps-ueberweisung-dokumentation/send/2-eps-ueberweisung-dokumentation/31-eps-standard-implementation-guideline-v2-7", "source_class": "authoritative_primary", "source_title": "eps e-payment standard, Standard Implementation Guideline, version 2.7", "checked_on": "2026-09-19", "checked_by": "validator-2026-09-19", "notes": "Confirms eps defines no return message: a payment that fails before OK ends as NOK with an optional StatusReason code." }, { "source_url": "https://docs.stripe.com/payments/eps", "source_class": "secondary", "source_title": "Stripe Docs, EPS payments", "checked_on": "2026-09-19", "checked_by": "validator-2026-09-19", "notes": "Confirms Stripe reports no chargeback exposure for EPS because the buyer authenticates the payment with their bank." } ] }, "rail_name": "Austria eps-Überweisung", "governing_authority": "PSA Payment Services Austria GmbH", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "eps:settlement", "id": "settlement", "rail": "eps", "kind": "rail-fact", "facet": "settlement", "name": "How does settlement work, and does eps hold the money?", "statement": "eps has no settlement of its own. The Scheme Operator routes XML messages between merchant and debtor bank and holds no funds [Inference from its role as a routing service]. The debtor bank executes a SEPA credit transfer from the buyer's account to the merchant's IBAN once the merchant has answered the vitality check; if the merchant does not answer, nothing is executed. The transfer then clears and settles like any SCT, through the banks' own clearing and settlement mechanisms [Inference].", "details": [ { "label": "Every eps message goes through the Scheme Operator", "value": "Since protocol version 2.4 the whole eps workflow runs through the central Scheme Operator: merchants send to its routing URL, and toward the debtor bank the SO acts as the merchant, replacing the merchant's ID and URLs with its own and signing what it sends. It keeps every incoming and outgoing message.", "citation": "eps e-payment standard, Standard Implementation Guideline, version 2.7, preamble; sections 3.1, 7.1.3, 7.2.5", "rests_on": "rule" }, { "label": "The debtor bank executes after a positive vitality check", "value": "After the buyer authorises, the debtor bank sends a vitality check through the Scheme Operator to the merchant's confirmation URL, to make sure the merchant can receive the confirmation. Only when the merchant's answer comes back does the bank execute the credit transfer.", "citation": "eps e-payment standard, Standard Implementation Guideline, version 2.7, sections 7.1.7, 7.1.8, 7.1.9, 7.1.10", "rests_on": "rule" }, { "label": "No transfer when the merchant misses the vitality check", "value": "If the merchant does not answer the vitality check before the timeout, the Scheme Operator tells the debtor bank with HTTP status 412, the bank shows the buyer an error and sends them to the merchant's NOK URL, and no credit transfer is executed; the buyer's TAN counts as used.", "citation": "eps e-payment standard, Standard Implementation Guideline, version 2.7, section 7.1.9", "rests_on": "rule" }, { "label": "The money moves as a SEPA credit transfer", "value": "eps moves no money itself. The buyer's own bank executes a SEPA credit transfer from the buyer's account to the merchant's IBAN, which the buyer authorised in their online banking; the guideline maps each payment field onto the SCT interbank message pacs.008. Finality, returns, recalls and liability for the transfer are therefore the SCT scheme's [Inference: no eps document says so in terms]. Whether a bank runs it as an SCT Inst payment is not stated in any eps document read [Unverified].", "citation": "eps e-payment standard, Standard Implementation Guideline, version 2.7, sections 1.1, 3.1, 7.1.7, 7.1.10, 9.1 (mapping table eps to SCT pacs.008)", "rests_on": "rule" }, { "label": "eps fields map onto the SCT pacs.008", "value": "The guideline's annex maps the initiation onto the SCT interbank message pacs.008: the beneficiary's BIC, name and IBAN become the creditor agent, creditor and creditor account; the structured and unstructured references become the remittance information; the amount and currency carry over. eps asks the merchant for charge code SHA, where SCT uses SLEV.", "citation": "eps e-payment standard, Standard Implementation Guideline, version 2.7, sections 6.2.1.1.3, 9.1", "rests_on": "rule" } ], "exceptions": [ "Whether a debtor bank executes the transfer as SCT or as SCT Inst is not stated in any eps document read [Unverified]; the guideline maps only to SCT.", "The approval time in the confirmation is when the bank wrote the confirmation, which the guideline says is most likely not when the merchant is credited (section 6.2.2.5)." ], "applies_to": "eps payments (eps-Überweisung) routed through PSA's Scheme Operator under eps protocol versions 2.4 to 2.7, and eps refunds from protocol 2.6", "caveat": "When the merchant's account is credited is a question for the SCT or SCT Inst scheme and the banks, not eps.", "related": [ "sepa-sct:settlement", "sepa-sct-inst:settlement", "eps:finality", "eps:messages" ], "basis": { "sources": "PSA, eps Standard Implementation Guideline version 2.7, sections 1.1, 3.1, 6.2.2.5, 7.1.3 and 7.1.7 to 7.1.10 and 9.1, read 2026-09-19.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Drafted on 2026-09-19 from PSA's eps documents as published that day. The SEPA layer is dated in the linked sepa-sct and sepa-sct-inst facts.", "source_edition": "eps Standard Implementation Guideline version 2.7 (file listed 2026-03-25), eps Refundierung version 1.0.1 and Technisches Beiblatt version 1.8 as the Rules cite them, read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://eps-ueberweisung.at/de/download/eps-ueberweisung-dokumentation/send/2-eps-ueberweisung-dokumentation/31-eps-standard-implementation-guideline-v2-7", "source_class": "authoritative_primary", "source_title": "eps e-payment standard, Standard Implementation Guideline, version 2.7", "checked_on": "2026-09-19", "checked_by": "validator-2026-09-19", "notes": "Confirms the debtor bank settles the credit transfer after a positive vitality check and that the Scheme Operator only routes messages between the parties." } ] }, "rail_name": "Austria eps-Überweisung", "governing_authority": "PSA Payment Services Austria GmbH", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "fednow:consumer-law", "id": "consumer-law", "rail": "fednow", "kind": "rail-fact", "facet": "consumer-law", "name": "What rights does a consumer have that the rulebook does not give?", "statement": "FedNow's own rules say nothing about what a bank owes its customer. Where a consumer account is on either end, the Electronic Fund Transfer Act and Regulation E apply on top, and Regulation J says in terms that the Act prevails over subpart C to the extent of any inconsistency. That produces the key asymmetry on this rail: a consumer can have a right to be made whole by their own bank even though the bank has no right to get the money back through FedNow. The limit of that right matters as much as its existence. Regulation E covers transfers the consumer did not authorise. A payment the consumer was tricked into making themselves is authorised, and the error resolution machinery is not written for it.", "details": [ { "label": "Regulation E prevails over the rail's own law", "value": "Consumer coverage does not push the rail's own law aside; it overrides it at the points where the two collide. A FedNow transfer stays under subpart C even when the Electronic Fund Transfer Act reaches part of it, and wherever the two say different things the Act is what governs.", "citation": "12 CFR 210.40(b)(4); repeated in the commentary to 210.41 under Payment Order, paragraph (2)", "rests_on": "law" }, { "label": "The Board's own worked examples", "value": "The Regulation J commentary works two of these through. Take a consumer who tells its own depository institution in time that the transfer was an unauthorised electronic fund transfer and claims the refund the Act gives it: that institution has to pay, and it has to pay whether or not subpart C would ever let it recover the money or unwind the payment order it sent to the Reserve Bank. The second example has the same shape for an error the customer properly asserts: the institution owes its customer the correction even while it stays obliged to pay its own payment order.", "citation": "12 CFR 210, appendix A to subpart C, commentary to section 210.40(b), paragraph (4)(i) and (ii)", "rests_on": "law" }, { "label": "Article 4A steps aside, subpart C does not", "value": "Article 4A takes itself out of the picture under 4A-108 as soon as the Act governs any part of a funds transfer. Subpart C does not follow it out. Every transfer on this rail remains under subpart C, and it makes no difference that the originator or the beneficiary is a consumer.", "citation": "12 CFR 210, appendix A to subpart C, commentary to section 210.41 under Payment Order, paragraph (2)", "rests_on": "law" }, { "label": "What counts as unauthorised", "value": "Three things all have to hold. Someone other than the consumer set the transfer in motion, that person had no actual authority to do it, and the consumer took no benefit from it. Three situations are then carved out by name: a transfer set going by a person the consumer handed the access device to, which stays authorised until the consumer tells the institution that this person's transfers no longer are; a transfer made with fraudulent intent by the consumer or by anyone acting with the consumer; and a transfer the institution or one of its employees initiated.", "citation": "12 CFR 1005.2(m)", "rests_on": "law" }, { "label": "Consumer liability caps for unauthorised transfers", "value": "Speed decides the exposure. Report loss or theft of an access device within two business days of learning of it and the consumer's liability stops at 50 dollars, or at the value of the unauthorised transfers if that is smaller. Report it later and the same comparison runs against 500 dollars instead. An unauthorised transfer that turns up on a periodic statement has to be raised within 60 days or the consumer carries what follows it. Extenuating circumstances lengthen these periods.", "citation": "12 CFR 1005.6(b)(1), (b)(2), (b)(3) and (b)(4)", "rests_on": "law" }, { "label": "Error resolution clock", "value": "A notice of error, spoken or written, starts the machinery, provided it reaches the institution within 60 days of the statement on which the error first showed. From there the institution has 10 business days to investigate and decide, three business days after finishing to tell the consumer the outcome, and one business day after deciding there was an error to put it right. Buying more time, up to 45 days in all, costs it a provisional credit to the account inside those first 10 business days.", "citation": "12 CFR 1005.11(b)(1)(i), 1005.11(c)(1) and 1005.11(c)(2)(i)", "rests_on": "law" }, { "label": "The scam gap", "value": "[Inference] A push payment the consumer was deceived into authorising is initiated by the consumer, so it does not meet the 1005.2(m) definition of an unauthorised transfer, and the error definition in 1005.11(a)(1) does not list it either. Nothing in Operating Circular 8 or the Operating Procedures gives the consumer a claim. The consumer's recourse is their own bank's policy, another law, or getting the receiving bank to send the money back voluntarily.", "citation": "12 CFR 1005.2(m) and 1005.11(a)(1) read together; absence of any consumer remedy in Operating Circular 8 and the public Operating Procedures", "rests_on": "law" }, { "label": "Funds availability", "value": "A beneficiary's bank that accepts a payment order must pay the beneficiary immediately after acceptance by crediting the account under Article 4A section 4A-405(a). The Expedited Funds Availability Act and Regulation CC also govern, but subpart C is stricter, so Regulation CC does not displace it. The commentary's example: accepting at 10 a.m. and crediting at 5 p.m. breaches subpart C even though Regulation CC is satisfied.", "citation": "12 CFR 210.44(b)(1) and commentary to 210.44(b) paragraph (2)", "rests_on": "law" }, { "label": "But that duty is owed upward, not to the customer", "value": "Having to pay the beneficiary at once gives the beneficiary nothing to sue on. The duty runs to the Reserve Bank: no one else, the beneficiary included, may assert it against the beneficiary's bank. Nor does it enlarge or shrink whatever that bank already owes the beneficiary under Article 4A or any other law.", "citation": "12 CFR 210.44(b)(2) and commentary to 210.44(b) paragraph (3)", "rests_on": "law" }, { "label": "Disclosure duties a FedNow bank still carries", "value": "Regulation E's general apparatus applies to a consumer account on this rail like any other: initial disclosures of liability, error resolution and stop payment rights, an annual or per statement error resolution notice, and 21 days' notice of an adverse change in terms.", "citation": "12 CFR 1005.7(b)(1) and (b)(7), 1005.8(a)(1) and 1005.8(b)", "rests_on": "law" }, { "label": "Where the rail does help a consumer indirectly", "value": "The request for payment warranty confines an RFP to legitimate purposes. Where the requesting bank's customer is an individual rather than a business, the test turns on the other side's expectations: an RFP the receiving bank's customer could not reasonably have looked for is a breach. That is a claim one bank makes against another, not a right a consumer holds, and being unhappy with the goods or the service does not on its own make out a breach.", "citation": "Operating Procedures v3.6 section 12.a RFP Warranties, p.52", "rests_on": "rule" } ], "exceptions": [ "Regulation E attaches to the account, not to the rail. A transfer between two business accounts over FedNow carries none of this.", "Small institution and other exclusions in 12 CFR 1005.3(c) can remove particular transfers from Regulation E coverage.", "An institution need not provisionally credit if it required and did not receive written confirmation of an oral notice of error within 10 business days.", "If state law or the account agreement imposes less liability on the consumer than 12 CFR 1005.6, the lesser amount applies.", "Remittance transfer rules in subpart B of Regulation E are not reached here, because a FedNow payment order today must have a US originator and a US beneficiary." ], "applies_to": "FedNow transfers where at least one end is a consumer account established primarily for personal, family or household purposes, in the United States.", "caveat": "This states where consumer law sits relative to the rail, not how a particular claim comes out. The Electronic Fund Transfer Act itself and the CFPB's official interpretations to Regulation E were not read for this record, and the scam gap line is an inference from two definitions rather than a stated rule. Treat it as the question to ask a lawyer, not the answer.", "related": [ "fednow:liability", "fednow:return", "fednow:refund" ], "basis": { "sources": "12 CFR 210 subpart C sections 210.40 and 210.44 with the appendix A commentary, read from eCFR for 2026-09-01. 12 CFR 1005 subpart A sections 1005.2, 1005.3, 1005.6, 1005.7, 1005.8 and 1005.11, read from eCFR for 2026-09-01. FedNow Service Operating Procedures April 2026 v3.6 section 12, read. EFTA statute and CFPB official interpretations not read.", "confidence": "medium" }, "currency": { "effective_since": "2026-09-01", "effective_note": "Date used is the eCFR point in time for the Regulation J and Regulation E text read. Regulation J subpart C is sourced from Reg. J, 87 FR 34362, June 6, 2022; Regulation E 1005.2 carries amendments through 83 FR 6417, February 13, 2018. Consumer rules on instant payment fraud are an active policy area and this facet should be rechecked more often than the rail's own rules.", "source_edition": "12 CFR 210 subpart C and 12 CFR 1005 subpart A as published on eCFR for 2026-09-01; FedNow Service Operating Procedures April 2026 version 3.6 (public version)", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "rail_name": "FedNow", "governing_authority": "Federal Reserve", "snapshot": "2026-09-17", "source_class": null, "effective_status": "draft", "effective_status_reason": null, "boundaries": [] }, { "uid": "fednow:decision-points", "id": "decision-points", "rail": "fednow", "kind": "rail-fact", "facet": "decision-points", "name": "Where does a rule leave the outcome to a bank's judgment?", "statement": "More of this rail is discretion than an outsider expects. The Reserve Banks may reject any message for any reason and may amend the circular without notice. The receiving bank decides in seconds whether to accept, and decides again whether to give money back when asked. The sending bank sets its own limits, its own negative list and its own thresholds. Almost nothing about a FedNow exception is decided by a rule; it is decided by a person or a system at one of two banks, inside a deadline. This record lists where, and cites the rule that leaves the decision open.", "details": [ { "label": "Reserve Bank, whether to accept at all", "value": "Any message can be turned away, for a reason the Reserve Bank need not give, or held back behind conditions it sets before it will take the message in; and an instant payment can still be turned away after the request for confirmation has gone out. Technical and business validation checks are not something it is obliged to run, and participants instruct it to carry on processing where it does not.", "citation": "Operating Circular 8, sections 9.1.1, 9.1.10 and 9.2.3; 12 CFR 210.45(a)", "rests_on": "rule" }, { "label": "Reserve Bank, whether to change the rules", "value": "Nothing here is a settled bargain. Operating Circular 8 can be amended whenever the Reserve Banks choose to amend it, with no notice owed beforehand, and the Operating Procedures can change at any time as well, where 30 days' notice of a material change is an aim rather than a promise.", "citation": "Operating Circular 8, section 22.1; Operating Procedures v3.6 section 2, p.6", "rests_on": "rule" }, { "label": "Reserve Bank, whether you may join or stay", "value": "Getting in and staying in are both judgment calls. Federal Reserve policy narrows eligibility and the Administrative Reserve Bank decides access on top of that; when a participant falls short of what is expected of it, what happens next is again a matter of Reserve Bank judgment, up to putting the participant off the service altogether. A participant that cannot be reached, or that is damaging the network, can also be signed off.", "citation": "Operating Circular 8, sections 5.1 and 14.3; Operating Procedures v3.6 section 4, p.9 and section 5.b, p.13", "rests_on": "rule" }, { "label": "Receiving bank, accept, reject or hold, in seconds", "value": "On a request for confirmation the receiving bank must answer within its reserved response time, one to five seconds of its own choosing inside a 20 second clock, with accept, reject, or accept without posting. It should use reasonable means to establish whether it holds an account for the beneficiary.", "citation": "Operating Circular 8, section 9.2.2; Operating Procedures v3.6 section 8.1 Reserved Receiver FI Response Time, p.27", "rests_on": "rule" }, { "label": "Receiving bank, whether it has reasonable cause", "value": "Accept without posting is open to the bank only where it has reasonable cause to think its beneficiary has no entitlement or permission to take the payment. Whether that bar is cleared is the bank's own call, and Regulation J leaves it there; real time screening is not something the Reserve Banks require of anyone.", "citation": "Operating Circular 8, section 9.2.2; 12 CFR 210.44(b)(3) and its commentary; Operating Procedures v3.6 section 3.a footnote 3, p.8", "rests_on": "law" }, { "label": "Receiving bank, whether to give money back", "value": "A return request is a request. The receiving bank answers IPAY, PECR, RJCR or PDCR on its own assessment, and a rejection ends the matter inside the service. The Reserve Banks will not determine whether a claim is sufficient or evaluate it.", "citation": "Operating Circular 8, section 9.6; Operating Procedures v3.6 section 15.2.c, pp.94 to 95 and section 12.d, p.53", "rests_on": "rule" }, { "label": "Either bank, whether an exception is fraud", "value": "Every unusual payment order has to be investigated by the participant to work out whether it turned into a reportable transfer, and the hinge of that is the participant's own good faith belief that fraud was behind it. The Reserve Banks carry the report and no more: they add nothing to it and pass no judgment on it.", "citation": "Operating Circular 8 Appendix C, sections 1.2.1, 1.2.2, 2.1 and 2.3", "rests_on": "rule" }, { "label": "Sending bank, whether a request for payment was legitimate", "value": "Sending a request for payment means warranting its purpose is legitimate, running risk based monitoring for abuse of the message, and investigating anomalous use, including going to its own customer about it. Once a warranty claim lands, the same bank has 20 business days to decide whether to take it or turn it down, with reasons either way.", "citation": "Operating Circular 8, section 9.8.5; Operating Procedures v3.6 sections 12.a, 12.b and 12.d, pp.52 to 54", "rests_on": "rule" }, { "label": "Sending bank, what it lets through", "value": "The participant chooses its own maximum transaction value between 1.00 dollar and the network limit, its reserved response time, its negative list entry pairs and restrictions, and its account activity thresholds. The Reserve Banks take no responsibility for monitoring or validating any of these choices and are not liable for losses arising from them.", "citation": "Operating Circular 8, sections 3.3, 3.4 and Appendix D sections 2.6 and 3.2; Operating Procedures v3.6 section 8.1, pp.26 to 27 and section 10.3.b, p.48", "rests_on": "rule" }, { "label": "Sending bank, what to do with a risk signal", "value": "Network Intelligence output is a flag, not a verdict: its only permitted use is to pick out a transaction for a closer look. Where an individual is involved, whatever the bank decides about proceeding has to rest on something other than that output. The Reserve Banks carry no liability for the routing decision the bank then takes.", "citation": "Operating Circular 8 Appendix E, sections 4.1, 4.2.1 and 10.1", "rests_on": "rule" }, { "label": "Either bank, whether to cooperate beyond the deadline", "value": "A participant receiving a nonvalue message about an exception must coordinate and use reasonable efforts to aid the other participant's investigation and remediate the exception. What reasonable efforts mean is not defined in the public text.", "citation": "Operating Circular 8, section 9.8.4 and Appendix C section 3.1", "rests_on": "rule" }, { "label": "Correspondent, whether a respondent may send", "value": "A correspondent can cap how much its direct respondents send, through a net send limit, and can decide respondent by respondent whether liquidity management transfers are available to them at all.", "citation": "Operating Procedures v3.6 section 8, p.22 and section 8.1 footnote 39, p.25; section 10.1 in the section list, p.42", "rests_on": "rule" } ], "exceptions": [ "Some things are not discretionary: an ACWP must be resolved by the ACWP Target Deadline unless acting either way would be impermissible under applicable law, and a rejection after ACWP obliges a prompt refund payment.", "A participant may not use ACWP as a general hold; it is available only on reasonable cause about the beneficiary's entitlement.", "A participant may not add its own institution's accounts to a negative list, and may not report a payment order it did not authorise as a reportable transfer.", "Nothing in the additional processing options in Appendix D restricts a Reserve Bank's own choice to accept a payment order under Article 4A section 4A-202(b).", "Where a consumer account is involved, the bank's discretion toward the network does not reduce its duties to its own customer under Regulation E." ], "applies_to": "FedNow Service exception handling and risk decisions, at the Reserve Banks, the sending participant and the receiving participant.", "caveat": "This is Orca's reading of where the rules leave judgment open, not a rule in itself, and it caps at medium confidence for that reason. Each line names the provision that leaves the decision open; none asserts how a bank will in fact decide. The deadlines a decision must be made inside are in the FedNow return, refund and hours entries (fednow:return, fednow:refund, fednow:hours), and several of them are strongly recommended rather than required.", "related": [ "fednow:finality", "fednow:return", "fednow:recall", "fednow:refund", "fednow:liability", "fednow:participants", "fednow:consumer-law" ], "basis": { "sources": "Operating Circular 8 effective 2026-04-01 sections 3, 5, 9.1, 9.2, 9.6, 9.8, 14, 22 and Appendices C, D and E, read. FedNow Service Operating Procedures April 2026 version 3.6 public version, sections 2, 3, 4, 5, 8.1, 10, 12 and 15.2, read. 12 CFR 210.44(b)(3) and 210.45(a) with commentary, read from eCFR for 2026-09-01.", "confidence": "medium" }, "currency": { "effective_since": "2026-04-01", "effective_note": "Operating Circular 8 effective 2026-04-01 with Operating Procedures April 2026 version 3.6. Sections 10.4 Account Activity Thresholds, 10.5 Network Intelligence and 11 Fraud Reporting are redacted in the public Operating Procedures, so some of the judgment those tools call for cannot be described from public text.", "source_edition": "Operating Circular 8 effective 2026-04-01; FedNow Service Operating Procedures April 2026 version 3.6 (public version); 12 CFR 210 subpart C as published on eCFR for 2026-09-01", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.frbservices.org/binaries/content/assets/crsocms/resources/rules-regulations/040126-operating-circular-8.pdf", "source_class": "authoritative_primary", "source_title": "Operating Circular 8, Funds Transfers Through the FedNow Service, effective 2026-04-01", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms Reserve Bank discretion to reject or condition any message and to amend the circular without notice (9.1.1, 9.1.10, 9.2.3, 22.1), participant eligibility and termination discretion (5.1, 14.3), receiving bank ACWP and return-request discretion (9.2.2, 9.6), fraud investigation and reporting discretion (Appendix C 1.2, 2.1, 2.3), RFP legitimacy and warranty discretion (9.8.5), and sending-bank threshold and Network Intelligence discretion (Appendix D 2.6, 3.2; Appendix E 4.1, 4.2.1, 10.1). Does not confirm the correspondent net-send-limit detail's Operating Procedures section 10.1 pinpoint, which is redacted in the public version; the claim itself is confirmed by the same line's other public citations." } ] }, "rail_name": "FedNow", "governing_authority": "Federal Reserve", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "fednow:finality", "id": "finality", "rail": "fednow", "kind": "rail-fact", "facet": "finality", "name": "When does a payment become final, and what does final not mean?", "statement": "Finality on FedNow has layers, and they settle at different moments. Settlement between the banks is final in seconds and cannot be undone: the credit to the receiving bank is final and irrevocable when made. Acceptance by the receiving bank, which is what obliges it to pay the beneficiary, is a separate event that can lag by a day where the bank answers accept without posting. And a consumer's right to be made whole by their own bank is a third thing again, which can exist after both of the others have closed. A payment that is final is not a payment that cannot come back; it is a payment that can only come back as a new payment, sent by choice.", "details": [ { "label": "Layer one, settlement between the banks", "value": "Whichever of two moments arrives first fixes settlement: the service posting the debit and the credit, or the service dispatching the Advice of Credit to the receiving bank. It is fixed at that moment whatever other Reserve Bank systems show and whatever the participant can or cannot yet see of its own balance.", "citation": "Operating Circular 8, section 7.1; Operating Procedures v3.6 section 4.a, p.9", "rests_on": "rule" }, { "label": "What the law calls that credit", "value": "Payment from a Reserve Bank to a receiving bank happens at whichever comes first, the credit reaching that bank's settlement account or the payment order being sent to it. The Board's commentary then says what sort of credit it is: from the moment it is made there is no taking it back, and Article 4A 4A-403 treats it as final settlement.", "citation": "12 CFR 210.46(a) and commentary to 210.46(a) paragraph (1)", "rests_on": "law" }, { "label": "Finality does not waive everything", "value": "Three things outlive that payment. Whatever claim the law of mistake and restitution gives a Reserve Bank stays with it. So does its ability to set the funds against an obligation the participant owes it, present or future. And legal process, or a third party's claim over the same funds, is left exactly where it was.", "citation": "Commentary to 12 CFR 210.46(a) paragraph (1); 12 CFR 210.47(c)", "rests_on": "law" }, { "label": "Layer two, acceptance by the receiving bank", "value": "What obliges the receiving bank to pay the beneficiary is not settlement but its own acceptance of the payment order. Answer ACWP and it has accepted nothing, under Article 4A or under the circular, notwithstanding that it has been paid, and Regulation J says as much in terms. From there it has until the ACWP Target Deadline, midnight ET on the first following day that is neither a weekend day nor a holiday it observes, to accept or to reject.", "citation": "Operating Circular 8, sections 9.2.5(a) and (b) and 2.9; 12 CFR 210.44(b)(3)", "rests_on": "law" }, { "label": "So the money can move and the payment still fail", "value": "Reject after an ACWP and three things follow at once: a refund payment has to be put in motion by the receiving bank without delay, the sender still owes its Reserve Bank, and no Reserve Bank takes on any duty to refund the sender. Settlement was final all along. The funds transfer simply never completed.", "citation": "Operating Circular 8, sections 9.2.5(c) and 9.2.5(f)", "rests_on": "rule" }, { "label": "Layer three, the customer's own claim", "value": "A consumer's claim lies against its own bank and runs under Regulation E, with Regulation J putting the Electronic Fund Transfer Act ahead of subpart C wherever the two conflict. The commentary puts the case plainly: the bank pays its consumer back even in the situation where subpart C leaves it no way to recover the money or to unwind the order it sent.", "citation": "12 CFR 210.40(b)(4) and commentary to 210.40(b) paragraph (4)(i)", "rests_on": "law" }, { "label": "No reversal, in any layer", "value": "There is no debit and no reversal message on this rail. Money returns only as a new funds transfer, which the holder of the funds chooses to send, or by other reasonable means.", "citation": "Operating Circular 8, section 9.6", "rests_on": "rule" }, { "label": "And no duty on the Reserve Banks to help you undo it", "value": "A Reserve Bank is not obliged to undo or alter a payment order however it is asked, and Article 4A 4A-211 does not make it so. Take the message in and what it owes is carriage of that message, nothing more.", "citation": "Operating Circular 8, section 9.8.6", "rests_on": "rule" }, { "label": "When finality has not yet happened", "value": "Up to settlement a Reserve Bank may turn a message away for any reason at all, including after the request for confirmation has gone out and including once the 20 second timeout has run. And a message is not in a Reserve Bank's hands at all until the FedNow application has time stamped it.", "citation": "Operating Circular 8, sections 9.1.1, 9.1.3 and 9.2.3", "rests_on": "rule" }, { "label": "Funds availability follows acceptance, not settlement", "value": "Where the receiving bank answers ACTC and the Reserve Bank accepts, funds must reach the beneficiary immediately after the Advice of Credit is put in front of that bank, which the Operating Procedures gloss as as soon as practicable and within a few seconds at most. Regulation J is what imposes the duty, and Regulation J also says the beneficiary gets no right out of it to assert against the bank.", "citation": "Operating Circular 8, sections 9.2.4 and 9.3; 12 CFR 210.44(b)(1) and (b)(2); Operating Procedures v3.6 section 5, p.12", "rests_on": "law" }, { "label": "The record of what happened is the Reserve Banks'", "value": "Timing disputes have one arbiter: the Reserve Banks' own records. They govern every timing question the service raises, settlement included, along with the limits on processing time and when a message was created, delivered and received.", "citation": "Operating Circular 8, section 13.2", "rests_on": "rule" } ], "exceptions": [ "A liquidity management transfer has no request for confirmation and no acceptance response, so layers one and two collapse into one for a pacs.009; it is returned only by a new pacs.009.", "The Reserve Banks' right of recovery under the law of mistake and restitution survives finality and may be waived only by express written agreement.", "A participant may object to a debit to its settlement account under Article 4A section 4A-505, with one year to bring the action.", "Finality is stated for settlement, not for the accounting view: balance reports may lag by up to about a minute and a provisional balance can stand from cycle day rollover until about 9 p.m. ET.", "The Reserve Banks may reject a payment order for any reason before accepting it, so a message in flight is not a payment." ], "applies_to": "FedNow Service value messages between participants. United States only. The consumer layer applies only where a consumer account is on one end.", "caveat": "Do not reduce this to a yes or no. An agent that reads 'final and irrevocable' and stops will tell a customer nothing can be done, which is wrong: the money is usually still in the named account, a return request exists, the receiving bank must help investigate, and a consumer may have a claim against their own bank whatever happens between the banks. An agent that reads 'there is a return request' and stops will promise a refund that no one is obliged to give.", "related": [ "fednow:settlement", "fednow:liability", "fednow:consumer-law", "fednow:return", "fednow:recall", "fednow:refund" ], "basis": { "sources": "Operating Circular 8 effective 2026-04-01 sections 7.1, 9.1, 9.2, 9.3, 9.6, 9.8 and 13.2, read. 12 CFR 210 subpart C sections 210.40, 210.44, 210.46 and 210.47 with appendix A commentary, read from eCFR for 2026-09-01. FedNow Service Operating Procedures April 2026 version 3.6 public version, sections 4, 5, 15.d and Appendix B, read.", "confidence": "high" }, "currency": { "effective_since": "2026-04-01", "effective_note": "Operating Circular 8 effective 2026-04-01; Regulation J subpart C as current on eCFR for 2026-09-01. The Reserve Banks may amend the circular at any time without prior notice.", "source_edition": "Operating Circular 8 effective 2026-04-01; 12 CFR 210 subpart C as published on eCFR for 2026-09-01; FedNow Service Operating Procedures April 2026 version 3.6 (public version)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.frbservices.org/binaries/content/assets/crsocms/resources/rules-regulations/040126-operating-circular-8.pdf", "source_class": "authoritative_primary", "source_title": "Operating Circular 8, Funds Transfers Through the FedNow Service, effective 2026-04-01", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17b", "notes": "Confirms settlement finality at the earlier of ledger entry or Advice of Credit (7.1), ACWP as non-acceptance under Article 4A with the ACWP Target Deadline and the refund-payment consequence of a post-ACWP rejection (9.2.5, 2.9), no reversal message and no Reserve Bank duty to cancel or amend (9.6, 9.8.6), funds availability timing after acceptance (9.2.4, 9.3), and that Reserve Bank records govern timing disputes (13.2). Regulation J appendix A commentary to 210.46(a), 210.44(b) and 210.47(c), read from eCFR for 2026-09-01, independently confirms the final-and-irrevocable characterization of the credit, survival of the mistake-and-restitution right after finality, and the beneficiary's-bank acceptance distinction; also confirms the consumer layer via commentary to 210.40(b)(4)." } ] }, "rail_name": "FedNow", "governing_authority": "Federal Reserve", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "fednow:hours", "id": "hours", "rail": "fednow", "kind": "rail-fact", "facet": "hours", "name": "When is the rail open, and what is a business day on it?", "statement": "FedNow never closes. Instant payments run 24 hours a day, every day of the year, including weekends and Federal Reserve holidays. But three different clocks matter and they do not agree: the funds transfer business day, which rolls at about 7:01 p.m. ET and differs from the calendar date until midnight; the standard business day, Monday to Friday except Federal Reserve holidays, which sets most response deadlines; and the liquidity management transfer window, which is open only part of the day on weekdays.", "details": [ { "label": "Instant payments", "value": "Open 24x7x365, and the Reserve Banks schedule no downtime for the service itself. Cycle day rollover does not interrupt it either; messages carry on processing straight through the roll.", "citation": "Operating Procedures v3.6 section 5.d, p.14 and section 6.a, p.15; FedNow Service Operating Hours page on frbservices.org, General Operating Hours", "rests_on": "rule" }, { "label": "Funds transfer business day", "value": "Every day of the week counts as one full 24 hour business day. Where it starts and stops is fixed by the FedNow Service Schedule the Reserve Banks publish on frbservices.org, and the same times bind every Reserve Bank whatever its own geography or time zone. The Reserve Banks may extend a day for any reason.", "citation": "Operating Circular 8, sections 11.1, 11.2 and 11.3", "rests_on": "rule" }, { "label": "When the day rolls", "value": "Approximately 7:01 p.m. ET, every calendar day. One cycle day ends and the next opens in the same instant, so processing never pauses. From the roll until midnight ET the date on the books is not the date on the wall, and it is the cycle day that dates a settlement. The roll is pinned to the Fedwire Funds Service close, so it slips later whenever Fedwire runs late, and the exact moment is not identical from one day to the next.", "citation": "FedNow Service Operating Hours page, Operating Hours for Instant Payment Messages; Operating Procedures v3.6 section 6.a, p.15", "rests_on": "rule" }, { "label": "How the roll is announced", "value": "Connection parties get an admi.004 broadcast carrying the ROLL event code when the day turns, and a second broadcast if the cycle day is extended. A participant reconciling its activity is expected to work from the cycle day in the message time stamps and not from what the calendar says.", "citation": "Operating Procedures v3.6 section 6.b, p.15 and section 6.c, p.17", "rests_on": "rule" }, { "label": "Standard business day", "value": "A weekday that is not a Federal Reserve holiday, measured over the Reserve Banks' core hours, which typically run 8:30 a.m. to 5 p.m. ET. Most FedNow response deadlines fall at midnight ET on the next such day, which is why a payment received on a Friday evening can carry a deadline of Monday night even though the rail itself never shut.", "citation": "Operating Circular 8, section 2.40; FedNow Service Operating Hours page, Standard business days and hours; Operating Procedures v3.6 Appendix A, pp.122 to 125", "rests_on": "rule" }, { "label": "Liquidity management transfer window", "value": "7 p.m. ET to 7 a.m. ET on weekdays, and all day on weekends and Federal Reserve holidays. Send a pacs.009 while the window is shut and the service rejects it.", "citation": "FedNow Service Operating Hours page, Operating Hours for Liquidity Management Transfer (LMT) Payment Messages; Operating Procedures v3.6 Appendix C Network Limits, p.128 and section 6.a, p.15", "rests_on": "rule" }, { "label": "Participant availability is an obligation, not a choice", "value": "Being reachable is a requirement, not a service level a bank sets for itself. A participant sending or receiving instant payments has to keep its messaging up, stay contactable about its customers, and put funds in front of a customer at any hour on any date in the year, Federal Reserve holidays and weekends included. Persistent failure can bring counselling, restriction or termination.", "citation": "Operating Circular 8, sections 14.1 and 14.3; Operating Procedures v3.6 section 5, p.12", "rests_on": "rule" }, { "label": "Planned downtime", "value": "Two ceilings and one fixed slot. A single stretch of planned maintenance is not to run past two consecutive hours, the quarterly total is not to pass 24 hours, and the work belongs in the Sunday window between 2 a.m. and 6 a.m. ET. Before going down, the participant signs off by participant broadcast (admi.004) or through the FedNow interface; from that point the service rejects instant payments addressed to it, while every other message type still reaches its queues.", "citation": "Operating Procedures v3.6 section 5.a, p.12", "rests_on": "guidance" }, { "label": "Timing inside a single payment", "value": "The payment timeout clock is 20 seconds for pacs.008, pacs.004 and pacs.009. Carved out of it is the receiving bank's reserved response time, which that bank configures anywhere from one to five seconds; it applies to instant payments only, since a pacs.009 draws no response from the receiver.", "citation": "Operating Procedures v3.6 Appendix C Network Limits, p.128 and section 8.1 Reserved Receiver FI Response Time, p.27", "rests_on": "rule" }, { "label": "Support is not 24x7 for everything", "value": "The Support Center itself is staffed 24x7x365. What is not always available is the work behind it: correspondent and respondent relationship changes, mergers, and opening or closing an account are handled only within standard business days and hours, and account balance reporting can drop out for a few minutes around the 7:00 p.m. to 7:05 p.m. ET rollover.", "citation": "Operating Procedures v3.6 Appendix B Support, pp.126 to 127", "rests_on": "guidance" } ], "exceptions": [ "A participant enabled only for liquidity management transfers is expected to be available only while the LMT window is open.", "Federal Reserve holidays change the LMT window to 7 p.m. ET the evening before the holiday through 7 p.m. ET on the holiday itself, and they remove that day from the standard business day count that response deadlines rely on.", "The Reserve Banks may delay the start of a new funds transfer business day or extend a cutoff time, and the cycle day extends when Fedwire Funds extends.", "The service adheres to daylight saving time, which moves rollover and end of day reporting; FedNow time stamps always carry the offset from UTC.", "The Reserve Banks may sign a participant off the service if it is unreachable, unresponsive or harming the network." ], "applies_to": "FedNow Service instant payments and liquidity management transfers, all participation types. United States, all times Eastern.", "caveat": "Three senses of 'business day' run at once on this rail and confusing them changes deadlines by days. The funds transfer business day is 24 hours and can differ from today's date. The standard business day is Monday to Friday and sets response deadlines. The calendar day is what a customer thinks in. Appendix G of the Operating Procedures, which holds the service level expectations, is redacted in the public version, so the availability numbers a participant is measured against are not public.", "related": [ "fednow:settlement", "fednow:limits" ], "basis": { "sources": "Operating Circular 8 effective 2026-04-01 sections 2.40, 11 and 14, read. FedNow Service Operating Procedures April 2026 version 3.6 public version, sections 5 and 6 and Appendices A, B and C, read. FedNow Service Operating Hours page on frbservices.org, fetched 2026-09-17.", "confidence": "high" }, "currency": { "effective_since": "2026-04-01", "effective_note": "Operating Circular 8 effective 2026-04-01. The FedNow Service Schedule is a live page the Reserve Banks may amend at any time (OC8 11.1), so the hours stated here age faster than the circular does.", "source_edition": "Operating Circular 8 effective 2026-04-01; FedNow Service Operating Procedures April 2026 version 3.6 (public version); FedNow Service Operating Hours page as fetched 2026-09-17", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.frbservices.org/binaries/content/assets/crsocms/resources/rules-regulations/040126-operating-circular-8.pdf", "source_class": "authoritative_primary", "source_title": "Operating Circular 8, Funds Transfers Through the FedNow Service, effective 2026-04-01", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17b", "notes": "Confirms the 24-hour funds transfer business day set by the FedNow Service Schedule and the Reserve Banks' right to extend it (11.1-11.3), the standard-business-day definition (2.40), participant availability as an obligation with counselling/restriction/termination for persistent failure (14.1, 14.3), and the 20 second timeout with a 1-5 second reserved receiver response time (Appendix C, section 8.1). The FedNow Service Operating Hours page on frbservices.org, fetched live 2026-09-17, independently confirms the cycle day rolls at approximately 7:01 p.m. ET (stated repeatedly, including under Operating Hours for Instant Payment Messages) and confirms the LMT window (7 p.m.-7 a.m. ET weekdays, 24 hours weekends/holidays) and the standard business day core hours (8:30 a.m.-5 p.m. ET). The public Operating Procedures v3.6 sections 5 and 6 and Appendix B confirm planned downtime limits, broadcast notification and the 7:00-7:05 p.m. ET reporting gap." } ] }, "rail_name": "FedNow", "governing_authority": "Federal Reserve", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "fednow:liability", "id": "liability", "rail": "fednow", "kind": "rail-fact", "facet": "liability", "name": "Who bears the loss when a payment goes wrong?", "statement": "Article 4A, as made federal law by Regulation J, allocates the loss between the banks, and Operating Circular 8 narrows what the Reserve Banks can owe. The Reserve Banks are liable for nothing beyond what Article 4A provides, never for consequential damages, and for a message handling failure only up to the fee paid for that message. Between the two banks, a bank that sends in its own name under an agreed security procedure is bound even by a payment order it did not authorise. Where a consumer is involved, the consumer's separate rights under Regulation E sit on top and are not touched by any of this.", "details": [ { "label": "The governing frame", "value": "Two instruments govern a FedNow funds transfer: subpart C of Regulation J and Operating Circular 8. Subpart C pulls Article 4A in and makes it federal law, and where the two read differently subpart C wins, as it does over any state law that conflicts with it. The circular is issued under Regulation J 210.40(c) and stands as an operating circular for the purposes of Article 4A 4A-107, which is what lets it displace an Article 4A provision it contradicts.", "citation": "12 CFR 210.40(a), 210.40(b)(1) and commentary to 210.40(a) and (c); Operating Circular 8, sections 1.1 and 21.2", "rests_on": "law" }, { "label": "Reserve Bank liability ceiling", "value": "Article 4A draws the outer bound. Handling a payment order, a Reserve Bank owes what that article makes it owe and not a dollar more, and it is forbidden to contract into consequential damages under 4A-305(d). For the circular's other services the exposure is narrower still: only losses flowing directly from willful misconduct or from a lapse of ordinary care. Special and consequential damages are out whether or not anyone saw them coming.", "citation": "12 CFR 210.47(a); Operating Circular 8, section 18.1", "rests_on": "law" }, { "label": "Liability capped at the fee", "value": "Where a Reserve Bank falls short of ordinary care or of good faith in processing one of the section 9 messages, the most it can be made to pay in damages is whatever fee that one message earned a Reserve Bank, and nothing above that.", "citation": "Operating Circular 8, section 18.2", "rests_on": "rule" }, { "label": "Unauthorised payment orders between a bank and its Reserve Bank", "value": "Picking one of the Reserve Banks' security procedures counts as rejecting the other. Article 4A 4A-203 then does the work: where the rejected procedure would have been commercially reasonable for that bank, the bank wears any message sent under its own name that a Reserve Bank accepted in line with the procedure the bank did pick, authorised by it or not.", "citation": "Operating Circular 8, sections 8.4 and 8.5", "rests_on": "rule" }, { "label": "Sixty days to report", "value": "The window to raise it is 60 calendar days, counted from whichever notice reaches the sender first, that its payment order was accepted or that its settlement account was debited for it. Sending the payment order is itself the sender's agreement that 60 days is the reasonable period Article 4A 4A-204(a) and 4A-304 leave open. Missing the window costs the sender its interest compensation, not the principal.", "citation": "12 CFR 210.43(c) and its commentary", "rests_on": "law" }, { "label": "One year to sue", "value": "Objecting to a debit on its Settlement Account requires the participant to have put notice to its Administrative Reserve Bank on 4A-505 terms first, and from the date of that notice it has a year to bring the claim. Any other claim against a Reserve Bank over the service runs its year from the transaction or occurrence instead, and in one forum only: the federal district court covering the head office of that Administrative Reserve Bank.", "citation": "Operating Circular 8, section 21.3; commentary to 12 CFR 210.43(c)(2)", "rests_on": "rule" }, { "label": "Indemnity for asking for a payment back", "value": "Asking for money back is not free of risk. Send a request for return, or any other message that seeks to cancel or amend a payment order, and Article 4A 4A-211 can put the participant on the hook, unless the message itself carries the element that gives up the indemnity obligation, in the form the technical specifications set. That element is not public.", "citation": "Operating Circular 8, section 9.8.7", "rests_on": "rule" }, { "label": "Request for payment warranty", "value": "Sending a request for payment carries a warranty, given both to the Reserve Bank and to the participant on the other end, that the request is legitimately meant. The sender also has to watch for abuse of these messages and to act on what it finds. Where the warranty is broken, the two banks settle it between themselves through a return request; the Reserve Banks make no determination on such a claim.", "citation": "Operating Circular 8, section 9.8.5; Operating Procedures v3.6 section 12.a and 12.d, pp.52 to 53", "rests_on": "rule" }, { "label": "Reliance on numbers, not names", "value": "Numbers win over names. A Reserve Bank presented with a number for the beneficiary's bank, or for the beneficiary, may act on that number even where the name in the same payment order points at somebody else, provided the inconsistency is not actually known to it, and it is under no obligation to go looking for one. Regulation J supplies non-bank senders and originators the notice that Article 4A requires before that reliance binds them.", "citation": "12 CFR 210.42(a) and (b) and commentary; Operating Circular 8, section 4.3", "rests_on": "law" }, { "label": "Where the Reserve Banks disclaim in advance", "value": "Not liable for: a participant's failure to follow the operating procedures or technical specifications; its profile and processing option choices; delay in retrieving a message; a routing number that went stale after publication; information in a message supplied by a participant; failure to meet availability obligations; an Additional Processing Option being unavailable; anything arising from Network Intelligence output or a decision taken on it.", "citation": "Operating Circular 8, sections 3.1, 3.4, 4.3, 4.4, 9.1.8, 14.4, Appendix D section 6.1 and Appendix E section 10.1", "rests_on": "rule" }, { "label": "Compensation is paid as interest", "value": "Compensation owed under Article 4A takes one form, interest, worked out by the 4A-506 method. If it lands with a sender or a receiving bank that is not itself the party entitled to it, that bank does not keep it: it must hand the benefit onward to whoever is entitled.", "citation": "12 CFR 210.47(b)(1) and (2)", "rests_on": "law" }, { "label": "The consumer layer is separate", "value": "Nothing above settles what a bank owes its own customer. Where the Electronic Fund Transfer Act reaches any part of the transfer, that Act, not subpart C, is what governs wherever the two conflict, and a consumer can hold a right to a refund in cases where the bank itself has no way to reverse the payment.", "citation": "12 CFR 210.40(b)(4) and commentary to 210.40(b)(4)(i) and (ii)", "rests_on": "law" } ], "exceptions": [ "Regulation J 210.44(b)(2) states that the beneficiary's bank's duty to make funds available immediately creates no right the beneficiary or any other party may assert against that bank, and does not affect its liability to the beneficiary under Article 4A or other law. The commentary gives the worked example: a bank that pays at 5 p.m. after accepting at 10 a.m. has breached subpart C, but the beneficiary has no claim under that provision.", "A participant and its service provider each indemnify the Reserve Banks for losses arising from the designation or use of that service provider, except where the loss arises solely from a Reserve Bank's own failure of ordinary care or good faith.", "The Reserve Banks do not waive any claim under the law of mistake and restitution.", "A Reserve Bank is not liable for loss beyond its reasonable control, including acts of war, civil unrest, strikes, terrorism and acts of nature.", "A funds transfer sent through another system but settled by a separate FedNow transfer is not governed by subpart C." ], "applies_to": "Allocation of loss among the Reserve Banks, the sending participant and the receiving participant on a FedNow funds transfer. It does not state what a bank owes its own customer.", "caveat": "Article 4A as set out in Appendix A to Regulation J was not read section by section for this record. Where an Article 4A section is named here, it is named as Regulation J or Operating Circular 8 cites it, not from its own text. That is why this record is medium, not high.", "related": [ "fednow:settlement", "fednow:participants", "fednow:consumer-law" ], "basis": { "sources": "12 CFR 210 subpart C sections 210.40 to 210.47 with the Appendix A commentary, read from eCFR for 2026-09-01. Operating Circular 8 effective 2026-04-01 sections 1, 3, 4, 8, 9.1, 9.8, 14, 15, 18, 21 and Appendices D and E, read. Operating Procedures April 2026 v3.6 section 12, read. Article 4A text itself not read.", "confidence": "medium" }, "currency": { "effective_since": "2026-04-01", "effective_note": "Operating Circular 8 effective 2026-04-01; Regulation J subpart C sourced from Reg. J, 87 FR 34362, June 6, 2022, as current on eCFR for 2026-09-01. The Reserve Banks may amend the circular at any time without prior notice, and a Board proposal of 2026-04-10 would change who may be an intermediary.", "source_edition": "Operating Circular 8 effective 2026-04-01; 12 CFR 210 subpart C as published on eCFR for 2026-09-01; FedNow Service Operating Procedures April 2026 version 3.6 (public version)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.frbservices.org/binaries/content/assets/crsocms/resources/rules-regulations/040126-operating-circular-8.pdf", "source_class": "authoritative_primary", "source_title": "Operating Circular 8, Funds Transfers Through the FedNow Service, effective 2026-04-01", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17b", "notes": "Confirms the Reserve Banks' liability ceiling under Article 4A with no consequential damages (18.1), the fee-paid damages cap for a section 9 message (18.2), the 60-day sender reporting window and the one-year suit limitation with its own-Reserve-Bank-district forum (21.3), unauthorised-order allocation between a participant and its Reserve Bank tied to security procedure selection (8.4-8.5), indemnity exposure for a cancellation or return request absent a disclaiming element (9.8.7), the RFP legitimacy warranty (9.8.5), and the listed liability disclaimers (3.1, 3.4, 4.3, 4.4, 9.1.8, 14.4, Appendix D 6.1, Appendix E 10.1). Regulation J 210.40(a) commentary, 210.42, 210.43(c), 210.44(b)(2) and 210.47 with appendix A commentary, read from eCFR for 2026-09-01, independently confirm the governing-frame, reliance-on-number, 60-day, beneficiary-no-claim and interest-compensation claims. Article 4A's own text (as set out in Regulation J appendix A) was not read section by section, consistent with the record's medium confidence and caveat." } ] }, "rail_name": "FedNow", "governing_authority": "Federal Reserve", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "fednow:limits", "id": "limits", "rail": "fednow", "kind": "rail-fact", "facet": "limits", "name": "What are the amount limits, and who sets them?", "statement": "There are two layers. The Reserve Banks set network limits that no participant may exceed: 10,000,000 US dollars for a customer credit transfer, a payment return and a liquidity management transfer alike. Underneath that, each sending bank sets its own maximum, which starts at a default of 100,000 dollars for customer credit transfers and 2,500,000 dollars for liquidity management transfers and can be raised up to the network limit. A third layer, whatever limit a bank puts on its own customer, is not published by anyone.", "details": [ { "label": "Network maximum, customer credit transfer", "value": "10,000,000 US dollars for a pacs.008. A message above it is rejected by the service. Applies to participants with Credit Transfer send and receive, or send, receive and receive Request for Payment.", "citation": "Operating Procedures v3.6 Appendix C Network Limits, p.128", "rests_on": "rule" }, { "label": "Network maximum, payment return", "value": "10,000,000 US dollars for a pacs.004, for all participants with a Credit Transfer participation type.", "citation": "Operating Procedures v3.6 Appendix C Network Limits, p.128", "rests_on": "rule" }, { "label": "Network maximum, liquidity management transfer", "value": "10,000,000 US dollars for a pacs.009, for all participants with an LMT participation type.", "citation": "Operating Procedures v3.6 Appendix C Network Limits, p.128", "rests_on": "rule" }, { "label": "Participant default, customer credit transfer", "value": "100,000 US dollars out of the box. The participant, or a service provider acting for it, resets that figure in the FedNow interface to any whole dollar amount from 1.00 dollar up to the network maximum. It bites on the way out only, and a profile that does nothing but receive has the field greyed out altogether.", "citation": "Operating Procedures v3.6 Appendix C, p.128 and section 8.1 Maximum Transaction Value Limit, p.26 with footnote 40", "rests_on": "rule" }, { "label": "Participant default, liquidity management transfer", "value": "2,500,000 US dollars, configurable by the participant up to the 10,000,000 dollar network maximum.", "citation": "Operating Procedures v3.6 Appendix C Network Limits, p.128", "rests_on": "rule" }, { "label": "A return is measured against the network limit only", "value": "Only one ceiling governs a payment return (pacs.004), and it is the network limit. The participant's own configured value limit is passed over on the return path even when it sits well below the network figure, so a bank that has held its own send limit low can still return a payment worth more than that limit.", "citation": "Operating Procedures v3.6 section 15.2.b Payment Return Value Limit Validation, p.92", "rests_on": "rule" }, { "label": "Minimum amount", "value": "Nothing smaller than 0.01 dollars may be sent as a value message. At the small end there is also the microdeposit: the Federal Reserve treats a customer credit transfer of 1.00 dollar or less, sent to prove out an account, as one, and permits it only where a relationship with the receiver is already in place or is being formed, whether that relationship is the sending bank's or its customer's.", "citation": "Operating Procedures v3.6 section 15.a Value Messages, p.78 and section 15.g Account Validation, p.82", "rests_on": "rule" }, { "label": "Time limits, which also bound a payment", "value": "The payment timeout clock is 20 seconds for pacs.008, pacs.004 and pacs.009. Within it the receiving bank reserves one to five seconds, configurable, to answer. If the clock expires the payment is rejected, and a resend needs a new unique message ID.", "citation": "Operating Procedures v3.6 Appendix C, p.128; section 8.1 Reserved Receiver FI Response Time, p.27; section 15.b Payment Timeout Clock, p.79", "rests_on": "rule" }, { "label": "Velocity and cumulative value controls are separate from limits", "value": "A sending bank may set account activity thresholds on its own customers' accounts, by count or by cumulative dollar value over a chosen period, and three cumulative value criteria are populated by default when a bank takes the Credit Transfer send and receive type. A breach rejects the payment with code F008 (value) or F009 (velocity). These are the bank's settings, not network limits.", "citation": "Operating Circular 8 Appendix D, sections 1.2.1 and 4.0; Operating Procedures v3.6 section 10.2.a and 10.2.d, pp.43 and 45", "rests_on": "rule" }, { "label": "Limits on an end customer are not published", "value": "What a bank allows its own account holder to send in one payment, per day or per month is set by that bank and is not published by the Federal Reserve, and no single published figure exists. Any number for it has to come from the specific bank.", "citation": "Absence of any such figure in Operating Circular 8, in the public Operating Procedures including Appendix C, and on the frbservices.org FedNow pages read 2026-09-17", "rests_on": "practice" } ], "exceptions": [ "A receiving bank cannot impose a lower amount limit through the service; the configurable maximum transaction value limit applies to sending only.", "Payment returns bypass the participant's own value limit, as above.", "Liquidity management transfers are additionally bounded by the LMT window, so an in limit pacs.009 sent outside 7 p.m. to 7 a.m. ET on a weekday is rejected anyway.", "A message may pass the limit check and still be rejected on insufficient balance or overdraft capacity, which is a different control with a different cause.", "No published minimum or maximum applies to a Request for Payment (pain.013) itself, and a zero dollar RFP is an established market practice used to test readiness." ], "applies_to": "Per message value limits on the FedNow Service, in US dollars. Network limits apply to every participant; the configurable limits apply per routing number with a Participant Profile.", "caveat": "Limits move faster than rules. The Federal Reserve publishes network and default figures in Appendix C of the Operating Procedures, which the Reserve Banks may change at any time, and features have shipped between versions. The 10,000,000 dollar figure is stated by the April 2026 edition; the date the Reserve Banks first set it is not established by the documents read here.", "related": [ "fednow:settlement", "fednow:hours" ], "basis": { "sources": "FedNow Service Operating Procedures April 2026 version 3.6, public version, Appendix C and sections 8.1, 10.2, 15 and 15.2, read. Operating Circular 8 effective 2026-04-01 Appendix D, read. frbservices.org FedNow pages fetched 2026-09-17 carry no other limit.", "confidence": "high" }, "currency": { "effective_since": "2026-04-28", "effective_note": "The date used is the version date of the public Operating Procedures that states these figures, not the date the Reserve Banks set them. The 10,000,000 dollar network maximum predates this edition; its start date is not established by any public document read for this record. Figures may change between Operating Procedures versions without a circular change.", "source_edition": "FedNow Service Operating Procedures April 2026 version 3.6 (public version, file dated 2026-04-28); Operating Circular 8 effective 2026-04-01", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.frbservices.org/binaries/content/assets/crsocms/resources/rules-regulations/042826-fednow-service-operating-procedures.pdf", "source_class": "authoritative_primary", "source_title": "FedNow Service Operating Procedures, April 2026, version 3.6 (public version, file dated 2026-04-28)", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17b", "notes": "Confirms Appendix C Network Limits exactly: 10,000,000 dollar network maximum for pacs.008, pacs.004 and pacs.009 alike, 100,000 dollar default customer credit transfer limit configurable up to the network maximum, 2,500,000 dollar default LMT limit, and the 20 second timeout clock. Confirms a payment return is validated only against the network limit, not the participant's own value limit (section 15.2.b). Confirms the microdeposit and minimum-value language at section 15 and the account activity threshold defaults referencing Operating Circular 8 Appendix D. No published minimum or maximum for a request for payment, and no published end-customer limit, were found anywhere in this document, Operating Circular 8 or the frbservices.org FedNow pages, consistent with the record's absence claims." } ] }, "rail_name": "FedNow", "governing_authority": "Federal Reserve", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "fednow:messages", "id": "messages", "rail": "fednow", "kind": "rail-fact", "facet": "messages", "name": "What messages does this rail use, and which are payments?", "statement": "FedNow runs on ISO 20022 with Federal Reserve usage guidelines, and every message must be cryptographically signed. Only three messages move money: pacs.008, pacs.004 and pacs.009. Everything else, including the return request and the request for payment, is a nonvalue message that creates no accounting entry. Which messages a bank must handle depends on its participation type, and a message its profile prohibits will not reach it.", "details": [ { "label": "Standard", "value": "ISO 20022, shaped by the FedNow Service's own usage guidelines. What the service carries falls into four buckets, one of which moves money and three of which do not: value, nonvalue, system and account reporting. Every message, outbound or inbound, rides under a Business Application Header (head.001).", "citation": "Operating Procedures v3.6 section 13.2.a and 13.2.d, pp.56 and 58", "rests_on": "rule" }, { "label": "Value messages", "value": "pacs.008 customer credit transfer, pacs.004 payment return, pacs.009 financial institution credit transfer for a liquidity management transfer. These are the payment orders; they settle and they carry the timeout clock and the network limits.", "citation": "Operating Procedures v3.6 section 1 Value Message definition, p.6 and section 15, p.78", "rests_on": "rule" }, { "label": "Nonvalue messages", "value": "Anything that is not a payment order and puts no accounting entry on any Reserve Bank's books. In practice that is the whole request and exception traffic: asking to be paid, asking to cancel such a request, asking for funds back, asking for information, plus the administrative messages. Carrying no value buys no exemption, though. A nonvalue message is held to the Reserve Banks' formats, their security procedures and their time and fee schedules exactly as a payment is.", "citation": "Operating Circular 8, sections 2.29, 9.8.1 and 9.8.2", "rests_on": "rule" }, { "label": "Status, which is not a message type", "value": "pacs.002 carries the status. A FedNow payment status comes from the service itself and is final as to settlement: ACSC settled, ACWP accepted without posting, RJCT rejected. A participant payment status comes from the receiving bank and does not affect settlement: ACTC intent to accept, RJCT, ACWP, then ACCC posted, PDNG pending or BLCK blocked. The two are told apart by the Instructing Agent field.", "citation": "Operating Procedures v3.6 section 15.e Payment Status (pacs.002), p.80", "rests_on": "rule" }, { "label": "Exception and enquiry messages", "value": "camt.056 return request, camt.029 return request response and also RFP cancellation response and information request response, pacs.028 payment status request, camt.026 information request, camt.028 additional payment information.", "citation": "Operating Procedures v3.6 Appendix F, pp.131 to 132 and Appendix A, pp.122 to 125", "rests_on": "rule" }, { "label": "Request for payment messages", "value": "pain.013 request for payment, pain.014 RFP response, camt.055 RFP cancellation request, with camt.029 as the cancellation response. A pain.013 is a nonvalue message; if accepted, the receiving bank's customer pays by a separate pacs.008.", "citation": "Operating Procedures v3.6 section 16.1.a, p.102 and Appendix F, p.131; Operating Circular 8, section 9.8.1", "rests_on": "rule" }, { "label": "System and reporting messages", "value": "admi.002 message reject, admi.007 receipt acknowledgement, admi.004 FedNow broadcast and participant broadcast, admi.011 system response, admi.006 retrieval request, admi.998 participant file, camt.060 reporting request, camt.052 account balance and activity reports, camt.054 debit and credit notification.", "citation": "Operating Procedures v3.6 Appendix F, pp.131 to 133", "rests_on": "rule" }, { "label": "What a profile makes mandatory", "value": "Appendix F states per participation type whether each message is mandatory, optional, conditional or prohibited to send and to receive. A Credit Transfer Receive Only participant is prohibited from sending pacs.008 and may only optionally send camt.056; a Send, Receive and Receive RFP participant must handle pain.013, pain.014 and camt.055. A Settlement Only participant is prohibited from sending or receiving pacs.009.", "citation": "Operating Procedures v3.6 Appendix F Tables 1 and 2, pp.131 to 133", "rests_on": "rule" }, { "label": "Signing and uniqueness are conditions of delivery", "value": "Every message exchanged with the service must be signed, except the participant broadcast ping and the API ping. An unsigned message, one signed with an expired key or one signed with an unrecognised key is rejected with admi.002. Every message needs a unique message ID in the header, including on a resend of a rejected message, and participants must detect and discard duplicate messages the service may deliver.", "citation": "Operating Procedures v3.6 section 7.a, p.18 and section 13.2.c, pp.57 to 58; Operating Circular 8, sections 9.1.12 and 9.1.13", "rests_on": "rule" }, { "label": "APIs, alongside the messages", "value": "Optional REST APIs sit beside required ISO 20022 messaging: Ping, Participant List, FedNow Account Balance and Network Intelligence, the last returning receiver account level risk data before a pacs.008 is sent.", "citation": "Operating Procedures v3.6 section 13.1.c, p.55; Operating Circular 8 Appendix E, sections 1.3 and 4.1", "rests_on": "rule" }, { "label": "The message specifications themselves are not public", "value": "The FedNow Service ISO 20022 Message Specifications, Implementation Guide and message flows sit on the Federal Reserve Financial Services MyStandards portal and on FedNow DevRel, both of which require credentials. They hold the permitted reason code list for each message. Orca does not consult them.", "citation": "Operating Procedures v3.6 section 2.b document table, p.6 and section 13.2.a footnote 94, p.56", "rests_on": "rule" } ], "exceptions": [ "camt.029 does duty for three different conversations: the return request response, the RFP cancellation response and the information request response. Its code set differs by use.", "A liquidity management transfer has no request for confirmation and no response message, so the receiving bank never answers a pacs.009; it is returned by a new pacs.009, never by a pacs.004.", "An Advice of Credit is, by operation of the circular, a payment order sent by the Reserve Bank to the receiving bank, and it carries the contents of the related Request for Confirmation.", "The service does not process an admi.002 sent to it by a participant; a participant needing to reject a FedNow message must telephone the Support Center.", "Zero dollar RFP is a market practice built on pain.013 and pain.014 with only ACTC and RJCT used in response; its guide sits on MyStandards and was not read." ], "applies_to": "All messaging on the FedNow Service, by any participation type, over MQ or API.", "caveat": "This lists the messages and what they are for. It does not list the reason codes any of them may carry. Those live in the ISO 20022 Message Specifications on MyStandards and in Appendix D of the Operating Procedures, which is redacted as confidential in the public version. Nine FedNow codes are public and are named in Orca's FedNow rail brief (docs/rails/fednow.md); the rest are not, and an ISO code valid elsewhere is not valid on FedNow unless the FedNow specifications permit it.", "related": [ "fednow:limits" ], "basis": { "sources": "FedNow Service Operating Procedures April 2026 version 3.6, public version, sections 7, 13, 15, 16 and Appendices A and F, read. Operating Circular 8 effective 2026-04-01 sections 2, 9.1, 9.5, 9.7, 9.8 and Appendix E, read.", "confidence": "high" }, "currency": { "effective_since": "2026-04-01", "effective_note": "Operating Circular 8 effective 2026-04-01 with Operating Procedures April 2026 version 3.6. New features have brought new messages and codes between versions, so the message set is checked against the current Operating Procedures rather than assumed stable.", "source_edition": "Operating Circular 8 effective 2026-04-01; FedNow Service Operating Procedures April 2026 version 3.6 (public version)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.frbservices.org/binaries/content/assets/crsocms/resources/rules-regulations/042826-fednow-service-operating-procedures.pdf", "source_class": "authoritative_primary", "source_title": "FedNow Service Operating Procedures, April 2026, version 3.6 (public version, file dated 2026-04-28)", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17b", "notes": "Confirms the value/nonvalue/system/reporting message split and the Business Application Header (section 13.2), the three value messages pacs.008/pacs.004/pacs.009, the pacs.002 and camt.029 status code sets, the exception and RFP message set (camt.056, camt.029, pacs.028, camt.026, camt.028, pain.013, pain.014, camt.055), the system and reporting messages, and the Appendix F messaging chart showing mandatory/optional/prohibited status by participation type, including that camt.056 is optional to send for a Receive Only participant and mandatory otherwise. Confirms Appendix D (Error and Warning Codes and Descriptions) and Appendix E (Required Test Cases) are each marked confidential and not available on the public website, supporting the caveat that reason codes are not public. Operating Circular 8 sections 2.29, 9.1.12-9.1.13 and 9.8.1 independently confirm the nonvalue message definition and the signing and uniqueness requirements." } ] }, "rail_name": "FedNow", "governing_authority": "Federal Reserve", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "fednow:participants", "id": "participants", "rail": "fednow", "kind": "rail-fact", "facet": "participants", "name": "Who can join, and who can be on either end of a payment?", "statement": "Only a financial institution eligible to hold a Reserve Bank account can be a FedNow participant, and even then the Reserve Bank decides. A participant picks a participation type, which fixes what it can send and receive. On the customer side the rail is closed and domestic: the originator and the beneficiary must each be a participant or hold a deposit account at one, in the United States. Non-banks reach the rail only as service providers or as customers of a participant.", "details": [ { "label": "Eligibility", "value": "Two gates, and a bank has to pass both. The first is legal: only an institution that applicable law allows to hold the Account Holder position defined in Operating Circular 1 can be a participant at all. The second is discretionary: Federal Reserve policy narrows the field beyond that, and the Administrative Reserve Bank decides for itself whether to let an applicant onto the service.", "citation": "Operating Circular 8, section 5.1", "rests_on": "rule" }, { "label": "Participation types", "value": "Three categories. Credit Transfer, in three forms: Receive Only; Send and Receive; Send, Receive and Receive Request for Payment. Liquidity Management Transfer, as Receive Only or Send and Receive. Settlement Only, a stand alone type for a correspondent. Turning on Credit Transfer brings LMT with it by default, and a bank that does not want LMT has to opt out of it.", "citation": "Operating Procedures v3.6 section 8.1.a Participation Type, pp.25 to 26 and Appendix F footnote 197, p.133", "rests_on": "rule" }, { "label": "One profile per routing number", "value": "A Participant Profile is required for each routing number a bank uses on the service, and a bank may have several. The profile fixes the participation type, the configurable limits, the reserved response time and the connection permissions. A bank is not required to enable every message type.", "citation": "Operating Procedures v3.6 section 8 Profiles Overview, pp.21 to 22; Operating Circular 8, sections 3.2 and 3.2.1", "rests_on": "rule" }, { "label": "Who can be originator or beneficiary", "value": "Both ends of the payment have to sit inside the network. The originator either is a participant itself or banks with the sending participant on a US deposit account, and the beneficiary faces the same test against the receiving participant. Name anyone else and the payment order must not be sent. That test is what keeps the rail domestic today.", "citation": "Operating Circular 8, section 9.1.2", "rests_on": "rule" }, { "label": "Correspondents", "value": "A correspondent is a bank that holds its own Master Account at a Reserve Bank and has taken on another participant's Settlement Account. Whether it needs a Participant Profile of its own depends on what it wants to do: one is required to set net send limits over its respondents' activity, to send or receive any message or report, or to get into the FedNow interface, and a correspondent wanting none of that can operate without a profile. Settling alone does not make it a party to the funds transfer.", "citation": "Operating Circular 8, sections 2.11, 7.4 and 7.6; Operating Procedures v3.6 section 8, p.22", "rests_on": "rule" }, { "label": "Service providers", "value": "A participant may put another entity, which need not itself be a bank, in the driving seat by signing the agreement at Appendix B of Operating Circular 8. Once that is done, a message the service provider initiates, transmits or receives carries exactly the authority and effect it would have had from the participant's own hands, and responsibility stays with the participant throughout. Where the service provider is itself a financial institution it is a Primary Service Provider, and it may run on a Secondary Service Provider's electronic connection instead of its own.", "citation": "Operating Circular 8, sections 2.30, 2.37, 2.38, 15.1, 15.3, 15.6 and 15.13; Operating Procedures v3.6 section 8, p.21", "rests_on": "rule" }, { "label": "Directory", "value": "There is a directory, kept by the Reserve Banks, and what it covers is the instant payment side of the network: a participant appears once it sends or receives Instant Payment Messages, and stays absent while it has not turned those on. The same list reaches participants as an admi.998 and through a Participant List API.", "citation": "Operating Circular 8, section 9.1.18; Operating Procedures v3.6 section 13.1.c, p.55 and Appendix F, p.132", "rests_on": "rule" }, { "label": "Public lists", "value": "The Federal Reserve publishes on frbservices.org a list of participating financial institutions live on the service, a routing transit number list, a settlement agents and liquidity providers list, and a certified service providers list, each dated. The participating institution and routing number lists on that page were dated 2026-09-14 when read.", "citation": "frbservices.org, FedNow Service Participants and Service Providers page, fetched 2026-09-17", "rests_on": "guidance" }, { "label": "How many participants", "value": "Not established here. The count sits in downloadable spreadsheets, and the routing number list is offered only under an access acknowledgement, which the drafter did not accept. No participant count is stated in the page text itself.", "citation": "frbservices.org, FedNow Service Participants and Service Providers page, fetched 2026-09-17", "rests_on": "practice" }, { "label": "Obligations that come with joining", "value": "A participant must keep a compliance programme for sanctions and BSA and AML, screen customers against sanctions lists, meet 24 hour availability, keep staff with the right access roles, hold at least two active signing key pairs at all times, and maintain contacts including a fraud notification contact.", "citation": "Operating Circular 8, sections 3.6, 14.1 and 17.1; Operating Procedures v3.6 section 3.a, p.8, section 7.b Active Key Management, p.19 and section 4.g Contact Management, p.11", "rests_on": "rule" }, { "label": "Losing access", "value": "The Reserve Banks may terminate, restrict or impose conditions on access, including for failure to meet the Operating Circular or applicable law, and may sign off a participant that is unreachable or is harming the network. They may also instruct a service provider to restrict or monitor the participant's connection.", "citation": "Operating Procedures v3.6 section 4, p.9 and section 5.b, p.13; Operating Circular 8, sections 14.3 and 15.7", "rests_on": "rule" } ], "exceptions": [ "A non-bank can be a service provider and can be an On Behalf Of account holder at a participant, sending and receiving instant payments for third parties, but it cannot be a participant.", "A participant that only settles, or only receives liquidity management transfers, never appears in the instant payment directory and cannot be sent a customer credit transfer.", "A service provider is not a sender or a receiving bank under Article 4A for payment orders it handles as agent.", "A branch's identifying number is deemed to be the participant's own for Regulation J, Article 4A and the circular.", "Regulation J currently bars a sender from requiring a Reserve Bank to use an intermediary bank other than a Reserve Bank, which is the legal reason a FedNow transfer has only two banks and a Reserve Bank. A Board proposal published 2026-04-10 would change this. [Unverified] Its status was not established; the Federal Register was not read for this record." ], "applies_to": "FedNow Service participation and the parties to a FedNow funds transfer. United States only.", "caveat": "Eligibility rests on Operating Circular 1, which was not read for this record, so the Account Holder definition is cited rather than restated. The number of live participants is not in this record.", "related": [ "fednow:settlement", "fednow:messages", "fednow:limits" ], "basis": { "sources": "Operating Circular 8 effective 2026-04-01 sections 3, 5, 7, 9.1, 14, 15 and 17, read. FedNow Service Operating Procedures April 2026 version 3.6 public version, sections 3, 4, 5, 7, 8 and Appendix F, read. 12 CFR 210.45(b), read. frbservices.org Participants and Service Providers page, fetched 2026-09-17. Operating Circular 1 not read.", "confidence": "medium" }, "currency": { "effective_since": "2026-04-01", "effective_note": "Operating Circular 8 effective 2026-04-01. Participation lists on frbservices.org are updated regularly and were dated 2026-09-14 when read. A Board proposal of 2026-04-10 on intermediaries in Regulation J would change who may stand between the two banks; its outcome is unknown here.", "source_edition": "Operating Circular 8 effective 2026-04-01; FedNow Service Operating Procedures April 2026 version 3.6 (public version); frbservices.org participant lists dated 2026-09-14", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.frbservices.org/binaries/content/assets/crsocms/resources/rules-regulations/040126-operating-circular-8.pdf", "source_class": "authoritative_primary", "source_title": "Operating Circular 8, Funds Transfers Through the FedNow Service, effective 2026-04-01", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17b", "notes": "Confirms the two-gate eligibility test tied to Operating Circular 1's Account Holder definition (5.1), the domestic originator/beneficiary requirement (9.1.2), the instant-payment-only directory (9.1.18), correspondent and service provider roles and their non-party status when limited to settling or acting as agent (2.11, 2.30, 2.37-2.38, 7.4, 7.6, 15.1, 15.3, 15.6, 15.13), termination and restriction discretion (14.3, 15.7), and participant obligations including sanctions/BSA compliance, availability and key management (3.6, 14.1, 17.1). The frbservices.org FedNow Service Participants and Service Providers page, fetched live 2026-09-17, independently confirms the four public lists (participating institutions, routing numbers, settlement agents and liquidity providers, certified service providers), both the institution and routing-number lists dated 9/14/26, the access-acknowledgement gate on the routing number list, and that no participant count appears on the page." } ] }, "rail_name": "FedNow", "governing_authority": "Federal Reserve", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "fednow:recall", "id": "recall", "rail": "fednow", "kind": "rail-fact", "facet": "recall", "name": "Can a sender cancel or claw back a payment it has sent?", "statement": "No. Once a FedNow payment order has been accepted, the service offers no way to call it back. A Reserve Bank asked to undo or alter a payment order is under no duty to do either, and where it passes the request along, delivering it is the whole of what it owes. Whether the request achieves anything is left to Article 4A section 4A-211 and to what the receiving bank decides. Sending the request can put the sending bank on the hook unless it gives up the indemnity inside the message. A separate cancellation path exists for a request for payment, which is not a payment.", "details": [ { "label": "No duty to cancel", "value": "Ask a Reserve Bank to undo or change a payment order and it owes you nothing, and Article 4A 4A-211 does not put it under a duty either. A request for return, or any other message aimed at cancelling or amending, buys the sender one thing: should the Reserve Bank take that message in, it will carry it to the participant the sender named as its addressee. That is the whole of the obligation.", "citation": "Operating Circular 8, section 9.8.6", "rests_on": "rule" }, { "label": "Whether it works is left to Article 4A", "value": "Delivery settles nothing about effect. Whether a message of that kind actually cancels or amends the payment order sitting with the receiving participant is a question for Article 4A 4A-211, and the circular leaves the answer there in its entirety.", "citation": "Operating Circular 8, section 9.8.6", "rests_on": "rule" }, { "label": "Asking can cost you", "value": "There is a price attached to asking. A participant that sends a request for return, or any other message reaching for a cancellation or an amendment, exposes itself under Article 4A 4A-211, and the way out is to give up the indemnity obligation inside the message itself, using the element the FedNow technical specifications lay down. Those specifications go to participants only.", "citation": "Operating Circular 8, section 9.8.7", "rests_on": "rule" }, { "label": "A warranty claim is expressly not a cancellation", "value": "Put the WarrantyBreach code WNTB on a return request and UCC Article 4A does not see a cancellation request at all. What it sees is a claim one bank makes against another over a request for payment, not an attempt to undo the payment order.", "citation": "Operating Procedures v3.6 section 12.c, p.52", "rests_on": "rule" }, { "label": "The only route back", "value": "The practical route is a return request (camt.056) to the receiving bank, which it may accept, partly accept, reject or hold pending, followed by a fresh payment return if it agrees.", "citation": "Operating Circular 8, section 9.6; Operating Procedures v3.6 section 15.2, pp.91 to 95", "rests_on": "rule" }, { "label": "Both banks must still help", "value": "A nonvalue message flagging an exception, an error, an unauthorised transfer or a rejection, obliges the participant receiving it to work with the participant that sent it: reasonable efforts towards that bank's investigation of what went wrong, and towards putting it right. What that obliges is cooperation, not payment.", "citation": "Operating Circular 8, section 9.8.4", "rests_on": "rule" }, { "label": "No stop before settlement either", "value": "The window in which a payment order exists but has not settled is seconds: the payment timeout clock is 20 seconds and there is no participant facility in the public procedures for withdrawing a message inside it. The Reserve Banks may reject a message for any reason at any point before acceptance, but that is their choice, not the sender's.", "citation": "Operating Procedures v3.6 Appendix C, p.128 and section 15.b, p.79; Operating Circular 8, sections 9.1.1 and 9.2.3", "rests_on": "rule" }, { "label": "A request for payment can be cancelled", "value": "A pain.013 request for payment cannot be amended, but the bank that sent it may withdraw it with a camt.055 as long as no payment has been made against it. The other bank replies by camt.029, perhaps PDCR first while it looks into it, then CNCL to confirm the cancellation or RJCR to refuse; that reply can come straight away or at any point up to the execution date the original request asked for.", "citation": "Operating Procedures v3.6 section 16.1.c, p.103 and Appendix A RFP Cancellation Request Response, pp.124 to 125", "rests_on": "guidance" }, { "label": "The security procedure will not catch your mistake", "value": "The security procedures exist to authenticate, not to audit. They are not used to spot an error in what a message carries or in how it was transmitted, and that holds for a message trying to cancel or amend a payment order as much as for the payment order itself. Nothing in the service is checking whether the payment was the right one.", "citation": "Operating Circular 8, section 8.6", "rests_on": "rule" }, { "label": "Fraud reporting is not recall", "value": "Appendix C makes a participant investigate and then report a reportable transfer, both to the service and to the participant on the other side of it. The Reserve Banks' role stops at carriage: they pass on what they are given, adding nothing to it and judging none of it. A bank that wants the money itself has to go and ask for it in a separate nonvalue message.", "citation": "Operating Circular 8 Appendix C, sections 2.2, 2.3 and 2.4", "rests_on": "rule" } ], "exceptions": [ "A payment the receiving bank answered with accept without posting is not accepted under Article 4A, so it can still be rejected by that bank, which then must promptly initiate a refund payment to the sender. That is the receiver's decision, not a sender cancellation.", "A settled liquidity management transfer is unwound only by a new pacs.009 in the other direction.", "A request for payment cancellation (camt.055) works only while no payment has been made.", "Reporting a reportable transfer is not treated by the Reserve Banks as an objection to a debit to the participant's Settlement Account for Article 4A purposes, and a participant may not report a payment order it did not authorise as a reportable transfer.", "A consumer's right to be made whole by their own bank is separate and can exist where no recall is possible." ], "applies_to": "Attempts by a sending FedNow Participant to undo a payment order it has sent through the service. United States only.", "caveat": "ACH intuition is wrong here in both directions. There is no reversal entry and no deadline by which the receiving bank must give money back. Equally, do not read 'final' as 'gone': the request path exists, the receiving bank often has the money still, and cooperation is required even where payment is not. What the circular refuses is any obligation on the Reserve Banks and any automatic effect.", "related": [ "fednow:return", "fednow:liability", "fednow:refund", "fednow:consumer-law" ], "basis": { "sources": "Operating Circular 8 effective 2026-04-01 sections 8.6, 9.1, 9.2, 9.6, 9.8 and Appendix C, read. FedNow Service Operating Procedures April 2026 version 3.6 public version, sections 12, 15.2, 16.1 and Appendices A and C, read. Article 4A section 4A-211 text not read.", "confidence": "high" }, "currency": { "effective_since": "2026-04-01", "effective_note": "Operating Circular 8 effective 2026-04-01. Section 9.8.6 and 9.8.7 carried the same effect in the edition of 2026-01-05 [Unverified]; the redline was not opened for this record.", "source_edition": "Operating Circular 8 effective 2026-04-01; FedNow Service Operating Procedures April 2026 version 3.6 (public version)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.frbservices.org/binaries/content/assets/crsocms/resources/rules-regulations/040126-operating-circular-8.pdf", "source_class": "authoritative_primary", "source_title": "Operating Circular 8, Funds Transfers Through the FedNow Service, effective 2026-04-01", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17b", "notes": "Confirms no Reserve Bank duty to cancel or amend a payment order, with effect left to Article 4A 4A-211 (9.8.6), indemnity exposure for a cancellation or return request absent a disclaiming element in the technical specifications (9.8.7), that the security procedures authenticate rather than audit message content (8.6), fraud-reporting cooperation duties without Reserve Bank evaluation (Appendix C 2.2-2.4), and the general nonvalue-message cooperation duty (9.8.4). Operating Procedures v3.6 section 12.c confirms a WNTB return request is not a 4A-211 cancellation request, and section 16.1 confirms a pain.013 is withdrawn by camt.055 with a camt.029 PDCR/CNCL/RJCR response, not by amendment." } ] }, "rail_name": "FedNow", "governing_authority": "Federal Reserve", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "fednow:refund", "id": "refund", "rail": "fednow", "kind": "rail-fact", "facet": "refund", "name": "When does money go back without the receiver being asked?", "statement": "FedNow has no general refund right. There is one place where the rules oblige the money to go back on their own: a payment the receiving bank accepted without posting, and then rejected after investigating. There the bank must promptly initiate a refund payment to the sender, and the sender is not excused from paying its Reserve Bank in the meantime. Everything else is either a request the receiving bank may refuse, a warranty claim between the two banks, or a consumer's separate right under Regulation E against their own bank.", "details": [ { "label": "Accept without posting is not acceptance", "value": "ACWP buys the receiving bank time without committing it. Where it answers a request for confirmation with ACWP and the Reserve Bank goes on to accept the payment, being paid is not the same as having accepted: under Article 4A and under the circular alike the receiving bank has accepted nothing. The response is open to it only where it has reasonable cause to think the beneficiary has no entitlement or permission to take the money.", "citation": "Operating Circular 8, sections 9.2.2 and 9.2.5(a); 12 CFR 210.44(b)(3) and its commentary", "rests_on": "law" }, { "label": "The one mandatory refund", "value": "Two outcomes send the money back on their own: the receiving bank rejecting the instant payment message after its ACWP, or that message being cancelled. Either way the duty lands on the receiving bank, and the duty is to get a refund payment moving to the sender without delay. Nowhere else does the circular make money go back unasked.", "citation": "Operating Circular 8, section 9.2.5(c)", "rests_on": "rule" }, { "label": "The deadline for deciding", "value": "Investigate, then reject or accept, and do it by the ACWP Target Deadline. That deadline is midnight Eastern time on the first day after the funds transfer business day in which the ACWP went out that is neither a weekend day nor a holiday the participant itself observes. A bank that still cannot move, because rejecting or accepting might not be permissible under applicable law, owes a pending (PDNG) status by that same deadline and an update once the matter resolves.", "citation": "Operating Circular 8, sections 2.9 and 9.2.5(b) and (e); Operating Procedures v3.6 section 15.d, p.79 and footnote 125", "rests_on": "rule" }, { "label": "The sender still owes its Reserve Bank", "value": "A transfer that never ends in the receiving bank's acceptance does not let the sender off. Article 4A 4A-402(c) notwithstanding, what the sender owes its Administrative Reserve Bank stands, and no Reserve Bank picks up a duty to refund the sender. What the sender gets instead is subrogation: it steps into whatever right the receiving bank's Administrative Reserve Bank has to recover the money from the receiving bank.", "citation": "Operating Circular 8, section 9.2.5(f)", "rests_on": "rule" }, { "label": "A rejection after ACWP is not a reject message", "value": "The money moves back as a refund payment, which is a new value message with its own settlement, timeout clock and network limit check. It is not a reversal of the original entry.", "citation": "Operating Circular 8, section 9.2.5(c); Operating Procedures v3.6 section 15.2.a, p.91", "rests_on": "rule" }, { "label": "Warranty breach is a claim, not a refund right", "value": "A bank that paid against a request for payment and then concludes the RFP warranty was broken can ask for the funds back by camt.056 under code WNTB, with 95 calendar days from settlement to raise it and 20 business days for the bank that sent the RFP to answer. That answer may be a refusal. No Reserve Bank rules on whether a claim holds up, and a dispute left unresolved has to be taken outside the service.", "citation": "Operating Procedures v3.6 section 12.c and 12.d, pp.52 to 54", "rests_on": "rule" }, { "label": "What does not make the money come back", "value": "No payer, payee or customer is given a right to a refund anywhere in the circular or the public procedures, not for a payment sent by mistake, not for goods that never arrived, and not for a payment talked out of someone by deception. Nor does a customer's unhappiness with what was delivered, or with its quality, breach the RFP warranty by itself.", "citation": "Operating Procedures v3.6 section 12.a, p.52; absence of any such right in Operating Circular 8 and the public Operating Procedures", "rests_on": "rule" }, { "label": "The consumer's own path", "value": "A consumer account brings Regulation E with it. Its error resolution and unauthorised transfer rules run against the consumer's own bank, and that bank can be required to make the consumer whole while having no route at all to recover the funds over FedNow. On any point where the Electronic Fund Transfer Act and subpart C conflict, Regulation J puts the Act first.", "citation": "12 CFR 210.40(b)(4) and commentary to 210.40(b) paragraph (4)(i); 12 CFR 1005.11(c)", "rests_on": "law" }, { "label": "Partial return is allowed", "value": "Where a receiving bank does agree to give money back on a return request, it may return the full amount received or a portion of it, answering PECR for a partial execution.", "citation": "Operating Procedures v3.6 section 15.2.a, p.91 and section 15.2.b message table, p.92", "rests_on": "rule" } ], "exceptions": [ "The receiving bank may block rather than refund, for example by holding the amount in a segregated account under applicable law, and must give a final status saying so.", "The ACWP deadline runs on the participant's own observed holidays as well as weekends, which is not the same calendar as the standard business day used for return request responses.", "A liquidity management transfer carries no request for confirmation and no ACWP, so this whole path does not exist for a pacs.009.", "Where an ACWP payment is ultimately accepted, the receiving bank must make funds available to the beneficiary immediately, and no refund arises.", "None of this reaches a payment the consumer authorised and later regrets." ], "applies_to": "FedNow instant payments where the receiving bank answered accept without posting, and request for payment warranty claims between participants. United States only.", "caveat": "This facet is thin on purpose, because the rail is thin here. FedNow has one automatic refund, tied to a compliance hold, and otherwise leaves repayment to a request the holder of the money may refuse. Anyone reading across from SEPA direct debit refund rights or card chargebacks will look for something that does not exist.", "related": [ "fednow:return", "fednow:recall", "fednow:consumer-law" ], "basis": { "sources": "Operating Circular 8 effective 2026-04-01 sections 2.9, 9.2 and 9.6, read. FedNow Service Operating Procedures April 2026 version 3.6 public version, sections 12, 15.d and 15.2, read. 12 CFR 210.40(b)(4), 210.44(b)(3) with commentary, and 12 CFR 1005.11, read from eCFR for 2026-09-01.", "confidence": "medium" }, "currency": { "effective_since": "2026-04-01", "effective_note": "Operating Circular 8 effective 2026-04-01 with Operating Procedures April 2026 version 3.6. The 95 day and 20 business day warranty figures sit in the Operating Procedures and can change between versions.", "source_edition": "Operating Circular 8 effective 2026-04-01; FedNow Service Operating Procedures April 2026 version 3.6 (public version); 12 CFR 210 subpart C and 12 CFR 1005 subpart A as published on eCFR for 2026-09-01", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.frbservices.org/binaries/content/assets/crsocms/resources/rules-regulations/040126-operating-circular-8.pdf", "source_class": "authoritative_primary", "source_title": "Operating Circular 8, Funds Transfers Through the FedNow Service, effective 2026-04-01", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17b", "notes": "Confirms ACWP as the one automatic refund trigger: a post-ACWP rejection or cancellation obliges the receiving bank to promptly initiate a refund payment (9.2.5(c)), the ACWP Target Deadline and PDNG status for a bank that cannot yet act (9.2.5(b),(e)), and that the sender's obligation to its Reserve Bank survives with subrogation rather than a Reserve Bank refund duty (9.2.5(f)). Confirms a rejection after ACWP moves as a new value message, not a reversal (9.2.5(c), 9.6). Operating Procedures v3.6 section 12.c-d confirms the WNTB warranty-claim path is a refusable request with a 95-day/20-business-day clock, not a refund right, and 12 CFR 210.44(b)(3) with commentary, read from eCFR for 2026-09-01, confirms the reasonable-cause standard for ACWP." } ] }, "rail_name": "FedNow", "governing_authority": "Federal Reserve", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "fednow:return", "id": "return", "rail": "fednow", "kind": "rail-fact", "facet": "return", "name": "How does money come back, and on whose say so?", "statement": "There is no reversal on this rail. Money comes back only as a fresh payment, sent by the bank that holds it, because it chose to send it. The sending bank may ask, with a return request (camt.056), within 60 days of settlement. The receiving bank answers accepted, partly accepted, rejected or pending, and if it agrees it sends a payment return (pacs.004) which is itself a new value message with its own timeout clock. The receiving bank may also return without being asked, for example when it cannot apply the funds. Nothing here is a right to be repaid, and the ACH habit of a return by deadline does not transfer.", "details": [ { "label": "The mechanism", "value": "Returning money means originating a fresh funds transfer over the service, which is the route the circular tells a participant to take, though it leaves room for any other reasonable way of getting the funds back. Either way the original payment order has to be referenced in the return, in the form the operating procedures and technical specifications call for.", "citation": "Operating Circular 8, section 9.6", "rests_on": "rule" }, { "label": "Return request window", "value": "Sixty calendar days, counted from the settlement of the original pacs.008, is the guideline for getting a camt.056 out. It sits in the Operating Procedures rather than in the circular, and the Operating Procedures put it as what a participant should do, not what it must.", "citation": "Operating Procedures v3.6 section 15.2.a, p.91, section 15.2.b Response Time, p.93 and Appendix A, p.123", "rests_on": "guidance" }, { "label": "Two windows do not take the 60 days", "value": "Two uses of the camt.056 fall outside that guideline altogether: reporting fraud, with code FRAD, and claiming a breach of the request for payment warranty, with code WNTB. The warranty claim answers to a deadline of its own, 95 calendar days from settlement of the underlying credit transfer, and that one the text puts as a must.", "citation": "Operating Procedures v3.6 section 15.2.a footnote 144, p.91, section 15.2.b, p.92 and section 12.d, p.53", "rests_on": "rule" }, { "label": "Answering a return request", "value": "The receiving bank replies by camt.029 under one of four codes: IPAY, the request is accepted and the funds are coming back; PECR, part of it is; RJCR, refused and nothing is coming back; PDCR, held while it investigates. A final answer is due as soon as it can be given and in any case before midnight ET on the following standard business day. Where the first answer was PDCR, the IPAY, PECR or RJCR that closes it out is due once the investigation ends, or 10 standard business days after the camt.056 arrived, whichever comes sooner.", "citation": "Operating Procedures v3.6 section 15.2.b Response Time, pp.92 to 93 and Appendix A, p.123", "rests_on": "guidance" }, { "label": "Warranty claims answer on a different clock", "value": "A WNTB claim puts 20 business days from receipt of the camt.056 on the bank that sent the request for payment. It can accept, which means a camt.029 with IPAY plus the funds back by pacs.004 or outside the service, or it can reject with RJCR, in which case it has to say why the warranty was not breached, or show that it has already made the other bank whole for the full amount.", "citation": "Operating Procedures v3.6 section 12.d, p.54", "rests_on": "rule" }, { "label": "The return itself is a payment", "value": "Once a pacs.004 is on its way it is treated exactly as a pacs.008 would be from end to end: the 20 second timeout clock, the receiving bank's reserved response time, negative list and the rest of the business validations, and a settlement of its own with finality. The amount can be all of what was received or only part of it.", "citation": "Operating Procedures v3.6 section 15.2.a, p.91 and section 15.2.d, p.96", "rests_on": "rule" }, { "label": "A return needs no request", "value": "Nothing obliges a bank to wait for a camt.056 before sending money back. A participant that finds it cannot apply funds it received may originate the return on its own, which is what happens when it rejects a payment it had earlier answered with accept without posting.", "citation": "Operating Procedures v3.6 section 15.2.a and 15.2.b message table, pp.91 to 92; Operating Circular 8, section 9.2.5(c)", "rests_on": "rule" }, { "label": "Value limit on a return", "value": "A pacs.004 is validated against the 10,000,000 dollar network limit and not against the returning participant's own lower configured limit.", "citation": "Operating Procedures v3.6 section 15.2.b Payment Return Value Limit Validation, p.92", "rests_on": "rule" }, { "label": "Who may send a return", "value": "The participant's profile must carry Credit Transfer Receive Only or Credit Transfer Send and Receive, or, for returning an LMT, LMT Send and Receive. Under the messaging chart, camt.056 is optional to send for a Receive Only participant and mandatory for the others.", "citation": "Operating Procedures v3.6 section 15.2.b Eligible FedNow Service Participation Types, p.91 and Appendix F Table 1, p.131", "rests_on": "rule" }, { "label": "Fraud codes ride the same messages", "value": "Fraud is reported through the return machinery rather than a channel of its own. A bank that sent a payment and afterwards works out it was fraud raises a camt.056 carrying FRAD; a bank that spots fraud in a payment it received originates a pacs.004 carrying FR01. Either one discharges the FedNow fraud reporting requirement, and neither is held to the 60 day guideline.", "citation": "Operating Procedures v3.6 section 15.2.b Fraud Reporting with Return Request and Payment Return, p.92", "rests_on": "rule" }, { "label": "Liquidity transfers return differently", "value": "Send a settled liquidity management transfer back with another pacs.009, never with a pacs.004, and point at the original through the end to end reference or the remittance information.", "citation": "Operating Procedures v3.6 section 15.2.a and 15.2.b message table, pp.91 to 92", "rests_on": "rule" }, { "label": "If there is no answer", "value": "Where the receipt acknowledgement (admi.007) came back but no camt.029 has followed it by midnight ET on the following standard business day, the requesting bank may put out another return request. Where even the admi.007 never arrived, the camt.056 itself should go again.", "citation": "Operating Procedures v3.6 section 15.2.c Response Stage, pp.94 to 95", "rests_on": "guidance" } ], "exceptions": [ "A return request is a request. The receiving bank may reject it with RJCR, and the money then stays where it is.", "Where a camt.056 fails business validation, the negative return request response comes from the FedNow Service itself rather than from the receiving bank.", "Where a camt.056 is not enabled on a participant's profile, it contacts the Support Center for an alternative means of seeking a return of funds.", "A return may also be made outside the FedNow Service, although returns of FedNow funds are expected to go back through FedNow for reconciliation.", "If the dispute is not resolved by this process, it must be taken outside the service; the Reserve Banks make no determination on the sufficiency of a claim.", "None of this is a consumer remedy. A consumer's own claim against their bank runs under Regulation E." ], "applies_to": "Returning a settled FedNow customer credit transfer or liquidity management transfer, between participants. It is not a right of the payer, the payee or any customer.", "caveat": "The response deadlines above come from the Operating Procedures tables, which say the guidelines are strongly recommended rather than required, except where the text says must, as for the 95 day warranty claim and the 20 business day warranty response. The record says which is which because the schema has no field for it. The permitted reason codes for camt.056, camt.029 and pacs.004 are not public beyond FRAD, WNTB and FR01; the lists sit on MyStandards and in the redacted Appendix D.", "related": [ "fednow:limits", "fednow:messages", "fednow:liability", "fednow:recall", "fednow:consumer-law" ], "basis": { "sources": "FedNow Service Operating Procedures April 2026 version 3.6, public version, sections 12, 15.2 and Appendix A, read. Operating Circular 8 effective 2026-04-01 sections 9.2.5, 9.6 and 9.8, read.", "confidence": "high" }, "currency": { "effective_since": "2026-04-01", "effective_note": "Operating Circular 8 effective 2026-04-01 with Operating Procedures April 2026 version 3.6. The windows and response times sit in the Operating Procedures, which the Reserve Banks may change at any time with an aim of 30 days' notice for material changes, so they move faster than the circular.", "source_edition": "Operating Circular 8 effective 2026-04-01; FedNow Service Operating Procedures April 2026 version 3.6 (public version)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.frbservices.org/binaries/content/assets/crsocms/resources/rules-regulations/042826-fednow-service-operating-procedures.pdf", "source_class": "authoritative_primary", "source_title": "FedNow Service Operating Procedures, April 2026, version 3.6 (public version, file dated 2026-04-28)", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17b", "notes": "Confirms the 60 calendar day return-request guideline and its footnote excluding FRAD and WNTB (section 15.2.a), the camt.029 response codes IPAY/RJCR/PDCR/PECR and the midnight-next-standard-business-day response guidance (section 15.2.b), the WNTB 95-calendar-day and 20-business-day clocks (section 12.c-d), that a pacs.004 is checked only against the network limit (section 15.2.b), the fraud codes FRAD/FR01 riding the return machinery outside the 60-day guideline (section 15.2.b), LMT returning by a new pacs.009 (section 15.2.a-b), and eligible participation types by the Appendix F messaging chart. Operating Circular 8 section 9.6 independently confirms a return is a fresh funds transfer with no reversal entry." } ] }, "rail_name": "FedNow", "governing_authority": "Federal Reserve", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "fednow:settlement", "id": "settlement", "rail": "fednow", "kind": "rail-fact", "facet": "settlement", "name": "How does a FedNow payment settle, and between whom?", "statement": "FedNow is real-time gross settlement. Each payment settles on its own, one at a time, by a debit and a credit on the books of a Federal Reserve Bank. There is no net position, no settlement window and no prefunded pool. The two banks settle in Reserve Bank Master Accounts, their own or a correspondent's, and the Reserve Banks are parties to the transfer rather than a clearing layer above it.", "details": [ { "label": "Settlement model", "value": "Real-time gross settlement, with clearing built into the same step rather than run before it, available 24x7x365. A payment discharges what one bank owes another by the Reserve Banks posting entries against the two banks' Master Accounts at the Federal Reserve.", "citation": "FedNow Service Operating Procedures, April 2026 v3.6 (public version), section 2 Introduction, p.6", "rests_on": "rule" }, { "label": "What settles", "value": "Three message types move money: the customer credit transfer (pacs.008), the payment return (pacs.004) and the liquidity management transfer (pacs.009). Everything else the service carries is a nonvalue message, which moves information rather than funds and leaves no accounting entry anywhere in the Reserve Banks' books.", "citation": "Operating Circular 8, effective 2026-04-01, sections 2.29 and 9.8.1; Operating Procedures v3.6 section 1, p.6 (Value Message definition)", "rests_on": "rule" }, { "label": "The settlement entry", "value": "Acceptance of a payment order sets off four things at once. The amount leaves the sender's Settlement Account, the identical amount lands in the receiver's Settlement Account, an Acknowledgment goes back to the sender, and an Advice of Credit goes out to the receiver.", "citation": "Operating Circular 8, section 9.1.14", "rests_on": "rule" }, { "label": "When settlement is final", "value": "Two events can make settlement final and whichever happens first is the one that counts: the service posting the debit and the credit, or the service issuing the Advice of Credit. Neither the arrival of the entry in some other Reserve Bank system nor the participant's ability to see its balance move has any bearing, because by then it is already final.", "citation": "Operating Circular 8, section 7.1; Operating Procedures v3.6 section 4.a Settlement, p.9", "rests_on": "rule" }, { "label": "Where the money sits", "value": "Settlement runs through a Settlement Account, meaning a Master Account at a Reserve Bank that the participant nominates for the purpose. A participant holding its own Master Account settles there by default, and the only way to sit elsewhere is to nominate an account a correspondent maintains and keep that nomination in force. One account at a time, its own or a single correspondent's, and the service checks the relationship as each transaction settles.", "citation": "Operating Circular 8, sections 2.39, 7.3 and 7.4; Operating Procedures v3.6 section 4.a, p.9", "rests_on": "rule" }, { "label": "No prefunding, but funds must be there", "value": "[Inference] Nothing in the public texts read sets up a prefunded pool or a collateral account for FedNow; settlement draws on the Master Account balance itself. Funds of the required quality, actually and collected, have to be sitting in the Settlement Account before anything can settle, which is what Federal Reserve policy, including the Policy on Payment System Risk, demands of the participant. A sender has no right to an overdraft, and the Reserve Banks may reject a value message that the balance or the overdraft capacity will not carry.", "citation": "Operating Circular 8, sections 7.8 and 7.9; 12 CFR 210.43(b)(1); Operating Procedures v3.6 section 4.b Account Balance Management, p.9", "rests_on": "rule" }, { "label": "Who the parties are", "value": "Whichever Reserve Bank happens to run the connection or carry the account, each participant is treated as dealing only with its own Administrative Reserve Bank: the sender's order counts as sent to that bank, and the receiver's Advice of Credit counts as coming from its own. No other Reserve Bank is a party to the transfer in any way, intermediary bank included, and a correspondent confined to settling for another participant or to acting as a Service Provider is not a party either.", "citation": "Operating Circular 8, sections 6.1, 6.2, 6.3 and 7.6; 12 CFR 210.40(b)(3)", "rests_on": "law" }, { "label": "No intermediary bank other than a Reserve Bank", "value": "The only institution a Reserve Bank will pass a payment order onward to is another Reserve Bank, so an order that would put any other intermediary bank in the chain must not be sent at all. Where a transfer crosses districts, the Reserve Bank is directed to execute through a fellow Reserve Bank.", "citation": "12 CFR 210.45(b); Operating Circular 8, section 4.1", "rests_on": "law" }, { "label": "Settlement date is the cycle day, not the calendar day", "value": "Dates here are accounting dates, not clock dates. The FedNow Service Funds Transfer Business Day turns over at approximately 7:01 p.m. ET, and from that turn until midnight ET the cycle day and the calendar date are two different dates; settlement dates follow the cycle day. A payment settling just after rollover carries the next cycle day.", "citation": "Operating Procedures v3.6 section 6.a, p.15; Operating Circular 8, sections 11.1 and 11.2", "rests_on": "rule" }, { "label": "Reporting lags settlement", "value": "A balance report can trail actual FedNow activity by as much as a minute, and from cycle day rollover until roughly 9 p.m. ET the balance shown may still be provisional. Neither lag reaches the payments themselves, which are settled and final in real time.", "citation": "Operating Procedures v3.6 Appendix B Support, p.126; section 6.b, p.16", "rests_on": "guidance" } ], "exceptions": [ "A liquidity management transfer (pacs.009) settles the same way but only inside the LMT window and only to support liquidity needs of instant payment activity, including moves to or from a Joint Account standing behind an instant payment system run in the private sector. [Inference] The circular does not name which private sector system.", "A correspondent that only settles for a respondent, and does not send or receive messages, is not a party to the funds transfer and may hold no FedNow profile at all.", "A Reserve Bank may recover an amount owed by debiting the participant's Master Account without prior notice, including where a correspondent did not settle in finally collected funds.", "Settlement Only is a distinct participation type for a correspondent that wants reporting and net send limits without sending or receiving payments." ], "applies_to": "All FedNow Service value messages between FedNow Participants settling in Reserve Bank Master Accounts. United States only.", "caveat": "The public Operating Procedures redact Appendix D (error and warning codes), Appendix E (test cases) and Appendix G (service level expectations), so the codes a participant sees when settlement is refused are not public. The mechanics above are complete from the public text; the reject reasons are not.", "related": [ "fednow:hours", "fednow:finality" ], "basis": { "sources": "Federal Reserve Banks Operating Circular 8 effective 2026-04-01, read in full. FedNow Service Operating Procedures April 2026 version 3.6, public version, sections 2, 4, 6 and Appendix B, read. 12 CFR 210 subpart C, read from eCFR.", "confidence": "high" }, "currency": { "effective_since": "2026-04-01", "effective_note": "Operating Circular 8 effective 2026-04-01 supersedes the edition of 2026-01-05. The Reserve Banks may amend it at any time without prior notice (OC8 22.1), and the Operating Procedures may change at any time with an aim of 30 days' notice for material changes (OP p.6).", "source_edition": "Operating Circular 8 effective 2026-04-01; FedNow Service Operating Procedures April 2026 version 3.6 (public version, file dated 2026-04-28); 12 CFR 210 subpart C as published on eCFR for 2026-09-01", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.frbservices.org/binaries/content/assets/crsocms/resources/rules-regulations/040126-operating-circular-8.pdf", "source_class": "authoritative_primary", "source_title": "Operating Circular 8, Funds Transfers Through the FedNow Service, effective 2026-04-01", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17b", "notes": "Confirms real-time gross settlement finality at the earlier of ledger entry or Advice of Credit, regardless of other systems or visibility (7.1), the four-part settlement entry on acceptance (9.1.14), Settlement Account designation through a Master Account or a correspondent's account (7.3-7.4), the funded-balance requirement with no overdraft right and Reserve Bank recovery without prior notice (7.7-7.9), that a correspondent confined to settling or acting as service provider is not a party (7.6), the no-intermediary-bank rule (4.1), and that dates follow the cycle day rather than the calendar day (11.1-11.2). Operating Procedures v3.6 section 2 confirms the settlement-model description, and section 6.a confirms cycle day rollover mechanics; the live frbservices.org FedNow Service Operating Hours page confirms the approximately 7:01 p.m. ET rollover figure more precisely than section 6.a alone, resolving the open question logged for this line." } ] }, "rail_name": "FedNow", "governing_authority": "Federal Reserve", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "gcc-afaq:consumer-law", "id": "consumer-law", "rail": "gcc-afaq", "kind": "rail-fact", "facet": "consumer-law", "name": "What protects the customers who send and receive AFAQ payments?", "statement": "No GCC-wide consumer law for AFAQ was found; customers are protected by the rules of their own country, and only Saudi Arabia's AFAQ texts were read. For customers of Saudi banks, SAMA's AFAQ texts give four protections that matter to a customer: the fee a bank charges for an AFAQ transfer may not exceed the maximum SAMA allows for cross-border transfers in its banking tariff; no FX margin may be added to the central banks' rate; the receiving bank must credit a correctly addressed payment the same day; and a payment the receiving bank cannot credit comes back in full at the original rate. Complaints between parties under these rules can be taken to SAMA.", "details": [ { "label": "Fee cap", "value": "SAMA urges Saudi banks to keep AFAQ customer fees low and competitive, and forbids a fee for sending an AFAQ transfer above the maximum its banking tariff allows for cross-border transfers. The tariff itself was not read, so the figure is not given here.", "citation": "SAMA, Charging Policy for Cross Currency Payments Using AFAQ Service, circular 43038107 of 2021-12-02 (1443-04-27 H), section 7", "rests_on": "rule" }, { "label": "No FX margin", "value": "Because the central banks guarantee the day's rate and banks carry no currency risk or foreign funding cost, SAMA bars participants from applying any FX margin to AFAQ payments.", "citation": "CP 43038107 section 6", "rests_on": "rule" }, { "label": "Same-day credit", "value": "Where the account number matches the named beneficiary, the receiving Saudi participant must credit the beneficiary with same-day value as soon as possible and at the latest by the end of the business cycle, and must give the value to the right person.", "citation": "SAMA, Operating Rules for Cross Currency Payments using AFAQ Service, circular 42068309 of 2021-05-05 (1442-09-24 H), sections 7.6 and 7.7", "rests_on": "rule" }, { "label": "Full return when a payment cannot be credited", "value": "A payment that cannot be credited is returned at the original rate and amounts with no deduction, so exchange movements and charges do not eat into it on the way back.", "citation": "OR 42068309 sections 7.8 and 7.9; GPC, AFAQ FAQs, Exchange Rates (read 2026-09-18)", "rests_on": "rule" }, { "label": "Who AFAQ serves", "value": "GPC names individual citizens and residents of the GCC states, retail businesses and corporate and wholesale clients as AFAQ's beneficiaries. SAMA limits use to genuine needs of non-bank clients, including consumer payments and remittances.", "citation": "GPC, AFAQ FAQs, Participants and Beneficiaries (read 2026-09-18); OR 42068309 section 7.1.1", "rests_on": "guidance" }, { "label": "Where to complain", "value": "Anyone left with an unsettled claim or dispute under SAMA's AFAQ rules can take it to SAMA, and Saudi law governs those rules. Whether a bank customer counts as a party who can use this route is not spelled out [Inference: the wording is not limited to participants].", "citation": "OR 42068309 sections 8.6 and 8.8", "rests_on": "rule" } ], "exceptions": [ "Customers of banks in the UAE, Bahrain, Oman, Qatar and Kuwait are covered by their own central bank's consumer and tariff rules, none of which was read.", "SAMA's general consumer protection rules and banking tariff apply to Saudi bank customers alongside these AFAQ texts; they were not read for this fact [Unverified].", "A receiving bank abroad may apply its own charges to the beneficiary; the no-deduction rule read covers returns, not incoming credits [Inference]." ], "applies_to": "Customers of Saudi banks that send or receive AFAQ cross-currency payments; nothing here is a GCC-wide rule", "caveat": "Say which country's rules you are applying. The no-FX-margin rule and fee cap are SAMA's for Saudi banks; do not assume another GCC central bank has the same.", "related": [ "gcc-afaq:refund", "gcc-afaq:liability", "gcc-afaq:return", "gcc-afaq:participants" ], "basis": { "sources": "SAMA rulebook portal, English pages read 2026-09-18: Charging Policy circular 43038107 (2021-12-02), sections 6 and 7; Operating Rules circular 42068309 (2021-05-05), sections 7.1, 7.6 to 7.9, 8.6 and 8.8 (public_primary; the portal denies legal effect). GPC AFAQ FAQs, read 2026-09-18. SAMA's banking tariff and consumer protection rules and all other GCC countries' consumer rules were not read. Nothing is quoted. Low because only one country's AFAQ texts were read and general consumer law was not.", "confidence": "low" }, "currency": { "effective_since": "2021-12-02", "effective_note": "Dated from the charging policy, circular 43038107 (2021-12-02, 1443-04-27 H), which carries the fee cap and FX margin bar; the credit and return rules date from circular 42068309 (2021-05-05). Both In-Force on 2026-09-18.", "source_edition": "CP 43038107 (2021-12-02); OR 42068309 (2021-05-05); GPC FAQs as read 2026-09-18", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://rulebook.sama.gov.sa/en/charging-policy-cross-currency-payments-using-afaq-service", "source_class": "public_primary", "source_title": "Charging Policy for Cross Currency Payments Using AFAQ Service (SAMA circular 43038107)", "checked_on": "2026-09-19", "checked_by": "gcc-afaq validator session", "notes": "Confirms the fee cap tied to SAMA's Banking Tariff for cross-border transfers (CP 7) and the bar on any FX margin (CP 6), matching the record's two SAMA-sourced consumer protections." }, { "source_url": "https://rulebook.sama.gov.sa/en/operating-rules-cross-currency-payments-using-afaq-service", "source_class": "public_primary", "source_title": "Operating Rules for Cross Currency Payments using AFAQ Service (SAMA circular 42068309)", "checked_on": "2026-09-19", "checked_by": "gcc-afaq validator session", "notes": "Confirms the same-day credit duty to the correctly named beneficiary (OR 7.6, 7.7), the full no-deduction return on an uncreditable payment (OR 7.8, 7.9), the genuine-client-needs limit on eligible clients (OR 7.1.1), and the dispute route to SAMA under Saudi law (OR 8.6, 8.8)." }, { "source_url": "https://www.gulf-payments.com/en/faqs/", "source_class": "public_primary", "source_title": "Gulf Payments Company, AFAQ FAQs", "checked_on": "2026-09-19", "checked_by": "gcc-afaq validator session", "notes": "Confirms the return payment's same exchange rate and amounts with no deductions, and lists individuals, retail businesses, and corporate and wholesale clients as AFAQ's beneficiaries." } ] }, "rail_name": "GCC AFAQ (cross-currency payments)", "governing_authority": "SAMA (Saudi participant rules); GCC central banks via GPC (system)", "snapshot": "2026-09-18", "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "gcc-afaq:decision-points", "id": "decision-points", "rail": "gcc-afaq", "kind": "rail-fact", "facet": "decision-points", "name": "Where do AFAQ's rules leave a decision to a bank, a central bank or the operator?", "statement": "Most of an AFAQ payment's path is automatic: rate checks, calendar checks and routing either pass or produce a rejection code. The human decisions sit at a few points. Each morning every central bank approves or declines the day's exchange rates, and an unapproved pair cannot be used. SAMA decides which Saudi banks join, stay or leave, which days are business days, whether to extend the cut-off, restrict payment types or close the service, and it hears disputes. The receiving bank decides that a payment cannot be credited and must be returned, and judges whether a missing or wrong IBAN is a reason to refuse. The sending bank must judge that each payment serves a genuine client need and is not arbitrage. And a gateway operator decides whether to send back a payment it could not hand to its domestic RTGS.", "details": [ { "label": "Central banks: the day's rates", "value": "Each central bank sends its currency's official dollar rate, receives the computed cross-rates, and approves or declines them. If it neither approves nor declines, the rate stays unconfirmed and payments in that pair are blocked for the day.", "citation": "SAMA, Operating Rules for Cross Currency Payments using AFAQ Service, circular 42068309 of 2021-05-05 (1442-09-24 H), section 5.1 items 2 and 3", "rests_on": "rule" }, { "label": "SAMA: membership", "value": "SAMA admits Saudi participants when in its opinion they meet its criteria, may suspend or terminate one in its discretion on the grounds its rules list, and must consent in writing before a participant withdraws.", "citation": "OR 42068309 sections 3.1 to 3.3", "rests_on": "rule" }, { "label": "SAMA: the calendar and the clock", "value": "SAMA declares which days are AFAQ business days for its participants and may switch a day either way, manages the cut-off, may limit transaction categories at points in the day, may close the service when it thinks fit, and in an emergency directs how transactions are handled, including extending hours or moving to contingency facilities. A participant may ask for a cut-off extension, which SAMA approves or refuses.", "citation": "OR 42068309 sections 5.2 and 5.4 to 5.6, and 8.3; SAMA, Charging Policy for Cross Currency Payments Using AFAQ Service, circular 43038107 of 2021-12-02 (1443-04-27 H), section 4.1", "rests_on": "rule" }, { "label": "Receiving bank: credit or return", "value": "The receiving participant decides whether the payment can be credited to the beneficiary named; if not, it returns it, unless SAMA directs otherwise. Where a customer payment to an IBAN country lacks a valid IBAN, the rules say this may justify rejection or return, which leaves the call to the receiving side.", "citation": "OR 42068309 sections 7.6, 7.8 and 7.12", "rests_on": "rule" }, { "label": "Sending bank: genuine need", "value": "The sending participant must ensure each AFAQ payment meets a genuine need of a non-bank client and must keep controls against arbitrage or speculation on the fixed rate, which requires it to judge its customers' purpose.", "citation": "OR 42068309 section 7.1", "rests_on": "rule" }, { "label": "Gateway operator: undeliverable payments", "value": "At the end of the day the Central Component automatically returns payments it could not deliver to the receiving gateway, but a gateway does not automatically return payments it could not pass to its domestic RTGS; that is left to the gateway operator.", "citation": "OR 42068309 section 5.1 item 8", "rests_on": "rule" }, { "label": "Sending central bank: missing confirmations", "value": "If no completion confirmation has come back ten minutes after the sending gateway sent a payment, and the payment was neither returned nor rejected, the sending central bank starts enquiries with GPC. Every payment must be confirmed before the end-of-day process starts.", "citation": "OR 42068309 section 7.5", "rests_on": "rule" }, { "label": "SAMA: disputes", "value": "Unresolved disputes and claims under SAMA's AFAQ rules may be submitted to SAMA.", "citation": "OR 42068309 section 8.6", "rests_on": "rule" } ], "exceptions": [ "Other central banks make the membership, calendar and dispute decisions for their own participants; their rules were not read.", "Whether the GPC Board also approves each participant, as GPC's 2023 interview says, and how that interacts with SAMA's admission power, is not settled by any public rule read [Inference]." ], "applies_to": "AFAQ cross-currency payments involving Saudi direct participants; the rate approval and gateway points apply to every central bank", "caveat": "This is Orca's reading of where SAMA's rules leave judgment open, each point tied to a section. It is not a complete list of what the non-public controlled documents may add.", "related": [ "gcc-afaq:participants", "gcc-afaq:hours", "gcc-afaq:return", "gcc-afaq:limits", "gcc-afaq-reject:RJ11", "gcc-afaq-reject:RJ10" ], "basis": { "sources": "SAMA rulebook portal, English pages read 2026-09-18: Operating Rules circular 42068309 (2021-05-05), sections 3.1 to 3.3, 5.1, 5.2, 5.4 to 5.6, 7.1, 7.5, 7.6, 7.8, 7.12, 8.3 and 8.6; Charging Policy circular 43038107 (2021-12-02), section 4.1 (public_primary; the portal denies legal effect). GPC 2023 interview reprint, read 2026-09-18. The GPC Operating Rules and Regulations were not used. Nothing is quoted. The decision-points facet caps at medium.", "confidence": "medium" }, "currency": { "effective_since": "2021-05-05", "effective_note": "Dated from SAMA circular 42068309 (2021-05-05, 1442-09-24 H), In-Force with no later version on 2026-09-18; the cut-off extension procedure from circular 43038107 (2021-12-02).", "source_edition": "OR 42068309 (2021-05-05); CP 43038107 (2021-12-02)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://rulebook.sama.gov.sa/en/operating-rules-cross-currency-payments-using-afaq-service", "source_class": "public_primary", "source_title": "Operating Rules for Cross Currency Payments using AFAQ Service (SAMA circular 42068309)", "checked_on": "2026-09-19", "checked_by": "gcc-afaq validator session", "notes": "Confirms each daily rate approval or decline step (OR 5.1 items 2 and 3), SAMA's admission, suspension and termination discretion (OR 3.1 to 3.3), SAMA's calendar, cut-off and closure powers plus cut-off extension by request (OR 5.2, 5.4 to 5.6, 8.3), the receiving bank's credit-or-return and IBAN judgment (OR 7.6, 7.8, 7.12), the sending bank's genuine-need duty (OR 7.1), the gateway operator's discretion on undeliverable payments (OR 5.1 item 8), the sending NCB's ten-minute enquiry trigger (OR 7.5), and the SAMA dispute route (OR 8.6)." }, { "source_url": "https://rulebook.sama.gov.sa/en/charging-policy-cross-currency-payments-using-afaq-service", "source_class": "public_primary", "source_title": "Charging Policy for Cross Currency Payments Using AFAQ Service (SAMA circular 43038107)", "checked_on": "2026-09-19", "checked_by": "gcc-afaq validator session", "notes": "Confirms the cut-off extension request and approval process and its SAR 25,000 per 30 minutes fee (CP 4.1)." }, { "source_url": "https://www.gulf-payments.com/en/gpc_news/facilitating-cross-border-payments-in-gcc/", "source_class": "public_primary", "source_title": "Gulf Payments Company, Facilitating cross-border payments in GCC (interview reprint, 2023-06-19)", "checked_on": "2026-09-19", "checked_by": "gcc-afaq validator session", "notes": "Confirms participants must comply with legal, technical and operational requirements prior to being approved for participation by the GPC Board, supporting the record's exception on how GPC Board approval and SAMA's admission power may both apply." } ] }, "rail_name": "GCC AFAQ (cross-currency payments)", "governing_authority": "SAMA (Saudi participant rules); GCC central banks via GPC (system)", "snapshot": "2026-09-18", "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "gcc-afaq:finality", "id": "finality", "rail": "gcc-afaq", "kind": "rail-fact", "facet": "finality", "name": "When does an AFAQ payment become final, and can it be reversed?", "statement": "For a Saudi direct participant, SAMA's AFAQ rules fix the moment of finality at the debit of the sending participant's account: from then on the payment is final and irrevocable, and the sender can neither cancel nor recall it. Under the model SAMA uses, the debit to the sender and the credit on the receiving side are booked together in the AFAQ Central Component, so there is no gap between them. Two layers must be kept apart. Between banks, each payment settles gross and final as it is booked; between the six central banks, the day's positions are netted and settled once, at the end of the day. Money can still come back after finality, but only as a separate return payment, never by unwinding the original.", "details": [ { "label": "The moment of finality", "value": "SAMA's rules make a payment final and irrevocable as soon as the sending direct participant's account is debited, and bar any cancellation or recall of a payment once that debit has happened.", "citation": "SAMA, Operating Rules for Cross Currency Payments using AFAQ Service, circular 42068309 of 2021-05-05 (1442-09-24 H), sections 7.13 and 7.14", "rests_on": "rule" }, { "label": "Debit and credit post together", "value": "SAMA runs its domestic RTGS functions for AFAQ inside the Central Component (its Country Specific Model). For a payment leaving Saudi Arabia, the Central Component debits the sending participant's settlement account and credits the receiving country's central bank shadow account, and books the matching entries in the receiving currency; the rules say both sets of entries are posted at the same moment. For a payment arriving in Saudi Arabia, the credit lands on the receiving participant's settlement account in the same way.", "citation": "OR 42068309 sections 4.1.7, 4.2 and 7.3", "rests_on": "rule" }, { "label": "The operator's description", "value": "The Gulf Payments Company describes an AFAQ transfer as final at once, on the debit and the matching credit in the central bank accounts, and markets same-day settlement finality and irrevocability as a feature of the system.", "citation": "GPC, Facilitating cross-border payments in GCC (interview reprint, 2023-06-19); GPC, Our Services page, AFAQ System Business Model (read 2026-09-18)", "rests_on": "guidance" }, { "label": "Completion on the receiving side", "value": "A payment counts as completed, for the confirmation sent back to the sender, once the receiving country's domestic RTGS has validated and accepted it for passing to the receiving participant. What happens after that inside the receiving country follows that country's own RTGS rules.", "citation": "OR 42068309 sections 7.4 and 7.5", "rests_on": "rule" }, { "label": "Central bank layer", "value": "The day's positions between central banks are reported, reconciled, confirmed and then settled in an end-of-day net settlement window through a settlement agent. This netting sits under the gross, already-final settlement between participants and does not reopen individual payments [Inference: no public text says a failed net settlement unwinds participant payments].", "citation": "OR 42068309 section 5.1 items 9 to 11; GPC, Working Hours and Official Holidays page (read 2026-09-18)", "rests_on": "rule" } ], "exceptions": [ "A payment the Central Component cannot deliver to the receiving country's gateway by the end of the day is sent back to the sender automatically as a return payment; the original debit is not undone (OR 42068309 section 5.1 item 8).", "A receiving participant that cannot credit the beneficiary returns the funds as a new return payment, normally within two joint business days (OR 42068309 sections 7.8 and 7.9).", "Participants in the other five GCC countries book through their own central bank's domestic RTGS, whose rules on finality were not read; the moment may be described differently there.", "Whether any GCC law designates AFAQ as a system whose finality is protected in insolvency was not found." ], "applies_to": "AFAQ cross-currency payments sent or received by Saudi direct participants under SAMA's Country Specific Model; the operator statement covers the system as a whole", "caveat": "Do not call AFAQ a net or deferred settlement system: participant payments settle gross and final one by one, and only the central banks net at day end. And do not read 'final' as 'the money cannot come back'; returns are a separate payment.", "related": [ "gcc-afaq:settlement", "gcc-afaq:recall", "gcc-afaq:return", "gcc-afaq:refund", "gcc-afaq-reject:RJ13" ], "basis": { "sources": "SAMA rulebook portal, English page read 2026-09-18: Operating Rules for Cross Currency Payments using AFAQ Service, circular 42068309 (2021-05-05), sections 4.1.7, 4.2, 5.1, 7.3 to 7.5, 7.8, 7.9, 7.13 and 7.14. The portal says its pages carry no legal effect, so the class is public_primary. Gulf Payments Company pages read 2026-09-18: Our Services, Working Hours and Official Holidays, and the 2023 interview reprint. The GPC Operating Rules and Regulations were not used. Nothing is quoted. Medium because the SAMA text is a non-authoritative portal copy and GCC-wide statements rest on operator pages.", "confidence": "medium" }, "currency": { "effective_since": "2021-05-05", "effective_note": "Dated from SAMA circular 42068309 (2021-05-05, 1442-09-24 H), In-Force with no later version shown on 2026-09-18. SAMA's pilot phase for AFAQ began on 2021-04-19 under its charging policy.", "source_edition": "OR 42068309 (2021-05-05); GPC pages as read 2026-09-18", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://rulebook.sama.gov.sa/en/operating-rules-cross-currency-payments-using-afaq-service", "source_class": "public_primary", "source_title": "Operating Rules for Cross Currency Payments using AFAQ Service (SAMA circular 42068309)", "checked_on": "2026-09-19", "checked_by": "gcc-afaq validator session", "notes": "Confirms the moment of finality at debit and the bar on cancellation or recall after debit (OR 7.13, 7.14), that Country Specific Model entries post simultaneously (OR 7.3, 4.1.7, 4.2), completion on validation by the receiving domestic RTGS (OR 7.4, 7.5), and the end-of-day net settlement window through a Settlement Agent (OR 5.1 items 9 to 11)." }, { "source_url": "https://www.gulf-payments.com/en/gpc_news/facilitating-cross-border-payments-in-gcc/", "source_class": "public_primary", "source_title": "Gulf Payments Company, Facilitating cross-border payments in GCC (interview reprint, 2023-06-19)", "checked_on": "2026-09-19", "checked_by": "gcc-afaq validator session", "notes": "Confirms the operator's description that a payment or transfer is immediately final upon debit and corresponding credit entry in the accounts NCBs provide, and that payments settle over Inter-NCB Primary accounts with shadow postings to the Central Component." } ] }, "rail_name": "GCC AFAQ (cross-currency payments)", "governing_authority": "SAMA (Saudi participant rules); GCC central banks via GPC (system)", "snapshot": "2026-09-18", "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "gcc-afaq:hours", "id": "hours", "rail": "gcc-afaq", "kind": "rail-fact", "facet": "hours", "name": "When is AFAQ open, and what counts as a business day?", "statement": "AFAQ is not a 24/7 system. It runs one business day at a time, from 08:00 to 16:00 Saudi time on GPC's published timetable, and payments and returns are exchanged between 08:30 and 15:00; the first half hour is for fixing exchange rates and the last hour for reporting and the central banks' net settlement. A payment can only go through on a day that is a working day in both the sending and the receiving country. The system is closed on Fridays and Saturdays, the UAE side is closed on Saturdays and Sundays, and GPC marks a day as not working when any participating country has an official holiday.", "details": [ { "label": "The daily timetable", "value": "08:00 to 08:30: central banks send and approve exchange rates. 08:30 to 15:00: exchange period, returns from participants included; its end is the cut-off for payments. 15:00 to 15:30: statements, net position reports, reconciliation and confirmation by central banks. 15:30 to 16:00: net settlement. All times are Saudi (KSA) time.", "citation": "GPC, Working Hours and Official Holidays page, AFAQ Cross-Currency Service Business Day Timetable (read 2026-09-18)", "rests_on": "guidance" }, { "label": "The phases behind those times", "value": "SAMA's rules give the shape of the day but no clock times. It falls into three blocks. Opening: exchange rates are agreed and Saudi participants prefund their AFAQ accounts. Exchange: customer and interbank payments and returns flow first, followed by a stretch in which only interbank payments are taken. Closing: payments that could not be delivered go back to senders, the central banks report, reconcile and settle net, and SAMA sweeps Saudi balances back.", "citation": "SAMA, Operating Rules for Cross Currency Payments using AFAQ Service, circular 42068309 of 2021-05-05 (1442-09-24 H), section 5.1", "rests_on": "rule" }, { "label": "Joint working days", "value": "The Central Component holds a calendar of working days and holidays per country and processes a payment only when both countries are working. Payments carry same-day value only. SAMA decides which days count as business days for its participants and may change a business day into a non-business day or the reverse.", "citation": "OR 42068309 sections 5.2, 5.3 and 7.2(c)", "rests_on": "rule" }, { "label": "Weekends and holidays", "value": "GPC states that AFAQ is closed on Friday and Saturday, that it is closed in the UAE on Saturday and Sunday, and that its daily status shows every country as not working when any participating country has an official holiday.", "citation": "GPC, Working Hours and Official Holidays page, Holidays section (read 2026-09-18)", "rests_on": "guidance" }, { "label": "Cut-off control and extensions", "value": "SAMA manages the cut-off for its participants and may limit which kinds of payment are allowed at points in the day. A Saudi participant can ask SAMA to extend the cut-off; if SAMA agrees, the participant that asked or caused it pays SAR 25,000 for each 30 minutes of extension. SAMA may also extend hours on its own in an emergency.", "citation": "OR 42068309 sections 5.4, 5.5 and 8.3; SAMA, Charging Policy for Cross Currency Payments Using AFAQ Service, circular 43038107 of 2021-12-02 (1443-04-27 H), section 4.1", "rests_on": "rule" } ], "exceptions": [ "SAMA's rules describe a separate interbank-only exchange period after the general one; GPC's published timetable shows a single exchange period, so when customer payments stop, if earlier than 15:00, is not public [Unverified].", "GPC's holiday table read on 2026-09-18 listed five countries and not Qatar, which joined on 2026-09-07 [Unverified: whether Qatar's calendar is loaded].", "A future-dated payment is not accepted by AFAQ; the sending bank holds it until the value date (GPC, AFAQ FAQs).", "SAMA may close the service for maintenance or other reasons it judges sufficient (OR 42068309 section 5.6)." ], "applies_to": "AFAQ cross-currency service, all GCC participants for the timetable; SAMA's rules on business days, cut-off and extension fees bind Saudi direct participants", "caveat": "A payment to or from the UAE needs a day the UAE works as well, so Sunday is not a joint working day for UAE corridors [Inference from the two weekend statements]. Always check the receiving country's holidays before promising same-day value.", "related": [ "gcc-afaq:settlement", "gcc-afaq:return", "gcc-afaq-reject:RJ05", "gcc-afaq-reject:RJ06", "gcc-afaq-reject:RJ07", "gcc-afaq-reject:RJ13" ], "basis": { "sources": "Gulf Payments Company, Working Hours and Official Holidays page and AFAQ FAQs, read 2026-09-18 (public_primary, the operator's own page; GPC's separate timetable document was not used). SAMA rulebook portal, English pages read 2026-09-18: Operating Rules circular 42068309 (2021-05-05), sections 5.1 to 5.6, 7.2 and 8.3; Charging Policy circular 43038107 (2021-12-02), section 4.1 (public_primary). The GPC Operating Rules and Regulations were not used. Nothing is quoted. Medium because the clock times rest on an operator web page, not a rule text.", "confidence": "medium" }, "currency": { "effective_since": "Not stated by the operator", "effective_note": "The clock times come from GPC's live page, which carries no effective date. SAMA's phase structure dates from circular 42068309 (2021-05-05, 1442-09-24 H).", "source_edition": "GPC Working Hours page as read 2026-09-18; OR 42068309 (2021-05-05); CP 43038107 (2021-12-02)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.gulf-payments.com/en/afaq-cross-currency-service/", "source_class": "public_primary", "source_title": "Gulf Payments Company, Working Hours and Official Holidays page", "checked_on": "2026-09-19", "checked_by": "gcc-afaq validator session", "notes": "Confirms the daily timetable exactly: 08:00 to 08:30 FX translation rate adjustment and authorization, 08:30 to 15:00 exchange period including returns, 15:00 to 15:30 reporting/reconciliation/confirmation, 15:30 to 16:00 net settlement window, all Saudi time. Confirms AFAQ is closed Friday and Saturday, closed in the UAE on Saturday and Sunday, and shows a country Not Working on any participating country's official holiday. On 2026-09-19 the holiday table listed five countries (UAE, Bahrain, Saudi Arabia, Oman, Kuwait), not Qatar, matching the record's own exception about Qatar's status being unconfirmed." }, { "source_url": "https://rulebook.sama.gov.sa/en/operating-rules-cross-currency-payments-using-afaq-service", "source_class": "public_primary", "source_title": "Operating Rules for Cross Currency Payments using AFAQ Service (SAMA circular 42068309)", "checked_on": "2026-09-19", "checked_by": "gcc-afaq validator session", "notes": "Confirms the shape of the business day without clock times (OR 5.1), the joint-working-day calendar rule (OR 5.2, 5.3, 7.2(c)), and SAMA's cut-off and emergency powers (OR 5.4, 5.5, 8.3)." }, { "source_url": "https://rulebook.sama.gov.sa/en/charging-policy-cross-currency-payments-using-afaq-service", "source_class": "public_primary", "source_title": "Charging Policy for Cross Currency Payments Using AFAQ Service (SAMA circular 43038107)", "checked_on": "2026-09-19", "checked_by": "gcc-afaq validator session", "notes": "Confirms the SAR 25,000 fee for each 30 minutes of a cut-off extension a participant requests and SAMA approves (CP 4.1)." } ] }, "rail_name": "GCC AFAQ (cross-currency payments)", "governing_authority": "SAMA (Saudi participant rules); GCC central banks via GPC (system)", "snapshot": "2026-09-18", "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "gcc-afaq:liability", "id": "liability", "rail": "gcc-afaq", "kind": "rail-fact", "facet": "liability", "name": "Who bears the loss when an AFAQ payment goes wrong?", "statement": "SAMA's rules put the risk on the participants and keep it off SAMA. Each Saudi participant acts as principal for its own payment messages, runs its own systems and liquidity at its own risk, and must fight fraud on its side. The receiving participant owes two things: a same-day credit to the right beneficiary when the account number matches the named beneficiary, and a full, prompt return when it cannot credit; returning within two business days spares it any claim for the sender's lost use of funds. SAMA excludes its own liability for delays, outages and its own acts, and for events beyond reasonable control. Disputes go to SAMA and Saudi law governs. How losses between banks in different countries are shared beyond this is not in any public text read.", "details": [ { "label": "Principal for its own messages", "value": "Each Saudi direct participant is liable as principal for the payment messages it sends, and stays liable for obligations already accrued if it leaves the service.", "citation": "SAMA, Operating Rules for Cross Currency Payments using AFAQ Service, circular 42068309 of 2021-05-05 (1442-09-24 H), sections 3.4 and 8.4", "rests_on": "rule" }, { "label": "The receiving bank's duties", "value": "When the account number in the message is the right one for the beneficiary named in field 59, the receiving participant must credit that beneficiary with same-day value by the end of the business cycle at the latest, and it must make sure the funds reach the correct beneficiary as described in the message.", "citation": "OR 42068309 sections 7.6 and 7.7", "rests_on": "rule" }, { "label": "Use-of-funds compensation and late returns", "value": "A return made within the two-business-day window carries no liability for compensating the sender's loss of use of the funds. SAMA's rules do not say what compensation applies to a later return [Inference: exposure to such a claim is implied but its measure is not public]. SAMA separately fines a late return SAR 100 and may add a charge based on the amount.", "citation": "OR 42068309 section 7.8; SAMA, Charging Policy for Cross Currency Payments Using AFAQ Service, circular 43038107 of 2021-12-02 (1443-04-27 H), section 4.2", "rests_on": "rule" }, { "label": "SAMA's exclusions", "value": "SAMA shields itself, its staff and its agents from any loss claim, direct or consequential, by a participant or by anyone else. The shield reaches SAMA's own conduct in running the service, losses that trace back to a participant's systems or fault, any outage or shortcoming of the service, and events outside reasonable control.", "citation": "OR 42068309 sections 8.1 and 8.2", "rests_on": "rule" }, { "label": "Participant-side risks", "value": "Each participant builds, secures and backs up its own connection at its own cost, manages its own liquidity without SAMA monitoring it, must prevent, detect and report fraud involving the service to SAMA and to the participants concerned, and must comply with Saudi anti-money-laundering and counter-terrorist-financing law.", "citation": "OR 42068309 sections 4.4, 4.7, 4.15, 4.18 and 7.15", "rests_on": "rule" }, { "label": "Disputes and law", "value": "A dispute or claim under SAMA's AFAQ rules that the parties cannot settle may be put to SAMA, and the rules are governed by the laws of Saudi Arabia.", "citation": "OR 42068309 sections 8.6 and 8.8", "rests_on": "rule" } ], "exceptions": [ "A cross-border dispute involves a participant bound by another central bank's rules; how the two rulebooks meet, and whether any GCC-level compensation scheme applies, is not in any public text read [Unverified].", "A customer's claim against their own bank runs under that country's banking and consumer law, not these interbank rules.", "SAMA may adjust duties case by case: the return duty applies unless SAMA advises otherwise (OR 42068309 section 7.8)." ], "applies_to": "Saudi direct participants and SAMA under SAMA's AFAQ operating rules", "caveat": "These are SAMA's rules for its own participants. Do not present them as the allocation of loss for the whole GCC system.", "related": [ "gcc-afaq:return", "gcc-afaq:consumer-law", "gcc-afaq:decision-points", "gcc-afaq:refund" ], "basis": { "sources": "SAMA rulebook portal, English pages read 2026-09-18: Operating Rules circular 42068309 (2021-05-05), sections 3.4, 4.4, 4.7, 4.15, 4.18, 7.6 to 7.8, 7.15, 8.1, 8.2, 8.4, 8.6 and 8.8; Charging Policy circular 43038107 (2021-12-02), section 4.2 (public_primary; the portal denies legal effect). The GPC Operating Rules and Regulations, which may hold GCC-level compensation rules, were not used. Nothing is quoted. Medium because the SAMA text is a non-authoritative portal copy and covers one country's participants.", "confidence": "medium" }, "currency": { "effective_since": "2021-05-05", "effective_note": "Dated from SAMA circular 42068309 (2021-05-05, 1442-09-24 H); the late-return fee from circular 43038107 (2021-12-02, 1443-04-27 H). Both In-Force with no later version on 2026-09-18.", "source_edition": "OR 42068309 (2021-05-05); CP 43038107 (2021-12-02)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://rulebook.sama.gov.sa/en/operating-rules-cross-currency-payments-using-afaq-service", "source_class": "public_primary", "source_title": "Operating Rules for Cross Currency Payments using AFAQ Service (SAMA circular 42068309)", "checked_on": "2026-09-19", "checked_by": "gcc-afaq validator session", "notes": "Confirms each direct participant is liable as principal for its own payment messages and stays liable for accrued obligations on leaving (OR 3.4, 8.4), the receiving bank's same-day-credit and correct-beneficiary duties (OR 7.6, 7.7), the two-business-day no-use-of-funds-liability window (OR 7.8), SAMA's exclusion of its own liability and force majeure (OR 8.1, 8.2), participant-side system, liquidity, fraud and AML duties (OR 4.4, 4.7, 4.15, 4.18, 7.15), and the dispute and governing-law provisions (OR 8.6, 8.8)." }, { "source_url": "https://rulebook.sama.gov.sa/en/charging-policy-cross-currency-payments-using-afaq-service", "source_class": "public_primary", "source_title": "Charging Policy for Cross Currency Payments Using AFAQ Service (SAMA circular 43038107)", "checked_on": "2026-09-19", "checked_by": "gcc-afaq validator session", "notes": "Confirms the SAR 100 late-return penalty and the possible additional charge tied to the amount of the payment returned (CP 4.2)." } ] }, "rail_name": "GCC AFAQ (cross-currency payments)", "governing_authority": "SAMA (Saudi participant rules); GCC central banks via GPC (system)", "snapshot": "2026-09-18", "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "gcc-afaq:limits", "id": "limits", "rail": "gcc-afaq", "kind": "rail-fact", "facet": "limits", "name": "What limits apply to an AFAQ payment: amount, type, purpose or timing?", "statement": "No public text read sets a maximum or minimum amount for an AFAQ payment. What limits it instead is its shape and its purpose. It must be a single credit transfer, customer or interbank, for same-day value, between two different GCC currencies, on a day both countries work, at that day's confirmed rate. SAMA also requires that Saudi participants use AFAQ only for genuine needs of non-bank customers, and forbids them and their customers from using the fixed daily rate for arbitrage or speculation. The sender's own available balance is a hard ceiling: a Saudi participant can only send what it prefunded that morning.", "details": [ { "label": "No published amount limit", "value": "Neither SAMA's operating rules nor its charging policy, nor any GPC page read, states an amount limit per payment or per day. SAMA keeps a general power to restrict which categories of transaction are allowed at given points of the business day, after telling participants.", "citation": "SAMA, Operating Rules for Cross Currency Payments using AFAQ Service, circular 42068309 of 2021-05-05 (1442-09-24 H), section 5.5; SAMA, Charging Policy circular 43038107 of 2021-12-02; GPC, Our Services and AFAQ FAQs pages (read 2026-09-18)", "rests_on": "rule" }, { "label": "What a payment must be", "value": "Only one payment per message, either a customer payment or an interbank payment, credited on the day it is sent. The money must land with an account holder of the receiving participant (a person or company for a customer payment, a financial institution for an interbank one) or with the receiving participant itself. The message carries the amount and currency code on each side and the day's rate, and must follow SAMA's format guides.", "citation": "OR 42068309 section 7.2", "rests_on": "rule" }, { "label": "Purpose: genuine client needs, no arbitrage", "value": "Saudi participants must confine AFAQ to real financial and payment needs of their non-bank clients, such as trade, remittances and consumer payments, must have controls that keep use within that bound, and must not take part in, or let clients take part in, profiting from gaps between AFAQ's rates and market exchange rates.", "citation": "OR 42068309 sections 1 (Arbitrage) and 7.1.1 to 7.1.3", "rests_on": "rule" }, { "label": "Currencies and rates", "value": "The cross-currency service covers the six GCC currencies: AED, BHD, SAR, OMR, QAR and KWD. A pair whose rate a central bank did not confirm that morning cannot be used for the rest of the day, and a message whose rate or converted amount does not match the confirmed rate is refused.", "citation": "GPC, Our Services page (read 2026-09-18); OR 42068309 section 5.1 item 3 and section 6", "rests_on": "rule" }, { "label": "Funds available", "value": "Saudi participants must prefund their AFAQ account at SAMA each day so that the balance covers every payment they send as it falls due.", "citation": "OR 42068309 section 5.1 item 5", "rests_on": "rule" }, { "label": "Destination-specific content", "value": "Every payment to the UAE must carry a correct purpose of payment code from the list SAMA communicates, and customer payments to countries that use IBAN must quote a valid IBAN for the beneficiary, failing which the payment may be refused or returned.", "citation": "OR 42068309 sections 7.11 and 7.12", "rests_on": "rule" } ], "exceptions": [ "A participant or a receiving bank may apply its own amount limits; SAMA's list of return codes includes AM02 (amount above an allowed maximum), which suggests such limits exist somewhere in the chain [Inference], but none is published.", "Customer limits a Saudi bank sets in its own channels for AFAQ transfers were not researched.", "The other GCC central banks may set limits for their own participants; their rules were not read.", "Future-dated payments are not accepted by AFAQ itself; the sending bank holds them until the value date (GPC, AFAQ FAQs)." ], "applies_to": "AFAQ cross-currency payments sent by Saudi direct participants; the currency list applies to the whole system", "caveat": "'No published amount limit' is not 'no limit'. Tell a user that any cap they meet comes from their bank or from funding, not from a published AFAQ rule. The currency list moves: QAR joined on 2026-09-07.", "related": [ "gcc-afaq:hours", "gcc-afaq:settlement", "gcc-afaq:decision-points", "gcc-afaq-reject:RJ16", "gcc-afaq-reject:RJ19", "gcc-afaq-reject:RJ01" ], "basis": { "sources": "SAMA rulebook portal, English pages read 2026-09-18: Operating Rules circular 42068309 (2021-05-05), sections 1, 5.1, 5.5, 6, 7.1, 7.2, 7.11, 7.12 and Appendix 2; Charging Policy circular 43038107 (2021-12-02), read in full (public_primary; the portal denies legal effect). Gulf Payments Company pages read 2026-09-18: Our Services, AFAQ FAQs, and the news item on Qatar joining (2026-09-07). The GPC Operating Rules and Regulations were not used. Nothing is quoted. Medium: the absence of an amount limit is an absence in the texts read, not a rule.", "confidence": "medium" }, "currency": { "effective_since": "2021-05-05", "effective_note": "Dated from SAMA circular 42068309 (2021-05-05, 1442-09-24 H). The currency list includes QAR since Qatar Central Bank joined on 2026-09-07; GPC's FAQ page still called QAR upcoming on 2026-09-18.", "source_edition": "OR 42068309 (2021-05-05); CP 43038107 (2021-12-02); GPC pages as read 2026-09-18", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://rulebook.sama.gov.sa/en/operating-rules-cross-currency-payments-using-afaq-service", "source_class": "public_primary", "source_title": "Operating Rules for Cross Currency Payments using AFAQ Service (SAMA circular 42068309)", "checked_on": "2026-09-19", "checked_by": "gcc-afaq validator session", "notes": "Confirms no published amount limit and SAMA's power to restrict transaction categories (OR 5.5), the qualified-payment-message shape (OR 7.2), the genuine-client-needs and no-arbitrage rules (OR 1 Arbitrage definition, 7.1.1 to 7.1.3), the confirmed-rate check (OR 5.1 item 3, section 6), Saudi prefunding (OR 5.1 item 5), and the UAE purpose-code and IBAN rules (OR 7.11, 7.12)." }, { "source_url": "https://www.gulf-payments.com/en/our-services/", "source_class": "public_primary", "source_title": "Gulf Payments Company, Our Services page", "checked_on": "2026-09-19", "checked_by": "gcc-afaq validator session", "notes": "Confirms the six currencies (AED, BHD, SAR, OMR, QAR, KWD) as AFAQ's current cross-currency service, and that no amount limit is stated on this page." }, { "source_url": "https://rulebook.sama.gov.sa/en/charging-policy-cross-currency-payments-using-afaq-service", "source_class": "public_primary", "source_title": "Charging Policy for Cross Currency Payments Using AFAQ Service (SAMA circular 43038107)", "checked_on": "2026-09-19", "checked_by": "gcc-afaq validator session", "notes": "Read in full; confirms no amount limit or FX margin is set here, only participant fees, penalties and a customer fee cap, consistent with the record's reading of an absence rather than a stated limit." } ] }, "rail_name": "GCC AFAQ (cross-currency payments)", "governing_authority": "SAMA (Saudi participant rules); GCC central banks via GPC (system)", "snapshot": "2026-09-18", "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "gcc-afaq:messages", "id": "messages", "rail": "gcc-afaq", "kind": "rail-fact", "facet": "messages", "name": "Which messages carry an AFAQ payment, a return and a confirmation?", "statement": "AFAQ runs three payment message pairs, each named by GPC in both SWIFT MT and ISO 20022 form: a customer credit transfer (MT103 or pacs.008), an interbank transfer (MT202 or pacs.009) and a return (MT202 RTRN or pacs.004). GPC says the core of the system uses ISO 20022 MX messages while the interfaces to central banks use MT, and the regional gateways convert between the two; SAMA's rules still point Saudi participants at MT fields and MT950 statements. A Payment Completion Confirmation travels back to the sender once the receiving side accepts a payment. AFAQ does not use the SWIFT network; it runs on its own private network. The detailed format guides are shared with participants only.", "details": [ { "label": "The three message pairs", "value": "Customer payments: MT103 or pacs.008. Interbank payments: MT202 or pacs.009. Returns: MT202 with the RTRN code, or pacs.004. GPC also says AFAQ follows ISO 20022.", "citation": "GPC, AFAQ FAQs, Payment Flows and Types (read 2026-09-18)", "rests_on": "guidance" }, { "label": "MT at the edges, MX inside", "value": "GPC describes MT formats at the interface to central banks and ISO 20022 MX inside the cross-currency service. SAMA's rules give the regional gateway the job of converting between MX and MT, among its checking and routing functions.", "citation": "GPC, Facilitating cross-border payments in GCC (interview reprint, 2023-06-19); SAMA, Operating Rules for Cross Currency Payments using AFAQ Service, circular 42068309 of 2021-05-05 (1442-09-24 H), section 4.1.2", "rests_on": "guidance" }, { "label": "MT references in SAMA's rules", "value": "SAMA's rules identify the beneficiary by field 59 and the original payment's reference in a return by field 72, have the Central Component send MT950 shadow account statements at day end, and require Saudi prefunding to go as an interbank payment to SAMA with the routing code AFAQSD100 in the account-with-institution field.", "citation": "OR 42068309 sections 4.1.5, 5.1 item 5, 7.6 and 7.9", "rests_on": "rule" }, { "label": "Confirmation and rejection", "value": "The receiving country's domestic RTGS sends a Payment Completion Confirmation, quoting the payment's unique message reference, back through the gateways and the Central Component to the sender. A payment the system refuses is sent back to the sending participant as a return payment carrying the rejection reason. A resent payment needs a new unique message reference but may keep the same UETR.", "citation": "OR 42068309 sections 7.3 and 7.5", "rests_on": "rule" }, { "label": "Network", "value": "AFAQ does not use the SWIFT network. It runs over a private, encrypted MPLS VPN connecting all participants, with API connectivity through the payment gateways and a public key infrastructure GPC runs.", "citation": "GPC, AFAQ FAQs, Network and Connectivity (read 2026-09-18); GPC, Our Services page (read 2026-09-18)", "rests_on": "guidance" }, { "label": "Tracking and free text since June 2026", "value": "GPC added end-to-end payment tracking, which shows banks each stage including the credit to the beneficiary, and free-text messaging between participating banks. The message types behind these features were not published.", "citation": "GPC news, GPC launches new AFAQ features to enhance payment transparency and tracking (2026-06-25)", "rests_on": "guidance" }, { "label": "Format guides are not public", "value": "SAMA's rules list the controlled documents that set the detail, including MT and MX message format guides, a REST API specification and gateway design specifications, and describe them as documents shared with the pilot banks. None is public.", "citation": "OR 42068309 section 2.8 and Appendix 1", "rests_on": "rule" } ], "exceptions": [ "Which message and field carries an RJ rejection code or a return reason code to a Saudi participant is set in the non-public format guides [Unverified; the return pair is the likely carrier by inference].", "Other central banks' participants connect through their own domestic RTGS, which may use different formats at the bank interface.", "No request-for-return, recall or status-inquiry message is named in any public text read." ], "applies_to": "AFAQ cross-currency service, all GCC participants for the message pairs and network; the MT field references are SAMA's rules for Saudi direct participants", "caveat": "GPC calls AFAQ ISO 20022, but banks may still send and receive MT at their interface. Ask which side of the gateway a question is about.", "related": [ "gcc-afaq:return", "gcc-afaq:recall", "gcc-afaq:participants", "gcc-afaq-reject:RJ12" ], "basis": { "sources": "Gulf Payments Company pages read 2026-09-18: AFAQ FAQs, Our Services, the 2023 interview reprint and the news item of 2026-06-25 (public_primary). SAMA rulebook portal, English page read 2026-09-18: Operating Rules circular 42068309 (2021-05-05), sections 2.8, 4.1.2, 4.1.5, 5.1, 7.3, 7.5, 7.6, 7.9 and Appendix 1 (public_primary; the portal denies legal effect). The message format guides are controlled documents shared with participants only, hence primary_not_public. The GPC Operating Rules and Regulations were not used. Nothing is quoted.", "confidence": "medium" }, "currency": { "effective_since": "2021-05-05", "effective_note": "Dated from SAMA circular 42068309 (2021-05-05, 1442-09-24 H). The GPC FAQ is undated as read 2026-09-18; tracking and free-text messaging launched 2026-06-25.", "source_edition": "OR 42068309 (2021-05-05); GPC pages as read 2026-09-18", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "primary_not_public": true, "corroboration": [ { "source_url": "https://www.gulf-payments.com/en/faqs/", "source_class": "public_primary", "source_title": "Gulf Payments Company, AFAQ FAQs", "checked_on": "2026-09-19", "checked_by": "gcc-afaq validator session", "notes": "Confirms the three message pairs exactly: MT103/pacs.008 for a single customer credit transfer, MT202/pacs.009 for a general financial institution transfer, and MT202 RTRN/pacs.004 for a return transfer, plus that AFAQ follows ISO 20022 standards and does not use the SWIFT network, instead running on a private MPLS-VPN with API connectivity through payment gateway applications." }, { "source_url": "https://rulebook.sama.gov.sa/en/operating-rules-cross-currency-payments-using-afaq-service", "source_class": "public_primary", "source_title": "Operating Rules for Cross Currency Payments using AFAQ Service (SAMA circular 42068309)", "checked_on": "2026-09-19", "checked_by": "gcc-afaq validator session", "notes": "Independently confirms, from a different organisation on a different host than GPC's FAQ page, that the Regional Payment Gateway converts message formats MX from and to MT (OR 4.1.2), that field 59 identifies the beneficiary and field 72 the original payment's reference in a return (OR 7.6, 7.9), that the Central Component produces MT950 shadow account statements (OR 4.1.5), and that the message format guides are controlled documents shared only with pilot banks (OR 2.8, Appendix 1). Does not itself name the pacs message codes GPC's FAQ gives." } ] }, "rail_name": "GCC AFAQ (cross-currency payments)", "governing_authority": "SAMA (Saudi participant rules); GCC central banks via GPC (system)", "snapshot": "2026-09-18", "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "not_public", "label": "the operator's own text", "needs": "what the operator's own text says, which Orca has not read", "detail": "SAMA (Saudi participant rules); GCC central banks via GPC (system)'s own text is not the source for this rail fact: it is not public, or not under terms Orca can use. It rests on 2 named public sources, so a term set by agreement rather than by a published rule is not Orca's to state.", "from": "currency.primary_not_public" } ] }, { "uid": "gcc-afaq:participants", "id": "participants", "rail": "gcc-afaq", "kind": "rail-fact", "facet": "participants", "name": "Who can send and receive AFAQ payments, and who is connected today?", "statement": "AFAQ participants are the six GCC central banks and the banks and financial institutions that hold a settlement account with their own central bank and belong to its domestic RTGS. Customers reach AFAQ only through such a participant. Since Qatar Central Bank joined on 2026-09-07, all six central banks are connected, and GPC's participant page lists 74 entries across the six countries, six of them central banks, with Bahrain and Kuwait the largest groups and the UAE represented by its central bank and a single commercial bank. In Saudi Arabia, SAMA decides who joins: a bank must be a SARIE RTGS member, hold an AFAQ account at SAMA, pass SAMA's certification and sign SAMA's participation agreement.", "details": [ { "label": "Who is eligible", "value": "GPC names two kinds of participant: the GCC central banks, and commercial banks and financial institutions that take part in their own country's payment system. To join, an institution needs a settlement account with its central bank, membership of that central bank's domestic RTGS, and compliance with AFAQ's technical and operational requirements.", "citation": "GPC, AFAQ FAQs, Participants and Beneficiaries, and Join AFAQ page, Key requirements (both read 2026-09-18)", "rests_on": "guidance" }, { "label": "Saudi admission rules", "value": "SAMA admits Saudi direct participants at its discretion against criteria it sets. Before its first payment a Saudi bank needs a signed participation agreement, SAMA's certification of the bank and its systems, and compliance with whatever legal, supervisory, technical and operational requirements SAMA has set. It must also be a SARIE RTGS member and hold a current AFAQ account at SAMA on SAMA's banking conditions.", "citation": "SAMA, Operating Rules for Cross Currency Payments using AFAQ Service, circular 42068309 of 2021-05-05 (1442-09-24 H), sections 3.1, 4.5 and 4.19", "rests_on": "rule" }, { "label": "Leaving or being removed", "value": "SAMA may suspend or terminate a Saudi participant on notice, for instance for failing its criteria or the rules, for suspected insolvency, for loss of licence, or where continued membership could harm the service. A participant may withdraw only with SAMA's prior written consent and at least 30 days' written notice. SAMA tells the other participants of such changes.", "citation": "OR 42068309 sections 3.2, 3.3 and 3.5", "rests_on": "rule" }, { "label": "Who is connected", "value": "GPC's participant page, read 2026-09-18, lists by country: Bahrain 26, Kuwait 20, Saudi Arabia 15, Oman 7, Qatar 4 and the UAE 2, each count including that country's central bank, 74 in all. Several banking groups appear in more than one country. GPC reported 74 participating banks when Qatar joined.", "citation": "GPC, AFAQ Participants page (read 2026-09-18, counted by hand); GPC news, Qatar Central Bank joins the Gulf Payments System AFAQ (2026-09-07)", "rests_on": "practice" }, { "label": "How banks are onboarded", "value": "A bank joins through its own central bank, which provides guidance, a test plan and training; after the bank's internal testing the central bank asks GPC to admit it to AFAQ certification testing, then certifies completion and plans the production rollout, and GPC announces each new participant to the others. GPC puts the onboarding stages at two to three weeks.", "citation": "GPC, Join AFAQ page, Onboarding Phases, and AFAQ FAQs, Preparation and Onboarding Process (read 2026-09-18)", "rests_on": "guidance" }, { "label": "Who uses it", "value": "GPC lists GCC citizens and residents, retail businesses, and corporate and wholesale clients as the people AFAQ serves.", "citation": "GPC, AFAQ FAQs, Participants and Beneficiaries (read 2026-09-18)", "rests_on": "guidance" } ], "exceptions": [ "The other five central banks set their own admission rules for their participants; none was read.", "GPC's 2023 interview says participants are approved by the GPC Board after meeting legal, technical and operational requirements, while SAMA's rules place Saudi admission with SAMA; both may apply in sequence [Inference].", "Onboarding of further Qatari and other commercial banks is continuing in phases (GPC news, 2026-09-07), so the list changes." ], "applies_to": "AFAQ cross-currency service across the six GCC countries; admission, suspension and withdrawal rules apply to Saudi direct participants", "caveat": "The participant list is a snapshot that GPC updates as banks join. A foreign bank's branch appears under the country where it holds its central bank account, so the same group can appear several times.", "related": [ "gcc-afaq:settlement", "gcc-afaq:messages", "gcc-afaq:decision-points", "gcc-afaq-reject:RJ08", "gcc-afaq-reject:RJ09" ], "basis": { "sources": "Gulf Payments Company pages read 2026-09-18: AFAQ Participants, Join AFAQ, AFAQ FAQs, the news item of 2026-09-07 and the 2023 interview reprint (public_primary). SAMA rulebook portal, English page read 2026-09-18: Operating Rules circular 42068309 (2021-05-05), sections 3.1 to 3.5, 4.5 and 4.19 (public_primary; the portal denies legal effect). The GPC Operating Rules and Regulations were not used. Nothing is quoted. Medium: the list is a dated operator snapshot and eligibility outside Saudi Arabia rests on GPC pages.", "confidence": "medium" }, "currency": { "effective_since": "2021-05-05", "effective_note": "Saudi admission rules date from SAMA circular 42068309 (2021-05-05, 1442-09-24 H). The participant counts are as listed on GPC's page on 2026-09-18, after Qatar Central Bank and three Qatari banks joined on 2026-09-07.", "source_edition": "OR 42068309 (2021-05-05); GPC pages as read 2026-09-18", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.gulf-payments.com/en/afaq-participants/", "source_class": "public_primary", "source_title": "Gulf Payments Company, AFAQ Participants page", "checked_on": "2026-09-19", "checked_by": "gcc-afaq validator session", "notes": "Confirms the eligible participant types (central banks; commercial banks and financial institutions in each country's own payment system). Recounted the page's per-country lists by hand on 2026-09-19 and got the same totals the record reports: Bahrain 26, Kuwait 20, Saudi Arabia 15, Oman 7, Qatar 4, UAE 2, each including that country's central bank, 74 in all." }, { "source_url": "https://www.gulf-payments.com/en/join-afaq/", "source_class": "public_primary", "source_title": "Gulf Payments Company, Join AFAQ page", "checked_on": "2026-09-19", "checked_by": "gcc-afaq validator session", "notes": "Confirms the key requirements to join (local settlement account, domestic RTGS membership, AFAQ technical and operational compliance) and the three onboarding phases (Preparation, Testing, Onboarding) with a two to three week estimate given on the AFAQ FAQs page." }, { "source_url": "https://rulebook.sama.gov.sa/en/operating-rules-cross-currency-payments-using-afaq-service", "source_class": "public_primary", "source_title": "Operating Rules for Cross Currency Payments using AFAQ Service (SAMA circular 42068309)", "checked_on": "2026-09-19", "checked_by": "gcc-afaq validator session", "notes": "Confirms Saudi admission requirements (SARIE RTGS membership, current AFAQ account, SAMA-communicated compliance, signed Agreement of Participation, OR 3.1), the certification requirement (OR 4.5), the account condition (OR 4.19), and suspension, termination and 30-day withdrawal-notice rules with notice to other participants (OR 3.2, 3.3, 3.5)." }, { "source_url": "https://www.gulf-payments.com/en/gpc_news/qatar-central-bank-joins-the-gulf-payments-system-afaq/", "source_class": "public_primary", "source_title": "Gulf Payments Company, Qatar Central Bank joins the Gulf Payments System AFAQ (2026-09-07)", "checked_on": "2026-09-19", "checked_by": "gcc-afaq validator session", "notes": "Confirms Qatar Central Bank and three Qatari commercial banks (Doha Bank, Qatar International Islamic Bank, Dukhan Bank) joined on 2026-09-07, bringing the total to 74 participating banks and completing all six GCC central banks' participation." } ] }, "rail_name": "GCC AFAQ (cross-currency payments)", "governing_authority": "SAMA (Saudi participant rules); GCC central banks via GPC (system)", "snapshot": "2026-09-18", "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "gcc-afaq:recall", "id": "recall", "rail": "gcc-afaq", "kind": "rail-fact", "facet": "recall", "name": "Can the sender cancel or recall an AFAQ payment?", "statement": "No. Under SAMA's rules, once the sending participant's account has been debited the payment can be neither cancelled nor recalled, and no public AFAQ text read describes a recall message, a request-for-return procedure or any deadline for one. A sender that wants money back has to ask the receiving bank, outside any rule that obliges it to agree, and the money then comes back as a return payment if the receiving bank chooses to send one. GPC added a free-text messaging channel between banks in June 2026 that can carry such an inquiry.", "details": [ { "label": "No cancellation or recall after debit", "value": "SAMA's rules rule out cancelling or recalling a payment message once it has been debited to the sending participant's account, which is also the point at which the payment becomes final and irrevocable.", "citation": "SAMA, Operating Rules for Cross Currency Payments using AFAQ Service, circular 42068309 of 2021-05-05 (1442-09-24 H), sections 7.13 and 7.14", "rests_on": "rule" }, { "label": "No recall procedure in the public texts", "value": "SAMA's rules name only two ways a payment goes back: a rejection by the system, returned to the sender, and a return by the receiving participant when it cannot credit the beneficiary. Neither is started by the sender, and neither text sets a way for the sender to demand one.", "citation": "OR 42068309 sections 7.3, 7.8 and 7.14", "rests_on": "rule" }, { "label": "Return codes that point to requests", "value": "SAMA's list of return reasons includes codes for a return made after a cancellation request (FOCR), a cancellation asked for by the debtor (CUST), fraud (FR01) and a return after an investigation request (RUTA). Their presence suggests banks do ask each other for money back and answer with a return [Inference]; the list sets no procedure or deadline for such requests.", "citation": "OR 42068309 Appendix 2 (Payments Returned)", "rests_on": "rule" }, { "label": "A channel for inquiries", "value": "Since June 2026 AFAQ has end-to-end tracking, which lets banks see whether the beneficiary was credited, and free-text messaging between participating banks for payment inquiries and operational matters.", "citation": "GPC news, GPC launches new AFAQ features to enhance payment transparency and tracking (2026-06-25)", "rests_on": "guidance" } ], "exceptions": [ "Whether a Saudi participant can withdraw a payment it has submitted but that has not yet been debited, for instance one still queued, is not stated in any public text read [Unverified].", "The other GCC central banks may set recall or cancellation practices for their own participants; their rules were not read.", "A receiving bank that returns a payment late pays SAMA's late-return fee, but no rule read obliges it to return a payment it credited correctly [Inference: the return duty covers only payments it could not credit] (SAMA Charging Policy circular 43038107 section 4.2; OR 42068309 section 7.8)." ], "applies_to": "AFAQ cross-currency payments sent by Saudi direct participants; the June 2026 features apply system-wide", "caveat": "Do not suggest the sender can pull an AFAQ payment back. The honest answer is: final at debit; ask the receiving bank, which may or may not return it.", "related": [ "gcc-afaq:finality", "gcc-afaq:return", "gcc-afaq:refund", "gcc-afaq:messages", "gcc-afaq-reject:RJ24" ], "basis": { "sources": "SAMA rulebook portal, English pages read 2026-09-18: Operating Rules circular 42068309 (2021-05-05), sections 7.3, 7.8, 7.13, 7.14 and Appendix 2; Charging Policy circular 43038107 (2021-12-02), section 4.2 (public_primary; the portal denies legal effect). GPC news item of 2026-06-25, read 2026-09-18. The GPC Operating Rules and Regulations were not used. Nothing is quoted. Medium: the no-recall rule is explicit for Saudi participants; the absence of a recall procedure is an absence in the texts read.", "confidence": "medium" }, "currency": { "effective_since": "2021-05-05", "effective_note": "Dated from SAMA circular 42068309 (2021-05-05, 1442-09-24 H), In-Force with no later version on 2026-09-18. Tracking and free-text messaging launched 2026-06-25 per GPC.", "source_edition": "OR 42068309 (2021-05-05); CP 43038107 (2021-12-02); GPC news 2026-06-25", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://rulebook.sama.gov.sa/en/operating-rules-cross-currency-payments-using-afaq-service", "source_class": "public_primary", "source_title": "Operating Rules for Cross Currency Payments using AFAQ Service (SAMA circular 42068309)", "checked_on": "2026-09-19", "checked_by": "gcc-afaq validator session", "notes": "Confirms no cancellation or recall is possible once the sending participant's account is debited (OR 7.13, 7.14), and that the operating rules name only rejection (OR 7.3) and return by the receiving participant (OR 7.8) as ways a payment goes back, with no sender-initiated recall procedure described. Confirms Appendix 2 lists return codes for FOCR, CUST, FR01 and RUTA." }, { "source_url": "https://www.gulf-payments.com/en/gpc_news/gpc-launches-new-afaq-features-to-enhance-payment-transparency-and-tracking/", "source_class": "public_primary", "source_title": "Gulf Payments Company, GPC launches new AFAQ features to enhance payment transparency and tracking (2026-06-25)", "checked_on": "2026-09-19", "checked_by": "gcc-afaq validator session", "notes": "Confirms end-to-end payment tracking and free-text messaging between participating banks for payment inquiries, launched 2026-06-25, matching the record's description of a channel for inquiries." } ] }, "rail_name": "GCC AFAQ (cross-currency payments)", "governing_authority": "SAMA (Saudi participant rules); GCC central banks via GPC (system)", "snapshot": "2026-09-18", "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "gcc-afaq:refund", "id": "refund", "rail": "gcc-afaq", "kind": "rail-fact", "facet": "refund", "name": "Does the payer have a right to get money back from an AFAQ payment?", "statement": "No AFAQ text read gives a payer a refund right. AFAQ carries only credit transfers the sending bank pushes, with no direct debit and no mandate a payer could dispute, and SAMA's rules make each payment final at debit with no cancellation or recall. Money comes back to a payer through the return rules, when the receiving bank could not credit the beneficiary, or by the receiver's voluntary return; any wider right to be repaid would come from the sending country's banking or consumer law, which sits outside AFAQ and was not researched for this fact.", "details": [ { "label": "Credit push only", "value": "Every eligible AFAQ message is a single customer or interbank credit, sent by the paying participant for same-day value. SAMA's rules provide nothing a payee could use to pull money from a payer.", "citation": "SAMA, Operating Rules for Cross Currency Payments using AFAQ Service, circular 42068309 of 2021-05-05 (1442-09-24 H), sections 1 (Cross-currency payment) and 7.2", "rests_on": "rule" }, { "label": "Final at debit", "value": "Once the sending participant is debited the payment is final and irrevocable, and it cannot be cancelled or recalled.", "citation": "OR 42068309 sections 7.13 and 7.14", "rests_on": "rule" }, { "label": "The only rule-based way back", "value": "The receiving participant must return a payment it cannot credit to the named beneficiary, at the original rate and amounts with nothing deducted, so the payer's bank gets back the full original amount in its own currency.", "citation": "OR 42068309 sections 7.8 and 7.9", "rests_on": "rule" }, { "label": "Nothing refund-specific in the charging policy", "value": "SAMA's AFAQ charging policy sets participant fees, penalties and a cap on customer fees, and bars an FX margin, but contains no refund of a payment or of customer charges.", "citation": "SAMA, Charging Policy for Cross Currency Payments Using AFAQ Service, circular 43038107 of 2021-12-02 (1443-04-27 H), sections 3 to 8", "rests_on": "rule" } ], "exceptions": [ "A payer's bank may reimburse a customer for its own error or for an unauthorised payment under national banking or consumer rules; for Saudi banks see SAMA's consumer protection rules, which were not read for this fact [Unverified].", "The other GCC countries' consumer and payment laws were not read.", "SAMA's return codes include FR01 (fraud) and MD06 (return requested by the end customer), so a receiving bank can return funds for those reasons; whether it must is not stated [Inference]." ], "applies_to": "AFAQ cross-currency payments sent by customers of Saudi direct participants; the credit-push design holds system-wide", "caveat": "Do not promise a payer a refund for an AFAQ transfer. What can be said is that a payment the receiving bank cannot credit comes back in full, and that any other remedy lies with the payer's own bank under national law.", "related": [ "gcc-afaq:recall", "gcc-afaq:return", "gcc-afaq:consumer-law", "gcc-afaq:liability" ], "basis": { "sources": "SAMA rulebook portal, English pages read 2026-09-18: Operating Rules circular 42068309 (2021-05-05), sections 1, 7.2, 7.8, 7.9, 7.13, 7.14 and Appendix 2; Charging Policy circular 43038107 (2021-12-02), read in full (public_primary; the portal denies legal effect). The GPC Operating Rules and Regulations were not used. Nothing is quoted. Low: this fact is mostly an absence in the AFAQ texts, and national refund law was not read.", "confidence": "low" }, "currency": { "effective_since": "2021-05-05", "effective_note": "Dated from SAMA circular 42068309 (2021-05-05, 1442-09-24 H), In-Force with no later version on 2026-09-18.", "source_edition": "OR 42068309 (2021-05-05); CP 43038107 (2021-12-02)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://rulebook.sama.gov.sa/en/operating-rules-cross-currency-payments-using-afaq-service", "source_class": "public_primary", "source_title": "Operating Rules for Cross Currency Payments using AFAQ Service (SAMA circular 42068309)", "checked_on": "2026-09-19", "checked_by": "gcc-afaq validator session", "notes": "Confirms AFAQ carries only single customer or interbank credit transfers with same-day value (OR 1 Cross-currency payment definition, 7.2), that a payment is final and irrevocable at debit with no cancellation or recall (OR 7.13, 7.14), and the full-amount, no-deduction return rule for an uncreditable payment (OR 7.8, 7.9)." }, { "source_url": "https://rulebook.sama.gov.sa/en/charging-policy-cross-currency-payments-using-afaq-service", "source_class": "public_primary", "source_title": "Charging Policy for Cross Currency Payments Using AFAQ Service (SAMA circular 43038107)", "checked_on": "2026-09-19", "checked_by": "gcc-afaq validator session", "notes": "Read in full; confirms it sets participant fees, penalties and a customer fee cap and contains nothing that refunds a payment or a customer charge." } ] }, "rail_name": "GCC AFAQ (cross-currency payments)", "governing_authority": "SAMA (Saudi participant rules); GCC central banks via GPC (system)", "snapshot": "2026-09-18", "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "jurisdiction", "label": "the country", "needs": "which country the payment or the account is in", "detail": "What can be said is that a payment the receiving bank cannot credit comes back in full, and that any other remedy lies with the payer's own bank under national law.", "from": "caveat" } ] }, { "uid": "gcc-afaq:return", "id": "return", "rail": "gcc-afaq", "kind": "rail-fact", "facet": "return", "name": "How does a receiving bank send an AFAQ payment back, and by when?", "statement": "When a Saudi receiving participant cannot credit the beneficiary, SAMA's rules have it send the payment back to the sender as a return payment, ideally the same business day and in any case within two business days counted only on days both countries work. The return mirrors the original exactly: same reference, same rate, same amounts in both currencies, nothing deducted, one message, and only one successful return per payment. The Central Component checks each return against the original and refuses it with a rejection code if it cannot find the original, if the window has passed, if the figures differ, or if the payment was already returned. A late return costs the returning Saudi participant a SAR 100 penalty.", "details": [ { "label": "When a return is due", "value": "The trigger is that the payment cannot be credited to the beneficiary named in it. Unless SAMA says otherwise, the receiving participant should return it quickly, the same business day if it can; otherwise before that payment type's cut-off on the next business day, and never later than two business days. Returning inside that window carries no liability to compensate the sender for the use of the funds.", "citation": "SAMA, Operating Rules for Cross Currency Payments using AFAQ Service, circular 42068309 of 2021-05-05 (1442-09-24 H), section 7.8", "rests_on": "rule" }, { "label": "Counting the two days", "value": "The two business days run from the date the original payment arrived and count only days on which the sending and the receiving country are both open.", "citation": "OR 42068309 section 7.9", "rests_on": "rule" }, { "label": "What the return must match", "value": "The return goes as a single message quoting the original payment's reference in field 72. Its currency codes, both amounts and the exchange rate must equal those of the payment as the returning participant received it, with no deduction of charges. GPC's FAQ gives the same same-rate, no-deduction rule for all participants.", "citation": "OR 42068309 sections 7.8 and 7.9; GPC, AFAQ FAQs, Exchange Rates (read 2026-09-18)", "rests_on": "rule" }, { "label": "Checks by the Central Component", "value": "The Central Component looks up the original payment and refuses the return if the original is not on file (RJ20), if it comes after the two-day window (RJ21), if any amount, currency or the rate differs (RJ22 covers a wrong amount), or if a return for that payment has already succeeded (RJ23).", "citation": "OR 42068309 section 7.9 and Appendix 2 (codes RJ20 to RJ23)", "rests_on": "rule" }, { "label": "Reason codes", "value": "The returning participant states why with one of the return reason codes in SAMA's Appendix 2, which the Central Component validates against its code dictionary; a code not in the dictionary is replaced with XX00. Many of the 78 codes share their letters with ISO 20022 return reasons, while some, such as BADE, BDIN, PPCI and ULBA, appear to be AFAQ's own [Unverified: not compared with the ISO external code sets].", "citation": "OR 42068309 section 7.10 and Appendix 2 (Payments Returned)", "rests_on": "rule" }, { "label": "When returns can be sent", "value": "Returns go in the day's exchange period, which GPC's timetable places at 08:30 to 15:00 Saudi time.", "citation": "OR 42068309 section 5.1 item 6; GPC, Working Hours and Official Holidays page (read 2026-09-18)", "rests_on": "rule" }, { "label": "Price of a late return", "value": "SAMA charges SAR 100 for each payment returned after the time the rules allow, may add a charge tied to the amount, and asks a Saudi participant that receives a late return to report it.", "citation": "SAMA, Charging Policy for Cross Currency Payments Using AFAQ Service, circular 43038107 of 2021-12-02 (1443-04-27 H), section 4.2", "rests_on": "rule" } ], "exceptions": [ "Receiving participants in the other GCC countries return under their own central bank's rules, which were not read; their deadlines may differ.", "A payment the Central Component cannot deliver to the receiving country's gateway is returned to the sender automatically at the end of the day (RJ13); a payment its gateway cannot deliver to the receiving country's domestic RTGS goes back only if the gateway's operator decides so (OR 42068309 section 5.1 item 8).", "A payment the system refuses before settlement also reaches the sender as a return, carrying an RJ code; that is a rejection, not a return by the receiving bank (OR 42068309 section 7.3)." ], "applies_to": "Return payments by Saudi receiving direct participants on AFAQ cross-currency payments, and the Central Component's checks on every return", "caveat": "In AFAQ, 'return' covers two different events: a receiving bank sending money back under these rules, and the system sending a refused payment back to the sender with an RJ code. Check the code family before explaining what happened.", "related": [ "gcc-afaq:finality", "gcc-afaq:recall", "gcc-afaq:liability", "gcc-afaq:hours", "gcc-afaq-reject:RJ20", "gcc-afaq-reject:RJ21", "gcc-afaq-reject:RJ22", "gcc-afaq-reject:RJ23", "gcc-afaq-reject:RJ13" ], "basis": { "sources": "SAMA rulebook portal, English pages read 2026-09-18: Operating Rules circular 42068309 (2021-05-05), sections 5.1, 7.3 and 7.8 to 7.10 and Appendix 2; Charging Policy circular 43038107 (2021-12-02), section 4.2 (public_primary; the portal denies legal effect). Gulf Payments Company AFAQ FAQs and Working Hours pages, read 2026-09-18. The GPC Operating Rules and Regulations were not used. Nothing is quoted. Medium because the SAMA text is a non-authoritative portal copy and binds Saudi participants only.", "confidence": "medium" }, "currency": { "effective_since": "2021-05-05", "effective_note": "Return rules date from SAMA circular 42068309 (2021-05-05, 1442-09-24 H); the late-return fee from circular 43038107 (2021-12-02, 1443-04-27 H). Both In-Force with no later version on 2026-09-18. The appendix notes that the Central Component's code dictionary may be updated from time to time.", "source_edition": "OR 42068309 (2021-05-05); CP 43038107 (2021-12-02); GPC pages as read 2026-09-18", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://rulebook.sama.gov.sa/en/operating-rules-cross-currency-payments-using-afaq-service", "source_class": "public_primary", "source_title": "Operating Rules for Cross Currency Payments using AFAQ Service (SAMA circular 42068309)", "checked_on": "2026-09-19", "checked_by": "gcc-afaq validator session", "notes": "Confirms the return trigger and same-business-day-preferred, two-business-day-maximum window with no use-of-funds liability inside it (OR 7.8), the joint-business-day counting rule (OR 7.9), the exact match requirement on reference, currency codes, amounts and rate with no deduction (OR 7.9), and the four checks the Central Component makes on a return (OR 7.9, matching RJ20 to RJ23), word for word against the record's reading." }, { "source_url": "https://rulebook.sama.gov.sa/en/charging-policy-cross-currency-payments-using-afaq-service", "source_class": "public_primary", "source_title": "Charging Policy for Cross Currency Payments Using AFAQ Service (SAMA circular 43038107)", "checked_on": "2026-09-19", "checked_by": "gcc-afaq validator session", "notes": "Confirms the SAR 100 late-return penalty, the possible additional charge tied to the amount, and the duty to report a late return to SAMA (CP 4.2)." }, { "source_url": "https://www.gulf-payments.com/en/faqs/", "source_class": "public_primary", "source_title": "Gulf Payments Company, AFAQ FAQs", "checked_on": "2026-09-19", "checked_by": "gcc-afaq validator session", "notes": "Confirms that return payments must have the same exchange rate and currency amounts as the originally received payment with no deductions, matching the record's same-rate, no-deduction claim." } ] }, "rail_name": "GCC AFAQ (cross-currency payments)", "governing_authority": "SAMA (Saudi participant rules); GCC central banks via GPC (system)", "snapshot": "2026-09-18", "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "gcc-afaq:settlement", "id": "settlement", "rail": "gcc-afaq", "kind": "rail-fact", "facet": "settlement", "name": "How and when do AFAQ payments settle, and between whom?", "statement": "AFAQ settles in central bank money, in two layers. Each payment settles gross and in real time between the sending and receiving participants, through accounts their central banks hold for them, with the sender paying in its own currency and the receiver credited in its own at a rate the central banks fixed that morning. The central banks then settle the day's net positions with each other once, in a window at the end of the business day, through a settlement agent that no public text read names. Saudi participants work from a dedicated AFAQ account at SAMA that they fund each morning from their SARIE RTGS account and that SAMA sweeps back to zero after the day's settlement.", "details": [ { "label": "Participant layer: gross and immediate", "value": "In the standard set-up, the sending country's domestic RTGS checks funds, debits the sending participant and credits the receiving central bank; the receiving country's RTGS debits the sending central bank and credits the receiving participant. The Central Component mirrors these moves on shadow accounts it keeps for each central bank.", "citation": "SAMA, Operating Rules for Cross Currency Payments using AFAQ Service, circular 42068309 of 2021-05-05 (1442-09-24 H), sections 4.1.1, 4.1.5 and 4.1.6", "rests_on": "rule" }, { "label": "SAMA's model: booking inside the Central Component", "value": "SAMA does not route AFAQ payments through its own domestic RTGS in real time. Under its Country Specific Model the Central Component, which GPC hosts and SAMA controls, keeps the Saudi participants' accounts and books both legs: the participant's settlement account against the other central bank's shadow account, in each currency, all posted at once.", "citation": "OR 42068309 sections 2.2, 4.1.7, 4.2, 4.3 and 7.3", "rests_on": "rule" }, { "label": "Saudi funding and sweep", "value": "A Saudi participant that wants to pay on a given day must first move riyals from its SARIE RTGS account to its AFAQ account at SAMA, with an interbank payment to SAMA that carries the routing code AFAQSD100, and keep enough there to cover every payment it sends. After the central banks' end-of-day settlement, SAMA reconciles and moves whatever is left back to the participant's RTGS current account. Liquidity management is the participant's own job; SAMA does not watch it.", "citation": "OR 42068309 sections 4.7, 4.19 and 5.1 items 5 and 12", "rests_on": "rule" }, { "label": "Currency conversion", "value": "Each morning the central banks send their currency's official rate against the US dollar, the Central Component works out every GCC cross-rate, and each central bank approves or declines it; a pair left unconfirmed cannot be used that day. The confirmed rate then applies to every payment in that pair for the whole business day, and the sender must state both currency amounts and the rate in the message.", "citation": "OR 42068309 section 1 (Confirmed Exchange Rate), section 5.1 items 2 to 4, and section 6; GPC, AFAQ FAQs, Exchange Rates (read 2026-09-18)", "rests_on": "rule" }, { "label": "Central bank layer: end-of-day net", "value": "After the exchange periods close, statements and net position reports go out, every central bank reconciles and confirms its net position, and settlement runs in a closing window. GPC's timetable places the reporting and confirmation step at 15:00 to 15:30 and the net settlement window at 15:30 to 16:00, Saudi time. The settlement agent that carries out this step is not named in any public text read.", "citation": "OR 42068309 section 5.1 items 9 to 11; GPC, Working Hours and Official Holidays page (read 2026-09-18)", "rests_on": "rule" }, { "label": "How the operator summarises it", "value": "GPC says participant accounts stay in each country's domestic RTGS, payments settle across the central banks' primary accounts with shadow postings in the Central Component, and every payment is converted at the day's fixed rate.", "citation": "GPC, Facilitating cross-border payments in GCC (interview reprint, 2023-06-19)", "rests_on": "guidance" } ], "exceptions": [ "Participants in the other five GCC countries fund and settle through their own central bank's domestic RTGS and gateway; whether any of them also uses a Country Specific Model like SAMA's was not established.", "SAMA may extend hours, switch to contingency arrangements or shut the service in an emergency, and may move the cut-off on request for a fee (OR 42068309 sections 5.4 and 8.3; SAMA Charging Policy circular 43038107 section 4.1).", "Payments in a currency pair whose rate was not confirmed that morning do not settle at all; they are refused." ], "applies_to": "AFAQ cross-currency payments among the six GCC countries; the funding and sweep lines apply to Saudi direct participants only", "caveat": "Two layers, two answers. If asked whether AFAQ is RTGS, the answer is yes for participants; if asked how central banks settle, it is end-of-day net. Do not describe the Saudi AFAQ account as the participant's SARIE RTGS account; it is a separate account funded from it.", "related": [ "gcc-afaq:finality", "gcc-afaq:hours", "gcc-afaq:participants", "gcc-afaq-reject:RJ19", "gcc-afaq-reject:RJ11" ], "basis": { "sources": "SAMA rulebook portal, English pages read 2026-09-18: Operating Rules for Cross Currency Payments using AFAQ Service, circular 42068309 (2021-05-05), sections 1, 2.2, 4.1 to 4.3, 4.7, 4.19, 5.1, 6 and 7.3; Charging Policy for Cross Currency Payments Using AFAQ Service, circular 43038107 (2021-12-02), section 4.1. Portal pages carry no legal effect by the portal's own terms (public_primary). Gulf Payments Company pages read 2026-09-18: Working Hours and Official Holidays, AFAQ FAQs, and the 2023 interview reprint. The GPC Operating Rules and Regulations were not used. Nothing is quoted.", "confidence": "medium" }, "currency": { "effective_since": "2021-05-05", "effective_note": "Dated from SAMA circular 42068309 (2021-05-05, 1442-09-24 H), In-Force with no later version on 2026-09-18. The GPC timetable times are from an undated live page read 2026-09-18.", "source_edition": "OR 42068309 (2021-05-05); CP 43038107 (2021-12-02); GPC pages as read 2026-09-18", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://rulebook.sama.gov.sa/en/operating-rules-cross-currency-payments-using-afaq-service", "source_class": "public_primary", "source_title": "Operating Rules for Cross Currency Payments using AFAQ Service (SAMA circular 42068309)", "checked_on": "2026-09-19", "checked_by": "gcc-afaq validator session", "notes": "Confirms the participant-layer processing entries (OR 4.1.1, 4.1.5, 4.1.6), the Country Specific Model booking inside the Central Component (OR 2.2, 4.1.7, 4.2, 4.3, 7.3), Saudi prefunding through SARIE with routing code AFAQSD100 and the end-of-day sweep (OR 4.7, 4.19, 5.1 items 5 and 12), and the daily rate confirmation process (OR 1, 5.1 items 2 to 4, section 6)." }, { "source_url": "https://www.gulf-payments.com/en/afaq-cross-currency-service/", "source_class": "public_primary", "source_title": "Gulf Payments Company, Working Hours and Official Holidays page", "checked_on": "2026-09-19", "checked_by": "gcc-afaq validator session", "notes": "Confirms the 15:00 to 15:30 reporting, reconciliation and confirmation window and the 15:30 to 16:00 net settlement window, Saudi time, cited for the central bank layer's end-of-day timing." }, { "source_url": "https://www.gulf-payments.com/en/gpc_news/facilitating-cross-border-payments-in-gcc/", "source_class": "public_primary", "source_title": "Gulf Payments Company, Facilitating cross-border payments in GCC (interview reprint, 2023-06-19)", "checked_on": "2026-09-19", "checked_by": "gcc-afaq validator session", "notes": "Confirms the operator's summary that participant accounts stay in each country's domestic RTGS, payments settle over the central banks' Inter-NCB Primary accounts with shadow postings in the Central Component, and each payment converts at the day's fixed rate." } ] }, "rail_name": "GCC AFAQ (cross-currency payments)", "governing_authority": "SAMA (Saudi participant rules); GCC central banks via GPC (system)", "snapshot": "2026-09-18", "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "google-pay:consumer-law", "id": "consumer-law", "rail": "google-pay", "kind": "rail-fact", "facet": "consumer-law", "name": "What consumer protection reaches a Google Pay payment?", "statement": "Whatever reaches the card, because the card is what pays; the wallet creates nothing and removes nothing. The one legal requirement Google states for itself is strong customer authentication: online payment transactions processed in European Economic Area countries must comply with it under the second Payment Services Directive, and Google's part is to return either an authenticated payload the merchant can process without a further challenge or a card number the merchant must put through 3-D Secure 2.0, in house or through its payment service provider. The rest of what the terms impose is data duty rather than payment protection: the merchant is solely responsible for its use of the buyer's personal information under the law, its acquiring agreement, its privacy policy and the network rules, may use it only for the current transaction and its post-transaction activities unless the buyer consents to more, and shares independent controller status with Google under European Union data protection law. No consumer payment law was read for this rail.", "details": [ { "label": "Payments processed in the European Economic Area must meet strong customer authentication", "value": "Google tells merchants that online payment transactions processed in European Economic Area countries must comply with strong customer authentication under the second Payment Services Directive. The directive is the rule; what is recorded here is Google's description of it and of what Google does about it, because the directive itself was not read. To let Google return the right credential for such a transaction, a merchant on version 2 of the API sends the merchant name that is rendered on the payment sheet, the country code of where the transaction is processed, which is the acquirer bank country, and the total price. The merchant then receives either an authenticated payload it can process without a further step-up or challenge, or a card number it must put through 3-D Secure 2.0, in house or through its payment service provider. Google adds that where assuranceDetails reports the cardholder was not authenticated, the merchant should apply the appropriate instrument risk checks and step the transaction up.", "citation": "SCA and Google Pay API, whole page", "rests_on": "guidance" }, { "label": "What a merchant may do with the buyer's personal information", "value": "The merchant is solely responsible for its use of End User personal information, including payment account information, complying with the law, its card acquiring agreement, its privacy policy and other applicable rules such as network rules. It may use personal information the API provides only to process the current transaction and to carry out post-transaction activities for that transaction, and the terms give a chargeback as the example, unless the End User has expressly consented to other uses. Google and the merchant are each independent controllers of personal information subject to European Union data protection law, each determining its own purposes and means. The merchant must keep administrative, technical and physical controls that meet or exceed industry standards, limit who may see the information, keep an incident response programme and notify Google promptly of a security incident, and Google may ask for reasonably acceptable verification of compliance.", "citation": "Google Pay API Terms of Service (effective 2021-03-01), sections 5 and 6", "rests_on": "rule" }, { "label": "Google is not a party to the sale", "value": "Google only enables a transaction by sharing payment credentials. The sale is solely between the merchant and the End User who buys from it, and Google is not a party to it. Google is not and will not be responsible for any aspect of the products or services the merchant sells, and it is not responsible for what End Users do, including not completing a transaction. So nothing in the wallet decides whether a payment is final, whether it can be undone, or who bears a loss.", "citation": "Google Pay API Terms of Service (effective 2021-03-01), section 1, first three bullets", "rests_on": "rule" }, { "label": "The merchant alone resolves disputes with its buyers", "value": "The merchant is solely responsible for investigating and resolving disputes with its End Users. Google is not a party to a dispute and will not be responsible for one. Read with the clause saying Google's enablement does not mean a transaction will not later be charged back, the terms place the whole dispute layer outside the wallet: with the issuer, the acquirer and the network's rules.", "citation": "Google Pay API Terms of Service (effective 2021-03-01), section 1, sixth bullet", "rests_on": "rule" } ], "exceptions": [ "A card-on-file payment is the case where the merchant has to step up itself, because Google returns a card number rather than an authenticated payload.", "The terms carry a governing law and arbitration section that applies where the API is accessed or used in Central America, South America or China, naming California law and expedited arbitration in Santa Clara County." ], "applies_to": "Google Pay used to pay a merchant with a credit, debit or prepaid card, on the web, in the two forms the API returns: a card stored as an Android device token (CRYPTOGRAM_3DS) and a card stored on file with the user's Google Account (PAN_ONLY). Not Google's stored balance or bank transfer features, not Google Pay in India, not Google Wallet passes, and not a purchase from Google itself.", "caveat": "The second Payment Services Directive itself was not read. This record says what Google tells merchants the requirement is and what Google returns, not what the law gives a buyer.", "related": [ "visa:consumer-law", "mastercard:consumer-law", "apple-pay:consumer-law" ], "basis": { "sources": "SCA and Google Pay API, read in full; Google Pay API Terms of Service sections 1, 5, 6 and 9; read 2026-09-20.", "confidence": "medium" }, "currency": { "effective_since": "2025-03-11", "effective_to": null, "effective_note": "Drafted 2026-09-20 from the Google pages saved that day. The date is the effective date the Google Pay API Terms of Service state for themselves; the developer pages carry their own last-updated dates and each Rule dates its own source. Nothing here dates the card network's rules, which change with their own rulebooks and are held in the visa and mastercard rails.", "source_edition": "SCA and Google Pay API, last updated 2025-03-11 UTC as the page states, read in full 2026-09-20 from the copy saved that day", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://developers.google.com/pay/api/web/guides/resources/sca", "source_class": "public_primary", "source_title": "SCA and Google Pay API", "checked_on": "2026-09-20", "checked_by": "validator-pass-through-wallets-2026-09-20", "notes": "Confirms Google's statement that transactions processed in European Economic Area countries must meet strong customer authentication under the second Payment Services Directive." } ] }, "rail_name": "Google Pay (pass-through wallet)", "governing_authority": "Google LLC, through the Google Pay API Terms of Service and the Google Pay and Wallet APIs Acceptable Use Policy, for the wallet's own rules; the card network, the card issuer and the merchant's card acquiring bank for the payment itself", "snapshot": "2026-09-20", "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "google-pay:decision-points", "id": "decision-points", "rail": "google-pay", "kind": "rail-fact", "facet": "decision-points", "name": "Who decides what, and when, in a Google Pay payment?", "statement": "The merchant decides most of what the wallet can decide, and the issuer decides the payment. Before checkout the merchant sets its card parameters, choosing which authentication methods, card networks, card classes and issuer countries it will take, and it may call isReadyToPay only to decide whether to show or hide Google Pay, deleting the data straight afterwards. The buyer picks a card and completes the sheet. The merchant then verifies the payload in order, checking the intermediate signing key against a non-expired root key, checking it has not expired, checking the payload signature, decrypting, checking the message has not expired, and only then charging the payment method. Reading assuranceDetails and, for a card-on-file payment or an unauthenticated one, running 3-D Secure, is the merchant's call too. The issuer authorises. Google's own decisions are about conduct rather than payments: it may change its acceptable use policy at any time, enforce it at its sole discretion, take corrective action, disable a transaction or a partner account for any reason it deems prudent, require a merchant to drop a platform provider, and update or modify the API.", "details": [ { "label": "What else the merchant's card parameters decide", "value": "Besides the authentication methods, the card parameters name the card networks the merchant supports out of those the API supports, and Google's page lists AMEX, DISCOVER, INTERAC, JCB, MASTERCARD and VISA, with a separate list for tokenised Brazilian debit and credit combo cards, which also needs the transaction country code set to BR. The merchant may turn off prepaid cards and credit cards, each of which is otherwise supported for the networks it names, and credit cards are a required setting for United Kingdom gambling merchants. It may set an issuer country allow list or a block list of ISO 3166-1 alpha-2 codes, but not both, because the two are mutually exclusive; with neither, a user may choose a payment method issued anywhere. Google filters the cards a payer sees by these options. A billing address can be requested, and Google warns that asking for more data adds friction.", "citation": "Google Pay API for web, request objects reference, CardParameters", "rests_on": "rule" }, { "label": "What the isReadyToPay call may be used for", "value": "A merchant agrees to use the isReadyToPay API only to decide whether to show or suppress Google Pay as a payment option during checkout, and to delete any data it receives from that call immediately afterwards. Google may update or modify the API at its discretion.", "citation": "Google Pay API Terms of Service (effective 2021-03-01), section 3, first paragraph", "rests_on": "rule" }, { "label": "The steps a merchant runs before it charges the payment method", "value": "To consume a version 2 payment method token an integrator fetches Google's root signing keys; verifies that the signature of the intermediate signing key is valid under one of the non-expired root signing keys; verifies that the intermediate signing key has not expired; verifies that the payload's signature is valid under that intermediate key; decrypts the payload only after the signature has been verified; verifies that the message has not expired, by checking that the current time is earlier than messageExpiration; and only then uses the payment method in the decrypted contents and charges it. Google strongly recommends its Tink library, which performs the first six steps.", "citation": "Payment data cryptography for merchants, steps for consuming the payload", "rests_on": "rule" }, { "label": "What assuranceDetails says about the credential", "value": "Where a merchant sets assuranceDetailsRequired to true in its card parameters, the response carries an assurance details object describing what validation was performed on the returned credential, so that the right instrument risk checks can be applied. Its accountVerified field, when true, says cardholder possession validation has been performed. Its cardHolderAuthenticated field, when true, says identification and verification has been performed; when false, Google says the merchant can run the same risk-based authentication it would for a card transaction, which can include a step-up with the 3-D Secure protocol where applicable. Google adds that where both are true no step-up of the returned credential is needed, and where neither is, it recommends the same risk checks and authentication, including a 3-D Secure flow where applicable. A merchant can receive and process the response without using the field at all.", "citation": "Google Pay API for web, response objects reference, CardInfo, assuranceDetails; AssuranceDetailsSpecifications; Google Pay API for web, request objects reference, CardParameters, assuranceDetailsRequired", "rests_on": "rule" }, { "label": "Google may change the policy and act against a transaction or a partner", "value": "Google reserves the right to expand or edit the acceptable use policy at any time, and exercises its sole discretion in interpreting and enforcing it together with the applicable terms of service. It also reserves the right to take any corrective action it deems appropriate where it believes or suspects that a partner or a transaction breaks the policy or is otherwise illegal or unsuitable, or to disable any transaction or partner account for any reason it deems prudent, and it may report illegal activity as the law allows. No notice period, procedure or route of review is given.", "citation": "Google Pay and Wallet APIs Acceptable Use Policy, opening paragraphs", "rests_on": "rule" }, { "label": "A platform provider acts only for the merchant", "value": "Unless Google says otherwise, a merchant may arrange for a platform provider to help it integrate its payment transaction interfaces with the API. That provider must act exclusively on the merchant's behalf and in accordance with its own written agreement with Google. Google may require the merchant to disengage from it where, in Google's discretion, the provider contributed to a breach of the terms or to other harm to Google.", "citation": "Google Pay API Terms of Service (effective 2021-03-01), section 3, second paragraph", "rests_on": "rule" } ], "exceptions": [ "Google's rights to act against a transaction or a partner carry no notice period, no procedure and no review on the pages read.", "Nothing on the pages read says what a merchant tells the buyer or Google when it rejects a payload." ], "applies_to": "Google Pay used to pay a merchant with a credit, debit or prepaid card, on the web, in the two forms the API returns: a card stored as an Android device token (CRYPTOGRAM_3DS) and a card stored on file with the user's Google Account (PAN_ONLY). Not Google's stored balance or bank transfer features, not Google Pay in India, not Google Wallet passes, and not a purchase from Google itself.", "caveat": "The decision that matters most to the payment, whether the issuer authorises it, is not on this rail at all. Read visa:decision-points or mastercard:decision-points for it.", "related": [ "visa:decision-points", "mastercard:decision-points", "apple-pay:decision-points" ], "basis": { "sources": "Payment data cryptography; request objects reference; response objects reference; Google Pay API Terms of Service section 3; Google Pay and Wallet APIs Acceptable Use Policy; read 2026-09-20.", "confidence": "medium" }, "currency": { "effective_since": "2026-02-20", "effective_to": null, "effective_note": "Drafted 2026-09-20 from the Google pages saved that day. The date is the effective date the Google Pay API Terms of Service state for themselves; the developer pages carry their own last-updated dates and each Rule dates its own source. Nothing here dates the card network's rules, which change with their own rulebooks and are held in the visa and mastercard rails.", "source_edition": "Payment data cryptography for merchants, last updated 2026-02-20 UTC as the page states, read in full 2026-09-20 from the copy saved that day", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://developers.google.com/pay/api/web/reference/request-objects", "source_class": "authoritative_primary", "source_title": "Google Pay API for web, request objects reference", "checked_on": "2026-09-20", "checked_by": "validator-pass-through-wallets-2026-09-20", "notes": "Confirms the merchant sets its own card parameters and may use isReadyToPay only to decide whether to show or hide Google Pay." } ] }, "rail_name": "Google Pay (pass-through wallet)", "governing_authority": "Google LLC, through the Google Pay API Terms of Service and the Google Pay and Wallet APIs Acceptable Use Policy, for the wallet's own rules; the card network, the card issuer and the merchant's card acquiring bank for the payment itself", "snapshot": "2026-09-20", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "google-pay:finality", "id": "finality", "rail": "google-pay", "kind": "rail-fact", "facet": "finality", "name": "When is a Google Pay payment final, and can it be undone?", "statement": "Google Pay decides neither, and says so itself. Google only enables a transaction by sharing payment credentials; the sale is solely between the merchant and the buyer, and Google is not a party to it. The terms go further than most: Google enabling a transaction does not mean the instrument has enough money, that the transaction will be authorised or processed, or that it will not later be charged back or otherwise reversed. So a completed Google Pay sheet is not a payment taken. Finality belongs to the card network, the issuer and the merchant's acquiring agreement. What the wallet does rule is narrower: the merchant verifies the signed payload and rejects one whose signature fails or whose message has expired, and then nothing is presented at all.", "details": [ { "label": "Google is not a party to the sale", "value": "Google only enables a transaction by sharing payment credentials. The sale is solely between the merchant and the End User who buys from it, and Google is not a party to it. Google is not and will not be responsible for any aspect of the products or services the merchant sells, and it is not responsible for what End Users do, including not completing a transaction. So nothing in the wallet decides whether a payment is final, whether it can be undone, or who bears a loss.", "citation": "Google Pay API Terms of Service (effective 2021-03-01), section 1, first three bullets", "rests_on": "rule" }, { "label": "Enabling a payment promises neither authorisation nor freedom from chargeback", "value": "Google enabling a transaction does not mean the End User has enough money in the instrument they used, that the transaction will be authorised or processed, or that it will not later result in a chargeback or another reversal. This is the wallet saying in its own terms that the outcome belongs to the issuer and the network. A merchant that treats the Google Pay sheet completing as a payment taken has misread the terms.", "citation": "Google Pay API Terms of Service (effective 2021-03-01), section 1, fourth bullet", "rests_on": "rule" }, { "label": "The merchant must hold its own card acquiring agreement", "value": "The merchant is solely responsible for establishing a payment card acquiring agreement with a card acquiring bank for processing transactions, and for all the fees, charges and expenses that relationship brings. It must comply with that agreement and with any applicable payment network rules. Google supplies no acquiring, no clearing and no settlement, and takes no responsibility for any of them.", "citation": "Google Pay API Terms of Service (effective 2021-03-01), section 1, fifth bullet", "rests_on": "rule" }, { "label": "The steps a merchant runs before it charges the payment method", "value": "To consume a version 2 payment method token an integrator fetches Google's root signing keys; verifies that the signature of the intermediate signing key is valid under one of the non-expired root signing keys; verifies that the intermediate signing key has not expired; verifies that the payload's signature is valid under that intermediate key; decrypts the payload only after the signature has been verified; verifies that the message has not expired, by checking that the current time is earlier than messageExpiration; and only then uses the payment method in the decrypted contents and charges it. Google strongly recommends its Tink library, which performs the first six steps.", "citation": "Payment data cryptography for merchants, steps for consuming the payload", "rests_on": "rule" }, { "label": "The payload expires, and an expired one must be rejected", "value": "The decrypted payload carries messageExpiration, the time the message expires given as UTC milliseconds since the epoch, and an integrator should reject any message that has expired. Checking that the current time is earlier than messageExpiration is one of the steps for consuming the payload, and the intermediate signing key must also be checked for expiry before its signature is trusted. Google publishes no figure for how long a payload lives, so the clock is read from the field rather than from a rule. The wallet keeps no operating hours and no settlement calendar, because it settles nothing.", "citation": "Payment data cryptography for merchants, steps for consuming the payload; encrypted message, messageExpiration", "rests_on": "rule" } ], "exceptions": [ "Before anything is presented, a failed payload check ends it: the merchant does not charge the payment method.", "Google may disable a transaction or a partner account under the acceptable use policy, which stops future payments but does nothing to payments already made." ], "applies_to": "Google Pay used to pay a merchant with a credit, debit or prepaid card, on the web, in the two forms the API returns: a card stored as an Android device token (CRYPTOGRAM_3DS) and a card stored on file with the user's Google Account (PAN_ONLY). Not Google's stored balance or bank transfer features, not Google Pay in India, not Google Wallet passes, and not a purchase from Google itself.", "caveat": "Do not answer whether a Google Pay payment is final from this record. It says who answers, and the answer is in visa:finality or mastercard:finality. The credential form does not change that: a device-token payment and a card-on-file payment are both card payments to the network.", "related": [ "visa:finality", "mastercard:finality", "apple-pay:finality" ], "basis": { "sources": "Google Pay API Terms of Service section 1; payment data cryptography; read 2026-09-20. No Visa or Mastercard document was read for this rail.", "confidence": "high" }, "currency": { "effective_since": "2021-03-01", "effective_to": null, "effective_note": "Drafted 2026-09-20 from the Google pages saved that day. The date is the effective date the Google Pay API Terms of Service state for themselves; the developer pages carry their own last-updated dates and each Rule dates its own source. Nothing here dates the card network's rules, which change with their own rulebooks and are held in the visa and mastercard rails.", "source_edition": "Google Pay API Terms of Service, effective 2021-03-01 as the page states, read in full 2026-09-20 from the copy saved that day", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://payments.developers.google.com/terms/sellertos", "source_class": "authoritative_primary", "source_title": "Google Pay API Terms of Service (effective 2021-03-01)", "checked_on": "2026-09-20", "checked_by": "validator-pass-through-wallets-2026-09-20", "notes": "Confirms Google is not a party to the sale and that its enablement of a transaction does not mean it will be authorised, processed or free of a later chargeback." } ] }, "rail_name": "Google Pay (pass-through wallet)", "governing_authority": "Google LLC, through the Google Pay API Terms of Service and the Google Pay and Wallet APIs Acceptable Use Policy, for the wallet's own rules; the card network, the card issuer and the merchant's card acquiring bank for the payment itself", "snapshot": "2026-09-20", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "google-pay:hours", "id": "hours", "rail": "google-pay", "kind": "rail-fact", "facet": "hours", "name": "When does Google Pay operate, and what deadlines does it set?", "statement": "Google Pay keeps no operating hours, no cut-off times and no settlement calendar, because it settles nothing. The one clock it sets is per message and is a security clock: the decrypted payload carries messageExpiration, the moment the message expires as UTC milliseconds since the epoch, and the merchant should reject any message past it. Checking that is one of the steps for consuming a payload, and the intermediate signing key must also be checked for expiry before its signature is trusted. Google publishes no figure for how long a payload lives, so there is no duration to record, only a field to read. Every timing that decides a payment belongs to the card network.", "details": [ { "label": "The payload expires, and an expired one must be rejected", "value": "The decrypted payload carries messageExpiration, the time the message expires given as UTC milliseconds since the epoch, and an integrator should reject any message that has expired. Checking that the current time is earlier than messageExpiration is one of the steps for consuming the payload, and the intermediate signing key must also be checked for expiry before its signature is trusted. Google publishes no figure for how long a payload lives, so the clock is read from the field rather than from a rule. The wallet keeps no operating hours and no settlement calendar, because it settles nothing.", "citation": "Payment data cryptography for merchants, steps for consuming the payload; encrypted message, messageExpiration", "rests_on": "rule" }, { "label": "The steps a merchant runs before it charges the payment method", "value": "To consume a version 2 payment method token an integrator fetches Google's root signing keys; verifies that the signature of the intermediate signing key is valid under one of the non-expired root signing keys; verifies that the intermediate signing key has not expired; verifies that the payload's signature is valid under that intermediate key; decrypts the payload only after the signature has been verified; verifies that the message has not expired, by checking that the current time is earlier than messageExpiration; and only then uses the payment method in the decrypted contents and charges it. Google strongly recommends its Tink library, which performs the first six steps.", "citation": "Payment data cryptography for merchants, steps for consuming the payload", "rests_on": "rule" } ], "exceptions": [ "The expiry is carried per message as an absolute time, so there is no fixed window to quote and none is recorded here." ], "applies_to": "Google Pay used to pay a merchant with a credit, debit or prepaid card, on the web, in the two forms the API returns: a card stored as an Android device token (CRYPTOGRAM_3DS) and a card stored on file with the user's Google Account (PAN_ONLY). Not Google's stored balance or bank transfer features, not Google Pay in India, not Google Wallet passes, and not a purchase from Google itself.", "caveat": "messageExpiration is not a Core time window in this record: the schema types a duration or a daily deadline, and this is an absolute time set per message, so it lives in the Rule's statement and cannot be queried.", "related": [ "visa:hours", "mastercard:hours", "apple-pay:hours" ], "basis": { "sources": "Payment data cryptography, read in full 2026-09-20.", "confidence": "high" }, "currency": { "effective_since": "2026-02-20", "effective_to": null, "effective_note": "Drafted 2026-09-20 from the Google pages saved that day. The date is the effective date the Google Pay API Terms of Service state for themselves; the developer pages carry their own last-updated dates and each Rule dates its own source. Nothing here dates the card network's rules, which change with their own rulebooks and are held in the visa and mastercard rails.", "source_edition": "Payment data cryptography for merchants, last updated 2026-02-20 UTC as the page states, read in full 2026-09-20 from the copy saved that day", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://developers.google.com/pay/api/web/guides/resources/payment-data-cryptography", "source_class": "authoritative_primary", "source_title": "Payment data cryptography for merchants", "checked_on": "2026-09-20", "checked_by": "validator-pass-through-wallets-2026-09-20", "notes": "Confirms the payload's messageExpiration field is the only timing rule Google states, with no figure published for how long a payload lives." } ] }, "rail_name": "Google Pay (pass-through wallet)", "governing_authority": "Google LLC, through the Google Pay API Terms of Service and the Google Pay and Wallet APIs Acceptable Use Policy, for the wallet's own rules; the card network, the card issuer and the merchant's card acquiring bank for the payment itself", "snapshot": "2026-09-20", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "google-pay:liability", "id": "liability", "rail": "google-pay", "kind": "rail-fact", "facet": "liability", "name": "Who bears the loss when a Google Pay payment goes wrong?", "statement": "Not Google, by its own terms, and the rest depends on which credential was used. Google is not a party to the sale, promises neither authorisation nor freedom from chargeback, and tells merchants that its own validation and fraud checks are not meant to replace their risk management. What Google supplies is information about the credential rather than a liability rule. For a device-token payment the payload carries a 3-D Secure cryptogram and, sometimes, an eciIndicator the merchant must pass on unaltered or the transaction fails; Google also prints a table pairing ECI values with a liable party for Visa and Mastercard, which is Google restating the networks' rules and not the governing text. For a card-on-file payment there is no cryptogram, no ECI value and no entry in that table: it is an ordinary card-absent card payment, and the merchant steps it up with 3-D Secure where the transaction needs it. Either way, assuranceDetails is what tells the merchant whether possession was validated and whether the cardholder was identified and verified, and who finally pays is the card network's rule.", "details": [ { "label": "Google is not a party to the sale", "value": "Google only enables a transaction by sharing payment credentials. The sale is solely between the merchant and the End User who buys from it, and Google is not a party to it. Google is not and will not be responsible for any aspect of the products or services the merchant sells, and it is not responsible for what End Users do, including not completing a transaction. So nothing in the wallet decides whether a payment is final, whether it can be undone, or who bears a loss.", "citation": "Google Pay API Terms of Service (effective 2021-03-01), section 1, first three bullets", "rests_on": "rule" }, { "label": "A card-on-file payment is not a tokenised payment, and the token rules do not reach it", "value": "PAN_ONLY is the authentication method for payment cards stored on file with the user's Google Account, and the payment data it returns is the personal account number with the expiration month and the expiration year. There is no cryptogram, no eciIndicator and no device account number. CRYPTOGRAM_3DS is the authentication method for cards stored as Android device tokens, and it returns a 3-D Secure cryptogram generated on the device. The difference matters beyond the fields: a card-on-file payment is an ordinary card-absent card payment that Google filled in, so every rule written for a device token, including the duty to pass an ECI indicator on and Google's liable-party table, reaches CRYPTOGRAM_3DS and nothing else. Where such a payment needs strong customer authentication, or where assuranceDetails reports the cardholder was not authenticated, the merchant runs 3-D Secure itself or through its payment service provider.", "citation": "Google Pay API for web, request objects reference, CardParameters, allowedAuthMethods; Payment data cryptography for merchants, PAN_ONLY; CRYPTOGRAM_3DS; eciIndicator; SCA and Google Pay API, Handle the response object", "rests_on": "rule" }, { "label": "The merchant keeps its own risk checks", "value": "Google tells merchants to make sure their existing risk checks and controls for payment transactions apply to Google Pay transactions too, because Google's own validation and fraud checks are not meant to replace a merchant's risk management. The note sits on the authentication methods field, so it covers both the device-token and the card-on-file credential.", "citation": "Google Pay API for web, request objects reference, CardParameters, allowedAuthMethods, the important note", "rests_on": "rule" }, { "label": "What assuranceDetails says about the credential", "value": "Where a merchant sets assuranceDetailsRequired to true in its card parameters, the response carries an assurance details object describing what validation was performed on the returned credential, so that the right instrument risk checks can be applied. Its accountVerified field, when true, says cardholder possession validation has been performed. Its cardHolderAuthenticated field, when true, says identification and verification has been performed; when false, Google says the merchant can run the same risk-based authentication it would for a card transaction, which can include a step-up with the 3-D Secure protocol where applicable. Google adds that where both are true no step-up of the returned credential is needed, and where neither is, it recommends the same risk checks and authentication, including a 3-D Secure flow where applicable. A merchant can receive and process the response without using the field at all.", "citation": "Google Pay API for web, response objects reference, CardInfo, assuranceDetails; AssuranceDetailsSpecifications; Google Pay API for web, request objects reference, CardParameters, assuranceDetailsRequired", "rests_on": "rule" }, { "label": "An ECI indicator must be passed on unaltered, and only device tokens carry one", "value": "The card network might provide an eciIndicator for an authenticated device-token transaction. Where it does, the merchant must pass that value on in the authorisation without altering it and without hardcoding it, or the transaction fails. The field is not always present, and it returns only for authenticated device-token transactions on Android, which is to say only for the CRYPTOGRAM_3DS authentication method. A card-on-file payment never carries one.", "citation": "Payment data cryptography for merchants, CRYPTOGRAM_3DS; eciIndicator", "rests_on": "rule" }, { "label": "Google's liable-party table is Google describing network rules, not setting them", "value": "Google prints a table pairing eciIndicator values with a card network and a liable party, for the CRYPTOGRAM_3DS authentication method only: for Mastercard an empty value and 06 against the merchant or acquirer and 02 against the card issuer, for Visa 07 against the merchant or acquirer and 05 against the card issuer, and an empty value against the merchant or acquirer for other networks. Google adds that no other Visa or Mastercard ECI value will be returned. This table is a wallet operator restating the card networks' rules. It is not the governing text, it says nothing about a card-on-file payment, and it states a bare ECI value where a network rule may turn on more than that. Orca does not carry a liability line on this table: the network's own rules are held in the visa and mastercard rails and in the Visa dispute conditions, and they govern.", "citation": "Payment data cryptography for merchants, eciIndicator table", "rests_on": "guidance" }, { "label": "Payments processed in the European Economic Area must meet strong customer authentication", "value": "Google tells merchants that online payment transactions processed in European Economic Area countries must comply with strong customer authentication under the second Payment Services Directive. The directive is the rule; what is recorded here is Google's description of it and of what Google does about it, because the directive itself was not read. To let Google return the right credential for such a transaction, a merchant on version 2 of the API sends the merchant name that is rendered on the payment sheet, the country code of where the transaction is processed, which is the acquirer bank country, and the total price. The merchant then receives either an authenticated payload it can process without a further step-up or challenge, or a card number it must put through 3-D Secure 2.0, in house or through its payment service provider. Google adds that where assuranceDetails reports the cardholder was not authenticated, the merchant should apply the appropriate instrument risk checks and step the transaction up.", "citation": "SCA and Google Pay API, whole page", "rests_on": "guidance" } ], "exceptions": [ "A merchant that receives an eciIndicator and does not pass it on unaltered fails the transaction outright, so no liability question arises.", "Where assuranceDetails reports both possession validation and cardholder authentication, Google says no step-up of the returned credential is needed; where neither, it recommends the merchant's usual risk checks and a 3-D Secure flow where applicable.", "A payment made with a Google merchant token for a merchant-initiated charge was not read for liability and is not answered here." ], "applies_to": "Google Pay used to pay a merchant with a credit, debit or prepaid card, on the web, in the two forms the API returns: a card stored as an Android device token (CRYPTOGRAM_3DS) and a card stored on file with the user's Google Account (PAN_ONLY). Not Google's stored balance or bank transfer features, not Google Pay in India, not Google Wallet passes, and not a purchase from Google itself.", "caveat": "Two traps. Google's ECI table is not a network rule: it covers device tokens only, states a bare ECI value where a network rule may turn on more, and the governing text is the network's own, so Orca carries no liability line resting on it. And the card-on-file credential is not a token: every device-token rule here, the cryptogram, the ECI value and the table, stops at CRYPTOGRAM_3DS.", "related": [ "visa:liability", "mastercard:liability", "visa-dispute:10.4", "visa-dispute:10.1", "apple-pay:liability" ], "basis": { "sources": "Google Pay API Terms of Service section 1; request objects reference; response objects reference; payment data cryptography; SCA and Google Pay API; read 2026-09-20. No Visa or Mastercard document was read for this rail, so no network liability line is stated here; the linked records hold them.", "confidence": "medium" }, "currency": { "effective_since": "2026-02-20", "effective_to": null, "effective_note": "Drafted 2026-09-20 from the Google pages saved that day. The date is the effective date the Google Pay API Terms of Service state for themselves; the developer pages carry their own last-updated dates and each Rule dates its own source. Nothing here dates the card network's rules, which change with their own rulebooks and are held in the visa and mastercard rails.", "source_edition": "Payment data cryptography for merchants, last updated 2026-02-20 UTC as the page states, read in full 2026-09-20 from the copy saved that day", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "rail_name": "Google Pay (pass-through wallet)", "governing_authority": "Google LLC, through the Google Pay API Terms of Service and the Google Pay and Wallet APIs Acceptable Use Policy, for the wallet's own rules; the card network, the card issuer and the merchant's card acquiring bank for the payment itself", "snapshot": "2026-09-20", "source_class": null, "effective_status": "draft", "effective_status_reason": null, "boundaries": [] }, { "uid": "google-pay:limits", "id": "limits", "rail": "google-pay", "kind": "rail-fact", "facet": "limits", "name": "What limits does Google Pay put on a payment or a merchant?", "statement": "No amount limit of Google's own was found in the pages read. The amount rule Google does set runs the other way: a merchant may not set a minimum or a maximum purchase amount specific to a buyer paying through the API, may not add a surcharge specific to such a buyer, and may not ask that buyer for card or other instrument account numbers on top of what the API returns. The rest of the limits are on what may be sold and by whom. The API may be used only for a payment a buyer starts for a genuine sale of the merchant's own products or services, not to move money that does not come from such a purchase; a merchant whose primary type is non-profit may take donations; digital goods may be sold through a web browser but not through mobile applications; and a merchant in regulated financial services warrants that it holds the licences. The acceptable use policy adds a long list of restricted products and services, and bars the staged wallet case where a second payment completes the first or a substitute merchant of record stands in. Google may change that policy at any time and enforce it at its sole discretion.", "details": [ { "label": "No buyer-specific minimum, maximum or surcharge, and no extra card numbers", "value": "Three things a merchant may not do. It may not set a minimum or a maximum purchase amount that applies specifically to an End User buying through the API. It may not require an End User to give it the account number of a credit card, debit card or other payment instrument on top of what the API provides. And it may not add a service use surcharge that applies specifically to an End User buying through the API. These are the only amount rules Google sets; no amount limit of Google's own was found in the pages read.", "citation": "Google Pay API Terms of Service (effective 2021-03-01), section 4", "rests_on": "rule" }, { "label": "The API may be used only for a genuine sale by the merchant", "value": "The API may be used only in connection with a payment transaction an End User starts for a bona fide sale of the merchant's own products or services, unless Google permits otherwise in writing. It may not be used to process a payment, or otherwise move money between the merchant and an End User, that does not come directly from that End User buying a product or service. A merchant that identifies its primary product or service type as non-profit, and that meets its own legal and other requirements, may use the API to receive donations. For digital products and services the terms apply only to transactions completed entirely through a web browser; a merchant selling digital products or services through mobile applications may not use the API and is pointed at In-App Billing. A merchant using the API for regulated financial services transactions warrants that it holds the licences and registrations, and Google expressly disclaims any obligation arising from that use.", "citation": "Google Pay API Terms of Service (effective 2021-03-01), section 2", "rests_on": "rule" }, { "label": "The product and service classes that may not use the APIs", "value": "A developer using the Google Pay or Google Wallet APIs as a biller or partner must keep to Google's restricted products and services policy, and the restriction holds whether the restricted goods are all of its inventory or only part of it. Grouped by what each restriction is about rather than as the page lists them, they come to five things. Licence-gated rather than barred: financial products and services, and healthcare content and services, each allowed only where the partner holds a relevant licence from, or is supervised by, a competent national authority, and gambling, allowed only in certain limited geographies and for restricted integration types and never where it is aimed at people who are underage or locally forbidden to gamble. Barred even so, inside those two gated areas: most cryptocurrency products and services, with an exception for buying or selling cryptocurrency for fiat money through regulated entities; binary options and comparable speculative products, and training or signals for trading them; personal loans repayable in full within sixty days of issue; multi-level marketing and get-rich-quick schemes; credit repair; debt collection; and on the healthcare side illegal or unapproved drugs, substances, pharmaceuticals and supplements, drug paraphernalia, miracle cures, and speculative or experimental treatments. Unlawful trade: counterfeit goods, the illegal sale of goods and services, unauthorised copyrighted material, anything by or for terrorist organisations, and soliciting donations for unlawful or illegitimate fundraising. Harm and content: goods that may cause damage, harm or injury such as guns, explosives and ammunition; adult products and services; anything sexualising minors or appealing to children while carrying adult themes, with Google reporting child sexual abuse imagery to the authorities; named classes of dating site; products or services designed to enable dishonest behaviour; hateful content; and tobacco and vaping products. And Google's own standing: use that falsely suggests Google endorses it, or that is likely to damage or reduce Google's goodwill or reputation.", "citation": "Google Pay and Wallet APIs Acceptable Use Policy, Restricted products and services", "rests_on": "rule" }, { "label": "A staged wallet may not sit behind Google Pay", "value": "Among the financial services the acceptable use policy prohibits is a transaction where a second payment transaction is carried out in order to complete the first, or where a substitute merchant of record stands in the transaction. That is the staged wallet case: the party Google Pay pays must be the party selling, and the credential must fund that sale directly rather than top up a balance that then pays the seller.", "citation": "Google Pay and Wallet APIs Acceptable Use Policy, Restricted products and services, Financial Services", "rests_on": "rule" }, { "label": "Google may change the policy and act against a transaction or a partner", "value": "Google reserves the right to expand or edit the acceptable use policy at any time, and exercises its sole discretion in interpreting and enforcing it together with the applicable terms of service. It also reserves the right to take any corrective action it deems appropriate where it believes or suspects that a partner or a transaction breaks the policy or is otherwise illegal or unsuitable, or to disable any transaction or partner account for any reason it deems prudent, and it may report illegal activity as the law allows. No notice period, procedure or route of review is given.", "citation": "Google Pay and Wallet APIs Acceptable Use Policy, opening paragraphs", "rests_on": "rule" }, { "label": "What else the merchant's card parameters decide", "value": "Besides the authentication methods, the card parameters name the card networks the merchant supports out of those the API supports, and Google's page lists AMEX, DISCOVER, INTERAC, JCB, MASTERCARD and VISA, with a separate list for tokenised Brazilian debit and credit combo cards, which also needs the transaction country code set to BR. The merchant may turn off prepaid cards and credit cards, each of which is otherwise supported for the networks it names, and credit cards are a required setting for United Kingdom gambling merchants. It may set an issuer country allow list or a block list of ISO 3166-1 alpha-2 codes, but not both, because the two are mutually exclusive; with neither, a user may choose a payment method issued anywhere. Google filters the cards a payer sees by these options. A billing address can be requested, and Google warns that asking for more data adds friction.", "citation": "Google Pay API for web, request objects reference, CardParameters", "rests_on": "rule" } ], "exceptions": [ "A merchant whose primary product or service type is non-profit, and which meets its own legal and other requirements, may use the API to receive donations.", "Gambling is allowed only in certain limited geographies and for restricted integration types, and financial or healthcare services only where the partner holds the relevant licence or supervision.", "A merchant may narrow what a buyer can choose through its own card parameters: card networks, prepaid and credit cards, and an issuer country allow list or block list, which are mutually exclusive.", "Any amount limit on the payment itself is the card's and the network's, not the wallet's." ], "applies_to": "Google Pay used to pay a merchant with a credit, debit or prepaid card, on the web, in the two forms the API returns: a card stored as an Android device token (CRYPTOGRAM_3DS) and a card stored on file with the user's Google Account (PAN_ONLY). Not Google's stored balance or bank transfer features, not Google Pay in India, not Google Wallet passes, and not a purchase from Google itself.", "caveat": "No amount limit means none was found in these pages, not that none exists. The restricted list is Google's own categories described in Orca's structure, not a reproduction of the policy, and Google states its list is not exhaustive.", "related": [ "visa:limits", "mastercard:limits", "apple-pay:limits" ], "basis": { "sources": "Google Pay API Terms of Service sections 2 and 4; Google Pay and Wallet APIs Acceptable Use Policy, read in full; request objects reference; read 2026-09-20.", "confidence": "high" }, "currency": { "effective_since": "2021-03-01", "effective_to": null, "effective_note": "Drafted 2026-09-20 from the Google pages saved that day. The date is the effective date the Google Pay API Terms of Service state for themselves; the developer pages carry their own last-updated dates and each Rule dates its own source. Nothing here dates the card network's rules, which change with their own rulebooks and are held in the visa and mastercard rails.", "source_edition": "Google Pay API Terms of Service, effective 2021-03-01 as the page states, read in full 2026-09-20 from the copy saved that day", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://payments.developers.google.com/terms/sellertos", "source_class": "authoritative_primary", "source_title": "Google Pay API Terms of Service (effective 2021-03-01)", "checked_on": "2026-09-20", "checked_by": "validator-pass-through-wallets-2026-09-20", "notes": "Confirms the bar on a buyer-specific minimum, maximum or surcharge, the bona fide sale requirement, the non-profit donation exception, and the web-only rule for digital goods." } ] }, "rail_name": "Google Pay (pass-through wallet)", "governing_authority": "Google LLC, through the Google Pay API Terms of Service and the Google Pay and Wallet APIs Acceptable Use Policy, for the wallet's own rules; the card network, the card issuer and the merchant's card acquiring bank for the payment itself", "snapshot": "2026-09-20", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "google-pay:messages", "id": "messages", "rail": "google-pay", "kind": "rail-fact", "facet": "messages", "name": "What does a Google Pay payment message carry?", "statement": "A signed, encrypted payment method token. Decrypted, its outer level carries messageExpiration, a messageId that uniquely identifies the message if it has to be revoked or found later, a payment method that today can only be CARD, and the credential itself. For a card the credential carries the account number as digits only, the expiration month as a number where 1 is January, the four-digit expiration year, and the authentication method. That method is where the two forms part: PAN_ONLY returns the card saved on file with the user's Google Account and nothing more, while CRYPTOGRAM_3DS returns a card stored as an Android device token and adds a 3-D Secure cryptogram generated on the device and, sometimes, an eciIndicator that must be passed on unaltered or the transaction fails. A merchantTokenId appears only where the merchant sent a merchant-initiated transaction object and a token update URL and the buyer chose a tokenised instrument. The merchant's own card parameters decide which networks, card classes and issuer countries a buyer may choose from. There is no Google Pay reason code list: the four API status codes report integration and account problems with the call, not the fate of a payment.", "details": [ { "label": "The two authentication methods a merchant may accept", "value": "In its card parameters a merchant declares, as a required field, which authentication methods it supports for a card transaction. PAN_ONLY is associated with payment cards stored on file with the user's Google Account, and the returned payment data includes the personal account number with the expiration month and the expiration year. CRYPTOGRAM_3DS is associated with cards stored as Android device tokens, and the returned payment data includes a 3-D Secure cryptogram generated on the device. The JCB and Discover card networks do not support CRYPTOGRAM_3DS because they do not support device account numbers.", "citation": "Google Pay API for web, request objects reference, CardParameters, allowedAuthMethods", "rests_on": "rule" }, { "label": "What the encrypted payload carries", "value": "The decrypted message has two levels: an outer level with metadata and security fields and an inner object holding the credential. The outer level carries messageExpiration, a messageId that uniquely identifies the message in case it has to be revoked or found later, a paymentMethod which today can only be CARD, and paymentMethodDetails. For a card the details carry the personal account number as digits only, the expiration month as a number where 1 is January, the four-digit expiration year, and the authentication method. A device-token payment adds the 3-D Secure cryptogram and, sometimes, the eciIndicator. A merchantTokenId appears only where the merchant sent a merchant-initiated transaction information object and a token update URL in the request and the user chose a tokenised instrument.", "citation": "Payment data cryptography for merchants, encrypted message; Card; PAN_ONLY; CRYPTOGRAM_3DS; Google Pay API for web, request objects reference, merchant-initiated transaction objects, tokenUpdateUrl", "rests_on": "rule" }, { "label": "An ECI indicator must be passed on unaltered, and only device tokens carry one", "value": "The card network might provide an eciIndicator for an authenticated device-token transaction. Where it does, the merchant must pass that value on in the authorisation without altering it and without hardcoding it, or the transaction fails. The field is not always present, and it returns only for authenticated device-token transactions on Android, which is to say only for the CRYPTOGRAM_3DS authentication method. A card-on-file payment never carries one.", "citation": "Payment data cryptography for merchants, CRYPTOGRAM_3DS; eciIndicator", "rests_on": "rule" }, { "label": "What else the merchant's card parameters decide", "value": "Besides the authentication methods, the card parameters name the card networks the merchant supports out of those the API supports, and Google's page lists AMEX, DISCOVER, INTERAC, JCB, MASTERCARD and VISA, with a separate list for tokenised Brazilian debit and credit combo cards, which also needs the transaction country code set to BR. The merchant may turn off prepaid cards and credit cards, each of which is otherwise supported for the networks it names, and credit cards are a required setting for United Kingdom gambling merchants. It may set an issuer country allow list or a block list of ISO 3166-1 alpha-2 codes, but not both, because the two are mutually exclusive; with neither, a user may choose a payment method issued anywhere. Google filters the cards a payer sees by these options. A billing address can be requested, and Google warns that asking for more data adds friction.", "citation": "Google Pay API for web, request objects reference, CardParameters", "rests_on": "rule" }, { "label": "The four status codes a rejected API call returns", "value": "A Google Pay API method that rejects returns a PaymentsError carrying a statusCode, a short code for the type of error, and a statusMessage, a developer-facing description of the error and what might fix it. There are four status codes. BUYER_ACCOUNT_ERROR says the current Google user cannot supply payment information. DEVELOPER_ERROR says a passed parameter is badly formatted, and an error message may show in the browser console for every configured environment. MERCHANT_ACCOUNT_ERROR says the site calling the API lacks the right permission, which can be a wrong configuration or a wrong merchant identifier in the request, with the status message giving the detail. INTERNAL_ERROR is a general server error. These describe the API call, not the fate of a payment: there is no reason code list on this rail, and nothing here is a decline, a return or a dispute reason.", "citation": "Google Pay API for web, error objects reference, PaymentsError; status codes", "rests_on": "rule" }, { "label": "The steps a merchant runs before it charges the payment method", "value": "To consume a version 2 payment method token an integrator fetches Google's root signing keys; verifies that the signature of the intermediate signing key is valid under one of the non-expired root signing keys; verifies that the intermediate signing key has not expired; verifies that the payload's signature is valid under that intermediate key; decrypts the payload only after the signature has been verified; verifies that the message has not expired, by checking that the current time is earlier than messageExpiration; and only then uses the payment method in the decrypted contents and charges it. Google strongly recommends its Tink library, which performs the first six steps.", "citation": "Payment data cryptography for merchants, steps for consuming the payload", "rests_on": "rule" } ], "exceptions": [ "The eciIndicator is not always present and never appears for a card-on-file payment.", "JCB and Discover do not support the device-token method, because they do not support device account numbers.", "The four status codes, BUYER_ACCOUNT_ERROR, DEVELOPER_ERROR, MERCHANT_ACCOUNT_ERROR and INTERNAL_ERROR, are integration errors and are held here rather than as a code directory." ], "applies_to": "Google Pay used to pay a merchant with a credit, debit or prepaid card, on the web, in the two forms the API returns: a card stored as an Android device token (CRYPTOGRAM_3DS) and a card stored on file with the user's Google Account (PAN_ONLY). Not Google's stored balance or bank transfer features, not Google Pay in India, not Google Wallet passes, and not a purchase from Google itself.", "caveat": "These are the wallet's fields, not the network's. Nothing here says what an issuer sends back or what a decline means; that is visa:messages and mastercard:messages. Field and value names are Google's defined terms and stay as Google writes them.", "related": [ "visa:messages", "mastercard:messages", "apple-pay:messages" ], "basis": { "sources": "Payment data cryptography, read in full; request objects reference, CardParameters and the merchant-initiated objects; error objects reference, read in full; read 2026-09-20.", "confidence": "high" }, "currency": { "effective_since": "2026-02-20", "effective_to": null, "effective_note": "Drafted 2026-09-20 from the Google pages saved that day. The date is the effective date the Google Pay API Terms of Service state for themselves; the developer pages carry their own last-updated dates and each Rule dates its own source. Nothing here dates the card network's rules, which change with their own rulebooks and are held in the visa and mastercard rails.", "source_edition": "Payment data cryptography for merchants, last updated 2026-02-20 UTC as the page states, read in full 2026-09-20 from the copy saved that day", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://developers.google.com/pay/api/web/guides/resources/payment-data-cryptography", "source_class": "authoritative_primary", "source_title": "Payment data cryptography for merchants", "checked_on": "2026-09-20", "checked_by": "validator-pass-through-wallets-2026-09-20", "notes": "Confirms the decrypted payload's structure and the fields distinguishing a PAN_ONLY credential from a CRYPTOGRAM_3DS credential." } ] }, "rail_name": "Google Pay (pass-through wallet)", "governing_authority": "Google LLC, through the Google Pay API Terms of Service and the Google Pay and Wallet APIs Acceptable Use Policy, for the wallet's own rules; the card network, the card issuer and the merchant's card acquiring bank for the payment itself", "snapshot": "2026-09-20", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "google-pay:participants", "id": "participants", "rail": "google-pay", "kind": "rail-fact", "facet": "participants", "name": "Who takes part in a Google Pay payment, and who does what?", "statement": "Start from what the wallet is not: Google moves no money and is not a party to the sale. The buyer, whom the terms call the End User, chooses a card held in their Google Account or provisioned as an Android device token. Google shares the credential as an encrypted payload and sets conduct rules, and may act against a transaction or a partner account under its acceptable use policy. The merchant sells, decrypts the payload, charges the payment method, holds its own card acquiring agreement, complies with that agreement and the network rules, keeps its own risk checks, resolves its own disputes and answers for taxes. A platform provider may help the merchant integrate, but only acting exclusively for the merchant and under its own written agreement with Google, and Google may make the merchant drop it. The card issuer performs the identification and verification that assuranceDetails reports and decides the authorisation, and the card network supplies the ECI value and sets the rules that actually govern the payment.", "details": [ { "label": "Google is not a party to the sale", "value": "Google only enables a transaction by sharing payment credentials. The sale is solely between the merchant and the End User who buys from it, and Google is not a party to it. Google is not and will not be responsible for any aspect of the products or services the merchant sells, and it is not responsible for what End Users do, including not completing a transaction. So nothing in the wallet decides whether a payment is final, whether it can be undone, or who bears a loss.", "citation": "Google Pay API Terms of Service (effective 2021-03-01), section 1, first three bullets", "rests_on": "rule" }, { "label": "Who the agreement binds, and what else the merchant must follow", "value": "Accessing or using the Google Pay API and its associated APIs binds the user to the Google Pay API Terms of Service and to the Google APIs Terms of Service, which the first incorporates by reference, and together they make a binding agreement between Google LLC and that user. Terms the Google Pay API Terms of Service do not define take their meaning from the Google APIs Terms of Service. On top of those, the merchant must comply with the Google Pay APIs acceptable use guidelines and the Google Pay API brand guidelines published on the developer site. The merchant is also solely responsible for any taxes, fees and duties a government imposes in connection with payments made through the API.", "citation": "Google Pay API Terms of Service (effective 2021-03-01), opening paragraph; sections 3 and 7", "rests_on": "rule" }, { "label": "A platform provider acts only for the merchant", "value": "Unless Google says otherwise, a merchant may arrange for a platform provider to help it integrate its payment transaction interfaces with the API. That provider must act exclusively on the merchant's behalf and in accordance with its own written agreement with Google. Google may require the merchant to disengage from it where, in Google's discretion, the provider contributed to a breach of the terms or to other harm to Google.", "citation": "Google Pay API Terms of Service (effective 2021-03-01), section 3, second paragraph", "rests_on": "rule" }, { "label": "The merchant must hold its own card acquiring agreement", "value": "The merchant is solely responsible for establishing a payment card acquiring agreement with a card acquiring bank for processing transactions, and for all the fees, charges and expenses that relationship brings. It must comply with that agreement and with any applicable payment network rules. Google supplies no acquiring, no clearing and no settlement, and takes no responsibility for any of them.", "citation": "Google Pay API Terms of Service (effective 2021-03-01), section 1, fifth bullet", "rests_on": "rule" }, { "label": "What assuranceDetails says about the credential", "value": "Where a merchant sets assuranceDetailsRequired to true in its card parameters, the response carries an assurance details object describing what validation was performed on the returned credential, so that the right instrument risk checks can be applied. Its accountVerified field, when true, says cardholder possession validation has been performed. Its cardHolderAuthenticated field, when true, says identification and verification has been performed; when false, Google says the merchant can run the same risk-based authentication it would for a card transaction, which can include a step-up with the 3-D Secure protocol where applicable. Google adds that where both are true no step-up of the returned credential is needed, and where neither is, it recommends the same risk checks and authentication, including a 3-D Secure flow where applicable. A merchant can receive and process the response without using the field at all.", "citation": "Google Pay API for web, response objects reference, CardInfo, assuranceDetails; AssuranceDetailsSpecifications; Google Pay API for web, request objects reference, CardParameters, assuranceDetailsRequired", "rests_on": "rule" }, { "label": "The merchant keeps its own risk checks", "value": "Google tells merchants to make sure their existing risk checks and controls for payment transactions apply to Google Pay transactions too, because Google's own validation and fraud checks are not meant to replace a merchant's risk management. The note sits on the authentication methods field, so it covers both the device-token and the card-on-file credential.", "citation": "Google Pay API for web, request objects reference, CardParameters, allowedAuthMethods, the important note", "rests_on": "rule" } ], "exceptions": [ "The Google entity that provides the consumer wallet in each country was not read; the terms bind Google LLC as the party offering the API to merchants.", "Nothing on the pages read describes Google's arrangements with card issuers or networks, so the issuer's and the network's parts here are read off the interface rather than off an agreement." ], "applies_to": "Google Pay used to pay a merchant with a credit, debit or prepaid card, on the web, in the two forms the API returns: a card stored as an Android device token (CRYPTOGRAM_3DS) and a card stored on file with the user's Google Account (PAN_ONLY). Not Google's stored balance or bank transfer features, not Google Pay in India, not Google Wallet passes, and not a purchase from Google itself.", "caveat": "Do not read this rail as a payment system with participants of its own. Every party here except Google is a party to a card payment, and the card network's participant rules, held in visa:participants and mastercard:participants, are what bind them.", "related": [ "visa:participants", "mastercard:participants", "apple-pay:participants" ], "basis": { "sources": "Google Pay API Terms of Service sections 1, 3, 5 and 7; response objects reference; request objects reference; read 2026-09-20.", "confidence": "high" }, "currency": { "effective_since": "2021-03-01", "effective_to": null, "effective_note": "Drafted 2026-09-20 from the Google pages saved that day. The date is the effective date the Google Pay API Terms of Service state for themselves; the developer pages carry their own last-updated dates and each Rule dates its own source. Nothing here dates the card network's rules, which change with their own rulebooks and are held in the visa and mastercard rails.", "source_edition": "Google Pay API Terms of Service, effective 2021-03-01 as the page states, read in full 2026-09-20 from the copy saved that day", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "rail_name": "Google Pay (pass-through wallet)", "governing_authority": "Google LLC, through the Google Pay API Terms of Service and the Google Pay and Wallet APIs Acceptable Use Policy, for the wallet's own rules; the card network, the card issuer and the merchant's card acquiring bank for the payment itself", "snapshot": "2026-09-20", "source_class": null, "effective_status": "draft", "effective_status_reason": null, "boundaries": [] }, { "uid": "google-pay:recall", "id": "recall", "rail": "google-pay", "kind": "rail-fact", "facet": "recall", "name": "Can a Google Pay payment be recalled or cancelled?", "statement": "Not through the wallet. Nothing on the pages read gives Google, the buyer or the merchant a route to recall, cancel or reverse a completed card payment to a third-party merchant. The cancel routes on Google's help page belong to Google's own charges, subscriptions and Play or YouTube purchases, where Google is the seller, and the page itself says a payment cannot be disputed until it has finished. For a payment to another merchant the page offers the store, the bank and the card provider, in that order. Before the payload is used there is one stopping point, and it belongs to the merchant, not to the wallet: a payload that fails verification or has expired is not charged.", "details": [ { "label": "Google publishes no way to recall a completed payment to a merchant", "value": "Nothing on the pages read gives the wallet a route to recall, cancel or reverse a completed card payment to a third-party merchant. The cancel routes Google's help page describes are for Google's own charges, subscriptions and Play or YouTube purchases, where Google is the seller and a different relationship applies. For a payment to another merchant the page offers only the store, the bank and the card provider. A completed payment is undone, if at all, on the card network.", "citation": "Google Pay Help article 7644016, Dispute, report, or cancel a payment, steps 2, 3 and 4; Google Pay API Terms of Service (effective 2021-03-01), section 1", "rests_on": "guidance" }, { "label": "Google is not a party to the sale", "value": "Google only enables a transaction by sharing payment credentials. The sale is solely between the merchant and the End User who buys from it, and Google is not a party to it. Google is not and will not be responsible for any aspect of the products or services the merchant sells, and it is not responsible for what End Users do, including not completing a transaction. So nothing in the wallet decides whether a payment is final, whether it can be undone, or who bears a loss.", "citation": "Google Pay API Terms of Service (effective 2021-03-01), section 1, first three bullets", "rests_on": "rule" }, { "label": "The steps a merchant runs before it charges the payment method", "value": "To consume a version 2 payment method token an integrator fetches Google's root signing keys; verifies that the signature of the intermediate signing key is valid under one of the non-expired root signing keys; verifies that the intermediate signing key has not expired; verifies that the payload's signature is valid under that intermediate key; decrypts the payload only after the signature has been verified; verifies that the message has not expired, by checking that the current time is earlier than messageExpiration; and only then uses the payment method in the decrypted contents and charges it. Google strongly recommends its Tink library, which performs the first six steps.", "citation": "Payment data cryptography for merchants, steps for consuming the payload", "rests_on": "rule" }, { "label": "The payload expires, and an expired one must be rejected", "value": "The decrypted payload carries messageExpiration, the time the message expires given as UTC milliseconds since the epoch, and an integrator should reject any message that has expired. Checking that the current time is earlier than messageExpiration is one of the steps for consuming the payload, and the intermediate signing key must also be checked for expiry before its signature is trusted. Google publishes no figure for how long a payload lives, so the clock is read from the field rather than from a rule. The wallet keeps no operating hours and no settlement calendar, because it settles nothing.", "citation": "Payment data cryptography for merchants, steps for consuming the payload; encrypted message, messageExpiration", "rests_on": "rule" } ], "exceptions": [ "A merchant can refuse a payload that fails verification or has expired, which is the only stop in the wallet's own reach and works only before the payment method is charged." ], "applies_to": "Google Pay used to pay a merchant with a credit, debit or prepaid card, on the web, in the two forms the API returns: a card stored as an Android device token (CRYPTOGRAM_3DS) and a card stored on file with the user's Google Account (PAN_ONLY). Not Google's stored balance or bank transfer features, not Google Pay in India, not Google Wallet passes, and not a purchase from Google itself.", "caveat": "This is a statement that something does not exist, drawn from reading the saved pages and finding no such route. Orca has no way to record that a document was read in full and nothing was found, so the claim sits in prose and is marked [Inference].", "related": [ "visa:recall", "mastercard:recall", "apple-pay:recall" ], "basis": { "sources": "Google Pay Help 7644016; Google Pay API Terms of Service section 1; payment data cryptography; read 2026-09-20.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the help page carries no date", "effective_to": null, "effective_note": "Drafted 2026-09-20 from the Google pages saved that day. The date is the effective date the Google Pay API Terms of Service state for themselves; the developer pages carry their own last-updated dates and each Rule dates its own source. Nothing here dates the card network's rules, which change with their own rulebooks and are held in the visa and mastercard rails.", "source_edition": "Google Pay Help article 7644016, Dispute, report, or cancel a payment, undated page, read in full 2026-09-20 from the copy saved that day", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://support.google.com/googlepay/answer/7644016?hl=en", "source_class": "public_primary", "source_title": "Google Pay Help article 7644016, Dispute, report, or cancel a payment", "checked_on": "2026-09-20", "checked_by": "validator-pass-through-wallets-2026-09-20", "notes": "Confirms the help page's cancel routes cover only Google's own charges and that a payment cannot be disputed until it has finished." } ] }, "rail_name": "Google Pay (pass-through wallet)", "governing_authority": "Google LLC, through the Google Pay API Terms of Service and the Google Pay and Wallet APIs Acceptable Use Policy, for the wallet's own rules; the card network, the card issuer and the merchant's card acquiring bank for the payment itself", "snapshot": "2026-09-20", "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "google-pay:refund", "id": "refund", "rail": "google-pay", "kind": "rail-fact", "facet": "refund", "name": "How is money returned to a buyer after a Google Pay purchase?", "statement": "By the merchant, under its own policy, on the card network. Google publishes no refund mechanism of its own for a payment to a third-party merchant, and none was found on the pages read. Since the sale is solely between the merchant and the buyer and Google is not a party to it, a refund is the merchant's act, and how it reaches the card is the card network's rule. The only thing the terms say about the aftermath is a data rule: a merchant may keep using personal information the API gave it for post-transaction activities for that transaction, and a chargeback is the example the terms give. Unlike Apple Pay, nothing in these pages tells a buyer that the number the merchant holds differs from the card's, and for a card-on-file payment it does not: PAN_ONLY returns the card number itself.", "details": [ { "label": "Google publishes no refund route of its own for a merchant sale", "value": "Google sets no refund mechanism for a card payment to a third-party merchant, and none was found on the pages read. Since the sale is between the merchant and the buyer and Google is not a party to it, a refund is the merchant's own act under its own policy, and it runs back on the card network. What the terms do say about the aftermath is narrow: a merchant may keep using End User personal information from the API for post-transaction activities for that transaction, and the terms give a chargeback as the example.", "citation": "Google Pay API Terms of Service (effective 2021-03-01), sections 1 and 5(a); Google Pay Help article 7644016, Dispute, report, or cancel a payment, whole page", "rests_on": "guidance" }, { "label": "Google is not a party to the sale", "value": "Google only enables a transaction by sharing payment credentials. The sale is solely between the merchant and the End User who buys from it, and Google is not a party to it. Google is not and will not be responsible for any aspect of the products or services the merchant sells, and it is not responsible for what End Users do, including not completing a transaction. So nothing in the wallet decides whether a payment is final, whether it can be undone, or who bears a loss.", "citation": "Google Pay API Terms of Service (effective 2021-03-01), section 1, first three bullets", "rests_on": "rule" }, { "label": "A card-on-file payment is not a tokenised payment, and the token rules do not reach it", "value": "PAN_ONLY is the authentication method for payment cards stored on file with the user's Google Account, and the payment data it returns is the personal account number with the expiration month and the expiration year. There is no cryptogram, no eciIndicator and no device account number. CRYPTOGRAM_3DS is the authentication method for cards stored as Android device tokens, and it returns a 3-D Secure cryptogram generated on the device. The difference matters beyond the fields: a card-on-file payment is an ordinary card-absent card payment that Google filled in, so every rule written for a device token, including the duty to pass an ECI indicator on and Google's liable-party table, reaches CRYPTOGRAM_3DS and nothing else. Where such a payment needs strong customer authentication, or where assuranceDetails reports the cardholder was not authenticated, the merchant runs 3-D Secure itself or through its payment service provider.", "citation": "Google Pay API for web, request objects reference, CardParameters, allowedAuthMethods; Payment data cryptography for merchants, PAN_ONLY; CRYPTOGRAM_3DS; eciIndicator; SCA and Google Pay API, Handle the response object", "rests_on": "rule" }, { "label": "What a merchant may do with the buyer's personal information", "value": "The merchant is solely responsible for its use of End User personal information, including payment account information, complying with the law, its card acquiring agreement, its privacy policy and other applicable rules such as network rules. It may use personal information the API provides only to process the current transaction and to carry out post-transaction activities for that transaction, and the terms give a chargeback as the example, unless the End User has expressly consented to other uses. Google and the merchant are each independent controllers of personal information subject to European Union data protection law, each determining its own purposes and means. The merchant must keep administrative, technical and physical controls that meet or exceed industry standards, limit who may see the information, keep an incident response programme and notify Google promptly of a security incident, and Google may ask for reasonably acceptable verification of compliance.", "citation": "Google Pay API Terms of Service (effective 2021-03-01), sections 5 and 6", "rests_on": "rule" } ], "exceptions": [ "A device-token payment gives the merchant a device account number rather than the card number, so a refund look-up by card number can fail there in the way it does for any tokenised payment [Inference: the pages read do not discuss refunds]." ], "applies_to": "Google Pay used to pay a merchant with a credit, debit or prepaid card, on the web, in the two forms the API returns: a card stored as an Android device token (CRYPTOGRAM_3DS) and a card stored on file with the user's Google Account (PAN_ONLY). Not Google's stored balance or bank transfer features, not Google Pay in India, not Google Wallet passes, and not a purchase from Google itself.", "caveat": "The help page's separate Return a purchase topic was not read, so this is what the pages that were read say and no more [Unverified].", "related": [ "visa:refund", "mastercard:refund", "apple-pay:refund" ], "basis": { "sources": "Google Pay API Terms of Service sections 1 and 5(a); Google Pay Help 7644016; payment data cryptography; read 2026-09-20.", "confidence": "medium" }, "currency": { "effective_since": "2021-03-01", "effective_to": null, "effective_note": "Drafted 2026-09-20 from the Google pages saved that day. The date is the effective date the Google Pay API Terms of Service state for themselves; the developer pages carry their own last-updated dates and each Rule dates its own source. Nothing here dates the card network's rules, which change with their own rulebooks and are held in the visa and mastercard rails.", "source_edition": "Google Pay API Terms of Service, effective 2021-03-01 as the page states, read in full 2026-09-20 from the copy saved that day", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://payments.developers.google.com/terms/sellertos", "source_class": "authoritative_primary", "source_title": "Google Pay API Terms of Service (effective 2021-03-01)", "checked_on": "2026-09-20", "checked_by": "validator-pass-through-wallets-2026-09-20", "notes": "Confirms Google sets no refund mechanism for a payment to a third-party merchant and that a merchant may use personal information for post-transaction activities such as a chargeback." } ] }, "rail_name": "Google Pay (pass-through wallet)", "governing_authority": "Google LLC, through the Google Pay API Terms of Service and the Google Pay and Wallet APIs Acceptable Use Policy, for the wallet's own rules; the card network, the card issuer and the merchant's card acquiring bank for the payment itself", "snapshot": "2026-09-20", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "google-pay:return", "id": "return", "rail": "google-pay", "kind": "rail-fact", "facet": "return", "name": "How is a Google Pay payment disputed or returned?", "statement": "Not through Google. The terms make the merchant solely responsible for investigating and resolving disputes with its buyers and say Google is not a party to a dispute and will not be responsible for one, which places the whole dispute layer with the issuer, the acquirer and the network's rules. Google's consumer help page says the same in plainer words: a payment cannot be disputed until it has finished; for a payment a user does not recognise, compare it with what the bank's own application shows rather than with old statements, and take it up with the store; and for a suspected scam or fraudulent charge the user made, contact the bank or card provider immediately. The page also offers a Google report-a-problem flow, but it does not say how far that reaches for a card payment to a third-party merchant, and the cancel routes it describes are for Google's own charges, where Google is the seller.", "details": [ { "label": "The merchant alone resolves disputes with its buyers", "value": "The merchant is solely responsible for investigating and resolving disputes with its End Users. Google is not a party to a dispute and will not be responsible for one. Read with the clause saying Google's enablement does not mean a transaction will not later be charged back, the terms place the whole dispute layer outside the wallet: with the issuer, the acquirer and the network's rules.", "citation": "Google Pay API Terms of Service (effective 2021-03-01), section 1, sixth bullet", "rests_on": "rule" }, { "label": "Google's help page sends a disputing user to the store, then to the bank", "value": "Google's consumer help page separates Google's own charges from payments to other sellers. For a payment a user does not recognise, it says to compare the amount with what the bank's own application shows rather than with old statements or receipts, and to take the problem up with the store first. For a suspected scam or fraudulent charge the user themselves made, it says to contact the bank or card provider immediately, and offers a route for reporting suspicious websites to Google. It also offers a report-a-problem flow, whose reach for a card payment to a third-party merchant the page does not state [Unverified]. A payment cannot be disputed until it has finished.", "citation": "Google Pay Help article 7644016, Dispute, report, or cancel a payment, steps 1, 3 and 4", "rests_on": "guidance" }, { "label": "Google is not a party to the sale", "value": "Google only enables a transaction by sharing payment credentials. The sale is solely between the merchant and the End User who buys from it, and Google is not a party to it. Google is not and will not be responsible for any aspect of the products or services the merchant sells, and it is not responsible for what End Users do, including not completing a transaction. So nothing in the wallet decides whether a payment is final, whether it can be undone, or who bears a loss.", "citation": "Google Pay API Terms of Service (effective 2021-03-01), section 1, first three bullets", "rests_on": "rule" }, { "label": "Enabling a payment promises neither authorisation nor freedom from chargeback", "value": "Google enabling a transaction does not mean the End User has enough money in the instrument they used, that the transaction will be authorised or processed, or that it will not later result in a chargeback or another reversal. This is the wallet saying in its own terms that the outcome belongs to the issuer and the network. A merchant that treats the Google Pay sheet completing as a payment taken has misread the terms.", "citation": "Google Pay API Terms of Service (effective 2021-03-01), section 1, fourth bullet", "rests_on": "rule" }, { "label": "What a merchant may do with the buyer's personal information", "value": "The merchant is solely responsible for its use of End User personal information, including payment account information, complying with the law, its card acquiring agreement, its privacy policy and other applicable rules such as network rules. It may use personal information the API provides only to process the current transaction and to carry out post-transaction activities for that transaction, and the terms give a chargeback as the example, unless the End User has expressly consented to other uses. Google and the merchant are each independent controllers of personal information subject to European Union data protection law, each determining its own purposes and means. The merchant must keep administrative, technical and physical controls that meet or exceed industry standards, limit who may see the information, keep an incident response programme and notify Google promptly of a security incident, and Google may ask for reasonably acceptable verification of compliance.", "citation": "Google Pay API Terms of Service (effective 2021-03-01), sections 5 and 6", "rests_on": "rule" } ], "exceptions": [ "A chargeback is the one post-transaction activity the terms name, as an example of what a merchant may keep using the buyer's personal information for.", "Cancelling a Google Play payment, a YouTube payment or a Google subscription is a different relationship: Google is the seller there, and those routes do not reach a payment to another merchant." ], "applies_to": "Google Pay used to pay a merchant with a credit, debit or prepaid card, on the web, in the two forms the API returns: a card stored as an Android device token (CRYPTOGRAM_3DS) and a card stored on file with the user's Google Account (PAN_ONLY). Not Google's stored balance or bank transfer features, not Google Pay in India, not Google Wallet passes, and not a purchase from Google itself.", "caveat": "Keep Google's own sales apart from payments to other merchants. The help page covers both in one article, and only its lines about other merchants belong to this rail. The reach of Google's report-a-problem flow for a third-party card payment is [Unverified].", "related": [ "visa:return", "mastercard:return", "visa-dispute:10.4", "visa-dispute:13.1", "apple-pay:return" ], "basis": { "sources": "Google Pay API Terms of Service section 1; Google Pay Help 7644016, read in full; read 2026-09-20. The linked Visa conditions and the Visa and Mastercard facts hold the network layer; no Visa or Mastercard document was read for this rail.", "confidence": "medium" }, "currency": { "effective_since": "2021-03-01", "effective_to": null, "effective_note": "Drafted 2026-09-20 from the Google pages saved that day. The date is the effective date the Google Pay API Terms of Service state for themselves; the developer pages carry their own last-updated dates and each Rule dates its own source. Nothing here dates the card network's rules, which change with their own rulebooks and are held in the visa and mastercard rails.", "source_edition": "Google Pay API Terms of Service, effective 2021-03-01 as the page states, read in full 2026-09-20 from the copy saved that day", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://payments.developers.google.com/terms/sellertos", "source_class": "authoritative_primary", "source_title": "Google Pay API Terms of Service (effective 2021-03-01)", "checked_on": "2026-09-20", "checked_by": "validator-pass-through-wallets-2026-09-20", "notes": "Confirms the merchant is solely responsible for resolving disputes with End Users and that Google is not a party to one." } ] }, "rail_name": "Google Pay (pass-through wallet)", "governing_authority": "Google LLC, through the Google Pay API Terms of Service and the Google Pay and Wallet APIs Acceptable Use Policy, for the wallet's own rules; the card network, the card issuer and the merchant's card acquiring bank for the payment itself", "snapshot": "2026-09-20", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "google-pay:settlement", "id": "settlement", "rail": "google-pay", "kind": "rail-fact", "facet": "settlement", "name": "How does money actually move for a Google Pay payment?", "statement": "On the card network, not through Google. Google's part ends at the credential: it returns a signed, encrypted payment method token that the merchant or its gateway decrypts with its own private key, and Google recommends its Tink library for the work and an annual key rotation. From there the merchant charges the payment method through the card acquiring agreement it is solely responsible for establishing, bearing its fees and complying with it and with the applicable payment network rules. Google holds no funds, runs no clearing and performs no settlement, and no settlement cycle, value date or netting rule of Google's own was found in the pages read.", "details": [ { "label": "Google hands over an encrypted, signed payload and nothing else", "value": "What passes from Google to the merchant is a payment method token: a signed, encrypted message the merchant or its gateway decrypts with its own private key. Google recommends its Tink library for the work and tells merchants to rotate their encryption key pairs annually. That is the whole of Google's part in the money side of the payment: after decryption the merchant charges the payment method through its own acquiring arrangement. Google holds no funds [Inference from the terms, which put the sale between the merchant and the buyer].", "citation": "Payment data cryptography for merchants, steps for consuming the payload; encryption public key format; Google Pay API Terms of Service (effective 2021-03-01), section 1", "rests_on": "rule" }, { "label": "The merchant must hold its own card acquiring agreement", "value": "The merchant is solely responsible for establishing a payment card acquiring agreement with a card acquiring bank for processing transactions, and for all the fees, charges and expenses that relationship brings. It must comply with that agreement and with any applicable payment network rules. Google supplies no acquiring, no clearing and no settlement, and takes no responsibility for any of them.", "citation": "Google Pay API Terms of Service (effective 2021-03-01), section 1, fifth bullet", "rests_on": "rule" }, { "label": "Google is not a party to the sale", "value": "Google only enables a transaction by sharing payment credentials. The sale is solely between the merchant and the End User who buys from it, and Google is not a party to it. Google is not and will not be responsible for any aspect of the products or services the merchant sells, and it is not responsible for what End Users do, including not completing a transaction. So nothing in the wallet decides whether a payment is final, whether it can be undone, or who bears a loss.", "citation": "Google Pay API Terms of Service (effective 2021-03-01), section 1, first three bullets", "rests_on": "rule" }, { "label": "The steps a merchant runs before it charges the payment method", "value": "To consume a version 2 payment method token an integrator fetches Google's root signing keys; verifies that the signature of the intermediate signing key is valid under one of the non-expired root signing keys; verifies that the intermediate signing key has not expired; verifies that the payload's signature is valid under that intermediate key; decrypts the payload only after the signature has been verified; verifies that the message has not expired, by checking that the current time is earlier than messageExpiration; and only then uses the payment method in the decrypted contents and charges it. Google strongly recommends its Tink library, which performs the first six steps.", "citation": "Payment data cryptography for merchants, steps for consuming the payload", "rests_on": "rule" } ], "exceptions": [ "None of Google's own: there is no settlement path in the wallet to make an exception to. Every exception that matters is the card network's, and sits in visa:settlement and mastercard:settlement." ], "applies_to": "Google Pay used to pay a merchant with a credit, debit or prepaid card, on the web, in the two forms the API returns: a card stored as an Android device token (CRYPTOGRAM_3DS) and a card stored on file with the user's Google Account (PAN_ONLY). Not Google's stored balance or bank transfer features, not Google Pay in India, not Google Wallet passes, and not a purchase from Google itself.", "caveat": "Handing over an encrypted payload is transport, not settlement and not authorisation. Nothing Google does here puts Google in the money flow.", "related": [ "visa:settlement", "mastercard:settlement", "apple-pay:settlement" ], "basis": { "sources": "Payment data cryptography; Google Pay API Terms of Service section 1; read 2026-09-20.", "confidence": "high" }, "currency": { "effective_since": "2021-03-01", "effective_to": null, "effective_note": "Drafted 2026-09-20 from the Google pages saved that day. The date is the effective date the Google Pay API Terms of Service state for themselves; the developer pages carry their own last-updated dates and each Rule dates its own source. Nothing here dates the card network's rules, which change with their own rulebooks and are held in the visa and mastercard rails.", "source_edition": "Google Pay API Terms of Service, effective 2021-03-01 as the page states, read in full 2026-09-20 from the copy saved that day", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://developers.google.com/pay/api/web/guides/resources/payment-data-cryptography", "source_class": "authoritative_primary", "source_title": "Payment data cryptography for merchants", "checked_on": "2026-09-20", "checked_by": "validator-pass-through-wallets-2026-09-20", "notes": "Confirms Google returns a signed, encrypted payment method token that the merchant decrypts with its own private key, recommending the Tink library and an annual key rotation." } ] }, "rail_name": "Google Pay (pass-through wallet)", "governing_authority": "Google LLC, through the Google Pay API Terms of Service and the Google Pay and Wallet APIs Acceptable Use Policy, for the wallet's own rules; the card network, the card issuer and the merchant's card acquiring bank for the payment itself", "snapshot": "2026-09-20", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "in-upi:consumer-law", "id": "consumer-law", "rail": "in-upi", "kind": "rail-fact", "facet": "consumer-law", "name": "What protection does a UPI customer have, and where do they go?", "statement": "A layered route, all of it set by the Reserve Bank. Compensation for a late reversal reaches the customer without a complaint. Every authorised operator has had to run an online dispute resolution system for failed transactions since 1 January 2021 and give its participants access to it, and both the operator and the customer's own institution must offer a way in, whether the payment stayed inside one institution or crossed between two. On UPI specifically, a third party app must let the customer raise the dispute inside the app they paid in, wired into the operator's system. Every dispute gets a reference number and can be followed. If it is still unresolved after a month, or the customer is not satisfied with the reply, the customer may go to an RBI Ombudsman, free of charge, within ninety days of the waiting period ending or of the institution's last word. For unauthorised transactions the bank must send alerts, take a report around the clock through several channels, and acknowledge it at once. A recurring mandate costs the customer nothing, can be withdrawn at any time, and is announced at least a day before each charge. Underneath all of it, every domestic digital payment must be authenticated with at least two distinct factors, one of which is dynamic outside a card present payment, and the Reserve Bank names the cases it has exempted, among them a UPI tap and pay at a near field communication terminal and every recurring charge after the first.", "details": [ { "label": "Compensation is credited without waiting for the customer to complain", "value": "Where the framework provides financial compensation, the bank or operator credits it to the customer's account of its own motion. It does not wait for a complaint or a claim.", "citation": "RBI circular on turn around time and customer compensation for failed transactions (RBI/2019-20/67), paragraph 5", "rests_on": "rule" }, { "label": "Every authorised operator must run an online dispute resolution system for failed transactions", "value": "Each authorised payment system operator must run a system for resolving customer disputes and grievances about failed transactions in its own payment system, and must give its participating members access to it. The duty began on 1 January 2021 for operators already running, and at the start of operations for anyone authorised since. Both the operator and the participant must give customers a way in, and it makes no difference whether the payment stayed inside one institution or crossed between two.", "citation": "RBI circular on the Online Dispute Resolution system for digital payments (RBI/2020-21/21), paragraph 3; Annex 1.1, 3.1 and 3.2", "rests_on": "rule" }, { "label": "The dispute resolution system covers the failed transactions the turn around time framework lists", "value": "What the dispute resolution system must cover is, to begin with, the failed transactions named in the turn around time framework, which for UPI means the funds transfer case and the merchant payment case. Everything that framework says about deadlines and about compensating the customer must be honoured while a dispute is resolved through the system. Extending the system to grievances beyond failed transactions was left for later.", "citation": "RBI circular on the Online Dispute Resolution system for digital payments (RBI/2020-21/21), Annex 4.1 and 4.2; paragraph 4; RBI circular on turn around time and customer compensation for failed transactions (RBI/2019-20/67), Annex, rows 4(a) and 4(b)", "rests_on": "rule" }, { "label": "How a customer lodges a dispute and follows it", "value": "A customer must be given one or more ways to raise a dispute: a form on the web or on paper, an interactive voice response line, a mobile application, a call centre, a text message, a branch or an office. Both the operator and the institution the customer banks with must offer this, with a link into the operator's system. Raising it must be simple and ask only for what is needed, with the system filling in the rest from what the customer gave and with data confidentiality designed in. Every dispute gets a unique reference number, and the customer can follow its progress by that number.", "citation": "RBI circular on the Online Dispute Resolution system for digital payments (RBI/2020-21/21), Annex 5.1, 5.3 and 5.4", "rests_on": "rule" }, { "label": "On UPI, a third party app must let the customer raise the dispute inside the app they paid in", "value": "For mobile systems such as UPI, a third party application provider must also give the customer a way to raise a dispute or grievance in the same application used to make the payment, and that facility must be wired into the operator's dispute resolution system. This is the only duty a Reserve Bank text read for this rail places directly on a UPI app that is not a bank.", "citation": "RBI circular on the Online Dispute Resolution system for digital payments (RBI/2020-21/21), Annex 5.2", "rests_on": "rule" }, { "label": "A grievance still unresolved after a month goes to an ombudsman", "value": "If a grievance is not resolved within one month, the customer may take it to the Reserve Bank's ombudsman scheme. The turn around time circular says the same for a customer who does not get the reversal or the compensation the framework promises.", "citation": "RBI circular on the Online Dispute Resolution system for digital payments (RBI/2020-21/21), paragraph 4; RBI circular on turn around time and customer compensation for failed transactions (RBI/2019-20/67), paragraph 6", "rests_on": "rule" }, { "label": "The 2021 ombudsman scheme covered system participants as well as banks", "value": "The scheme the Reserve Bank brought into force on 12 November 2021 merged the banking ombudsman scheme, the scheme for non-banking financial companies and the scheme for digital transactions into one. It covered commercial banks, regional rural banks and the larger urban co-operative banks, the larger non-banking financial companies with a customer interface, and all system participants as the scheme defined them. That last category is how a customer of a payment system reached an ombudsman.", "citation": "RBI notification bringing the Reserve Bank Integrated Ombudsman Scheme, 2021 into force, paragraphs 1, 2 and 5", "rests_on": "rule" }, { "label": "A newer ombudsman scheme replaced the 2021 one on 1 July 2026", "value": "The Reserve Bank Integrated Ombudsman Scheme, 2026 came into force on 1 July 2026 and replaced the 2021 scheme. Complaints received before that date, appeals from decisions under the old scheme and the execution of awards made under it stay with the old scheme. The turn around time and dispute resolution circulars still send customers to the 2021 scheme, so the circular text is behind the scheme that now governs. The Reserve Bank's own list of covered entities for the 2026 scheme names banks, certain non-banking financial companies, non-bank prepaid instrument issuers and credit information companies, and does not repeat the system participant category the 2021 notification used.", "citation": "RBI questions and answers on the Reserve Bank Integrated Ombudsman Scheme, 2026, questions 1, 3 and 13; RBI notification bringing the Reserve Bank Integrated Ombudsman Scheme, 2021 into force, paragraph 2; RBI circular on turn around time and customer compensation for failed transactions (RBI/2019-20/67), paragraph 6; RBI circular on the Online Dispute Resolution system for digital payments (RBI/2020-21/21), paragraph 4", "rests_on": "rule" }, { "label": "When a customer may go to the ombudsman, and by when", "value": "The customer must take the grievance to the institution first. They may then go to an ombudsman if no reply came within thirty days, or within whatever longer period the Reserve Bank, NPCI or a card network sets for that kind of complaint, or at any point once they have a reply they are not satisfied with. The complaint must reach the ombudsman within ninety days of that period ending or of the last thing the institution said, whichever is later, and the complaint to the institution must itself have been made inside the ordinary limitation period. On UPI this is the Reserve Bank saying plainly that NPCI's own timelines can lengthen the wait, and those timelines are not public to Orca.", "citation": "RBI questions and answers on the Reserve Bank Integrated Ombudsman Scheme, 2026, questions 16 and 17", "rests_on": "rule" }, { "label": "Alerts the customer must get, and the ways they must be able to report", "value": "Banks must register customers for text message alerts, and for email alerts where they are available, and must send the text alerts. Reporting an unauthorised transaction, or a lost or stolen instrument, must be possible around the clock through several channels, including the website, phone banking, text message, email, an interactive voice response line, a dedicated toll free number and the customer's own branch. A customer must be able to object simply by replying to the alert, without hunting for an address, and the bank's home page must carry a direct link for reporting one. Every report gets an immediate acknowledgement with a complaint number. The bank must record when each message was delivered and when the customer answered, because that timing decides how much the customer owes. A bank may decline to offer electronic transactions, other than cash at a machine, to a customer who gives it no mobile number.", "citation": "RBI circular on limiting the liability of customers in unauthorised electronic banking transactions (RBI/2017-18/15), paragraph 5", "rests_on": "rule" }, { "label": "A digital payment is authenticated with at least two distinct factors", "value": "Every digital payment must be authenticated with at least two distinct factors, unless it is one of the exempted cases. A factor is something the customer has, something they know or something they are, and the directions give passwords, one time passwords by text message, passphrases, personal identification numbers, card hardware, software tokens and biometrics as examples. Outside a card present payment, at least one factor must be dynamic, meaning the proof sent with the payment is unique to that payment. The factors must be chosen so that breaking one does not weaken the other. An issuer may offer its customers a choice of factors.", "citation": "Reserve Bank of India (Authentication mechanisms for digital payment transactions) Directions, 2025, paragraphs 5, 6(a), 6(b) and 6(c)", "rests_on": "rule" }, { "label": "Which payments are exempt from two factor authentication, including a UPI tap and pay", "value": "The directions carry a list of use cases already exempted from the two factor requirement, and say that later additions apply too. Two of the listed cases touch UPI directly. A UPI tap and pay payment at a near field communication point of sale terminal is exempt, under a letter the Reserve Bank sent NPCI dated 2 September 2026. Recurring payments after the first one under the e-mandate framework are exempt as well. The list also covers small value contactless card payments, some prepaid instruments, toll collection, small value offline payments and certain corporate travel bookings.", "citation": "Reserve Bank of India (Authentication mechanisms for digital payment transactions) Directions, 2025, Annexure-1, items 1 to 7, in particular items 2 and 7", "rests_on": "rule" }, { "label": "Registering a recurring mandate, and getting out of one", "value": "A customer who wants recurring payments registers once, and the mandate takes effect only after an additional factor of authentication on top of whatever the issuer normally asks. Every registered mandate carries a validity period, and the issuer must give the customer a way to change that period or withdraw the mandate at any time, and must say so clearly when the mandate is set up. A mandate may be for a fixed amount, or for a varying amount within whatever overall cap the Reserve Bank has set, and for a varying one the customer must be able to set the largest single charge. The customer chooses how they are told before a charge. Changing or withdrawing a mandate needs the additional factor again.", "citation": "RBI Digital Payments E-mandate Framework, 2026, paragraph 4", "rests_on": "rule" }, { "label": "The customer is told at least a day before each recurring charge", "value": "The issuer must tell the customer at least twenty four hours before it actually takes the money. The notice must at the least name the merchant, the amount, the date and time of the debit, the mandate's reference number and the reason for the debit, which is the mandate the customer registered. The customer must be able to opt out of that one payment or of the mandate altogether, with the opt-out confirmed by an additional factor and acknowledged. The notice is not required where the mandate exists only to top up a toll tag or a national common mobility card.", "citation": "RBI Digital Payments E-mandate Framework, 2026, paragraph 6", "rests_on": "rule" }, { "label": "The customer is told after each recurring charge", "value": "After taking the money the issuer must tell the customer, naming at the least the merchant, the amount, the date and time of the debit, the reference numbers of the transaction and of the mandate, the reason for the debit, and how to complain.", "citation": "RBI Digital Payments E-mandate Framework, 2026, paragraph 7", "rests_on": "rule" }, { "label": "The first charge under a mandate is authenticated", "value": "The first payment under a recurring mandate needs an additional factor of authentication. Where that first payment is taken at the same time as the mandate is registered, one authentication may serve both. Payments made under a mandate are not subject to any other limits or controls the customer has set.", "citation": "RBI Digital Payments E-mandate Framework, 2026, paragraph 5", "rests_on": "rule" }, { "label": "A recurring mandate costs the customer nothing, and the acquirer answers for its merchants", "value": "No charge may be put on the customer for having a recurring mandate. Where cards are involved an existing mandate can be carried over to a reissued card. An acquirer must see to it that the merchants it has taken on comply with the directions.", "citation": "RBI Digital Payments E-mandate Framework, 2026, paragraph 10", "rests_on": "rule" } ], "exceptions": [ "The waiting period before an ombudsman is thirty days, or longer where the Reserve Bank, NPCI or a card network sets a longer one for that kind of complaint. On UPI that means NPCI's own periods can lengthen the wait, and those periods are not public to Orca.", "The turn around time and dispute resolution circulars still send customers to the 2021 ombudsman scheme, which the Reserve Bank replaced on 1 July 2026.", "Whether the 2026 scheme still reaches a customer of a payment system is unverified: the 2021 notification named system participants among the entities covered and the Reserve Bank's 2026 list of covered entities does not repeat that category." ], "applies_to": "UPI in India, in INR, as the Reserve Bank of India regulates it. The scheme rules NPCI writes for UPI are not held, so nothing here describes UPI's own message flow, clearing or dispute procedure.", "caveat": "Nothing here describes the dispute procedure NPCI runs between banks. The customer's route is the Reserve Bank's; the machinery behind it is NPCI's and is not held.", "related": [ "in-upi:liability", "in-upi:decision-points" ], "basis": { "sources": "RBI/2020-21/21 and its Annex, RBI/2019-20/67 paragraphs 5 and 6, the Integrated Ombudsman notification of 12 November 2021, the Reserve Bank's 2026 ombudsman questions and answers, RBI/2017-18/15 paragraph 5, RBI/2025-26/79 paragraph 6 with Annexure-1, and RBI/DPSS/2026-27/396, read 2026-09-20. The ombudsman lines rest on the Reserve Bank's own explanation rather than the scheme text, which is on a host that returned nothing, so the fact stays at medium.", "confidence": "medium" }, "currency": { "effective_since": "2021-01-01", "effective_to": null, "effective_note": "Drafted 2026-09-20 in Orca Core form from Reserve Bank of India material only, under the decision to publish in-upi as a regulator-only rail. NPCI's own rules for UPI are not public to Orca, so every facet NPCI governs says so instead of guessing.", "source_edition": "Reserve Bank of India documents read 2026-09-20: RBI/2019-20/67 of 20 September 2019, RBI/2020-21/21 of 6 August 2020, the Integrated Ombudsman notification of 12 November 2021, the 2026 Scheme questions and answers updated 1 July 2026, the certificates of authorisation dated 8 September 2026, two payment systems overview pages, RBI/2025-26/79 of 25 September 2025, RBI/2017-18/15 of 6 July 2017 and RBI/DPSS/2026-27/396 of 21 April 2026", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.rbi.org.in/Scripts/NotificationUser.aspx?Id=11946&Mode=0", "source_class": "authoritative_primary", "source_title": "RBI circular on the Online Dispute Resolution system for digital payments (RBI/2020-21/21)", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms the 1 January 2021 ODR duty, the TPAP in-app lodging requirement and the reference number tracking." }, { "source_url": "https://www.rbi.org.in/commonperson/english/scripts/FAQs.aspx?Id=3407", "source_class": "public_primary", "source_title": "RBI questions and answers on the Reserve Bank Integrated Ombudsman Scheme, 2026", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms the free, 90 day, 30 day wait ombudsman route." }, { "source_url": "https://www.rbi.org.in/Scripts/NotificationUser.aspx?Id=12898&Mode=0", "source_class": "authoritative_primary", "source_title": "Reserve Bank of India (Authentication mechanisms for digital payment transactions) Directions, 2025", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms the two factor minimum and the UPI tap and pay exemption." }, { "source_url": "https://www.rbi.org.in/Scripts/BS_ViewMasDirections.aspx?id=13374", "source_class": "authoritative_primary", "source_title": "RBI Digital Payments E-mandate Framework, 2026", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms the no-charge, notice and withdrawal rules for a recurring mandate." } ] }, "rail_name": "UPI (Unified Payments Interface)", "governing_authority": "Reserve Bank of India", "snapshot": "2026-09-20", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "in-upi:decision-points", "id": "decision-points", "rail": "in-upi", "kind": "rail-fact", "facet": "decision-points", "name": "Where does a rule leave the decision to a bank or a person?", "statement": "The Reserve Bank has pushed judgement out of the failed payment path and left it in three other places. The reversal of a failed payment is automatic and its compensation is credited without a complaint, so nobody decides whether the customer gets it. The dispute resolution system must be rule based and system driven with zero or minimal manual intervention, which is the regulator saying plainly that it does not want a person deciding a failed transaction. Judgement remains where a bank sets its own board approved policy for a customer who reported an unauthorised transaction more than seven working days late, where an issuer chooses to apply risk based checks above the two factor minimum, and where an ombudsman weighs whether there was deficiency in service and what to award. The judgement Orca cannot see at all is the interbank one: the decisions banks make about each other inside NPCI's dispute procedure.", "details": [ { "label": "The dispute resolution system is rule driven, with as little human judgement as possible", "value": "The dispute resolution system must be transparent, rule based, system driven, easy to use and unbiased, and must run with zero or minimal manual intervention. That is a statement about where judgement is allowed to sit: on a failed UPI transaction the regulator wants the answer computed, not decided.", "citation": "RBI circular on the Online Dispute Resolution system for digital payments (RBI/2020-21/21), Annex 2.1; paragraph 1", "rests_on": "rule" }, { "label": "Compensation is credited without waiting for the customer to complain", "value": "Where the framework provides financial compensation, the bank or operator credits it to the customer's account of its own motion. It does not wait for a complaint or a claim.", "citation": "RBI circular on turn around time and customer compensation for failed transactions (RBI/2019-20/67), paragraph 5", "rests_on": "rule" }, { "label": "When the customer bears part of the loss, and how much", "value": "Where the customer was negligent, for instance by sharing their credentials, they bear the whole loss up to the moment they report it, and everything after the report falls on the bank. Where the fault lay elsewhere in the system and the customer took between four and seven working days to report, their liability per transaction is the value of the transaction or a ceiling set by the type of account, whichever is smaller. The ceilings are 5,000 rupees for a basic savings account, 25,000 rupees for the larger current, cash credit and overdraft accounts and for credit cards with a limit above 5 lakh rupees, and 10,000 rupees for the ordinary accounts in between, including savings accounts generally, prepaid instruments and gift cards. Past seven working days, the bank's own board approved policy decides, and that policy must be published and given to customers. The working days are counted on the home branch's schedule and the day of the bank's communication is not counted.", "citation": "RBI circular on limiting the liability of customers in unauthorised electronic banking transactions (RBI/2017-18/15), paragraphs 7 and 8, with Tables 1 and 2", "rests_on": "rule" }, { "label": "An issuer may add checks above the minimum where the risk warrants it", "value": "An issuer may pick out payments to weigh against behavioural and contextual signals, such as where the payment is being made from, how the customer usually behaves, what the device looks like and the customer's past transactions, and may apply checks beyond the two factor minimum when the risk looks higher. This is discretion the regulator grants rather than a duty it imposes, and it is one of the few places in the Reserve Bank's UPI material where a bank is told it may decide for itself.", "citation": "Reserve Bank of India (Authentication mechanisms for digital payment transactions) Directions, 2025, paragraph 8", "rests_on": "rule" }, { "label": "How an ombudsman complaint ends", "value": "A complaint is first checked for whether it can be taken up at all, and closed with an explanation if it cannot. If it can, it goes to the institution for a reply, and the ombudsman's office weighs the complaint, the reply, the documents from both sides and the Reserve Bank's own instructions. It then ends in one of three ways: a settlement the parties reach with the ombudsman's help, an award directing the institution to act or to pay where deficiency in service is found, or a rejection with reasons. Both sides are told the outcome.", "citation": "RBI questions and answers on the Reserve Bank Integrated Ombudsman Scheme, 2026, questions 24 and 26", "rests_on": "rule" }, { "label": "The rules banks use to settle a UPI dispute between themselves are not held", "value": "Nothing in the Reserve Bank material Orca has read describes how two banks settle a UPI dispute between themselves: what a bank may raise against another, on what grounds, inside what deadline, who decides, and what happens when a bank does not answer in time. The Reserve Bank's own framework reaches the customer's side of this, through the automatic reversal, the compensation, the dispute resolution system and the ombudsman. The interbank side is NPCI's, and the Reserve Bank says so in passing: its own guidance on when a customer may go to an ombudsman defers to whatever period NPCI has set for that kind of complaint. Those periods and the procedure around them are not public to Orca, because NPCI's website answered a plain request with a refusal on 2026-09-20.", "citation": "RBI list of certificates of authorisation under the Payment and Settlement Systems Act, 2007, Retail Payments Organisation, entry 1, Unified Payments Interface, 24.08.2016; RBI overview page on payment and settlement systems (Payments Regulatory Board and NPCI systems), paragraph naming the systems NPCI operates; RBI questions and answers on the Reserve Bank Integrated Ombudsman Scheme, 2026, question 17", "rests_on": "guidance" } ], "exceptions": [ "A bank may waive a customer's liability even where the customer was careless, which is discretion in the customer's favour.", "The interbank decisions are NPCI's and are not held." ], "applies_to": "UPI in India, in INR, as the Reserve Bank of India regulates it. The scheme rules NPCI writes for UPI are not held, so nothing here describes UPI's own message flow, clearing or dispute procedure.", "caveat": "The most consequential judgement on this rail, what one bank may raise against another and who decides it, is inside NPCI's procedure and is not held.", "related": [ "in-upi:consumer-law", "in-upi:liability" ], "basis": { "sources": "RBI/2020-21/21 Annex 2.1, RBI/2019-20/67 paragraph 5, RBI/2017-18/15 paragraphs 7 and 9, RBI/2025-26/79 paragraph 8 and the Reserve Bank's 2026 ombudsman questions and answers, question 24, read 2026-09-20. This is Orca's reading of where judgement sits, which never reaches high confidence.", "confidence": "medium" }, "currency": { "effective_since": "2021-01-01", "effective_to": null, "effective_note": "Drafted 2026-09-20 in Orca Core form from Reserve Bank of India material only, under the decision to publish in-upi as a regulator-only rail. NPCI's own rules for UPI are not public to Orca, so every facet NPCI governs says so instead of guessing.", "source_edition": "Reserve Bank of India documents read 2026-09-20: RBI/2019-20/67 of 20 September 2019, RBI/2020-21/21 of 6 August 2020, the Integrated Ombudsman notification of 12 November 2021, the 2026 Scheme questions and answers updated 1 July 2026, the certificates of authorisation dated 8 September 2026, two payment systems overview pages, RBI/2025-26/79 of 25 September 2025, RBI/2017-18/15 of 6 July 2017 and RBI/DPSS/2026-27/396 of 21 April 2026", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.rbi.org.in/Scripts/NotificationUser.aspx?Id=11946&Mode=0", "source_class": "authoritative_primary", "source_title": "RBI circular on the Online Dispute Resolution system for digital payments (RBI/2020-21/21)", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms the rule based, system driven, minimal manual intervention requirement for the dispute resolution system." }, { "source_url": "https://www.rbi.org.in/Scripts/NotificationUser.aspx?Id=11040&Mode=0", "source_class": "authoritative_primary", "source_title": "RBI circular on limiting the liability of customers in unauthorised electronic banking transactions (RBI/2017-18/15)", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms the board approved policy governing delay beyond seven working days and the bank's discretion to waive customer liability." }, { "source_url": "https://www.rbi.org.in/Scripts/NotificationUser.aspx?Id=12898&Mode=0", "source_class": "authoritative_primary", "source_title": "Reserve Bank of India (Authentication mechanisms for digital payment transactions) Directions, 2025", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms the issuer's discretion to apply risk based checks above the two factor minimum." }, { "source_url": "https://www.rbi.org.in/commonperson/english/scripts/FAQs.aspx?Id=3407", "source_class": "public_primary", "source_title": "RBI questions and answers on the Reserve Bank Integrated Ombudsman Scheme, 2026", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms the ombudsman's weighing of deficiency in service before settlement, award or rejection." } ] }, "rail_name": "UPI (Unified Payments Interface)", "governing_authority": "Reserve Bank of India", "snapshot": "2026-09-20", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "in-upi:finality", "id": "finality", "rail": "in-upi", "kind": "rail-fact", "facet": "finality", "name": "When does a UPI payment become final?", "statement": "Not held. No Reserve Bank document Orca has read says at what moment a UPI payment becomes final or irrevocable. The rule sits with NPCI, which the Reserve Bank authorised to operate UPI on 24 August 2016. NPCI holds the answer and does not publish it to Orca: a plain automated request to its website returned HTTP 403 on 2026-09-20, and so did a request for its robots.txt, so even its crawl policy could not be read. What Orca can say instead is that a payment which failed does not stand: the Reserve Bank requires it to be reversed automatically and compensated if the reversal is late.", "details": [ { "label": "When a UPI payment becomes final is not held", "value": "Nothing in the Reserve Bank material Orca has read says at what moment a UPI payment becomes final, or what makes it irrevocable. The Reserve Bank regulates UPI and authorised NPCI to operate it; the rules that would answer this are NPCI's own. Those documents are not public to Orca: NPCI's website answered a plain request with a refusal on 2026-09-20, and its crawl policy file answered the same way, so the policy itself could not be read. Orca states no finality rule for UPI rather than guess one.", "citation": "RBI list of certificates of authorisation under the Payment and Settlement Systems Act, 2007, Retail Payments Organisation, entry 1, Unified Payments Interface, 24.08.2016; RBI overview page on payment and settlement systems (Payments Regulatory Board and NPCI systems), paragraph naming the systems NPCI operates", "rests_on": "guidance" }, { "label": "NPCI holds the authorisation for UPI, dated 24 August 2016", "value": "The Reserve Bank's register lists the National Payments Corporation of India as a Retail Payments Organisation and shows Unified Payments Interface among the payment systems it is authorised to set up and operate, with an authorisation date of 24 August 2016. The same entry carries NPCI's other authorisations, each with its own date, and a footnote that approvals for NPCI's international activities moved to NPCI International Payments Limited with effect from 10 August 2020.", "citation": "RBI list of certificates of authorisation under the Payment and Settlement Systems Act, 2007, Retail Payments Organisation, entry 1 and its footnote; RBI overview page on payment and settlement systems (Payments Regulatory Board and NPCI systems), paragraph naming the systems NPCI operates", "rests_on": "rule" }, { "label": "UPI funds transfer: automatic reversal at the latest on the day after the transaction", "value": "Where a UPI transfer of funds has debited the payer's account and the payee's account has not been credited, the payee's bank must reverse the payment automatically, at the latest on the day after the day of the transaction, and does not wait for the customer to ask. The day of the transaction is a calendar date. This is the regulator putting a failed payment back, not a scheme return of a payment that worked.", "citation": "RBI circular on turn around time and customer compensation for failed transactions (RBI/2019-20/67), Annex, row 4(a); general instructions 1, 2 and 4", "rests_on": "rule" } ], "exceptions": [ "A failed UPI payment is reversed automatically under the Reserve Bank's framework, which is not the same question as when a good payment becomes final." ], "applies_to": "UPI in India, in INR, as the Reserve Bank of India regulates it. The scheme rules NPCI writes for UPI are not held, so nothing here describes UPI's own message flow, clearing or dispute procedure.", "caveat": "A reader who needs UPI's finality rule must get it from NPCI, not from Orca.", "related": [ "in-upi:return", "in-upi:recall" ], "basis": { "sources": "The RBI certificates of authorisation dated 8 September 2026 and the RBI payment systems overview page establish that NPCI operates UPI; a plain request to NPCI's website on 2026-09-20 establishes that its rules cannot be read. No claim about finality is made.", "confidence": "low" }, "currency": { "effective_since": "2026-09-20", "effective_to": null, "effective_note": "Drafted 2026-09-20. The fact asserts who governs the subject and that Orca cannot read the governing document; it asserts nothing about the content. effective_since carries the date the Reserve Bank sources were read, because an absence has no start date.", "source_edition": "Reserve Bank of India documents read 2026-09-20: RBI/2019-20/67 of 20 September 2019, RBI/2020-21/21 of 6 August 2020, the Integrated Ombudsman notification of 12 November 2021, the 2026 Scheme questions and answers updated 1 July 2026, the certificates of authorisation dated 8 September 2026, two payment systems overview pages, RBI/2025-26/79 of 25 September 2025, RBI/2017-18/15 of 6 July 2017 and RBI/DPSS/2026-27/396 of 21 April 2026", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.rbi.org.in/Scripts/PublicationsView.aspx?id=12043", "source_class": "authoritative_primary", "source_title": "RBI list of certificates of authorisation under the Payment and Settlement Systems Act, 2007", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms NPCI as UPI's authorised operator since 24 August 2016; the record asserts nothing about UPI's finality rule." } ] }, "rail_name": "UPI (Unified Payments Interface)", "governing_authority": "Reserve Bank of India", "snapshot": "2026-09-20", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "in-upi:hours", "id": "hours", "rail": "in-upi", "kind": "rail-fact", "facet": "hours", "name": "When is UPI open?", "statement": "Not held. No Reserve Bank document Orca has read states UPI's operating hours, cut-offs or holiday behaviour. The Reserve Bank's overview page does say that the real time gross settlement system runs around the clock and that the national automated clearing house was made available on all days of the week, and says nothing of the sort about UPI. NPCI holds the answer and does not publish it to Orca: a plain automated request to its website returned HTTP 403 on 2026-09-20, and so did a request for its robots.txt, so even its crawl policy could not be read.", "details": [ { "label": "UPI's operating hours and cut-offs are not held", "value": "Nothing in the Reserve Bank material Orca has read states UPI's operating hours, its cut-off times or its behaviour on a holiday. The Reserve Bank's overview page says the real time gross settlement system and the national automated clearing house were made available around the clock and on all days, and says no such thing about UPI. The hours are NPCI's to set and publish, in rules that are not public to Orca: NPCI's website answered a plain request with a refusal on 2026-09-20.", "citation": "RBI list of certificates of authorisation under the Payment and Settlement Systems Act, 2007, Retail Payments Organisation, entry 1, Unified Payments Interface, 24.08.2016; RBI overview page on payment and settlement systems (Payments Regulatory Board and NPCI systems), paragraph naming the systems NPCI operates", "rests_on": "guidance" }, { "label": "NPCI holds the authorisation for UPI, dated 24 August 2016", "value": "The Reserve Bank's register lists the National Payments Corporation of India as a Retail Payments Organisation and shows Unified Payments Interface among the payment systems it is authorised to set up and operate, with an authorisation date of 24 August 2016. The same entry carries NPCI's other authorisations, each with its own date, and a footnote that approvals for NPCI's international activities moved to NPCI International Payments Limited with effect from 10 August 2020.", "citation": "RBI list of certificates of authorisation under the Payment and Settlement Systems Act, 2007, Retail Payments Organisation, entry 1 and its footnote; RBI overview page on payment and settlement systems (Payments Regulatory Board and NPCI systems), paragraph naming the systems NPCI operates", "rests_on": "rule" } ], "exceptions": [ "The Reserve Bank's turn around time deadlines are counted in calendar days from the date of the transaction, so they do not stop for a weekend or a holiday even though UPI's own hours are unknown." ], "applies_to": "UPI in India, in INR, as the Reserve Bank of India regulates it. The scheme rules NPCI writes for UPI are not held, so nothing here describes UPI's own message flow, clearing or dispute procedure.", "caveat": "The common claim that UPI is available 24 hours a day is not confirmed by any document Orca has read for this rail.", "related": [ "in-upi:settlement" ], "basis": { "sources": "The RBI payment systems overview page and the certificates of authorisation dated 8 September 2026, read 2026-09-20. That UPI runs around the clock is widely said and is [Unverified] here: no document read says it.", "confidence": "low" }, "currency": { "effective_since": "2026-09-20", "effective_to": null, "effective_note": "Drafted 2026-09-20. The fact asserts who governs the subject and that Orca cannot read the governing document; it asserts nothing about the content. effective_since carries the date the Reserve Bank sources were read, because an absence has no start date.", "source_edition": "Reserve Bank of India documents read 2026-09-20: RBI/2019-20/67 of 20 September 2019, RBI/2020-21/21 of 6 August 2020, the Integrated Ombudsman notification of 12 November 2021, the 2026 Scheme questions and answers updated 1 July 2026, the certificates of authorisation dated 8 September 2026, two payment systems overview pages, RBI/2025-26/79 of 25 September 2025, RBI/2017-18/15 of 6 July 2017 and RBI/DPSS/2026-27/396 of 21 April 2026", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "rail_name": "UPI (Unified Payments Interface)", "governing_authority": "Reserve Bank of India", "snapshot": "2026-09-20", "source_class": null, "effective_status": "draft", "effective_status_reason": null, "boundaries": [] }, { "uid": "in-upi:liability", "id": "liability", "rail": "in-upi", "kind": "rail-fact", "facet": "liability", "name": "Who bears the loss on a UPI payment?", "statement": "It depends which loss. For a payment that failed, the bank or operator that misses the reversal deadline pays the customer 100 rupees for every day of delay, without being asked. For a payment the customer says they never authorised, the Reserve Bank's framework applies: the customer owes nothing where the bank's own fault contributed, or where the fault lay elsewhere in the system and the customer reported within three working days; a capped amount, set by the type of account and never more than the transaction, where the report came within four to seven working days; and whatever the bank's published board approved policy says beyond seven. The bank credits the disputed amount within ten working days of the report and settles liability afterwards, within ninety days at the outside, and it is the bank that must prove the customer is liable at all. An issuer that authenticated the payment against the Reserve Bank's directions pays the whole loss without argument. An ombudsman can award up to 30 lakh rupees for consequential loss and a further 3 lakh for the customer's time and distress.", "details": [ { "label": "Compensation of 100 rupees for each day of delay beyond the deadline", "value": "When a reversal is late, the customer is owed 100 rupees for every day of delay beyond the deadline the framework sets for that kind of payment. On a UPI funds transfer the clock starts once the day after the transaction has passed; on a UPI payment to a merchant, once five days after the transaction have passed. This is a rate that accrues, not a ceiling on anything.", "citation": "RBI circular on turn around time and customer compensation for failed transactions (RBI/2019-20/67), Annex, rows 4(a) and 4(b); row 1(a) for the wording on crediting the account holder", "rests_on": "rule" }, { "label": "When the customer owes nothing on a transaction they did not authorise", "value": "The customer bears no part of the loss in two situations. The first is where the bank's own fraud, negligence or shortcoming contributed to it, and there it makes no difference whether the customer reported the transaction at all. The second is where the fault lay neither with the bank nor with the customer but somewhere else in the system, and the customer told the bank within three working days of the bank's communication about the transaction.", "citation": "RBI circular on limiting the liability of customers in unauthorised electronic banking transactions (RBI/2017-18/15), paragraph 6", "rests_on": "rule" }, { "label": "When the customer bears part of the loss, and how much", "value": "Where the customer was negligent, for instance by sharing their credentials, they bear the whole loss up to the moment they report it, and everything after the report falls on the bank. Where the fault lay elsewhere in the system and the customer took between four and seven working days to report, their liability per transaction is the value of the transaction or a ceiling set by the type of account, whichever is smaller. The ceilings are 5,000 rupees for a basic savings account, 25,000 rupees for the larger current, cash credit and overdraft accounts and for credit cards with a limit above 5 lakh rupees, and 10,000 rupees for the ordinary accounts in between, including savings accounts generally, prepaid instruments and gift cards. Past seven working days, the bank's own board approved policy decides, and that policy must be published and given to customers. The working days are counted on the home branch's schedule and the day of the bank's communication is not counted.", "citation": "RBI circular on limiting the liability of customers in unauthorised electronic banking transactions (RBI/2017-18/15), paragraphs 7 and 8, with Tables 1 and 2", "rests_on": "rule" }, { "label": "The money goes back within ten working days of the customer reporting", "value": "Once the customer notifies the bank, the bank credits the amount of the unauthorised transaction to the account within ten working days, without waiting for any insurance claim to settle, and value dates the credit to the day of the unauthorised transaction. This credit comes first and the question of who was liable is settled afterwards. A bank may waive the customer's liability even where the customer was careless.", "citation": "RBI circular on limiting the liability of customers in unauthorised electronic banking transactions (RBI/2017-18/15), paragraph 9", "rests_on": "rule" }, { "label": "The claim is settled within ninety days, or the customer is paid anyway", "value": "The bank must resolve the complaint and establish what the customer owes, if anything, inside the time its own board approved policy sets, and in no case later than ninety days from receiving the complaint. If it cannot do that in ninety days it pays the compensation the framework provides regardless. The customer must not lose interest on a debit account or carry extra interest on a credit card because of the episode.", "citation": "RBI circular on limiting the liability of customers in unauthorised electronic banking transactions (RBI/2017-18/15), paragraph 10", "rests_on": "rule" }, { "label": "The bank has to prove the customer is liable", "value": "Where a transaction is said to be unauthorised, the burden of proving that the customer is liable rests on the bank. The customer does not have to prove they did not do it.", "citation": "RBI circular on limiting the liability of customers in unauthorised electronic banking transactions (RBI/2017-18/15), paragraph 12", "rests_on": "rule" }, { "label": "An issuer that authenticates against the rules pays the whole loss", "value": "If a loss arises from a payment made without complying with the authentication directions, the issuer compensates the customer in full and without argument. The issuer must satisfy itself that its authentication mechanism is sound before it deploys it, and must comply with the data protection statute.", "citation": "Reserve Bank of India (Authentication mechanisms for digital payment transactions) Directions, 2025, paragraph 9", "rests_on": "rule" }, { "label": "Disputes on a recurring payment, and who bears an unauthorised one", "value": "The issuer must run a way for the customer to complain about a recurring payment. The Reserve Bank's instructions on limiting a customer's liability for unauthorised transactions apply to recurring payments taken under a mandate just as they do to any other.", "citation": "RBI Digital Payments E-mandate Framework, 2026, paragraph 9; RBI circular on limiting the liability of customers in unauthorised electronic banking transactions (RBI/2017-18/15), paragraphs 6 to 9", "rests_on": "rule" }, { "label": "The ombudsman costs the customer nothing and can award compensation", "value": "There is no fee to file or to have a complaint resolved. There is no ceiling on the amount in dispute that may be brought. For consequential loss the ombudsman may award up to 30 lakh rupees, and separately up to 3 lakh rupees for the complainant's lost time, expenses, harassment or mental anguish.", "citation": "RBI questions and answers on the Reserve Bank Integrated Ombudsman Scheme, 2026, questions 21, 22 and 23", "rests_on": "rule" } ], "exceptions": [ "The unauthorised transaction circular is addressed to scheduled commercial banks including regional rural banks, small finance banks and payments banks; a separate circular covers co-operative banks and was not read.", "How the loss is shared between two banks, as opposed to between a bank and its customer, is NPCI's to decide and is not held." ], "applies_to": "UPI in India, in INR, as the Reserve Bank of India regulates it. The scheme rules NPCI writes for UPI are not held, so nothing here describes UPI's own message flow, clearing or dispute procedure.", "caveat": "The 100 rupees a day is compensation for a late reversal. It says nothing about who bears the loss on a fraudulent payment, which is a different circular with different tests.", "related": [ "in-upi:consumer-law", "in-upi:return" ], "basis": { "sources": "RBI/2017-18/15 paragraphs 5 to 12, RBI/2019-20/67 Annex rows 4(a) and 4(b), RBI/2025-26/79 paragraph 9, RBI/DPSS/2026-27/396 paragraph 9 and the Reserve Bank's 2026 ombudsman questions and answers, read 2026-09-20. The fact stays at medium because the unauthorised transaction circular never names UPI: that it reaches a UPI payment is an [Inference] from its own category of remote payment transactions.", "confidence": "medium" }, "currency": { "effective_since": "2017-07-06", "effective_to": null, "effective_note": "Drafted 2026-09-20 in Orca Core form from Reserve Bank of India material only, under the decision to publish in-upi as a regulator-only rail. NPCI's own rules for UPI are not public to Orca, so every facet NPCI governs says so instead of guessing.", "source_edition": "Reserve Bank of India documents read 2026-09-20: RBI/2019-20/67 of 20 September 2019, RBI/2020-21/21 of 6 August 2020, the Integrated Ombudsman notification of 12 November 2021, the 2026 Scheme questions and answers updated 1 July 2026, the certificates of authorisation dated 8 September 2026, two payment systems overview pages, RBI/2025-26/79 of 25 September 2025, RBI/2017-18/15 of 6 July 2017 and RBI/DPSS/2026-27/396 of 21 April 2026", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.rbi.org.in/Scripts/NotificationUser.aspx?Id=11040&Mode=0", "source_class": "authoritative_primary", "source_title": "RBI circular on limiting the liability of customers in unauthorised electronic banking transactions (RBI/2017-18/15)", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms the zero, limited and full liability rules, the ten and ninety day deadlines and the burden of proof." }, { "source_url": "https://www.rbi.org.in/Scripts/NotificationUser.aspx?Id=12898&Mode=0", "source_class": "authoritative_primary", "source_title": "Reserve Bank of India (Authentication mechanisms for digital payment transactions) Directions, 2025", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms that an issuer whose authentication was non-compliant pays the whole loss." }, { "source_url": "https://www.rbi.org.in/commonperson/english/scripts/FAQs.aspx?Id=3407", "source_class": "public_primary", "source_title": "RBI questions and answers on the Reserve Bank Integrated Ombudsman Scheme, 2026", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms the ombudsman's compensation ceilings of 30 lakh rupees for consequential loss and 3 lakh rupees for time and distress." } ] }, "rail_name": "UPI (Unified Payments Interface)", "governing_authority": "Reserve Bank of India", "snapshot": "2026-09-20", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "in-upi:limits", "id": "limits", "rail": "in-upi", "kind": "rail-fact", "facet": "limits", "name": "What limits apply to a UPI payment?", "statement": "Orca holds one threshold, and it is not a limit on how much may be sent. Under the Reserve Bank's recurring payment framework, which says in its own applicability paragraph that it covers UPI, a recurring payment taken under a mandate may go through without the customer authenticating again up to 15,000 rupees, and up to 1,00,000 rupees where it is an insurance premium, a mutual fund subscription or a credit card bill. Above that the customer must authenticate. What Orca does not hold is UPI's actual value limits, per transaction, per day or by kind of payee: those are NPCI's to set, in rules that are not public to Orca.", "details": [ { "label": "Recurring payments up to 15,000 rupees need no fresh authentication", "value": "A recurring payment under a mandate may go through without an additional factor of authentication up to 15,000 rupees. Above that the customer must authenticate again.", "citation": "RBI Digital Payments E-mandate Framework, 2026, paragraph 8(a)", "rests_on": "rule" }, { "label": "Three kinds of recurring payment have a 1,00,000 rupee threshold instead", "value": "Insurance premiums, subscriptions to mutual funds and credit card bill payments may be taken under a mandate without an additional factor of authentication up to 1,00,000 rupees a transaction, rather than the ordinary 15,000.", "citation": "RBI Digital Payments E-mandate Framework, 2026, paragraph 8(b)", "rests_on": "rule" }, { "label": "UPI's per transaction and per day limits are not held", "value": "Nothing in the Reserve Bank material Orca has read states a limit on the value of a UPI payment, per transaction, per day or per kind of payee. The one monetary threshold Orca holds for UPI comes from the recurring payment framework and is about when a customer must authenticate again, not about how much may be sent. UPI's own limits are NPCI's to set, in rules that are not public to Orca: NPCI's website answered a plain request with a refusal on 2026-09-20. Limits also move faster than rules, so an unsourced figure would be wrong sooner than most.", "citation": "RBI list of certificates of authorisation under the Payment and Settlement Systems Act, 2007, Retail Payments Organisation, entry 1, Unified Payments Interface, 24.08.2016; RBI overview page on payment and settlement systems (Payments Regulatory Board and NPCI systems), paragraph naming the systems NPCI operates", "rests_on": "guidance" } ], "exceptions": [ "The two thresholds decide whether the customer must authenticate again, not how much may be sent.", "Value limits on UPI are reported to have moved in 2025, with person to merchant limits delegated to NPCI. Neither the Reserve Bank announcement nor the NPCI circular was read, so nothing about them is recorded." ], "applies_to": "UPI in India, in INR, as the Reserve Bank of India regulates it. The scheme rules NPCI writes for UPI are not held, so nothing here describes UPI's own message flow, clearing or dispute procedure.", "caveat": "Anyone who needs UPI's send limits must get them from NPCI. Limits also move faster than rules, so an unsourced figure here would go wrong sooner than most.", "related": [ "in-upi:consumer-law" ], "basis": { "sources": "RBI/DPSS/2026-27/396 paragraphs 2 and 8, read 2026-09-20, for the two thresholds; a plain request to NPCI's website on the same day for why UPI's own limits cannot be read. effective_since is the date of the recurring payment directions, which took effect immediately, and is not the date either threshold first applied, because those directions consolidate earlier circulars that were not read.", "confidence": "medium" }, "currency": { "effective_since": "2026-04-21", "effective_to": null, "effective_note": "Drafted 2026-09-20 in Orca Core form from Reserve Bank of India material only, under the decision to publish in-upi as a regulator-only rail. NPCI's own rules for UPI are not public to Orca, so every facet NPCI governs says so instead of guessing.", "source_edition": "Reserve Bank of India documents read 2026-09-20: RBI/2019-20/67 of 20 September 2019, RBI/2020-21/21 of 6 August 2020, the Integrated Ombudsman notification of 12 November 2021, the 2026 Scheme questions and answers updated 1 July 2026, the certificates of authorisation dated 8 September 2026, two payment systems overview pages, RBI/2025-26/79 of 25 September 2025, RBI/2017-18/15 of 6 July 2017 and RBI/DPSS/2026-27/396 of 21 April 2026", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.rbi.org.in/Scripts/BS_ViewMasDirections.aspx?id=13374", "source_class": "authoritative_primary", "source_title": "RBI Digital Payments E-mandate Framework, 2026", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms the framework's applicability to UPI and the two authentication thresholds of 15,000 and 1,00,000 rupees." } ] }, "rail_name": "UPI (Unified Payments Interface)", "governing_authority": "Reserve Bank of India", "snapshot": "2026-09-20", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "in-upi:messages", "id": "messages", "rail": "in-upi", "kind": "rail-fact", "facet": "messages", "name": "What message standard does UPI use, and what codes does it carry?", "statement": "Not held, and deliberately not guessed. No Reserve Bank document Orca has read describes UPI's messages, their fields, or the response and error codes written on them. No document read names a message standard for UPI at all, so nothing in the corpus should assume ISO 20022 meanings on this rail until a source that names one is opened. NPCI holds the answer and does not publish it to Orca: a plain automated request to its website returned HTTP 403 on 2026-09-20, and so did a request for its robots.txt, so even its crawl policy could not be read. No UPI code record exists in Orca and no UPI code list has been opened, so no code list's scope has been confirmed. The Reserve Bank's register shows NPCI authorised for several other payment systems on dates of their own, among them the Immediate Payment Service, the Aadhaar Enabled Payment System, RuPay affiliation, the National Automated Clearing House and toll collection, so a code list belonging to any of those is not a UPI list.", "details": [ { "label": "UPI's message standard, fields and response codes are not held", "value": "Nothing in the Reserve Bank material Orca has read describes UPI's messages: the standard they follow, their fields, or the response and error codes a participant writes on them. No document read names a message standard for UPI at all, so nothing in the corpus should assume ISO 20022 meanings on this rail until a source that names one is opened. The specification and the code lists are NPCI's and are not public to Orca: NPCI's website answered a plain request with a refusal on 2026-09-20, and its crawl policy file answered the same way. No UPI code record is drafted, and no code list has been opened, so none has had its scope confirmed. The Reserve Bank's register shows NPCI authorised for several other payment systems on dates of their own, among them the Immediate Payment Service, the Aadhaar Enabled Payment System, RuPay affiliation, the National Automated Clearing House and toll collection, so a code list belonging to any of those is not a UPI list. Check the scheme name in a document's own title before treating any Indian code list as UPI's.", "citation": "RBI list of certificates of authorisation under the Payment and Settlement Systems Act, 2007, Retail Payments Organisation, entry 1, Unified Payments Interface, 24.08.2016; RBI overview page on payment and settlement systems (Payments Regulatory Board and NPCI systems), paragraph naming the systems NPCI operates", "rests_on": "guidance" }, { "label": "UPI and the Immediate Payment Service are separate systems with separate deadlines", "value": "The framework gives UPI and the Immediate Payment Service rows of their own. The Immediate Payment Service has a single case, an account debited and the payee not credited, reversed at the latest on the day after the transaction. UPI is split in two: the same case on a transfer of funds, and a payment to a merchant where no confirmation reached the merchant, which runs to five days. A deadline or a code list that belongs to one of the two does not belong to the other.", "citation": "RBI circular on turn around time and customer compensation for failed transactions (RBI/2019-20/67), Annex, rows 3(a), 4(a) and 4(b); RBI list of certificates of authorisation under the Payment and Settlement Systems Act, 2007, Retail Payments Organisation, entry 1: Immediate Payment Service 12.10.2010 and Unified Payments Interface 24.08.2016", "rests_on": "rule" }, { "label": "NPCI holds the authorisation for UPI, dated 24 August 2016", "value": "The Reserve Bank's register lists the National Payments Corporation of India as a Retail Payments Organisation and shows Unified Payments Interface among the payment systems it is authorised to set up and operate, with an authorisation date of 24 August 2016. The same entry carries NPCI's other authorisations, each with its own date, and a footnote that approvals for NPCI's international activities moved to NPCI International Payments Limited with effect from 10 August 2020.", "citation": "RBI list of certificates of authorisation under the Payment and Settlement Systems Act, 2007, Retail Payments Organisation, entry 1 and its footnote; RBI overview page on payment and settlement systems (Payments Regulatory Board and NPCI systems), paragraph naming the systems NPCI operates", "rests_on": "rule" } ], "exceptions": [ "none known: nothing about UPI messages is held, so there is nothing to except." ], "applies_to": "UPI in India, in INR, as the Reserve Bank of India regulates it. The scheme rules NPCI writes for UPI are not held, so nothing here describes UPI's own message flow, clearing or dispute procedure.", "caveat": "Confirm the scheme name in a document's own title before treating any Indian response code list as UPI's. That confirmation has not been made for any list.", "related": [ "in-upi:participants" ], "basis": { "sources": "The RBI certificates of authorisation dated 8 September 2026, which authorises the Immediate Payment Service and UPI separately, and RBI/2019-20/67 Annex rows 3 and 4, which give them separate deadlines, read 2026-09-20; a plain request to NPCI's website on the same day for why the code lists cannot be read.", "confidence": "low" }, "currency": { "effective_since": "2026-09-20", "effective_to": null, "effective_note": "Drafted 2026-09-20. The fact asserts who governs the subject and that Orca cannot read the governing document; it asserts nothing about the content. effective_since carries the date the Reserve Bank sources were read, because an absence has no start date.", "source_edition": "Reserve Bank of India documents read 2026-09-20: RBI/2019-20/67 of 20 September 2019, RBI/2020-21/21 of 6 August 2020, the Integrated Ombudsman notification of 12 November 2021, the 2026 Scheme questions and answers updated 1 July 2026, the certificates of authorisation dated 8 September 2026, two payment systems overview pages, RBI/2025-26/79 of 25 September 2025, RBI/2017-18/15 of 6 July 2017 and RBI/DPSS/2026-27/396 of 21 April 2026", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.rbi.org.in/Scripts/PublicationsView.aspx?id=12043", "source_class": "authoritative_primary", "source_title": "RBI list of certificates of authorisation under the Payment and Settlement Systems Act, 2007", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms NPCI's separate authorisations for IMPS, AEPS, RuPay affiliation, NACH, NETC and UPI on their own dates; the record asserts nothing about UPI's own message content." }, { "source_url": "https://www.rbi.org.in/Scripts/NotificationUser.aspx?Id=11693&Mode=0", "source_class": "authoritative_primary", "source_title": "RBI circular on turn around time and customer compensation for failed transactions (RBI/2019-20/67)", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms that the Immediate Payment Service and UPI have separate annex rows with separate deadlines." } ] }, "rail_name": "UPI (Unified Payments Interface)", "governing_authority": "Reserve Bank of India", "snapshot": "2026-09-20", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "in-upi:participants", "id": "participants", "rail": "in-upi", "kind": "rail-fact", "facet": "participants", "name": "Who takes part in UPI, and who lets them?", "statement": "The Reserve Bank authorises the operator; NPCI runs the system; banks and non-banks participate; apps sit on top without a Reserve Bank authorisation of their own. Under section 4 of the Payment and Settlement Systems Act, 2007 nobody may run a payment system in India without Reserve Bank authorisation, and the Reserve Bank's published register shows the National Payments Corporation of India, as a Retail Payments Organisation, holding Unified Payments Interface with an authorisation date of 24 August 2016. The register holds no category for a UPI application provider and none of the best known UPI apps appears in it for UPI; the companies behind them appear for other businesses. Their place in UPI comes from NPCI's rules, which are not held. The Reserve Bank does place one duty directly on a third party app: let the customer raise a dispute inside it. Where the Reserve Bank's payment systems circulars write PSP they mean a Payment System Participant, a member of a payment system, and not UPI's payment service provider bank. UPI is also a family rather than one product: the Reserve Bank names UPI 123Pay for feature phone users as a distinct offering, and which UPI rule holds for which product is NPCI's to say.", "details": [ { "label": "Nobody may run a payment system in India without the Reserve Bank's authorisation", "value": "Under section 4 of the Payment and Settlement Systems Act, 2007, nobody other than the Reserve Bank may start or operate a payment system in India unless the Reserve Bank authorises it. The Act and the regulations under it came into effect on 12 August 2008. The Reserve Bank publishes the register of everyone it has authorised.", "citation": "RBI overview page on payment and settlement systems (Payments Regulatory Board and NPCI systems), legal frame paragraph; RBI overview page on payment and settlement systems (Board for Regulation and Supervision), Payment and Settlement Systems Act paragraph; RBI list of certificates of authorisation under the Payment and Settlement Systems Act, 2007, opening paragraphs", "rests_on": "rule" }, { "label": "NPCI holds the authorisation for UPI, dated 24 August 2016", "value": "The Reserve Bank's register lists the National Payments Corporation of India as a Retail Payments Organisation and shows Unified Payments Interface among the payment systems it is authorised to set up and operate, with an authorisation date of 24 August 2016. The same entry carries NPCI's other authorisations, each with its own date, and a footnote that approvals for NPCI's international activities moved to NPCI International Payments Limited with effect from 10 August 2020.", "citation": "RBI list of certificates of authorisation under the Payment and Settlement Systems Act, 2007, Retail Payments Organisation, entry 1 and its footnote; RBI overview page on payment and settlement systems (Payments Regulatory Board and NPCI systems), paragraph naming the systems NPCI operates", "rests_on": "rule" }, { "label": "The Reserve Bank authorises the operator of UPI, not the apps people pay with", "value": "The register of certificates of authorisation holds no category for a UPI application provider, and none of the best known UPI apps appears in it for UPI. The corporate groups behind them do appear, for other businesses: as bill payment operating units, as issuers of prepaid instruments and as payment aggregators. Their place in UPI comes from NPCI's rules, which are not public to Orca. The Reserve Bank does nonetheless put one duty directly on a third party application provider, namely to let a customer raise a dispute inside the app they paid in.", "citation": "RBI list of certificates of authorisation under the Payment and Settlement Systems Act, 2007, the register as a whole; Retail Payments Organisation, Bharat Bill Payment Operating Units, Prepaid Payment Instrument issuers and Payment Aggregators; RBI circular on the Online Dispute Resolution system for digital payments (RBI/2020-21/21), Annex 5.2", "rests_on": "rule" }, { "label": "The board that governs payment systems, and the Reserve Bank's own disagreement about it", "value": "The Reserve Bank is the designated authority for regulating and supervising payment systems, and it exercises the powers and duties given to it by sub-sections 1 and 2 of section 3 of the Payment and Settlement Systems Act through the Payments Regulatory Board. The Reserve Bank's other overview page still calls the Board for Regulation and Supervision of Payment and Settlement Systems the highest policy making body on payment systems in the country. Two Reserve Bank pages therefore say different things, and the page naming the Payments Regulatory Board and the 2025 regulations under it is the newer of the two. The Department of Payment and Settlement Systems is the secretariat and issues the circulars.", "citation": "RBI overview page on payment and settlement systems (Payments Regulatory Board and NPCI systems), Payments Regulatory Board paragraph and member table; RBI overview page on payment and settlement systems (Board for Regulation and Supervision), Board for Regulation and Supervision paragraph", "rests_on": "rule" }, { "label": "Bank in the framework includes a non-bank that is authorised", "value": "Where the framework says bank, it also means a non-bank, wherever that non-bank is authorised to operate. The circular is addressed to all operators and participants of authorised payment systems, not to banks alone.", "citation": "RBI circular on turn around time and customer compensation for failed transactions (RBI/2019-20/67), Annex, general instruction 6; addressee line", "rests_on": "rule" }, { "label": "UPI and the Immediate Payment Service are separate systems with separate deadlines", "value": "The framework gives UPI and the Immediate Payment Service rows of their own. The Immediate Payment Service has a single case, an account debited and the payee not credited, reversed at the latest on the day after the transaction. UPI is split in two: the same case on a transfer of funds, and a payment to a merchant where no confirmation reached the merchant, which runs to five days. A deadline or a code list that belongs to one of the two does not belong to the other.", "citation": "RBI circular on turn around time and customer compensation for failed transactions (RBI/2019-20/67), Annex, rows 3(a), 4(a) and 4(b); RBI list of certificates of authorisation under the Payment and Settlement Systems Act, 2007, Retail Payments Organisation, entry 1: Immediate Payment Service 12.10.2010 and Unified Payments Interface 24.08.2016", "rests_on": "rule" }, { "label": "An authentication or tokenisation service must be open to everything in its environment", "value": "A provider or participant offering authentication or tokenisation must make it reachable by every application and token requestor operating in that environment, for every use case, channel and way of storing a token. The environment means the device hardware, the operating system and the like.", "citation": "Reserve Bank of India (Authentication mechanisms for digital payment transactions) Directions, 2025, paragraph 7", "rests_on": "rule" }, { "label": "The recurring payment framework covers UPI", "value": "The Reserve Bank's consolidated directions on recurring payments state in their own applicability paragraph that they bind every payment system provider and payment system participant for recurring transactions, domestic or cross-border, made using cards, prepaid instruments or UPI. This is one of the few Reserve Bank instruments read for this rail that names UPI in its scope rather than in an example.", "citation": "RBI Digital Payments E-mandate Framework, 2026, paragraphs 1 and 2", "rests_on": "rule" } ], "exceptions": [ "The Reserve Bank's own two overview pages disagree about which board governs payment systems: the newer names the Payments Regulatory Board under section 3(3) and the older still calls the Board for Regulation and Supervision of Payment and Settlement Systems the highest policy making body.", "What a bank or an app must do to join UPI, who sponsors whom, and what each may do once in, are NPCI's rules and are not held.", "UPI 123Pay for feature phone users is held only as far as the Reserve Bank's description of it goes; UPI Lite, UPI Circle, credit line on UPI and RuPay credit card on UPI each have their own NPCI circulars and are not held at all." ], "applies_to": "UPI in India, in INR, as the Reserve Bank of India regulates it. The scheme rules NPCI writes for UPI are not held, so nothing here describes UPI's own message flow, clearing or dispute procedure.", "caveat": "PSP means two different things on this rail. In the Reserve Bank's circulars it is a Payment System Participant; in UPI's own vocabulary it is the bank that gives a customer a UPI handle, which no Reserve Bank document read defines.", "related": [ "in-upi:decision-points", "in-upi:messages" ], "basis": { "sources": "The RBI certificates of authorisation dated 8 September 2026, read entry by entry, the Reserve Bank's two payment systems overview pages, RBI/2020-21/21 Annex 5.2 and RBI/2019-20/67 Annex general instruction 6, read 2026-09-20. That no app is authorised for UPI rests on reading the register and finding nothing, which is weaker than a statement would be, so the fact stays at medium.", "confidence": "medium" }, "currency": { "effective_since": "2016-08-24", "effective_to": null, "effective_note": "Drafted 2026-09-20 in Orca Core form from Reserve Bank of India material only, under the decision to publish in-upi as a regulator-only rail. NPCI's own rules for UPI are not public to Orca, so every facet NPCI governs says so instead of guessing.", "source_edition": "Reserve Bank of India documents read 2026-09-20: RBI/2019-20/67 of 20 September 2019, RBI/2020-21/21 of 6 August 2020, the Integrated Ombudsman notification of 12 November 2021, the 2026 Scheme questions and answers updated 1 July 2026, the certificates of authorisation dated 8 September 2026, two payment systems overview pages, RBI/2025-26/79 of 25 September 2025, RBI/2017-18/15 of 6 July 2017 and RBI/DPSS/2026-27/396 of 21 April 2026", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "rail_name": "UPI (Unified Payments Interface)", "governing_authority": "Reserve Bank of India", "snapshot": "2026-09-20", "source_class": null, "effective_status": "draft", "effective_status_reason": null, "boundaries": [] }, { "uid": "in-upi:recall", "id": "recall", "rail": "in-upi", "kind": "rail-fact", "facet": "recall", "name": "Can a UPI payment be cancelled or recalled after it is sent?", "statement": "Not held. No Reserve Bank document Orca has read says whether a payer or a payer's bank can recall a UPI payment once it has gone. NPCI holds the answer and does not publish it to Orca: a plain automated request to its website returned HTTP 403 on 2026-09-20, and so did a request for its robots.txt, so even its crawl policy could not be read. Two nearby things exist and are not a recall. A payment that failed is reversed automatically by the regulator's own framework. A recurring mandate can be withdrawn at any time, and a single charge under it opted out of before it is taken, but that stops future money rather than clawing back money already sent.", "details": [ { "label": "Whether a sent UPI payment can be recalled is not held", "value": "Nothing in the Reserve Bank material Orca has read says whether a payer or a payer's bank can recall a UPI payment once it has gone, or on what grounds. What the Reserve Bank does provide is the automatic reversal of a payment that failed, which is a different thing: it is the regulator putting back money that never reached the payee, not a way to undo a payment that worked. Any recall right there may be is in NPCI's rules, which are not public to Orca: NPCI's website answered a plain request with a refusal on 2026-09-20.", "citation": "RBI list of certificates of authorisation under the Payment and Settlement Systems Act, 2007, Retail Payments Organisation, entry 1, Unified Payments Interface, 24.08.2016; RBI overview page on payment and settlement systems (Payments Regulatory Board and NPCI systems), paragraph naming the systems NPCI operates", "rests_on": "guidance" }, { "label": "UPI funds transfer: automatic reversal at the latest on the day after the transaction", "value": "Where a UPI transfer of funds has debited the payer's account and the payee's account has not been credited, the payee's bank must reverse the payment automatically, at the latest on the day after the day of the transaction, and does not wait for the customer to ask. The day of the transaction is a calendar date. This is the regulator putting a failed payment back, not a scheme return of a payment that worked.", "citation": "RBI circular on turn around time and customer compensation for failed transactions (RBI/2019-20/67), Annex, row 4(a); general instructions 1, 2 and 4", "rests_on": "rule" }, { "label": "Registering a recurring mandate, and getting out of one", "value": "A customer who wants recurring payments registers once, and the mandate takes effect only after an additional factor of authentication on top of whatever the issuer normally asks. Every registered mandate carries a validity period, and the issuer must give the customer a way to change that period or withdraw the mandate at any time, and must say so clearly when the mandate is set up. A mandate may be for a fixed amount, or for a varying amount within whatever overall cap the Reserve Bank has set, and for a varying one the customer must be able to set the largest single charge. The customer chooses how they are told before a charge. Changing or withdrawing a mandate needs the additional factor again.", "citation": "RBI Digital Payments E-mandate Framework, 2026, paragraph 4", "rests_on": "rule" }, { "label": "The customer is told at least a day before each recurring charge", "value": "The issuer must tell the customer at least twenty four hours before it actually takes the money. The notice must at the least name the merchant, the amount, the date and time of the debit, the mandate's reference number and the reason for the debit, which is the mandate the customer registered. The customer must be able to opt out of that one payment or of the mandate altogether, with the opt-out confirmed by an additional factor and acknowledged. The notice is not required where the mandate exists only to top up a toll tag or a national common mobility card.", "citation": "RBI Digital Payments E-mandate Framework, 2026, paragraph 6", "rests_on": "rule" } ], "exceptions": [ "A recurring mandate can be withdrawn, and a particular charge under it opted out of before the debit, both behind an additional factor of authentication. That is a right against future payments, not against a payment already made." ], "applies_to": "UPI in India, in INR, as the Reserve Bank of India regulates it. The scheme rules NPCI writes for UPI are not held, so nothing here describes UPI's own message flow, clearing or dispute procedure.", "caveat": "Do not read the automatic reversal of a failed payment as a recall right. They have different triggers, different actors and different clocks.", "related": [ "in-upi:return", "in-upi:finality" ], "basis": { "sources": "RBI/DPSS/2026-27/396 paragraphs 4 and 6 and RBI/2019-20/67 Annex row 4(a), read 2026-09-20, for the two nearby rights; a plain request to NPCI's website on the same day for why the recall rule itself cannot be read.", "confidence": "low" }, "currency": { "effective_since": "2026-09-20", "effective_to": null, "effective_note": "Drafted 2026-09-20. The fact asserts who governs the subject and that Orca cannot read the governing document; it asserts nothing about the content. effective_since carries the date the Reserve Bank sources were read, because an absence has no start date.", "source_edition": "Reserve Bank of India documents read 2026-09-20: RBI/2019-20/67 of 20 September 2019, RBI/2020-21/21 of 6 August 2020, the Integrated Ombudsman notification of 12 November 2021, the 2026 Scheme questions and answers updated 1 July 2026, the certificates of authorisation dated 8 September 2026, two payment systems overview pages, RBI/2025-26/79 of 25 September 2025, RBI/2017-18/15 of 6 July 2017 and RBI/DPSS/2026-27/396 of 21 April 2026", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.rbi.org.in/Scripts/BS_ViewMasDirections.aspx?id=13374", "source_class": "authoritative_primary", "source_title": "RBI Digital Payments E-mandate Framework, 2026", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms the mandate withdrawal and per-charge opt-out rights, which stop future payments rather than clawing back one already made." }, { "source_url": "https://www.rbi.org.in/Scripts/NotificationUser.aspx?Id=11693&Mode=0", "source_class": "authoritative_primary", "source_title": "RBI circular on turn around time and customer compensation for failed transactions (RBI/2019-20/67)", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms the automatic reversal of a failed funds transfer as a distinct, regulator-mandated mechanism." } ] }, "rail_name": "UPI (Unified Payments Interface)", "governing_authority": "Reserve Bank of India", "snapshot": "2026-09-20", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "in-upi:refund", "id": "refund", "rail": "in-upi", "kind": "rail-fact", "facet": "refund", "name": "How does a UPI refund work?", "statement": "Not held. No Reserve Bank document Orca has read describes a merchant refunding a UPI payment: how it is sent, how long it may take, or whether it travels as a fresh payment or as a reversal of the original. NPCI holds the answer and does not publish it to Orca: a plain automated request to its website returned HTTP 403 on 2026-09-20, and so did a request for its robots.txt, so even its crawl policy could not be read. The automatic reversal the Reserve Bank does mandate is for payments that failed, not for goods that disappointed.", "details": [ { "label": "How a UPI refund is made is not held", "value": "Nothing in the Reserve Bank material Orca has read describes a refund on UPI: how a merchant sends money back for goods not delivered, how long it takes, or whether it travels as a new payment or as a reversal of the old one. The automatic reversal the Reserve Bank mandates is for failed payments only. The refund mechanics are NPCI's, in rules that are not public to Orca: NPCI's website answered a plain request with a refusal on 2026-09-20.", "citation": "RBI list of certificates of authorisation under the Payment and Settlement Systems Act, 2007, Retail Payments Organisation, entry 1, Unified Payments Interface, 24.08.2016; RBI overview page on payment and settlement systems (Payments Regulatory Board and NPCI systems), paragraph naming the systems NPCI operates", "rests_on": "guidance" }, { "label": "UPI payment to a merchant: automatic reversal within five days of the transaction", "value": "Where a UPI payment to a merchant has debited the payer's account and no confirmation of the transaction reached the merchant, the payment must be reversed automatically within five days of the day of the transaction. The row does not say which bank must do the reversing; on the funds transfer row the duty sits with the payee's bank, and the framework's own principle puts a credit that did not arrive on the credit side.", "citation": "RBI circular on turn around time and customer compensation for failed transactions (RBI/2019-20/67), Annex, row 4(b); general instructions 1 and 4", "rests_on": "rule" } ], "exceptions": [ "A UPI payment to a merchant that was debited without the merchant getting confirmation is reversed automatically within five days of the transaction. That is a failed payment, not a refund." ], "applies_to": "UPI in India, in INR, as the Reserve Bank of India regulates it. The scheme rules NPCI writes for UPI are not held, so nothing here describes UPI's own message flow, clearing or dispute procedure.", "caveat": "A customer's dispute with a merchant about goods or services is a separate matter from either the failed payment path or an NPCI refund mechanism, and no document read here addresses it.", "related": [ "in-upi:return" ], "basis": { "sources": "RBI/2019-20/67 Annex row 4(b), read 2026-09-20, for what the regulator does cover; a plain request to NPCI's website on the same day for why the refund rule cannot be read.", "confidence": "low" }, "currency": { "effective_since": "2026-09-20", "effective_to": null, "effective_note": "Drafted 2026-09-20. The fact asserts who governs the subject and that Orca cannot read the governing document; it asserts nothing about the content. effective_since carries the date the Reserve Bank sources were read, because an absence has no start date.", "source_edition": "Reserve Bank of India documents read 2026-09-20: RBI/2019-20/67 of 20 September 2019, RBI/2020-21/21 of 6 August 2020, the Integrated Ombudsman notification of 12 November 2021, the 2026 Scheme questions and answers updated 1 July 2026, the certificates of authorisation dated 8 September 2026, two payment systems overview pages, RBI/2025-26/79 of 25 September 2025, RBI/2017-18/15 of 6 July 2017 and RBI/DPSS/2026-27/396 of 21 April 2026", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.rbi.org.in/Scripts/NotificationUser.aspx?Id=11693&Mode=0", "source_class": "authoritative_primary", "source_title": "RBI circular on turn around time and customer compensation for failed transactions (RBI/2019-20/67)", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms that the automatic reversal the regulator mandates is for a payment that failed to reach the merchant, not a refund for goods." } ] }, "rail_name": "UPI (Unified Payments Interface)", "governing_authority": "Reserve Bank of India", "snapshot": "2026-09-20", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "in-upi:return", "id": "return", "rail": "in-upi", "kind": "rail-fact", "facet": "return", "name": "What happens when a UPI payment does not reach the payee?", "statement": "The Reserve Bank makes it automatic. Where a UPI transfer of funds debited the payer and the payee was not credited, the payee's bank must reverse it at the latest on the day after the transaction. Where a UPI payment to a merchant was debited and no confirmation reached the merchant, the reversal must happen within five days of the transaction. Both clocks run from the calendar date of the transaction, and once the money comes back the payer's bank must credit it the same day. Late reversal costs 100 rupees for every day of delay, credited to the customer without a complaint. What is not held is the other half of the picture: the rules two banks use to settle a UPI dispute between themselves, which are NPCI's and are not public to Orca.", "details": [ { "label": "UPI funds transfer: automatic reversal at the latest on the day after the transaction", "value": "Where a UPI transfer of funds has debited the payer's account and the payee's account has not been credited, the payee's bank must reverse the payment automatically, at the latest on the day after the day of the transaction, and does not wait for the customer to ask. The day of the transaction is a calendar date. This is the regulator putting a failed payment back, not a scheme return of a payment that worked.", "citation": "RBI circular on turn around time and customer compensation for failed transactions (RBI/2019-20/67), Annex, row 4(a); general instructions 1, 2 and 4", "rests_on": "rule" }, { "label": "UPI payment to a merchant: automatic reversal within five days of the transaction", "value": "Where a UPI payment to a merchant has debited the payer's account and no confirmation of the transaction reached the merchant, the payment must be reversed automatically within five days of the day of the transaction. The row does not say which bank must do the reversing; on the funds transfer row the duty sits with the payee's bank, and the framework's own principle puts a credit that did not arrive on the credit side.", "citation": "RBI circular on turn around time and customer compensation for failed transactions (RBI/2019-20/67), Annex, row 4(b); general instructions 1 and 4", "rests_on": "rule" }, { "label": "How the two days in the deadline are counted", "value": "Two days matter. The day of the transaction is a calendar date, and every deadline is counted from it. The day of reversal is the day the reversal concludes and the money reaches the payer's side. Once the funds come back from the payee's side, the payer's bank must put them in the customer's account the same day.", "citation": "RBI circular on turn around time and customer compensation for failed transactions (RBI/2019-20/67), Annex, general instructions 4 and 5", "rests_on": "rule" }, { "label": "What counts as a failed transaction", "value": "A failed transaction is one that did not complete for a reason the customer is not responsible for: a communication link that went down, a session that timed out, an automated teller machine with no cash, and the like. Credits that could not be made to the payee because the information was missing or wrong count as failures too, and so does a delay in starting the reversal. A payment the customer simply regrets is not a failed transaction.", "citation": "RBI circular on turn around time and customer compensation for failed transactions (RBI/2019-20/67), Annex, general instruction 2; paragraph 2", "rests_on": "rule" }, { "label": "The stated deadline is an outer limit, not a target", "value": "The turn around time the framework prescribes is the outer limit for resolving a failed transaction. Banks and other operators and participants are to work towards resolving failures faster than it. A reversal that lands on the last permitted day is compliant and is not what the framework asks for.", "citation": "RBI circular on turn around time and customer compensation for failed transactions (RBI/2019-20/67), paragraph 4", "rests_on": "rule" }, { "label": "Compensation of 100 rupees for each day of delay beyond the deadline", "value": "When a reversal is late, the customer is owed 100 rupees for every day of delay beyond the deadline the framework sets for that kind of payment. On a UPI funds transfer the clock starts once the day after the transaction has passed; on a UPI payment to a merchant, once five days after the transaction have passed. This is a rate that accrues, not a ceiling on anything.", "citation": "RBI circular on turn around time and customer compensation for failed transactions (RBI/2019-20/67), Annex, rows 4(a) and 4(b); row 1(a) for the wording on crediting the account holder", "rests_on": "rule" }, { "label": "Compensation is credited without waiting for the customer to complain", "value": "Where the framework provides financial compensation, the bank or operator credits it to the customer's account of its own motion. It does not wait for a complaint or a claim.", "citation": "RBI circular on turn around time and customer compensation for failed transactions (RBI/2019-20/67), paragraph 5", "rests_on": "rule" }, { "label": "The framework covers payments that begin and end in India", "value": "The reversal deadlines and the compensation apply to domestic transactions, meaning those where both the payer and the payee are in India. A payment with a leg outside India is outside this framework.", "citation": "RBI circular on turn around time and customer compensation for failed transactions (RBI/2019-20/67), Annex, general instruction 7", "rests_on": "rule" }, { "label": "UPI and the Immediate Payment Service are separate systems with separate deadlines", "value": "The framework gives UPI and the Immediate Payment Service rows of their own. The Immediate Payment Service has a single case, an account debited and the payee not credited, reversed at the latest on the day after the transaction. UPI is split in two: the same case on a transfer of funds, and a payment to a merchant where no confirmation reached the merchant, which runs to five days. A deadline or a code list that belongs to one of the two does not belong to the other.", "citation": "RBI circular on turn around time and customer compensation for failed transactions (RBI/2019-20/67), Annex, rows 3(a), 4(a) and 4(b); RBI list of certificates of authorisation under the Payment and Settlement Systems Act, 2007, Retail Payments Organisation, entry 1: Immediate Payment Service 12.10.2010 and Unified Payments Interface 24.08.2016", "rests_on": "rule" }, { "label": "The rules banks use to settle a UPI dispute between themselves are not held", "value": "Nothing in the Reserve Bank material Orca has read describes how two banks settle a UPI dispute between themselves: what a bank may raise against another, on what grounds, inside what deadline, who decides, and what happens when a bank does not answer in time. The Reserve Bank's own framework reaches the customer's side of this, through the automatic reversal, the compensation, the dispute resolution system and the ombudsman. The interbank side is NPCI's, and the Reserve Bank says so in passing: its own guidance on when a customer may go to an ombudsman defers to whatever period NPCI has set for that kind of complaint. Those periods and the procedure around them are not public to Orca, because NPCI's website answered a plain request with a refusal on 2026-09-20.", "citation": "RBI list of certificates of authorisation under the Payment and Settlement Systems Act, 2007, Retail Payments Organisation, entry 1, Unified Payments Interface, 24.08.2016; RBI overview page on payment and settlement systems (Payments Regulatory Board and NPCI systems), paragraph naming the systems NPCI operates; RBI questions and answers on the Reserve Bank Integrated Ombudsman Scheme, 2026, question 17", "rests_on": "guidance" } ], "exceptions": [ "The framework covers only domestic payments, meaning those where both payer and payee are in India.", "The merchant row names no bank; that the duty falls on the payee's side is an inference from the framework's own principle.", "The interbank dispute and chargeback path NPCI runs is a different mechanism with a different clock and different decision makers, and it is not held." ], "applies_to": "UPI in India, in INR, as the Reserve Bank of India regulates it. The scheme rules NPCI writes for UPI are not held, so nothing here describes UPI's own message flow, clearing or dispute procedure.", "caveat": "This is the regulator reversing a payment that failed. It is not a scheme return of a payment that worked, and it is not NPCI's chargeback.", "related": [ "in-upi:refund", "in-upi:recall", "in-upi:liability" ], "basis": { "sources": "RBI/2019-20/67 and its Annex, read 2026-09-20 and restated in Orca's own words. The Immediate Payment Service has its own row with its own single case; do not carry a deadline or a code from one to the other.", "confidence": "high" }, "currency": { "effective_since": "2019-10-15", "effective_to": null, "effective_note": "Drafted 2026-09-20 in Orca Core form from Reserve Bank of India material only, under the decision to publish in-upi as a regulator-only rail. NPCI's own rules for UPI are not public to Orca, so every facet NPCI governs says so instead of guessing.", "source_edition": "Reserve Bank of India documents read 2026-09-20: RBI/2019-20/67 of 20 September 2019, RBI/2020-21/21 of 6 August 2020, the Integrated Ombudsman notification of 12 November 2021, the 2026 Scheme questions and answers updated 1 July 2026, the certificates of authorisation dated 8 September 2026, two payment systems overview pages, RBI/2025-26/79 of 25 September 2025, RBI/2017-18/15 of 6 July 2017 and RBI/DPSS/2026-27/396 of 21 April 2026", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.rbi.org.in/Scripts/NotificationUser.aspx?Id=11693&Mode=0", "source_class": "authoritative_primary", "source_title": "RBI circular on turn around time and customer compensation for failed transactions (RBI/2019-20/67)", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms the automatic reversal deadlines for both UPI cases, the calendar day anchor, the same day credit on receipt, and the 100 rupee per day compensation." } ] }, "rail_name": "UPI (Unified Payments Interface)", "governing_authority": "Reserve Bank of India", "snapshot": "2026-09-20", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "in-upi:settlement", "id": "settlement", "rail": "in-upi", "kind": "rail-fact", "facet": "settlement", "name": "How and when do UPI positions settle?", "statement": "Not held. No Reserve Bank document Orca has read says how UPI is cleared and settled, in whose books, on how many cycles a day, or what happens when a participant cannot fund its position. The Reserve Bank names NPCI a Retail Payments Organisation and authorises it for UPI, and stops there. NPCI holds the answer and does not publish it to Orca: a plain automated request to its website returned HTTP 403 on 2026-09-20, and so did a request for its robots.txt, so even its crawl policy could not be read.", "details": [ { "label": "How and when UPI positions settle is not held", "value": "Nothing in the Reserve Bank material Orca has read says how UPI positions are cleared and settled, in whose books, on how many cycles a day, or what happens if a participant cannot fund its position. The Reserve Bank names NPCI a Retail Payments Organisation and authorises it for UPI, and says nothing about the mechanics. The answer is NPCI's and is not public to Orca: NPCI's website answered a plain request with a refusal on 2026-09-20, and its crawl policy file answered the same way.", "citation": "RBI list of certificates of authorisation under the Payment and Settlement Systems Act, 2007, Retail Payments Organisation, entry 1, Unified Payments Interface, 24.08.2016; RBI overview page on payment and settlement systems (Payments Regulatory Board and NPCI systems), paragraph naming the systems NPCI operates", "rests_on": "guidance" }, { "label": "NPCI holds the authorisation for UPI, dated 24 August 2016", "value": "The Reserve Bank's register lists the National Payments Corporation of India as a Retail Payments Organisation and shows Unified Payments Interface among the payment systems it is authorised to set up and operate, with an authorisation date of 24 August 2016. The same entry carries NPCI's other authorisations, each with its own date, and a footnote that approvals for NPCI's international activities moved to NPCI International Payments Limited with effect from 10 August 2020.", "citation": "RBI list of certificates of authorisation under the Payment and Settlement Systems Act, 2007, Retail Payments Organisation, entry 1 and its footnote; RBI overview page on payment and settlement systems (Payments Regulatory Board and NPCI systems), paragraph naming the systems NPCI operates", "rests_on": "rule" } ], "exceptions": [ "none known: no Reserve Bank text read describes UPI settlement at all, so there is nothing to except." ], "applies_to": "UPI in India, in INR, as the Reserve Bank of India regulates it. The scheme rules NPCI writes for UPI are not held, so nothing here describes UPI's own message flow, clearing or dispute procedure.", "caveat": "No settlement rule for UPI was found at any address that answered a request, so Orca cannot say whether NPCI publishes one at all.", "related": [ "in-upi:finality" ], "basis": { "sources": "The RBI certificates of authorisation dated 8 September 2026 and the RBI payment systems overview page, read 2026-09-20, for who operates UPI; a plain request to NPCI's website on the same day for why its rules cannot be read.", "confidence": "low" }, "currency": { "effective_since": "2026-09-20", "effective_to": null, "effective_note": "Drafted 2026-09-20. The fact asserts who governs the subject and that Orca cannot read the governing document; it asserts nothing about the content. effective_since carries the date the Reserve Bank sources were read, because an absence has no start date.", "source_edition": "Reserve Bank of India documents read 2026-09-20: RBI/2019-20/67 of 20 September 2019, RBI/2020-21/21 of 6 August 2020, the Integrated Ombudsman notification of 12 November 2021, the 2026 Scheme questions and answers updated 1 July 2026, the certificates of authorisation dated 8 September 2026, two payment systems overview pages, RBI/2025-26/79 of 25 September 2025, RBI/2017-18/15 of 6 July 2017 and RBI/DPSS/2026-27/396 of 21 April 2026", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.rbi.org.in/Scripts/PublicationsView.aspx?id=12043", "source_class": "authoritative_primary", "source_title": "RBI list of certificates of authorisation under the Payment and Settlement Systems Act, 2007", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms NPCI as UPI's authorised operator; the record asserts nothing about UPI's settlement mechanics." } ] }, "rail_name": "UPI (Unified Payments Interface)", "governing_authority": "Reserve Bank of India", "snapshot": "2026-09-20", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "mastercard:consumer-law", "id": "consumer-law", "rail": "mastercard", "kind": "rail-fact", "facet": "consumer-law", "name": "How do Mastercard's rules relate to consumer protection law?", "statement": "Mastercard's rules give cardholders their own protections and step aside where law gives more: law prevails on cardholder liability, can shorten the issuer's time to charge back, limits how long an issuer may hold refunded funds, and in Europe drives strong customer authentication and a refund right for authorized transactions. The rules do not restate the laws, and Orca has not read the laws themselves.", "details": [ { "label": "Liability", "value": "The cardholder protection rule gives way to law that imposes greater liability or a conflicting duty.", "citation": "Mastercard Rules, 2 June 2026, rule 6.3 (p. 140)", "rests_on": "rule" }, { "label": "Dispute handling", "value": "The issuer's 60-day window to charge back after a cardholder dispute is shortened where law or regulation sets a shorter period, and the issuer need not charge back where law prohibits it.", "citation": "Mastercard Rules, 2 June 2026, rule 6.2.3 (p. 139)", "rests_on": "rule" }, { "label": "Refund holds", "value": "An issuer may put a temporary hold on refunded funds only to the extent applicable law allows.", "citation": "Transaction Processing Rules, 9 June 2026, rule 2.13.2 (p. 67)", "rests_on": "rule" }, { "label": "Refunds required by law", "value": "Where law requires a merchant such as an airline to refund, and the card cannot take it, the merchant uses its own refund policy; refund restrictions yield to law, regulation or a regulator's direction.", "citation": "Transaction Processing Rules, 9 June 2026, rules 3.14 and 3.14.1 (pp. 139 to 140)", "rests_on": "rule" }, { "label": "Europe: SCA", "value": "In the countries Mastercard lists as SCA countries, an issuer must decline a remote electronic transaction that lacks required strong customer authentication with the soft decline code of its chosen switch, and use that code for no other reason; the merchant must then try EMV 3DS or another SCA method. Where a charge exceeds what the cardholder could reasonably expect, the refund right for authorized transactions in the legislation may apply.", "citation": "Transaction Processing Rules, 9 June 2026, Europe Region rules 5.1.1 and 5.1.2 (pp. 226 to 227)", "rests_on": "rule" }, { "label": "Authentication by law", "value": "Where law requires, as in the EEA and UK, an issuer may use other authentication methods that meet Mastercard Identity Check performance indicators.", "citation": "Transaction Processing Rules, 9 June 2026, rule 3.4 (p. 126)", "rests_on": "rule" } ], "exceptions": [ "United States: Regulation E (debit) and Regulation Z (credit) were not read; how they interact with rule 6.3 is not stated in the rules read [Unverified].", "EEA and UK: the payment services legislation behind SCA and the refund right was not read [Unverified].", "Commercial cards other than small business cards are outside Mastercard's own cardholder liability and dispute rules (Mastercard Rules rules 6.2.3 and 6.3)." ], "applies_to": "All Mastercard regions; the SCA line applies to SCA countries in the Europe Region and to Albania, Montenegro, North Macedonia and Serbia for intracountry transactions", "caveat": "This fact records where Mastercard's rules defer to law. It is not a statement of what any law requires.", "related": [ "mastercard:liability", "mastercard:refund", "mastercard:return" ], "basis": { "sources": "Mastercard Rules (2 June 2026) rules 6.2.3, 6.3; Transaction Processing Rules (9 June 2026) rules 2.13.2, 3.4, 3.14, 3.14.1 and Europe Region 5.1.1, 5.1.2. Read from copies downloaded from Mastercard's public rules page on 2026-09-19. Nothing is quoted. Medium: the lines report the rules' own references to law; the laws were not read.", "confidence": "medium" }, "currency": { "effective_since": "Before the current editions; start not stated in them", "effective_note": "Rules as stated in the Mastercard Rules of 2 June 2026, the Transaction Processing Rules of 9 June 2026, the Security Rules and Procedures Merchant Edition of 4 August 2026, the Quick Reference Booklet of 2 June 2026 and the Chargebacks Made Simple Guide of July 2025, as downloaded from Mastercard's public rules page on 2026-09-19. New editions drop past effective dates, so when a rule began is often not shown. Mastercard reissues its manuals on no fixed calendar and announces changes on Mastercard Connect first [Inference]. The Europe Region rule on unattended POS terminals that applies in SCA countries extends to Albania, Montenegro, North Macedonia and Serbia on 2027-01-13 (Transaction Processing Rules, Europe Region rule 4.10, pp. 186 to 187).", "source_edition": "Mastercard Rules, 2 June 2026 edition (https://www.mastercard.com/content/dam/mccom/shared/business/support/rules-pdfs/mastercard-rules.pdf); Transaction Processing Rules, 9 June 2026 edition (https://www.mastercard.com/content/dam/mccom/shared/business/support/rules-pdfs/transaction-processing-rules.pdf)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.mastercard.com/content/dam/mccom/shared/business/support/rules-pdfs/mastercard-rules.pdf", "source_class": "authoritative_primary", "source_title": "Mastercard Rules, 2 June 2026 edition", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms that the cardholder liability protection yields to stronger or conflicting law, and that the issuer's 60 calendar day window to charge back a cardholder dispute is shortened or waived where law sets a shorter period or prohibits the chargeback." }, { "source_url": "https://www.mastercard.com/content/dam/mccom/shared/business/support/rules-pdfs/transaction-processing-rules.pdf", "source_class": "authoritative_primary", "source_title": "Transaction Processing Rules, 9 June 2026 edition", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms the refund rules that defer to law, including the temporary hold on refunded funds limited to what applicable law allows, the involuntary refund exception for airlines and similar merchants required by law, the Europe strong customer authentication soft decline and the refund right for authorized transactions in legislation, and the law based alternative authentication methods that must meet Mastercard Identity Check performance indicators." } ] }, "rail_name": "Mastercard", "governing_authority": "Mastercard", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "mastercard:decision-points", "id": "decision-points", "rail": "mastercard", "kind": "rail-fact", "facet": "decision-points", "name": "Where do Mastercard's rules leave a decision to a person or an institution?", "statement": "The rules leave several decisions open: the issuer decides each authorization on listed grounds, and whether to charge back in listed cases; the merchant decides whether to proceed with a transaction it suspects is fraud and how to retry a decline; the acquirer decides at each chargeback cycle whether to accept or contest; and Mastercard alone interprets its rules, rules on disputes, may depart from its processes in extraordinary events, and grants variances.", "details": [ { "label": "Issuer: each authorization", "value": "An issuer may approve or decline an individual transaction on grounds Mastercard lists: limits the cardholder set, fraud or credit risk seen in how the cardholder uses the card, whether funds or credit are there, cash restrictions on a secured or high-risk account, and anything else Mastercard permits. It must decide transaction by transaction, not by merchant or terminal country, acquirer country, transaction type or acceptance environment alone, and may not run a program that approves only at a subset of acceptance locations without Mastercard's written approval.", "citation": "Mastercard Rules, 2 June 2026, rule 6.4 (pp. 140 to 141)", "rests_on": "rule" }, { "label": "Issuer: whether to charge back", "value": "The issuer judges whether the cardholder supplied what its procedure requires and whether the cardholder is at fault or abusing the process, and need not charge back in those and the other listed cases.", "citation": "Mastercard Rules, 2 June 2026, rule 6.2.3 (p. 139)", "rests_on": "rule" }, { "label": "Merchant: suspected fraud", "value": "A merchant or acquirer that believes in good faith a card-not-present transaction is fraudulent has 72 hours from the request to decide not to proceed, but may not systematically decline by card, issuer or geography.", "citation": "Transaction Processing Rules, 9 June 2026, rule 2.11.3 (p. 61)", "rests_on": "rule" }, { "label": "Merchant: retries", "value": "A merchant builds its own resubmission strategy for merchant-initiated transactions from the decline code and the Merchant Advice Code, within the bars the rules set.", "citation": "Transaction Processing Rules, 9 June 2026, rule 3.3.1 (p. 124)", "rests_on": "rule" }, { "label": "Acquirer and issuer at each cycle", "value": "At second presentment, pre-arbitration and arbitration each side chooses to accept liability or contest, and either may accept at any point before Mastercard rules.", "citation": "Chargebacks Made Simple Guide, July 2025, sections 5.1 to 5.3 (pp. 8 to 10)", "rests_on": "guidance" }, { "label": "Mastercard", "value": "Mastercard alone interprets and enforces its Standards, may resolve disputes between customers with no appeal, may depart from its processes when it judges an event such as an account data compromise extraordinary, and decides variance requests submitted through Variance Manager. It may also decline Stand-In requests on a BIN where it detects fraud.", "citation": "Mastercard Rules, 2 June 2026, rules 2.1 and 2.1.1 (p. 58); Transaction Processing Rules, 9 June 2026, rule 2.2.2 (p. 47)", "rests_on": "rule" }, { "label": "DRM ruling", "value": "Mastercard's Dispute Resolution Management team decides liability in arbitration and compliance cases on the merits and the rules.", "citation": "Chargebacks Made Simple Guide, July 2025, sections 5.4 and 6.4 (pp. 11, 15)", "rests_on": "guidance" } ], "exceptions": [ "Europe Region: modifications apply to rule 6.4, not read [Unverified].", "EEA, UK and Gibraltar: several decisions described here run through the registered switch the customer chooses rather than Mastercard's systems (Transaction Processing Rules, Europe Region rules 2.7.1 and 2.11.3, pp. 92, 94)." ], "applies_to": "All Mastercard regions, with the variations listed", "caveat": "Orca's reading of where judgment sits; each line cites the rule that leaves the decision open.", "related": [ "mastercard:participants", "mastercard:return", "mastercard:liability", "mastercard:finality" ], "basis": { "sources": "Mastercard Rules (2 June 2026) rules 2.1, 2.1.1, 6.2.3, 6.4; Transaction Processing Rules (9 June 2026) rules 2.2.2, 2.11.3, 3.3.1; Chargebacks Made Simple Guide (July 2025) sections 5 and 6. Read from copies downloaded from Mastercard's public rules page on 2026-09-19. Nothing is quoted. Medium: this facet caps at medium.", "confidence": "medium" }, "currency": { "effective_since": "Before the current editions; start not stated in them", "effective_note": "Rules as stated in the Mastercard Rules of 2 June 2026, the Transaction Processing Rules of 9 June 2026, the Security Rules and Procedures Merchant Edition of 4 August 2026, the Quick Reference Booklet of 2 June 2026 and the Chargebacks Made Simple Guide of July 2025, as downloaded from Mastercard's public rules page on 2026-09-19. New editions drop past effective dates, so when a rule began is often not shown. Mastercard reissues its manuals on no fixed calendar and announces changes on Mastercard Connect first [Inference].", "source_edition": "Mastercard Rules, 2 June 2026 edition (https://www.mastercard.com/content/dam/mccom/shared/business/support/rules-pdfs/mastercard-rules.pdf); Transaction Processing Rules, 9 June 2026 edition (https://www.mastercard.com/content/dam/mccom/shared/business/support/rules-pdfs/transaction-processing-rules.pdf); Chargebacks Made Simple Guide, July 2025 (https://www.mastercard.com/content/dam/mccom/shared/business/support/rules-pdfs/chargebacks-made-simple-guide.pdf)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.mastercard.com/content/dam/mccom/shared/business/support/rules-pdfs/mastercard-rules.pdf", "source_class": "authoritative_primary", "source_title": "Mastercard Rules, 2 June 2026 edition", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms Mastercard's sole right to interpret and enforce its Standards, that its resolution of a dispute between customers is final and not subject to appeal, review or challenge, its discretion to deviate from its processes only in an extraordinary event, the variance request process, the issuer's listed grounds for an individual authorization decision and the bar on selective authorization by merchant or terminal country, and the issuer's listed grounds for not charging back a cardholder dispute." }, { "source_url": "https://www.mastercard.com/content/dam/mccom/shared/business/support/rules-pdfs/transaction-processing-rules.pdf", "source_class": "authoritative_primary", "source_title": "Transaction Processing Rules, 9 June 2026 edition", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms the 72 hour window for a merchant or acquirer to decide not to proceed with a card-not-present transaction it believes in good faith is fraudulent, and the bar on systematically declining by card, issuer or geography." }, { "source_url": "https://www.mastercard.com/content/dam/mccom/shared/business/support/rules-pdfs/chargebacks-made-simple-guide.pdf", "source_class": "public_primary", "source_title": "Chargebacks Made Simple Guide, July 2025", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms that only the issuer starts a chargeback, that the acquirer chooses to accept or contest at second presentment, pre-arbitration and arbitration, and that Mastercard's Dispute Resolution Management team rules on arbitration and compliance cases." } ] }, "rail_name": "Mastercard", "governing_authority": "Mastercard", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "mastercard:finality", "id": "finality", "rail": "mastercard", "kind": "rail-fact", "facet": "finality", "name": "When is a Mastercard card payment final, and what can still undo it?", "statement": "There is no single point of finality. An issuer's approval commits it to pay for the transaction once it is cleared, but an approval moves no money and it lapses once its protection period runs out. After clearing and settlement the issuer can still charge the transaction back where the Chargeback Guide gives it a right, and the case can go on through second presentment, pre-arbitration and arbitration to a ruling by Mastercard. Under the Mastercard Rules, Mastercard's resolution of a dispute between customers is final; its guide for merchants also describes a written request to reconsider a ruling within 45 calendar days.", "details": [ { "label": "The issuer must pay", "value": "Every customer has to honour and pay for the transactions other customers present on cards it has issued, and a sponsor stays liable for the cards of an affiliate it stops sponsoring.", "citation": "Mastercard Rules, 2 June 2026, rule 3.3 item 2 (p. 73)", "rests_on": "rule" }, { "label": "An approval lapses", "value": "For a Mastercard POS transaction, an approval protects against an authorization-related chargeback (message reason code 4808) for a fixed period counted from the approval date: 30 calendar days for a preauthorization, 7 for a final or deferred authorization, and 5 for an authorized refund. When the period ends the approved amount counts as zero and the issuer must have released any hold. A preauthorization for an installment plan financed by the acquirer or merchant has no time limit.", "citation": "Transaction Processing Rules, 9 June 2026, rules 2.8 (pp. 54 to 55) and 2.13.1 (p. 65)", "rests_on": "rule" }, { "label": "Chargeback after settlement", "value": "Only the issuer can start a chargeback. Mastercard moves the funds automatically when the issuer charges back and again when the acquirer rejects it by second presentment; the issuer can then accept or escalate. A ruling by Mastercard's Dispute Resolution Management team ends the process, with the amount and any fees adjusted through the Mastercard Consolidated Billing System.", "citation": "Chargebacks Made Simple Guide, July 2025, sections 3.1, 5.1, 5.4 (pp. 6, 8, 11)", "rests_on": "guidance" }, { "label": "Mastercard decides, and its decision stands", "value": "Mastercard may, but need not, settle a disagreement between customers, and the Mastercard Rules say its resolution cannot be appealed, reviewed or challenged. The Chargebacks Made Simple Guide separately describes an appeal: the customer found liable may ask Mastercard in writing to reconsider, and Mastercard must receive the request within 45 calendar days of the ruling [Inference: both can hold, since the appeal is a request to Mastercard itself].", "citation": "Mastercard Rules, 2 June 2026, rule 2.1 (p. 58); Chargebacks Made Simple Guide, July 2025, sections 5.6 and 6.6 (pp. 11, 15)", "rests_on": "rule" }, { "label": "Time limits for chargebacks are not public to Orca", "value": "The public guide lists the four chargeback categories but gives no codes or deadlines; it sends readers to the Chargeback Guide on Mastercard Connect, which Orca does not hold.", "citation": "Chargebacks Made Simple Guide, July 2025, sections 1.2 and 4 (pp. 3, 7)", "rests_on": "guidance" } ], "exceptions": [ "Europe Region: the authorization-related protection period for a preauthorization of a Maestro POS, ATM or manual cash transaction is 7 calendar days, not 30 (Transaction Processing Rules, Europe Region rule 2.8, p. 92).", "Maestro POS preauthorization: void if the issuer does not receive the completion within 20 minutes, with stated exceptions (Transaction Processing Rules rule 2.5.2 item 3, p. 51).", "EEA, UK and Gibraltar: many processing rules name the registered switch the customer chooses instead of Mastercard's Interchange System, so the messages that carry an approval, reversal or clearing may be that switch's (Transaction Processing Rules, Europe Region rules 2.7.1, 2.11 and 2.13, pp. 92 to 95)." ], "applies_to": "Mastercard, Maestro and Cirrus transactions in all Mastercard regions, with the regional variations listed", "caveat": "Do not tell a user a card payment is final at approval or at settlement. A chargeback can follow where the Chargeback Guide grants a right, and Orca does not hold those rights or their time limits.", "related": [ "mastercard:return", "mastercard:settlement", "mastercard:recall", "mastercard:decision-points" ], "basis": { "sources": "Mastercard Rules (2 June 2026) rules 2.1 and 3.3; Transaction Processing Rules (9 June 2026) rules 2.5.2, 2.8, 2.13.1 and Europe Region 2.7.1, 2.8, 2.11, 2.13; Chargebacks Made Simple Guide (July 2025) sections 1.2, 3.1, 4, 5.1, 5.4, 5.6, 6.6. All read from copies downloaded from Mastercard's public rules page on 2026-09-19. Nothing is quoted. Medium: the Chargeback Guide, which governs what happens after settlement, is not public to Orca.", "confidence": "medium" }, "currency": { "effective_since": "Before the current editions; start not stated in them", "effective_note": "Rules as stated in the Mastercard Rules of 2 June 2026, the Transaction Processing Rules of 9 June 2026, the Security Rules and Procedures Merchant Edition of 4 August 2026, the Quick Reference Booklet of 2 June 2026 and the Chargebacks Made Simple Guide of July 2025, as downloaded from Mastercard's public rules page on 2026-09-19. New editions drop past effective dates, so when a rule began is often not shown. Mastercard reissues its manuals on no fixed calendar and announces changes on Mastercard Connect first [Inference]. From 2026-10-23 an issuer must be ready to use the Transaction Link Identifier in a disputed merchant-initiated transaction to tie it to the earlier transaction when deciding chargeback liability (Transaction Processing Rules rule 2.18).", "source_edition": "Mastercard Rules, 2 June 2026 edition (https://www.mastercard.com/content/dam/mccom/shared/business/support/rules-pdfs/mastercard-rules.pdf); Transaction Processing Rules, 9 June 2026 edition (https://www.mastercard.com/content/dam/mccom/shared/business/support/rules-pdfs/transaction-processing-rules.pdf); Chargebacks Made Simple Guide, July 2025 (https://www.mastercard.com/content/dam/mccom/shared/business/support/rules-pdfs/chargebacks-made-simple-guide.pdf)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.mastercard.com/content/dam/mccom/shared/business/support/rules-pdfs/mastercard-rules.pdf", "source_class": "authoritative_primary", "source_title": "Mastercard Rules, 2 June 2026 edition", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms the duty of every customer to accept and pay for transactions on cards it issued, including continued liability for an affiliate's cards after sponsorship ends, and that Mastercard's resolution of a dispute between customers is final and not subject to appeal, review or challenge." }, { "source_url": "https://www.mastercard.com/content/dam/mccom/shared/business/support/rules-pdfs/transaction-processing-rules.pdf", "source_class": "authoritative_primary", "source_title": "Transaction Processing Rules, 9 June 2026 edition", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms the message reason code 4808 chargeback protection periods of 30 days for a preauthorization, 7 days for a final or deferred authorization and 5 days for an authorized refund, that the approved amount is deemed zero once the period expires, and the Europe Region variation setting the Maestro POS, ATM and manual cash preauthorization period at 7 days." }, { "source_url": "https://www.mastercard.com/content/dam/mccom/shared/business/support/rules-pdfs/chargebacks-made-simple-guide.pdf", "source_class": "public_primary", "source_title": "Chargebacks Made Simple Guide, July 2025", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms that Mastercard moves funds automatically at the first chargeback and again at second presentment, and describes a written appeal to Mastercard that must be received within 45 calendar days of a ruling decision." } ] }, "rail_name": "Mastercard", "governing_authority": "Mastercard", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "mastercard:hours", "id": "hours", "rail": "mastercard", "kind": "rail-fact", "facet": "hours", "name": "When can a Mastercard payment be authorized, and when does settlement run?", "statement": "Authorization is meant to run around the clock. Every customer keeps a 24-hour connection to the Interchange System and provides authorization for its cards and merchants, and when an issuer does not answer in time Mastercard's Stand-In Processing Service, or another provider the issuer has named, answers for it. Settlement follows a calendar: Mastercard's booklet lists holidays on which settlement cut-offs or money movements do not happen.", "details": [ { "label": "Always connected", "value": "Each customer must keep a working connection to the Interchange System 24 hours a day, directly or through a service provider, and a Principal or Affiliate Sponsoring Customer must provide authorization services for the cards it and its affiliates issue and for its merchants.", "citation": "Mastercard Rules, 2 June 2026, rules 3.3 item 3 and 3.4 (pp. 73 to 74)", "rests_on": "rule" }, { "label": "Time-outs go to Stand-In", "value": "Acquirers and issuers must meet the response timers in Mastercard's Dual Message and Single Message system guides, which are not public to Orca. If the issuer's answer does not arrive in time, the transaction goes to the Stand-In Processing System or the alternate provider the issuer has chosen.", "citation": "Transaction Processing Rules, 9 June 2026, rule 2.3 (pp. 48 to 49)", "rests_on": "rule" }, { "label": "Stand-In is required", "value": "Issuers must use the Stand-In Processing Service for all Mastercard card programs and for Maestro and Cirrus programs, the latter unless an alternative on-behalf service in use since before 1 December 2003 meets Mastercard's performance standards. The issuer is liable for everything Stand-In approves, and Stand-In parameters must be at or above Mastercard's default limits unless a regional floor allows lower.", "citation": "Transaction Processing Rules, 9 June 2026, rule 2.2.2 (pp. 46 to 47)", "rests_on": "rule" }, { "label": "Settlement calendar", "value": "No settlement cut-offs on 1 January or 25 December; no money moved in a regional settlement service on days the US Federal Reserve is closed; holiday dates for 2026 and 2027 are listed.", "citation": "Quick Reference Booklet, 2 June 2026, Holiday processing schedule (pp. 13 to 15)", "rests_on": "guidance" } ], "exceptions": [ "Europe Region: issuers follow the routing timer values in the Authorization Manual, which is not public to Orca (Transaction Processing Rules, Europe Region rule 2.3, p. 89).", "EEA, UK and Gibraltar: an issuer need use Mastercard's Stand-In only if its chosen registered switch requires it, but that switch must offer a back-up service that can approve on the issuer's behalf, set at or above Mastercard's default limits (Transaction Processing Rules, Europe Region rule 2.2.2, pp. 88 to 89).", "Maestro POS preauthorization: void if the completion does not reach the issuer within 20 minutes, with stated exceptions (Transaction Processing Rules rule 2.5.2 item 3, p. 51)." ], "applies_to": "All Mastercard regions for authorization; the settlement calendar shown is for US dollar settlement", "caveat": "A 24-hour authorization duty is not a guarantee of an answer from the issuer itself: a Stand-In answer is still binding on the issuer. Exact timers and settlement cut-off times are in documents Orca does not hold.", "related": [ "mastercard:settlement", "mastercard:limits", "mastercard:messages" ], "basis": { "sources": "Mastercard Rules (2 June 2026) rules 3.3, 3.4; Transaction Processing Rules (9 June 2026) rules 2.2.2, 2.3, 2.5.2, Europe Region 2.2.2 and 2.3; Quick Reference Booklet (2 June 2026) pp. 13 to 15. Read from copies downloaded from Mastercard's public rules page on 2026-09-19. Nothing is quoted. Medium: the timer values and cut-off times are not public to Orca.", "confidence": "medium" }, "currency": { "effective_since": "Before the current editions; start not stated in them", "effective_note": "Rules as stated in the Mastercard Rules of 2 June 2026, the Transaction Processing Rules of 9 June 2026, the Security Rules and Procedures Merchant Edition of 4 August 2026, the Quick Reference Booklet of 2 June 2026 and the Chargebacks Made Simple Guide of July 2025, as downloaded from Mastercard's public rules page on 2026-09-19. New editions drop past effective dates, so when a rule began is often not shown. Mastercard reissues its manuals on no fixed calendar and announces changes on Mastercard Connect first [Inference].", "source_edition": "Mastercard Rules, 2 June 2026 edition (https://www.mastercard.com/content/dam/mccom/shared/business/support/rules-pdfs/mastercard-rules.pdf); Transaction Processing Rules, 9 June 2026 edition (https://www.mastercard.com/content/dam/mccom/shared/business/support/rules-pdfs/transaction-processing-rules.pdf); Quick Reference Booklet, merchant download, 2 June 2026 edition (https://www.mastercard.com/content/dam/mccom/shared/business/support/rules-pdfs/mastercard-quick-reference-booklet-merchant.pdf)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.mastercard.com/content/dam/mccom/shared/business/support/rules-pdfs/mastercard-rules.pdf", "source_class": "authoritative_primary", "source_title": "Mastercard Rules, 2 June 2026 edition", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms the 24 hour per day connection to the Interchange System and the duty to provide authorization services for issued cards and merchants." }, { "source_url": "https://www.mastercard.com/content/dam/mccom/shared/business/support/rules-pdfs/transaction-processing-rules.pdf", "source_class": "authoritative_primary", "source_title": "Transaction Processing Rules, 9 June 2026 edition", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms that Stand-In Processing answers a transaction when an issuer's response does not arrive in time, and that Stand-In use is mandatory for Mastercard, Maestro and Cirrus programs subject to the pre-December-2003 alternative service exception." }, { "source_url": "https://www.mastercard.com/content/dam/mccom/shared/business/support/rules-pdfs/mastercard-quick-reference-booklet-merchant.pdf", "source_class": "authoritative_primary", "source_title": "Quick Reference Booklet, merchant download, 2 June 2026 edition", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms no settlement cutoffs on 1 January or 25 December, that no money moves in a Regional Settlement Service on days the US Federal Reserve is closed, and the listed 2026 and 2027 holiday dates." } ] }, "rail_name": "Mastercard", "governing_authority": "Mastercard", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "mastercard:liability", "id": "liability", "rail": "mastercard", "kind": "rail-fact", "facet": "liability", "name": "Who bears the loss on an unauthorized or disputed Mastercard payment?", "statement": "Cardholders who took reasonable care and reported loss or theft promptly are not liable for transactions they did not authorize, unless a stronger law sets otherwise; commercial cards other than small business cards and unregistered cards are outside that rule. Between the banks, the issuer bears what it or Stand-In approves, subject to chargeback rights set in the Chargeback Guide, and the merchant bears declines it accepts risk for, such as deferred authorizations. Mastercard monitors merchants with excessive chargebacks or fraud and can put terminated merchants on its MATCH list.", "details": [ { "label": "Cardholder protection", "value": "An issuer must not hold a cardholder liable for an unauthorized transaction if the cardholder guarded the card with reasonable care and reported its loss or theft promptly on learning of it. The rule excludes cards issued to non-persons or for business use (small business cards stay covered) and cards not yet registered to an identified holder, and yields to law that imposes greater liability or conflicts.", "citation": "Mastercard Rules, 2 June 2026, rule 6.3 (p. 140)", "rests_on": "rule" }, { "label": "Issuer bears Stand-In approvals", "value": "The issuer is liable for every transaction the Stand-In Processing Service approves, with or without PIN validation.", "citation": "Transaction Processing Rules, 9 June 2026, rule 2.2.2 (p. 46)", "rests_on": "rule" }, { "label": "Merchant bears deferred declines", "value": "A merchant that submits card-present authorizations on a deferred basis does so acknowledging it keeps the risk of loss if the issuer's decline cannot be recovered. A transit merchant is fully liable for declines for an expired card or a card that cannot do deferred authorization.", "citation": "Transaction Processing Rules, 9 June 2026, rules 2.7 (p. 53) and 4.5.5 (p. 165)", "rests_on": "rule" }, { "label": "E-commerce", "value": "For Maestro e-commerce the issuer bears fraud on transactions it approved unless the merchant or acquirer took part in the fraud or the merchant's site cannot pass UCAF data, and it keeps a chargeback right where UCAF carries Mastercard's static AAV. Mastercard Identity Check liability shifts for Mastercard cards are set in the Chargeback Guide.", "citation": "Transaction Processing Rules, 9 June 2026, rule 5.1.2 (p. 202)", "rests_on": "rule" }, { "label": "Chargeback monitoring", "value": "Under the Excessive Chargeback Program, a merchant's chargebacks in a month divided by its Mastercard transactions in the month before, times 10,000, gives its basis points; the thresholds are in the Data Integrity Monitoring Program manual, which Orca does not hold. Acquirers of flagged merchants must monitor them, and Mastercard pays issuer recovery fees to affected issuers, subject to a USD 20 minimum per issuer.", "citation": "Security Rules and Procedures, Merchant Edition, 4 August 2026, rules 8.3 to 8.3.3 (pp. 87 to 88)", "rests_on": "rule" }, { "label": "Questionable merchants and MATCH", "value": "The Questionable Merchant Audit Program lets issuers recover part of their fraud losses at a merchant Mastercard finds questionable. An acquirer may list a terminated merchant on MATCH for excessive chargebacks when, over the previous three months, its Mastercard chargebacks topped 1.5 percent of its Mastercard sales transactions in a month and reached at least USD 5,000.", "citation": "Security Rules and Procedures, Merchant Edition, 4 August 2026, rules 8.4 (p. 89) and 11.14.1, Table 11.4, reason code 04 (p. 157)", "rests_on": "rule" }, { "label": "Liability shifts are chargeback categories", "value": "Mastercard's summary lists a chip liability shift among the fraud chargeback sub-categories; its conditions are in the Chargeback Guide.", "citation": "Chargebacks Made Simple Guide, July 2025, section 4 (p. 7)", "rests_on": "guidance" } ], "exceptions": [ "Europe Region: the liability shift applies to EMV 3DS as it does to 3DS 1.0.2, with detail in the Chargeback Guide (Transaction Processing Rules, Europe Region rule 3.2, p. 144).", "Where applicable law sets greater cardholder liability or a conflicting duty, the law governs (Mastercard Rules rule 6.3).", "The Excessive Chargeback Program thresholds, the Identity Check liability shifts and the chargeback conditions are in documents not public to Orca." ], "applies_to": "All Mastercard regions; the cardholder rule covers consumer and small business cards", "caveat": "The cardholder rule is Mastercard's; national law (for example US Regulation E or Z) may give the cardholder more, and Orca has not read those laws. MATCH reason codes describe merchant terminations, not transaction outcomes.", "related": [ "mastercard:return", "mastercard:consumer-law", "mastercard:decision-points", "mastercard:finality", "mastercard-decline:54", "mastercard-decline:57" ], "basis": { "sources": "Mastercard Rules (2 June 2026) rule 6.3; Transaction Processing Rules (9 June 2026) rules 2.2.2, 2.7, 4.5.5, 5.1.2 and Europe Region 3.2; Security Rules and Procedures Merchant Edition (4 August 2026) rules 8.3, 8.4, 11.14.1; Chargebacks Made Simple Guide (July 2025) p. 7. Read from copies downloaded from Mastercard's public rules page on 2026-09-19. Nothing is quoted. Medium: thresholds and liability shift conditions are in documents Orca does not hold.", "confidence": "medium" }, "currency": { "effective_since": "Before the current editions; start not stated in them", "effective_note": "Rules as stated in the Mastercard Rules of 2 June 2026, the Transaction Processing Rules of 9 June 2026, the Security Rules and Procedures Merchant Edition of 4 August 2026, the Quick Reference Booklet of 2 June 2026 and the Chargebacks Made Simple Guide of July 2025, as downloaded from Mastercard's public rules page on 2026-09-19. New editions drop past effective dates, so when a rule began is often not shown. Mastercard reissues its manuals on no fixed calendar and announces changes on Mastercard Connect first [Inference].", "source_edition": "Mastercard Rules, 2 June 2026 edition (https://www.mastercard.com/content/dam/mccom/shared/business/support/rules-pdfs/mastercard-rules.pdf); Transaction Processing Rules, 9 June 2026 edition (https://www.mastercard.com/content/dam/mccom/shared/business/support/rules-pdfs/transaction-processing-rules.pdf); Security Rules and Procedures, Merchant Edition, 4 August 2026 edition (https://www.mastercard.com/content/dam/mccom/shared/business/support/rules-pdfs/SPME-Manual.pdf); Chargebacks Made Simple Guide, July 2025 (https://www.mastercard.com/content/dam/mccom/shared/business/support/rules-pdfs/chargebacks-made-simple-guide.pdf)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.mastercard.com/content/dam/mccom/shared/business/support/rules-pdfs/mastercard-rules.pdf", "source_class": "authoritative_primary", "source_title": "Mastercard Rules, 2 June 2026 edition", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms the cardholder liability protection for unauthorized transactions, its exclusions for non-consumer and unregistered cards, and that stronger or conflicting law governs instead." }, { "source_url": "https://www.mastercard.com/content/dam/mccom/shared/business/support/rules-pdfs/transaction-processing-rules.pdf", "source_class": "authoritative_primary", "source_title": "Transaction Processing Rules, 9 June 2026 edition", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms the issuer's liability for every transaction the Stand-In Processing Service approves." }, { "source_url": "https://www.mastercard.com/content/dam/mccom/shared/business/support/rules-pdfs/SPME-Manual.pdf", "source_class": "authoritative_primary", "source_title": "Security Rules and Procedures, Merchant Edition, 4 August 2026 edition", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms the Excessive Chargeback Program basis points formula, the USD 20 minimum threshold for issuer recovery payments, the Questionable Merchant Audit Program's partial fraud loss recovery for issuers, and the MATCH listing threshold of chargebacks exceeding 1.5 percent of a merchant's monthly Mastercard sales and totalling at least USD 5,000 over the previous three months." }, { "source_url": "https://www.mastercard.com/content/dam/mccom/shared/business/support/rules-pdfs/chargebacks-made-simple-guide.pdf", "source_class": "public_primary", "source_title": "Chargebacks Made Simple Guide, July 2025", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms the four chargeback categories and that a chip liability shift is listed as a fraud related sub-category." } ] }, "rail_name": "Mastercard", "governing_authority": "Mastercard", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "jurisdiction", "label": "the country", "needs": "which country the payment or the account is in", "detail": "The cardholder rule is Mastercard's; national law (for example US Regulation E or Z) may give the cardholder more, and Orca has not read those laws.", "from": "caveat" } ] }, { "uid": "mastercard:limits", "id": "limits", "rail": "mastercard", "kind": "rail-fact", "facet": "limits", "name": "What amount and usage limits apply to a Mastercard payment?", "statement": "No network-wide maximum amount was found in the texts read. The limits that exist are specific: merchants generally may not set a minimum or maximum amount (the US allows a credit-card minimum of up to USD 10 and a few maximums), issuers set their cardholders' limits but must keep Stand-In parameters above Mastercard's floors, credit card issuers must meet ATM approval standards, and gratuity, cash back and transit transactions carry their own caps.", "details": [ { "label": "No merchant minimum or maximum", "value": "A merchant may not require, or suggest it requires, a minimum or maximum amount to accept a valid Mastercard or Maestro card. In the US Region and US territories a merchant may set a minimum of up to USD 10 (or a higher figure the Federal Reserve sets by regulation) for Mastercard credit cards, and only US government bodies and merchants in MCCs 8220, 8244 and 8249 may set a maximum; neither may treat issuers or brands differently.", "citation": "Mastercard Rules, 2 June 2026, rule 5.12.3 (p. 123) and Additional U.S. Region and U.S. Territory Rules 5.12.3 (pp. 382 to 383)", "rests_on": "rule" }, { "label": "Stand-In floors", "value": "Stand-In parameters for Mastercard programs must be at or above Mastercard's global default limits unless the issuer's region or country allows a lower minimum; daily accumulative limits may be set higher than the defaults.", "citation": "Transaction Processing Rules, 9 June 2026, rule 2.2.2 (p. 47)", "rests_on": "rule" }, { "label": "ATM standards for credit card issuers", "value": "A Mastercard credit card issuer must approve at least 70 percent of ATM transactions and keep denial rates under a cap for each category: response 51 at 10 percent, 55 at 13 percent, 57 at 14 percent, 61 at 9 percent and 62 at 4 percent. It must let credit cardholders withdraw at least the equivalent of USD 200 a day when credit is available, and approve up to USD 10 or 10 percent (the larger) above the daily limit it told the cardholder.", "citation": "Transaction Processing Rules, 9 June 2026, rule 2.2.3 (p. 48)", "rests_on": "rule" }, { "label": "Gratuity tolerance", "value": "Where a tip may be added after authorization, it must not exceed 20 percent of the authorized amount unless an incremental authorization covers the excess on a preauthorization.", "citation": "Transaction Processing Rules, 9 June 2026, rule 3.3.1 (p. 123)", "rests_on": "rule" }, { "label": "Cash back", "value": "The maximum cash back must not exceed USD 100 or the local equivalent for Debit Mastercard, and for Maestro signature-verified and cross-border transactions; a merchant's own minimum and maximum must apply to all cardholders alike.", "citation": "Transaction Processing Rules, 9 June 2026, rule 4.9 (p. 168)", "rests_on": "rule" }, { "label": "No cap on some channels", "value": "There is no maximum amount for a contactless transaction at an ATM or for a consumer-presented QR transaction.", "citation": "Transaction Processing Rules, 9 June 2026, rules 4.6 and 4.8 (pp. 165, 167)", "rests_on": "rule" }, { "label": "Transit", "value": "A transit debt recovery transaction may not exceed the contactless transit aggregated CVM limit, and a first ride risk claim may not exceed the limit for the merchant's country, which Mastercard publishes; the figures were not read.", "citation": "Transaction Processing Rules, 9 June 2026, rules 4.5.4 and 4.5.5 (pp. 161 to 163); Quick Reference Booklet, 2 June 2026, p. 358", "rests_on": "rule" } ], "exceptions": [ "Latin America and the Caribbean Region: issuers may set Stand-In minimums below the default only as the region's table allows, USD 30 for listed card-not-present and debit transactions, from 2026-01-01 for most countries and from 2026-10-01 for Argentina, Bolivia, Brazil, Chile, Colombia, Ecuador, Guyana, Paraguay, Peru, Suriname and Uruguay (Transaction Processing Rules, Latin America and the Caribbean Region rule 2.2.2, p. 98).", "Europe Region: a table of lower Stand-In minimums applies by country, and in the EEA, UK and Gibraltar the ATM denial categories are replaced by the chosen switch's codes (Transaction Processing Rules, Europe Region rules 2.2.2 and 2.2.3, pp. 88 to 89).", "Australia: Debit Mastercard cash back up to AUD 500 (Transaction Processing Rules, Asia/Pacific Region rule 4.9, p. 176). United Kingdom: cash back without a purchase on Debit Mastercard, up to GBP 100 (Europe Region rule 4.9, p. 182).", "A search of the texts for a network-wide transaction maximum was not exhaustive [Unverified]." ], "applies_to": "All Mastercard regions, with the regional variations listed", "caveat": "An amount limit a cardholder meets usually comes from the issuer's own settings or the available balance, not from a published Mastercard rule. The US USD 10 minimum is permission for merchants, not a network floor.", "related": [ "mastercard:hours", "mastercard:decision-points", "mastercard-decline:51", "mastercard-decline:55", "mastercard-decline:57", "mastercard-decline:61", "mastercard-decline:62" ], "basis": { "sources": "Mastercard Rules (2 June 2026) rule 5.12.3 and Additional U.S. Region and U.S. Territory Rules 5.12.3; Transaction Processing Rules (9 June 2026) rules 2.2.2, 2.2.3, 3.3.1, 4.5.4, 4.5.5, 4.6, 4.8, 4.9 and regional rules 2.2.2, 2.2.3, 4.9; Quick Reference Booklet (2 June 2026) p. 358. Read from copies downloaded from Mastercard's public rules page on 2026-09-19. Nothing is quoted. Medium: the texts were not searched in full, and the CVM and first ride risk figures were not read.", "confidence": "medium" }, "currency": { "effective_since": "2026-06-09", "effective_note": "2026-06-09 is the date of the Transaction Processing Rules edition that states these limits, not the date each began; the edition removed past effective dates. The Mastercard Rules edition read is 2026-06-02. Latin America and the Caribbean Stand-In floors extend to eleven more countries on 2026-10-01.", "source_edition": "Mastercard Rules, 2 June 2026 edition (https://www.mastercard.com/content/dam/mccom/shared/business/support/rules-pdfs/mastercard-rules.pdf); Transaction Processing Rules, 9 June 2026 edition (https://www.mastercard.com/content/dam/mccom/shared/business/support/rules-pdfs/transaction-processing-rules.pdf); Quick Reference Booklet, merchant download, 2 June 2026 edition (https://www.mastercard.com/content/dam/mccom/shared/business/support/rules-pdfs/mastercard-quick-reference-booklet-merchant.pdf)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.mastercard.com/content/dam/mccom/shared/business/support/rules-pdfs/mastercard-rules.pdf", "source_class": "authoritative_primary", "source_title": "Mastercard Rules, 2 June 2026 edition", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms the bar on a merchant setting a minimum or maximum transaction amount, and the United States Region exception allowing a credit card minimum up to USD 10 or a higher Federal Reserve figure and a maximum only for government bodies and merchants in MCC 8220, 8244 or 8249." }, { "source_url": "https://www.mastercard.com/content/dam/mccom/shared/business/support/rules-pdfs/transaction-processing-rules.pdf", "source_class": "authoritative_primary", "source_title": "Transaction Processing Rules, 9 June 2026 edition", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms the Stand-In parameter floor rule, the ATM approval standards for Mastercard credit card issuers including the 70 percent minimum approval rate and the denial rate caps of 10 percent for response 51, 13 percent for 55, 14 percent for 57, 9 percent for 61 and 4 percent for 62, the 20 percent gratuity tolerance, and the Australia Debit Mastercard cash back cap of AUD 500." } ] }, "rail_name": "Mastercard", "governing_authority": "Mastercard", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "mastercard:messages", "id": "messages", "rail": "mastercard", "kind": "rail-fact", "facet": "messages", "name": "Which messages and fields carry a Mastercard payment and its outcome?", "statement": "Mastercard runs two message systems. In the Dual Message System authorization (0100 and 0110) and clearing (First Presentment 1240, through the Global Clearing Management System) are separate; in the Single Message System one financial message (0200 and 0210) does both. Reversals use 0400 and 0420, and advices 0220. The outcome of an authorization is in DE 39, the Merchant Advice Code in DE 48 subelement 84, a clearing or chargeback reason in DE 25, and the Transaction Link Identifier in DE 105. Disputes run in Mastercom.", "details": [ { "label": "Two systems", "value": "Dual Message: the issuer or Stand-In authorizes in one message and the acquirer clears in a second. Single Message: one message carries authorization and clearing.", "citation": "Chargebacks Made Simple Guide, July 2025, section 2.2 (p. 5)", "rests_on": "guidance" }, { "label": "Message types", "value": "Authorization Request 0100 and Response 0110; Financial Transaction Request 0200 and Response 0210; Financial Transaction Advice 0220; Reversal Request 0400 and Acquirer Reversal Advice 0420; First Presentment 1240; Fee Collection 1740.", "citation": "Transaction Processing Rules, 9 June 2026, rules 2.1 (p. 43), 2.11.1 (p. 59), 2.13.2 (p. 67) and 4.5.5 (pp. 163, 165)", "rests_on": "rule" }, { "label": "DE 39 response code", "value": "Carries the issuer's answer: 00 approves and 85 means not declined on an account status inquiry, 10 is a partial approval, and decline values such as 51 or 05. On a reversal since 1 July 2026 it says why (32 partial, 06 error, 17 cardholder cancellation), and 34 marks a merchant's cancellation for suspected fraud.", "citation": "Transaction Processing Rules, 9 June 2026, rules 2.2 (p. 45), 2.11.1 (p. 60), 2.11.3 (p. 61), 3.3.1 (p. 123) and 4.5.5 Table 23 (pp. 163 to 164)", "rests_on": "rule" }, { "label": "DE 48 subelement 84, Merchant Advice Code", "value": "Sent with a decline to guide retries: 01 new account data available, 02 try again later, 03 do not try again, 21 payment cancellation (Mastercard use only).", "citation": "Transaction Processing Rules, 9 June 2026, rule 3.3.1 Table 20 (p. 124)", "rests_on": "rule" }, { "label": "DE 25 message reason code", "value": "Carries clearing reasons such as 1403 and 1404 for partial multi-clearing and chargeback reasons such as 4808 for an authorization-related chargeback.", "citation": "Transaction Processing Rules, 9 June 2026, rules 2.8 (p. 54) and 2.10.1.1 (p. 57)", "rests_on": "rule" }, { "label": "DE 105 Transaction Link Identifier", "value": "Subelement 001 carries the TLID assigned at authorization, which acquirers echo in later lifecycle messages; subelement 002 links a later related transaction, such as a merchant-initiated one or a refund, to the original.", "citation": "Transaction Processing Rules, 9 June 2026, rules 2.1 (pp. 43 to 44), 2.10.1.1 (p. 58) and 2.13.1 (p. 66)", "rests_on": "rule" }, { "label": "Other identifying fields", "value": "DE 61 subfield 7 marks the authorization type (4 preauthorization, 1 deferred, 0 with a final authorization flag, 8 account status inquiry); DE 3 subfield 1 the transaction type (20 refund, 09 purchase with cash back, 30 balance inquiry).", "citation": "Transaction Processing Rules, 9 June 2026, rules 2.2 (p. 45), 2.5 (p. 50), 2.7 Table 3 (p. 52), 2.13 (p. 65), 2.14 (p. 67) and 4.9 (p. 167)", "rests_on": "rule" }, { "label": "Clearing and dispute systems", "value": "Dual Message customers clear through the Global Clearing Management System; chargebacks and compliance cases run in Mastercom on Mastercard Connect.", "citation": "Transaction Processing Rules, 9 June 2026, rules 2.18.1 and 2.18.2 (pp. 68 to 69)", "rests_on": "rule" }, { "label": "ISO 8583", "value": "The rules name ISO 8583 response codes once, in the Europe issuer failure-rate rule.", "citation": "Transaction Processing Rules, 9 June 2026, Europe Region rule 2.4.2 (p. 89)", "rests_on": "rule" } ], "exceptions": [ "EEA, UK and Gibraltar: many message types and fields are those defined by the registered switch the customer chooses, not Mastercard's (Transaction Processing Rules, Europe Region, for example rules 2.11, 2.13.1 and 5.1.2, pp. 93, 95, 227).", "Australia: from 2027-03-01 listed card-present transactions must follow the Real Time Clearing (Clear Now) specifications or the Single Message System (Transaction Processing Rules, Asia/Pacific Region rule 2.1, p. 71).", "The full field layouts and value lists are in the Customer Interface Specification and the Single Message System Specifications, which are not public to Orca." ], "applies_to": "Transactions processed on Mastercard's network, all regions, with the variations listed", "caveat": "A DE 39 decline and a DE 25 chargeback reason are different things in different messages; do not map one to the other.", "related": [ "mastercard:settlement", "mastercard:recall", "mastercard:refund", "mastercard:return", "mastercard-decline:05", "mastercard-decline:51" ], "basis": { "sources": "Transaction Processing Rules (9 June 2026) rules 2.1, 2.2, 2.5, 2.7, 2.8, 2.10.1.1, 2.11.1, 2.11.3, 2.13, 2.13.1, 2.13.2, 2.14, 2.18.1, 2.18.2, 3.3.1, 4.5.5, 4.9 and regional rules cited; Chargebacks Made Simple Guide (July 2025) p. 5. Read from copies downloaded from Mastercard's public rules page on 2026-09-19. Nothing is quoted.", "confidence": "high" }, "currency": { "effective_since": "Before the current editions; start not stated in them", "effective_note": "Rules as stated in the Mastercard Rules of 2 June 2026, the Transaction Processing Rules of 9 June 2026, the Security Rules and Procedures Merchant Edition of 4 August 2026, the Quick Reference Booklet of 2 June 2026 and the Chargebacks Made Simple Guide of July 2025, as downloaded from Mastercard's public rules page on 2026-09-19. New editions drop past effective dates, so when a rule began is often not shown. Mastercard reissues its manuals on no fixed calendar and announces changes on Mastercard Connect first [Inference]. From 2026-10-23 acquirers must send the original TLID in DE 105 subelement 002 on related merchant-initiated transactions (Transaction Processing Rules rule 2.1).", "source_edition": "Transaction Processing Rules, 9 June 2026 edition (https://www.mastercard.com/content/dam/mccom/shared/business/support/rules-pdfs/transaction-processing-rules.pdf); Chargebacks Made Simple Guide, July 2025 (https://www.mastercard.com/content/dam/mccom/shared/business/support/rules-pdfs/chargebacks-made-simple-guide.pdf)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.mastercard.com/content/dam/mccom/shared/business/support/rules-pdfs/transaction-processing-rules.pdf", "source_class": "authoritative_primary", "source_title": "Transaction Processing Rules, 9 June 2026 edition", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms the authorization, financial, advice, reversal and clearing message types, that DE 39 carries the response code, that DE 48 subelement 84 carries the Merchant Advice Code with values 01, 02, 03 and 21, and that the Europe issuer failure rate rule is the only place the Rules name ISO 8583 response codes, there giving 31, 82 and 96 different meanings than their Table 23 labels." }, { "source_url": "https://www.mastercard.com/content/dam/mccom/shared/business/support/rules-pdfs/chargebacks-made-simple-guide.pdf", "source_class": "public_primary", "source_title": "Chargebacks Made Simple Guide, July 2025", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms the Dual Message System and Single Message System distinction." } ] }, "rail_name": "Mastercard", "governing_authority": "Mastercard", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "mastercard:participants", "id": "participants", "rail": "mastercard", "kind": "rail-fact", "facet": "participants", "name": "Who takes part in the Mastercard network, and in what roles?", "statement": "Mastercard licenses Customers, mostly regulated financial institutions, to issue cards and acquire transactions for Mastercard, Maestro and Cirrus, directly or by sponsoring others. Around them sit registered Service Providers, Network Enablement Partners, and Digital Activity customers such as digital wallet operators, token requestors and checkout facilitators. For push payments the rules rename the roles: the issuer is the Receiving Institution and the acquirer the Originating Institution.", "details": [ { "label": "Principal and Affiliate", "value": "A financial institution or other entity authorized under its home law to make loans, take deposits, issue prepaid or e-money or execute payments may apply; financial institutions must be supervised. Mastercard admits at its sole discretion.", "citation": "Mastercard Rules, 2 June 2026, rule 1.1.1 (p. 34)", "rests_on": "rule" }, { "label": "Association, Affiliate Sponsoring Customer, BIN Sponsor", "value": "An Association is an entity controlled by eligible institutions acting for them. An Affiliate Sponsoring Customer sponsors affiliates' activity without issuing or acquiring itself. A Principal or sponsor that sponsors affiliates or runs co-brand or program-manager programs is a BIN Sponsor, and from 20 May 2025 needs Mastercard's approval to sponsor a Sponsored Program Manager.", "citation": "Mastercard Rules, 2 June 2026, rules 1.1.2 to 1.1.4 (pp. 34 to 35)", "rests_on": "rule" }, { "label": "Payment Transfer Activity Customer", "value": "An entity Mastercard approves for a Payment Transfer Activity program, under a separate agreement per program and security, legal and rule criteria. In these programs the Originating Institution sends and the Receiving Customer receives.", "citation": "Mastercard Rules, 2 June 2026, rule 1.1.6 (p. 36) and Applicability of Rules (p. 31); Transaction Processing Rules, 9 June 2026, Applicability of Rules (p. 25)", "rests_on": "rule" }, { "label": "Service Providers and Network Enablement Partners", "value": "Customers register Service Providers for defined program services, among them 3-D Secure service providers, AML and sanctions providers, Payment Facilitators with Sponsored Merchants, and Third Party Processors. Network Enablement Partners are a separate class with their own agreement and eligibility.", "citation": "Mastercard Rules, 2 June 2026, rule 7.1 (pp. 155 to 156) and chapter 7 contents (7.8 to 7.11)", "rests_on": "rule" }, { "label": "Digital Activity", "value": "Staged digital wallet operators, pass-through digital wallets (device wallets and commerce platforms), merchant and on-behalf token requestors, and checkout facilitators are governed as Digital Activity. The 2 June 2026 edition added new Digital Activity customer types. Pass-through wallets and checkout facilitators must follow the standards of each program they join, and the rules give the Mastercard Agent Pay Program Standards as an example.", "citation": "Mastercard Rules, 2 June 2026, summary of changes (p. 26), chapter 9 contents (pp. 10 to 11), rules 9.1, 9.2, 9.2.4 item 4, 9.5 and 9.5.1 item 5 (pp. 213 to 218, 223 to 224)", "rests_on": "rule" }, { "label": "Brands", "value": "The rules cover three card brands, Mastercard, Maestro and Cirrus; a rule that names no brand applies to all three. A Debit Mastercard card issued outside China on a BIN routed to the Single Message System follows the Maestro POS rules.", "citation": "Mastercard Rules, 2 June 2026, Applicability of Rules (p. 30); Transaction Processing Rules, 9 June 2026, Applicability of Rules (p. 25)", "rests_on": "rule" } ], "exceptions": [ "Europe Region: modifications apply to rules 1.1.2 and 1.1.3, not read [Unverified].", "Mainland China: the POS transaction rules apply to all domestic transactions (Mastercard Rules, Applicability of Rules, p. 30).", "The Agent Pay Program Standards themselves are not among the public documents read." ], "applies_to": "All Mastercard regions", "caveat": "Merchants and cardholders are not Customers; they reach the network through acquirers and issuers. Chapter 7 roles are described from their titles and the opening of rule 7.1 only.", "related": [ "mastercard:decision-points", "mastercard:liability", "mastercard:settlement" ], "basis": { "sources": "Mastercard Rules (2 June 2026) applicability pages, summary of changes, rules 1.1.1 to 1.1.6, 7.1, chapter 7 contents, 9.1, 9.2, 9.2.4, 9.5, 9.5.1; Transaction Processing Rules (9 June 2026) applicability page. Read from copies downloaded from Mastercard's public rules page on 2026-09-19. Nothing is quoted. Medium: chapter 7 was read only in part.", "confidence": "medium" }, "currency": { "effective_since": "Before the current editions; start not stated in them", "effective_note": "Rules as stated in the Mastercard Rules of 2 June 2026, the Transaction Processing Rules of 9 June 2026, the Security Rules and Procedures Merchant Edition of 4 August 2026, the Quick Reference Booklet of 2 June 2026 and the Chargebacks Made Simple Guide of July 2025, as downloaded from Mastercard's public rules page on 2026-09-19. New editions drop past effective dates, so when a rule began is often not shown. Mastercard reissues its manuals on no fixed calendar and announces changes on Mastercard Connect first [Inference]. The BIN Sponsor approval requirement applies to Sponsored Program Manager registrations from 2025-05-20.", "source_edition": "Mastercard Rules, 2 June 2026 edition (https://www.mastercard.com/content/dam/mccom/shared/business/support/rules-pdfs/mastercard-rules.pdf); Transaction Processing Rules, 9 June 2026 edition (https://www.mastercard.com/content/dam/mccom/shared/business/support/rules-pdfs/transaction-processing-rules.pdf)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.mastercard.com/content/dam/mccom/shared/business/support/rules-pdfs/mastercard-rules.pdf", "source_class": "authoritative_primary", "source_title": "Mastercard Rules, 2 June 2026 edition", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms the Principal, Affiliate, Association, Affiliate Sponsoring Customer, BIN Sponsor and Payment Transfer Activity Customer roles, the three card brands, and that the Mastercard Agent Pay Program Standards are named as an example of the program standards a pass-through wallet or checkout facilitator must follow, in rules 9.2.4 item 4 and 9.5.1 item 5." } ] }, "rail_name": "Mastercard", "governing_authority": "Mastercard", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "mastercard:recall", "id": "recall", "rail": "mastercard", "kind": "rail-fact", "facet": "recall", "name": "Can a Mastercard payment be cancelled or recalled after it is sent?", "statement": "Before clearing, the merchant side cancels by reversing the authorization, and must do so within 24 hours in the cases the rules list. After clearing no party can call a card payment back: the merchant returns money by a refund, a refund itself can be reversed only for a clerical error within one calendar day, and otherwise the cardholder's route is a dispute through the issuer [Inference: the texts read describe no recall of a cleared purchase].", "details": [ { "label": "Reversal within 24 hours", "value": "The acquirer must see that a merchant sends a reversal within 24 hours when a sale is voided or paid another way, when the final amount is lower than approved (unless it clears within 24 hours), and, from 1 July 2026, when the authorization request is found to have been sent in error. Since 1 July 2026 the reversal carries DE 39 value 32 for a partial reversal, 06 for an erroneous request and 17 for a cardholder cancellation. Automated fuel dispensers and contactless transit are exempt.", "citation": "Transaction Processing Rules, 9 June 2026, rule 2.11.1 (pp. 59 to 60)", "rests_on": "rule" }, { "label": "Hold released within an hour", "value": "An issuer that receives a reversal must release the hold in the stated amount within 60 minutes of matching it to the authorization.", "citation": "Transaction Processing Rules, 9 June 2026, rule 2.11.2 (pp. 60 to 61)", "rests_on": "rule" }, { "label": "Turning an approval into a decline for fraud", "value": "For a card-not-present transaction the merchant or acquirer believes in good faith to be fraudulent, it has 72 hours from the authorization request to decide not to proceed; it then reverses the full amount with DE 39 value 34 and gives the cardholder a contact for questions.", "citation": "Transaction Processing Rules, 9 June 2026, rule 2.11.3 (p. 61)", "rests_on": "rule" }, { "label": "Cancel before completion", "value": "A single message POS transaction can be cancelled before completion with the terminal's cancel or stop key; the terminal also times out and reverses if no answer comes.", "citation": "Transaction Processing Rules, 9 June 2026, rule 2.11.4 (p. 62)", "rests_on": "rule" }, { "label": "Refunds are nearly irreversible", "value": "A refund may be reversed, or adjusted downward, only to correct a documented clerical error such as wrong data, a duplicate or transposed figures, with the issuer's agreement, and no later than one calendar day after the refund was sent.", "citation": "Transaction Processing Rules, 9 June 2026, rules 2.11.1 (p. 60) and 2.13 (p. 65)", "rests_on": "rule" }, { "label": "Correcting errors between customers", "value": "A customer unjustly enriched by an error must repay the customer that lost by it.", "citation": "Transaction Processing Rules, 9 June 2026, rule 2.20 (p. 69)", "rests_on": "rule" }, { "label": "ATM cash not taken", "value": "An acquirer must not automatically reverse an ATM withdrawal because the cardholder left some or all of the cash behind.", "citation": "Transaction Processing Rules, 9 June 2026, rule 2.11.1 (p. 60)", "rests_on": "rule" } ], "exceptions": [ "Europe Region: the reversal duty covers cancellation and a lower final amount within 24 hours, and the text read does not list the erroneous-request case (Transaction Processing Rules, Europe Region rule 2.11.1, p. 93).", "EEA, UK and Gibraltar: reversal messages and fields are those of the registered switch the customer chooses (Transaction Processing Rules, Europe Region rules 2.11 and 2.11.3, pp. 93 to 94).", "Italy: issuers must support full and partial reversals on all prepaid Mastercard and prepaid Debit Mastercard ranges (Transaction Processing Rules, Europe Region rule 2.11.2, p. 94)." ], "applies_to": "Mastercard, Maestro and Cirrus transactions in all regions, with the variations listed", "caveat": "A reversal before clearing releases a hold; it is not a refund. After clearing, send a user to the refund or the issuer's dispute process, not to a recall.", "related": [ "mastercard:refund", "mastercard:return", "mastercard:finality", "mastercard:messages" ], "basis": { "sources": "Transaction Processing Rules (9 June 2026) rules 2.11, 2.11.1 to 2.11.4, 2.13, 2.20 and Europe Region 2.11, 2.11.1 to 2.11.3. Read from a copy downloaded from Mastercard's public rules page on 2026-09-19. Nothing is quoted. Medium: each line follows from a cited rule, but the statement that no recall of a cleared purchase exists is an absence in the texts read.", "confidence": "medium" }, "currency": { "effective_since": "Before the current editions; start not stated in them", "effective_note": "Rules as stated in the Mastercard Rules of 2 June 2026, the Transaction Processing Rules of 9 June 2026, the Security Rules and Procedures Merchant Edition of 4 August 2026, the Quick Reference Booklet of 2 June 2026 and the Chargebacks Made Simple Guide of July 2025, as downloaded from Mastercard's public rules page on 2026-09-19. New editions drop past effective dates, so when a rule began is often not shown. Mastercard reissues its manuals on no fixed calendar and announces changes on Mastercard Connect first [Inference]. The reversal values 06, 17 and 32 and the erroneous-request reversal duty took effect 2026-07-01.", "source_edition": "Transaction Processing Rules, 9 June 2026 edition (https://www.mastercard.com/content/dam/mccom/shared/business/support/rules-pdfs/transaction-processing-rules.pdf)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.mastercard.com/content/dam/mccom/shared/business/support/rules-pdfs/transaction-processing-rules.pdf", "source_class": "authoritative_primary", "source_title": "Transaction Processing Rules, 9 June 2026 edition", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms the merchant reversal within 24 hours of a void, an error effective 1 July 2026, or a finalization at a lower amount, using response values 06, 17 or 32, the issuer's 60 minute window to release a hold after matching a reversal, and the 72 hour window and response value 34 for a merchant's fraud cancellation." } ] }, "rail_name": "Mastercard", "governing_authority": "Mastercard", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "mastercard:refund", "id": "refund", "rail": "mastercard", "kind": "rail-fact", "facet": "refund", "name": "How does a merchant refund a Mastercard payment, and what must the issuer do with it?", "statement": "A merchant must take back goods or cancel services unless it disclosed otherwise at the sale, and it refunds by crediting the same card account, in the purchase currency and for no more than the purchase amount, with narrow exceptions. Refunds are authorized online in every region now, the merchant sends the refund record within 15 days to avoid a Credit Not Processed chargeback, and the acquirer presents it within 5 days. The issuer must be able to answer a refund authorization, may not decline it on some grounds, and posts the funds within one day of clearing.", "details": [ { "label": "Returns are accepted by default", "value": "Unless the merchant disclosed otherwise at the time of sale, it must accept returns and cancellations. A price adjustment or return on a Mastercard card is made only as a credit to the account used for the purchase (or a card the same issuer reissued to the same holder). Where law forces an involuntary refund, the card is unavailable or the refund authorization is declined, the merchant follows its own policy, which may mean cash, cheque or a prepaid card.", "citation": "Transaction Processing Rules, 9 June 2026, rule 3.14 (p. 139)", "rests_on": "rule" }, { "label": "What a refund may be", "value": "A refund only returns money for goods returned, services cancelled or a price adjustment on an earlier purchase. It is in the purchase currency and does not exceed the purchase amount, except for currency movements or return shipping the merchant agrees to cover. It must not pay out gambling winnings or crypto or securities proceeds, though returning unspent funds within 90 days or refunding a fraud claim is allowed.", "citation": "Transaction Processing Rules, 9 June 2026, rule 3.14.1 (p. 140)", "rests_on": "rule" }, { "label": "Deadlines on the merchant side", "value": "The merchant sends the refund record to its acquirer within 15 days of the refund receipt date, to avoid a Credit Not Processed chargeback, and the acquirer presents a refund within 5 calendar days of its date (or of its authorization).", "citation": "Transaction Processing Rules, 9 June 2026, rules 3.15 item 2 and 3.15.1 (pp. 141 to 142)", "rests_on": "rule" }, { "label": "Online refund authorization", "value": "Acquirers must support online authorization of dual message refunds and send each request at the time of the refund. It became mandatory on 18 October 2024 in Asia/Pacific (India domestic excepted), Europe, Latin America and the Caribbean (Brazil excepted) and Middle East/Africa, on 9 January 2025 in Brazil, and on 1 October 2025 in Canada and the US. An authorized refund carries a 5-day authorization-related protection period.", "citation": "Transaction Processing Rules, 9 June 2026, rule 2.13.1 (pp. 65 to 66)", "rests_on": "rule" }, { "label": "What the issuer may answer", "value": "Except for non-reloadable prepaid cards, an issuer must be able to receive and answer a refund authorization, and should approve it when the account is open. It must not answer with 10, 12 or 51, may use 57 only for a non-reloadable prepaid program (Mastercard advises registering the program as such first), and must not decline only because of a format error or missing PIN or chip data.", "citation": "Transaction Processing Rules, 9 June 2026, rule 2.13.2 (pp. 66 to 67); rule 2.2 (p. 45)", "rests_on": "rule" }, { "label": "Posting and display", "value": "Within one day of receiving the refund's clearing message the issuer posts the funds or adjusts open-to-buy, with a temporary hold allowed where law permits and the case warrants. Pending refunds must be visible to the cardholder in at least one channel.", "citation": "Transaction Processing Rules, 9 June 2026, rule 2.13.2 (p. 67)", "rests_on": "rule" }, { "label": "Fast refund", "value": "With Mastercard's approval a merchant may also offer a fast refund as a MoneySend Payment Transaction, to the original account or another, but must keep offering the ordinary refund.", "citation": "Transaction Processing Rules, 9 June 2026, rule 3.14 (p. 139)", "rests_on": "rule" } ], "exceptions": [ "India domestic transactions are outside the online refund authorization mandate (Transaction Processing Rules rule 2.13.1, p. 66).", "Contactless transit aggregated refunds are outside the acquirer's online refund authorization duty (Transaction Processing Rules rule 2.13.1, p. 65).", "Europe Region, Middle East/Africa Region and the US Region modify rules 3.14 and 3.14.1; those modifications were not read [Unverified]. In the EEA, UK and Gibraltar refund messages are those of the chosen registered switch (Europe Region rules 2.13.1 and 2.13.2, p. 95).", "A Maestro card-present refund may not be key-entered (Transaction Processing Rules rule 3.14.1, p. 140)." ], "applies_to": "Mastercard, Maestro and Debit Mastercard refunds in all regions, with the variations listed", "caveat": "A refund is a new credit transaction, not the reversal of the purchase, and the issuer may hold refunded funds briefly where law allows. The 15-day and 5-day limits bind the merchant and acquirer; they are not a promise of when the cardholder sees the money.", "related": [ "mastercard:recall", "mastercard:return", "mastercard:consumer-law", "mastercard:messages", "mastercard-decline:12", "mastercard-decline:51", "mastercard-decline:57" ], "basis": { "sources": "Transaction Processing Rules (9 June 2026) rules 2.2, 2.13, 2.13.1, 2.13.2, 3.14, 3.14.1, 3.15, 3.15.1 and Europe Region 2.13.1, 2.13.2. Read from a copy downloaded from Mastercard's public rules page on 2026-09-19. Nothing is quoted.", "confidence": "high" }, "currency": { "effective_since": "Before the current editions; start not stated in them", "effective_note": "Rules as stated in the Mastercard Rules of 2 June 2026, the Transaction Processing Rules of 9 June 2026, the Security Rules and Procedures Merchant Edition of 4 August 2026, the Quick Reference Booklet of 2 June 2026 and the Chargebacks Made Simple Guide of July 2025, as downloaded from Mastercard's public rules page on 2026-09-19. New editions drop past effective dates, so when a rule began is often not shown. Mastercard reissues its manuals on no fixed calendar and announces changes on Mastercard Connect first [Inference]. The last regional online refund authorization dates (Canada and US) were 2025-10-01.", "source_edition": "Transaction Processing Rules, 9 June 2026 edition (https://www.mastercard.com/content/dam/mccom/shared/business/support/rules-pdfs/transaction-processing-rules.pdf)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.mastercard.com/content/dam/mccom/shared/business/support/rules-pdfs/transaction-processing-rules.pdf", "source_class": "authoritative_primary", "source_title": "Transaction Processing Rules, 9 June 2026 edition", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms the merchant's duty to accept returns unless disclosed otherwise at the sale, the same account credit requirement, the refund amount and currency limits with the shipping cost and currency fluctuation exceptions, the five day clearing submission window, and the issuer rules barring response values 10, 12 and 51 and allowing 57 only for a non-reloadable prepaid program." } ] }, "rail_name": "Mastercard", "governing_authority": "Mastercard", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "mastercard:return", "id": "return", "rail": "mastercard", "kind": "rail-fact", "facet": "return", "name": "Can a Mastercard payment be sent back, and how does a chargeback work?", "statement": "On a card network the return is the chargeback, and only the issuer can start one. An issuer must charge back within 60 calendar days of a cardholder's dispute when a right exists and it has not settled the matter otherwise. Funds move automatically at each chargeback cycle, and unresolved cases go to pre-arbitration, arbitration and a Mastercard ruling. Where no chargeback right exists, either side may bring a compliance case for a rule breach that caused a loss. The chargeback reason codes, their conditions and their time frames are in the Chargeback Guide, which Orca does not hold.", "details": [ { "label": "Only the issuer starts it", "value": "A chargeback is Mastercard's rules-based way for issuer and acquirer to settle who bears a disputed transaction, and only the issuer can open one.", "citation": "Chargebacks Made Simple Guide, July 2025, section 3.1 (p. 6)", "rests_on": "guidance" }, { "label": "The issuer's duty to act", "value": "Each issuer must have a dispute procedure and tell cardholders about it. Within 60 calendar days of a cardholder's dispute, or less if law requires, an issuer that has not otherwise resolved it must charge back where a right exists and the requirements can be met. No chargeback is owed where law forbids one, where Mastercard permits a further exception, where the issuer finds the cardholder responsible, fraudulent or abusing the process or missing the explanations and documents its procedure requires, or where the cardholder has already been made whole, whether by a statement credit or through Mastercom Collaboration, Ethoca or a similar route. The duty does not cover commercial cards (small business cards excepted) or cards whose holder has not been registered.", "citation": "Mastercard Rules, 2 June 2026, rule 6.2.3 (pp. 139 to 140)", "rests_on": "rule" }, { "label": "Cycles and money movement", "value": "The first chargeback credits the issuer and debits the acquirer automatically. The acquirer may accept or reject it by second presentment, which moves the money back. The issuer may then accept or escalate: to pre-arbitration where that step is required, where an acquirer that does nothing for 30 calendar days is treated as accepting, and then to arbitration. Either side may accept liability at any time before Mastercard rules.", "citation": "Chargebacks Made Simple Guide, July 2025, sections 5.1 to 5.3 (pp. 8 to 10)", "rests_on": "guidance" }, { "label": "Ruling and appeal", "value": "Mastercard's Dispute Resolution Management team may rule on an arbitration case on the merits and the rules, and posts the amount, filing fees and any technical violation fees through the Mastercard Consolidated Billing System. The customer found liable may ask for reconsideration in writing within 45 calendar days of the ruling.", "citation": "Chargebacks Made Simple Guide, July 2025, sections 5.4 to 5.6 (p. 11)", "rests_on": "guidance" }, { "label": "Compliance cases", "value": "Where no chargeback exists for the dispute, an issuer or an acquirer that has a documented loss from a rule breach may file. A pre-compliance case left unanswered for 30 calendar days is rejected automatically; a compliance case must be answered within 10 calendar days, after which Mastercard can rule. A compliance case is not allowed where chargeback and arbitration are available or prohibited, among other bars.", "citation": "Chargebacks Made Simple Guide, July 2025, sections 3.2 and 6.1 to 6.6 (pp. 6, 12 to 15)", "rests_on": "guidance" }, { "label": "Four categories", "value": "Mastercard groups chargebacks as fraud, authorization, point-of-interaction error and cardholder dispute, each with sub-categories that carry their own conditions, time frames and documents. The individual reason codes differ between the Dual and Single Message Systems.", "citation": "Chargebacks Made Simple Guide, July 2025, section 4 (p. 7)", "rests_on": "guidance" }, { "label": "Good faith and tools", "value": "Every chargeback and compliance cycle must be brought in good faith after reviewing the Standards and the facts, and it needs Mastercom access on Mastercard Connect. A reissued card with the same account number must carry its expiry date in chargeback records.", "citation": "Transaction Processing Rules, 9 June 2026, rules 2.18.2 and 2.19 (p. 69)", "rests_on": "rule" } ], "exceptions": [ "Commercial cards (other than small business cards) and cards sold before the holder is registered fall outside the issuer's 60-day duty (Mastercard Rules rule 6.2.3, pp. 139 to 140).", "Chargeback rights, reason codes and time frames differ by message system and region; they are in the Chargeback Guide, which is not public to Orca.", "From 2026-10-23 an issuer must be ready to use the Transaction Link Identifier to tie a disputed merchant-initiated transaction to its earlier transaction when deciding liability (Transaction Processing Rules rule 2.18, p. 68)." ], "applies_to": "Mastercard, Maestro and Cirrus transactions in all regions; the chargeback detail is Mastercard's summary for customers", "caveat": "Do not state chargeback deadlines such as a number of days from the transaction: none is in the public documents read. A decline is not a chargeback; the decline codes in mastercard-decline arise before any money moves.", "related": [ "mastercard:finality", "mastercard:refund", "mastercard:liability", "mastercard:decision-points", "mastercard:messages" ], "basis": { "sources": "Mastercard Rules (2 June 2026) rule 6.2.3; Transaction Processing Rules (9 June 2026) rules 2.18, 2.18.2, 2.19; Chargebacks Made Simple Guide (July 2025) sections 3 to 6. Read from copies downloaded from Mastercard's public rules page on 2026-09-19. Nothing is quoted. Medium: the Chargeback Guide is not public to Orca, and the guide yields to it on conflict.", "confidence": "medium" }, "currency": { "effective_since": "Before the current editions; start not stated in them", "effective_note": "Rules as stated in the Mastercard Rules of 2 June 2026, the Transaction Processing Rules of 9 June 2026, the Security Rules and Procedures Merchant Edition of 4 August 2026, the Quick Reference Booklet of 2 June 2026 and the Chargebacks Made Simple Guide of July 2025, as downloaded from Mastercard's public rules page on 2026-09-19. New editions drop past effective dates, so when a rule began is often not shown. Mastercard reissues its manuals on no fixed calendar and announces changes on Mastercard Connect first [Inference]. The Transaction Link Identifier duty for disputed merchant-initiated transactions takes effect 2026-10-23.", "source_edition": "Mastercard Rules, 2 June 2026 edition (https://www.mastercard.com/content/dam/mccom/shared/business/support/rules-pdfs/mastercard-rules.pdf); Transaction Processing Rules, 9 June 2026 edition (https://www.mastercard.com/content/dam/mccom/shared/business/support/rules-pdfs/transaction-processing-rules.pdf); Chargebacks Made Simple Guide, July 2025 (https://www.mastercard.com/content/dam/mccom/shared/business/support/rules-pdfs/chargebacks-made-simple-guide.pdf)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.mastercard.com/content/dam/mccom/shared/business/support/rules-pdfs/mastercard-rules.pdf", "source_class": "authoritative_primary", "source_title": "Mastercard Rules, 2 June 2026 edition", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms the issuer's 60 calendar day window to charge back after a cardholder dispute when a right exists and the dispute is not otherwise resolved, shortened or waived as law requires." }, { "source_url": "https://www.mastercard.com/content/dam/mccom/shared/business/support/rules-pdfs/chargebacks-made-simple-guide.pdf", "source_class": "public_primary", "source_title": "Chargebacks Made Simple Guide, July 2025", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms the four chargeback categories, that funds move automatically at the first chargeback and at second presentment, that an acquirer's inaction on a pre-arbitration case for 30 calendar days loses it, and the pre-compliance 30 day and compliance 10 day case response windows." } ] }, "rail_name": "Mastercard", "governing_authority": "Mastercard", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "mastercard:settlement", "id": "settlement", "rail": "mastercard", "kind": "rail-fact", "facet": "settlement", "name": "How and when do Mastercard customers settle with each other?", "statement": "A customer that authorizes and clears through Mastercard's Interchange System settles net under Mastercard's settlement Standards, although an issuer and an acquirer may agree to settle a given transaction between themselves. Mastercard converts each transaction into the settlement currency, every customer reconciles each day, and the net settlement advisement is the definitive record of what moved. If a Principal or Association fails to meet a settlement obligation on a processed transaction, Mastercard meets it, with stated exclusions. Cut-off times are in the Settlement Manual, which Orca has not read.", "details": [ { "label": "Net settlement, bilateral by agreement", "value": "Using the Interchange System for authorization and clearing brings the duty to net settle under Mastercard's settlement Standards. For a particular transaction the issuer and the acquirer may instead settle directly under a bilateral agreement. The detailed Standards are in the Settlement Manual.", "citation": "Mastercard Rules, 2 June 2026, rule 8.2 (p. 199)", "rests_on": "rule" }, { "label": "Currency", "value": "The acquirer submits each transaction in the currency it took place in, and Mastercard converts it into the settlement currency. Customers settling bilaterally may use any transaction currency Mastercard supports.", "citation": "Mastercard Rules, 2 June 2026, rule 8.2.1 (p. 199)", "rests_on": "rule" }, { "label": "Daily reconciliation", "value": "Each customer reconciles the Interchange System's totals and transactions to its own books every day. A Dual Message System customer must clear through the Global Clearing Management System, fix and resend rejected messages, and balance its clearing data against each daily net settlement advisement; where reports and the advisement differ, the advisement governs.", "citation": "Mastercard Rules, 2 June 2026, rule 8.2.3 (p. 200); Transaction Processing Rules, 9 June 2026, rule 2.18.1 (pp. 68 to 69)", "rests_on": "rule" }, { "label": "Settlement guarantee", "value": "When a Principal or Association defaults on a settlement obligation from a processed transaction, Mastercard pays it to the extent it is not otherwise met and takes over the receivable. To protect that claim it may, among other steps, charge back on the defaulter's behalf, list its account numbers in warning files, hold money it owes the defaulter, and refuse authorizations on its cards. Outside the guarantee: obligations of the defaulter's sponsored affiliates, intracountry transactions a government ordered left unsettled, transactions in which issuer and acquirer are one group, related, or under common control, and anything not processed through the Interchange System.", "citation": "Mastercard Rules, 2 June 2026, rule 8.5 (pp. 202 to 203)", "rests_on": "rule" }, { "label": "Holidays", "value": "Mastercard performs no settlement cut-offs on 1 January and 25 December. On most other US Federal Reserve holidays customers can settle cross-border and same-currency activity on their local settlement bank's calendar, but no money moves in a regional settlement service on a day the Federal Reserve is closed. The booklet lists the New York Branch holiday dates for 2026 and 2027.", "citation": "Quick Reference Booklet, 2 June 2026, Holiday processing schedule (pp. 13 to 15)", "rests_on": "guidance" }, { "label": "Presentment deadlines", "value": "The acquirer must present a Mastercard purchase within 30 calendar days of the latest approval for a preauthorization and within 7 for any other authorization; a Maestro purchase or ATM transaction within 7 days of the transaction date; a refund within 5 days; a Payment Transaction within one calendar day of its authorization. An issuer must still accept a late presentment when the account is in good standing or the item can otherwise be posted.", "citation": "Transaction Processing Rules, 9 June 2026, rule 3.15.1 (pp. 141 to 142)", "rests_on": "rule" }, { "label": "Clearing timing", "value": "Mastercard's guide says a dual message transaction is usually cleared within one day of authorization, while a single message transaction is authorized and cleared in one message at the time of purchase.", "citation": "Chargebacks Made Simple Guide, July 2025, sections 2.1 and 2.2 (pp. 4 to 5)", "rests_on": "guidance" } ], "exceptions": [ "Australia: from 2027-03-01 acquirers must clear listed card-present Mastercard transactions in Australia through Real Time Clearing (the Clear Now product) or, for debit and ATM transactions, through the Single Message System (Transaction Processing Rules, Asia/Pacific Region rule 2.1, p. 71).", "Europe Region and Latin America and the Caribbean Region: the Mastercard Rules modify rules 8.2.1 and 8.5 for these regions; those modifications were not read [Unverified].", "Payment Transfer Activity: the settlement guarantee covers only first presentment processed PTA transactions in a program Mastercard lists as covered (Mastercard Rules rule 8.5, PTA variation, p. 203).", "Settlement cut-off times and settlement options are in the Settlement Manual and the Single Message System guides, which are not public to Orca." ], "applies_to": "Customers that authorize and clear through Mastercard's Interchange System, all regions; holiday dates are for US dollar settlement", "caveat": "Settlement between banks is not the moment money reaches a merchant or leaves a cardholder; those depend on the acquirer's and issuer's own arrangements, which these rules do not set.", "related": [ "mastercard:finality", "mastercard:hours", "mastercard:messages" ], "basis": { "sources": "Mastercard Rules (2 June 2026) rules 8.2, 8.2.1, 8.2.3, 8.5; Transaction Processing Rules (9 June 2026) rules 2.18.1, 3.15.1, Asia/Pacific Region 2.1; Quick Reference Booklet (2 June 2026) pp. 13 to 15; Chargebacks Made Simple Guide (July 2025) pp. 4 to 5. Read from copies downloaded from Mastercard's public rules page on 2026-09-19. Nothing is quoted. Medium: the Settlement Manual and the regional modifications to chapter 8 were not read.", "confidence": "medium" }, "currency": { "effective_since": "Before the current editions; start not stated in them", "effective_note": "Rules as stated in the Mastercard Rules of 2 June 2026, the Transaction Processing Rules of 9 June 2026, the Security Rules and Procedures Merchant Edition of 4 August 2026, the Quick Reference Booklet of 2 June 2026 and the Chargebacks Made Simple Guide of July 2025, as downloaded from Mastercard's public rules page on 2026-09-19. New editions drop past effective dates, so when a rule began is often not shown. Mastercard reissues its manuals on no fixed calendar and announces changes on Mastercard Connect first [Inference]. The Australian clearing change takes effect 2027-03-01.", "source_edition": "Mastercard Rules, 2 June 2026 edition (https://www.mastercard.com/content/dam/mccom/shared/business/support/rules-pdfs/mastercard-rules.pdf); Transaction Processing Rules, 9 June 2026 edition (https://www.mastercard.com/content/dam/mccom/shared/business/support/rules-pdfs/transaction-processing-rules.pdf); Quick Reference Booklet, merchant download, 2 June 2026 edition (https://www.mastercard.com/content/dam/mccom/shared/business/support/rules-pdfs/mastercard-quick-reference-booklet-merchant.pdf); Chargebacks Made Simple Guide, July 2025 (https://www.mastercard.com/content/dam/mccom/shared/business/support/rules-pdfs/chargebacks-made-simple-guide.pdf)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.mastercard.com/content/dam/mccom/shared/business/support/rules-pdfs/mastercard-rules.pdf", "source_class": "authoritative_primary", "source_title": "Mastercard Rules, 2 June 2026 edition", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms the net settlement requirement, the bilateral settlement option, the daily reconciliation duty, and Mastercard's obligation to meet a failed Principal's or Association's settlement obligation within the rule's stated limits." }, { "source_url": "https://www.mastercard.com/content/dam/mccom/shared/business/support/rules-pdfs/mastercard-quick-reference-booklet-merchant.pdf", "source_class": "authoritative_primary", "source_title": "Quick Reference Booklet, merchant download, 2 June 2026 edition", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms no settlement cutoffs on 1 January or 25 December and the listed 2026 and 2027 US dollar settlement holiday dates." } ] }, "rail_name": "Mastercard", "governing_authority": "Mastercard", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "mx-spei:consumer-law", "id": "consumer-law", "rail": "mx-spei", "kind": "rail-fact", "facet": "consumer-law", "name": "What must a SPEI participant tell its own customer, and what may it charge?", "statement": "A great deal, and quickly. Regla 83a fixes exactly what each side tells its own customer about a settled transfer, down to the settlement time to the second, the Clave de Rastreo in the format it was sent, and a set phrase warning that the sending institution has not verified the beneficiary name. Regla 84a sets the channels: free, monthly, by post or in the account statement, and in the internet and mobile channels within sixty seconds of the settlement advice, kept available for at least three months. Where a payment was not credited, the receiving participant must make the reason reachable by the beneficiary and must run a free channel for asking why. Every participant must publish a page, linked from its electronic channels, describing how to file a clarification, a status enquiry or a claim. Regla 85a requires a link to the Banco de México receipt against every settled transfer within five minutes, kept for three months. Regla 88a forbids fees between participants for sending, receiving, returning or crediting, forbids any fee at all to a beneficiary, makes CoDi free to customers, and allows a retry fee only when the retry succeeds. Since Circular 9/2026 the Guías also fix the mobile interface: what the screen must show before the customer authorises, the receiving participant's name derived from the CLABE without asking, and what the result screen must carry.", "details": [ { "label": "What each side must tell its own customer about a settled transfer", "value": "Regla 83a fixes the content. The sending participant tells its paying customer the receiving participant's name from the SPEI catalogue current at settlement, the calendar date and the time of settlement to the second, the amount, the beneficiary account identifier used (CLABE, debit card number, electronic payment funds number or the ten digits of a mobile line), the beneficiary name as the customer gave it followed by a set phrase saying the institution has not verified it, the Clave de Rastreo in the format it was sent in, the Referencia Numérica, the payment concept where given, and for CoDi the collection scheme folio. For a CoDi order the beneficiary name comes from the Mensaje de Cobro and the unverified phrase is dropped; for an order instructed on a mobile number alone, only the beneficiary's initials or the identifiers Apéndice AR of the Manual sets are shown. The receiving participant tells its beneficiary customer the settlement date and time, amount, Clave de Rastreo, Referencia Numérica, concept and CoDi folio, plus the sending participant's name, the paying customer's CLABE and the name the sending participant gave for that account holder. CoDi operations must be labelled as such to both customers.", "citation": "Circular 14/2017, Reglas del Sistema de Pagos Electrónicos Interbancarios (texto compilado), Regla 83a, fracciones I to IV", "rests_on": "rule" }, { "label": "Monthly by post or in the statement, and in the electronic channels within sixty seconds for three months", "value": "Participants must send that information to the customer free of charge, at the address the customer gave, within the first fifteen calendar days after the end of each calendar month, for every accepted order in that month; a participant that already puts the same information in the periodic account statement need not send it separately. Beyond that, participants must include the information in the internet sites they give customers for looking at account movements and in the mobile channels through which customers present Solicitudes de Envío, within sixty seconds of the Administrador making the settlement advice available, and must keep it available there for at least three months from settlement. Requests presented at an automated teller machine are excepted.", "citation": "Circular 14/2017, Reglas del Sistema de Pagos Electrónicos Interbancarios (texto compilado), Regla 84a, fracciones I, II and III", "rests_on": "rule" }, { "label": "A beneficiary must be able to find out, free, why a settled payment was not credited", "value": "Where an accepted transfer order was not credited, the receiving participant must make the Regla 83a information available to the beneficiary through a channel the beneficiary can reach. It must also run a channel for answering its beneficiary customers' enquiries about accepted orders for which the Administrador has made a settlement advice available, and through that channel it must tell them the reasons the amounts were not credited to their accounts. That information must be free to the customer.", "citation": "Circular 14/2017, Reglas del Sistema de Pagos Electrónicos Interbancarios (texto compilado), Regla 84a, fracciones IV and V", "rests_on": "rule" }, { "label": "Every participant must publish how to file a clarification, a status enquiry or a claim", "value": "Participants must put a page on their internet site, and an electronic link to it in their electronic channels other than automated teller machines, setting out the procedure a customer must follow to present clarification requests, enquiries about the state of a payment, or claims relating to a Solicitud de Envío or an accepted transfer order. Participants must also give customers a section in their software where they can look up the state of their CoDi orders for at least the last three months, in the order the customer chooses, as Apéndice AD of the Manual sets.", "citation": "Circular 14/2017, Reglas del Sistema de Pagos Electrónicos Interbancarios (texto compilado), Regla 84a, fracciones VI and VII", "rests_on": "rule" }, { "label": "A link to the Banco de México receipt must sit against every settled transfer within five minutes", "value": "Participants that have agreed with customers to operate through electronic channels must include, for every accepted transfer order and in every enquiry they offer on it, the electronic link built as Apéndice E of the Manual directs, so that the customer can look up the state of the order or, where it was credited, generate the Comprobante Electrónico de Pago. The link must be available within five minutes of the Administrador making the settlement advice available and must be kept for at least three months from settlement. Where the customer reaches the Banco de México portal through that link, the participant must supply into the portal the settlement date, the Clave de Rastreo or Referencia Numérica, the names of both participants from the current SPEI catalogue, the beneficiary account identifier and the amount.", "citation": "Circular 14/2017, Reglas del Sistema de Pagos Electrónicos Interbancarios (texto compilado), Regla 85a", "rests_on": "rule" }, { "label": "No fees between participants, none to a beneficiary, and none on CoDi or an eliminated order", "value": "Participants may not charge each other fees for sending, receiving, returning or crediting transfer orders, and a receiving participant is forbidden to charge the beneficiary customer anything at all. Sending participants may not charge their paying customers for sending CoDi orders or for receiving and processing the Mensajes de Cobro those customers receive, and receiving participants may not charge beneficiary customers for generating and sending Mensajes de Cobro. Sending participants may not charge for an order SPEI eliminated. Participants may charge a customer for retrying the sending of an order, and only where the retry succeeds; the last paragraph of Regla 88a lists orders other than the return type and then names CoDi orders, and whether it is adding CoDi retries to what may be charged or excluding them alongside returns is not resolvable from the wording [Unverified]. Either way a retry fee is lawful only on success, and the second paragraph's ban on charging for sending a CoDi order stands on its own terms.", "citation": "Circular 14/2017, Reglas del Sistema de Pagos Electrónicos Interbancarios (texto compilado), Regla 88a", "rests_on": "rule" }, { "label": "The Guías are part of the SPEI rules and the mobile interface must follow them", "value": "Circular 9/2026 added the Guías to Regla 2a as definition XXVII Quáter and made them bind in four places: Regla 7a makes the operating process for customer to customer transfers run according to their user experience specifications; Regla 10a requires participants to meet them for any Solicitud de Envío presented through a mobile device; Regla 9a Bis 10 requires the transfer instruction forms an indirect participant gives its customers to meet them; and Regla 71a, fracción V, imposes them on participants other than credit institutions that offer transfers through electronic channels. Regla 7a also makes the Administrador publish the Guías on its site with the publication date, the version number and the date the version takes effect, keep earlier versions posted with their validity periods, and tell participants of changes in advance. They are Banco de México's own, public, versioned and dated, and they govern what a customer sees on a phone rather than how money moves.", "citation": "Circular 14/2017, Reglas del Sistema de Pagos Electrónicos Interbancarios (texto compilado), Reglas 2a, fracción XXVII Quáter, 7a, 9a Bis 10, fracción I, 10a and 71a, fracción V; Guías para la homologación de la experiencia de usuario en transferencias electrónicas de fondos a través de dispositivos móviles, versión 1.1, section II, alcance, and section VII, control de versiones", "rests_on": "rule" }, { "label": "The screen must show the receiving participant derived from the account identifier", "value": "In the information entry stage the interface must let the customer capture the beneficiary by any of the account identifiers (CLABE, card digits, mobile number, or an account number for a transfer inside the same institution), by picking from the phone's contacts or saved accounts, or by reading a QR code. It must then show the SPEI participant associated with that identifier. Where a CLABE is used the participant's name must be derived from it without asking the customer, and where the account belongs to an indirect participant the field shows the participant that provides the indirect participation services for that CLABE. For other identifiers the entity shows the receiving participant where it can work it out, and the customer may correct it, except where the identifier is a mobile number and the entity obtained the receiving participant from the Administrador, in which case the field must not be editable.", "citation": "Guías para la homologación de la experiencia de usuario en transferencias electrónicas de fondos a través de dispositivos móviles, versión 1.1, section V.B, momento 2, numerals 3 and 4", "rests_on": "rule" }, { "label": "A confirmation screen must show five things before the customer authorises", "value": "The third stage of the flow is consistency and integrity. The interface must show the customer the operation's data for checking, and at least the amount, the beneficiary's name (masked or not), the beneficiary's account, the receiving participant, and the account the money will come from, masked or showing its last digits. It must then offer an interactive element by which the customer accepts sending the transfer, and only with that acceptance may the entity proceed to its own authorisation and authentication. The entity may add further identity checks and its own validations on transaction limits, format, security and regulatory requirements.", "citation": "Guías para la homologación de la experiencia de usuario en transferencias electrónicas de fondos a través de dispositivos móviles, versión 1.1, section V.C, numerals 1 and 2", "rests_on": "rule" }, { "label": "The result screen must carry the status, the Clave de Rastreo and a link to the CEP", "value": "The fourth stage is notification. The interface must show the state of the operation (sent, rejected, under review, among others), the amount, the payment concept and numeric reference where they apply, and the beneficiary's masked name, account identifier and institution. For an operation between institutions it must also show the Clave de Rastreo and a link for downloading the Comprobante Electrónico de Pago; for one inside a single institution, a folio or authorisation number. Separately, error, rejection and cancellation messages must be precise and clear, so that the customer is told plainly what happened.", "citation": "Guías para la homologación de la experiencia de usuario en transferencias electrónicas de fondos a través de dispositivos móviles, versión 1.1, section V.D, numerals 1 to 3, and section V.E, numeral 6", "rests_on": "rule" } ], "exceptions": [ "Requests presented at an automated teller machine are outside the sixty second electronic channel duty and outside the clarifications page link duty.", "The Guías bind from Circular 9/2026 but participants and the indirect participants they contract with have until 2026-12-14 to comply, and version 1.1 of the Guías takes effect on that same date, so the interface rules describe what will be required rather than what is required today.", "General Mexican consumer and financial services law was not read here: the Ley para la Transparencia y Ordenamiento de los Servicios Financieros article 22, cited in Circular 9/2026's preamble, the Ley de Protección y Defensa al Usuario de Servicios Financieros, and CONDUSEF's own rules." ], "applies_to": "SPEI in Mexico, in Mexican pesos: ordinary customer to customer transfer orders, low value orders, CoDi orders, Pagos Programados and the four return types, among the 94 direct participants Banco de México lists and the indirect participants they serve", "caveat": "What a beneficiary is actually told when a payment was not credited rests on the numbered catalogue in section 9 of the Manual, which Banco de México gives only to participants. Orca can say the participant must give a reason and cannot say what reason the customer sees.", "related": [ "pix:consumer-law", "mx-spei:messages" ], "basis": { "sources": "Reglas del SPEI 83a, 84a, 85a and 88a; Guías versión 1.1 sections II, V.B, V.C, V.D, V.E and VII; read 2026-09-20. The general consumer statutes were not read.", "confidence": "high" }, "currency": { "effective_since": "2026-06-17", "effective_to": null, "effective_note": "Drafted 2026-09-20 in Orca Core form. The date is the day the Diario Oficial de la Federación published Circular 9/2026, the newest source this fact rests on, which made the Guías part of the SPEI rules. Each Rule listed here carries its own date, and compliance with the Guías is due by 2026-12-14.", "source_edition": "Circular 14/2017, Reglas del Sistema de Pagos Electrónicos Interbancarios, texto compilado, published in the Diario Oficial de la Federación on 2017-07-04 and including the amendments made by Circulares 5/2018, 11/2018, 18/2018, 3/2019, 8/2019, 1/2022, 15/2022, 16/2022, 12/2023, 2/2025 and 9/2026, the last of them published in the DOF on 2026-06-17; PDF of 296 pages read in Spanish on 2026-09-20; Guías para la homologación de la experiencia de usuario en transferencias electrónicas de fondos a través de dispositivos móviles, versión 1.1, published 2026-08-28 and in force from 2026-12-14; PDF of 58 pages marked Uso Público read in Spanish on 2026-09-20", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.banxico.org.mx/marco-normativo/normativa-emitida-por-el-banco-de-mexico/circular-14-2017/%7BA06FBFEE-06BB-F249-32FC-25B334B2A744%7D.pdf", "source_class": "authoritative_primary", "source_title": "Circular 14/2017, Reglas del Sistema de Pagos Electrónicos Interbancarios (texto compilado)", "checked_on": "2026-09-21", "checked_by": "mx-spei validator session, 2026-09-21", "notes": "Confirms Reglas 83a, 84a, 85a and 88a give the content, channel and timing rules, the not-credited disclosure duties, the clarifications page and the CEP link and fee rules the fact states." }, { "source_url": "https://www.banxico.org.mx/marco-normativo/normativa-emitida-por-el-banco-de-mexico/circular-14-2017/%7BFBF220A3-C5B8-268A-C57B-A00CD109BA63%7D.pdf", "source_class": "authoritative_primary", "source_title": "Guías para la homologación de la experiencia de usuario en transferencias electrónicas de fondos a través de dispositivos móviles, versión 1.1", "checked_on": "2026-09-21", "checked_by": "mx-spei validator session, 2026-09-21", "notes": "Confirms sections II, V.B, V.C, V.D, V.E and VII of the Guias version 1.1 set the mobile interface requirements the fact adds since Circular 9/2026, including the confirmation screen, the CLABE derived participant name and the result screen." } ] }, "rail_name": "SPEI (Mexico peso interbank electronic transfers)", "governing_authority": "Banco de México", "snapshot": "2026-09-20", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "mx-spei:decision-points", "id": "decision-points", "rail": "mx-spei", "kind": "rail-fact", "facet": "decision-points", "name": "Where do the SPEI rules leave a decision to a bank or a person?", "statement": "In five places that change what happens to a payment. The sending participant decides whether to accept the customer's Solicitud de Envío at all, on identification and verification criteria the Reglas leave to it, and must tell the customer the cause if it refuses; and it decides whether to instruct cancellation in the seconds before settlement. The receiving participant decides whether to accept optional transfer order types at all, and an order of a type it refused becomes a mandatory return; whether to run validations beyond the Reglas above six thousand UDIS and ask the Administrador for a longer crediting window; and whether to accept or reject a support request under the Convenio. The beneficiary decides whether to instruct the return of a payment credited to its account, which is the only return a customer can start. And the Administrador decides whether to extend or suspend the operating hours, whether to grant an extension request, and when to eliminate an order it cannot settle.", "details": [ { "label": "The sending participant decides whether to accept the customer's request at all", "value": "Under Regla 7a the sending participant performs the checks Regla 13a requires and, on them, decides whether to accept the Solicitud de Envío. If it accepts, it processes the request by sending the transfer order to the Administrador through the instance the order set calls for. If it does not, it rejects the request and must tell the customer both the fact and the cause. The Reglas leave the acceptance criteria to the participant's own identification, authentication and verification, so what makes a request acceptable varies by institution and is not something Orca can state.", "citation": "Circular 14/2017, Reglas del Sistema de Pagos Electrónicos Interbancarios (texto compilado), Regla 7a, fracción II, and Regla 13a", "rests_on": "rule" }, { "label": "A sent order can be cancelled only while it is unsettled, and there is no recall after that", "value": "The sending participant may send the Administrador instructions to cancel transfer orders it has already sent, through the instance it sent them on. Orders may be cancelled only while SPEI has not settled them under Regla 18a. Once the order is settled and the settlement advice is out it is an Orden de Transferencia Aceptada por SPEI and article 11 of the Ley de Sistemas de Pagos makes it irrevocable, so no instruction from the sender can pull it back. After that point money returns only as a new transfer order of a return type sent by the receiving side.", "citation": "Circular 14/2017, Reglas del Sistema de Pagos Electrónicos Interbancarios (texto compilado), Regla 17a, third paragraph, and Regla 18a", "rests_on": "rule" }, { "label": "A receiving participant may tell the Administrador it will not take certain order types", "value": "Section 9 of the Manual marks some transfer order types optional. A receiving participant may notify the Administrador in advance that it has decided not to receive them, and once it has, an order of such a type arriving at it is a mandatory return ground under Regla 23a, fracción V. Which types are optional is in the Manual and is not public, so Orca cannot say what a participant is choosing between. Two further choices sit with the same participant: whether to run validations beyond the Reglas above six thousand UDIS and ask the Administrador for a longer crediting window, and whether to accept or reject a support request under the Convenio.", "citation": "Circular 14/2017, Reglas del Sistema de Pagos Electrónicos Interbancarios (texto compilado), Regla 23a, fracción V, Regla 19a, fracción I, and Regla 43a, fracción III", "rests_on": "rule" }, { "label": "Six thousand UDIS is the point at which a receiver may ask for longer to run extra checks", "value": "Where a single transfer reaches six thousand UDIS, or where transfers to one beneficiary account in a single SPEI operating day add up to that figure, a receiving participant that decides under its internal processes to run validations beyond those the Reglas require may ask the Administrador, through the Dirección de Operación y Continuidad de Sistemas de Pagos e Infraestructuras de Mercados, for authorisation to credit later than the ordinary deadline, for a period of no more than six months. The request must record that the participant is in the course of automating those validations. Participants use the official UDI value for the first day of January of the calendar year. Again a threshold, not a cap.", "citation": "Circular 14/2017, Reglas del Sistema de Pagos Electrónicos Interbancarios (texto compilado), Regla 19a, fracción I, third paragraph", "rests_on": "rule" }, { "label": "Participants must enter into a fraud collaboration agreement, and Regla 43a sets what it must contain", "value": "Participants must enter into a Convenio de Colaboración para la Protección de Clientes Emisores setting out the procedure for presenting support requests to receiving participants, so as to protect paying customers, direct and indirect, where accepted transfer orders are processed that those customers did not ask for. They must obtain Banco de México's authorisation before entering into it or amending it, though not for a new participant joining one already made, and the draft they submit must contain at least: who is signing; how receiving participants will handle support requests, keep the evidence of receipt and follow them up; the criteria and times for deciding whether to accept or reject one; how the beneficiary may be stopped from taking the funds and for how long, subject to the CNBV's own rules; how the funds are released to the beneficiary or handed to the sending participant for the paying customer, which must involve confirming the order with that customer; the mechanism for returning the funds, and the obligation to send a credited return under Reglas 28a or 29a where the participants have enough to presume a fraudulent operation; when an order counts as possibly fraudulent and the obligation to return it as a not credited return under Regla 24a; and how responsibilities and disputes between participants are settled. A participant that operates an international foreign exchange settlement system including the peso is not required to join. The Convenio itself is not published, so Orca states the delegation and the required contents and stops there.", "citation": "Circular 14/2017, Reglas del Sistema de Pagos Electrónicos Interbancarios (texto compilado), Regla 43a, fracciones I to VIII", "rests_on": "rule" }, { "label": "A beneficiary who does not recognise a credited payment may instruct its return, within thirty seconds", "value": "Where a Cliente Beneficiario does not recognise an accepted order already credited to its account, the receiving participant must let it send the money back by presenting a Solicitud de Envío for a transfer order of the credited return type, in the format section 8 of the Manual sets. The participant must send that order no later than thirty seconds after receiving the request, and four seconds where it is a CoDi order. The participant must also send a credited return on its own, without the beneficiary asking, in two cases: where applying the Convenio de Colaboración para la Protección del Cliente Emisor determines that the funds must go back, and where it received a CoDi order, credited it, and did not send the Administrador the processing advice confirming the credit, in which case the deadline is eight seconds from the settlement advice. This is the only return on the rail a customer can start.", "citation": "Circular 14/2017, Reglas del Sistema de Pagos Electrónicos Interbancarios (texto compilado), Reglas 28a and 30a, first and third paragraphs", "rests_on": "rule" }, { "label": "The Administrador may extend or suspend the hours, and a participant may ask for up to sixty minutes", "value": "The Administrador may extend the SPEI operating hours or suspend the service for fortuitous event or force majeure, and must tell participants of an extension through the electronic channel it has designated. A participant that expects a technical or operational problem to stop it sending its pending orders before the close may request an extension through the Dirección de Operación y Continuidad de Sistemas de Pagos e Infraestructuras de Mercados, at least thirty minutes before the close, on the form in Apéndice J of the Manual, stating the number and total amount of the orders still to send, the cause and type of problem and the minutes requested. An extension runs for between one and four periods of fifteen minutes, so sixty minutes at most, the first period beginning one second after the scheduled close.", "citation": "Circular 14/2017, Reglas del Sistema de Pagos Electrónicos Interbancarios (texto compilado), Reglas 36a, 37a and 38a", "rests_on": "rule" }, { "label": "Four grounds on which the Administrador eliminates an order it has not settled", "value": "The Administrador eliminates an order automatically when it is unsettled at the close of the SPEI operating day; when a non-CoDi order is unsettled after the number of clearing cycles section 5.7 of the Manual sets, because the sender's Cuenta del SPEI is short or because the receiving participant has disconnected from the instance; when a CoDi order is unsettled after the clearing cycle immediately following its receipt; and when the Administrador is prevented from processing it. Separately it may eliminate orders for as long as the sender has too little balance in the instance account they were sent to. The number of cycles is set in a section of the Manual that is not public, so Orca cannot say how long an order survives on the shortfall ground.", "citation": "Circular 14/2017, Reglas del Sistema de Pagos Electrónicos Interbancarios (texto compilado), Regla 17a, fracciones I to IV, and the paragraph added by Circular 1/2022", "rests_on": "rule" } ], "exceptions": [ "Which transfer order types are optional is in section 9 of the Manual, so Orca cannot say what a receiving participant is choosing between.", "The criteria for accepting or rejecting a support request are in the Convenio de Colaboración, which is not published." ], "applies_to": "SPEI in Mexico, in Mexican pesos: ordinary customer to customer transfer orders, low value orders, CoDi orders, Pagos Programados and the four return types, among the 94 direct participants Banco de México lists and the indirect participants they serve", "caveat": "Most of the discretion on this rail points at documents Orca does not hold. The Reglas name the decision and leave the criteria to the Manual, to the Convenio, or to the participant's own internal processes.", "related": [ "pix:decision-points" ], "basis": { "sources": "Reglas del SPEI 7a, 13a, 17a, 19a fracción I, 23a fracción V, 28a, 36a, 37a and 43a fracción III, read 2026-09-20.", "confidence": "medium" }, "currency": { "effective_since": "2022-03-23", "effective_to": null, "effective_note": "Drafted 2026-09-20 in Orca Core form. The date is the day the Diario Oficial de la Federación published Circular 1/2022, which last set most of the provisions this fact rests on. Each Rule listed here carries its own date.", "source_edition": "Circular 14/2017, Reglas del Sistema de Pagos Electrónicos Interbancarios, texto compilado, published in the Diario Oficial de la Federación on 2017-07-04 and including the amendments made by Circulares 5/2018, 11/2018, 18/2018, 3/2019, 8/2019, 1/2022, 15/2022, 16/2022, 12/2023, 2/2025 and 9/2026, the last of them published in the DOF on 2026-06-17; PDF of 296 pages read in Spanish on 2026-09-20", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.banxico.org.mx/marco-normativo/normativa-emitida-por-el-banco-de-mexico/circular-14-2017/%7BA06FBFEE-06BB-F249-32FC-25B334B2A744%7D.pdf", "source_class": "authoritative_primary", "source_title": "Circular 14/2017, Reglas del Sistema de Pagos Electrónicos Interbancarios (texto compilado)", "checked_on": "2026-09-21", "checked_by": "mx-spei validator session, 2026-09-21", "notes": "Confirms Reglas 7a, 13a, 17a, 19a fraccion I, 23a fraccion V, 28a, 36a, 37a and 43a fraccion III place the five decisions the fact names with the sending participant, the receiving participant, the beneficiary and the Administrador respectively." } ] }, "rail_name": "SPEI (Mexico peso interbank electronic transfers)", "governing_authority": "Banco de México", "snapshot": "2026-09-20", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "mx-spei:finality", "id": "finality", "rail": "mx-spei", "kind": "rail-fact", "facet": "finality", "name": "When does a SPEI payment become final, and can it be reversed?", "statement": "Finality is statutory here, and it lands at one identifiable moment. Once the Administrador has validated an Orden de Transferencia, settled it and made the Aviso de Liquidación available to both participants, it is an Orden de Transferencia Aceptada por SPEI, and Ley de Sistemas de Pagos article 11 makes it, its compensación and its liquidación firm, irrevocable, enforceable and effective against third parties. Settlement is in central bank money on the participants' own Cuentas del SPEI and no participant may overdraw, so a settled payment is never settled on credit. Before settlement the sender may cancel; after it, nothing the sender does can pull the money back. A court, regulator or insolvency measure against a participant bites only from the banking day after it is served on the Administrador, so payments in flight on the day of service still settle.", "details": [ { "label": "An order becomes an Orden de Transferencia Aceptada por SPEI when it is settled and advised", "value": "A transfer order passes the Administrador's automated validations, is settled, and the Aviso de Liquidación is made available to both the sending and the receiving participant. At that point, and not before, it is an Orden de Transferencia Aceptada por SPEI. Regla 18a states that these are the accepted transfer orders the Ley de Sistemas de Pagos speaks of, which is what carries the statutory finality across from the law to this system.", "citation": "Circular 14/2017, Reglas del Sistema de Pagos Electrónicos Interbancarios (texto compilado), Regla 18a, second and third paragraphs", "rests_on": "rule" }, { "label": "Accepted orders, their netting and their settlement are firm, irrevocable, enforceable and effective against third parties", "value": "Ley de Sistemas de Pagos article 11 gives accepted transfer orders, their compensación and their liquidación, and every act the system's internal rules require to complete them, the four part legal standard of being firm, irrevocable, enforceable and effective against third parties. Compensación here is the statutory netting of article 2, fracción II, the replacement of the rights and obligations from transfer orders by a single net claim, not the delay payment the Reglas separately call compensación. Creditors and insolvency bodies keep whatever claims for damages the general law gives them against whoever is answerable; what they cannot do is unwind the settlement.", "citation": "Ley de Sistemas de Pagos, article 11, first and third paragraphs, and article 2, fracción II", "rests_on": "law" }, { "label": "A court, regulator or insolvency measure bites only from the banking day after it is served on the Administrador", "value": "A judicial or administrative resolution against a participant, including attachment and other enforcement acts and anything arising from insolvency or winding up, that would prohibit, suspend or limit the payments that participant must make in a payment system, takes effect and becomes enforceable only from the banking day after it is served on the Administrador in the manner article 13 sets. Payments already in flight on the day of service are therefore not caught.", "citation": "Ley de Sistemas de Pagos, article 11, second paragraph, and article 13", "rests_on": "law" }, { "label": "No participant may overdraw its Cuenta del SPEI", "value": "Settlement uses the balance the participant holds in the Cuenta del SPEI for the instance the order was sent to. An order for more than that balance at the moment of settlement cannot settle, so participants cannot run an overdraft on a Cuenta del SPEI. SPEI extends no credit: the only money that settles a payment is money already in the participant's account in the system.", "citation": "Circular 14/2017, Reglas del Sistema de Pagos Electrónicos Interbancarios (texto compilado), Regla 6a, first paragraph; SPEI, divulgación del cumplimiento y adopción de los Principios para las Infraestructuras del Mercado Financiero, executive summary and section III.C", "rests_on": "rule" }, { "label": "A sent order can be cancelled only while it is unsettled, and there is no recall after that", "value": "The sending participant may send the Administrador instructions to cancel transfer orders it has already sent, through the instance it sent them on. Orders may be cancelled only while SPEI has not settled them under Regla 18a. Once the order is settled and the settlement advice is out it is an Orden de Transferencia Aceptada por SPEI and article 11 of the Ley de Sistemas de Pagos makes it irrevocable, so no instruction from the sender can pull it back. After that point money returns only as a new transfer order of a return type sent by the receiving side.", "citation": "Circular 14/2017, Reglas del Sistema de Pagos Electrónicos Interbancarios (texto compilado), Regla 17a, third paragraph, and Regla 18a", "rests_on": "rule" } ], "exceptions": [ "An order that never settles is not final and never happened: the Administrador eliminates it at the close, after the clearing cycles section 5.7 of the Manual sets, or when it cannot process it (mx-spei:settlement).", "Finality of the settlement does not extinguish claims in damages: Ley de Sistemas de Pagos article 11 keeps whatever actions the general law gives creditors, insolvency bodies and third parties against whoever is answerable." ], "applies_to": "SPEI in Mexico, in Mexican pesos: ordinary customer to customer transfer orders, low value orders, CoDi orders, Pagos Programados and the four return types, among the 94 direct participants Banco de México lists and the indirect participants they serve", "caveat": "Compensación means two different things on this rail. In Ley de Sistemas de Pagos article 2, fracción II, it is netting, the replacement of the rights and obligations from transfer orders by a single net claim. In Reglas 86a and 87a it is the delay payment a participant owes a customer or another participant. Same Spanish word, two meanings, both in scope.", "related": [ "pix:finality", "mx-spei:recall" ], "basis": { "sources": "Reglas del SPEI 6a, 17a and 18a; Ley de Sistemas de Pagos articles 2, 11 and 13; read 2026-09-20.", "confidence": "high" }, "currency": { "effective_since": "2017-07-04", "effective_to": null, "effective_note": "Drafted 2026-09-20 in Orca Core form. The date is the day the Diario Oficial de la Federación published Circular 14/2017, the original text of the Reglas del SPEI; each Rule this fact lists carries its own date, which for a provision a later circular changed is that circular's publication date.", "source_edition": "Circular 14/2017, Reglas del Sistema de Pagos Electrónicos Interbancarios, texto compilado, published in the Diario Oficial de la Federación on 2017-07-04 and including the amendments made by Circulares 5/2018, 11/2018, 18/2018, 3/2019, 8/2019, 1/2022, 15/2022, 16/2022, 12/2023, 2/2025 and 9/2026, the last of them published in the DOF on 2026-06-17; PDF of 296 pages read in Spanish on 2026-09-20; Ley de Sistemas de Pagos, new law published in the Diario Oficial de la Federación on 2002-12-12, last reform published on 2025-11-14; PDF of 14 pages from the Cámara de Diputados read in Spanish on 2026-09-20", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.diputados.gob.mx/LeyesBiblio/pdf/LSP.pdf", "source_class": "authoritative_primary", "source_title": "Ley de Sistemas de Pagos", "checked_on": "2026-09-21", "checked_by": "mx-spei validator session, 2026-09-21", "notes": "Confirms article 11 gives accepted transfer orders, their compensacion and liquidacion the firm, irrevocable, enforceable and effective against third parties standard, and holds judicial and insolvency measures off until the banking day after service on the Administrador." }, { "source_url": "https://www.banxico.org.mx/marco-normativo/normativa-emitida-por-el-banco-de-mexico/circular-14-2017/%7BA06FBFEE-06BB-F249-32FC-25B334B2A744%7D.pdf", "source_class": "authoritative_primary", "source_title": "Circular 14/2017, Reglas del Sistema de Pagos Electrónicos Interbancarios (texto compilado)", "checked_on": "2026-09-21", "checked_by": "mx-spei validator session, 2026-09-21", "notes": "Confirms Regla 18a makes an order an Orden de Transferencia Aceptada por SPEI once validated, settled and advised, Regla 6a bars overdrafts on a Cuenta del SPEI, and Regla 17a lets the sender cancel only before settlement." } ] }, "rail_name": "SPEI (Mexico peso interbank electronic transfers)", "governing_authority": "Banco de México", "snapshot": "2026-09-20", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "mx-spei:hours", "id": "hours", "rail": "mx-spei", "kind": "rail-fact", "facet": "hours", "name": "When is SPEI open, and what is a SPEI day?", "statement": "SPEI runs continuously, and its day is not a calendar day. The operating day for a given banking day begins at 18:00:00 on the previous banking day and ends at 17:59:59 on that banking day, in every instance. A transfer sent at 19:00 on a Monday therefore belongs to Tuesday's operating day. Every time in the Reglas is Mexico City time unless a provision says otherwise. Low value orders reaching a credit institution or a mobile transfer clearing house must be credited within five seconds twenty four hours a day, every day of the year, while smaller participants get the five second duty only between 06:00:00 and the close. The Administrador may extend the hours or suspend the service for force majeure, and a participant with a technical problem may ask for up to sixty minutes in four fifteen minute periods.", "details": [ { "label": "Continuous operation, and an operating day that starts at 18:00:00 the previous banking day", "value": "SPEI runs on a continuous operating scheme. The operating day for a given banking day, in every SPEI instance, begins at 18:00:00 on the previous banking day and ends at 17:59:59 on the banking day itself. So a transfer sent at 19:00 on a Monday belongs to Tuesday's operating day, and a claim that a payment went out the same day has to say which day is meant.", "citation": "Circular 14/2017, Reglas del Sistema de Pagos Electrónicos Interbancarios (texto compilado), Regla 35a", "rests_on": "rule" }, { "label": "Every time in the Reglas is Mexico City time unless it says otherwise", "value": "Unless a provision states otherwise, the times the Reglas and the other applicable provisions give are referred to the time zone in force in Mexico City. Every deadline expressed as a clock time on this rail, from the 06:00:00 overnight cutovers to the 17:59:59 close, is read in that zone.", "citation": "Circular 14/2017, Reglas del Sistema de Pagos Electrónicos Interbancarios (texto compilado), Regla 34a", "rests_on": "rule" }, { "label": "The Administrador may extend or suspend the hours, and a participant may ask for up to sixty minutes", "value": "The Administrador may extend the SPEI operating hours or suspend the service for fortuitous event or force majeure, and must tell participants of an extension through the electronic channel it has designated. A participant that expects a technical or operational problem to stop it sending its pending orders before the close may request an extension through the Dirección de Operación y Continuidad de Sistemas de Pagos e Infraestructuras de Mercados, at least thirty minutes before the close, on the form in Apéndice J of the Manual, stating the number and total amount of the orders still to send, the cause and type of problem and the minutes requested. An extension runs for between one and four periods of fifteen minutes, so sixty minutes at most, the first period beginning one second after the scheduled close.", "citation": "Circular 14/2017, Reglas del Sistema de Pagos Electrónicos Interbancarios (texto compilado), Reglas 36a, 37a and 38a", "rests_on": "rule" }, { "label": "Three thousand customer accounts splits participants into two classes", "value": "A participant that is a credit institution or an institution of electronic payment funds and that keeps at least three thousand demand deposit or electronic payment funds accounts, counted as Regla 15a directs, must connect to every SPEI instance on every operating day. One below that count connects only to the instance its transfer order set is assigned to, and must be able to connect to any other when the Administrador tells it to. The same figure changes the deadlines: a participant under three thousand accounts is outside the round the clock five second crediting window for low value orders and instead credits within five seconds between 06:00:00 and the close, and its return deadline for low value orders taken overnight is 06:00:10.", "citation": "Circular 14/2017, Reglas del Sistema de Pagos Electrónicos Interbancarios (texto compilado), Reglas 5a Bis, 15a, 19a, fracción II, and 25a, fracción III", "rests_on": "rule" } ], "exceptions": [ "Participants that are neither credit institutions nor mobile transfer clearing houses work to clock time deadlines in the overnight window rather than to a seconds clock, at 06:00:30 for crediting and 06:01:00 for returning.", "Mexico has observed no daylight saving since 2022, so the Mexico City offset does not shift during the year [Unverified: not checked in a source read here]." ], "applies_to": "SPEI in Mexico, in Mexican pesos: ordinary customer to customer transfer orders, low value orders, CoDi orders, Pagos Programados and the four return types, among the 94 direct participants Banco de México lists and the indirect participants they serve", "caveat": "Never write same day about a SPEI payment without saying which day. The operating day and the banking day do not coincide, and the operating day starts the evening before.", "related": [ "pix:hours" ], "basis": { "sources": "Reglas del SPEI 15a, 19a, 34a, 35a, 36a, 37a and 38a, read 2026-09-20. That Mexico observes no daylight saving is not sourced here.", "confidence": "high" }, "currency": { "effective_since": "2017-07-04", "effective_to": null, "effective_note": "Drafted 2026-09-20 in Orca Core form. The date is the day the Diario Oficial de la Federación published Circular 14/2017, the original text of the Reglas del SPEI; each Rule this fact lists carries its own date, which for a provision a later circular changed is that circular's publication date.", "source_edition": "Circular 14/2017, Reglas del Sistema de Pagos Electrónicos Interbancarios, texto compilado, published in the Diario Oficial de la Federación on 2017-07-04 and including the amendments made by Circulares 5/2018, 11/2018, 18/2018, 3/2019, 8/2019, 1/2022, 15/2022, 16/2022, 12/2023, 2/2025 and 9/2026, the last of them published in the DOF on 2026-06-17; PDF of 296 pages read in Spanish on 2026-09-20", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.banxico.org.mx/marco-normativo/normativa-emitida-por-el-banco-de-mexico/circular-14-2017/%7BA06FBFEE-06BB-F249-32FC-25B334B2A744%7D.pdf", "source_class": "authoritative_primary", "source_title": "Circular 14/2017, Reglas del Sistema de Pagos Electrónicos Interbancarios (texto compilado)", "checked_on": "2026-09-21", "checked_by": "mx-spei validator session, 2026-09-21", "notes": "Confirms Reglas 15a, 19a, 34a, 35a, 36a, 37a and 38a: continuous operation, the 18:00:00 to 17:59:59 operating day, Mexico City time, the five second low value crediting window and its class exceptions, and the hours extension mechanism." } ] }, "rail_name": "SPEI (Mexico peso interbank electronic transfers)", "governing_authority": "Banco de México", "snapshot": "2026-09-20", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "mx-spei:liability", "id": "liability", "rail": "mx-spei", "kind": "rail-fact", "facet": "liability", "name": "Who bears a loss when a SPEI deadline is missed?", "statement": "The Administrador bears nothing: Regla 22a releases Banco de México from all liability to participants and their customers for the actions SPEI performs under the Reglas and as the Manual directs, automated ones included. Between the others the Reglas impose paid compensation rather than damages, and the same word compensación is used for it. A sending participant that misses the sending deadline in Regla 17a or either return crediting deadline in Reglas 27a and 31a pays its own paying customer; a receiving participant that misses the crediting deadline in Regla 19a pays its own beneficiary customer; and a receiving participant that misses a return deadline in Reglas 25a or 30a pays the sending participant by adding the amount to the extemporánea return itself. Regla 87a computes the amount from the Tasa Ponderada de Fondeo Bancario of the previous banking day, the transfer amount and the seconds of delay divided by 31,104,000, and where the breach runs into the next operating day Regla 86a makes the sum payable the greater of that doubled and a floor of 3.5 times the daily UMA, one daily UMA for CoDi. A participant whose own infrastructure fails must tell affected customers within sixty seconds and must stop taking send requests while it cannot operate normally.", "details": [ { "label": "The Administrador is released from liability for what it does under the Reglas and the Manual", "value": "Banco de México, as Administrador, is released from all liability towards participants and their customers for the actions SPEI performs that the Reglas provide for and that are carried out as the Manual directs, including the ones performed automatically. The liability the Reglas do allocate runs between participants, and between a participant and its own customer, as paid compensation rather than damages.", "citation": "Circular 14/2017, Reglas del Sistema de Pagos Electrónicos Interbancarios (texto compilado), Regla 22a", "rests_on": "rule" }, { "label": "A participant that misses a sending, crediting or return crediting deadline pays its own customer", "value": "Regla 86a makes a participant pay its own customer, computed as Regla 87a directs, in two situations. The sending participant pays its paying customer where it missed a deadline in Regla 17a for sending the order, Regla 27a for crediting a not credited return, or Regla 31a for crediting a credited return. The receiving participant pays its beneficiary customer where it missed the crediting deadline in Regla 19a. In both cases the money must be in the same customer account by the close of the SPEI operating day after the one on which the breach happened. Where an indirect participant is in the chain, the participant must verify under the Contrato de Servicios de Participación Indirecta that the indirect participant pays its own customer the same amount on the same clock.", "citation": "Circular 14/2017, Reglas del Sistema de Pagos Electrónicos Interbancarios (texto compilado), Regla 86a, fracciones I, I Bis and II", "rests_on": "rule" }, { "label": "A receiving participant that returns late pays the sending participant, inside the return itself", "value": "Where the receiving participant missed a deadline in Regla 25a or Regla 30a, it must pay the sending participant of the order being returned the amount Regla 87a computes. It does not pay separately: it sends the extemporánea return type, not credited or credited as the case requires, for the original amount plus that compensation, and the sending participant must then credit the whole of it to its own customer within the ordinary deadline. Where the party in default is a beneficiary customer acting as an indirect participant, the participant that holds its Contrato de Servicios de Participación Indirecta must verify that it pays.", "citation": "Circular 14/2017, Reglas del Sistema de Pagos Electrónicos Interbancarios (texto compilado), Regla 86a, fracciones III and III Bis", "rests_on": "rule" }, { "label": "The compensation is the greater of a floor in UMA and twice a formula over the delay in seconds", "value": "Regla 87a computes a reference amount in three steps: take the Tasa Ponderada de Fondeo Bancario that Banco de México published on the banking day before the breach, closed to four decimals, multiply it by the amount of the transfer including centavos, multiply that by the number of seconds of delay counted from the first second after the breach, and divide by 31,104,000, closing the result to two decimals. Where the breach runs at least into the SPEI operating day after the deadline expired, Regla 86a makes the amount payable the greater of 3.5 times the daily value of the Unidad de Medida y Actualización in force at the time of the breach and twice that reference amount. For a participant processing CoDi orders the floor is one daily UMA rather than 3.5. The UMA is an index unit, not pesos, so neither figure is a money amount.", "citation": "Circular 14/2017, Reglas del Sistema de Pagos Electrónicos Interbancarios (texto compilado), Regla 87a, and Regla 86a, the paragraphs on the greater of the two amounts", "rests_on": "rule" }, { "label": "A late return becomes the extemporánea type and its amount must include the delay compensation", "value": "Missing the applicable deadline does not simply make a return late. Where the receiving participant sends the return on a SPEI operating day later than the one on which it received the original order, it must send a different transfer order type, the devolución extemporánea of a transfer not credited to a customer account, in the format section 8 of the Manual sets, and the amount must be the original amount plus the compensation Regla 87a computes. A record that treats the extemporánea return as the same message sent later is wrong: it is another type, for another amount.", "citation": "Circular 14/2017, Reglas del Sistema de Pagos Electrónicos Interbancarios (texto compilado), Reglas 26a and 24a, fracción II", "rests_on": "rule" }, { "label": "Orders arriving in the last five minutes of the day may be returned in the first five of the next, free", "value": "Where a participant receives accepted transfer orders during the five consecutive minutes immediately before the close of the SPEI operating day and those orders need returning under Regla 23a or Regla 30a, it may send the returns in the first five minutes of the next SPEI operating day. In that case it owes no compensation under Regla 87a.", "citation": "Circular 14/2017, Reglas del Sistema de Pagos Electrónicos Interbancarios (texto compilado), Regla 86a, the paragraph added by Circular 8/2019", "rests_on": "rule" }, { "label": "A participant whose own infrastructure fails must tell affected customers within sixty seconds", "value": "Where a participant's own technological infrastructure suffers an event that affects the SPEI related services it gives its customers, or an event affects its ordinary operation in SPEI, it must tell the affected customers, through the channels by which they instruct or try to instruct Solicitudes de Envío and through the channels agreed with them, that the failure came from the participant's own infrastructure or that an event affected its ordinary operation. The deadline is sixty seconds from the event, unless the failure took out the communication channels needed to give the notice, in which case the notice goes as soon as they are back. The same duty runs down to indirect customers through the indirect participant.", "citation": "Circular 14/2017, Reglas del Sistema de Pagos Electrónicos Interbancarios (texto compilado), Regla 89a, first and second paragraphs", "rests_on": "rule" }, { "label": "A participant that cannot operate normally must stop taking send requests", "value": "For as long as a participant is unable to operate normally in SPEI because of such an event, it must stop letting its customers present Solicitudes de Envío, CoDi operations included. The only exception is the scheduled send requests the second and third paragraphs of Regla 10a and fracción III of Regla 14a allow.", "citation": "Circular 14/2017, Reglas del Sistema de Pagos Electrónicos Interbancarios (texto compilado), Regla 89a, third paragraph", "rests_on": "rule" } ], "exceptions": [ "Orders received in the last five consecutive minutes of the operating day that need returning may be returned in the first five minutes of the next one with no compensation owed.", "Where an indirect participant is in the chain the compensation is owed by it to its own customer, and the participant's duty is to verify under the Contrato de Servicios de Participación Indirecta that it pays." ], "applies_to": "SPEI in Mexico, in Mexican pesos: ordinary customer to customer transfer orders, low value orders, CoDi orders, Pagos Programados and the four return types, among the 94 direct participants Banco de México lists and the indirect participants they serve", "caveat": "The Reglas allocate paid compensation for missed deadlines and say nothing about loss from fraud, mistaken instructions or an insolvent counterparty. Those sit with the Convenio de Colaboración and the general law, and the Convenio is not public (mx-spei:refund).", "related": [ "pix:liability", "mx-spei:return" ], "basis": { "sources": "Reglas del SPEI 17a, 19a, 22a, 25a, 26a, 27a, 30a, 31a, 86a, 87a and 89a, read 2026-09-20.", "confidence": "high" }, "currency": { "effective_since": "2022-03-23", "effective_to": null, "effective_note": "Drafted 2026-09-20 in Orca Core form. The date is the day the Diario Oficial de la Federación published Circular 1/2022, which last set Reglas 86a and 87a and added the CoDi floor. Each Rule listed here carries its own date.", "source_edition": "Circular 14/2017, Reglas del Sistema de Pagos Electrónicos Interbancarios, texto compilado, published in the Diario Oficial de la Federación on 2017-07-04 and including the amendments made by Circulares 5/2018, 11/2018, 18/2018, 3/2019, 8/2019, 1/2022, 15/2022, 16/2022, 12/2023, 2/2025 and 9/2026, the last of them published in the DOF on 2026-06-17; PDF of 296 pages read in Spanish on 2026-09-20", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.banxico.org.mx/marco-normativo/normativa-emitida-por-el-banco-de-mexico/circular-14-2017/%7BA06FBFEE-06BB-F249-32FC-25B334B2A744%7D.pdf", "source_class": "authoritative_primary", "source_title": "Circular 14/2017, Reglas del Sistema de Pagos Electrónicos Interbancarios (texto compilado)", "checked_on": "2026-09-21", "checked_by": "mx-spei validator session, 2026-09-21", "notes": "Confirms Reglas 17a, 19a, 22a, 25a, 26a, 27a, 30a, 31a, 86a, 87a and 89a: the Administrador's release from liability, the paid compensation allocation between participants and customers, the Regla 87a formula and Regla 86a floor, the last five minutes exception, and the infrastructure failure notice and stop-taking-requests duties." } ] }, "rail_name": "SPEI (Mexico peso interbank electronic transfers)", "governing_authority": "Banco de México", "snapshot": "2026-09-20", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "mx-spei:limits", "id": "limits", "rail": "mx-spei", "kind": "rail-fact", "facet": "limits", "name": "Does SPEI cap a transfer, and what do its thresholds actually do?", "statement": "No maximum transfer amount appears anywhere in the 296 pages of the Reglas, and that is stated here as an absence rather than as a rule [Unverified]. What the Reglas do set are thresholds that switch obligations. One thousand five hundred UDIS, valued at 1 January of the year, marks an Orden de Transferencia de Bajo Valor and moves crediting to five seconds and returning to ten. Six thousand UDIS, per transfer or accumulated to one beneficiary account in a day, is the point at which a receiving participant may ask the Administrador for a longer crediting window while it runs extra checks. Three thousand customer accounts splits participants into classes with different deadlines and different instance obligations. And a non-bank participant that may not hold customer balances must sweep a customer out within two minutes once its balance passes a limit computed from its protection resources divided by its customer count. UDIS are an index unit, not pesos.", "details": [ { "label": "One thousand five hundred UDIS marks a low value order and switches the clocks", "value": "An Orden de Transferencia de Bajo Valor is one addressed to a credit institution, or sent or received by a Cámara de Compensación de Transferencias a Través de Dispositivos Móviles, for up to the equivalent of one thousand five hundred UDIS, valued at the official UDI value for 1 January of the year the order is issued. This is a threshold, not a cap: nothing stops a larger transfer, but a low value order must be credited in five seconds around the clock and returned in ten seconds in the daytime window instead of the ordinary thirty and sixty. The UDI is an index unit whose value changes, so an amount stated in UDIS is not an amount in pesos.", "citation": "Circular 14/2017, Reglas del Sistema de Pagos Electrónicos Interbancarios (texto compilado), Regla 2a, fracción XXXIV", "rests_on": "rule" }, { "label": "Six thousand UDIS is the point at which a receiver may ask for longer to run extra checks", "value": "Where a single transfer reaches six thousand UDIS, or where transfers to one beneficiary account in a single SPEI operating day add up to that figure, a receiving participant that decides under its internal processes to run validations beyond those the Reglas require may ask the Administrador, through the Dirección de Operación y Continuidad de Sistemas de Pagos e Infraestructuras de Mercados, for authorisation to credit later than the ordinary deadline, for a period of no more than six months. The request must record that the participant is in the course of automating those validations. Participants use the official UDI value for the first day of January of the calendar year. Again a threshold, not a cap.", "citation": "Circular 14/2017, Reglas del Sistema de Pagos Electrónicos Interbancarios (texto compilado), Regla 19a, fracción I, third paragraph", "rests_on": "rule" }, { "label": "Three thousand customer accounts splits participants into two classes", "value": "A participant that is a credit institution or an institution of electronic payment funds and that keeps at least three thousand demand deposit or electronic payment funds accounts, counted as Regla 15a directs, must connect to every SPEI instance on every operating day. One below that count connects only to the instance its transfer order set is assigned to, and must be able to connect to any other when the Administrador tells it to. The same figure changes the deadlines: a participant under three thousand accounts is outside the round the clock five second crediting window for low value orders and instead credits within five seconds between 06:00:00 and the close, and its return deadline for low value orders taken overnight is 06:00:10.", "citation": "Circular 14/2017, Reglas del Sistema de Pagos Electrónicos Interbancarios (texto compilado), Reglas 5a Bis, 15a, 19a, fracción II, and 25a, fracción III", "rests_on": "rule" }, { "label": "A non-bank participant that may not hold customer balances must sweep a customer out at a computed limit", "value": "A participant that is required to hold financial resources for the protection of paying customers, that takes customer money only to pass it on to accounts at other participants, and that under its own regulation may not keep a balance in its Cuentas de Clientes, must operate a per customer limit. Once a customer's balance passes it, the participant has two minutes to send the funds through SPEI to the beneficiary accounts the customer has nominated. The limit is not a fixed sum: it is the protection resources the participant holds under Regla 68a divided by its number of paying customers, and the participant reports that customer count to the Administrador every quarter. Where no such account has been agreed in advance, an incoming transfer is a mandatory return ground.", "citation": "Circular 14/2017, Reglas del Sistema de Pagos Electrónicos Interbancarios (texto compilado), Regla 70a, fracciones I and II, and Regla 23a, fracción VII", "rests_on": "rule" } ], "exceptions": [ "A participant may set its own transactional limits: the Guías expressly allow an entity to validate against them before sending, and those limits are the institution's, not SPEI's.", "The per customer sweep limit is not a stated figure at all; it is arithmetic over a participant's own protection resources and customer count, so it differs by participant and moves quarterly." ], "applies_to": "SPEI in Mexico, in Mexican pesos: ordinary customer to customer transfer orders, low value orders, CoDi orders, Pagos Programados and the four return types, among the 94 direct participants Banco de México lists and the indirect participants they serve", "caveat": "Every threshold on this rail is in UDIS, an index unit whose value changes and which is fixed for these purposes at its 1 January value. Recording any of them as an amount in pesos would be a false claim.", "related": [ "pix:limits" ], "basis": { "sources": "Reglas del SPEI 2a fracción XXXIV, 5a Bis, 15a, 19a, 23a fracción VII, 68a and 70a; Guías versión 1.1 section V.C; read 2026-09-20. That no maximum amount appears is an absence found by reading the compiled text and is marked [Unverified].", "confidence": "medium" }, "currency": { "effective_since": "2022-12-13", "effective_to": null, "effective_note": "Drafted 2026-09-20 in Orca Core form. The date is the day the Diario Oficial de la Federación published Circular 15/2022, which last set the low value threshold, the newest of the four thresholds this fact carries. Each Rule listed here carries its own date.", "source_edition": "Circular 14/2017, Reglas del Sistema de Pagos Electrónicos Interbancarios, texto compilado, published in the Diario Oficial de la Federación on 2017-07-04 and including the amendments made by Circulares 5/2018, 11/2018, 18/2018, 3/2019, 8/2019, 1/2022, 15/2022, 16/2022, 12/2023, 2/2025 and 9/2026, the last of them published in the DOF on 2026-06-17; PDF of 296 pages read in Spanish on 2026-09-20; Guías para la homologación de la experiencia de usuario en transferencias electrónicas de fondos a través de dispositivos móviles, versión 1.1, published 2026-08-28 and in force from 2026-12-14; PDF of 58 pages marked Uso Público read in Spanish on 2026-09-20", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.banxico.org.mx/marco-normativo/normativa-emitida-por-el-banco-de-mexico/circular-14-2017/%7BA06FBFEE-06BB-F249-32FC-25B334B2A744%7D.pdf", "source_class": "authoritative_primary", "source_title": "Circular 14/2017, Reglas del Sistema de Pagos Electrónicos Interbancarios (texto compilado)", "checked_on": "2026-09-21", "checked_by": "mx-spei validator session, 2026-09-21", "notes": "Confirms that no maximum transfer amount appears in the 296 page compiled text, stated as an absence, and that Reglas 2a fraccion XXXIV, 5a Bis, 15a, 19a, 23a fraccion VII and 70a set the four thresholds the fact lists." }, { "source_url": "https://www.banxico.org.mx/marco-normativo/normativa-emitida-por-el-banco-de-mexico/circular-14-2017/%7BFBF220A3-C5B8-268A-C57B-A00CD109BA63%7D.pdf", "source_class": "authoritative_primary", "source_title": "Guías para la homologación de la experiencia de usuario en transferencias electrónicas de fondos a través de dispositivos móviles, versión 1.1", "checked_on": "2026-09-21", "checked_by": "mx-spei validator session, 2026-09-21", "notes": "Confirms section V.C of the Guias mentions transactional limits previously defined by the user as a validation the entity may run, supporting the fact's note that a participant's own limit is the institution's, not SPEI's." } ] }, "rail_name": "SPEI (Mexico peso interbank electronic transfers)", "governing_authority": "Banco de México", "snapshot": "2026-09-20", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "mx-spei:messages", "id": "messages", "rail": "mx-spei", "kind": "rail-fact", "facet": "messages", "name": "Which messages carry a SPEI payment, and can an outsider read the format?", "statement": "Not the interbank format. SPEI uses Banco de México's own protocol: the Reglas nowhere name ISO 20022 and no ISO message name appears in the 296 pages. Every transfer order type and message format is in section 8 of the Manual, the instance assignment and the return cause catalogue in section 9, the CLABE structure in section 6, the credit confirmation in Apéndice D, the CEP link in Apéndice E and the CoDi advices in Apéndice AD, and the Manual is a document the Administrador makes available to participants only. The Aviso de Liquidación, the Confirmación de Abono and the CoDi processing advices are named in the Reglas and specified nowhere Orca can read. What is public is the customer facing edge: the Clave de Rastreo the sending participant assigns and the Referencia Numérica the customer chooses, both of which must be shown back to the customer; the Comprobante Electrónico de Pago and its batch service, whose input file is six comma separated fields per line, UTF-8 without a byte order mark, up to 500 lines, with the institution keys published on the service's own page; and the identifiers the Guías make the result screen show.", "details": [ { "label": "Every transfer order type, every message format and the CLABE structure are in the Manual, and it is not public", "value": "SPEI uses Banco de México's own message protocol. The Reglas nowhere name ISO 20022 and no ISO message name appears in the 296 pages. What they do is point at the Manual: Regla 5a makes participants send the order types defined in section 8 of the Manual through the instances section 9 assigns them; Reglas 24a, 26a, 28a and 29a all put the return formats in section 8; Regla 2a, fracción VIII, puts the CLABE structure in section 6; and Regla 2a, fracción XXX, defines the Manual as a document the Administrador prepares and makes available to Participantes. So the interbank format is unreadable from outside. What is public and citable is the customer facing edge: the Clave de Rastreo, the Referencia Numérica, the CEP and its batch service. The Aviso de Liquidación, the Confirmación de Abono and the CoDi processing advices are named in the Reglas but specified in the Manual, the last of them in Apéndice AD.", "citation": "Circular 14/2017, Reglas del Sistema de Pagos Electrónicos Interbancarios (texto compilado), Reglas 5a, 2a, fracciones VIII and XXX, 24a, 20a and 21a", "rests_on": "rule" }, { "label": "The numbered catalogue of return causes is in the Manual and is not public", "value": "When it sends a not credited return, the receiving participant must state the cause from among those marked as return causes in the catalogue in section 9 of the Manual de Operación del SPEI. Three things follow that a reader should be told plainly. The catalogue exists and is the operative list, because Regla 24a makes stating a cause from it part of the obligation. It is longer than the ten grounds Regla 23a names, because fracción VIII of that Regla makes a return ground of any further cause the catalogue marks as such. And it is not published: Regla 2a, fracción XXX, defines the Manual as a document the Administrador prepares and makes available to Participantes, and Regla 57a makes an applicant sign a unilateral confidentiality undertaking over all SPEI information the Administrador gives it before it may even file for admission. Orca therefore holds no mx-spei return codes, and a list of SPEI codes found on a vendor page is that vendor's mapping, not the authority's catalogue.", "citation": "Circular 14/2017, Reglas del Sistema de Pagos Electrónicos Interbancarios (texto compilado), Reglas 24a, 23a, fracción VIII, 2a, fracción XXX, and 57a, second paragraph", "rests_on": "rule" }, { "label": "The two identifiers a customer can see and quote", "value": "The Clave de Rastreo is alphanumeric data the sending participant assigns to each transfer order as Regla 14a directs, and it is what a customer quotes to trace a payment or pull its receipt. The Referencia Numérica is numeric data the paying customer, or an indirect paying customer through its indirect participant, puts on the Solicitud de Envío to identify the transfer. Both must be shown back to the customer under Regla 83a, the Clave de Rastreo in the same format the sending participant sent it in. Where an order is eliminated and the customer is allowed to submit the request again, the new order must carry a new Clave de Rastreo, and a Clave de Rastreo the same sending participant already used on that operation date is a mandatory return ground.", "citation": "Circular 14/2017, Reglas del Sistema de Pagos Electrónicos Interbancarios (texto compilado), Reglas 2a, fracciones IX and XL, 14a, 17a, 23a, fracción X, and 83a, fracción I, incisos f) and g)", "rests_on": "rule" }, { "label": "The public batch lookup for payment receipts, and the shape of its input file", "value": "Banco de México runs a batch service for generating between two and 500 Comprobantes Electrónicos de Pago at once, downloadable as PDF, XML or both inside a ZIP. The receipts must be for transfers between different SPEI participant institutions and for transfers made from 2018-03-16. The input is a plain text file, UTF-8 without a byte order mark, with one comma separated line per transfer carrying the transfer date as AAAA-MM-DD, the Clave de Rastreo, the sending institution key, the receiving institution key, the beneficiary account as CLABE, debit card number or mobile number, and the amount; the institution keys are published on the service's own list page. Each output file is named by the transfer date and the Clave de Rastreo, and a resumen.txt reports the outcome per line. A file that does not match the structure is rejected in whole.", "citation": "Guía de Operación para Usuarios del CEP-Servicio de Consulta por Lotes, sections 2, 3.1 and 4.3", "rests_on": "guidance" }, { "label": "No receipt exists until the receiving participant confirms the credit", "value": "A CEP is built from the Confirmación de Abono the receiving participant sends the Administrador after crediting, and the batch service states the first reason a receipt cannot be produced: the receiving institution has not yet sent that confirmation. The other two are that the transfer date, beneficiary account or amount does not match the Clave de Rastreo, and that the payment is in a state other than settled. So a settled but uncredited payment, which is the normal state of a payment about to be returned, has no CEP, and the absence of a receipt is not evidence that a payment did not settle. Regla 21a adds that the Administrador rejects confirmations that do not meet Apéndice D of the Manual and gives the receiving participant twenty four hours to correct and resend them.", "citation": "Guía de Operación para Usuarios del CEP-Servicio de Consulta por Lotes, section 4.3, the resumen.txt outcomes; Circular 14/2017, Reglas del Sistema de Pagos Electrónicos Interbancarios (texto compilado), Reglas 20a and 21a", "rests_on": "guidance" }, { "label": "A link to the Banco de México receipt must sit against every settled transfer within five minutes", "value": "Participants that have agreed with customers to operate through electronic channels must include, for every accepted transfer order and in every enquiry they offer on it, the electronic link built as Apéndice E of the Manual directs, so that the customer can look up the state of the order or, where it was credited, generate the Comprobante Electrónico de Pago. The link must be available within five minutes of the Administrador making the settlement advice available and must be kept for at least three months from settlement. Where the customer reaches the Banco de México portal through that link, the participant must supply into the portal the settlement date, the Clave de Rastreo or Referencia Numérica, the names of both participants from the current SPEI catalogue, the beneficiary account identifier and the amount.", "citation": "Circular 14/2017, Reglas del Sistema de Pagos Electrónicos Interbancarios (texto compilado), Regla 85a", "rests_on": "rule" }, { "label": "The result screen must carry the status, the Clave de Rastreo and a link to the CEP", "value": "The fourth stage is notification. The interface must show the state of the operation (sent, rejected, under review, among others), the amount, the payment concept and numeric reference where they apply, and the beneficiary's masked name, account identifier and institution. For an operation between institutions it must also show the Clave de Rastreo and a link for downloading the Comprobante Electrónico de Pago; for one inside a single institution, a folio or authorisation number. Separately, error, rejection and cancellation messages must be precise and clear, so that the customer is told plainly what happened.", "citation": "Guías para la homologación de la experiencia de usuario en transferencias electrónicas de fondos a través de dispositivos móviles, versión 1.1, section V.D, numerals 1 to 3, and section V.E, numeral 6", "rests_on": "rule" } ], "exceptions": [ "A settled but uncredited payment has no CEP at all, because a CEP is built from the receiving participant's Confirmación de Abono. That is the normal state of a payment about to be returned, so the absence of a receipt is not evidence the payment did not settle.", "For CLS operations Banco de México converts between SWIFT and the SPEI protocol, which is the only place a public source names another message standard, and the PFMI disclosure that says so is dated 2016-03-28.", "CEPs exist only for transfers made from 2018-03-16 and only between different participant institutions." ], "applies_to": "SPEI in Mexico, in Mexican pesos: ordinary customer to customer transfer orders, low value orders, CoDi orders, Pagos Programados and the four return types, among the 94 direct participants Banco de México lists and the indirect participants they serve", "caveat": "The most valuable thing an integrator would want from this facet, the message layouts and the numbered return causes, is exactly what Banco de México does not publish. This fact caps at medium for as long as that holds, and it will not be fixed by reading harder.", "related": [ "pix:messages", "mx-spei:return" ], "basis": { "sources": "Reglas del SPEI 2a fracciones VIII, IX, XXX and XL, 5a, 14a, 20a, 21a, 24a, 83a and 85a; Guía de Operación para Usuarios del CEP-Servicio de Consulta por Lotes, November 2025, sections 2, 3.1 and 4.3; Guías versión 1.1 section V.D; SPEI PFMI disclosure of 2016-03-28 on the SWIFT conversion for CLS; read 2026-09-20. That no ISO 20022 name appears in the Reglas is stated as an absence [Unverified].", "confidence": "medium" }, "currency": { "effective_since": "2022-03-23", "effective_to": null, "effective_note": "Drafted 2026-09-20 in Orca Core form. The date is the day the Diario Oficial de la Federación published Circular 1/2022, which moved the format and instance references into their current form. Each Rule listed here carries its own date, and the CEP lines carry the November 2025 edition of the batch service guide.", "source_edition": "Circular 14/2017, Reglas del Sistema de Pagos Electrónicos Interbancarios, texto compilado, published in the Diario Oficial de la Federación on 2017-07-04 and including the amendments made by Circulares 5/2018, 11/2018, 18/2018, 3/2019, 8/2019, 1/2022, 15/2022, 16/2022, 12/2023, 2/2025 and 9/2026, the last of them published in the DOF on 2026-06-17; PDF of 296 pages read in Spanish on 2026-09-20; Guía de Operación para Usuarios del CEP-Servicio de Consulta por Lotes, November 2025; PDF of 12 pages marked Uso Público read in Spanish on 2026-09-20; Guías para la homologación de la experiencia de usuario en transferencias electrónicas de fondos a través de dispositivos móviles, versión 1.1, published 2026-08-28 and in force from 2026-12-14; PDF of 58 pages marked Uso Público read in Spanish on 2026-09-20; Sistema de Pagos Electrónicos Interbancarios (SPEI), divulgación del cumplimiento y adopción de los Principios para las Infraestructuras del Mercado Financiero, disclosure date 2016-03-28; PDF of 41 pages read in Spanish on 2026-09-20", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.banxico.org.mx/marco-normativo/normativa-emitida-por-el-banco-de-mexico/circular-14-2017/%7BA06FBFEE-06BB-F249-32FC-25B334B2A744%7D.pdf", "source_class": "authoritative_primary", "source_title": "Circular 14/2017, Reglas del Sistema de Pagos Electrónicos Interbancarios (texto compilado)", "checked_on": "2026-09-21", "checked_by": "mx-spei validator session, 2026-09-21", "notes": "Confirms no ISO 20022 name appears in the compiled text, that Reglas 2a, 5a, 14a, 20a, 21a, 24a, 83a and 85a keep the message formats in the Manual while making the Clave de Rastreo, Referencia Numerica and CEP link public, and that the PFMI SWIFT to SPEI conversion for CLS is the only other message standard named." }, { "source_url": "https://www.banxico.org.mx/apps/dgspim/%7B14726DC9-C3C0-D197-26F0-7BAEACF905C3%7D.pdf", "source_class": "public_primary", "source_title": "Guía de Operación para Usuarios del CEP-Servicio de Consulta por Lotes", "checked_on": "2026-09-21", "checked_by": "mx-spei validator session, 2026-09-21", "notes": "Confirms sections 2, 3.1 and 4.3 describe the CEP batch service's input fields, output files and the three no-CEP outcomes the fact states." }, { "source_url": "https://www.banxico.org.mx/marco-normativo/normativa-emitida-por-el-banco-de-mexico/circular-14-2017/%7BFBF220A3-C5B8-268A-C57B-A00CD109BA63%7D.pdf", "source_class": "authoritative_primary", "source_title": "Guías para la homologación de la experiencia de usuario en transferencias electrónicas de fondos a través de dispositivos móviles, versión 1.1", "checked_on": "2026-09-21", "checked_by": "mx-spei validator session, 2026-09-21", "notes": "Confirms section V.D of the Guias sets the result screen identifiers the fact lists." }, { "source_url": "https://www.banxico.org.mx/sistemas-de-pago/d/%7B89B6CCF0-6070-7389-3DD5-B27AC4ECD9D1%7D.pdf", "source_class": "public_primary", "source_title": "SPEI, divulgación del cumplimiento y adopción de los Principios para las Infraestructuras del Mercado Financiero", "checked_on": "2026-09-21", "checked_by": "mx-spei validator session, 2026-09-21", "notes": "Confirms the PFMI disclosure is the source for the SWIFT to SPEI protocol conversion Banco de Mexico runs for CLS operations, dated 2016-03-28." } ] }, "rail_name": "SPEI (Mexico peso interbank electronic transfers)", "governing_authority": "Banco de México", "snapshot": "2026-09-20", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "mx-spei:participants", "id": "participants", "rail": "mx-spei", "kind": "rail-fact", "facet": "participants", "name": "Who can be a SPEI participant, and what does it take to get in?", "statement": "Four categories may act as participants: entities under federal financial regulation supervised by Banco de México, the CNBV, the CNSF or the CONSAR; agencies and entities of the federal public administration; Banco de México as trustee of the relevant trusts; and any institution operating an international foreign exchange settlement system that includes the peso, which is how CLS reaches SPEI. Qualifying is only the start: an applicant needs Banco de México's authorisation under Circular 13/2017, admission by the Administrador under Regla 64a and the contract Regla 65a requires, and before it may even file, a unilateral confidentiality undertaking over all SPEI information the Administrador gives it. The public list dated 2026-09-10 carries 94 direct participants in eleven categories, 46 of them banca múltiple and one of them the clearing house through which mobile number transfers reach SPEI. Class matters after admission too: three thousand customer accounts decides whether a participant must connect to every instance and which deadlines it works to. Indirect participation is its own regime in Reglas 9a Bis 1 to 9a Bis 10, with a contract that pushes the participant's obligations down. Participants pay a fixed monthly quota plus a per operation quota, with CoDi returns exempt.", "details": [ { "label": "Four categories of institution may act as a participant", "value": "Regla 56a admits entities subject to federal financial regulation and to supervision by Banco de México, the Comisión Nacional Bancaria y de Valores, the Comisión Nacional de Seguros y Fianzas or the Comisión Nacional del Sistema de Ahorro para el Retiro; agencies and entities of the federal public administration; Banco de México acting as trustee of the relevant trusts; and any institution outside the first category that operates an international foreign exchange settlement system with the peso among its currencies, which is how CLS reaches SPEI. Credit institution participants may send and receive CLS transfer orders through Banco de México.", "citation": "Circular 14/2017, Reglas del Sistema de Pagos Electrónicos Interbancarios (texto compilado), Reglas 56a, fracciones I to IV, 32a and 33a", "rests_on": "rule" }, { "label": "Three gates before an institution can operate: an authorisation, an admission and a contract", "value": "Meeting Regla 56a's categories is not enough. An applicant must also meet the requirements, terms and conditions the Reglas and the Manual set, obtain Banco de México's authorisation under Circular 13/2017, be admitted by the Administrador under Regla 64a, and sign the contract Regla 65a requires. The admission request goes to the Administrador alongside the Circular 13/2017 authorisation request, may be presented together through the Dirección de Operación y Continuidad de Sistemas de Pagos e Infraestructuras de Mercados, must be signed digitally by the applicant's chief executive or an officer no more than two levels below, and must come with the compliance reports Regla 62a requires.", "citation": "Circular 14/2017, Reglas del Sistema de Pagos Electrónicos Interbancarios (texto compilado), Reglas 4a, 56a, last paragraph, 57a, first paragraph, 62a, 64a and 65a", "rests_on": "rule" }, { "label": "Before it may even apply, an institution must sign a confidentiality undertaking over all SPEI information", "value": "Regla 57a requires an applicant, before presenting its admission request, to give the Administrador a unilateral confidentiality contract signed by its legal representative, on the clauses the Administrador makes available through the Dirección de Operación y Continuidad de Sistemas de Pagos e Infraestructuras de Mercados. Under it the applicant undertakes to keep strictly confidential all information relating to SPEI that the Administrador gives it, in any form, oral, written, graphic or electronic, to use it only for the purposes the Reglas provide, to give access only to the people needed to comply with the Reglas, to answer for its people's use of it, and to hold the Administrador harmless. This is why the Manual and everything in it stays outside Orca: the route to it runs through an undertaking Orca must not work around.", "citation": "Circular 14/2017, Reglas del Sistema de Pagos Electrónicos Interbancarios (texto compilado), Regla 57a, second paragraph", "rests_on": "rule" }, { "label": "94 direct participants at 2026-09-10, in eleven categories", "value": "Banco de México publishes the list of direct participants and updates it as the information changes. The list dated 2026-09-10 carries 94: 46 banca múltiple, 6 banca de desarrollo, 13 instituciones de fondos de pago electrónico, 9 casas de bolsa, 8 sociedades financieras populares, 4 transmisores de dinero, 4 sociedades cooperativas de ahorro y préstamo, 1 cámara de compensación, 1 administradora de fondos para el retiro, 1 fondo y fideicomiso and 1 depósito de valores. The single clearing house entry is the participant class through which mobile number transfers reach SPEI. Separate public lists cover the participants that offer indirect participation services and the indirect participants themselves, and neither was opened.", "citation": "Participantes directos en el SPEI, listado público, listado público updated 2026-09-10, all eleven category headings", "rests_on": "rule" }, { "label": "Three thousand customer accounts splits participants into two classes", "value": "A participant that is a credit institution or an institution of electronic payment funds and that keeps at least three thousand demand deposit or electronic payment funds accounts, counted as Regla 15a directs, must connect to every SPEI instance on every operating day. One below that count connects only to the instance its transfer order set is assigned to, and must be able to connect to any other when the Administrador tells it to. The same figure changes the deadlines: a participant under three thousand accounts is outside the round the clock five second crediting window for low value orders and instead credits within five seconds between 06:00:00 and the close, and its return deadline for low value orders taken overnight is 06:00:10.", "citation": "Circular 14/2017, Reglas del Sistema de Pagos Electrónicos Interbancarios (texto compilado), Reglas 5a Bis, 15a, 19a, fracción II, and 25a, fracción III", "rests_on": "rule" }, { "label": "Which instances a participant must connect to depends on its class and its account count", "value": "Each participant must process its transfer orders through the SPEI instance section 9 of the Manual assigns to the order set they belong to. A credit institution or an institution of electronic payment funds holding at least three thousand accounts, and any other participant that has told the Administrador under Apéndice G of the Manual that it chooses to, must connect to every instance on every operating day. Everyone else connects only to the instance its own order set needs, but must be able to connect to any other the moment the Administrador says so, and must still meet any connection duty a contingency imposes. Every participant must run one or more Aplicativos SPEI certified by the Administrador that guarantee those connections.", "citation": "Circular 14/2017, Reglas del Sistema de Pagos Electrónicos Interbancarios (texto compilado), Regla 5a Bis, fracciones I and II and the paragraphs that follow", "rests_on": "rule" }, { "label": "Indirect participation is a defined regime, and the contract pushes the Reglas down a level", "value": "Reglas 9a Bis 1 to 9a Bis 10 set out when a participant may provide Servicios de Participación Indirecta, which entities are excluded from receiving them, the requirements for providing them, the minimum content of the Contrato de Servicios de Participación Indirecta, the identification and validation the participant must perform on the indirect participant and on its indirect customers, the quarterly reports to the Administrador, and how the service is suspended in whole or in part and ended. The contract is the instrument that carries the participant's own obligations down to the indirect participant, including crediting its customers inside the participant's own deadlines and paying them the delay compensation, which Regla 86a then makes the participant verify.", "citation": "Circular 14/2017, Reglas del Sistema de Pagos Electrónicos Interbancarios (texto compilado), Reglas 9a Bis 1 to 9a Bis 10, and Regla 86a, fracciones I Bis and III Bis", "rests_on": "rule" }, { "label": "A fixed monthly quota plus a per operation quota, with CoDi returns exempt", "value": "Each participant pays the Administrador, by the tenth banking day of the following month, a fixed monthly quota that lets it send and receive any number of transfer orders so long as this does not harm the system's proper working. On top of that it pays a per operation quota counting the transfer requests it sent, the returns of not credited accepted orders it received whether extemporánea or not, the orders it sent to CLS, and the bytes it had retransmitted. Participants owe no quota at all on returns of CoDi orders not credited to customer accounts. The per operation tariffs are set by the Administrador and told to each participant by the last banking day of November of the year before.", "citation": "Circular 14/2017, Reglas del Sistema de Pagos Electrónicos Interbancarios (texto compilado), Regla 90a, first and second paragraphs", "rests_on": "rule" } ], "exceptions": [ "A participant operating an international foreign exchange settlement system including the peso is excused the Convenio de Colaboración that binds the others.", "The participant list changes without notice, so the count of 94 is a snapshot at 2026-09-10 and nothing more.", "Separate public lists cover the participants that offer indirect participation services and the indirect participants themselves, and neither was opened here." ], "applies_to": "SPEI in Mexico, in Mexican pesos: ordinary customer to customer transfer orders, low value orders, CoDi orders, Pagos Programados and the four return types, among the 94 direct participants Banco de México lists and the indirect participants they serve", "caveat": "Regla 57a's confidentiality undertaking is why this rail has no code directory. The route to the Manual, and so to the return cause catalogue, runs through an undertaking over all SPEI information, and Orca will not work around it.", "related": [ "pix:participants" ], "basis": { "sources": "Reglas del SPEI 4a, 5a Bis, 9a Bis 1 to 9a Bis 10, 15a, 32a, 33a, 56a, 57a, 62a, 64a, 65a, 86a and 90a; Participantes directos en el SPEI, listado público updated 2026-09-10; read 2026-09-20. Circular 13/2017 was not opened.", "confidence": "high" }, "currency": { "effective_since": "2026-09-10", "effective_to": null, "effective_note": "Drafted 2026-09-20 in Orca Core form. The date is the day Banco de México updated the public participant list, the newest source this fact rests on. Each Rule listed here carries its own date, and the Reglas lines date from Circular 14/2017 as amended.", "source_edition": "Circular 14/2017, Reglas del Sistema de Pagos Electrónicos Interbancarios, texto compilado, published in the Diario Oficial de la Federación on 2017-07-04 and including the amendments made by Circulares 5/2018, 11/2018, 18/2018, 3/2019, 8/2019, 1/2022, 15/2022, 16/2022, 12/2023, 2/2025 and 9/2026, the last of them published in the DOF on 2026-06-17; PDF of 296 pages read in Spanish on 2026-09-20; Participantes directos en el SPEI, listado público updated to 2026-09-10, 94 participants; PDF of 6 pages marked Uso Público read on 2026-09-20", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.banxico.org.mx/marco-normativo/normativa-emitida-por-el-banco-de-mexico/circular-14-2017/%7BA06FBFEE-06BB-F249-32FC-25B334B2A744%7D.pdf", "source_class": "authoritative_primary", "source_title": "Circular 14/2017, Reglas del Sistema de Pagos Electrónicos Interbancarios (texto compilado)", "checked_on": "2026-09-21", "checked_by": "mx-spei validator session, 2026-09-21", "notes": "Confirms Reglas 4a, 56a, 57a, 62a, 64a, 65a, 9a Bis 1 to 9a Bis 10, 86a and 90a set the four participant categories, the authorisation, admission, contract and confidentiality gates, the three thousand account threshold, indirect participation, and the quota structure the fact states." }, { "source_url": "https://www.banxico.org.mx/servicios/d/%7BC24C7DBC-9ABF-6F41-DA38-561CEB1401B3%7D.pdf", "source_class": "public_primary", "source_title": "Participantes directos en el SPEI, listado público", "checked_on": "2026-09-21", "checked_by": "mx-spei validator session, 2026-09-21", "notes": "Confirms the list dated 2026-09-10 carries 94 direct participants, 46 of them banca multiple." } ] }, "rail_name": "SPEI (Mexico peso interbank electronic transfers)", "governing_authority": "Banco de México", "snapshot": "2026-09-20", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "mx-spei:recall", "id": "recall", "rail": "mx-spei", "kind": "rail-fact", "facet": "recall", "name": "Can a sender pull a SPEI payment back?", "statement": "Only before it settles. The sending participant may instruct the Administrador to cancel an order it has already sent, through the instance it sent it on, and cancellation is possible only while SPEI has not settled the order. Once settlement has happened and the settlement advice is out, the order is an Orden de Transferencia Aceptada por SPEI and irrevocable in law, so no instruction from the sending side reaches it. After that, money returns only as a new transfer order of a return type sent by the receiving side: because the receiving participant must return it on one of the Regla 23a grounds, because the beneficiary agrees to send it back, or through the Convenio de Colaboración where the payer never instructed the payment at all. The customer has no recall right of any kind; the only lever is the participant's cancellation instruction, and only in the seconds before settlement.", "details": [ { "label": "A sent order can be cancelled only while it is unsettled, and there is no recall after that", "value": "The sending participant may send the Administrador instructions to cancel transfer orders it has already sent, through the instance it sent them on. Orders may be cancelled only while SPEI has not settled them under Regla 18a. Once the order is settled and the settlement advice is out it is an Orden de Transferencia Aceptada por SPEI and article 11 of the Ley de Sistemas de Pagos makes it irrevocable, so no instruction from the sender can pull it back. After that point money returns only as a new transfer order of a return type sent by the receiving side.", "citation": "Circular 14/2017, Reglas del Sistema de Pagos Electrónicos Interbancarios (texto compilado), Regla 17a, third paragraph, and Regla 18a", "rests_on": "rule" }, { "label": "Accepted orders, their netting and their settlement are firm, irrevocable, enforceable and effective against third parties", "value": "Ley de Sistemas de Pagos article 11 gives accepted transfer orders, their compensación and their liquidación, and every act the system's internal rules require to complete them, the four part legal standard of being firm, irrevocable, enforceable and effective against third parties. Compensación here is the statutory netting of article 2, fracción II, the replacement of the rights and obligations from transfer orders by a single net claim, not the delay payment the Reglas separately call compensación. Creditors and insolvency bodies keep whatever claims for damages the general law gives them against whoever is answerable; what they cannot do is unwind the settlement.", "citation": "Ley de Sistemas de Pagos, article 11, first and third paragraphs, and article 2, fracción II", "rests_on": "law" }, { "label": "Ten grounds on which the receiving participant must return a payment it could not credit", "value": "Regla 23a obliges the receiving participant to send a new transfer order of the not credited return type in any of ten cases: the accepted order's information does not meet section 8 of the Manual; the beneficiary's Cuenta del Cliente, or the Cuenta del Cliente Indirecto at an indirect participant it serves, does not exist; the order is identified as presumed fraudulent under the Convenio de Colaboración para la Protección del Cliente Emisor; a competent judicial or administrative authority has stopped that account receiving funds; the order is of a type section 9 of the Manual marks optional and the participant has told the Administrador it will not take those; a non-scheduled payment reaches the participant's Cuenta Alterna del SPEI, other than a devolución another participant sent from its own alternate account; no sweep account was agreed in advance with the customer for the Regla 70a per customer limit; crediting is impossible for any further cause section 9 of the Manual marks as a return cause, in addition to the ones the Regla itself names; the order is a CoDi order outside the cases Regla 9a Bis permits; or the Clave de Rastreo is one the same sending participant already used on that SPEI operation date. These are grounds, not codes, and they are not numbered in the Reglas.", "citation": "Circular 14/2017, Reglas del Sistema de Pagos Electrónicos Interbancarios (texto compilado), Regla 23a, fracciones I to X", "rests_on": "rule" }, { "label": "A beneficiary who does not recognise a credited payment may instruct its return, within thirty seconds", "value": "Where a Cliente Beneficiario does not recognise an accepted order already credited to its account, the receiving participant must let it send the money back by presenting a Solicitud de Envío for a transfer order of the credited return type, in the format section 8 of the Manual sets. The participant must send that order no later than thirty seconds after receiving the request, and four seconds where it is a CoDi order. The participant must also send a credited return on its own, without the beneficiary asking, in two cases: where applying the Convenio de Colaboración para la Protección del Cliente Emisor determines that the funds must go back, and where it received a CoDi order, credited it, and did not send the Administrador the processing advice confirming the credit, in which case the deadline is eight seconds from the settlement advice. This is the only return on the rail a customer can start.", "citation": "Circular 14/2017, Reglas del Sistema de Pagos Electrónicos Interbancarios (texto compilado), Reglas 28a and 30a, first and third paragraphs", "rests_on": "rule" }, { "label": "Participants must enter into a fraud collaboration agreement, and Regla 43a sets what it must contain", "value": "Participants must enter into a Convenio de Colaboración para la Protección de Clientes Emisores setting out the procedure for presenting support requests to receiving participants, so as to protect paying customers, direct and indirect, where accepted transfer orders are processed that those customers did not ask for. They must obtain Banco de México's authorisation before entering into it or amending it, though not for a new participant joining one already made, and the draft they submit must contain at least: who is signing; how receiving participants will handle support requests, keep the evidence of receipt and follow them up; the criteria and times for deciding whether to accept or reject one; how the beneficiary may be stopped from taking the funds and for how long, subject to the CNBV's own rules; how the funds are released to the beneficiary or handed to the sending participant for the paying customer, which must involve confirming the order with that customer; the mechanism for returning the funds, and the obligation to send a credited return under Reglas 28a or 29a where the participants have enough to presume a fraudulent operation; when an order counts as possibly fraudulent and the obligation to return it as a not credited return under Regla 24a; and how responsibilities and disputes between participants are settled. A participant that operates an international foreign exchange settlement system including the peso is not required to join. The Convenio itself is not published, so Orca states the delegation and the required contents and stops there.", "citation": "Circular 14/2017, Reglas del Sistema de Pagos Electrónicos Interbancarios (texto compilado), Regla 43a, fracciones I to VIII", "rests_on": "rule" } ], "exceptions": [ "An order the Administrador eliminates unsettled needs no recall: it never settled, and the sending participant must tell its customer within ten seconds (mx-spei:settlement)." ], "applies_to": "SPEI in Mexico, in Mexican pesos: ordinary customer to customer transfer orders, low value orders, CoDi orders, Pagos Programados and the four return types, among the 94 direct participants Banco de México lists and the indirect participants they serve", "caveat": "Cancellation is not a recall. It reaches an order that has not yet settled, and on a system that averaged 1.9 seconds to settle in 2016 the window is very short.", "related": [ "mx-spei:finality", "pix:recall" ], "basis": { "sources": "Reglas del SPEI 17a, 18a, 23a, 28a and 43a; Ley de Sistemas de Pagos article 11; read 2026-09-20.", "confidence": "high" }, "currency": { "effective_since": "2022-03-23", "effective_to": null, "effective_note": "Drafted 2026-09-20 in Orca Core form. The date is the day the Diario Oficial de la Federación published Circular 1/2022, which last set the cancellation paragraph of Regla 17a. Each Rule listed here carries its own date.", "source_edition": "Circular 14/2017, Reglas del Sistema de Pagos Electrónicos Interbancarios, texto compilado, published in the Diario Oficial de la Federación on 2017-07-04 and including the amendments made by Circulares 5/2018, 11/2018, 18/2018, 3/2019, 8/2019, 1/2022, 15/2022, 16/2022, 12/2023, 2/2025 and 9/2026, the last of them published in the DOF on 2026-06-17; PDF of 296 pages read in Spanish on 2026-09-20; Ley de Sistemas de Pagos, new law published in the Diario Oficial de la Federación on 2002-12-12, last reform published on 2025-11-14; PDF of 14 pages from the Cámara de Diputados read in Spanish on 2026-09-20", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.banxico.org.mx/marco-normativo/normativa-emitida-por-el-banco-de-mexico/circular-14-2017/%7BA06FBFEE-06BB-F249-32FC-25B334B2A744%7D.pdf", "source_class": "authoritative_primary", "source_title": "Circular 14/2017, Reglas del Sistema de Pagos Electrónicos Interbancarios (texto compilado)", "checked_on": "2026-09-21", "checked_by": "mx-spei validator session, 2026-09-21", "notes": "Confirms Reglas 17a, 18a, 23a, 28a and 43a: cancellation is possible only before settlement, an accepted order is irrevocable after, and money returns afterward only as a new return order started by the receiving side or through the Convenio." }, { "source_url": "https://www.diputados.gob.mx/LeyesBiblio/pdf/LSP.pdf", "source_class": "authoritative_primary", "source_title": "Ley de Sistemas de Pagos", "checked_on": "2026-09-21", "checked_by": "mx-spei validator session, 2026-09-21", "notes": "Confirms article 11 makes accepted transfer orders firm, irrevocable, enforceable and effective against third parties, supporting the fact's claim that nothing from the sending side reaches a settled order." } ] }, "rail_name": "SPEI (Mexico peso interbank electronic transfers)", "governing_authority": "Banco de México", "snapshot": "2026-09-20", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "mx-spei:refund", "id": "refund", "rail": "mx-spei", "kind": "rail-fact", "facet": "refund", "name": "If a payer did not instruct a SPEI payment, how does the money come back?", "statement": "Nothing in the Reglas gives a payer a unilateral right to a refund of a settled, credited payment. The single route is an agreement among the participants that Banco de México requires but does not publish. Regla 43a makes participants enter into a Convenio de Colaboración para la Protección de Clientes Emisores, with Banco de México's prior authorisation, under which a sending participant presents a support request to the receiving participant on behalf of a customer whose account was debited for a transfer it did not ask for. Regla 43a sets what the Convenio must contain: how requests are handled, evidenced and followed up, the criteria and times for accepting or rejecting one, how and for how long the beneficiary can be stopped from taking the funds subject to CNBV rules, how the funds are released or handed back, the mechanism for returning them to the paying customer, when a transfer counts as possibly fraudulent, and how disputes between participants are settled. Where the participants have enough to presume fraud, the receiving participant must send a credited return under Reglas 28a or 29a. The Convenio's own text is not public, and it may set shorter deadlines than Regla 30a, which then govern.", "details": [ { "label": "Participants must enter into a fraud collaboration agreement, and Regla 43a sets what it must contain", "value": "Participants must enter into a Convenio de Colaboración para la Protección de Clientes Emisores setting out the procedure for presenting support requests to receiving participants, so as to protect paying customers, direct and indirect, where accepted transfer orders are processed that those customers did not ask for. They must obtain Banco de México's authorisation before entering into it or amending it, though not for a new participant joining one already made, and the draft they submit must contain at least: who is signing; how receiving participants will handle support requests, keep the evidence of receipt and follow them up; the criteria and times for deciding whether to accept or reject one; how the beneficiary may be stopped from taking the funds and for how long, subject to the CNBV's own rules; how the funds are released to the beneficiary or handed to the sending participant for the paying customer, which must involve confirming the order with that customer; the mechanism for returning the funds, and the obligation to send a credited return under Reglas 28a or 29a where the participants have enough to presume a fraudulent operation; when an order counts as possibly fraudulent and the obligation to return it as a not credited return under Regla 24a; and how responsibilities and disputes between participants are settled. A participant that operates an international foreign exchange settlement system including the peso is not required to join. The Convenio itself is not published, so Orca states the delegation and the required contents and stops there.", "citation": "Circular 14/2017, Reglas del Sistema de Pagos Electrónicos Interbancarios (texto compilado), Regla 43a, fracciones I to VIII", "rests_on": "rule" }, { "label": "Where the Convenio sets shorter return deadlines than the Reglas, the Convenio's deadlines govern", "value": "Regla 30a's own deadlines for returning a credited transfer, thirty seconds from the beneficiary's request and the four and eight second CoDi variants, give way where the participants have agreed shorter ones in the Convenio de Colaboración para la Protección del Cliente Emisor. The receiving participant must then apply the agreed deadlines. Because the Convenio is not published, the deadlines that actually bind a participant on this path may be shorter than the ones the Reglas state, and Orca cannot say by how much.", "citation": "Circular 14/2017, Reglas del Sistema de Pagos Electrónicos Interbancarios (texto compilado), Regla 30a, last paragraph", "rests_on": "rule" }, { "label": "A beneficiary who does not recognise a credited payment may instruct its return, within thirty seconds", "value": "Where a Cliente Beneficiario does not recognise an accepted order already credited to its account, the receiving participant must let it send the money back by presenting a Solicitud de Envío for a transfer order of the credited return type, in the format section 8 of the Manual sets. The participant must send that order no later than thirty seconds after receiving the request, and four seconds where it is a CoDi order. The participant must also send a credited return on its own, without the beneficiary asking, in two cases: where applying the Convenio de Colaboración para la Protección del Cliente Emisor determines that the funds must go back, and where it received a CoDi order, credited it, and did not send the Administrador the processing advice confirming the credit, in which case the deadline is eight seconds from the settlement advice. This is the only return on the rail a customer can start.", "citation": "Circular 14/2017, Reglas del Sistema de Pagos Electrónicos Interbancarios (texto compilado), Reglas 28a and 30a, first and third paragraphs", "rests_on": "rule" }, { "label": "A credited return sent on a later operating day is the extemporánea type", "value": "Where the receiving participant does not send the credited return on the same SPEI operating day on which it received the original accepted order, any order it sends on a later day must be of the devolución extemporánea of a transfer credited to a customer account type, in the format section 8 of the Manual sets. Regla 86a, fracción III, then makes the amount the original plus the Regla 87a compensation, as it does for the not credited variant.", "citation": "Circular 14/2017, Reglas del Sistema de Pagos Electrónicos Interbancarios (texto compilado), Regla 29a, and Regla 86a, fracción III", "rests_on": "rule" } ], "exceptions": [ "A participant that operates an international foreign exchange settlement system including the peso is not required to join the Convenio.", "Where the receiving participant catches a presumed fraudulent transfer before crediting it, the money goes back as a not credited return under Regla 24a instead, on that family's much shorter clock (mx-spei:return)." ], "applies_to": "SPEI in Mexico, in Mexican pesos: ordinary customer to customer transfer orders, low value orders, CoDi orders, Pagos Programados and the four return types, among the 94 direct participants Banco de México lists and the indirect participants they serve", "caveat": "Orca states the delegation and the required contents of the Convenio and stops there. Whether a given support request succeeds, how long a beneficiary's funds can be frozen, and what the actual deadlines are all rest on a document Orca does not hold.", "related": [ "pix:refund", "mx-spei:return" ], "basis": { "sources": "Reglas del SPEI 23a fracción III, 28a, 29a, 30a, 43a and 44a, read 2026-09-20. The Convenio itself is approved by Banco de México but not published and was not consulted.", "confidence": "medium" }, "currency": { "effective_since": "2025-02-21", "effective_to": null, "effective_note": "Drafted 2026-09-20 in Orca Core form. The date is the day the Diario Oficial de la Federación published Circular 2/2025, which last amended Regla 43a. Each Rule listed here carries its own date.", "source_edition": "Circular 14/2017, Reglas del Sistema de Pagos Electrónicos Interbancarios, texto compilado, published in the Diario Oficial de la Federación on 2017-07-04 and including the amendments made by Circulares 5/2018, 11/2018, 18/2018, 3/2019, 8/2019, 1/2022, 15/2022, 16/2022, 12/2023, 2/2025 and 9/2026, the last of them published in the DOF on 2026-06-17; PDF of 296 pages read in Spanish on 2026-09-20", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.banxico.org.mx/marco-normativo/normativa-emitida-por-el-banco-de-mexico/circular-14-2017/%7BA06FBFEE-06BB-F249-32FC-25B334B2A744%7D.pdf", "source_class": "authoritative_primary", "source_title": "Circular 14/2017, Reglas del Sistema de Pagos Electrónicos Interbancarios (texto compilado)", "checked_on": "2026-09-21", "checked_by": "mx-spei validator session, 2026-09-21", "notes": "Confirms Reglas 43a, 28a, 29a and 30a: the Convenio de Colaboracion is the sole route back for a payment the payer did not instruct, its required contents match the fact, a presumed fraudulent transfer routes to a credited return under 28a or 29a, and the Convenio's own text is not public and may set shorter deadlines than Regla 30a." } ] }, "rail_name": "SPEI (Mexico peso interbank electronic transfers)", "governing_authority": "Banco de México", "snapshot": "2026-09-20", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "mx-spei:return", "id": "return", "rail": "mx-spei", "kind": "rail-fact", "facet": "return", "name": "Can a SPEI payment be returned, who returns it, and how fast?", "statement": "A return on SPEI is a new transfer order sent by the receiving side, not a reversal, and the clock runs in seconds. Two families. Where the payment was not credited to a customer account, the receiving participant must return it on any of ten grounds in Regla 23a, within sixty seconds of the settlement advice, or ten seconds for a low value order in the daytime window, eight seconds for a CoDi order at any hour, and by 06:00:10 or 06:01:00 for orders taken overnight; participant to participant orders are exempt. The sending participant then credits its own customer within five seconds, four for CoDi, and tells the customer the cause within five seconds of crediting. Where the payment was credited, the beneficiary may instruct a return and the receiving participant must send it within thirty seconds of being asked, four for CoDi; the sending participant credits within thirty seconds. Missing a deadline changes the order type to the extemporánea variant and adds the Regla 87a compensation to the amount returned. A return eliminated without settling must be sent again on its own clock. The numbered catalogue of return causes is in section 9 of the Manual de Operación del SPEI, which Banco de México gives only to participants, so Orca holds no SPEI return codes.", "details": [ { "label": "Ten grounds on which the receiving participant must return a payment it could not credit", "value": "Regla 23a obliges the receiving participant to send a new transfer order of the not credited return type in any of ten cases: the accepted order's information does not meet section 8 of the Manual; the beneficiary's Cuenta del Cliente, or the Cuenta del Cliente Indirecto at an indirect participant it serves, does not exist; the order is identified as presumed fraudulent under the Convenio de Colaboración para la Protección del Cliente Emisor; a competent judicial or administrative authority has stopped that account receiving funds; the order is of a type section 9 of the Manual marks optional and the participant has told the Administrador it will not take those; a non-scheduled payment reaches the participant's Cuenta Alterna del SPEI, other than a devolución another participant sent from its own alternate account; no sweep account was agreed in advance with the customer for the Regla 70a per customer limit; crediting is impossible for any further cause section 9 of the Manual marks as a return cause, in addition to the ones the Regla itself names; the order is a CoDi order outside the cases Regla 9a Bis permits; or the Clave de Rastreo is one the same sending participant already used on that SPEI operation date. These are grounds, not codes, and they are not numbered in the Reglas.", "citation": "Circular 14/2017, Reglas del Sistema de Pagos Electrónicos Interbancarios (texto compilado), Regla 23a, fracciones I to X", "rests_on": "rule" }, { "label": "The numbered catalogue of return causes is in the Manual and is not public", "value": "When it sends a not credited return, the receiving participant must state the cause from among those marked as return causes in the catalogue in section 9 of the Manual de Operación del SPEI. Three things follow that a reader should be told plainly. The catalogue exists and is the operative list, because Regla 24a makes stating a cause from it part of the obligation. It is longer than the ten grounds Regla 23a names, because fracción VIII of that Regla makes a return ground of any further cause the catalogue marks as such. And it is not published: Regla 2a, fracción XXX, defines the Manual as a document the Administrador prepares and makes available to Participantes, and Regla 57a makes an applicant sign a unilateral confidentiality undertaking over all SPEI information the Administrador gives it before it may even file for admission. Orca therefore holds no mx-spei return codes, and a list of SPEI codes found on a vendor page is that vendor's mapping, not the authority's catalogue.", "citation": "Circular 14/2017, Reglas del Sistema de Pagos Electrónicos Interbancarios (texto compilado), Reglas 24a, 23a, fracción VIII, 2a, fracción XXX, and 57a, second paragraph", "rests_on": "rule" }, { "label": "Sixty seconds from the settlement advice, with six named exceptions in seconds and clock times", "value": "The general deadline for a not credited return is sixty seconds from the moment the Administrador makes the settlement advice for the original order available. Six cases fall outside it. An order of the participant to participant type has no deadline under this Regla. An order received by a participant that is neither a credit institution nor a mobile transfer clearing house between the SPEI opening time and 05:59:00 of the operating day is returned by 06:01:00 that day. A low value order received by a credit institution or a mobile transfer clearing house is returned within ten seconds of the settlement advice, and that ten second window applies only between 06:00:00 and 17:59:50; for the period from 17:59:51 to 05:59:59 the smaller participants named in that fracción return by 06:00:10 of the following banking day. A Pago Programado is returned by 06:00:10 of the operating day. An order other than a Pago Programado received in the Cuenta Alterna del SPEI is returned by 06:01:00 where it arrived before 06:00:00 and by the SPEI close where it arrived after. An order above one thousand five hundred UDIS received by a credit institution or a mobile transfer clearing house between the opening time and 05:59:59 is returned by 06:00:10. A CoDi order is returned within eight seconds, twenty four hours a day every day of the year, and the receiving participant must also send the Administrador a processing advice reporting the return within ten seconds of the settlement advice, in the form Apéndice AD of the Manual sets.", "citation": "Circular 14/2017, Reglas del Sistema de Pagos Electrónicos Interbancarios (texto compilado), Regla 25a, first paragraph and fracciones I to VII", "rests_on": "rule" }, { "label": "A late return becomes the extemporánea type and its amount must include the delay compensation", "value": "Missing the applicable deadline does not simply make a return late. Where the receiving participant sends the return on a SPEI operating day later than the one on which it received the original order, it must send a different transfer order type, the devolución extemporánea of a transfer not credited to a customer account, in the format section 8 of the Manual sets, and the amount must be the original amount plus the compensation Regla 87a computes. A record that treats the extemporánea return as the same message sent later is wrong: it is another type, for another amount.", "citation": "Circular 14/2017, Reglas del Sistema de Pagos Electrónicos Interbancarios (texto compilado), Reglas 26a and 24a, fracción II", "rests_on": "rule" }, { "label": "The sending participant credits its customer within five seconds of the return settling, four for CoDi", "value": "When the settlement advice for a not credited return or its extemporánea variant reaches the participant that sent the original order, it has five seconds to credit that amount to the Cuenta del Cliente of the customer who made the request, and four seconds where the order was a CoDi order. Where the payment came through an indirect participant, the participant must make sure the indirect participant credits its own customer inside the same window. Where it cannot credit at all, it must not generate another return of the return, and must instead make the funds available for withdrawal at a counter or for transfer to another account the customer names.", "citation": "Circular 14/2017, Reglas del Sistema de Pagos Electrónicos Interbancarios (texto compilado), Regla 27a, first, second, third and fourth paragraphs", "rests_on": "rule" }, { "label": "The paying customer must be told the money is back and why, within five seconds of the credit", "value": "Having credited a return or an extemporánea return, the sending participant must tell the customer who made the request, free of charge, through the channel the request came in on and the additional channel they agreed, that the funds are back in the account and what the receiving participant gave as the cause. The deadline is five seconds from the credit. The cause the customer sees is the one the receiving participant stated from the catalogue in section 9 of the Manual, which Orca does not hold, so Orca cannot say what wording or code the customer is shown.", "citation": "Circular 14/2017, Reglas del Sistema de Pagos Electrónicos Interbancarios (texto compilado), Regla 27a, last paragraph", "rests_on": "rule" }, { "label": "A beneficiary who does not recognise a credited payment may instruct its return, within thirty seconds", "value": "Where a Cliente Beneficiario does not recognise an accepted order already credited to its account, the receiving participant must let it send the money back by presenting a Solicitud de Envío for a transfer order of the credited return type, in the format section 8 of the Manual sets. The participant must send that order no later than thirty seconds after receiving the request, and four seconds where it is a CoDi order. The participant must also send a credited return on its own, without the beneficiary asking, in two cases: where applying the Convenio de Colaboración para la Protección del Cliente Emisor determines that the funds must go back, and where it received a CoDi order, credited it, and did not send the Administrador the processing advice confirming the credit, in which case the deadline is eight seconds from the settlement advice. This is the only return on the rail a customer can start.", "citation": "Circular 14/2017, Reglas del Sistema de Pagos Electrónicos Interbancarios (texto compilado), Reglas 28a and 30a, first and third paragraphs", "rests_on": "rule" }, { "label": "A credited return sent on a later operating day is the extemporánea type", "value": "Where the receiving participant does not send the credited return on the same SPEI operating day on which it received the original accepted order, any order it sends on a later day must be of the devolución extemporánea of a transfer credited to a customer account type, in the format section 8 of the Manual sets. Regla 86a, fracción III, then makes the amount the original plus the Regla 87a compensation, as it does for the not credited variant.", "citation": "Circular 14/2017, Reglas del Sistema de Pagos Electrónicos Interbancarios (texto compilado), Regla 29a, and Regla 86a, fracción III", "rests_on": "rule" }, { "label": "The sending participant credits its customer within thirty seconds of the credited return settling, four for CoDi", "value": "When the settlement advice for a credited return reaches the participant that sent the original order, it has thirty seconds to credit that amount to the Cuenta del Cliente of the customer who made the original request, and four seconds where the order was a CoDi order. Where the payment came through an indirect participant the same window applies to crediting the indirect customer. Where it cannot credit, it must not send the money back again and must make it available for withdrawal at a counter or for transfer to another account the customer names, and it must tell the customer of the credit within five seconds of making it.", "citation": "Circular 14/2017, Reglas del Sistema de Pagos Electrónicos Interbancarios (texto compilado), Regla 31a, first, second, third and fourth paragraphs and the last paragraph", "rests_on": "rule" }, { "label": "A return that was eliminated without settling must be sent again, on one of two clocks", "value": "Where a participant sent a return under Reglas 23a and 24a, credited or not, late or not, and the Administrador then tells it that return was eliminated without settling, it must send a fresh return. If the elimination was because the participant that is to receive the return had disconnected from the instance, the fresh return goes within five seconds of the Administrador's notice that the connection is back, or, if no such notice comes, within sixty minutes of the elimination notice; it may not be sent to a different instance from the one the original accepted order was processed through. If the elimination was because the sender's own Cuenta del SPEI for that instance was short, the fresh return goes within five seconds of the elimination notice.", "citation": "Circular 14/2017, Reglas del Sistema de Pagos Electrónicos Interbancarios (texto compilado), Regla 25a Bis, fracciones I and II", "rests_on": "rule" }, { "label": "A return goes back through the instance the original came in on", "value": "SPEI is not one queue. It runs several Instancias del SPEI, each a processing component with its own Cuenta del SPEI, and section 9 of the Manual assigns each set of transfer order types to an instance. A not credited return must be sent through the same instance the receiving participant received the original order through. The same holds for an extemporánea return of either family, except in the cases section 5.16.4 of the Manual allows, where it may go through any instance. So a statement about a participant's SPEI balance is wrong on its face: there is one balance per instance.", "citation": "Circular 14/2017, Reglas del Sistema de Pagos Electrónicos Interbancarios (texto compilado), Reglas 24a, 26a, second paragraph, 30a, second paragraph, and 2a, fracción XXVIII Bis", "rests_on": "rule" } ], "exceptions": [ "Orders arriving in the last five consecutive minutes of the operating day may be returned in the first five minutes of the next one, and no compensation is owed for that.", "Where the Convenio de Colaboración sets shorter deadlines than Regla 30a for a credited return, the Convenio's deadlines govern, and the Convenio is not published.", "A return may itself fail to settle and be eliminated, in which case Regla 25a Bis sets the retry rather than treating the obligation as discharged." ], "applies_to": "SPEI in Mexico, in Mexican pesos: ordinary customer to customer transfer orders, low value orders, CoDi orders, Pagos Programados and the four return types, among the 94 direct participants Banco de México lists and the indirect participants they serve", "caveat": "The ten grounds in Regla 23a are not the code list and must never be presented as one or numbered. Regla 24a makes the receiving participant state the cause from a numbered catalogue in section 9 of the Manual, and fracción VIII of Regla 23a makes that catalogue strictly longer than the Regla. Orca does not hold it and holds no mx-spei reason codes. A numbered list of SPEI codes on a vendor page is that vendor's mapping, not Banco de México's catalogue.", "related": [ "pix:return", "mx-spei:refund", "mx-spei:liability" ], "basis": { "sources": "Reglas del SPEI 23a, 24a, 25a, 25a Bis, 26a, 27a, 28a, 29a, 30a, 31a, 86a and 2a fracciones XXX and XXVIII Bis, read 2026-09-20. The catalogue in section 9 of the Manual was not consulted and is not to be sought through third parties.", "confidence": "high" }, "currency": { "effective_since": "2022-03-23", "effective_to": null, "effective_note": "Drafted 2026-09-20 in Orca Core form. The date is the day the Diario Oficial de la Federación published Circular 1/2022, which rewrote most of the return chain, including the instance rules and the CoDi deadlines. Each Rule listed here carries its own date.", "source_edition": "Circular 14/2017, Reglas del Sistema de Pagos Electrónicos Interbancarios, texto compilado, published in the Diario Oficial de la Federación on 2017-07-04 and including the amendments made by Circulares 5/2018, 11/2018, 18/2018, 3/2019, 8/2019, 1/2022, 15/2022, 16/2022, 12/2023, 2/2025 and 9/2026, the last of them published in the DOF on 2026-06-17; PDF of 296 pages read in Spanish on 2026-09-20", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.banxico.org.mx/marco-normativo/normativa-emitida-por-el-banco-de-mexico/circular-14-2017/%7BA06FBFEE-06BB-F249-32FC-25B334B2A744%7D.pdf", "source_class": "authoritative_primary", "source_title": "Circular 14/2017, Reglas del Sistema de Pagos Electrónicos Interbancarios (texto compilado)", "checked_on": "2026-09-21", "checked_by": "mx-spei validator session, 2026-09-21", "notes": "Confirms Reglas 23a to 31a, 86a and 2a fracciones XXX and XXVIII Bis: the two return families, their grounds, deadlines, extemporanea variants and crediting windows, the retry rule in Regla 25a Bis, the same-instance rule, and that the numbered cause catalogue sits in section 9 of the Manual and is not public." } ] }, "rail_name": "SPEI (Mexico peso interbank electronic transfers)", "governing_authority": "Banco de México", "snapshot": "2026-09-20", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "mx-spei:settlement", "id": "settlement", "rail": "mx-spei", "kind": "rail-fact", "facet": "settlement", "name": "How does a SPEI payment settle, and in whose money?", "statement": "The Administrador validates each order automatically, then settles it out of the balance in the sending participant's Cuenta del SPEI for the instance the order was sent to, weighing that balance against the orders still pending and the priority marked on the order, through a process set out in section 4 of the Manual that Orca does not hold. Settlement is in central bank money and there are no overdrafts. Participants fund a Cuenta del SPEI from their SIAC-BANXICO or DALÍ account or from incoming SPEI credits, and balances are swept out at the close. SPEI is not one queue: several instances run in parallel, each with its own account, and which order types go to which instance is in section 9 of the Manual. An order that cannot settle is eliminated rather than held indefinitely. The only public description of the mechanics is Banco de México's PFMI disclosure, and it is dated 2016-03-28, before the instances existed.", "details": [ { "label": "The Administrador validates, then settles against the instance account, taking pending orders and priority into account", "value": "Once the Administrador has run its automated validations through the relevant SPEI instance, it settles the order by the process in section 4 of the Manual, which performs the compensación the Ley de Sistemas de Pagos speaks of. The process weighs the balance of the Cuenta del SPEI for the instance the order came in on, the orders still awaiting settlement, and the priority the sending participant marked on the order. Section 4 of the Manual is not public, so how those three are weighed against each other is not something Orca can state.", "citation": "Circular 14/2017, Reglas del Sistema de Pagos Electrónicos Interbancarios (texto compilado), Regla 18a, first paragraph", "rests_on": "rule" }, { "label": "No participant may overdraw its Cuenta del SPEI", "value": "Settlement uses the balance the participant holds in the Cuenta del SPEI for the instance the order was sent to. An order for more than that balance at the moment of settlement cannot settle, so participants cannot run an overdraft on a Cuenta del SPEI. SPEI extends no credit: the only money that settles a payment is money already in the participant's account in the system.", "citation": "Circular 14/2017, Reglas del Sistema de Pagos Electrónicos Interbancarios (texto compilado), Regla 6a, first paragraph; SPEI, divulgación del cumplimiento y adopción de los Principios para las Infraestructuras del Mercado Financiero, executive summary and section III.C", "rests_on": "rule" }, { "label": "A Cuenta del SPEI is funded from SIAC-BANXICO or DALÍ, or by incoming credits, and swept at close", "value": "A participant raises the balance of a Cuenta del SPEI other than its Cuenta Alterna by transferring funds from its SIAC-BANXICO account or its DALÍ account, or by receiving accepted transfer orders from other participants through that instance. At the close of the SPEI operating day a credit institution's Cuenta del SPEI balances move to its Cuenta Única; a participant that is not a credit institution has its balances held overnight in a concentrating account at SIAC-BANXICO, earning no interest, and credited back to the same Cuentas del SPEI at the time section 3 of the Manual sets on the next operating day.", "citation": "Circular 14/2017, Reglas del Sistema de Pagos Electrónicos Interbancarios (texto compilado), Regla 6a, second, third and fourth paragraphs", "rests_on": "rule" }, { "label": "Four grounds on which the Administrador eliminates an order it has not settled", "value": "The Administrador eliminates an order automatically when it is unsettled at the close of the SPEI operating day; when a non-CoDi order is unsettled after the number of clearing cycles section 5.7 of the Manual sets, because the sender's Cuenta del SPEI is short or because the receiving participant has disconnected from the instance; when a CoDi order is unsettled after the clearing cycle immediately following its receipt; and when the Administrador is prevented from processing it. Separately it may eliminate orders for as long as the sender has too little balance in the instance account they were sent to. The number of cycles is set in a section of the Manual that is not public, so Orca cannot say how long an order survives on the shortfall ground.", "citation": "Circular 14/2017, Reglas del Sistema de Pagos Electrónicos Interbancarios (texto compilado), Regla 17a, fracciones I to IV, and the paragraph added by Circular 1/2022", "rests_on": "rule" }, { "label": "Which instances a participant must connect to depends on its class and its account count", "value": "Each participant must process its transfer orders through the SPEI instance section 9 of the Manual assigns to the order set they belong to. A credit institution or an institution of electronic payment funds holding at least three thousand accounts, and any other participant that has told the Administrador under Apéndice G of the Manual that it chooses to, must connect to every instance on every operating day. Everyone else connects only to the instance its own order set needs, but must be able to connect to any other the moment the Administrador says so, and must still meet any connection duty a contingency imposes. Every participant must run one or more Aplicativos SPEI certified by the Administrador that guarantee those connections.", "citation": "Circular 14/2017, Reglas del Sistema de Pagos Electrónicos Interbancarios (texto compilado), Regla 5a Bis, fracciones I and II and the paragraphs that follow", "rests_on": "rule" }, { "label": "A hybrid design that settled a payment in 1.9 seconds on average as at 2016", "value": "Banco de México describes SPEI as a hybrid payment system that processes transfer orders very close to real time, how often it settles depending on the processes it has to run, and reports an average of 1.9 seconds to settle a payment with the result posted immediately to the participants' accounts in the system. Participants may mark an order high priority, which is tried first and reaches balance the institution has reserved for the purpose, and may bundle several orders into one payment instruction. Two send topologies exist: under V the receiving participant learns of an order only once it has settled, under T it first receives the payment instruction as an intention to pay. Every figure and every mechanism here is as at the disclosure date of 2016-03-28, before the SPEI instances were introduced in 2022.", "citation": "SPEI, divulgación del cumplimiento y adopción de los Principios para las Infraestructuras del Mercado Financiero, executive summary, and section III on the general system design", "rests_on": "guidance" } ], "exceptions": [ "Banco de México's own public page and its PFMI disclosure describe SPEI as settling very close to real time, while the Reglas describe clearing cycles feeding settlement. Both are Banco de México's words and Orca does not choose between them.", "How many clearing cycles an order survives on the insufficient balance ground is set in section 5.7 of the Manual and is not public." ], "applies_to": "SPEI in Mexico, in Mexican pesos: ordinary customer to customer transfer orders, low value orders, CoDi orders, Pagos Programados and the four return types, among the 94 direct participants Banco de México lists and the indirect participants they serve", "caveat": "The PFMI disclosure is ten years old and predates six of the eleven amending circulares and the SPEI instances, so every figure taken from it, including the 1.9 second average, is a 2016 figure and not a current one.", "related": [ "pix:settlement" ], "basis": { "sources": "Reglas del SPEI 5a Bis, 6a, 17a and 18a; SPEI PFMI disclosure of 2016-03-28, executive summary and general system design; read 2026-09-20.", "confidence": "medium" }, "currency": { "effective_since": "2017-07-04", "effective_to": null, "effective_note": "Drafted 2026-09-20 in Orca Core form. The date is the day the Diario Oficial de la Federación published Circular 14/2017, the original text of the Reglas del SPEI; each Rule this fact lists carries its own date, which for a provision a later circular changed is that circular's publication date.", "source_edition": "Circular 14/2017, Reglas del Sistema de Pagos Electrónicos Interbancarios, texto compilado, published in the Diario Oficial de la Federación on 2017-07-04 and including the amendments made by Circulares 5/2018, 11/2018, 18/2018, 3/2019, 8/2019, 1/2022, 15/2022, 16/2022, 12/2023, 2/2025 and 9/2026, the last of them published in the DOF on 2026-06-17; PDF of 296 pages read in Spanish on 2026-09-20; Sistema de Pagos Electrónicos Interbancarios (SPEI), divulgación del cumplimiento y adopción de los Principios para las Infraestructuras del Mercado Financiero, disclosure date 2016-03-28; PDF of 41 pages read in Spanish on 2026-09-20", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.banxico.org.mx/marco-normativo/normativa-emitida-por-el-banco-de-mexico/circular-14-2017/%7BA06FBFEE-06BB-F249-32FC-25B334B2A744%7D.pdf", "source_class": "authoritative_primary", "source_title": "Circular 14/2017, Reglas del Sistema de Pagos Electrónicos Interbancarios (texto compilado)", "checked_on": "2026-09-21", "checked_by": "mx-spei validator session, 2026-09-21", "notes": "Confirms Reglas 5a Bis, 6a, 17a and 18a: automated validation then settlement against the sending instance balance weighing pending orders and priority, central bank money with no overdrafts, funding from SIAC-BANXICO, DALI or incoming credits, several instances each with its own account, and elimination rather than indefinite holding for an order that cannot settle." }, { "source_url": "https://www.banxico.org.mx/sistemas-de-pago/d/%7B89B6CCF0-6070-7389-3DD5-B27AC4ECD9D1%7D.pdf", "source_class": "public_primary", "source_title": "SPEI, divulgación del cumplimiento y adopción de los Principios para las Infraestructuras del Mercado Financiero", "checked_on": "2026-09-21", "checked_by": "mx-spei validator session, 2026-09-21", "notes": "Confirms the executive summary and general system design describe SPEI settling very close to real time and never mentions clearing cycles anywhere in the 41 pages, in tension with Regla 17a's cycle based elimination; the fact logs this rather than choosing, and its 1.9 second figure and other mechanics carry the 2016-03-28 disclosure date, before the SPEI instances existed." } ] }, "rail_name": "SPEI (Mexico peso interbank electronic transfers)", "governing_authority": "Banco de México", "snapshot": "2026-09-20", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "my-duitnow:consumer-law", "id": "consumer-law", "rail": "my-duitnow", "kind": "rail-fact", "facet": "consumer-law", "name": "What does the law give a consumer on this rail, beyond the rulebook?", "statement": "Malaysian consumer protection for DuitNow comes from Bank Negara Malaysia's policy documents issued under the Financial Services Act 2013 and its Islamic and development-institution counterparts, not from the scheme rules. BNM's interoperability framework gives every consumer a set of service rights on fund transfers: an instant alert for every transfer in or out, a real-time view of their balance, free transfers up to RM5,000, safety tips kept current, protected data, comparable pricing, and online control of their own limits. Other BNM policies add protection against unauthorised transactions, fixed complaint turnaround times and a route to the Financial Markets Ombudsman Service. A consumer here includes micro and small businesses.", "details": [ { "label": "Who is protected", "value": "A financial consumer is anyone using a financial service for personal, domestic or household purposes, and also anyone using it in connection with a micro or small business as defined by SME Corporation Malaysia, as BNM has specified under the Act.", "citation": "Financial Services Act 2013 (Act 758), sections 121 and 123(3); IFTF (BNM/RH/PD 028-143, 2026-06-30) paragraph 5.2 (definition of financial consumer)", "rests_on": "law" }, { "label": "Where BNM's power comes from", "value": "BNM may set business conduct standards for financial service providers, covering disclosure, fair terms, promotion, advice and complaints handling. The IFTF's consumer duties are issued under that power among others, and breaching a standard can lead to enforcement action.", "citation": "Financial Services Act 2013, section 123(1) and (2); IFTF (BNM/RH/PD 028-143, 2026-06-30) paragraphs 3.1 and 5.2 (meaning of S)", "rests_on": "law" }, { "label": "Service rights on every transfer", "value": "Each institution offering fund transfers must: alert the payer and the payee instantly for every transfer made or received (the payer's institution and the payee's institution respectively); let the consumer see a real-time balance and manage transfer limits online; keep consumer data secure against loss, theft and unauthorised access; publish transfer pricing in a form that allows comparison; and keep consumers supplied with timely, practical safety tips.", "citation": "IFTF (BNM/RH/PD 028-143, 2026-06-30) paragraph 10.1 and footnotes 18 and 19", "rests_on": "law" }, { "label": "Turning alerts off", "value": "A consumer may ask for instant alerts to be switched off, and the institution may agree, but only after clearly explaining the risks of doing so and obtaining the consumer's consent.", "citation": "IFTF (BNM/RH/PD 028-143, 2026-06-30) paragraph 10.2 (guidance) and paragraph 10.3 (standard)", "rests_on": "law" }, { "label": "Free transfers", "value": "DuitNow transfers up to RM5,000 funded from a current, savings or e-money account must be free to a consumer on either side. BNM may set a different threshold.", "citation": "IFTF (BNM/RH/PD 028-143, 2026-06-30) paragraph 9.15 and footnote 17", "rests_on": "law" }, { "label": "Protection against unauthorised transactions", "value": "Banks carry the loss on unauthorised e-banking transactions unless they prove specific customer failures, must advise the customer to make a police report and explain the process in writing, and must provide provisional credit on long investigations.", "citation": "BNM policy document Ensuring Fair Treatment for Victims of Unauthorised e-Banking Transactions, BNM/RH/PD 028-139, issued 2024-06-28, effective 2024-10-01, paragraphs 9.3, 9.5, 9.6 and 11", "rests_on": "law" }, { "label": "Complaints and redress", "value": "Institutions must acknowledge a complaint by the next working day and decide it within 5 working days if simple or 20 if complex, with a 10-day extension where third-party documents are needed, then refer eligible consumers to the Financial Markets Ombudsman Service or, outside its remit, to BNMLINK.", "citation": "BNM policy document Complaints Handling, BNM/RH/PD 028-137, issued 2025-03-28, effective 2026-04-01, paragraphs 11.3, 11.5, 11.6, 11.8, 12.3 and 12.4", "rests_on": "law" } ], "exceptions": [ "The free-transfer rule does not cover customers dealing with the institution as merchants (IFTF footnote 17).", "The unauthorised-transaction policy applies to banks and development financial institutions, and its joint-culpability and provisional-credit protections only to individuals and micro and small enterprises (BNM/RH/PD 028-139 paragraphs 2.1 and 5.2).", "Consumer duties in BNM's Policy Document on Fair Treatment of Financial Consumers (2024-03-27) and Product Transparency and Disclosure (2024-12-03) also apply but were not read for this record.", "Islamic banks and development financial institutions are bound through the parallel provisions of the Islamic Financial Services Act 2013 and the Development Financial Institutions Act 2002 (IFTF 3.1), which were not read." ], "applies_to": "financial consumers, including micro and small businesses, using DuitNow at Malaysian banks, e-money issuers and acquirers", "caveat": "These are duties on the consumer's own institution, enforceable by BNM, not rights against the operator or the other side's bank. A consumer's route to enforce them is a complaint to their institution, then the ombudsman.", "related": [ "my-duitnow:liability", "my-duitnow:refund", "my-duitnow:limits", "my-duitnow:participants" ], "basis": { "sources": "Financial Services Act 2013 (Act 758), sections 121 and 123, from the copy on bnm.gov.my, which shows the text as enacted (amendments not checked). BNM policy documents: IFTF BNM/RH/PD 028-143 (2026-06-30) paragraphs 3.1, 5.2, 9.15, 10.1 to 10.3; Ensuring Fair Treatment for Victims of Unauthorised e-Banking Transactions BNM/RH/PD 028-139 (2024-06-28) paragraphs 2.1, 5.2, 9.3, 9.5, 9.6, 11; Complaints Handling BNM/RH/PD 028-137 (issued 2025-03-28, effective 2026-04-01) paragraphs 11 and 12. All authoritative_primary from the governing authority, cited by paragraph. BNM Terms of Use (updated November 2023) bar reproduction except as copyright law permits; nothing here is quoted. No PayNet material was consulted.", "confidence": "high" }, "currency": { "effective_since": "2026-06-30", "effective_note": "The IFTF consumer duties took effect 2026-06-30. Whether the superseded Interoperable Credit Transfer Framework of 2019 carried the same duties was not checked. The complaints timelines apply from 2026-04-01; the unauthorised-transaction policy from 2024-10-01.", "source_edition": "IFTF BNM/RH/PD 028-143 2026-06-30; BNM/RH/PD 028-139 2024-06-28; Complaints Handling BNM/RH/PD 028-137 2025-03-28; FSA 2013 as published on bnm.gov.my", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.bnm.gov.my/documents/20124/943361/pd_IFTF_June2026.pdf", "source_class": "authoritative_primary", "source_title": "Interoperable Fund Transfer Framework, BNM/RH/PD 028-143, issued 30 June 2026", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the financial consumer definition, BNM's conduct-standard power, the paragraph 10.1 to 10.3 service rights (limits, notifications, balance, disclosure, data protection, safety tips, opt out of alerts) and the paragraph 9.15 free transfer threshold up to RM5,000. Does not confirm the unauthorised e-banking protection detail, which cites BNM/RH/PD 028-139, a document not located on bnm.gov.my." } ] }, "rail_name": "Malaysia DuitNow", "governing_authority": "Bank Negara Malaysia", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "my-duitnow:decision-points", "id": "decision-points", "rail": "my-duitnow", "kind": "rail-fact", "facet": "decision-points", "name": "Where does a person or institution have to make a judgment call?", "statement": "Most of the judgment on DuitNow sits with the customer's own bank and with the recipient's bank, not with the operator or BNM. The paying bank decides, after an investigation, whether a disputed payment was unauthorised and whether any loss falls on the customer. The recipient's institution decides whether a credit was a mistake before any recovery can move money, and after seven months the recipient decides whether to give it back at all. The operator decides who gets onto the rail and on what terms, subject to an appeal to its own independent directors. BNM keeps a few calls for itself, such as deciding in writing that an institution need not offer cross-border QR purchases. This is Orca's reading of where published rules leave discretion open, and every line cites the rule that leaves it open.", "details": [ { "label": "Was it unauthorised, and who pays", "value": "The paying bank investigates a disputed transaction, weighing its own customer reminders and controls first, and decides whether the customer bears any loss. If it assigns loss to an individual or small business customer, it must show evidence, weigh joint culpability, and have the decision checked by an independent reviewer before telling the customer. Where it concludes neither side was at fault, BNM's guidance invites, but does not require, a look for other contributing factors.", "citation": "BNM policy document Ensuring Fair Treatment for Victims of Unauthorised e-Banking Transactions, BNM/RH/PD 028-139, issued 2024-06-28, paragraphs 9.1, 9.4, 9.7 to 9.9 and 9.11 (guidance)", "rests_on": "law" }, { "label": "Asking the customer for more", "value": "The bank judges what cooperation it needs beyond the minimum dispute details, and must justify any heavier demand such as keeping the customer's phone for forensic work.", "citation": "BNM policy document Ensuring Fair Treatment for Victims of Unauthorised e-Banking Transactions, BNM/RH/PD 028-139 (2024-06-28), paragraph 9.2 and footnote 8 (attached to paragraph 9.6(b))", "rests_on": "law" }, { "label": "Was it a mistake", "value": "For a mistaken transfer, the recipient's institution must be satisfied the credit was erroneous before recovering anything. In the middle recovery window it then judges whether the recipient's evidence of entitlement is reasonable; after seven months the recipient alone decides whether to consent.", "citation": "DuitNow Transfer Terms and Conditions of Deutsche Bank (Malaysia) Berhad, version May 2026, clauses 5.1 to 5.3; of HSBC Bank Malaysia Berhad, version October 2022 (v1.4), clauses 5.1 to 5.3", "rests_on": "practice" }, { "label": "Suspending a customer's use", "value": "Participants reserve the right, at their sole discretion, to suspend or end a customer's DuitNow access where they judge use to be inappropriate, fraudulent or suspicious, citing repeated recipient-name lookups without payment as an example.", "citation": "DuitNow Transfer Terms and Conditions of Deutsche Bank (Malaysia) Berhad, version May 2026, clause 3.2; of HSBC Bank Malaysia Berhad, version October 2022, clause 3.2", "rests_on": "practice" }, { "label": "Switching off alerts", "value": "An institution may agree to a consumer's request to disable instant transaction alerts, after explaining the risks and getting consent; whether to agree is left to it.", "citation": "IFTF (BNM/RH/PD 028-143, 2026-06-30) paragraphs 10.2 (guidance) and 10.3", "rests_on": "guidance" }, { "label": "Admission to the rail", "value": "The operator decides access applications against its own risk-based criteria, chooses whether an applicant joins directly or through a sponsor, and sets access conditions. Appeals go to a board committee with an independent chair and an independent majority. Sponsors in turn judge which institutions to sponsor under their own published criteria.", "citation": "IFTF (BNM/RH/PD 028-143, 2026-06-30) paragraphs 8.8, 8.11 to 8.13, 8.18 and 8.19", "rests_on": "law" }, { "label": "Removal from the rail", "value": "The operator's rules set when a participant may be suspended or removed, subject to notice and a chance to make representations. For RENTAS, BNM decides on suspension after considering the participant's reasons.", "citation": "IFTF (BNM/RH/PD 028-143, 2026-06-30) paragraph 8.15(d); BNM Participation Rules for Payments and Securities Services, version 3 (2025-09-29), clauses 6.2 and 6.3", "rests_on": "law" }, { "label": "BNM's own calls", "value": "BNM decides in writing whether offering cross-border QR purchases would pose a material risk to a given institution or to the shared infrastructure, which relieves that institution of the duty; BNM's feedback statement adds that it will consider exemptions from the cross-border mandate only where such a risk is clear. Cross-border account-to-account transfers work differently: for an institution that is encouraged but not required to offer them, the operator evaluates a request to discontinue the service and may accept it only after consulting BNM, weighing disruption to the ecosystem. The text gives no such discontinuance route to banks that are required to offer cross-border transfers [Inference from paragraph 9.5 referring only to paragraph 9.4]. BNM also sets each participant's minimum NRTS balance.", "citation": "IFTF (BNM/RH/PD 028-143, 2026-06-30) paragraphs 9.3 to 9.5 and 9.14; IFTF feedback statement dated 2026-06-30, paragraph 1.7; BNM Operational Procedures for MYR Settlement in RENTAS (BNM/RH/PD 028-28, version 1.8, 2025-09-29), clause 38.15(vi)", "rests_on": "law" } ], "exceptions": [ "Fraud screening and blocking decisions taken on payments in flight, by the paying bank, the receiving bank or the operator, are not described in any public source read; BNM's Policy Document on Financial Institutions' Response to Fraud (2026-06-30) and its Dear CEO letters on e-banking fraud likely govern them and were not read [Unverified].", "Disputes between participants go to the operator's dispute resolution mechanism, whose procedure and decision-makers are in rules that are not public (IFTF 8.15(b)).", "Once the ombudsman takes a case, the decision on a consumer dispute passes to the Financial Markets Ombudsman Service under its own terms of reference, not read for this record." ], "applies_to": "DuitNow Transfer and access to the RPP in Malaysia", "caveat": "Where a line cites participants' customer terms, the discretion is the bank's contractual reservation, not a rule shown to come from the scheme; the operator's rules may narrow or widen it and are not public.", "related": [ "my-duitnow:liability", "my-duitnow:recall", "my-duitnow:participants", "my-duitnow:settlement", "my-duitnow:consumer-law" ], "basis": { "sources": "BNM policy documents: Ensuring Fair Treatment for Victims of Unauthorised e-Banking Transactions BNM/RH/PD 028-139 (2024-06-28) paragraphs 9.1 to 9.11 and footnote 8, fetched 2026-09-18 from https://www.bnm.gov.my/documents/20124/938039/Ensuring_Fair_Treatment_for_Victims_of_Unauthorised_eBanking-Transactions.pdf and read in full; IFTF BNM/RH/PD 028-143 (2026-06-30) paragraphs 8.8 to 8.19, 9.3 to 9.5, 9.14, 10.2, 10.3 and its feedback statement paragraph 1.7; RENTAS Participation Rules v3 (2025-09-29) clause 6; RENTAS MYR Operational Procedures v1.8 (2025-09-29) clause 38.15: authoritative_primary. Participants' DuitNow Transfer terms, Deutsche Bank (Malaysia) Berhad May 2026 and HSBC Bank Malaysia Berhad October 2022 (common template). Orca's reading of where discretion sits caps this facet at medium; the operator's rules are not public, hence primary_not_public. No PayNet material was consulted.", "confidence": "medium" }, "currency": { "effective_since": "2026-06-30", "effective_note": "Dated from the IFTF. The unauthorised-transaction policy has applied since 2024-10-01 and the RENTAS texts since 2025-09-29.", "source_edition": "IFTF 2026-06-30 and feedback statement; BNM/RH/PD 028-139 2024-06-28; RENTAS Participation Rules v3 and MYR Operational Procedures v1.8, both 2025-09-29; participant terms May 2026 and October 2022", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "primary_not_public": true, "corroboration": [ { "source_url": "https://www.bnm.gov.my/documents/20124/943361/pd_IFTF_June2026.pdf", "source_class": "authoritative_primary", "source_title": "Interoperable Fund Transfer Framework, BNM/RH/PD 028-143, issued and effective 30 June 2026", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the operator decides access applications against risk-based criteria, chooses direct or sponsored participation, and that appeals go to a board committee chaired by and with a majority of independent directors (paragraphs 8.8, 8.11 to 8.13, 8.18, 8.19). Confirms the operator's own rules set suspension and termination circumstances with required notice and a chance to make representations (paragraph 8.15(d)), and separately that BNM's own RENTAS Participation Rules version 3 have BNM itself deciding on RENTAS suspension after considering the participant's reasons (clauses 6.2 and 6.3 of that document, read at bnm.gov.my, same host). Confirms an institution may disable a consumer's instant transaction alerts only after explaining the risk and obtaining consent, with paragraph 10.2 marked guidance and 10.3 the binding disclosure duty. Confirms paragraph 9.14 gives BNM sole written authority to exempt an institution from the cross-border QR purchase mandate on a finding of material risk, and separately that paragraph 9.5 gives the operator, after consulting BNM, the call on a paragraph 9.4 institution's request to discontinue cross-border account-to-account transfers, a route the text does not extend to the paragraph 9.3 institutions required to offer that service. The feedback statement dated 30 June 2026, paragraph 1.7, confirms BNM intends to consider cross-border mandate exemptions only where a clear material risk exists." }, { "source_url": "https://www.hsbc.com.my/content/dam/hsbc/my/docs/ways-to-bank/duitnow/duitnow-transfer-terms-of-use.pdf", "source_class": "secondary", "source_title": "HSBC Bank Malaysia Berhad, DuitNow Transfer Terms and Conditions, version October 2022 (DuitNow Transfer v1.4)", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms a participant bank's own terms make the crediting bank the judge of whether a transfer was erroneous, of whether a recipient's evidence of entitlement is reasonable in the eleven-business-day to seven-month window, and give the recipient alone the decision whether to consent to recovery after seven months (clauses 5.1 to 5.3). Confirms the bank reserves sole discretion to suspend or end a customer's DuitNow access for use it judges inappropriate, fraudulent or suspicious, naming repeated unconfirmed recipient lookups as an example (clause 3.2). Does not address admission to the rail, BNM's own discretionary calls, or the operator's dispute resolution mechanism, which are not addressed in a participant's customer terms." }, { "source_url": "https://www.bnm.gov.my/documents/20124/938039/Ensuring_Fair_Treatment_for_Victims_of_Unauthorised_eBanking-Transactions.pdf", "source_class": "authoritative_primary", "source_title": "Ensuring Fair Treatment for Victims of Unauthorised e-Banking Transactions, BNM/RH/PD 028-139, issued 28 June 2024, effective 1 October 2024", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the paying bank first weighs its own reminder and control obligations, then decides fault, with evidence, joint-culpability weighing and independent review required before telling the customer, and that guidance only invites a look for other contributing factors when neither side is at fault (paragraphs 9.1, 9.4, 9.7 to 9.9, 9.11 which is guidance). Confirms footnote 8, attached to paragraph 9.6(b) on refusal to cooperate, leaves the bank to judge what cooperation beyond the paragraph 9.2 minimum information it needs and requires justification for a heavier demand such as retaining a phone for forensic work (paragraphs 9.2 and footnote 8)." } ] }, "rail_name": "Malaysia DuitNow", "governing_authority": "Bank Negara Malaysia", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "not_public", "label": "the operator's own text", "needs": "what the operator's own text says, which Orca has not read", "detail": "Bank Negara Malaysia's own text is not the source for this rail fact: it is not public, or not under terms Orca can use. It rests on 3 named public sources, so a term set by agreement rather than by a published rule is not Orca's to state.", "from": "currency.primary_not_public" } ] }, { "uid": "my-duitnow:finality", "id": "finality", "rail": "my-duitnow", "kind": "rail-fact", "facet": "finality", "name": "When does a DuitNow transfer become final, and can it be reversed?", "statement": "Finality on DuitNow has three layers, and only one is fully public. Between participants, settlement in BNM's NRTS module is a final and irrevocable discharge in central bank money under BNM's own RENTAS rules. Between a customer and their bank, participants' published terms say a confirmed DuitNow transfer is irrevocable and cannot be cancelled, stopped or changed. The layer that ties the two together, the moment the operator's scheme rules treat a transfer as final, sits in PayNet's rulebook, which is not public. Irrevocable does not mean unrecoverable: a mistaken transfer can be pursued through a recovery process, and an unauthorised one through the paying bank's investigation, both of which move money back as a separate step.", "details": [ { "label": "Interbank layer", "value": "BNM's RENTAS rules define settlement as the final and irrevocable discharge of one participant's obligation to another, in central bank money for ringgit. RPP items settle in NRTS by a simultaneous debit and credit of the two participants' NRTS accounts at BNM.", "citation": "BNM Participation Rules for Payments and Securities Services, version 3 (2025-09-29), glossary item 55; BNM Operational Procedures for MYR Settlement in RENTAS (BNM/RH/PD 028-28, version 1.8, 2025-09-29), clauses 8.14, 38.3 and Appendix XX", "rests_on": "rule" }, { "label": "Statutory finality", "value": "The Financial Services Act 2013 protects a transfer order in a certified designated payment system from being revoked, reversed or set aside by anyone, including a court or an insolvency administrator, from the moment the system's rules make it final. RENTAS is deemed a certified designated payment system under the Act. Whether the RPP itself holds a certificate of finality was not established [Unverified]; if it does not, the statutory protection reaches the RPP's settlement leg in RENTAS but not the RPP's own processing [Inference].", "citation": "Financial Services Act 2013 (Act 758), Part IV Division 3, sections 37, 38, 40, 41 and 42, and sections 35(2)(a) and 277, text as published on bnm.gov.my (amendments after enactment not checked)", "rests_on": "law" }, { "label": "Suspension of a participant", "value": "If BNM suspends a RENTAS participant, settlements completed before the suspension stay valid, final and irrevocable, while queued and pending items at that point are cancelled and new items rejected.", "citation": "BNM Participation Rules for Payments and Securities Services, version 3 (2025-09-29), clause 6.3.1", "rests_on": "rule" }, { "label": "Customer layer", "value": "Participants' DuitNow Transfer terms tell the customer that once a transfer is confirmed it is irrevocable: the customer cannot cancel it, stop it or alter it. The same terms make the customer responsible for entering the right DuitNow ID and checking the displayed recipient name before confirming, and say the bank need not check further that the registered recipient is the intended one.", "citation": "DuitNow Transfer Terms and Conditions of Deutsche Bank (Malaysia) Berhad, version May 2026, clauses 2.3, 2.5 and 2.6; of HSBC Bank Malaysia Berhad, version October 2022 (v1.4), clauses 2.3, 2.5 and 2.6", "rests_on": "practice" }, { "label": "What can still come back", "value": "The same terms give the customer a right to have mistaken and unauthorised DuitNow transfers investigated and, where the conditions are met, recovered: a mistaken transfer through a tiered recovery process run with the recipient's institution, and an unauthorised one through the paying bank's investigation and reversal of the debit. BNM separately obliges banks to bear losses from unauthorised e-banking transactions in defined cases. Both are new money movements, not a reversal of the settled transfer [Inference].", "citation": "DuitNow Transfer Terms and Conditions of Deutsche Bank (Malaysia) Berhad, version May 2026, clauses 4 to 6; BNM policy document Ensuring Fair Treatment for Victims of Unauthorised e-Banking Transactions, BNM/RH/PD 028-139, issued 2024-06-28, paragraphs 9.5 and 9.6", "rests_on": "practice" }, { "label": "Scheme layer", "value": "The operator must, by law, have rules fixing when a transfer order is final if its system is certified, and BNM requires it to maintain clear, comprehensive rules and procedures for participants. Those rules are disclosed to participants, not to the public, so the exact point at which the scheme treats a DuitNow transfer as final is not published.", "citation": "Financial Services Act 2013, section 35(2)(a); IFTF (BNM/RH/PD 028-143, 2026-06-30) paragraphs 8.14 and 8.15; BNM policy document Payment System Operator (BNM/RH/PD 029-54, 2022-12-22) paragraph 26.1", "rests_on": "law" } ], "exceptions": [ "A transfer that has not completed is not final. A participant's FAQ says a transfer shown as processing may take up to 24 hours in exceptional cases and that an unsuccessful one is reversed automatically to the payer (GXBank DuitNow Services FAQ, effective 2024-03-22, section A).", "The statutory protection in FSA 2013 Division 3 does not apply to a transfer order sent after the end of the day on which an insolvency administrator is appointed for the operator or a participant (FSA section 41).", "Finality does not bar a customer's rights under BNM's policy on unauthorised e-banking transactions, which applies to banks; an e-money issuer's customer relies on the e-money policy document instead (see the liability fact).", "Scams in which the customer willingly approved the payment are excluded from BNM's definition of an unauthorised transaction (BNM/RH/PD 028-139 paragraph 5.2). The participants' recovery process covers transfers sent to the wrong recipient by mistake; whether the scheme extends it to scam payments is not stated in any source read, which leaves the bank's complaint process and the Financial Markets Ombudsman Service as the published routes." ], "applies_to": "a DuitNow Transfer in ringgit between accounts at RPP participants in Malaysia", "caveat": "Do not tell a customer a DuitNow transfer is gone for good, and do not tell them it can be undone. It is irrevocable as an instruction; recovery of a mistaken transfer depends on the recipient's institution being satisfied it was an error and on money remaining in the recipient's account.", "related": [ "my-duitnow:settlement", "my-duitnow:participants" ], "basis": { "sources": "BNM Participation Rules for Payments and Securities Services, version 3, 2025-09-29 (clause 6.3.1, glossary 55); BNM Operational Procedures for MYR Settlement in RENTAS, BNM/RH/PD 028-28, version 1.8, 2025-09-29 (clauses 8.14, 38.3, Appendix XX); Financial Services Act 2013 (Act 758), Part IV Division 3 (sections 37 to 45) and section 277, from the copy on bnm.gov.my, which shows the text as enacted; BNM policy documents IFTF BNM/RH/PD 028-143 (2026-06-30), Payment System Operator BNM/RH/PD 029-54 (2022-12-22) and Ensuring Fair Treatment for Victims of Unauthorised e-Banking Transactions BNM/RH/PD 028-139 (2024-06-28). For the customer layer, participants' own published DuitNow Transfer terms: Deutsche Bank (Malaysia) Berhad version May 2026 (country.db.com), HSBC Bank Malaysia Berhad October 2022 (hsbc.com.my); these two use near-identical wording, which reads as a common industry template, so they are not independent of each other. A third bank's version of the same terms was found but is marked confidential in its footer and was not used. GXBank DuitNow Services FAQ effective 2024-03-22 (gxbank.my). The scheme rules are not public, hence primary_not_public and medium confidence. BNM Terms of Use (updated November 2023) bar reproduction except as copyright law permits; nothing here is quoted. No PayNet material was consulted.", "confidence": "medium" }, "currency": { "effective_since": "2025-09-29", "effective_note": "The interbank layer is dated from NRTS entering the RENTAS procedures on 2025-09-29. The FSA provisions date from 2013-06-30. The customer-layer wording has been in participants' terms since at least October 2022 (HSBC v1.4) and is unchanged in Deutsche Bank's May 2026 version.", "source_edition": "RENTAS Participation Rules v3 and MYR Operational Procedures v1.8, both 2025-09-29; FSA 2013 as published on bnm.gov.my; IFTF 2026-06-30; PSO PD 2022-12-22; PD 028-139 2024-06-28; participant terms as dated in the details", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "primary_not_public": true, "corroboration": [ { "source_url": "https://www.bnm.gov.my/documents/20124/943361/op-myr-stlmt-rentas-sep25.pdf", "source_class": "authoritative_primary", "source_title": "Operational Procedures for Malaysian Ringgit (MYR) Settlement in RENTAS, BNM/RH/PD 028-28, version 1.8, issued 29 September 2025; Participation Rules for Payments and Securities Services, version 3, issued 29 September 2025", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the interbank layer: settlement in NRTS by simultaneous debit and credit of the two NRTS accounts, and glossary item 55 defining settlement as final and irrevocable discharge in central bank money. Confirms clause 6.3.1: settlements completed before a participant suspension stay valid, final and irrevocable, while queued and pending items are cancelled. Does not confirm the BNM policy document on unauthorised e-banking transactions cited for the what-can-still-come-back detail; that document was not located on bnm.gov.my, so the bank-loss-bearing half of that detail rests only on the HSBC DuitNow Transfer Terms and Conditions source recorded separately on this record." }, { "source_url": "https://www.hsbc.com.my/content/dam/hsbc/my/docs/ways-to-bank/duitnow/duitnow-transfer-terms-of-use.pdf", "source_class": "secondary", "source_title": "DuitNow Transfer Terms and Conditions, HSBC Bank Malaysia Berhad, version October 2022 (v1.4), marked Public", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the customer layer: clause 2.6 makes a confirmed transfer irrevocable and clause 2.3 and 2.5 place the ID and name check on the customer with no duty on the bank to verify further. Confirms clause 6.1: the bank investigates an unauthorised or fraudulent transfer within 14 calendar days and reverses the debit if found not caused by the customer. Independent of the Deutsche Bank copy of the same template; this is a distinct organisation from Bank Negara Malaysia and a distinct host from bnm.gov.my." } ] }, "rail_name": "Malaysia DuitNow", "governing_authority": "Bank Negara Malaysia", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "not_public", "label": "the operator's own text", "needs": "what the operator's own text says, which Orca has not read", "detail": "Bank Negara Malaysia's own text is not the source for this rail fact: it is not public, or not under terms Orca can use. It rests on 2 named public sources, so a term set by agreement rather than by a published rule is not Orca's to state.", "from": "currency.primary_not_public" } ] }, { "uid": "my-duitnow:hours", "id": "hours", "rail": "my-duitnow", "kind": "rail-fact", "facet": "hours", "name": "When does this rail operate, and when do payments move?", "statement": "DuitNow runs continuously. BNM's settlement module for the RPP operates 24 hours a day, 7 days a week, including weekends and public holidays, and BNM requires the operator to deliver the service without interruption on systems built for high availability. Participants tell customers the same thing: transfers go through any time and normally arrive at once. Business days still matter in the customer's own recovery process for mistaken transfers, whose clocks run in business days, and in two weekday-only net settlement windows BNM schedules for FPX-RPP Bridge transactions, whose reach into DuitNow is not stated. Any scheduled maintenance windows the operator sets are in its own rules and are not public.", "details": [ { "label": "Settlement never closes", "value": "BNM's near real time settlement module, which carries RPP settlement, operates round the clock on every day of the year, weekends and holidays included. It keeps settling even while the main RENTAS host is down for its batch run, during which participants cannot top up or move funds through RENTAS.", "citation": "BNM Operational Procedures for MYR Settlement in RENTAS (BNM/RH/PD 028-28, version 1.8, 2025-09-29), clauses 38.6 and 38.13, Appendix XX", "rests_on": "rule" }, { "label": "The operator must stay up", "value": "BNM requires the operator of the shared payment infrastructure to keep fund transfer services running reliably and without interruption, on systems designed for high availability under BNM's technology risk rules. As a payment system operator it must also set service level objectives and minimum service targets, keep enough capacity for stressed conditions, and test capacity regularly.", "citation": "IFTF (BNM/RH/PD 028-143, 2026-06-30) paragraph 8.3 and footnote 13; BNM policy document Payment System Operator (BNM/RH/PD 029-54, 2022-12-22) paragraphs 17.4 to 17.7", "rests_on": "law" }, { "label": "What customers are told", "value": "Participants describe DuitNow Transfer as instant and available 24/7 through internet and mobile banking and e-wallets, with the money normally reaching the recipient immediately. One participant warns that a transfer can sit in a processing state for up to 24 hours in exceptional cases.", "citation": "GXBank DuitNow Services FAQ, effective 2024-03-22, section A (DuitNow Transfer); Bank Islam Malaysia Berhad DuitNow FAQ, reference FAQ/DUITNOW/2024/V.02, and DuitNow product page, read 2026-09-18", "rests_on": "practice" }, { "label": "Where business days still count", "value": "Participants' DuitNow terms define a business day as Monday to Friday excluding Kuala Lumpur public and bank holidays, and use it for the clocks in the mistaken-transfer recovery process, not for sending or receiving.", "citation": "DuitNow Transfer Terms and Conditions of Deutsche Bank (Malaysia) Berhad, version May 2026, definitions and clause 5; of HSBC Bank Malaysia Berhad, version October 2022 (v1.4), definitions and clause 5", "rests_on": "practice" }, { "label": "Scheduled transfers", "value": "Participants may let customers set future-dated and recurring DuitNow transfers inside their own apps. These are a bank feature that sends an ordinary transfer on the chosen day; nothing in BNM's texts makes scheduling a scheme service [Inference].", "citation": "GXBank DuitNow Services FAQ, effective 2024-03-22, section A; Bank Islam Malaysia Berhad DuitNow FAQ (FAQ/DUITNOW/2024/V.02), question 7", "rests_on": "practice" } ], "exceptions": [ "Weekend and holiday deferred net settlement for other retail payments runs only from 8.00 am to 6.00 pm, and its schedule names FPX; it is not the RPP's settlement route [Inference] (BNM Operational Procedures for MYR Settlement in RENTAS, clause 9).", "BNM's MYR settlement schedule for business days includes two deferred net settlement windows for FPX-RPP Bridge transactions, due by 11.00 am and by 3.50 pm, with no counterpart on weekends or holidays. The procedures do not say which transactions these are; whether any DuitNow Transfer waits for them is unconfirmed [Inference: they concern payments crossing between FPX and the RPP, not ordinary DuitNow Transfers, which settle on the 24/7 NRTS] (BNM Operational Procedures for MYR Settlement in RENTAS, BNM/RH/PD 028-28, version 1.8, 2025-09-29, clauses 8.1 and 8.2).", "A participant's own maintenance windows, cut-offs for particular channels, and any operator-wide maintenance windows are not published by BNM; the operator's rules on them are not public.", "If NRTS settlement is queued for lack of funds in a participant's NRTS account, interbank settlement waits; BNM notes that in exceptional circumstances it may take longer than the normal seconds (Operational Procedures clauses 38.1 and 38.5)." ], "applies_to": "DuitNow Transfer and the settlement of RPP transactions in Malaysia", "caveat": "A 24/7 rail with business-day recovery clocks means a mistaken transfer on a Friday night gives the sender less calendar time than it seems: the ten business day window for the simplest recovery tier starts from the transaction date but counts only weekdays that are not Kuala Lumpur holidays.", "related": [ "my-duitnow:settlement", "my-duitnow:finality" ], "basis": { "sources": "BNM Operational Procedures for MYR Settlement in RENTAS, BNM/RH/PD 028-28, version 1.8, 2025-09-29 (clauses 8.1, 8.2, 9, 38.1, 38.5, 38.6, 38.13, Appendix XX); IFTF BNM/RH/PD 028-143, 2026-06-30 (paragraph 8.3, footnote 13); Payment System Operator BNM/RH/PD 029-54, 2022-12-22 (paragraphs 17.4 to 17.7): authoritative_primary. Participants' published material, used for what customers are told: GXBank DuitNow Services FAQ effective 2024-03-22 (gxbank.my); Bank Islam Malaysia Berhad DuitNow FAQ FAQ/DUITNOW/2024/V.02 and product page (bankislam.com); Deutsche Bank (Malaysia) Berhad DuitNow Transfer terms version May 2026 (country.db.com); HSBC Bank Malaysia Berhad DuitNow Transfer terms October 2022 (hsbc.com.my). The operator's scheme hours and maintenance rules are not public, hence primary_not_public and medium. BNM Terms of Use (updated November 2023) bar reproduction except as copyright law permits; nothing here is quoted. No PayNet material was consulted.", "confidence": "medium" }, "currency": { "effective_since": "2025-09-29", "effective_note": "The 24/7 settlement statement dates from NRTS entering the RENTAS procedures on 2025-09-29. Customer-facing 24/7 availability predates it; the date it began is not stated in any source read.", "source_edition": "RENTAS MYR Operational Procedures v1.8 2025-09-29; IFTF 2026-06-30; PSO PD 2022-12-22; participant FAQs and terms as dated in the details", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "primary_not_public": true, "corroboration": [ { "source_url": "https://www.bnm.gov.my/documents/20124/943361/op-myr-stlmt-rentas-sep25.pdf", "source_class": "authoritative_primary", "source_title": "Operational Procedures for Malaysian Ringgit (MYR) Settlement in RENTAS, BNM/RH/PD 028-28, version 1.8, issued and effective 29 September 2025", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms Near Real Time Settlement operates 24 hours a day, 7 days a week including weekends and holidays, and continues operating during the RENTAS Host batch-processing window when the rest of RENTAS is unavailable (clauses 38.6, 38.13, Appendix XX). Confirms the separate weekend and holiday deferred net settlement for retail payments runs only 8.00am to 6.00pm and its schedule names only FPX (clause 9). Confirms the weekday MYR settlement schedule carries two deferred net settlement windows labelled FPX-RPP Bridge, due by 11.00am and by 3.50pm, with no weekend or holiday counterpart, and that the procedures do not define which transactions these cover (clauses 8.1, 8.2). Confirms that under exceptional circumstances interbank settlement may take longer than the normal few seconds (clause 38.1)." }, { "source_url": "https://www.hsbc.com.my/ways-to-bank/duitnow/", "source_class": "secondary", "source_title": "HSBC Bank Malaysia Berhad, Ways to Bank: DuitNow product page", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms a participant bank tells customers DuitNow Transfer is instant, real-time and usable 24/7, any time and anywhere, independently of and consistent with BNM's settlement-hours text. Does not address the FPX-RPP Bridge windows, operator uptime duties, or business-day recovery clocks, which rest on the BNM procedures and on participants' DuitNow Transfer terms and conditions." } ] }, "rail_name": "Malaysia DuitNow", "governing_authority": "Bank Negara Malaysia", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "not_public", "label": "the operator's own text", "needs": "what the operator's own text says, which Orca has not read", "detail": "Bank Negara Malaysia's own text is not the source for this rail fact: it is not public, or not under terms Orca can use. It rests on 2 named public sources, so a term set by agreement rather than by a published rule is not Orca's to state.", "from": "currency.primary_not_public" } ] }, { "uid": "my-duitnow:liability", "id": "liability", "rail": "my-duitnow", "kind": "rail-fact", "facet": "liability", "name": "Who bears the loss when a payment goes wrong?", "statement": "For a DuitNow transfer from a bank account that the customer did not authorise, BNM puts the loss on the bank by default: the bank may pass any of it to the customer only by proving the customer acted fraudulently, refused to cooperate, or broke specific credential-safety duties the bank had told them about, and even then may not leave the whole loss with the customer where the bank could have stopped further unauthorised transactions and did not. A long investigation triggers provisional credit. Payments the customer approved, including scam payments, fall outside that policy, and for a transfer sent to the wrong recipient the customer's own terms place the risk on the customer, with the recovery process as the only remedy. How losses are allocated between participants, and the operator's liability, sit in scheme rules that are not public.", "details": [ { "label": "What counts as unauthorised", "value": "The test is whether the customer agreed to the payment at all. A payment the victim knowingly made at the time falls outside the policy, even if they were deceived (BNM's examples are love, investment and parcel scams), and so does a payment the customer keyed in wrongly. Successful authentication does not settle the question: the bank must look beyond it when deciding whether the customer authorised the payment.", "citation": "BNM policy document Ensuring Fair Treatment for Victims of Unauthorised e-Banking Transactions, BNM/RH/PD 028-139, issued 2024-06-28, effective 2024-10-01, paragraph 5.2", "rests_on": "law" }, { "label": "The bank bears it by default", "value": "The bank must not hold the customer responsible where the loss stems from the bank's own shortcomings, which BNM lists: failures in the bank's systems, security controls or fraud detection, faulty or forged credentials it issued, misconduct by its staff or agents, transactions before the customer had the credential or after the customer reported a compromise, not giving customers a way to report promptly or reminders of their duties, and leaving contradictory evidence unresolved.", "citation": "BNM/RH/PD 028-139 (2024-06-28), paragraph 9.5", "rests_on": "law" }, { "label": "When the customer can be made to pay", "value": "Only if the bank proves one of three things: the customer broke a credential-safety duty the bank had told them about (reporting a breach or a lost device promptly, keeping security devices safe, never giving access details or passcodes to anyone), refused to cooperate with the investigation, or acted fraudulently. Where the bank could have stopped further unauthorised transactions and did not, the customer may not be made to bear the whole loss, and any split under joint culpability must be fair and proportionate, backed by evidence and checked by an independent review before the customer is told.", "citation": "BNM/RH/PD 028-139 (2024-06-28), paragraphs 9.6 to 9.9", "rests_on": "law" }, { "label": "Provisional credit", "value": "If the bank's investigation runs past 14 working days from the dispute, it must at once offer interest-free provisional credit of the disputed amount or RM5,000 per case, whichever is lower, paid once the customer accepts its terms and supplies a police report, and must credit the remainder by the 30th working day if still undecided. If the customer is later found liable the bank may ask for repayment on a reasonable timeline.", "citation": "BNM/RH/PD 028-139 (2024-06-28), paragraphs 11.1 and 11.2", "rests_on": "law" }, { "label": "E-wallets", "value": "BNM's unauthorised e-banking policy applies to banks. For e-money, BNM's e-money policy separately bars an issuer from holding a customer liable for fraud losses on transactions it chose to let through without authentication, unless it proves the customer acted fraudulently [Unverified: whether the e-money policy has a broader loss-allocation rule; only this paragraph was read closely].", "citation": "BNM/RH/PD 028-139 (2024-06-28), paragraphs 2.1 and 5.2 (definition of financial institution); BNM policy document Electronic Money, BNM/RH/PD 029-57, issued 2025-01-31, paragraph 19.12(d)", "rests_on": "law" }, { "label": "Quick reversal where a bank skips MFA", "value": "A bank that does not use MFA for transactions below RM10,000 to the customer's own account must reverse unauthorised first-party transactions within three calendar days of the customer's report.", "citation": "BNM policy document Risk Management in Technology, BNM/RH/PD 028-98, issued 2025-11-28, Appendix 3 item 8(a)", "rests_on": "law" }, { "label": "Mistaken transfers", "value": "Participants' terms place the risk of a wrong DuitNow ID or wrong recipient on the sender, exclude the bank's and the operator's liability for it unless mandatory law requires otherwise, and give the sender only the recovery process. For an unauthorised or fraudulent DuitNow transfer the same terms promise an investigation within 14 calendar days and reversal of the debit if the bank finds it occurred and was not the customer's doing.", "citation": "DuitNow Transfer Terms and Conditions of Deutsche Bank (Malaysia) Berhad, version May 2026, clauses 2.3, 2.5, 6 and 7.1; of HSBC Bank Malaysia Berhad, version October 2022 (v1.4), clauses 2.3, 2.5, 6 and 7.1", "rests_on": "practice" }, { "label": "Between participants and the operator", "value": "BNM requires the operator to manage credit, settlement and other risks and to run a dispute resolution mechanism among participants, and requires it to have rules on credit losses from a participant default. The rules allocating losses between participants, and any limit on the operator's own liability, are the operator's and are not public.", "citation": "IFTF (BNM/RH/PD 028-143, 2026-06-30) paragraph 8.15(a) and (b); BNM policy document Payment System Operator (BNM/RH/PD 029-54, 2022-12-22) paragraph 16.4", "rests_on": "law" } ], "exceptions": [ "The customer-protection paragraphs on joint culpability and provisional credit (9.7 to 9.10 and 11) apply only to individuals and micro and small enterprises; larger business customers get the rest of the policy only (BNM/RH/PD 028-139 paragraph 5.2, definition of customer).", "Scam payments the customer approved are outside BNM's unauthorised-transaction policy. BNM's Policy Document on Financial Institutions' Response to Fraud, issued 2026-06-30, may change the position for them and was not located or read [Unverified].", "Where the customer disputes the bank's decision they can take the case to the Financial Markets Ombudsman Service; a bank must not report unrepaid provisional credit to the credit bureau while an FMOS case lodged within six months is pending (BNM/RH/PD 028-139 paragraphs 10.3 and 11.4).", "Merchant disputes on DuitNow QR purchases are not covered here." ], "applies_to": "DuitNow transfers from accounts at Malaysian banks (including Islamic banks and development financial institutions) and, where stated, e-money issuers", "caveat": "The question that decides liability is not whether the payment was fraudulent but whether the customer authorised it. A customer tricked into approving a transfer is, under the published policy, an authorising customer, and the bank-bears-it default does not reach them.", "related": [ "my-duitnow:recall", "my-duitnow:finality", "my-duitnow:limits", "my-duitnow:participants" ], "basis": { "sources": "BNM policy document Ensuring Fair Treatment for Victims of Unauthorised e-Banking Transactions, BNM/RH/PD 028-139, issued 2024-06-28, effective 2024-10-01 (paragraph 4.1), fetched 2026-09-18 from https://www.bnm.gov.my/documents/20124/938039/Ensuring_Fair_Treatment_for_Victims_of_Unauthorised_eBanking-Transactions.pdf (linked from the BNM banking policy listing, 11 pages) and read in full; paragraphs 2, 5.2, 7, 8 to 12 relied on. BNM policy documents Electronic Money BNM/RH/PD 029-57 (2025-01-31) paragraph 19.12; Risk Management in Technology BNM/RH/PD 028-98 (2025-11-28) Appendix 3 item 8; IFTF BNM/RH/PD 028-143 (2026-06-30) paragraph 8.15; Payment System Operator BNM/RH/PD 029-54 (2022-12-22) paragraph 16.4: authoritative_primary. Participants' DuitNow Transfer terms: Deutsche Bank (Malaysia) Berhad May 2026 and HSBC Bank Malaysia Berhad October 2022 (common template). The interparticipant and operator liability rules are not public, hence primary_not_public and medium. BNM Terms of Use (updated November 2023) bar reproduction except as copyright law permits; nothing here is quoted. No PayNet material was consulted.", "confidence": "medium" }, "currency": { "effective_since": "2024-10-01", "effective_note": "BNM/RH/PD 028-139 took effect 2024-10-01 and superseded the 2014 circular on e-banking and payment instrument risks and the 2010 e-banking guidelines. BNM's Policy Document on Financial Institutions' Response to Fraud (2026-06-30), named in IFTF 6.1(m), was not read and may add to or change this position.", "source_edition": "BNM/RH/PD 028-139 issued 2024-06-28; E-Money BNM/RH/PD 029-57 2025-01-31; RMiT BNM/RH/PD 028-98 2025-11-28; IFTF 2026-06-30; PSO PD 2022-12-22; participant terms May 2026 and October 2022", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "primary_not_public": true, "corroboration": [ { "source_url": "https://www.bnm.gov.my/documents/20124/938039/Ensuring_Fair_Treatment_for_Victims_of_Unauthorised_eBanking-Transactions.pdf", "source_class": "authoritative_primary", "source_title": "Ensuring Fair Treatment for Victims of Unauthorised e-Banking Transactions, BNM/RH/PD 028-139, issued 28 June 2024, effective 1 October 2024", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the unauthorised transaction test turns on customer consent, not authentication, and excludes payments the customer willingly made even when deceived, giving love, investment and parcel scams as examples (paragraph 5.2). Confirms the bank must not hold the customer responsible for losses caused by the bank's own system, security, credential, staff, timing or reminder failures, or by unresolved contradictory evidence (paragraph 9.5). Confirms the bank may only hold the customer responsible if it proves fraud, refusal to cooperate, or a breach of the three named credential duties, that a customer able to be shown jointly culpable is not made to bear the full loss where the bank failed to act, and that any allocation must be evidenced and independently reviewed before the customer is told (paragraphs 9.6 to 9.9). Confirms the fourteen working day trigger for provisional credit up to the disputed amount or RM5,000 whichever is lower, disbursed once the customer agrees terms and supplies a police report, with the remainder credited by the thirtieth working day and repayment askable if the customer is later found liable (paragraphs 11.1 and 11.2). Confirms the joint culpability and provisional credit paragraphs apply only to individuals and micro and small enterprises (paragraph 5.2 definition of customer), the Financial Markets Ombudsman Service channel, and the bar on reporting unrepaid provisional credit to the credit bureau while a timely ombudsman case is pending (paragraphs 10.3 and 11.4). Does not address losses between participants or the operator's own liability, which the record marks as resting on non-public scheme rules." }, { "source_url": "https://www.hsbc.com.my/content/dam/hsbc/my/docs/ways-to-bank/duitnow/duitnow-transfer-terms-of-use.pdf", "source_class": "secondary", "source_title": "HSBC Bank Malaysia Berhad, DuitNow Transfer Terms and Conditions, version October 2022 (DuitNow Transfer v1.4)", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms a participant bank's own terms place responsibility for a correctly entered recipient on the sender, that the bank performs no independent check of the named recipient's identity, and that the bank and the DuitNow operator disclaim liability for a wrong-recipient transfer unless mandatory law forbids the disclaimer, leaving only the funds-recovery process as remedy (clauses 2.3, 2.5, 7.1). Confirms that for an unauthorised or fraudulent transfer the bank commits to a fourteen calendar day investigation and reverses the debit if it finds the transfer unauthorised or fraudulent and not caused by the customer, consistent with the bank-bears-it-by-default position in BNM's policy though far less detailed (clause 6.1). Does not address provisional credit, the burden of proof standard, or joint culpability, which rest on BNM/RH/PD 028-139 alone." } ] }, "rail_name": "Malaysia DuitNow", "governing_authority": "Bank Negara Malaysia", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "not_public", "label": "the operator's own text", "needs": "what the operator's own text says, which Orca has not read", "detail": "Bank Negara Malaysia's own text is not the source for this rail fact: it is not public, or not under terms Orca can use. It rests on 2 named public sources, so a term set by agreement rather than by a published rule is not Orca's to state.", "from": "currency.primary_not_public" } ] }, { "uid": "my-duitnow:limits", "id": "limits", "rail": "my-duitnow", "kind": "rail-fact", "facet": "limits", "name": "How much can move in one payment, and who sets the limit?", "statement": "No BNM text sets a DuitNow amount ceiling, and no scheme-wide maximum was found in any public source; whether the operator's rules set one is not public. What a customer can send is set by their own bank or e-wallet, inside BNM rules that push in two directions: customers must be able to manage their own limits online, new banking customers start at a conservative default, and e-wallets need BNM's approval to hold RM5,000 or more. Participants' published limits cluster around RM5,000 a day by default and RM50,000 a day at most. RM5,000 is also the line below which a transfer must be free, which is a fee rule, not a limit.", "details": [ { "label": "The customer controls the limit", "value": "Every bank, e-money issuer and acquirer offering fund transfers must give its consumers a convenient way to manage their transaction limits online, through its website or app.", "citation": "IFTF (BNM/RH/PD 028-143, 2026-06-30) paragraph 10.1(a) (standard)", "rests_on": "law" }, { "label": "Conservative defaults for new bank customers", "value": "For a new digital banking customer, BNM's technology risk policy has banks start the transfer limit low, giving about RM1,000 a day as an example, and lets the customer raise it only through a secure channel such as MFA-protected online banking or a branch, with verification and a cooling-off period on first enrolment and on limit increases.", "citation": "BNM policy document Risk Management in Technology (RMiT), BNM/RH/PD 028-98, issued 2025-11-28, Appendix 3 item 1(i) and 1(j)", "rests_on": "law" }, { "label": "When a bank skips MFA", "value": "A bank that chooses not to use multi-factor authentication for financial transactions below RM10,000 to the customer's own account must instead set per-transaction and cumulative limits, let the customer lower them or switch MFA on, and reverse unauthorised first-party transactions within three calendar days of the customer's report.", "citation": "BNM policy document RMiT (BNM/RH/PD 028-98, 2025-11-28), Appendix 3 item 8", "rests_on": "law" }, { "label": "E-wallet ceilings", "value": "An e-money issuer sets a wallet limit suited to its product, needs BNM's prior written approval to take the limit to RM5,000 or more, and must notify BNM before smaller increases. Open third-party transfers of RM10,000 or more from an e-wallet require stronger multi-factor authentication. Below RM10,000 an issuer may use lighter authentication for transactions it rates low risk, but if it drops MFA it must set per-transaction and cumulative limits that the customer can reduce.", "citation": "BNM policy document Electronic Money (E-Money), BNM/RH/PD 029-57, issued 2025-01-31, paragraphs 20.6 to 20.9, 19.13, 28.74, 28.75 and footnote 17", "rests_on": "law" }, { "label": "What participants publish", "value": "Two participants, in their own words, publish a default daily DuitNow transfer limit of RM5,000 and a maximum of RM50,000, combined with other transfers from the same account. The bank among them caps non-residents at RM10,000 a day. The digital bank among them sets a separate, lower daily limit for QR payments to merchants.", "citation": "GXBank DuitNow Services FAQ, effective 2024-03-22, sections A and B; Bank Islam Malaysia Berhad DuitNow FAQ (FAQ/DUITNOW/2024/V.02), question 16", "rests_on": "practice" }, { "label": "RM5,000 is a fee threshold", "value": "A participant must offer DuitNow Transfer free to consumers, as sender or recipient, for transfers up to RM5,000 funded from a current, savings or e-money account; BNM may change the amount. Above it a participant may charge. One participant says a 50 sen fee applies above RM5,000 and that it waives it; another lists a 50 sen fee from 2024-06-01 in its FAQ while its product page shows transfers above RM5,000 as free [Unverified: which is current].", "citation": "IFTF (BNM/RH/PD 028-143, 2026-06-30) paragraph 9.15 and footnote 17; GXBank DuitNow Services FAQ (2024-03-22), section A; Bank Islam Malaysia Berhad DuitNow FAQ (FAQ/DUITNOW/2024/V.02), question 15", "rests_on": "law" } ], "exceptions": [ "The free-transfer rule does not apply to customers whose relationship with the institution is as a merchant (IFTF 9.15 footnote 17).", "Corporate customers of banks that serve large businesses may have limits set by contract; no BNM text or participant page read for this record gives them.", "Cross-border DuitNow transfers may carry other limits, including under foreign exchange rules; none were read for this record.", "Whether the operator's rules impose a per-transaction maximum on the RPP is not public; the RM50,000 figures above are individual participants' own caps, not a scheme cap." ], "applies_to": "DuitNow Transfer and DuitNow QR sent by consumers from Malaysian bank and e-money accounts", "caveat": "Do not quote a DuitNow limit as a network number. The answer is always the sending institution's limit for that customer, which the customer may lower and, subject to verification and a cooling-off period, raise.", "related": [ "my-duitnow:participants", "my-duitnow:hours" ], "basis": { "sources": "IFTF BNM/RH/PD 028-143, 2026-06-30 (paragraphs 9.15 and 10.1(a), footnote 17); Risk Management in Technology BNM/RH/PD 028-98, 2025-11-28 (Appendix 3 items 1 and 8); Electronic Money BNM/RH/PD 029-57, 2025-01-31 (paragraphs 19.13, 20.6 to 20.9, 28.74, 28.75, footnote 17): authoritative_primary, all read from bnm.gov.my. Participants' published figures: GXBank DuitNow Services FAQ effective 2024-03-22 (gxbank.my) and Bank Islam Malaysia Berhad DuitNow FAQ FAQ/DUITNOW/2024/V.02 (bankislam.com), each in its own wording. The absence of a scheme cap rests on no source stating one, and the operator's rules are not public, hence primary_not_public and medium. BNM Terms of Use (updated November 2023) bar reproduction except as copyright law permits; nothing here is quoted. No PayNet material was consulted.", "confidence": "medium" }, "currency": { "effective_since": "2026-06-30", "effective_note": "Dated from the IFTF, which carries the online limit-management duty and the RM5,000 free-transfer threshold. The RMiT edition read is 2025-11-28 and the E-Money edition 2025-01-31. Participants' published limits and fees are as read 2026-09-18 and are each participant's to change.", "source_edition": "IFTF BNM/RH/PD 028-143 2026-06-30; RMiT BNM/RH/PD 028-98 2025-11-28; E-Money BNM/RH/PD 029-57 2025-01-31; GXBank FAQ 2024-03-22; Bank Islam FAQ V.02 2024", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "primary_not_public": true, "corroboration": [ { "source_url": "https://www.bnm.gov.my/documents/20124/943361/27012025_Revised_E-Money_PD_v2.pdf", "source_class": "authoritative_primary", "source_title": "Electronic Money, BNM/RH/PD 029-57, issued 31 January 2025", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms paragraph 20.8: an e-money issuer needs BNM's prior written approval to raise a wallet limit to RM5,000 or more, and 20.9: must notify BNM 14 days ahead of a smaller increase. Confirms 19.12(d): where an issuer skips authentication on an online payment it may not hold the customer liable for fraud losses unless it proves fraud, and 19.13 on reducing limits. Confirms footnote 17 (RMiT read separately below) on the RM10,000 stronger-MFA threshold." }, { "source_url": "https://www.bnm.gov.my/documents/20124/938039/pd-rmit-nov25.pdf", "source_class": "authoritative_primary", "source_title": "Risk Management in Technology, BNM/RH/PD 028-98, issued 28 November 2025", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms Appendix 3 item 1(i) and (j): a new digital banking customer starts at a conservative default such as RM1,000 a day, raised only through a secure channel with verification and a cooling off period, and item 8: a bank skipping MFA below RM10,000 to the customer's own account must set reducible per-transaction and cumulative limits." }, { "source_url": "https://gxbank.my/docs/terms/DuitNow%20Services%20-%20Frequently%20Asked%20Questions%20%28FAQ%29.pdf", "source_class": "secondary", "source_title": "DuitNow Services Frequently Asked Questions, GXBank, effective 22 March 2024", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the published RM5,000 default and RM50,000 maximum daily DuitNow transfer limit, the separate lower QR merchant payment daily limit, and the 50 sen fee above RM5,000 that GXBank currently waives. Does not address the non-resident RM10,000 cap or the fee-versus-free discrepancy attributed to a second bank's FAQ and product page; that bank's site could not be reliably fetched, so those two lines are not independently confirmed." } ] }, "rail_name": "Malaysia DuitNow", "governing_authority": "Bank Negara Malaysia", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "not_public", "label": "the operator's own text", "needs": "what the operator's own text says, which Orca has not read", "detail": "Bank Negara Malaysia's own text is not the source for this rail fact: it is not public, or not under terms Orca can use. It rests on 3 named public sources, so a term set by agreement rather than by a published rule is not Orca's to state.", "from": "currency.primary_not_public" } ] }, { "uid": "my-duitnow:messages", "id": "messages", "rail": "my-duitnow", "kind": "rail-fact", "facet": "messages", "name": "What messages carry a payment and its exceptions on this rail?", "statement": "BNM does not publish DuitNow's message set. It requires the operator to write the technical standards, API standards, communication protocols, QR standards and addressing-database procedures that make transfers interoperable, and those belong to the operator. The operator's own documentation was deliberately not consulted for this record under Orca's decision on its terms of use. What public BNM and participant sources do show is the shape of the customer flow: a transfer is addressed either by account number or by a DuitNow ID looked up in the National Addressing Database, the payer sees the registered recipient name before confirming, and both sides get an instant notification. BNM's own settlement messages for RENTAS use ISO 20022.", "details": [ { "label": "Who writes the standards", "value": "The operator of the shared payment infrastructure must develop the technical standards and business rules for interoperability, including secure QR standards, API standards, communication protocols and the operating procedures for populating and running the National Addressing Database. Other operators that enable QR payments in Malaysia must adopt its interoperable QR standard.", "citation": "IFTF (BNM/RH/PD 028-143, 2026-06-30) paragraphs 8.2(a) and 8.6", "rests_on": "law" }, { "label": "Addressing by identifier", "value": "The National Addressing Database links a bank or e-money account to an identifier the account holder already has, such as a national identity card (NRIC) or passport number, a mobile number, or a company or business registration number, so a payment can be addressed to the identifier instead of the account. Participants must let their consumers register in it.", "citation": "IFTF (BNM/RH/PD 028-143, 2026-06-30) paragraph 5.2 (definition of National Addressing Database) and paragraph 9.2(b)", "rests_on": "law" }, { "label": "Name check before paying", "value": "When a customer pays a DuitNow ID, the paying bank looks the identifier up in the addressing database and shows the registered recipient's name for the customer to check before confirming. Participants limit repeated lookups that are not followed by a confirmed transfer and may suspend a customer's use of the service for suspicious patterns of lookups.", "citation": "DuitNow Transfer Terms and Conditions of Deutsche Bank (Malaysia) Berhad, version May 2026, clauses 2.2 and 3; of HSBC Bank Malaysia Berhad, version October 2022 (v1.4), clauses 2.2 and 3 (the latter stating a limit of five consecutive lookups)", "rests_on": "practice" }, { "label": "Status back to the customer", "value": "Participants tell the customer whether each transfer succeeded, failed or was rejected, and BNM requires an instant notification to the payer from the payer's institution and to the payee from the payee's.", "citation": "DuitNow Transfer Terms and Conditions of Deutsche Bank (Malaysia) Berhad, version May 2026, clause 2.4; IFTF (BNM/RH/PD 028-143, 2026-06-30) paragraph 10.1(b), footnotes 18 and 19", "rests_on": "practice" }, { "label": "Settlement leg", "value": "The operator streams each completed RPP transaction to BNM's NRTS module line by line. BNM's RENTAS procedures record the completion of RENTAS's own migration to ISO 20022 messages; the format of the RPP-to-NRTS stream is not described in them [Unverified].", "citation": "BNM Operational Procedures for MYR Settlement in RENTAS (BNM/RH/PD 028-28, version 1.8, 2025-09-29), clause 38.2 and revision history for version 1.8 (removal of the ISO 20022 onboarding appendices)", "rests_on": "rule" } ], "exceptions": [ "The operator's message catalogue, status and reason codes, and API specifications are held under the operator's own terms of use, which bar reproduction and derivative works; Orca has not decided whether to use them, so none of their content appears here (docs/rails/my-duitnow.md).", "DuitNow QR, Request, AutoDebit and cross-border flows have their own message flows, none of which is described in a BNM text read.", "Identifier types accepted can vary by participant and customer type; one participant's page limits which identifiers each customer type may register [Unverified: whether this is a scheme rule]." ], "applies_to": "DuitNow Transfer between Malaysian bank and e-money participants on the RPP", "caveat": "This record is deliberately thin. An integrator needs the operator's technical standards, which are available to participants and under terms Orca has not accepted; nothing here substitutes for them.", "related": [ "my-duitnow:participants", "my-duitnow:settlement", "my-duitnow:return" ], "basis": { "sources": "IFTF BNM/RH/PD 028-143 (2026-06-30) paragraphs 5.2, 8.2, 8.6, 9.2, 10.1; BNM Operational Procedures for MYR Settlement in RENTAS BNM/RH/PD 028-28 version 1.8 (2025-09-29) clause 38.2 and revision history: authoritative_primary. Participants' DuitNow Transfer terms, Deutsche Bank (Malaysia) Berhad May 2026 and HSBC Bank Malaysia Berhad October 2022 (common template). The operator's technical standards are not public in the sense Orca can use, hence primary_not_public. Confidence is low because the facet's core, the message set, is not answered. No PayNet material was consulted.", "confidence": "low" }, "currency": { "effective_since": "2026-06-30", "effective_note": "Dated from the IFTF, which assigns standard-setting to the operator. The participant terms describing the name check date from at least October 2022.", "source_edition": "IFTF 2026-06-30; RENTAS MYR Operational Procedures v1.8 2025-09-29; participant terms May 2026 and October 2022", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "primary_not_public": true, "corroboration": [ { "source_url": "https://www.bnm.gov.my/documents/20124/943361/pd_IFTF_June2026.pdf", "source_class": "authoritative_primary", "source_title": "Interoperable Fund Transfer Framework, BNM/RH/PD 028-143, issued 30 June 2026", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms paragraph 8.2(a): the operator must develop technical standards and business rules including QR standards, API standards, communication protocols and NAD operating procedures, and 8.6: other QR operators must adopt the operator's interoperable QR standard. Confirms paragraph 5.2's National Addressing Database definition and 9.2(b)'s registration duty, and 10.1(b) and footnotes 18 and 19's instant notification duty." }, { "source_url": "https://www.hsbc.com.my/content/dam/hsbc/my/docs/ways-to-bank/duitnow/duitnow-transfer-terms-of-use.pdf", "source_class": "secondary", "source_title": "DuitNow Transfer Terms and Conditions, HSBC Bank Malaysia Berhad, version October 2022 (v1.4), marked Public", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms clause 2.2: the bank performs a Name Enquiry and displays the registered recipient's name before confirmation, clause 3: a limit of five consecutive Name Enquiries without a confirmed transfer before results stop displaying, and clause 2.4: the bank notifies the customer of each successful, failed or rejected transfer. Independent of Bank Negara Malaysia; distinct organisation and host." } ] }, "rail_name": "Malaysia DuitNow", "governing_authority": "Bank Negara Malaysia", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "not_public", "label": "the operator's own text", "needs": "what the operator's own text says, which Orca has not read", "detail": "Bank Negara Malaysia's own text is not the source for this rail fact: it is not public, or not under terms Orca can use. It rests on 2 named public sources, so a term set by agreement rather than by a published rule is not Orca's to state.", "from": "currency.primary_not_public" } ] }, { "uid": "my-duitnow:participants", "id": "participants", "rail": "my-duitnow", "kind": "rail-fact", "facet": "participants", "name": "Who can be on this rail, in what roles, and who cannot?", "statement": "In Malaysia, being on DuitNow is mostly a duty rather than a choice. Bank Negara Malaysia requires every bank and every e-wallet issuer that meets its eligibility test to join the shared payment infrastructure, which today means the Real-time Retail Payments Platform (RPP) run by PayNet, and to let its customers send to and receive from any other participant. Acquirers that join must accept interoperable QR payments. Beyond the mandated group, the operator must admit any financial institution or other Malaysian regulated entity that passes objective, risk-based access criteria, directly or through a sponsor, and must publish its access requirements and the names of its participants.", "details": [ { "label": "Which infrastructure this is", "value": "BNM's framework speaks of a shared payment infrastructure, which it defines as a payment system BNM determines, located in Malaysia, that carries inter-bank and inter-scheme transfers processed domestically. BNM names the RPP operated by Payments Network Malaysia Sdn Bhd (PayNet) as the only one at present, and says any change to that list will come through the framework or a supplementary document. DuitNow is the name the framework uses for the transfer service on the RPP.", "citation": "BNM policy document Interoperable Fund Transfer Framework (IFTF), BNM/RH/PD 028-143, issued 2026-06-30, paragraph 5.2 (definitions of shared payment infrastructure and eligible domestic fund transfer transaction) and footnote 12", "rests_on": "law" }, { "label": "Who must join", "value": "Banking institutions (licensed banks including digital banks, licensed Islamic banks, and prescribed development financial institutions) and eligible e-money issuers must participate, must let their customers make account-to-account transfers with customers of any other participant, and must let customers register account details and identifiers in the National Addressing Database. The same two groups must enable interoperable QR purchases for the retail segment.", "citation": "IFTF (BNM/RH/PD 028-143, 2026-06-30) paragraphs 9.2 and 9.6 (standards), paragraph 5.2 (definition of banking institution and footnote 8 on digital banks), and paragraph 2.2 (applicability table); IFTF feedback statement dated 2026-06-30, paragraph 1.5, on the retail-only scope of the QR mandate", "rests_on": "law" }, { "label": "Which e-wallets are outside the mandate", "value": "The mandate reaches eligible e-money issuers offering network-based e-money, meaning e-wallets run through apps or the internet. A standard e-money issuer and a limited purpose e-money issuer are not required to participate, and an acquirer contracted with such a non-participating issuer may run a closed QR scheme for that issuer's own users.", "citation": "IFTF (BNM/RH/PD 028-143, 2026-06-30) paragraph 2.2 footnote 2, paragraph 9.13 (guidance) and footnote 16", "rests_on": "law" }, { "label": "Acquirers", "value": "A registered merchant acquirer that participates must let its merchants take QR payments from customers of any participant, may not run or offer its own proprietary QR network, and must let a merchant choose which network routes its payments where the acquirer sits on more than one. Existing proprietary QR networks must be closed by 2028-06-30 and may take no new merchants meanwhile.", "citation": "IFTF (BNM/RH/PD 028-143, 2026-06-30) paragraphs 9.10 and 9.12, Appendix II", "rests_on": "law" }, { "label": "Open access for others", "value": "The operator must admit any financial institution or other regulated entity in Malaysia that meets objective, non-discriminatory and risk-based requirements covering settlement, operational and business risk. An applicant regulated by a body other than BNM must show, through an independent external assessment, that it meets BNM standards in areas that include financial strength, technology and cyber risk, liquidity and settlement risk, onboarding, customer protection, and AML/CFT.", "citation": "IFTF (BNM/RH/PD 028-143, 2026-06-30) paragraphs 8.8, 8.9 and 8.10, Appendix I", "rests_on": "law" }, { "label": "Admission, refusal and appeal", "value": "The operator must publish its access requirements, its application procedure and the names of all approved participants on its website, must tell applicants how long a decision and an appeal will take, and must give a written decision. A refused applicant, or one that disputes the conditions imposed, can appeal to a board committee chaired by, and made up mostly of, independent directors.", "citation": "IFTF (BNM/RH/PD 028-143, 2026-06-30) paragraphs 8.11, 8.12 and 8.13", "rests_on": "law" }, { "label": "Direct or sponsored", "value": "The operator decides whether an applicant joins directly or indirectly through a sponsor, in proportion to its size and risk. A sponsor must set and publish its own objective access requirements and a description of its sponsorship services, and must periodically review the institutions it sponsors.", "citation": "IFTF (BNM/RH/PD 028-143, 2026-06-30) paragraphs 8.18 and 8.19; BNM policy document Payment System Operator, BNM/RH/PD 029-54, issued 2022-12-22, paragraph 24.3 on tiered participation", "rests_on": "law" }, { "label": "Every inter-bank transfer goes this way", "value": "A financial institution must route inter-bank and inter-scheme transfers through the shared payment infrastructure. It may also use another approved operator's transfer service, but only one that interoperates with the shared infrastructure. BNM's feedback statement adds that QR transfers inside one institution (on-us) must also go through the shared infrastructure, for system-wide fraud monitoring.", "citation": "IFTF (BNM/RH/PD 028-143, 2026-06-30) paragraph 8.4 (standard) and paragraph 8.5 (guidance); IFTF feedback statement dated 2026-06-30, paragraph 3.2", "rests_on": "law" }, { "label": "Removal", "value": "The operator must have rules defining when a participant's access may be withdrawn, suspended or terminated, and must give the participant adequate notice and a reasonable chance to make representations first. The rules themselves are the operator's and are not public.", "citation": "IFTF (BNM/RH/PD 028-143, 2026-06-30) paragraph 8.15(d); BNM policy document Payment System Operator (BNM/RH/PD 029-54, 2022-12-22) paragraph 24.5", "rests_on": "law" } ], "exceptions": [ "Access is today limited to regulated entities in Malaysia; BNM says it is open to engaging other institutions but has not changed the rule (IFTF feedback statement 2026-06-30, paragraph 3.1).", "Standard and limited purpose e-money issuers are not mandated to join, and a proprietary QR scheme serving only one such issuer's users is permitted (IFTF 9.13 and footnote 16).", "The QR purchase mandate applies only to participants offering QR purchases to retail customers and merchants; an institution serving only large corporates is outside it (IFTF feedback statement 2026-06-30, paragraph 1.5).", "Cross-border participation duties (IFTF 9.3, 9.4, 9.8, 9.11) start on a Nexus go-live date BNM has not yet announced (IFTF Appendix II).", "The list of approved participants that the operator must publish was not read for this record, so no participant count is stated." ], "applies_to": "banks, e-money issuers, merchant acquirers and other regulated entities in Malaysia connecting to the shared payment infrastructure (the RPP) for DuitNow transfers and DuitNow QR", "caveat": "Mandated participation is not the same as a given customer being reachable. A customer receives by account number at any participant, but receives by DuitNow ID only after registering that ID in the National Addressing Database through their own institution.", "related": [], "basis": { "sources": "BNM policy document Interoperable Fund Transfer Framework, BNM/RH/PD 028-143, issued and effective 2026-06-30, read in full from bnm.gov.my: paragraphs 2.2, 5.2, 8.4 to 8.19, 9.2, 9.6, 9.10 to 9.13, footnotes 2, 8, 12 and 16, Appendices I and II. BNM Feedback Statement on the IFTF policy document, dated 2026-06-30, paragraphs 1.5, 3.1 and 3.2. BNM policy document Payment System Operator, BNM/RH/PD 029-54, issued 2022-12-22, paragraphs 24.1 to 24.5. All authoritative_primary or public_primary from the governing authority. BNM's Terms of Use (updated November 2023) bar reproduction and derivative works of site content except as copyright law permits; this record cites and paraphrases and quotes nothing. No PayNet material was consulted.", "confidence": "high" }, "currency": { "effective_since": "2026-06-30", "effective_note": "The IFTF took effect 2026-06-30 and superseded the Interoperable Credit Transfer Framework of 2019-12-23 (IFTF 4.1, 7.1). Paragraphs 9.3, 9.4, 9.7(b), 9.8, 9.11 and 9.12(b) run on the Appendix II timelines: proprietary QR networks close by 2028-06-30; cross-border duties start on a Nexus date BNM will announce.", "source_edition": "IFTF BNM/RH/PD 028-143 issued 2026-06-30; IFTF feedback statement 2026-06-30; Payment System Operator BNM/RH/PD 029-54 issued 2022-12-22", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.bnm.gov.my/documents/20124/943361/pd_IFTF_June2026.pdf", "source_class": "authoritative_primary", "source_title": "Interoperable Fund Transfer Framework, BNM/RH/PD 028-143, issued 30 June 2026", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the shared payment infrastructure definition and the naming of the RPP, the mandatory participation duty for banking institutions and eligible e-money issuers, the acquirer QR duty, the fair and open access criteria and admission and appeal process in paragraphs 8.8 to 8.13, the sponsorship duties in 8.18 and 8.19, the routing duty in 8.4, and the removal rule in 8.15(d). The retail-only scope of the QR mandate is confirmed against the feedback statement paragraph 1.5, read in the same fetch." } ] }, "rail_name": "Malaysia DuitNow", "governing_authority": "Bank Negara Malaysia", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "my-duitnow:recall", "id": "recall", "rail": "my-duitnow", "kind": "rail-fact", "facet": "recall", "name": "Can the sender or the sending bank pull a payment back, and how?", "statement": "A sender cannot cancel a confirmed DuitNow transfer. What participants offer instead is a recovery process for a transfer sent to the wrong person by mistake, run by the sender's bank with the recipient's institution. How much control the recipient has depends on how late the sender asks: early on, recovery turns on whether the money is still in the recipient's account; in the middle period, the recipient can block it only by showing entitlement; after seven months, nothing moves without the recipient's consent. The process is published only in participants' customer terms, which share one template; the operator's rule behind it is not public, and no BNM text read sets it.", "details": [ { "label": "No cancellation", "value": "Once confirmed, a DuitNow transfer cannot be cancelled, stopped or changed by the customer.", "citation": "DuitNow Transfer Terms and Conditions of Deutsche Bank (Malaysia) Berhad, version May 2026, clause 2.6; of HSBC Bank Malaysia Berhad, version October 2022 (v1.4), clause 2.6", "rests_on": "practice" }, { "label": "Who may start a recovery", "value": "The sender, through their own bank, for a transfer the sender made in error. The sender's bank then works with the recipient's bank or e-money issuer; the recipient's institution decides whether the credit was in fact erroneous.", "citation": "DuitNow Transfer Terms and Conditions of Deutsche Bank (Malaysia) Berhad, version May 2026, clauses 4.1 and 5; of HSBC Bank Malaysia Berhad, version October 2022, clauses 4.1 and 5", "rests_on": "practice" }, { "label": "How the clock changes the outcome", "value": "Measured from the transaction date: a request made after seven months needs the recipient's consent, which the recipient's institution seeks within 10 business days and, once given, remits within 1 business day. A request made from the 11th business day up to seven months lets the recipient's institution notify the recipient and debit the account unless the recipient shows reasonable evidence of entitlement, with the terms giving 10 and 15 business day marks for that exchange. A request within 10 business days is aimed at return of the funds within 7 business days, if the credit was wrong and the recipient's balance can cover it.", "citation": "DuitNow Transfer Terms and Conditions of Deutsche Bank (Malaysia) Berhad, version May 2026, clauses 5.1 to 5.3; of HSBC Bank Malaysia Berhad, version October 2022 (v1.4), clauses 5.1 to 5.3", "rests_on": "practice" }, { "label": "Money may be gone", "value": "Recovery is limited by what is left in the recipient's account. If the balance falls short, the sender may get only part of the money back, or none.", "citation": "DuitNow Transfer Terms and Conditions of Deutsche Bank (Malaysia) Berhad, version May 2026, clause 5.1.2; of HSBC Bank Malaysia Berhad, version October 2022, clause 5.1.2", "rests_on": "practice" }, { "label": "The sender carries the risk of a wrong entry", "value": "The terms place responsibility for entering the right DuitNow ID and checking the displayed recipient name on the sender, and exclude the bank's and the operator's liability for a transfer to the wrong ID or recipient, unless mandatory law says otherwise.", "citation": "DuitNow Transfer Terms and Conditions of Deutsche Bank (Malaysia) Berhad, version May 2026, clauses 2.3, 2.5 and 7.1.2; of HSBC Bank Malaysia Berhad, version October 2022, clauses 2.3, 2.5 and 7.1.2", "rests_on": "practice" }, { "label": "No interbank recall message is published", "value": "No BNM text read describes a recall or cancellation request between participants for a settled RPP transfer. Any such message, and the scheme rule the recovery process implements, would be in the operator's technical standards and rules, which are not public [Inference: the common wording across participants suggests a scheme rule].", "citation": "IFTF (BNM/RH/PD 028-143, 2026-06-30) paragraphs 8.2(a) and 8.14; BNM policy document Payment System Operator (BNM/RH/PD 029-54, 2022-12-22) paragraph 26.1", "rests_on": "law" } ], "exceptions": [ "The process is for mistaken transfers. An unauthorised or fraudulent transfer follows a different route: the paying bank investigates within 14 calendar days under the same terms, and for banks BNM's policy on unauthorised e-banking transactions governs who bears the loss (see the liability fact).", "A payment the customer made willingly to a scammer is neither a mistake of entry nor, under BNM's definition, unauthorised; no source read says whether the recovery process applies to it.", "The two sets of terms read are a common template; a participant may word or apply the process differently, and e-wallet issuers' terms were not read.", "DuitNow QR, Request and AutoDebit may have their own recovery or refund provisions, not read for this record." ], "applies_to": "a DuitNow Transfer sent in error by a customer of a Malaysian bank participant", "caveat": "Two banks' terms in identical wording count as one published source, not two, for Orca's independence test. Before this record can be corroborated it needs a source in independent wording, such as a participant FAQ or a BNM or ombudsman publication that describes the same windows.", "related": [ "my-duitnow:finality", "my-duitnow:hours" ], "basis": { "sources": "Participants' published DuitNow Transfer terms: Deutsche Bank (Malaysia) Berhad, version May 2026 (country.db.com), and HSBC Bank Malaysia Berhad, version October 2022 v1.4 marked Public (hsbc.com.my), clauses 2 to 7; their wording is near identical. A third bank's copy of the same terms is marked confidential in its footer and was not used. BNM texts for what is and is not published: IFTF BNM/RH/PD 028-143 (2026-06-30) paragraphs 8.2 and 8.14; Payment System Operator BNM/RH/PD 029-54 (2022-12-22) paragraph 26.1. The operator's rule is not public, hence primary_not_public; the sources are secondary and not independent of each other, hence medium at most. No PayNet material was consulted.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_note": "The same windows appear in HSBC's October 2022 terms and Deutsche Bank's May 2026 terms, so they have been stable since at least October 2022. When the process began is not stated in either.", "source_edition": "Deutsche Bank (Malaysia) Berhad DuitNow Transfer Terms and Conditions, version May 2026; HSBC Bank Malaysia Berhad DuitNow Transfer Terms and Conditions vOct2022 (v1.4)", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "primary_not_public": true, "corroboration": [] }, "rail_name": "Malaysia DuitNow", "governing_authority": "Bank Negara Malaysia", "snapshot": "2026-09-18", "source_class": null, "effective_status": "draft", "effective_status_reason": null, "boundaries": [ { "kind": "not_public", "label": "the operator's own text", "needs": "what the operator's own text says, which Orca has not read", "detail": "Bank Negara Malaysia's own text is not the source for this rail fact: it is not public, or not under terms Orca can use. It rests on 0 named public sources, so a term set by agreement rather than by a published rule is not Orca's to state.", "from": "currency.primary_not_public" } ] }, { "uid": "my-duitnow:refund", "id": "refund", "rail": "my-duitnow", "kind": "rail-fact", "facet": "refund", "name": "Does the payer have a right to get money back, and on what terms?", "statement": "A payer who authorised a DuitNow transfer has no general right, in any BNM text read, to have it refunded. DuitNow Transfer is a credit push the payer approves, so there is no mandate to dispute and no no-questions refund window of the kind a direct debit carries. Money comes back to a payer through three narrower routes: the bank's liability for unauthorised transactions, the recovery process for a transfer sent to the wrong person, and the bank's complaint process leading to the Financial Markets Ombudsman Service. A merchant refunding a DuitNow QR purchase does so under arrangements not described in any public source read.", "details": [ { "label": "No refund right for an authorised transfer", "value": "BNM's consumer duties for fund transfers cover limits, notifications, balances, disclosure, data protection and fraud alerts; none gives a payer a right to reverse a transfer they authorised. BNM's unauthorised-transaction policy expressly leaves out payments the customer knowingly approved [Inference: no refund right exists in BNM text; the operator's rules are not public].", "citation": "IFTF (BNM/RH/PD 028-143, 2026-06-30) paragraphs 10.1 to 10.3; BNM policy document Ensuring Fair Treatment for Victims of Unauthorised e-Banking Transactions (BNM/RH/PD 028-139, 2024-06-28) paragraph 5.2", "rests_on": "law" }, { "label": "Unauthorised payments", "value": "Where a payment from a bank account was not authorised, the bank carries the loss unless it proves one of the narrow customer failures BNM allows, and must give provisional credit if its investigation runs past 14 working days. This is the closest thing on DuitNow to a refund right, and it is a liability rule, not a refund of an authorised payment.", "citation": "BNM/RH/PD 028-139 (2024-06-28), paragraphs 9.5, 9.6 and 11.1", "rests_on": "law" }, { "label": "Mistaken payments", "value": "A payer who sent money to the wrong person can ask for recovery through their bank; whether and how much comes back depends on timing, the recipient's balance and, after seven months, the recipient's consent.", "citation": "DuitNow Transfer Terms and Conditions of Deutsche Bank (Malaysia) Berhad, version May 2026, clause 5; of HSBC Bank Malaysia Berhad, version October 2022 (v1.4), clause 5", "rests_on": "practice" }, { "label": "Complaint and ombudsman", "value": "A consumer unhappy with any outcome can complain to the institution, which must acknowledge within the next working day and decide within 5 working days for a simple case or 20 for a complex one, with 10 more where third-party documents such as police reports are needed. The institution must then point an eligible complainant to the Financial Markets Ombudsman Service, or to BNM's BNMLINK where the case is outside the ombudsman's remit.", "citation": "BNM policy document Complaints Handling, BNM/RH/PD 028-137, issued 2025-03-28, effective 2026-04-01 (paragraphs 12.1 to 12.4 from 2025-03-28), paragraphs 11.3, 11.5, 11.6, 11.8, 12.3 and 12.4", "rests_on": "law" }, { "label": "E-wallet balance refunds are something else", "value": "An e-money issuer must refund a customer's e-money balance at no extra cost within 14 days, or 30 for complex cases, when the customer closes the account, was wrongly charged, or disputes a transaction. That is a refund of stored value by the issuer, not a reversal of a DuitNow payment to its recipient [Inference].", "citation": "BNM policy document Electronic Money (BNM/RH/PD 029-57, 2025-01-31), paragraphs 20.10 to 20.14", "rests_on": "law" } ], "exceptions": [ "DuitNow QR purchase refunds from merchant to customer, and any refund feature on DuitNow Request, are not described in any BNM text or participant page read for this record [Unverified].", "BNM's Policy Document on Financial Institutions' Response to Fraud, issued 2026-06-30, was not located or read and may create a route back for scam victims [Unverified].", "The ombudsman's jurisdiction has a monetary limit set in regulations under the FSA, not read for this record (Complaints Handling policy document, footnote 13)." ], "applies_to": "consumers and micro and small businesses paying by DuitNow Transfer from Malaysian bank and e-money accounts", "caveat": "A customer who says they want a DuitNow payment refunded usually means one of three different things: they did not make it, they sent it to the wrong person, or they were deceived into making it. The first has BNM-backed protection, the second has a recovery process that depends on the recipient's balance, and the third has, in the texts read, only the complaint route.", "related": [ "my-duitnow:liability", "my-duitnow:recall", "my-duitnow:finality" ], "basis": { "sources": "BNM policy documents: IFTF BNM/RH/PD 028-143 (2026-06-30) paragraphs 10.1 to 10.3; Ensuring Fair Treatment for Victims of Unauthorised e-Banking Transactions BNM/RH/PD 028-139 (2024-06-28) paragraphs 5.2, 9.5, 9.6, 11.1; Complaints Handling BNM/RH/PD 028-137 (issued 2025-03-28, effective 2026-04-01) paragraphs 11 and 12; Electronic Money BNM/RH/PD 029-57 (2025-01-31) paragraphs 20.10 to 20.14: authoritative_primary. Participants' DuitNow Transfer terms: Deutsche Bank (Malaysia) Berhad May 2026 and HSBC Bank Malaysia Berhad October 2022 (common template). The central claim is an absence in BNM text and the operator's rules are not public, hence primary_not_public and medium. BNM Terms of Use (updated November 2023) bar reproduction except as copyright law permits; nothing here is quoted. No PayNet material was consulted.", "confidence": "medium" }, "currency": { "effective_since": "2026-06-30", "effective_note": "Dated from the IFTF's consumer duties. The complaints-handling timelines apply from 2026-04-01; the ombudsman referral duty from 2025-03-28.", "source_edition": "IFTF 2026-06-30; BNM/RH/PD 028-139 2024-06-28; Complaints Handling BNM/RH/PD 028-137 2025-03-28; E-Money BNM/RH/PD 029-57 2025-01-31; participant terms May 2026 and October 2022", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "primary_not_public": true, "corroboration": [ { "source_url": "https://www.bnm.gov.my/documents/20124/938039/PD_Complaints_Handling.pdf", "source_class": "authoritative_primary", "source_title": "Complaints Handling, BNM/RH/PD 028-137, issued 28 March 2025, effective 1 April 2026", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the complaint and ombudsman route: acknowledgement by the next working day, decision within 5 working days for a simple case or 20 for a complex one with a 10 day extension where third party documents are needed, and referral to the Financial Markets Ombudsman Service or BNMLINK, per paragraphs 11.3, 11.5 to 11.8 and 12.3 to 12.4. Does not confirm the unauthorised payments detail, which cites BNM/RH/PD 028-139, a document not located on bnm.gov.my." }, { "source_url": "https://www.hsbc.com.my/content/dam/hsbc/my/docs/ways-to-bank/duitnow/duitnow-transfer-terms-of-use.pdf", "source_class": "secondary", "source_title": "DuitNow Transfer Terms and Conditions, HSBC Bank Malaysia Berhad, version October 2022 (v1.4), marked Public", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms clause 5: a mistaken payment can be pursued through a bank recovery process whose outcome depends on timing, the recipient's balance and, after seven months, the recipient's consent. Independent of Bank Negara Malaysia; distinct organisation and host." } ] }, "rail_name": "Malaysia DuitNow", "governing_authority": "Bank Negara Malaysia", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "not_public", "label": "the operator's own text", "needs": "what the operator's own text says, which Orca has not read", "detail": "Bank Negara Malaysia's own text is not the source for this rail fact: it is not public, or not under terms Orca can use. It rests on 2 named public sources, so a term set by agreement rather than by a published rule is not Orca's to state.", "from": "currency.primary_not_public" } ] }, { "uid": "my-duitnow:return", "id": "return", "rail": "my-duitnow", "kind": "rail-fact", "facet": "return", "name": "Can the receiving side send a payment back, on what grounds, and by when?", "statement": "No public source read describes a return right for the receiving participant on DuitNow: no return message, no list of grounds, no deadline. What is published is narrower. A transfer that does not complete is reversed to the payer automatically, according to at least one participant, and a transfer that completed by mistake can come back only through the sender-initiated recovery process. Whether the operator's rules let a receiving participant return a settled credit on its own initiative, for example for a closed or blocked account, is set in rules that are not public. This record therefore says what is unknown rather than what is absent.", "details": [ { "label": "Failed transfers come back automatically", "value": "One participant tells customers that a transfer stuck in a processing state may take up to 24 hours in exceptional cases, and that if it ends unsuccessful the amount is reversed to the customer automatically, with a contact route if it is not back within 24 hours.", "citation": "GXBank DuitNow Services FAQ, effective 2024-03-22, section A (question on issues with a DuitNow Transfer) and section B (question on failed QR payments)", "rests_on": "practice" }, { "label": "Customers are told the outcome", "value": "Participants' terms commit them to notify the customer whether each transfer succeeded, failed or was rejected, and BNM requires instant notification of transfers made and received.", "citation": "DuitNow Transfer Terms and Conditions of Deutsche Bank (Malaysia) Berhad, version May 2026, clause 2.4; IFTF (BNM/RH/PD 028-143, 2026-06-30) paragraph 10.1(b) and footnotes 18 and 19", "rests_on": "practice" }, { "label": "After completion, only the sender's recovery process is published", "value": "Where a completed transfer reached the wrong person, participants' published route back is the sender-initiated recovery process described in the recall fact, in which the recipient's institution debits the recipient only under the conditions and windows set there.", "citation": "DuitNow Transfer Terms and Conditions of Deutsche Bank (Malaysia) Berhad, version May 2026, clause 5; of HSBC Bank Malaysia Berhad, version October 2022 (v1.4), clause 5", "rests_on": "practice" }, { "label": "The scheme's position is not public", "value": "BNM requires the operator to set business rules and technical standards and to disclose them to participants; it does not require their publication. Any return or reversal flow between participants, its grounds and its timing are therefore not in any public source read [Unverified: whether such a flow exists].", "citation": "IFTF (BNM/RH/PD 028-143, 2026-06-30) paragraphs 8.2(a), 8.14 and 8.15; BNM policy document Payment System Operator (BNM/RH/PD 029-54, 2022-12-22) paragraph 26.1", "rests_on": "law" } ], "exceptions": [ "The automatic reversal of a failed transfer is one participant's published statement; how other participants handle it, and on what clock, was not read.", "A suspended RENTAS participant's pending settlement items are cancelled by BNM, which is a settlement-level event, not a customer-level return (BNM Participation Rules for Payments and Securities Services, version 3, clause 6.3.1).", "DuitNow QR purchase refunds by merchants are a separate question; see the refund fact." ], "applies_to": "a DuitNow Transfer received by a customer of a Malaysian bank or e-money participant", "caveat": "Do not infer an ACH-style return right from the absence of a rule. The public record supports only two statements: a failed transfer does not leave the payer's account debited, and a completed mistaken transfer comes back only through the sender's recovery request.", "related": [ "my-duitnow:recall", "my-duitnow:finality", "my-duitnow:settlement" ], "basis": { "sources": "GXBank DuitNow Services FAQ, effective 2024-03-22 (gxbank.my); Deutsche Bank (Malaysia) Berhad DuitNow Transfer terms, version May 2026 (country.db.com); HSBC Bank Malaysia Berhad DuitNow Transfer terms, October 2022 (hsbc.com.my); BNM IFTF BNM/RH/PD 028-143 (2026-06-30) paragraphs 8.2, 8.14, 8.15, 10.1(b); BNM Payment System Operator BNM/RH/PD 029-54 (2022-12-22) paragraph 26.1; BNM Participation Rules for Payments and Securities Services, version 3 (2025-09-29) clause 6.3.1. The operator's rules are not public, hence primary_not_public. Confidence is low: the main claim is an absence of published information, and the one positive line rests on a single participant. No PayNet material was consulted.", "confidence": "low" }, "currency": { "effective_since": "Unknown", "effective_note": "No source dates a return rule because none publishes one. The participant FAQ is effective 2024-03-22.", "source_edition": "GXBank DuitNow Services FAQ 2024-03-22; Deutsche Bank DuitNow terms May 2026; HSBC DuitNow terms October 2022; IFTF 2026-06-30; PSO PD 2022-12-22", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "primary_not_public": true, "corroboration": [ { "source_url": "https://gxbank.my/docs/terms/DuitNow%20Services%20-%20Frequently%20Asked%20Questions%20%28FAQ%29.pdf", "source_class": "secondary", "source_title": "DuitNow Services Frequently Asked Questions, GXBank, effective 22 March 2024", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms GXBank's own statement that an unsuccessful transfer is automatically reversed to the customer, with a 24 hour contact point if it is not back." }, { "source_url": "https://www.hsbc.com.my/content/dam/hsbc/my/docs/ways-to-bank/duitnow/duitnow-transfer-terms-of-use.pdf", "source_class": "secondary", "source_title": "DuitNow Transfer Terms and Conditions, HSBC Bank Malaysia Berhad, version October 2022 (v1.4), marked Public", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms clause 2.4's notification duty and that clause 5's recovery process, not a bank initiated return, is the only published route back after a completed mistaken transfer. Independent of GXBank; distinct organisation and host. The scheme-not-public claim is also supported by paragraph 26.1 of BNM's Payment System Operator policy document (rules disclosed to participants, not published) and clause 6.3.1 of the RENTAS Participation Rules (a suspended participant's pending items are cancelled by BNM, a settlement level event, not a customer level return); both were consulted in full but are not separately recorded as sources on this record." } ] }, "rail_name": "Malaysia DuitNow", "governing_authority": "Bank Negara Malaysia", "snapshot": "2026-09-18", "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "not_public", "label": "the operator's own text", "needs": "what the operator's own text says, which Orca has not read", "detail": "Bank Negara Malaysia's own text is not the source for this rail fact: it is not public, or not under terms Orca can use. It rests on 2 named public sources, so a term set by agreement rather than by a published rule is not Orca's to state.", "from": "currency.primary_not_public" } ] }, { "uid": "my-duitnow:settlement", "id": "settlement", "rail": "my-duitnow", "kind": "rail-fact", "facet": "settlement", "name": "How and in what money do participants settle with each other?", "statement": "Under Bank Negara Malaysia's RENTAS procedures in force since 2025-09-29, RPP transactions settle between participants one by one, gross, in central bank money, normally within seconds of the customer transfer completing. PayNet streams each completed transaction to a BNM module called Near Real Time Settlement (NRTS), which debits the paying participant's NRTS account at BNM and credits the receiving participant's at the same moment. The accounts are prefunded, settlement runs around the clock, and a participant short of funds has its outgoing items queued rather than rejected. Whether this has fully replaced the earlier deferred net settlement for RPP is stated by BNM's procedures but was not confirmed against any go-live notice, and the same procedures still schedule weekday net settlement for transactions they label FPX-RPP Bridge without saying which those are.", "details": [ { "label": "Gross, near real time, per transaction", "value": "Retail payments on NRTS settle gross in near real time, and BNM describes the aim as interbank settlement completing normally within seconds of the customer-level transaction. BNM also allows that in exceptional circumstances settlement may take longer than expected. The operator may send only completed transactions, one line at a time.", "citation": "BNM Operational Procedures for Malaysian Ringgit (MYR) Settlement in RENTAS, BNM/RH/PD 028-28, version 1.8 issued and effective 2025-09-29, clauses 38.1 and 38.2; BNM Participation Rules for Payments and Securities Services, version 3 issued 2025-09-29, glossary item 31 (NRTS)", "rests_on": "rule" }, { "label": "The RPP is on NRTS", "value": "BNM's appendix listing the retail payment services covered by NRTS names one service, the Real Time Payments Platform (RPP). BNM's list uses that name; PayNet and BNM's framework call it the Real-time Retail Payments Platform [Inference: the same system].", "citation": "BNM Operational Procedures for MYR Settlement in RENTAS (BNM/RH/PD 028-28, version 1.8, 2025-09-29), Appendix XX; IFTF (BNM/RH/PD 028-143, 2026-06-30) paragraph 1.1", "rests_on": "rule" }, { "label": "Settlement asset", "value": "NRTS accounts are held at BNM, so settlement is a transfer across the central bank's books and the settlement asset is a claim on the central bank. BNM's rules define settlement as the final and irrevocable discharge of one participant's obligation to another, in central bank money for ringgit.", "citation": "BNM Operational Procedures for MYR Settlement in RENTAS (BNM/RH/PD 028-28, version 1.8, 2025-09-29), clauses 8.14 and 38.3; BNM Participation Rules for Payments and Securities Services, version 3 (2025-09-29), glossary item 55 (Settlement)", "rests_on": "rule" }, { "label": "Prefunding and queuing", "value": "Participants must prefund their NRTS accounts from their RENTAS MYR settlement accounts, by manual or automatic sweep. Items settle first in, first out; when a payer lacks funds its items queue and then settle first available, first out. When an account drops to its minimum a ten-minute buffer starts, during which outgoing items queue and incoming items still settle; if the balance is still short afterwards BNM sweeps cash in up to the participant's chosen optimum level.", "citation": "BNM Operational Procedures for MYR Settlement in RENTAS (BNM/RH/PD 028-28, version 1.8, 2025-09-29), clauses 38.4, 38.5, 38.8 and 38.15", "rests_on": "rule" }, { "label": "Minimum balance", "value": "BNM sets each participant's minimum NRTS balance, currently computed as half of the participant's largest total outgoing value in any ten-minute interval over a rolling twelve months, and may change the method. Breaching the minimum draws BNM's general non-compliance charges. Participants set their own optimum level; balances above a maximum are swept out automatically.", "citation": "BNM Operational Procedures for MYR Settlement in RENTAS (BNM/RH/PD 028-28, version 1.8, 2025-09-29), clause 38.15 (minimum, optimum and maximum balance)", "rests_on": "rule" }, { "label": "The operator's own duties", "value": "PayNet, as a RENTAS participant of the retail payment system operator type, must stream retail transactions to BNM promptly, must lose none in the stream, must get BNM's written approval for major changes affecting retail settlement, and must keep enough capacity. As a payment system operator it must also hold liquid resources and manage credit exposures to participants, including through collateral.", "citation": "BNM Participation Rules for Payments and Securities Services, version 3 (2025-09-29), clauses 11.1 to 11.8; BNM policy document Payment System Operator (BNM/RH/PD 029-54, 2022-12-22), paragraphs 15 and 16", "rests_on": "rule" }, { "label": "What changed in 2025", "value": "The version 1.8 change log records that RPP window 1 and window 2 net settlement were removed from the MYR settlement schedule and that NRTS was added as a RENTAS module. Before that date RPP positions were settled net in scheduled windows [Inference from the change log; the earlier procedures were not read].", "citation": "BNM Operational Procedures for MYR Settlement in RENTAS (BNM/RH/PD 028-28), revision history for version 1.8 dated 2025-09-29 (clauses 1.1, 3.1, 8.2 and 38)", "rests_on": "rule" } ], "exceptions": [ "BNM's procedures keep a deferred net settlement for retail payments on weekends and holidays, 8.00 am to 6.00 pm, with scheduled FPX windows; the schedule names FPX only, and whether any RPP item still settles net under it is not stated [Inference: it does not] (Operational Procedures clause 9).", "On business days BNM's MYR settlement schedule still carries two deferred net settlement windows for FPX-RPP Bridge transactions, due by 11.00 am and by 3.50 pm; they do not run on weekends or holidays. The procedures never define which transactions count as FPX-RPP Bridge, so whether any DuitNow Transfer settles net through these windows is not stated [Inference: they cover payments crossing between FPX and the RPP, not ordinary DuitNow Transfers, which the same procedures send to NRTS] (BNM Operational Procedures for MYR Settlement in RENTAS, BNM/RH/PD 028-28, version 1.8, 2025-09-29, clauses 8.1 and 8.2).", "Settlement between participants does not decide what happens between a payer and their own bank or between a payee and theirs; those are set by the operator's scheme rules, which are not public, and by each participant's customer terms.", "Participants that reach the RPP through a sponsor settle through that sponsor [Inference from IFTF 8.18 and 8.19; the sponsor's settlement arrangements are not published by BNM].", "Cross-border DuitNow flows involve a foreign counterpart and its settlement arrangements, which no BNM text read for this record describes." ], "applies_to": "interbank settlement of RPP transactions, including DuitNow Transfer, between direct participants holding NRTS accounts at Bank Negara Malaysia", "caveat": "The go-live of NRTS for the RPP is taken from the procedures' effective date of 2025-09-29, not from a BNM or PayNet announcement. A reader who needs to know whether a given day's RPP payments settled gross or net should confirm with BNM's RENTAS notices.", "related": [ "my-duitnow:participants" ], "basis": { "sources": "BNM Operational Procedures for Malaysian Ringgit (MYR) Settlement in the Real Time Electronic Transfer of Funds and Securities System (RENTAS), BNM/RH/PD 028-28, version 1.8 issued and effective 2025-09-29, read from bnm.gov.my: revision history, clauses 1.5, 3.1.6, 8.1, 8.2, 8.14, 8.20 to 8.21, 9, 38.1 to 38.15, Appendix XX. BNM Participation Rules for Payments and Securities Services, version 3 issued 2025-09-29: clause 11 and glossary items 31, 36, 47, 50 and 55. BNM policy document Payment System Operator, BNM/RH/PD 029-54, 2022-12-22, paragraphs 15 and 16. IFTF BNM/RH/PD 028-143, 2026-06-30, paragraph 1.1. BNM is both the governing authority and the operator of RENTAS, so these are authoritative_primary for the settlement leg. Confidence is medium, not high, because the RPP's move to NRTS was not confirmed against a go-live notice and the pre-2025 arrangement is inferred. BNM Terms of Use (updated November 2023) bar reproduction and derivative works except as copyright law permits; nothing here is quoted. No PayNet material was consulted.", "confidence": "medium" }, "currency": { "effective_since": "2025-09-29", "effective_note": "NRTS entered the RENTAS MYR procedures in version 1.8, effective 2025-09-29 (clause 1.5). The minimum balance method and the ten-minute buffer may be changed by BNM (clause 38.15).", "source_edition": "Operational Procedures for MYR Settlement in RENTAS, BNM/RH/PD 028-28, version 1.8, 2025-09-29; Participation Rules for Payments and Securities Services, version 3, 2025-09-29; Payment System Operator BNM/RH/PD 029-54, 2022-12-22", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.bnm.gov.my/documents/20124/943361/op-myr-stlmt-rentas-sep25.pdf", "source_class": "authoritative_primary", "source_title": "Operational Procedures for Malaysian Ringgit (MYR) Settlement in RENTAS, BNM/RH/PD 028-28, version 1.8, issued and effective 29 September 2025", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms NRTS settles retail payments including the RPP gross, per transaction, normally within seconds, 24 hours a day 7 days a week including weekends and holidays, streamed line by line by the operator (clauses 38.1, 38.2, 38.6). Confirms prefunding by manual or automatic sweep, first in first out queuing with first available first out on shortfall, and the ten minute minimum balance buffer during which outgoing items queue while incoming items still settle (clauses 38.4, 38.5, 38.8, 38.15). Confirms the minimum balance formula, fifty percent of the highest ten minute outgoing total over a rolling twelve months, set and revisable by BNM (clause 38.15). Confirms settlement accounts are held at BNM and that the Appendix XX list of retail payments covered by NRTS names only the Real Time Payments Platform (RPP) (clauses 8.14, Appendix XX). Confirms the version 1.8 revision history removed RPP window 1 and window 2 net settlement and introduced NRTS as a new module (revision history for clauses 8.2 and 38). Confirms the weekday schedule carries two deferred net settlement windows labelled FPX-RPP Bridge, due by 11.00am and by 3.50pm, and that the separate weekend and holiday deferred net settlement, 8.00am to 6.00pm, names only FPX in its schedule (clauses 8.2 and 9). Does not confirm a go-live notice for NRTS separate from the procedures own effective date, and does not define which transactions count as FPX-RPP Bridge." } ] }, "rail_name": "Malaysia DuitNow", "governing_authority": "Bank Negara Malaysia", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "nct-inst:consumer-law", "id": "consumer-law", "rail": "nct-inst", "kind": "rail-fact", "facet": "consumer-law", "name": "What consumer protections apply to an NCT Inst payment, and where do they come from?", "statement": "The rulebook binds only banks and the NPC and gives consumers no rights of their own. It does two things for them: it requires each Participant to comply with the payment services rules in Titles III and IV of the Payment Services Directive, or match them, and it sets minimum duties towards customers, such as prompt notice of a rejected payment and information about rights, risks and charges. Everything else a consumer can rely on comes from national law in the country of the account. For SEK and NOK those acts were read for this record; for DKK the Danish act was not. The EU Instant Payments Regulation is about euro and is not a source of rights for these currencies.", "details": [ { "label": "Consumers are not parties", "value": "The rulebook is a multilateral contract between the NPC and each Participant and among Participants; anyone else has neither rights nor obligations under it. What reaches the customer does so through the Participant's own terms and conditions, which must be consistent with the rulebook.", "citation": "NPC010-01 NCT Inst Rulebook 2025 v1.1 (issued and effective 2025-11-21), sections 3.2, 3.5, 5.2, 5.7 items 1 and 2, and 5.8 items 1 and 2", "rests_on": "rule" }, { "label": "Payment services law is a condition of the scheme", "value": "The scheme assumes Titles III and IV of the Payment Services Directive, or equivalent binding rules, are in force nationally. Participants must stay compliant with those titles and with the Regulation on information accompanying transfers of funds, and a Participant outside the Directive's reach must take on substantially equivalent obligations to its customers as far as its own law allows, except the Article 66 rules tied to EEA authorisation.", "citation": "NPC010-01 2025 v1.1, sections 1.9, 5.1 and 5.14", "rests_on": "rule" }, { "label": "What the rulebook itself promises the customer", "value": "A rejected payment must be reported to the Originator at once, with the reason, except where the rejection has regulatory grounds. Each PSP must tell its customers about their risks, rights and obligations, including those under law, and about service level and charges, must explain on request how a payment was handled, and must not stop a customer from using another PSP. Remittance data must reach the Beneficiary whole. Before an RFRO, the Originator must be told a refund is not guaranteed.", "citation": "NPC010-01 2025 v1.1, sections 2.7, 4.2.3 B, 4.3.2.3, 5.7 items 5, 16, 18 and 27, and 5.8 item 21", "rests_on": "rule" }, { "label": "Charges", "value": "Payer and payee are each charged, if at all, by their own PSP, and each PSP sets its charges under applicable law. The Beneficiary PSP may deduct its own fee from the amount credited only where its customer agreed to that.", "citation": "NPC010-01 2025 v1.1, section 4.2, subsection Charging Principles, and section 5.8 item 12", "rests_on": "rule" }, { "label": "SEK: the statutory core", "value": "The Swedish Payment Services Act gives the consumer its refund right for unauthorised payments, with a SEK 400 deductible and a SEK 12,000 ceiling for gross negligence, a thirteen month notice limit, the rule that a payment to the unique identifier given is correctly executed, and the PSP's duty to refund a payment it executed wrongly. Where strong customer authentication was not used, the account holder's PSP bears the whole amount of an unauthorised payment unless the holder acted fraudulently.", "citation": "Lag (2010:751) om betaltjänster, consolidated to SFS 2026:1068, chapter 5 sections 45 and 47 to 49, chapter 5 a sections 1 to 6", "rests_on": "law" }, { "label": "SEK: only consumers keep all of it", "value": "A Swedish PSP may agree different terms with a customer who is not a consumer on the unauthorised payment liability rules and on much of the execution liability regime, so a business payer's position depends on its contract.", "citation": "Lag (2010:751) om betaltjänster, chapter 5 section 59 and chapter 5 a section 8", "rests_on": "law" }, { "label": "NOK: the statutory core", "value": "The Norwegian Financial Contracts Act puts unauthorised payment losses on the PSP, with a NOK 450 customer deductible and a NOK 12,000 ceiling for gross negligence with an electronic instrument, and nothing for the customer where strong customer authentication was not required, unless it acted fraudulently. A payment to the account number given counts as correctly executed, with a duty on the PSP to try to recover a misdirected amount.", "citation": "Finansavtaleloven (LOV-2020-12-18-146), sections 4-26 and 4-30, read on Lovdata 2026-09-18", "rests_on": "law" } ], "exceptions": [ "DKK: the Danish Payments Act (lov om betalinger) was not read, so no Danish consumer rule is stated. [Unverified]", "NOK: the Norwegian act applies to payment services in Norway today, but NCT Inst in NOK cannot yet be used because there is no NOK instant settlement service (Norges Bank, Financial Infrastructure 2026, 2026-06-10).", "Faroe Islands and Greenland: Participants there are in the scheme's geography but outside the EEA, so they are bound only by the rulebook's substantial-equivalence clause as far as their law permits (NPC010-01 2025 v1.1, sections 2.1 and 5.14). [Unverified: local payment services law not checked.]", "Verification of payee is not part of NCT Inst. The NPC runs a separate Confirmation of Payee scheme and is replacing it with a Verification of Payee scheme; the EU verification duty in Regulation (EU) 2024/886 concerns euro transfers [Inference: the Regulation was not re-read for this record] (NPC presentation to the ECB TIPS Consultative Group, 2025-10-21, slide 6).", "Customer-to-PSP message formats are only a recommendation in this scheme, so what a customer can send and receive electronically depends on its PSP (NPC010-01 2025 v1.1, section 0.5.1)." ], "applies_to": "consumers and other payment service users sending or receiving NCT Inst payments in SEK, DKK or NOK, and the source of each protection: the rulebook, national payment services law, or neither", "caveat": "A protection that sounds scheme-wide usually is not. The rulebook only obliges banks to follow national law and to inform customers; the amounts, deadlines and burdens are national and differ between Sweden, Denmark and Norway.", "related": [ "nct-inst:refund", "nct-inst:liability", "nct-inst:recall" ], "basis": { "sources": "NPC010-01 NCT Inst Rulebook 2025 v1.1 (2025-11-21), sections 0.5.1, 1.9, 2.1, 2.7, 3.2, 3.5, 4.2.3 B, 4.2 (Charging Principles), 4.3.2.3, 5.1, 5.2, 5.7, 5.8, 5.14. Lag (2010:751) om betaltjänster, consolidated to SFS 2026:1068, read on riksdagen.se 2026-09-18. Finansavtaleloven (LOV-2020-12-18-146), read on Lovdata 2026-09-18. NPC presentation to the ECB TIPS Consultative Group (2025-10-21). Norges Bank Financial Infrastructure 2026. The Danish Payments Act and Regulation (EU) 2024/886 were not read.", "confidence": "medium" }, "currency": { "effective_since": "2025-11-21", "effective_note": "Rulebook 2025 v1.1 effective 2025-11-21. Swedish act read to SFS 2026:1068 and Norwegian act as on Lovdata 2026-09-18; either can change independently of the rulebook.", "source_edition": "NPC010-01 NCT Inst Rulebook 2025 v1.1 (2025-11-21); Lag (2010:751) om betaltjänster (to SFS 2026:1068); Finansavtaleloven LOV-2020-12-18-146", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "rail_name": "Nordic Credit Transfer Instant (NCT Inst)", "governing_authority": "Nordic Payments Council", "snapshot": "2026-09-18", "source_class": null, "effective_status": "draft", "effective_status_reason": null, "boundaries": [] }, { "uid": "nct-inst:decision-points", "id": "decision-points", "rail": "nct-inst", "kind": "rail-fact", "facet": "decision-points", "name": "Where does NCT Inst stop and a person or a bank decide?", "statement": "The payment itself is automatic and measured in seconds, but the rulebook leaves real choices on either side of it, and some of them depend on the currency. Before and during the payment, banks choose their limits, whether to take cross-border payments, and, in SEK, whether to reject above the scheme maximum. After it, everything that could bring money back turns on a decision: the sending bank decides whether to pass on its customer's request, the receiving bank and its customer decide whether to give money back, and the receiving bank decides whether to charge for it. Denmark removes one of those decisions by accepting recalls for duplicates and technical errors automatically. Each line below names the provision that leaves the choice open; this reading is Orca's and is capped at medium confidence.", "details": [ { "label": "How low to set the sending limit", "value": "Every Originator PSP may set a lower limit than the scheme maximum for its own customers, by its own risk analysis and by channel.", "citation": "NPC010-01 NCT Inst Rulebook 2025 v1.1 (issued and effective 2025-11-21), section 2.5; NPC014-01 v2.0 (2024-11-25), sections 2.1 to 2.3", "rests_on": "rule" }, { "label": "SEK: whether to refuse a payment above SEK 1,000,000", "value": "In SEK the rule is permissive: a Participant can reject a payment above the scheme maximum but need not, and may agree higher or unlimited amounts with others. In DKK there is no such choice; above DKK 500,000 the payment must be rejected.", "citation": "NPC014-01 v2.0 (2024-11-25), sections 2.1 and 2.3", "rests_on": "rule" }, { "label": "Whether to accept cross-border payments", "value": "Each Participant chooses, per scheme and per currency, whether to receive cross-border NCT Inst payments; opting out of receiving also means not sending them.", "citation": "NPC010-01 2025 v1.1, sections 2.2 and 2.6; NPC017-01 Clarification Paper v3.2 (effective 2025-12-21), section 2.1", "rests_on": "rule" }, { "label": "Whether to reject a payment in another currency", "value": "A Beneficiary PSP may reject a payment whose currency differs from the currency of its customer's account, or may convert it; the rulebook does not govern the conversion.", "citation": "NPC010-01 2025 v1.1, section 2.4", "rests_on": "rule" }, { "label": "What to do when no answer comes", "value": "After the time-out, an Originator PSP with no confirmation chooses whether to start the investigation procedure, use other channels, or simply wait; what it may not do is treat the payment as failed or release the reservation.", "citation": "NPC010-01 2025 v1.1, sections 4.2.3 D and 4.4", "rests_on": "rule" }, { "label": "Whether the sending bank passes a request on", "value": "The Originator PSP judges whether a customer's Recall request falls within the three Recall grounds and the time limits, and may refuse it; it may likewise refuse an RFRO that gives no reason or comes more than 13 months after the debit. It also chooses whether to send an RFRO instantly or not.", "citation": "NPC010-01 2025 v1.1, section 4.3.2.2 step CT-02.01R and section 4.3.2.3 with process step 1", "rests_on": "rule" }, { "label": "How the receiving bank handles a Recall", "value": "National law and the account contract decide which of three positions the Beneficiary PSP is in before answering a Recall: bound to get its customer's authorisation, free to choose whether to ask, or able to debit the customer straight away.", "citation": "NPC010-01 2025 v1.1, section 4.3.2.2 steps CT-02.03 and CT-02.03A", "rests_on": "rule" }, { "label": "The Beneficiary's consent", "value": "An RFRO succeeds only if the Beneficiary agrees; its decision, passed back through the banks, decides the outcome for both PSPs. The Beneficiary can also refuse a Recall.", "citation": "NPC010-01 2025 v1.1, sections 4.3.2.2 step CT-02.03R and 4.3.2.3 steps 3, 4A and 4B", "rests_on": "rule" }, { "label": "Whether to charge, and how much to send back", "value": "The Beneficiary PSP decides whether to charge the Originator PSP a fee on a positive Recall or RFRO answer, and so the amount returned can be less than the original. RIX-INST likewise lets a beneficiary accepting a recall repay the original amount or a lower one.", "citation": "NPC010-01 2025 v1.1, sections 4.3.2.2 and 4.3.2.3 step 4A; Sveriges Riksbank RIX-INST Instructions (June 2026), section 15.2", "rests_on": "rule" }, { "label": "DKK: a decision taken away", "value": "Under the Danish community's service, which TIPS DKK participants must adhere to, a Recall from the sending PSP for a duplicate or a technical error is accepted automatically for the full amount; the Beneficiary PSP can refuse only where the funds were already returned, the payment never arrived, or the amounts differ.", "citation": "Finans Danmark, NPC AOS note (2025-03-10, effective 2025-04-22); Danmarks Nationalbank Terms and Conditions for Accounts in TARGET DKK (effective 2026-06-15), Part V Article 2(4)", "rests_on": "rule" }, { "label": "SEK: the Riksbank's own discretions", "value": "The Riksbank decides whether to approve an Instructing Party for the SIP Model, and may decline to adapt RIX-INST to NCT Inst changes that depart far from SCT Inst and would need TIPS platform changes.", "citation": "Sveriges Riksbank RIX-INST Instructions (June 2026), sections 3.4 and 14.2", "rests_on": "rule" }, { "label": "SEK: when a bank may pause before refunding", "value": "A Swedish PSP facing an unauthorised transaction claim must restore the account by the next banking day, unless it has grounds to suspect the transaction was authorised, in which case it may take reasonable time to investigate.", "citation": "Lag (2010:751) om betaltjänster, chapter 5 a section 1, consolidated to SFS 2026:1068", "rests_on": "law" } ], "exceptions": [ "NOK: the NOK-specific choices, such as the absence of a scheme maximum until Bits decides otherwise, cannot be exercised yet because no NOK settlement service exists (NPC014-01 v2.0, section 2.2; Norges Bank, Financial Infrastructure 2026, 2026-06-10).", "Participants may agree bilaterally or multilaterally on a shorter target time than 5 seconds or a shorter time-out than 7 seconds, which binds only them (NPC010-01 2025 v1.1, section 4.2.3 B and C).", "The NPC's Scheme Management Committee may cut the maximum amount at very short notice in an emergency, which is a scheme-level decision outside any single payment (NPC014-01 v2.0, section 4.1).", "Denmark: which Danish rules govern whether a Beneficiary PSP may debit its customer on a Recall without authorisation was not read; the rulebook points to national legislation for that choice. [Unverified]", "An Originator PSP may offer future-dated instant payments and let the customer cancel before the chosen date, or not offer them at all (NPC010-01 2025 v1.1, section 4.2.1)." ], "applies_to": "points before, during and after an NCT Inst payment in SEK, DKK or NOK where the rulebook, a central bank's terms or national law leaves the outcome to a Participant, a customer or a central bank rather than prescribing it", "caveat": "This facet is Orca's reading of where the texts leave room for judgement. Every line cites the provision that leaves the choice open, but the grouping and the emphasis are interpretation.", "related": [ "nct-inst:recall", "nct-inst:limits", "nct-inst:participants", "nct-inst:finality" ], "basis": { "sources": "NPC010-01 NCT Inst Rulebook 2025 v1.1 (2025-11-21), sections 2.2, 2.4 to 2.6, 4.2.1, 4.2.3, 4.3.2.2, 4.3.2.3, 4.4. NPC014-01 v2.0, sections 2 and 4.1. NPC017-01 v3.2, section 2.1. Sveriges Riksbank RIX-INST Instructions (June 2026), sections 3.4, 14.2, 15.2. Finans Danmark AOS note (2025-03-10); Danmarks Nationalbank Terms and Conditions for Accounts in TARGET DKK (2026-06-15), Part V Article 2. Lag (2010:751) om betaltjänster, chapter 5 a section 1. Norges Bank Financial Infrastructure 2026.", "confidence": "medium" }, "currency": { "effective_since": "2025-11-21", "effective_note": "Rulebook 2025 v1.1 effective 2025-11-21; maximum amount document NPC014-01 v2.0 of 2024-11-25; Danish AOS effective 2025-04-22. The 2027 rulebook is due for publication in November 2026.", "source_edition": "NPC010-01 NCT Inst Rulebook 2025 v1.1 (2025-11-21); NPC014-01 v2.0 (2024-11-25); RIX-INST Instructions (June 2026); Finans Danmark AOS note (2025-03-10)", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "rail_name": "Nordic Credit Transfer Instant (NCT Inst)", "governing_authority": "Nordic Payments Council", "snapshot": "2026-09-18", "source_class": null, "effective_status": "draft", "effective_status_reason": null, "boundaries": [] }, { "uid": "nct-inst:finality", "id": "finality", "rail": "nct-inst", "kind": "rail-fact", "facet": "finality", "name": "When does an NCT Inst payment become final, and can it be reversed?", "statement": "Finality on NCT Inst comes in layers. For the customer, the payment is done a few seconds after it is sent: the Beneficiary PSP gives the money to its customer once its positive confirmation is safely with its CSM. Between the banks, the central bank settlement service books the transfer when that positive answer arrives, and for DKK the central bank's terms make the order irrevocable at an earlier moment still, when the funds are reserved. After that there is no Return in the scheme. The only routes back are a Recall or a Request for Recall by the Originator, and the Beneficiary side can refuse either. Which settlement layer applies depends on the currency: SEK settles in the Riksbank's RIX-INST, DKK in Danmarks Nationalbank's TIPS service, and NOK has no instant settlement service yet.", "details": [ { "label": "The seconds that decide it", "value": "The Originator PSP should know the outcome, positive or negative, by 5 seconds after its Time Stamp. The Beneficiary PSP's answer has to reach its CSM by 7 seconds, and a CSM that has heard nothing by then rejects with a time-out. Whatever answer exists at that point has to be back with the Originator PSP by the 9th second. Participants may agree tighter figures among themselves.", "citation": "NPC010-01 NCT Inst Rulebook 2025 v1.1 (issued and effective 2025-11-21), section 4.2.3 A, B and C", "rests_on": "rule" }, { "label": "When the Beneficiary is paid", "value": "The Beneficiary PSP may release the funds only after it knows its positive confirmation reached its own CSM, through a technical acknowledgement or a similar arrangement with that CSM. From then the Beneficiary can use the money on the terms of its account. That release is the point a customer experiences as final.", "citation": "NPC010-01 2025 v1.1, section 1.4 step 5, section 4.2.3 B, process steps CT-01.09 and CT-01.10", "rests_on": "rule" }, { "label": "Cover is arranged before the payment moves", "value": "Sending the transaction to its CSM authorises that CSM to hold cover on the Originator PSP's account at once, so the Beneficiary PSP is covered as soon as it receives the transaction. The Originator PSP becomes bound to settle only when a positive confirmation comes back. A community may replace the reservation with another arrangement only if it gives at least the same settlement certainty.", "citation": "NPC010-01 2025 v1.1, section 1.4 step 2 and the clearing function note, section 4.3 principles 1 to 3", "rests_on": "rule" }, { "label": "SEK: settled on acceptance in RIX-INST", "value": "In the Standard Model, the one that follows NCT Inst, RIX-INST reserves the amount on the Originating Participant's settlement account, asks the Beneficiary Participant, and on a positive answer debits one account and credits the other in the same step. A negative answer gives the status Rejected, no answer by the deadline gives Expired, and in both cases the reservation is released. RIX is a designated settlement system under the Swedish Settlement Act (1999:1309) and Directive 98/26/EC.", "citation": "Sveriges Riksbank, RIX-INST Instructions (June 2026), sections 1, 3.8 and 14.2.1 with Table 40", "rests_on": "rule" }, { "label": "DKK: irrevocable once reserved in TIPS", "value": "Danmarks Nationalbank's account terms fix, for settlement finality law purposes, that an instant payment order enters the Danish krone system and becomes irrevocable when the funds are reserved on the participant's TIPS account, which is earlier than the moment of settlement. The order then settles if the payee accepts and is rejected, with the reservation lifted, if the payee refuses or does not answer in time under the scheme. The terms name the Danish Capital Markets Act, sections 163 and 166, and Article 3(1) and Article 5 of Directive 98/26/EC as the basis.", "citation": "Danmarks Nationalbank, Terms and Conditions for Accounts in TARGET DKK (effective 2026-06-15), Part I Article 3(2) and Article 18(1)(b), Part V Article 6(3)", "rests_on": "rule" }, { "label": "There is no Return", "value": "The Exception Processing in the rulebook is Reject, Recall and Request for Recall by the Originator. A Beneficiary who wants to send money back is told to arrange it with its own PSP, for example as a new payment; the scheme gives it no return message. A positive answer to a Recall or RFRO has to use the prescribed return message and may not be sent as a fresh NCT Inst payment.", "citation": "NPC010-01 2025 v1.1, sections 4.3.2, 4.3.2.2, 4.3.2.3 step 4A and 4.3.2.4; NPC017-01 Clarification Paper v3.2 (effective 2025-12-21), section 2.16", "rests_on": "rule" }, { "label": "Silence does not undo the payment", "value": "An Originator PSP that has no answer 10 seconds after the Time Stamp may investigate, ask by other channels or wait. Until some confirmation arrives it must keep the amount reserved on its customer's account and keep the Beneficiary PSP covered, and it may not treat the payment as failed. [Inference: this differs from the euro scheme, where law requires the payer's account to be restored after 10 seconds; no such rule appears in the NCT Inst rulebook.]", "citation": "NPC010-01 2025 v1.1, section 4.2.3 D and section 4.4", "rests_on": "rule" }, { "label": "Finality says nothing about who bears a loss", "value": "The Beneficiary PSP credits the account named by the IBAN in the transaction, which the rulebook treats as the unique identifier. Whether a customer who gave the wrong account, or was defrauded, can recover money is a matter for payment services law, which the rulebook requires every Participant to follow or match in substance.", "citation": "NPC010-01 2025 v1.1, sections 1.9, 5.1, 5.8 item 10 and 5.14", "rests_on": "rule" } ], "exceptions": [ "SEK: settlement is in Sveriges Riksbank's RIX-INST on the Eurosystem TIPS platform, and every RIX-INST participant must be able to receive Standard Model payments (RIX-INST Instructions June 2026, sections 1, 3.4 and 14.2).", "SEK: RIX-INST also runs a SIP Model, in which one approved Instructing Party acts for both banks and a payment settles straight after validation, with no reservation and no request to the Beneficiary Participant. RIX-INST names the Standard Model, not the SIP Model, as the one that follows NCT Inst, so the timing in this record describes Standard Model payments (RIX-INST Instructions June 2026, sections 1 and 14.2.2).", "DKK: settlement is in Danmarks Nationalbank's TIPS DCAs, which it opened for Danish kroner when it moved krone payments to TARGET Services at Easter 2025; a TIPS DCA may not go into debit (Danmarks Nationalbank press release 2025-04-23; Terms and Conditions for Accounts in TARGET DKK, effective 2026-06-15, Part V Article 1(2)).", "NOK: NOK has been a Scheme Currency since 2021, but no NOK instant settlement service exists yet. Norges Bank signed to use TIPS in November 2024 and then aimed at the first half of 2028; its June 2026 report says the adaptations are larger than assumed and the plan is being revised (NPC100-01 v1.1; Norges Bank press release 2024-11-29; Norges Bank, Financial Infrastructure 2026, published 2026-06-10). No NOK settlement layer can be stated.", "Insolvency-law finality is set by the settlement system's own law, not by the rulebook. For SEK that is the Swedish Act 1999:1309 named by the Riksbank; the Act itself and the Riksbank's Terms and Conditions for RIX were not read for this record [Unverified].", "Groups of Participants may agree a shorter target than 5 seconds or a shorter time-out than 7 seconds, binding only on themselves (NPC010-01 2025 v1.1, section 4.2.3 B and C).", "A Reservation of the Amount may be made as an immediate debit instead of a hold, so a customer can see the money leave before the outcome is known (NPC010-01 2025 v1.1, chapter 7, defined term Reservation of the Amount)." ], "applies_to": "NCT Inst payments in SEK, DKK or NOK between Participants established in a country on the EPC list of SEPA scheme countries, in Greenland or in the Faroe Islands, under the NPC Instant Credit Transfer Scheme; never euro, which is SCT Inst", "caveat": "A reader used to SEPA Instant should not assume the ten second release rule carries over: the NPC rulebook keeps the reservation in place until a confirmation arrives. And a record that says NCT Inst payments are final in the Nordics without naming the currency is wrong for Norway, where there is no instant settlement service yet.", "related": [ "nct-inst:settlement", "nct-inst:hours", "nct-inst:return", "nct-inst:recall", "nct-inst:refund", "nct-inst:liability", "nct-inst:consumer-law", "nct-inst:decision-points" ], "basis": { "sources": "NPC010-01 NCT Inst Rulebook 2025 v1.1 (issued and effective 2025-11-21, marked Public), read for this record: sections 1.4, 1.9, 4.2.3 A to D, 4.3, 4.3.1 (CT-01.09, CT-01.10), 4.3.2 to 4.3.2.4, 4.4, 5.1, 5.8, 5.14, chapter 7. NPC017-01 Clarification Paper v3.2, section 2.16. NPC100-01 v1.1. Sveriges Riksbank RIX-INST Instructions (June 2026), sections 1, 3.4, 3.8, 14.2, 14.2.1, 14.2.2. Danmarks Nationalbank Terms and Conditions for Accounts in TARGET DKK (effective 2026-06-15), Part I Articles 3 and 18, Part V Articles 1 and 6; Danmarks Nationalbank press release 2025-04-23. Norges Bank press release 2024-11-29 and Financial Infrastructure 2026 (2026-06-10). The Swedish Settlement Act, the Danish Capital Markets Act and Directive 98/26/EC were not read; they are named only as the central banks name them.", "confidence": "high" }, "currency": { "effective_since": "2025-11-21", "effective_note": "The 2025 NCT Inst rulebook took effect on 2025-10-05 (v1.0), and v1.1 was issued and took effect on 2025-11-21 with minor changes that do not touch timing or finality. The 2025 edition cut the target from 10 to 5 seconds, the time-out from 20 to 7 seconds and the no-answer point from 25 to 10 seconds (Annex IV, entries for section 4.2.3). The 2027 rulebook is due for publication in November 2026. NOK settlement dates are under revision by Norges Bank.", "source_edition": "NPC010-01 NCT Inst Rulebook 2025 v1.1 (2025-11-21); RIX-INST Instructions (June 2026); Danmarks Nationalbank Terms and Conditions for Accounts in TARGET DKK (2026-06-15)", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "rail_name": "Nordic Credit Transfer Instant (NCT Inst)", "governing_authority": "Nordic Payments Council", "snapshot": "2026-09-18", "source_class": null, "effective_status": "draft", "effective_status_reason": null, "boundaries": [] }, { "uid": "nct-inst:hours", "id": "hours", "rail": "nct-inst", "kind": "rail-fact", "facet": "hours", "name": "When can an NCT Inst payment be sent and settled?", "statement": "At any time. The scheme runs around the clock on every calendar day with no cut-off, and every Participant has to be able to send and receive on that basis. The SEK and DKK settlement services are also open all day every day, so a payment made at night or on a holiday settles at once. What stops overnight is not payments but the movement of liquidity: each central bank pauses transfers between its instant and its large-value accounts for a spell around the evening change of business day. Days still matter for R-transactions, because the rulebook counts Recall and RFRO windows in Banking Business Days, and each Participant has its own. NOK has no settlement service, so no NOK hours can be stated.", "details": [ { "label": "The scheme's clock", "value": "The service is available 24 hours a day on every Calendar Day, and because of that the rulebook sets no Cut-off Time.", "citation": "NPC010-01 NCT Inst Rulebook 2025 v1.1 (issued and effective 2025-11-21), sections 1.8, 2.2 and 4.2.2", "rests_on": "rule" }, { "label": "Participants must keep up", "value": "Both Originator PSPs and Beneficiary PSPs must be able to process NCT Inst at all hours on all days, business continuity arrangements included. The rulebook accepts that a Participant may be unreachable for a while in exceptional circumstances.", "citation": "NPC010-01 2025 v1.1, sections 5.3, 5.7 item 4 and 5.8 item 4", "rests_on": "rule" }, { "label": "A payment can be set for later", "value": "An Originator PSP may let its customer pick a future date and time. That chosen moment then counts as the Time of Receipt, the PSP sends the payment only then, and it may allow the customer to cancel before the chosen date.", "citation": "NPC010-01 2025 v1.1, section 4.2.1", "rests_on": "rule" }, { "label": "Business days are each Participant's own", "value": "Recall and RFRO deadlines are counted in Banking Business Days, which the rulebook defines per Participant as the days that Participant is open for business. There is no single scheme calendar, so the same ten or fifteen days can end on different dates for two banks.", "citation": "NPC010-01 2025 v1.1, sections 4.3.2.2, 4.3.2.3 and chapter 7, defined term Banking Business Day", "rests_on": "rule" }, { "label": "SEK: RIX-INST is always open", "value": "RIX-INST settles around the clock every day of the year. The Riksbank may close it for technical maintenance a limited number of times a year, with at least a month's notice. A participant may take itself offline briefly for maintenance if it tells the Riksbank in advance, but otherwise must keep its connection open and staffed at all times.", "citation": "Sveriges Riksbank, RIX-INST Instructions (June 2026), sections 3.1, 5.1 and 12", "rests_on": "rule" }, { "label": "SEK: the evening pause in liquidity", "value": "On each Swedish business day, liquidity transfers between RIX-RTGS and RIX-INST stop at 17:58, RIX-RTGS closes and the value date changes at 18:00, and the link reopens at 19:00. Payments keep settling in RIX-INST meanwhile. Because the value date moves at 18:00, a payment settled in the evening can carry the next value date.", "citation": "Sveriges Riksbank, RIX-INST Instructions (June 2026), sections 3.2, 3.7 and 12 with Table 28", "rests_on": "rule" }, { "label": "DKK: TIPS accounts run every calendar day", "value": "Danmarks Nationalbank's TIPS accounts are open every calendar day, while its other krone accounts run only on Danish business days, whose closing days it lists. Instant payment orders are processed through every period of the schedule. Liquidity transfers between TIPS accounts and other krone accounts are blocked from 17:00 until the new business day opens in the evening, and around the mandatory maintenance window that runs until 02:30 after a closing day.", "citation": "Danmarks Nationalbank, Appendices to the Terms and Conditions for Accounts in TARGET DKK (effective 2026-06-15), Appendix 3 paragraphs 2, 3 and 5 with the schedule table", "rests_on": "rule" } ], "exceptions": [ "NOK: no NOK instant settlement service exists, so no settlement hours apply to NOK. Norges Bank is revising its plan for NBO INST on TIPS (Norges Bank, Financial Infrastructure 2026, 2026-06-10).", "SEK: RIX-RTGS may run Extended Opening Hours, which postpone the 17:58 liquidity cut-off and the events after it (RIX-INST Instructions June 2026, section 12, Table 28).", "DKK: the exact times in the Danmarks Nationalbank schedule are marked approximate for the start of the business day (about 18:45), and an optional maintenance window from 03:00 to 05:00 may be used on business days (Appendices to the Terms and Conditions for Accounts in TARGET DKK, 2026-06-15, Appendix 3 table). [Unverified: whether instant payments are processed during the optional maintenance window is not stated in a way this drafter could read from the extracted table.]", "A Participant may be temporarily unreachable in exceptional circumstances, which the rulebook recognises (NPC010-01 2025 v1.1, section 5.3).", "A payment rejected on regulatory grounds need not be reported to the Originator immediately, which is the one exception the rulebook makes to instant notice of a reject (NPC010-01 2025 v1.1, section 4.2.3 B)." ], "applies_to": "the times at which an NCT Inst payment in SEK, DKK or NOK can be initiated, sent, received and settled, and the day count used for its R-transactions", "caveat": "Round-the-clock settlement is a statement about SEK and DKK. For NOK the currency is in the scheme but there is nowhere to settle it yet.", "related": [ "nct-inst:finality", "nct-inst:settlement", "nct-inst:recall" ], "basis": { "sources": "NPC010-01 NCT Inst Rulebook 2025 v1.1 (2025-11-21), sections 1.8, 2.2, 4.2.1, 4.2.2, 4.2.3 B, 4.3.2.2, 4.3.2.3, 5.3, 5.7, 5.8, chapter 7. Sveriges Riksbank RIX-INST Instructions (June 2026), sections 3.1, 3.2, 3.7, 5.1, 12. Danmarks Nationalbank Appendices to the Terms and Conditions for Accounts in TARGET DKK (effective 2026-06-15), Appendix 3. Norges Bank Financial Infrastructure 2026 (2026-06-10).", "confidence": "high" }, "currency": { "effective_since": "2025-11-21", "effective_note": "Rulebook 2025 v1.1 effective 2025-11-21. The Riksbank schedule is from the June 2026 Instructions and the Danish schedule from the appendices effective 2026-06-15; both change when those documents are re-issued.", "source_edition": "NPC010-01 NCT Inst Rulebook 2025 v1.1 (2025-11-21); RIX-INST Instructions (June 2026); Appendices to the Terms and Conditions for Accounts in TARGET DKK (2026-06-15)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.nordicpaymentscouncil.org/media/0mib5gjt/npc010-01-2025-nct-instant-rulebook-version-11.pdf", "source_class": "authoritative_primary", "source_title": "NPC010-01 NCT Inst Rulebook 2025 v1.1", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms 24 hour, all calendar day availability with no scheme cut-off time, that Originator and Beneficiary PSPs must be able to process NCT Inst around the clock including business continuity duties, that an Originator PSP may let a customer choose a future date and time as the Time of Receipt, that Recall and RFRO deadlines run on each Participant's own Banking Business Days rather than one scheme calendar, that a temporarily unreachable Participant is recognised, and that a reject on regulatory grounds need not be reported to the Originator immediately." }, { "source_url": "https://www.riksbank.se/globalassets/media/rix/rix-inst-rtgs/engelska/rix-inst-instructions.pdf", "source_class": "authoritative_primary", "source_title": "Sveriges Riksbank, RIX-INST Instructions, June 2026", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms RIX-INST settles around the clock every day with 24/7 support, that liquidity transfers between RIX-RTGS and RIX-INST stop at 17:58, the Value Date changes at 18:00 and the link reopens at 19:00 on each Business Day, and that Extended Opening Hours in RIX-RTGS postpone that schedule." }, { "source_url": "https://www.nationalbanken.dk/media/10mppqcw/appendices-to-the-terms-and-conditions-for-accounts-in-target-dkk-15-june-2026.pdf", "source_class": "authoritative_primary", "source_title": "Danmarks Nationalbank, Appendices to the Terms and Conditions for Accounts in TARGET DKK, effective 15 June 2026", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms TIPS DCAs operate every calendar day while other Danish krone account types follow the Danish business day calendar, that a business day starts at approximately 18:45, and that the operating schedule table lists instant payment order processing on TIPS DCAs continuing through the mandatory and optional maintenance windows that pause other account types, so DKK instant payment processing is not interrupted by those windows." }, { "source_url": "https://www.norges-bank.no/en/news-events/publications/Financial-Infrastructure-Report/financial-infrastructure-2026/web-report-financial-infrastructure-2026/", "source_class": "public_primary", "source_title": "Norges Bank, Financial infrastructure 2026", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms no NOK instant settlement service exists yet, that integrating NOK into TIPS needs more extensive adaptation than originally assumed, and that Norges Bank's timetable for the service is currently being revised, so no NOK settlement hours can be stated." } ] }, "rail_name": "Nordic Credit Transfer Instant (NCT Inst)", "governing_authority": "Nordic Payments Council", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "nct-inst:liability", "id": "liability", "rail": "nct-inst", "kind": "rail-fact", "facet": "liability", "name": "Who is liable when an NCT Inst payment goes wrong, and how much?", "statement": "There are three separate liability regimes. Between banks, the rulebook makes a Participant liable to the other Participant in the same payment for foreseeable losses caused by its material breach, negligence or operational failure, capped at the payment amount unless it acted intentionally. Between a bank and its central bank settlement service, the central bank's own terms apply, and they limit its liability sharply; the Danish terms were read, the Swedish ones were not. Between a bank and its customer, payment services law applies, not the rulebook. The rulebook itself gives customers no rights, and the NPC answers only for intentional acts.", "details": [ { "label": "When one Participant owes another", "value": "Liability runs only between the two Participants in a given payment. One owes the other for foreseeable loss, legal costs included, where the loss comes from its own or its people's operational failure, negligence or material breach of the rulebook in connection with that payment.", "citation": "NPC010-01 NCT Inst Rulebook 2025 v1.1 (issued and effective 2025-11-21), section 5.9, Scope of Liability", "rests_on": "rule" }, { "label": "How far the cap reaches", "value": "Only losses that Participants making instant transfers in the Scheme Currencies regularly run into count as foreseeable, and nothing can be claimed for a loss caused by action taken to manage or limit risk. Every claim stops at the amount of the payment. That ceiling holds even against gross negligence and lifts only for intent, and a claimant that contributed through its own negligence has its claim reduced in proportion.", "citation": "NPC010-01 2025 v1.1, section 5.9, Limits on Liability", "rests_on": "rule" }, { "label": "Force majeure", "value": "A Participant is not liable where circumstances outside its control stop, hinder or delay its performance.", "citation": "NPC010-01 2025 v1.1, section 5.9, Force majeure", "rests_on": "rule" }, { "label": "The NPC's own liability", "value": "The NPC and those acting for it answer for its exercise of discretion under the rulebook only if the act or omission was intentional, and never for unforeseeable losses.", "citation": "NPC010-01 2025 v1.1, section 5.10", "rests_on": "rule" }, { "label": "Outsourcing does not shift it", "value": "A Participant stays responsible for its scheme obligations whether it performs them itself or through intermediaries, CSMs or outsourcing providers, and uses a CSM or Intermediary PSP at its own risk. Customers and other outsiders have no rights under the rulebook, which binds only the NPC and the Participants.", "citation": "NPC010-01 2025 v1.1, sections 1.5, 3.1, 5.2 and 5.3", "rests_on": "rule" }, { "label": "Governing law", "value": "The rulebook is governed by Swedish law and prevails over any other agreement between the NPC and Participants on the same subject; within it, chapter 5 prevails over chapter 4, and both over the rest.", "citation": "NPC010-01 2025 v1.1, section 5.13", "rests_on": "rule" }, { "label": "DKK: what Danmarks Nationalbank answers for", "value": "Danmarks Nationalbank is liable only for transaction losses attributable to its own error, and not for losses from technical disruption, transmission problems, a participant's own systems, a participant's own conduct, or force majeure, nor for indirect or consequential losses. For errors of the Eurosystem it pays only what it can recover from the Eurosystem. Participants may not claim against the Eurosystem, and a participant must reimburse Danmarks Nationalbank for amounts it has to pay the Eurosystem because of that participant; Danmarks Nationalbank's own liability to the Eurosystem for TIPS is capped at EUR 200,000 a year.", "citation": "Danmarks Nationalbank, Terms and Conditions for Accounts in TARGET DKK (effective 2026-06-15), Part I Article 22(2) to 22(10)", "rests_on": "rule" }, { "label": "DKK: corrections by the central bank", "value": "Danmarks Nationalbank corrects, and may reverse, an incorrect transaction it caused itself, and does nothing about one it did not cause.", "citation": "Danmarks Nationalbank, Terms and Conditions for Accounts in TARGET DKK (effective 2026-06-15), Part I Article 21", "rests_on": "rule" }, { "label": "SEK: the account owner answers for its reachable parties", "value": "An indirect participant reaches RIX-INST through a direct participant's account, and the direct participant owns that account and is responsible for the payments settled on it.", "citation": "Sveriges Riksbank RIX-INST Instructions (June 2026), section 10.3", "rests_on": "rule" } ], "exceptions": [ "SEK: the Riksbank's liability towards RIX-INST participants sits in its Terms and Conditions for RIX and Monetary Policy Instruments, which were not read, so no Swedish settlement liability rule is stated (RIX-INST Instructions June 2026, section 2.1). [Unverified]", "NOK: no NOK settlement service exists, so no central bank liability terms for NOK instant payments exist yet (Norges Bank, Financial Infrastructure 2026, 2026-06-10).", "The scheme's risk management annex, NPC910-01, has restricted distribution and is shared with suppliers only under a non-disclosure agreement, so any liability or loss allocation it contains is not public and not stated here (NPC010-01 2025 v1.1, Annex III).", "Customer-facing liability, such as who bears an unauthorised or misdirected payment, comes from national payment services law and is set out under refund for SEK and NOK; the Danish act was not read (Lag (2010:751) om betaltjänster; Finansavtaleloven LOV-2020-12-18-146).", "Currency conversion losses arising from a Recall or RFRO on a converted payment are handled through the recall fee or bilaterally, not through the section 5.9 regime (NPC017-01 Clarification Paper v3.2, section 2.7)." ], "applies_to": "losses arising from an NCT Inst payment in SEK, DKK or NOK: between Participants under the rulebook, between the NPC and Participants, and between participants and the Danish and Swedish central bank settlement services", "caveat": "The payment-amount cap is a scheme rule between banks. It does not limit what a customer can recover from its own bank under payment services law.", "related": [ "nct-inst:refund", "nct-inst:settlement", "nct-inst:recall" ], "basis": { "sources": "NPC010-01 NCT Inst Rulebook 2025 v1.1 (2025-11-21), sections 1.5, 3.1, 5.2, 5.3, 5.9, 5.10, 5.13, Annex III. NPC017-01 Clarification Paper v3.2, section 2.7. Danmarks Nationalbank Terms and Conditions for Accounts in TARGET DKK (effective 2026-06-15), Part I Articles 21 and 22. Sveriges Riksbank RIX-INST Instructions (June 2026), sections 2.1 and 10.3. Norges Bank Financial Infrastructure 2026.", "confidence": "high" }, "currency": { "effective_since": "2025-11-21", "effective_note": "Rulebook 2025 v1.1 effective 2025-11-21; Annex IV lists no change to sections 5.9 or 5.10 in the 2025 edition. Danish terms as effective from 2026-06-15.", "source_edition": "NPC010-01 NCT Inst Rulebook 2025 v1.1 (2025-11-21); Danmarks Nationalbank Terms and Conditions for Accounts in TARGET DKK (2026-06-15); RIX-INST Instructions (June 2026)", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "rail_name": "Nordic Credit Transfer Instant (NCT Inst)", "governing_authority": "Nordic Payments Council", "snapshot": "2026-09-18", "source_class": null, "effective_status": "draft", "effective_status_reason": null, "boundaries": [] }, { "uid": "nct-inst:limits", "id": "limits", "rail": "nct-inst", "kind": "rail-fact", "facet": "limits", "name": "What limits apply to an NCT Inst payment, and who sets them?", "statement": "Unlike SEPA Instant, NCT Inst still has a scheme maximum per payment, and it differs by currency, both in amount and in force. In DKK the ceiling is 500,000 and anything above it must be rejected. In SEK it is 1,000,000, but a Participant may reject above it rather than must, and Participants can agree a higher or unlimited amount between themselves. NOK has no scheme maximum until Bits says otherwise. Beneficiary PSPs have to accept any payment up to the ceiling, an Originator PSP may set a lower one for its own customers, and the NPC can change the figures outside the rulebook cycle on at least 90 days' notice.", "details": [ { "label": "The ceiling binds the receiving side", "value": "The maximum amount is defined as what every Participant is obliged to receive from any other. The rulebook repeats that Beneficiary PSPs must accept and process payments up to and including it, and points to NPC014-01 for the figure.", "citation": "NPC010-01 NCT Inst Rulebook 2025 v1.1 (issued and effective 2025-11-21), section 2.5; NPC014-01 Maximum Amount NCT Inst v2.0 (2024-11-25), section 2", "rests_on": "rule" }, { "label": "DKK 500,000, a hard stop", "value": "For Danish kroner the scheme maximum is DKK 500,000 per instruction, and Participants must reject any instruction or transaction above it.", "citation": "NPC014-01 v2.0 (2024-11-25), section 2.1", "rests_on": "rule" }, { "label": "SEK 1,000,000, a soft stop", "value": "For Swedish kronor the scheme maximum is SEK 1,000,000. Above it a Participant may reject unless it has agreed otherwise with the other Participant or within a community, and higher or unlimited amounts may be agreed bilaterally or by communities.", "citation": "NPC014-01 v2.0 (2024-11-25), section 2.3", "rests_on": "rule" }, { "label": "NOK: no scheme maximum", "value": "For Norwegian kroner the NPC sets no scheme maximum until further notice from Bits, the Norwegian banking industry's infrastructure company.", "citation": "NPC014-01 v2.0 (2024-11-25), section 2.2", "rests_on": "rule" }, { "label": "The sending bank may go lower", "value": "In every currency an Originator PSP may apply a lower limit to the services it offers its own customers, based on its own risk analysis and the channel the customer uses.", "citation": "NPC010-01 2025 v1.1, section 2.5; NPC014-01 v2.0, sections 2.1 to 2.3", "rests_on": "rule" }, { "label": "How the figures change", "value": "The maximum can move with a new rulebook, taking effect on that rulebook's date, or between rulebooks, taking effect at least 90 calendar days after the NPC publishes a new version of NPC014-01. The Scheme Management Committee reviews the need once a year with the local banking communities, Participants may propose a new figure, and in an emergency the Committee may cut the maximum at shorter notice.", "citation": "NPC014-01 v2.0 (2024-11-25), sections 1, 3, 4.1 and 4.2; NPC010-01 2025 v1.1, section 2.5", "rests_on": "rule" }, { "label": "An over-limit reject still exists", "value": "The rulebook's list of reject reasons keeps a reason for an amount above the maximum authorised for NCT Inst, open to the Originator PSP, the CSM and the Beneficiary PSP. The CSM list also has a reason for a settlement limit being exceeded.", "citation": "NPC010-01 2025 v1.1, section 4.6, attribute AT-R004", "rests_on": "rule" }, { "label": "Field limits are not payment limits", "value": "The amount field accepts up to 99,999,999,999 kronor and 99 öre or øre, and never zero. RIX-INST's own parameter for the largest SEK payment is SEK 99,999,999,999.99. Neither figure is the scheme maximum.", "citation": "NPC100-01 Scheme Currencies v1.1 (2021-11-23), section 3; Sveriges Riksbank RIX-INST Instructions (June 2026), section 9.2, Table 15", "rests_on": "rule" }, { "label": "Settlement cover is a limit too", "value": "A payment only settles if the originating bank's account holds enough. RIX-INST checks the settlement account and any Credit Memorandum Balance limit the participant has set; Danmarks Nationalbank rejects an instant payment order if the payer's TIPS account cannot cover it or if it exceeds the available Credit Memorandum Balance.", "citation": "Sveriges Riksbank RIX-INST Instructions (June 2026), sections 3.6 and 14.2.1; Danmarks Nationalbank Terms and Conditions for Accounts in TARGET DKK (effective 2026-06-15), Part V Articles 6(3)(a) and 6(5)", "rests_on": "rule" }, { "label": "Data and count limits", "value": "Remittance information may be up to 140 characters unstructured or up to 280 characters structured, and it must reach the Beneficiary whole. Each payment can carry one Recall and one RFRO at most.", "citation": "NPC010-01 2025 v1.1, sections 2.7, 4.3.2.2 and 4.3.2.3", "rests_on": "rule" } ], "exceptions": [ "SEK: Participants or communities may agree amounts above SEK 1,000,000, including no limit, so a SEK payment above the scheme maximum can succeed between banks that have agreed it (NPC014-01 v2.0, section 2.3).", "DKK: Danmarks Nationalbank's own public description of Danish instant payments gives the same DKK 500,000 ceiling (Danmarks Nationalbank web page The payments infrastructure in Denmark, read 2026-09-18).", "NOK: the absence of a NOK maximum has no practical effect yet, because no NOK instant settlement service exists (Norges Bank, Financial Infrastructure 2026, 2026-06-10).", "Customer limits set by law are not in the NPC texts. [Unverified: whether Swedish, Danish or Norwegian payment services law gives payers a right to set their own instant payment ceiling, as the amended SEPA Regulation does for euro, was not checked.]", "The maximum amounts in the version of NPC014-01 before v2.0 were not read, so whether v2.0 changed the figures or only the wording is not established; its version history describes wording changes and the added words at least 90 days (NPC014-01 v2.0, version history)." ], "applies_to": "the amount of a single NCT Inst instruction or transaction in SEK, DKK or NOK, the lower limits a sending PSP may set, and the settlement cover and data limits that also bound a payment", "caveat": "The same scheme gives three different answers depending on currency, and in SEK the answer is a permission, not a prohibition. A statement such as the NCT Inst limit is one million kronor is wrong for DKK and NOK and incomplete for SEK.", "related": [ "nct-inst:settlement", "nct-inst:decision-points", "nct-inst:participants", "nct-inst:messages" ], "basis": { "sources": "NPC014-01 Maximum Amount for Instructions under the NCT Inst Scheme Rulebook v2.0 (2024-11-25, SMC decision 2024-09-19), read in full. NPC010-01 NCT Inst Rulebook 2025 v1.1 (2025-11-21), sections 2.5, 2.7, 4.3.2.2, 4.3.2.3, 4.6 (AT-R004). NPC100-01 Scheme Currencies v1.1, section 3. Sveriges Riksbank RIX-INST Instructions (June 2026), sections 3.6, 9.2 (Table 15), 14.2.1. Danmarks Nationalbank Terms and Conditions for Accounts in TARGET DKK (2026-06-15), Part V Article 6; web page The payments infrastructure in Denmark. Norges Bank Financial Infrastructure 2026.", "confidence": "high" }, "currency": { "effective_since": "2024-11-25", "effective_note": "The figures are those in NPC014-01 v2.0, dated 2024-11-25 after an SMC decision of 2024-09-19. Whether v2.0 took effect on that date or with the 2025 rulebook on 2025-10-05 is not stated in the document [Unverified]. A change between rulebook releases applies no earlier than 90 calendar days after the NPC publishes it; the 2027 rulebook is due for publication in November 2026.", "source_edition": "NPC014-01 Maximum Amount NCT Inst v2.0 (2024-11-25); NPC010-01 NCT Inst Rulebook 2025 v1.1 (2025-11-21); NPC100-01 v1.1 (2021-11-23)", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "rail_name": "Nordic Credit Transfer Instant (NCT Inst)", "governing_authority": "Nordic Payments Council", "snapshot": "2026-09-18", "source_class": null, "effective_status": "draft", "effective_status_reason": null, "boundaries": [] }, { "uid": "nct-inst:messages", "id": "messages", "rail": "nct-inst", "kind": "rail-fact", "facet": "messages", "name": "Which messages carry an NCT Inst payment and its exceptions, and whose rules govern them?", "statement": "NCT Inst runs on ISO 20022 XML in its 2019 message versions. Between PSPs the NPC's Inter-PSP Implementation Guidelines are binding: the payment is a pacs.008, the instant answer a pacs.002, a Recall or RFRO a camt.056, a refusal a camt.029, money going back a pacs.004, and a status enquiry a pacs.028. The customer-facing formats are only recommended. The reason codes inside these messages come from the NPC's own guidance for NCT Inst, not from the settlement operators, which keep separate error code lists. The SEK and DKK settlement services use the same message versions and add their own checks.", "details": [ { "label": "Binding between banks, optional towards customers", "value": "The Inter-PSP Implementation Guidelines are a binding supplement to the rulebook and are mandatory. The Customer-to-PSP guidelines and the NPC recommendation on customer reporting are only recommended, supported at the customer's request.", "citation": "NPC010-01 NCT Inst Rulebook 2025 v1.1 (issued and effective 2025-11-21), sections 0.5.1 and 5.2; NPC012-01 NCT Inst Inter-PSP Implementation Guidelines 2025 v1.1 (2025-11-21), section 1", "rests_on": "rule" }, { "label": "The message set", "value": "Payment: pacs.008.001.08. Positive or negative confirmation: pacs.002.001.10, with status ACCP or RJCT. Recall and RFRO: camt.056.001.08. Negative answer to either: camt.029.001.09. Positive answer to either: pacs.004.001.09. Investigation of a payment with no confirmation, and status update on an unanswered Recall or RFRO: pacs.028.001.03. All are built on the 2019 ISO 20022 versions.", "citation": "NPC012-01 2025 v1.1, abstract, section 0.1 reference [2] and section 1 table, with sections 2.1 to 2.11", "rests_on": "rule" }, { "label": "How a payment identifies itself as NCT Inst", "value": "Service Level must carry the code NPCA, and Local Instrument is mandatory with the code INST. Each payment carries a Time Stamp to the millisecond. The UETR end-to-end reference is optional.", "citation": "NPC012-01 2025 v1.1, sections 1.3, 1.5.2 and 2.1.1 (Service Level, Local Instrument and UETR elements); NPC010-01 2025 v1.1, section 4.2.3 A", "rests_on": "rule" }, { "label": "Nordic features in the payload", "value": "Participants must handle the Latin character set plus the Scandinavian letters and the @ sign. An account may be addressed by an alias or proxy instead of an IBAN, using dedicated attributes. Where the customer gives a structured creditor reference, the Originator PSP must validate it against ISO 11649 or the national scheme, such as a Swedish OCR reference or a Norwegian KID. Remittance data may be 140 characters unstructured or 280 structured.", "citation": "NPC012-01 2025 v1.1, sections 1.4, 1.5.4 and 1.5.5; NPC010-01 2025 v1.1, section 2.7", "rests_on": "rule" }, { "label": "A format change with a date", "value": "From 15 November 2026 only structured or hybrid postal addresses are allowed in the messages; unstructured addresses stop being accepted.", "citation": "NPC012-01 2025 v1.1, section 1.7; NPC010-01 2025 v1.1, Annex IV, change 1 in the list for v1.1; NPC017-01 Clarification Paper v3.2, section 2.11", "rests_on": "rule" }, { "label": "Reason codes come from the NPC guidance", "value": "The rulebook defers to NPC020-01, the NPC's guidance on reason codes for NCT Inst R-transactions, for which ISO codes to use in Rejects, Recalls, RFROs and the answers to them. Version 3.1 applies to the rulebook effective from 5 October 2025, and the clarification paper reminds Beneficiary PSPs that using the prescribed codes is an obligation.", "citation": "NPC010-01 2025 v1.1, sections 4.3.2.1 to 4.3.2.3; NPC020-01 Guidance on Reason Codes for NCT Inst R-transactions v3.1 (published and effective 2026-07-03), section 1; NPC017-01 v3.2, section 2.17", "rests_on": "rule" }, { "label": "SEK: same versions, own header and own errors", "value": "RIX-INST uses pacs.008.001.08, pacs.002.001.10, camt.056.001.08, camt.029.001.09, pacs.004.001.09 and pacs.028.001.03 for the Standard and SIP Models, which are selected with .NPC in the TIPS message header; it always works with 11-character BICs. It publishes its own error code table, which is separate from the NCT Inst reason codes, and warns that its messages are not always identical to the Eurosystem's TIPS versions.", "citation": "Sveriges Riksbank RIX-INST Instructions (June 2026), sections 2.2, 14.1, 14.2, 15.1 Table 46, chapter 22 and Annex 6", "rests_on": "rule" }, { "label": "DKK: validate what you receive", "value": "A TIPS DKK account holder or reachable party must send messages that meet the NCT Inst requirements and must check that incoming messages meet them too, following a technical mapping the Danish sector agreed with Danmarks Nationalbank; a non-compliant incoming message has to be rejected. The terms list pacs.002, pacs.004, pacs.008, pacs.028, camt.029 and camt.056 among the messages processed on TIPS accounts, and point to the TIPS UDFS for validation rules and error codes.", "citation": "Danmarks Nationalbank Terms and Conditions for Accounts in TARGET DKK (effective 2026-06-15), Part V Article 2(4); Appendices to the Terms and Conditions (2026-06-15), Appendix 1 paragraphs 4(d) and 6(d)", "rests_on": "rule" } ], "exceptions": [ "DKK: a Finans Danmark note of 2025-03-10 records that TIPS DKK, under a waiver from the NPC, did not accept the camt.029 reason codes ARDT and NOOR and rejected recalls answered with them, pending Danmarks Nationalbank's alignment with the rulebook. [Unverified: whether the waiver still applies.] (Finans Danmark AOS note, 2025-03-10)", "NOK: no NOK settlement service exists, so no operator message rules for NOK exist yet (Norges Bank, Financial Infrastructure 2026, 2026-06-10).", "SEK: RIX-INST's ELKT Model for cross-currency payments uses its own header code .XCY and its own validation, and recalls in that model are not supported; it is not an NCT Inst route (RIX-INST Instructions June 2026, sections 14.2 and 15.1).", "Communities may use additional ISO 20022 elements as Additional Optional Services; a receiving PSP outside that community may ignore them or reject the message (NPC012-01 2025 v1.1, section 1.2).", "The two NPC texts do not list quite the same reject codes. The Inter-PSP guidelines give their pacs.002 reject codes as examples and include DS24 and RR09, which the reason code guidance v3.1 does not describe (NPC012-01 2025 v1.1, section 2.2.2; NPC020-01 v3.1, section 3). Which list bounds the codes a Participant may use is not settled by either text. [Unverified]" ], "applies_to": "the inter-PSP ISO 20022 messages for NCT Inst payments in SEK, DKK or NOK and their R-transactions, and the settlement operators' message handling for SEK and DKK", "caveat": "Three code lists can appear on the same wire: the NCT Inst reason codes, the settlement operator's own error codes, and any product-level codes a bank's app shows. A code seen in a RIX-INST or TIPS rejection is not necessarily an NCT Inst reason code.", "related": [ "nct-inst:recall", "nct-inst:return", "nct-inst:settlement" ], "basis": { "sources": "NPC012-01 NCT Inst Inter-PSP Implementation Guidelines 2025 v1.1 (2025-11-21), abstract, sections 0.1, 1, 1.2 to 1.7, 2.1.1 and the table of contents 2.1 to 2.11. NPC010-01 NCT Inst Rulebook 2025 v1.1, sections 0.5.1, 2.7, 4.2.3 A, 4.3.2.1 to 4.3.2.3, 5.2, Annex IV. NPC020-01 v3.1, section 1. NPC017-01 v3.2, sections 2.11 and 2.17. Sveriges Riksbank RIX-INST Instructions (June 2026), sections 2.2, 14, 15, 22 and Annex 6. Danmarks Nationalbank Terms and Conditions for Accounts in TARGET DKK and Appendices (2026-06-15). Finans Danmark AOS note (2025-03-10).", "confidence": "high" }, "currency": { "effective_since": "2025-11-21", "effective_note": "Inter-PSP IG 2025 v1.1 issued and effective 2025-11-21 with rulebook 2025 v1.1; the reason code guidance in force is v3.1 of 2026-07-03. The unstructured address format ends on 2026-11-15. The 2027 rulebook and IGs are due for publication in November 2026.", "source_edition": "NPC012-01 Inter-PSP IG 2025 v1.1 (2025-11-21); NPC010-01 Rulebook 2025 v1.1 (2025-11-21); NPC020-01 v3.1 (2026-07-03); RIX-INST Instructions (June 2026); Danmarks Nationalbank Terms and Conditions (2026-06-15)", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "rail_name": "Nordic Credit Transfer Instant (NCT Inst)", "governing_authority": "Nordic Payments Council", "snapshot": "2026-09-18", "source_class": null, "effective_status": "draft", "effective_status_reason": null, "boundaries": [] }, { "uid": "nct-inst:participants", "id": "participants", "rail": "nct-inst", "kind": "rail-fact", "facet": "participants", "name": "Who can take part in NCT Inst, and how?", "statement": "Payment service providers established in a SEPA scheme country, Greenland or the Faroe Islands can join, but unlike the EPC schemes they must first be members of the NPC or be approved as non-member participants. A Participant signs the Adherence Agreement, must at least be able to receive payments, and must be reachable domestically in at least one Scheme Currency; it may opt out of cross-border payments per currency. Each central bank adds its own entry conditions: in SEK every RIX-INST participant must adhere to NCT Inst and accept its payments, and in DKK a TIPS account holder must adhere to NCT Inst and to a Danish community service for automatic recalls. In September 2025 the NPC reported 74 NCT Inst participants, 54 for DKK and 20 for SEK, and none for NOK.", "details": [ { "label": "Membership comes first", "value": "To be a Participant an institution must be an NPC Scheme Member, unless the NPC's Board approves it as a Non-Member Participant under the NPC Bylaws, and it must sign the Adherence Agreement, which binds it to the rulebook.", "citation": "NPC010-01 NCT Inst Rulebook 2025 v1.1 (issued and effective 2025-11-21), sections 1.5, 5.4 item 1 and 5.5", "rests_on": "rule" }, { "label": "Who is eligible", "value": "Geography comes first: a Participant has to be established in Greenland, the Faroe Islands or a country on the EPC list of SEPA scheme countries. Beyond that the tests are about fitness and function: access to at least one CSM, directly or indirectly; a real business in payment accounts and payment services; financial soundness; controls for risk, money laundering and sanctions. An EEA-authorised credit institution passes automatically, and an authorised payment institution or other PSP under the Payment Services Directive is treated as passing several of the tests.", "citation": "NPC010-01 2025 v1.1, section 5.4", "rests_on": "rule" }, { "label": "What every Participant must be able to do", "value": "Each Participant takes part at least as a Beneficiary PSP and must be reachable domestically in at least one of the Scheme Currencies it adheres to. It may accept cross-border payments or opt out; opting out of receiving them also bars sending them, and the choice can be made per scheme and per currency.", "citation": "NPC010-01 2025 v1.1, sections 2.2, 2.4, 2.6 and 5.3; NPC017-01 Clarification Paper v3.2 (effective 2025-12-21), section 2.1", "rests_on": "rule" }, { "label": "What counts as cross-border", "value": "A cross-border payment is one where the two PSPs are in different countries, which PSPs usually detect from the IBAN country codes. Payments between Danish, Faroese and Greenlandic IBANs are not treated as cross-border, because all three settle through Danmarks Nationalbank.", "citation": "NPC010-01 2025 v1.1, chapter 7, defined terms Cross-border NCT Inst Transactions and Cross-border Payment; NPC017-01 v3.2, section 2.2", "rests_on": "guidance" }, { "label": "The participant list", "value": "The NPC keeps the List of NCT Inst Scheme Participants, including each Participant's admission date and adhered currencies, and makes it available to Participants; applicants consent to publication of those details.", "citation": "NPC010-01 2025 v1.1, section 5.6", "rests_on": "rule" }, { "label": "How many", "value": "The NPC told the ECB's TIPS Consultative Group that in September 2025 there were 74 NCT Inst scheme participants, 54 for DKK and 20 for SEK.", "citation": "NPC presentation to the ECB TIPS Consultative Group, 2025-10-21, slide 6", "rests_on": "practice" }, { "label": "SEK: RIX-INST entry conditions", "value": "An institution must first be a RIX Participant and then be certified for RIX-INST; signing the NCT Inst Adherence Agreement is a condition of certification, every RIX-INST participant must at least be able to receive NCT Inst payments in the Standard Model, and since November 2024 all are obliged to accept them. Others can take part indirectly as Reachable Parties through a participant's account, and only PSPs can be Reachable Parties.", "citation": "Sveriges Riksbank RIX-INST Instructions (June 2026), sections 3.4, 3.5, 10.1 to 10.3 and 14.2; Sveriges Riksbank, Payments Report 2025, section RIX-INST enables competition and innovation", "rests_on": "rule" }, { "label": "DKK: TIPS account entry conditions", "value": "Credit institutions, payment institutions and e-money institutions supervised in Denmark, and certain foreign ones, may apply to Danmarks Nationalbank. A TIPS account applicant must hold a main cash account and prove adherence to NCT Inst and to the Danish community's service for automatic acceptance of DUPL and TECH recalls; each reachable party it designates must meet the same adherence conditions, and it must stop one that no longer does.", "citation": "Danmarks Nationalbank Terms and Conditions for Accounts in TARGET DKK (effective 2026-06-15), Part I Articles 4(1) and 5(2) and 5(4), Part V Article 3", "rests_on": "rule" } ], "exceptions": [ "NOK: NOK has been a Scheme Currency since 2021, but the NPC's September 2025 count lists participants only for DKK and SEK, and no NOK settlement service exists yet (NPC100-01 v1.1; NPC presentation to the TIPS Consultative Group, 2025-10-21, slide 6; Norges Bank, Financial Infrastructure 2026). [Inference: no PSP can be live for NOK today.]", "SEK: the Riksbank reported in its Payments Report 2025 that only two smaller banks send payments in the NCT Inst standard format in RIX-INST daily, so accepting NCT Inst and offering it to customers are different things (Sveriges Riksbank, Payments Report 2025).", "Participants outside the EEA, such as those in the Faroe Islands and Greenland, carry the rulebook's substantial-equivalence duty in place of the Payment Services Directive (NPC010-01 2025 v1.1, section 5.14).", "The List of NCT Inst Scheme Participants is made available to Participants; whether a public copy exists was not established, so no participant can be named from it here. [Unverified]", "A Participant may leave on at least six months' written notice, taking effect on a day the NPC designates, and remains bound for what it did before leaving (NPC010-01 2025 v1.1, section 5.11)." ], "applies_to": "payment service providers that participate, or want to participate, in the NPC Instant Credit Transfer Scheme in SEK, DKK or NOK, directly or through another PSP, and the central bank entry conditions for SEK and DKK", "caveat": "Participant counts are a snapshot reported by the NPC for September 2025, not a rule, and will be out of date. Being able to receive NCT Inst, which the Riksbank requires, does not mean a bank lets its customers send it.", "related": [ "nct-inst:settlement", "nct-inst:messages", "nct-inst:recall" ], "basis": { "sources": "NPC010-01 NCT Inst Rulebook 2025 v1.1 (2025-11-21), sections 1.5, 2.2, 2.4, 2.6, 5.3 to 5.6, 5.11, 5.14, chapter 7. NPC017-01 Clarification Paper v3.2, sections 2.1 and 2.2. NPC100-01 v1.1. NPC presentation to the ECB TIPS Consultative Group (2025-10-21), slide 6. Sveriges Riksbank RIX-INST Instructions (June 2026), sections 3.4, 3.5, 10, 14.2; Payments Report 2025. Danmarks Nationalbank Terms and Conditions for Accounts in TARGET DKK (2026-06-15), Part I Articles 4 and 5, Part V Article 3. Norges Bank Financial Infrastructure 2026.", "confidence": "high" }, "currency": { "effective_since": "2025-11-21", "effective_note": "Rulebook 2025 v1.1 effective 2025-11-21. Participant counts are as reported by the NPC for September 2025. The Riksbank's obligation to accept NCT Inst dates from November 2024.", "source_edition": "NPC010-01 NCT Inst Rulebook 2025 v1.1 (2025-11-21); NPC017-01 v3.2; RIX-INST Instructions (June 2026); Danmarks Nationalbank Terms and Conditions for Accounts in TARGET DKK (2026-06-15)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.nordicpaymentscouncil.org/media/0mib5gjt/npc010-01-2025-nct-instant-rulebook-version-11.pdf", "source_class": "authoritative_primary", "source_title": "NPC010-01 NCT Inst Rulebook 2025 v1.1", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms that a Participant must be an NPC Scheme Member or an NPC Board approved Non-Member Participant and must sign the Adherence Agreement, the geography and fitness tests for eligibility, that every Participant takes part at least as a Beneficiary PSP and must be reachable domestically in at least one adhered Scheme Currency, the cross-border opt-out rule, the definitions of cross-border transactions, the List of NCT Inst Scheme Participants held under section 5.6 and made available to Participants, the substantial-equivalence duty for non-EEA Participants, and the six month notice period to leave the scheme." }, { "source_url": "https://www.riksbank.se/globalassets/media/rix/rix-inst-rtgs/engelska/rix-inst-instructions.pdf", "source_class": "authoritative_primary", "source_title": "Sveriges Riksbank, RIX-INST Instructions, June 2026", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms that an institution must be a RIX Participant and then be certified for RIX-INST, that signing the NCT Inst Adherence Agreement is a condition of certification, and that every RIX-INST participant must at least be able to receive Standard Model payments." }, { "source_url": "https://www.nationalbanken.dk/media/jlgj04wa/terms-and-conditions-for-accounts-in-target-dkk-15-june-2026.pdf", "source_class": "authoritative_primary", "source_title": "Danmarks Nationalbank, Terms and Conditions for Accounts in TARGET DKK, effective 15 June 2026", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms that credit institutions, payment institutions and e-money institutions supervised in Denmark, and certain foreign institutions, may apply to Danmarks Nationalbank as participants, that a TIPS DCA applicant must already hold or open a Main Cash Account, and that TIPS DCA and reachable-party applicants must have adhered to the NPC Instant Credit Transfer Scheme and its Danish Additional Optional Service on automatic acceptance of recalls with reason codes DUPL and TECH." }, { "source_url": "https://www.nordicpaymentscouncil.org/get-involved/list-of-scheme-participants/", "source_class": "public_primary", "source_title": "Nordic Payments Council, List of Scheme Participants", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the NPC publishes a List of Scheme Participants page with CSV and PDF downloads for the NCT Instant Credit Transfer Scheme, reachable via a plain unauthenticated page load, which resolves the earlier open question of whether any public copy of the participant list exists." }, { "source_url": "https://www.riksbank.se/en-gb/payments--cash/payments-in-sweden/payments-report-2025/safety-efficiency-and-accessibility/are-payments-in-sweden-efficient/rix-inst-enables-competition-and-innovation/", "source_class": "public_primary", "source_title": "Sveriges Riksbank, Payments Report 2025, RIX-INST enables competition and innovation", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the sentence that there are currently two smaller banks that send payments on RIX-INST in the standard format on a daily basis, supporting the distinction between accepting NCT Inst and offering it to customers." }, { "source_url": "https://www.ecb.europa.eu/paym/target/target-professional-use-documents-links/tips/shared/pdf/tipsmeetdoc/ecb.tipsmeetdoc251021_TIPS-CG-6.6.en.pdf", "source_class": "public_primary", "source_title": "NPC presentation to the ECB TIPS Consultative Group, 2025-10-21", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the NPC reported 74 NCT Inst scheme participants in September 2025, 54 adhering in DKK and 20 in SEK, with none reported for NOK." } ] }, "rail_name": "Nordic Credit Transfer Instant (NCT Inst)", "governing_authority": "Nordic Payments Council", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "nct-inst:recall", "id": "recall", "rail": "nct-inst", "kind": "rail-fact", "facet": "recall", "name": "Can the sender get an NCT Inst payment back, and who decides?", "statement": "The sender can ask, but the receiving side decides. There are two routes. A Recall is for the Originator PSP's own problems, a duplicate or a technical fault within 10 Banking Business Days, or fraud within 13 months. A Request for Recall by the Originator (RFRO) covers everything else the customer wants undone, such as a wrong account or a wrong amount, within 13 months. In both, the Beneficiary PSP has 15 Banking Business Days to answer, the answer may be no, and each payment gets one attempt of each kind. Denmark adds a community rule under which recalls for duplicates and technical errors are accepted automatically; Norway has a three day legal correction right for PSP errors; Sweden has neither in the NPC's own summary.", "details": [ { "label": "Recall: the Originator PSP's tool", "value": "Only the Originator PSP can start a Recall, possibly at its customer's request, and only for duplicate sending, a technical problem that made the payment wrong, or a fraudulently originated instruction. It may turn down a customer who asks for a Recall on other grounds or too late.", "citation": "NPC010-01 NCT Inst Rulebook 2025 v1.1 (issued and effective 2025-11-21), section 4.3.2.2, steps CT-02.00, CT-02.01 and CT-02.01R", "rests_on": "rule" }, { "label": "Recall windows", "value": "Duplicates and technical errors must be recalled within 10 Banking Business Days of execution, or fewer where local law or community practice sets fewer; fraud within 13 months. The Beneficiary PSP must answer within 15 Banking Business Days of receipt, or fewer on the same basis, and breaches the rulebook if it does not. If its customer has not replied by then, it must send a negative answer saying so.", "citation": "NPC010-01 2025 v1.1, section 4.3.2.2 and step CT-02.03", "rests_on": "rule" }, { "label": "How the Beneficiary PSP handles a Recall", "value": "Where the money is still there, national law and the account contract decide whether the Beneficiary PSP must get its customer's authorisation, may decide to ask, or can debit straight away. It answers no, with a reason, where the payment never arrived or was already sent back, where the customer refuses or does not reply, where the account is closed or lacks funds, or where a legal reason stands in the way.", "citation": "NPC010-01 2025 v1.1, section 4.3.2.2, steps CT-02.03, CT-02.03A and CT-02.03R", "rests_on": "rule" }, { "label": "RFRO: the customer's request", "value": "An RFRO serves any reason outside the three Recall grounds; the rulebook's codes cover the Originator asking with no reason given, a wrong amount, and a wrong account identifier. The payment's debit date must be within 13 months before the Originator PSP received the request, and the Originator PSP must tell its customer that getting the money back is not guaranteed and depends on the Beneficiary's consent. It may send the RFRO instantly or not.", "citation": "NPC010-01 2025 v1.1, section 4.3.2.3 and process step 1, and section 4.6 attribute AT-R071", "rests_on": "rule" }, { "label": "RFRO answer and its finality", "value": "The Beneficiary PSP puts the request and its reason to the Beneficiary and must answer within 15 Banking Business Days, or fewer where local law or community practice applies. A yes means debiting the Beneficiary and returning the funds; a no is passed back to the Originator. The Beneficiary's communicated decision settles the fate of the original payment for both PSPs.", "citation": "NPC010-01 2025 v1.1, section 4.3.2.3, steps 3, 4A and 4B", "rests_on": "rule" }, { "label": "Amounts, fees, currency and count", "value": "The amount sent back may be less than the original, because the Beneficiary PSP may charge the Originator PSP a fee, only on a positive answer. Funds go back in the original currency. One Recall and one RFRO per payment, and none can be repeated after an answer. If no answer comes in 15 Banking Business Days, the Originator PSP may ask for a status update.", "citation": "NPC010-01 2025 v1.1, sections 2.4, 4.3.2.2 and 4.3.2.3, steps CT-02.07 and 4C", "rests_on": "rule" }, { "label": "The messages", "value": "Recall and RFRO both travel as camt.056.001.08; a negative answer is camt.029.001.09, a positive answer is pacs.004.001.09, and a status update request is pacs.028.001.03.", "citation": "NPC012-01 NCT Inst Inter-PSP Implementation Guidelines 2025 v1.1 (2025-11-21), section 1 table and sections 2.3 to 2.11", "rests_on": "rule" }, { "label": "SEK: RIX-INST only passes it on", "value": "RIX-INST acts as a technical go-between for recall requests under NCT Inst. It checks that the sender may send one and that the original beneficiary participant is reachable, and does no more checking; the beneficiary participant accepts or rejects, and may repay the original amount or less.", "citation": "Sveriges Riksbank RIX-INST Instructions (June 2026), sections 15.1 and 15.2", "rests_on": "rule" } ], "exceptions": [ "DKK: every TIPS DKK account holder and reachable party must adhere to a Danish Additional Optional Service under which a Recall from the sending PSP with reason DUPL or TECH is accepted automatically and the full amount returned; the Beneficiary PSP may still refuse only where the money was already returned (ARDT), the original payment never arrived (NOOR), or the amounts do not match. Customer-initiated requests stay under the scheme rules (Danmarks Nationalbank Terms and Conditions for Accounts in TARGET DKK, effective 2026-06-15, Part I Article 5(2)(e) and Part V Articles 2(4) and 3; Finans Danmark AOS note, 2025-03-10, effective 2025-04-22).", "DKK: the Finans Danmark note of 2025-03-10 records a waiver from the NPC under which TIPS DKK did not accept the negative answer codes ARDT and NOOR, so a DKK recall answered with them was rejected by TIPS DKK until Danmarks Nationalbank announces alignment. [Unverified: whether the waiver still applies in September 2026.]", "DKK: for TIPS DKK instant payments the NPC's country table applies the rulebook's own 10 and 15 day periods; the five day practice it lists for Denmark belongs to batch clearing (NPC017-01 Clarification Paper v3.2, section 2.14 table).", "NOK: the NPC's country table cites the Norwegian Financial Contracts Act section 4-25 for PSP recalls of duplicates and technical errors, which lets a PSP correct its own erroneous credit by debiting the account before the end of the third working day (NPC017-01 v3.2, section 2.14 table; Finansavtaleloven, LOV-2020-12-18-146, section 4-25(2), read on Lovdata). NOK has no live NCT Inst settlement yet.", "SEK: the NPC's country table gives no Swedish law, a three day best practice only for corrections in Dataclearing (a batch system), and notes there is no Swedish best practice for recalls by the Originator PSP; NCT Inst in SEK therefore runs on the rulebook's 10 and 15 day periods [Inference from NPC017-01 v3.2, section 2.14 table].", "Currency conversion losses on a payment converted at the Beneficiary PSP may be taken into the recall fee or settled bilaterally outside the procedure (NPC017-01 v3.2, section 2.7)." ], "applies_to": "requests by the Originator PSP or the Originator to get back a settled NCT Inst payment in SEK, DKK or NOK, and the Beneficiary side's answer", "caveat": "A Recall or RFRO is a request, never a right to the money. Except under the Danish rule for DUPL and TECH recalls, the Beneficiary side can say no, and silence for 15 Banking Business Days ends in a no.", "related": [ "nct-inst:finality", "nct-inst:return", "nct-inst:settlement", "nct-inst:decision-points", "nct-inst:messages", "nct-inst:refund" ], "basis": { "sources": "NPC010-01 NCT Inst Rulebook 2025 v1.1 (2025-11-21), sections 2.4, 4.3.2.2, 4.3.2.3, 4.6 (AT-R051, AT-R071). NPC012-01 Inter-PSP Implementation Guidelines 2025 v1.1, section 1 and table of contents 2.3 to 2.11. NPC017-01 Clarification Paper v3.2, sections 2.7, 2.13, 2.14 (country table read as an image) and 2.15. Sveriges Riksbank RIX-INST Instructions (June 2026), section 15. Danmarks Nationalbank Terms and Conditions for Accounts in TARGET DKK (2026-06-15), Part I Article 5 and Part V Articles 2, 3 and 7. Finans Danmark AOS note (2025-03-10), linked from the NPC Additional Optional Services page. Finansavtaleloven section 4-25 on Lovdata.", "confidence": "high" }, "currency": { "effective_since": "2025-11-21", "effective_note": "Rulebook 2025 v1.1 effective 2025-11-21. The 2025 edition added the words allowing fewer days where local law or community practice applies, and the one-Recall and one-RFRO rules (Annex IV, entries for sections 4.3.2.2 and 4.3.2.3). The Danish AOS took effect 2025-04-22. The 2027 rulebook is due for publication in November 2026.", "source_edition": "NPC010-01 NCT Inst Rulebook 2025 v1.1 (2025-11-21); NPC012-01 Inter-PSP IG 2025 v1.1; NPC017-01 v3.2; Danmarks Nationalbank Terms and Conditions for Accounts in TARGET DKK (2026-06-15); Finans Danmark AOS note (2025-03-10)", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "rail_name": "Nordic Credit Transfer Instant (NCT Inst)", "governing_authority": "Nordic Payments Council", "snapshot": "2026-09-18", "source_class": null, "effective_status": "draft", "effective_status_reason": null, "boundaries": [] }, { "uid": "nct-inst:refund", "id": "refund", "rail": "nct-inst", "kind": "rail-fact", "facet": "refund", "name": "Does anyone have a right to be refunded for an NCT Inst payment, and on what grounds?", "statement": "Not under the scheme. NCT Inst is a credit push with no refund process: a payer who regrets an authorised payment can only ask, through an RFRO, and the payee may refuse. Refund rights come from national payment services law, which the rulebook requires every Participant to follow or match in substance. They turn on whether the payment was authorised and whether it was executed correctly. For SEK and NOK the national acts were read for this record; they put an unauthorised payment back on the payer's account with small deductibles and a thirteen month notice limit in Sweden, and treat a payment made to the account number given as correctly executed, leaving only a duty to try to recover it. The Danish act was not read.", "details": [ { "label": "No refund in the scheme", "value": "The rulebook's Exception Processing is Reject, Recall and RFRO. None is a refund right: a Recall is the Originator PSP's request for its own errors or fraud, and an RFRO depends on the Beneficiary's consent, which the Originator PSP must warn its customer about.", "citation": "NPC010-01 NCT Inst Rulebook 2025 v1.1 (issued and effective 2025-11-21), sections 4.3.2, 4.3.2.2 and 4.3.2.3", "rests_on": "rule" }, { "label": "The rulebook hands the question to payment services law", "value": "Using the scheme presupposes that Titles III and IV of the Payment Services Directive, or equivalent binding rules, are in force nationally. Participants must comply with those titles at all times, and one not subject to the Directive must take on substantially equivalent obligations towards other Participants and its customers.", "citation": "NPC010-01 2025 v1.1, sections 1.9, 5.1 and 5.14", "rests_on": "rule" }, { "label": "SEK: an unauthorised payment is put back", "value": "Under the Swedish Payment Services Act the account holder's PSP must restore the account at once, and by the end of the next banking day after it learns of an unauthorised transaction at the latest; only grounds to suspect the transaction was in fact authorised buy it time, and a missed deadline must be explained to Finansinspektionen. What the account holder can be made to bear is small: nothing for debits after it asked for the instrument to be blocked, unless it acted fraudulently; at most SEK 12,000 if it is a consumer and was grossly negligent; and at most SEK 400 where it merely failed to protect a personal security credential.", "citation": "Lag (2010:751) om betaltjänster, chapter 5 a sections 1 to 4, consolidated to SFS 2026:1068, read on riksdagen.se", "rests_on": "law" }, { "label": "SEK: the notice limit", "value": "The Swedish account holder loses the protection if it does not notify its PSP as soon as it can after learning of an unauthorised transaction, or within thirteen months of the debit where the PSP has given it the transaction information.", "citation": "Lag (2010:751) om betaltjänster, chapter 5 a section 6", "rests_on": "law" }, { "label": "SEK: a wrong account number is the payer's risk", "value": "If the payer gave a wrong unique identifier, the PSP carries no liability for the payment failing or going wrong, because the law treats a payment made to the identifier given as correctly executed towards that payee. What remains is a recovery effort: the payer's PSP must take reasonable steps and may charge for them if the framework contract allows, the payee's PSP must help with the information it has, and a payer left without its money can ask in writing for what it needs to go to court.", "citation": "Lag (2010:751) om betaltjänster, chapter 5 section 45", "rests_on": "law" }, { "label": "SEK: a payment the bank got wrong", "value": "Where the payer's PSP is responsible for a payment that was not executed or was executed defectively, it must refund the amount or restore the debited account as soon as it can, value dated no later than the original debit, and must on request try to trace the payment free of charge.", "citation": "Lag (2010:751) om betaltjänster, chapter 5 sections 47 to 49", "rests_on": "law" }, { "label": "NOK: an unauthorised payment", "value": "Under the Norwegian Financial Contracts Act the starting point is that the PSP carries the customer's loss from an unauthorised payment. The customer carries nothing, unless it acted fraudulently, for losses after it notified, where the PSP gave it no way to notify, or where strong customer authentication was not required. Otherwise its share is a deductible of up to NOK 450 for a lost, stolen or misappropriated instrument, up to NOK 12,000 for gross negligence with an electronic instrument, and the whole loss only for intentional breach.", "citation": "Finansavtaleloven (LOV-2020-12-18-146), section 4-30, read on Lovdata 2026-09-18", "rests_on": "law" }, { "label": "NOK: a wrong account number", "value": "Where the payer gave a wrong account number, the PSP must still take reasonable steps to get the amount back, the payee's PSP must cooperate, and a payer who cannot recover it may ask in writing for the information needed to pursue it. The PSP itself is not liable, because a payment made to the account number or other unique identifier given counts as correctly executed towards the payee that identifier points to, whatever other details the customer added.", "citation": "Finansavtaleloven (LOV-2020-12-18-146), section 4-26", "rests_on": "law" } ], "exceptions": [ "DKK: the Danish Payments Act (lov om betalinger) was not read, so no Danish refund rule is stated here. [Unverified: the rulebook's reliance on Payment Services Directive Titles III and IV suggests equivalent Danish rights exist, but that is inference only.]", "NOK: the Norwegian rules apply to payment services in Norway generally, but no NCT Inst payment in NOK can be made yet because no NOK settlement service exists (Norges Bank, Financial Infrastructure 2026, 2026-06-10).", "DKK: the Danish automatic acceptance of DUPL and TECH recalls returns money for the sending PSP's own mistakes; it is a scheme service between PSPs, not a refund right a customer can invoke (Finans Danmark AOS note, 2025-03-10, effective 2025-04-22).", "A payment converted at the Beneficiary PSP may come back short after a Recall or RFRO because of currency conversion losses, which may be covered in the recall fee or settled bilaterally (NPC017-01 Clarification Paper v3.2, section 2.7).", "Participants established outside the EEA, including in the Faroe Islands and Greenland, are bound only by the rulebook's requirement to take on substantially equivalent obligations to the extent their national law permits (NPC010-01 2025 v1.1, sections 2.1 and 5.14). [Unverified: which payment services law applies in the Faroe Islands and Greenland was not checked.]" ], "applies_to": "a payer whose NCT Inst payment in SEK, DKK or NOK was unauthorised, executed defectively, or sent to the wrong account, and a payer who wants an authorised payment back", "caveat": "Refund rights are national law, not scheme rules, and this record reads the Swedish and Norwegian acts only. The deductibles and caps are consumer-facing figures under those acts and can change without any change to the NPC rulebook.", "related": [ "nct-inst:recall", "nct-inst:return", "nct-inst:finality" ], "basis": { "sources": "NPC010-01 NCT Inst Rulebook 2025 v1.1 (2025-11-21), sections 1.9, 2.1, 4.3.2 to 4.3.2.3, 5.1, 5.14. NPC017-01 Clarification Paper v3.2, section 2.7. Lag (2010:751) om betaltjänster, consolidated to SFS 2026:1068, read on riksdagen.se 2026-09-18: chapter 5 sections 45 and 47 to 49, chapter 5 a sections 1 to 4 and 6. Finansavtaleloven (LOV-2020-12-18-146), sections 4-26 and 4-30, read on Lovdata 2026-09-18. Finans Danmark AOS note (2025-03-10). Norges Bank Financial Infrastructure 2026.", "confidence": "medium" }, "currency": { "effective_since": "2025-11-21", "effective_note": "Rulebook 2025 v1.1 effective 2025-11-21. The Swedish act was read in its consolidation up to SFS 2026:1068, and the Norwegian act as published on Lovdata on 2026-09-18; the relevant Swedish sections carry amendment references to Lag (2018:175) and Lag (2022:723).", "source_edition": "NPC010-01 NCT Inst Rulebook 2025 v1.1 (2025-11-21); Lag (2010:751) om betaltjänster (to SFS 2026:1068); Finansavtaleloven LOV-2020-12-18-146 (Lovdata, read 2026-09-18)", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "rail_name": "Nordic Credit Transfer Instant (NCT Inst)", "governing_authority": "Nordic Payments Council", "snapshot": "2026-09-18", "source_class": null, "effective_status": "draft", "effective_status_reason": null, "boundaries": [] }, { "uid": "nct-inst:return", "id": "return", "rail": "nct-inst", "kind": "rail-fact", "facet": "return", "name": "Can the receiving side send an NCT Inst payment back on its own?", "statement": "No. NCT Inst has no Return. A Beneficiary PSP that cannot or will not apply a payment rejects it within the seconds of the payment itself; once the funds are with the Beneficiary, the scheme gives the receiving side no message for sending them back on its own initiative. Money travels back in only two ways: as the answer to a Recall or Request for Recall by the Originator, or as a brand-new payment that the Beneficiary chooses to make. The message used for a positive recall answer is called a Payment Return in ISO 20022, which is a naming trap, not a Return right.", "details": [ { "label": "Three exception types, none of them a Return", "value": "The rulebook's Exception Processing consists of the Reject, the Recall and the Request for Recall by the Originator. It then states that it provides no exception process for a Beneficiary who wants to give the funds back, and sends that Beneficiary to its own PSP to arrange another payment.", "citation": "NPC010-01 NCT Inst Rulebook 2025 v1.1 (issued and effective 2025-11-21), sections 4.3.2, 4.3.2.1 to 4.3.2.4", "rests_on": "rule" }, { "label": "Refusal happens before, not after", "value": "A Beneficiary PSP that cannot apply a payment answers with a negative confirmation carrying a reason code inside the execution time, and the Originator PSP then cancels the reservation on its customer's account. Nothing has been paid, so nothing needs returning.", "citation": "NPC010-01 2025 v1.1, sections 4.3.1 CT-01.06, 4.3.2.1 CT-01.06R and 5.8 items 11 and 13", "rests_on": "rule" }, { "label": "The return message is only an answer", "value": "In the inter-PSP messages the pacs.004 Payment Return carries the positive answer to a Recall or an RFRO, and nothing else. A Beneficiary PSP that agrees to give money back has to use it, and may not send the money as a separate NCT Inst payment instead.", "citation": "NPC012-01 NCT Inst Inter-PSP Implementation Guidelines 2025 v1.1 (2025-11-21), section 1 table and sections 2.5 and 2.10; NPC010-01 2025 v1.1, sections 4.3.2.2 and 4.3.2.3 step 4A", "rests_on": "rule" }, { "label": "SEK: the settlement service says the same", "value": "RIX-INST uses the return message only for a beneficiary accepting a recall request, and then settles and confirms it; there is no separate return flow.", "citation": "Sveriges Riksbank RIX-INST Instructions (June 2026), sections 15.1 Table 46 and 15.2", "rests_on": "rule" }, { "label": "Giving money back as a new payment", "value": "The NPC's clarification paper suggests that a Beneficiary sending funds back make a new NCT or NCT Inst payment to the Originator's account, may mark it with the purpose code RRCT and may quote the Originator's original reference. Where data protection law stops the Beneficiary's PSP from showing its customer the Originator's IBAN, the transfer back needs a specific arrangement between that PSP and its customer, using a reference the PSP supplies.", "citation": "NPC017-01 Clarification Paper on the NCT and NCT Inst Rulebooks v3.2 (published 2025-10-01, effective 2025-12-21), section 2.16", "rests_on": "guidance" } ], "exceptions": [ "DKK: under the Danish community's Additional Optional Service, a DKK Beneficiary PSP automatically returns the full amount when the sending PSP recalls a payment as a duplicate (DUPL) or a technical error (TECH). That works like a return in practice but is still a Recall answer, started by the Originator PSP (Finans Danmark, NPC AOS Automatic acceptance of PSP-initiated Request for Recall with reason code DUPL and TECH, 2025-03-10, effective 2025-04-22; Danmarks Nationalbank Terms and Conditions for Accounts in TARGET DKK, 2026-06-15, Part V Article 2(4)).", "NOK: Norwegian law lets a payment service provider that by its own error credited the wrong account or the wrong amount correct it by debiting the account before the end of the third working day, including at another provider where it has access to do so; the right does not apply where the credit was made on a third person's payment order. It is a legal correction right of the PSP, not a scheme Return, and the NPC lists it for Norway against PSP recalls for duplicates and technical errors. [Inference: how it would sit beside the NCT Inst Recall window once NOK goes live is not stated in any NPC text.] (Finansavtaleloven, LOV-2020-12-18-146, section 4-25(2) and (3), read on Lovdata; NPC017-01 v3.2, section 2.14 table).", "SEK: no Swedish legal correction right was found in the NPC texts; the NPC clarification paper lists no Swedish law for PSP corrections and gives only a three day best practice for Dataclearing corrections, which is a batch system, not NCT Inst (NPC017-01 v3.2, section 2.14 table). [Unverified: the Swedish Payment Services Act was not searched for a correction right.]", "A payment rejected on the Originator PSP's side before it is sent never enters the inter-PSP space; the Originator PSP only has to tell its customer why (NPC010-01 2025 v1.1, section 4.3.2.1)." ], "applies_to": "a settled NCT Inst payment in SEK, DKK or NOK and whether the Beneficiary PSP or the Beneficiary can send it back without a request from the Originator side", "caveat": "In SEPA Credit Transfer a Return exists; in NCT Inst, as in SEPA Instant, it does not. Code lists and message names that mention a return here always describe a positive answer to a Recall or RFRO.", "related": [ "nct-inst:finality", "nct-inst:settlement", "nct-inst:recall", "nct-inst:refund", "nct-inst:messages" ], "basis": { "sources": "NPC010-01 NCT Inst Rulebook 2025 v1.1 (2025-11-21), sections 4.3.1, 4.3.2 to 4.3.2.4, 5.8. NPC012-01 Inter-PSP Implementation Guidelines 2025 v1.1, section 1 and the tables of contents for 2.5 and 2.10. NPC017-01 Clarification Paper v3.2, sections 2.14 (table read as an image) and 2.16. Sveriges Riksbank RIX-INST Instructions (June 2026), section 15. Finans Danmark AOS note of 2025-03-10, linked from the NPC's Additional Optional Services page. Danmarks Nationalbank Terms and Conditions for Accounts in TARGET DKK (2026-06-15), Part V Article 2. Norwegian Financial Contracts Act (Finansavtaleloven) section 4-25, read on Lovdata 2026-09-18.", "confidence": "high" }, "currency": { "effective_since": "2025-11-21", "effective_note": "Rulebook 2025 v1.1 effective 2025-11-21; the no-Return design is the same in 2025 v1.0. The Danish AOS took effect on 2025-04-22. The 2027 rulebook is due for publication in November 2026.", "source_edition": "NPC010-01 NCT Inst Rulebook 2025 v1.1 (2025-11-21); NPC012-01 Inter-PSP IG 2025 v1.1 (2025-11-21); NPC017-01 v3.2; Finans Danmark AOS note (2025-03-10)", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "rail_name": "Nordic Credit Transfer Instant (NCT Inst)", "governing_authority": "Nordic Payments Council", "snapshot": "2026-09-18", "source_class": null, "effective_status": "draft", "effective_status_reason": null, "boundaries": [] }, { "uid": "nct-inst:settlement", "id": "settlement", "rail": "nct-inst", "kind": "rail-fact", "facet": "settlement", "name": "How does NCT Inst settlement work, when does it happen, and in what money?", "statement": "The NPC scheme does not settle anything itself. It obliges each Originator PSP to give settlement certainty through a CSM of its choice and leaves the settling to that CSM. In practice each currency has one central bank service: SEK settles one payment at a time in central bank money in the Riksbank's RIX-INST, DKK settles the same way on Danmarks Nationalbank's TIPS accounts, and both run on the Eurosystem's TIPS platform. NOK has no instant settlement service yet. Settlement is in the currency the Originator PSP sent, and R-transactions go back in that same currency.", "details": [ { "label": "The scheme sets the duty, not the mechanism", "value": "The rulebook keeps the scheme apart from infrastructure: Participants pick their CSMs, and the clearing and settlement steps a CSM performs are outside the scheme. What the scheme does require is that the Originator PSP settle a completed payment, provide settlement certainty to the Beneficiary PSP through a CSM, and hold a CSM contract that lets it meet that duty.", "citation": "NPC010-01 NCT Inst Rulebook 2025 v1.1 (issued and effective 2025-11-21), sections 1.4, 1.6, 2.2 and 5.7 items 6 and 8", "rests_on": "rule" }, { "label": "Which currency settles", "value": "The Scheme Currency the Originator PSP sends is the one cleared, settled and received. Any conversion to or from an account in another currency happens at either PSP and is outside the scheme. Rejects, Recalls and RFROs run in the original currency.", "citation": "NPC010-01 2025 v1.1, section 2.4; NPC100-01 Scheme Currencies v1.1 (2021-11-23), section 2", "rests_on": "rule" }, { "label": "SEK: one payment at a time, in RIX-INST", "value": "RIX-INST is the Riksbank's instant settlement service inside RIX, built on the Eurosystem's TIPS platform, and settles each payment individually in central bank money as bookkeeping entries on participants' settlement accounts. In its Standard Model, the one that follows NCT Inst, the amount is reserved on the originating account and moves to the beneficiary account the moment the Beneficiary Participant accepts.", "citation": "Sveriges Riksbank, RIX-INST Instructions (June 2026), sections 1, 3.1, 3.8 and 14.2.1", "rests_on": "rule" }, { "label": "SEK: where the liquidity comes from", "value": "A RIX-INST settlement account cannot go below zero, and no credit is available inside RIX-INST. Liquidity is created in the Riksbank's large-value service, RIX-RTGS, and moved across; transfers run at all hours except for roughly an hour after RIX-RTGS closes on each business day, from 17:58 to 19:00. A bank that takes part only in RIX-INST needs a RIX-RTGS participant as its agent to move liquidity in and pay its fees.", "citation": "Sveriges Riksbank, RIX-INST Instructions (June 2026), sections 3.2, 3.5, 3.6, 3.7 and 12 with Table 28", "rests_on": "rule" }, { "label": "SEK: the Swish model is a different one", "value": "The Riksbank describes a second model, the SIP Model, in which one approved Instructing Party acts for both banks and a payment settles straight after validation without a reservation or a request to the Beneficiary Participant; it gives Swish payments as the case where that happens. Its Payments Report 2025 says interbank Swish payments have settled in RIX-INST since February 2024.", "citation": "Sveriges Riksbank, RIX-INST Instructions (June 2026), section 14.2.2; Sveriges Riksbank, Payments Report 2025, section RIX-INST enables competition and innovation", "rests_on": "rule" }, { "label": "DKK: TIPS accounts at Danmarks Nationalbank", "value": "Instant payments in Danish kroner settle on TIPS dedicated cash accounts that Danmarks Nationalbank opens for holders of its main cash accounts. An instant payment order is checked against the payer's TIPS account, the amount is reserved and cannot be used for anything else, and the order settles when the payee accepts. Insufficient funds, a refusal or no timely answer under the scheme ends in rejection with the reservation lifted.", "citation": "Danmarks Nationalbank, Terms and Conditions for Accounts in TARGET DKK (effective 2026-06-15), Part I Articles 3(3) and 3(8), Part V Articles 1 and 6(3) to 6(5)", "rests_on": "rule" }, { "label": "DKK: a system that moved in 2025", "value": "Danmarks Nationalbank moved krone payments from its Kronos2 system to the Eurosystem's TARGET Services, including TIPS, at Easter 2025, and describes itself as the system owner of TIPS for Danish instant payments.", "citation": "Danmarks Nationalbank press release, 23 April 2025; Danmarks Nationalbank web page The payments infrastructure in Denmark (read 2026-09-18)", "rests_on": "practice" }, { "label": "Positive recall answers settle too", "value": "A positive answer to a Recall or RFRO moves money back and has to settle. The DKK terms route positive recall answers over TIPS accounts and reject one that the paying account cannot cover; the RIX-INST Instructions have the beneficiary side accept a recall with the return message, which RIX-INST then settles and confirms.", "citation": "NPC010-01 2025 v1.1, section 4.3.2.2 step CT-02.05; Danmarks Nationalbank Terms and Conditions for Accounts in TARGET DKK (2026-06-15), Part V Articles 4(1)(c) and 6(7); RIX-INST Instructions (June 2026), section 15.1 Table 46", "rests_on": "rule" } ], "exceptions": [ "NOK: there is no instant settlement service in Norwegian kroner. Norges Bank signed an agreement with the ECB on 2024-11-28 to use TIPS and then planned availability in the first half of 2028; in its Financial Infrastructure 2026 report (2026-06-10) it says the new service, NBO INST, needs more adaptation than assumed and its plan is being revised (Norges Bank press release 2024-11-29; Financial Infrastructure 2026).", "SEK: RIX-INST also offers the ELKT Model for cross-currency payments; it is optional, is based on parts of the EPC OCT Inst scheme, and the Riksbank intends to align it with the NPC's NOLO Inst scheme once published. It is not an NCT Inst settlement route (RIX-INST Instructions June 2026, sections 1 and 3.4).", "SEK: the Riksbank adapts RIX-INST to NCT Inst changes only if told in time, and may be unable to follow changes that depart far from SCT Inst and would require changes to the TIPS platform (RIX-INST Instructions June 2026, section 3.4).", "A community of Participants may replace the up-front reservation of funds with another arrangement, provided it gives the same or higher settlement certainty (NPC010-01 2025 v1.1, section 1.4 step 2).", "Payments inside one PSP, where Originator PSP and Beneficiary PSP are the same Participant, need no interbank settlement (NPC010-01 2025 v1.1, section 3.1). [Inference: the rulebook allows the roles to coincide but does not describe settlement for that case.]" ], "applies_to": "the interbank leg of an NCT Inst payment in SEK, DKK or NOK between an Originator PSP and a Beneficiary PSP, through the CSM each uses, with the central bank settlement services for SEK and DKK", "caveat": "The rulebook describes settlement in general terms and names no CSM; the currency-by-currency picture comes from the Riksbank's and Danmarks Nationalbank's own texts, not from the NPC.", "related": [ "nct-inst:finality", "nct-inst:hours", "nct-inst:limits", "nct-inst:participants", "nct-inst:messages" ], "basis": { "sources": "NPC010-01 NCT Inst Rulebook 2025 v1.1 (2025-11-21), sections 1.4, 1.6, 2.2, 2.4, 3.1, 4.3.2.2, 5.7. NPC100-01 v1.1. Sveriges Riksbank RIX-INST Instructions (June 2026), sections 1, 3.1 to 3.8, 12, 14.2.1, 14.2.2, 15.1; Riksbank Payments Report 2025 web section on RIX-INST. Danmarks Nationalbank Terms and Conditions for Accounts in TARGET DKK (effective 2026-06-15), Part I Article 3, Part V Articles 1, 4 and 6; press release 2025-04-23; web page The payments infrastructure in Denmark. Norges Bank press release 2024-11-29; Norges Bank Financial Infrastructure 2026 (2026-06-10). The Riksbank's Terms and Conditions for RIX were not read.", "confidence": "high" }, "currency": { "effective_since": "2025-11-21", "effective_note": "Rulebook 2025 v1.1 effective 2025-11-21. The RIX-INST Instructions read are the June 2026 edition, and the Danmarks Nationalbank terms the edition effective 2026-06-15; both are re-issued as dated documents. DKK moved to TIPS at Easter 2025 (April 2025). NOK settlement timing is under revision by Norges Bank.", "source_edition": "NPC010-01 NCT Inst Rulebook 2025 v1.1 (2025-11-21); RIX-INST Instructions (June 2026); Danmarks Nationalbank Terms and Conditions for Accounts in TARGET DKK (2026-06-15)", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "rail_name": "Nordic Credit Transfer Instant (NCT Inst)", "governing_authority": "Nordic Payments Council", "snapshot": "2026-09-18", "source_class": null, "effective_status": "draft", "effective_status_reason": null, "boundaries": [] }, { "uid": "paypal:consumer-law", "id": "consumer-law", "rail": "paypal", "kind": "rail-fact", "facet": "consumer-law", "name": "What consumer protections apply to PayPal payments, and where do they come from?", "statement": "PayPal's consumer protections come from two places that must not be confused. Its buyer protection program is a contract promise PayPal makes and decides itself. Separately, each regional agreement writes the local payments law into its terms: the US agreement carries error-resolution, unauthorised-transfer, preauthorised-payment and remittance-transfer rules whose timelines follow the pattern of the Electronic Fund Transfer Act and Regulation E [Inference], and names that Act and the Fair Credit Billing Act; the UK and Irish agreements carry electronic money and payment services rules with regulator and ombudsman routes. Every line below is how PayPal's agreement states the right; the statutes themselves were not read.", "details": [ { "label": "Laws the US agreement names", "value": "Before linking a bank account the user is told to understand the rights the Electronic Fund Transfer Act and the Fair Credit Billing Act give for different funding sources. For card-funded payments, the Purchase Protection page adds that card chargeback rights may be wider than PayPal's program.", "citation": "PayPal User Agreement (US), last updated 2026-09-14, Link or Unlink a Payment Method; PayPal's Purchase Protection Program (US), last updated 2026-01-26, Dispute with PayPal or Your Card Issuer", "rests_on": "rule" }, { "label": "Error resolution timeline", "value": "A user must raise a suspected error within 60 days after PayPal sent the first statement showing it, and may be asked to confirm an oral report in writing within 10 Business Days. PayPal decides within 10 Business Days; if it needs longer it may take up to 45 days, or 90 days for new accounts, point-of-sale and foreign-initiated transfers, but must first credit the disputed amount provisionally within 10 Business Days (20 for new accounts). Results follow within 3 Business Days of finishing, with a written explanation and access to documents if PayPal finds no error.", "citation": "PayPal User Agreement (US), 2026-09-14, Error Resolution; In case of Errors or questions about your electronic transfers", "rests_on": "rule" }, { "label": "Unauthorised transfers", "value": "The user should report at once; a report later than 60 days after the statement showing the transfer may cost the user later losses PayPal could have stopped, though PayPal may extend the time for good reason such as travel or a hospital stay.", "citation": "PayPal User Agreement (US), 2026-09-14, Reporting an Unauthorized Transaction", "rests_on": "rule" }, { "label": "Remittance transfers", "value": "A personal Send Money payment for personal purposes of at least 15 US dollars, received in a PayPal account outside the US, is a Remittance Transfer; checkout payments to merchants are not. Errors must be reported within 180 days of the date PayPal promised the funds would be available; PayPal decides within 90 days and reports within 3 Business Days after that.", "citation": "PayPal User Agreement (US), 2026-09-14, Remittance Transfer Errors", "rests_on": "rule" }, { "label": "Preauthorised payments", "value": "A consumer can stop a recurring automatic payment by telling PayPal at least 3 Business Days before it falls due, and PayPal is liable if it then fails to stop it. Where recurring amounts vary, the consumer is entitled to notice of amount and date at least 10 days ahead, or only when outside an agreed range if the seller offers that option.", "citation": "PayPal User Agreement (US), 2026-09-14, Automatic payments (buying part); Accepting preauthorized payments", "rests_on": "rule" }, { "label": "Business accounts differ", "value": "A debit to a US business account made with its assigned account and routing number without valid authorisation, or above the amount authorised, must be reported by 8 pm Pacific time on the Business Day after it posts; after that the business must recover the money from the originator itself.", "citation": "PayPal User Agreement (US), 2026-09-14, Returning Unauthorized or Excess Business Account Debits", "rests_on": "rule" } ], "exceptions": [ "UK accounts: PayPal UK Ltd is an FCA-authorised electronic money institution and safeguards users' funds under the Electronic Money Regulations 2011. Unexpected billing agreement payments must be raised within eight weeks, and incorrect or unauthorised payments within 13 months; PayPal restores an unauthorised or incorrect payment by the end of the next Business Day. Complaints can go to the Financial Ombudsman Service within 6 months of PayPal's final answer, or to the FCA (PayPal User Agreement (UK), PayPal UK Ltd, 2026-07-15, Information about us; How we protect your PayPal balance; Resolving Problems; Complaints).", "UK accounts: authorised push payment fraud on money sent out of PayPal by Faster Payments or CHAPS may be reimbursed up to 85,000 pounds per claim for payments from 7 October 2024, with a decision usually in 5 business days and always within 35; payments between PayPal accounts and checkout payments fall outside these rules (PayPal User Agreement (UK), 2026-07-15, Authorised Push Payment (APP) Fraud).", "Irish accounts: the same eight-week and 13-month limits apply; electronic money is outside Luxembourg deposit guarantee cover; a bank-funded payer keeps an 8-week SEPA Direct Debit refund right against their bank; complaints may be escalated to the CSSF, the European Consumer Centres Network or a Fin-Net body (PayPal User Agreement (Ireland), PayPal (Europe) S.à r.l. et Cie, S.C.A., 2026-01-22, Holding and using a PayPal balance; Linking and Unlinking a Funding Source; Resolving Problems; Complaints).", "The statutes and regulations named or implied (EFTA and Regulation E including its remittance transfer rule, the FCBA, the UK Payment Services and Electronic Money Regulations, EU payment services and electronic money law) were not read; whether the agreements match them is unconfirmed.", "Agreements for regions other than the US, the UK and Ireland were not read." ], "applies_to": "Consumer (personal) PayPal accounts under the US User Agreement; UK and Irish accounts as noted in exceptions", "caveat": "The US agreement's timelines follow the Regulation E pattern [Inference: the regulation was not read]. Buyer protection for non-receipt or misdescription is PayPal's contract, not statute; the card issuer's rights on a card-funded payment come from the card agreement and card law.", "related": [ "paypal:return", "paypal:liability", "paypal:recall", "paypal:hours", "paypal-dispute:UNAUTHORISED", "paypal-dispute:PROBLEM_WITH_REMITTANCE", "us-ach:consumer-law", "sepa-sdd-core:consumer-law" ], "basis": { "sources": "Read 2026-09-19 with a plain fetch: PayPal User Agreement (US), PayPal, Inc., last updated 2026-09-14 (https://www.paypal.com/us/legalhub/paypal/useragreement-full), sections Link or Unlink a Payment Method, Automatic payments, Accepting preauthorized payments, Liability for Unauthorized Transactions and Other Errors (including Error Resolution, Returning Unauthorized or Excess Business Account Debits, Remittance Transfer Errors); PayPal's Purchase Protection Program (US), last updated 2026-01-26; PayPal User Agreement (UK), PayPal UK Ltd, 2026-07-15, and PayPal User Agreement (Ireland), 2026-01-22, sections Information about us, the balance and safeguarding sections, Resolving Problems, Authorised Push Payment (APP) Fraud (UK), Complaints. No statute was read. Nothing is quoted. Medium because the law behind the agreements was not read; the agreements' own terms are stated directly.", "confidence": "medium" }, "currency": { "effective_since": "2026-09-14", "effective_note": "Dated from the US User Agreement edition read (last updated 2026-09-14). The UK agreement read was last updated 2026-07-15 and the Ireland agreement 2026-01-22. The US Policy Updates page (last updated 2026-08-06) listed no notice with a later effective date on 2026-09-19.", "source_edition": "PayPal User Agreement (US) 2026-09-14; Purchase Protection (US) 2026-01-26; UK User Agreement 2026-07-15; Ireland User Agreement 2026-01-22", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.paypal.com/us/legalhub/paypal/useragreement-full", "source_class": "authoritative_primary", "source_title": "PayPal User Agreement (US), last updated 2026-09-14", "checked_on": "2026-09-19", "checked_by": "validator session 2026-09-19", "notes": "Confirms the error resolution timeline (60 day report window, 10 Business Day acknowledgement, decision within 10 Business Days or up to 45 days with provisional credit, 90 days and 20 Business Days for new or point of sale or foreign initiated transfers, 3 Business Day result window), the unauthorised transfer 60 day reporting rule, the remittance transfer definition and its 180 day and 90 day windows, and the automatic payment stop and variable amount notice rules. Does not address the UK or Irish statutes named in the record, which were not read." } ] }, "rail_name": "PayPal (staged wallet)", "governing_authority": "PayPal (regional entities; US: PayPal, Inc.)", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "paypal:decision-points", "id": "decision-points", "rail": "paypal", "kind": "rail-fact", "facet": "decision-points", "name": "Where do PayPal's rules leave a decision to PayPal or another party?", "statement": "Most judgement on this rail sits with PayPal itself, and its agreements reserve it in terms of sole discretion. PayPal decides whether a buyer's claim is eligible and who wins it, whether to give a temporary refund, whether a seller qualifies for Seller Protection, whether a payment is too risky to complete, and whether to hold, limit or reserve an account, often on criteria it need not disclose. Two decisions sit elsewhere: the card issuer decides a chargeback and the buyer's bank decides a bank reversal. And one sits with the buyer: whether to go to PayPal or to the card issuer.", "details": [ { "label": "Deciding a buyer's claim", "value": "PayPal alone decides whether a claim qualifies for Purchase Protection and how it ends, weighing the eligibility rules, what both sides submit and anything else it thinks relevant; it may close a dispute or claim on its own. Its first decision stands unless an appeal succeeds on new or compelling information or a process error.", "citation": "PayPal's Purchase Protection Program (US), last updated 2026-01-26, opening paragraph; Online Dispute Resolution Process, Step 5", "rests_on": "rule" }, { "label": "Temporary refunds and escalation", "value": "While investigating, PayPal may choose to refund the buyer provisionally; if the buyer then loses, PayPal may take the money back after at least 5 business days' notice. Buyer, seller or PayPal may escalate a dispute to a claim, and PayPal may make the buyer wait at least 7 days from the transaction before escalating.", "citation": "PayPal's Purchase Protection Program (US), 2026-01-26, Online Dispute Resolution Process, Steps 1 and 2", "rests_on": "rule" }, { "label": "Seller appeals", "value": "A seller that loses a claim PayPal decided may appeal twice, through the stages PRE_ARBITRATION and ARBITRATION; a case not appealed within the appeal period is treated as resolved. The developer guide says buyers may also appeal an unfavourable decision.", "citation": "PayPal Disputes OpenAPI specification, customer_disputes_v1.json, Disputes 1.11, schema dispute_lifecycle_stage; PayPal developer guide, Disputes Overview, Internal disputes (undated, read 2026-09-19)", "rests_on": "rule" }, { "label": "Seller Protection eligibility", "value": "PayPal decides at its sole discretion whether a seller's case meets the Seller Protection program, and may treat a transaction as excluded for prohibited activity even after marking it eligible.", "citation": "PayPal's Seller Protection Program (US), 2026-01-26, What's Eligible; Ineligible Items and Transactions", "rests_on": "rule" }, { "label": "Payment review, holds, limitations and reserves", "value": "PayPal decides which payments are high-risk and must be reviewed before shipping, then completes or cancels them. It may hold payments, limit accounts and set rolling or minimum reserves on business accounts, using confidential criteria and proprietary risk models, and has no duty to explain its risk procedures. For court orders and legal process it decides which action the law requires.", "citation": "PayPal User Agreement (US), last updated 2026-09-14, Payment review (selling part); Holds, Limitations, and Reserves; Court Orders, Regulatory Requirements, or Other Legal Processes", "rests_on": "rule" }, { "label": "Decisions outside PayPal", "value": "The card issuer, not PayPal, decides whether a buyer's chargeback on a card-funded payment succeeds; in such cases PayPal passes the merchant's response to the issuer through the card network. The buyer's bank or card issuer decides a bank reversal or chargeback in the same way.", "citation": "PayPal User Agreement (US), 2026-09-14, Payments that are invalidated and reversed; PayPal developer guide, Disputes Overview, External disputes (undated, read 2026-09-19)", "rests_on": "rule" }, { "label": "The buyer's choice", "value": "A card-funded buyer decides whether to claim with PayPal or dispute with the card issuer. Going to the issuer first rules out a later PayPal claim; losing with PayPal leaves the issuer route open.", "citation": "PayPal's Purchase Protection Program (US), 2026-01-26, Dispute with PayPal or Your Card Issuer", "rests_on": "rule" }, { "label": "Stated turnaround", "value": "PayPal's developer guide says PayPal adjudicates an escalated internal case within 10 days. A PayPal business article says sellers get 10 days to answer a claim, that silence closes it for the buyer, and that resolution usually takes about 30 days. Neither figure appears in the agreements.", "citation": "PayPal developer guide, Disputes Overview, Internal disputes (undated, read 2026-09-19); PayPal Business Resource Center article on dispute transactions (2026-07-17), claim resolution timeline", "rests_on": "guidance" } ], "exceptions": [ "UK and Irish accounts: the Buyer Protection pages give PayPal the same sole discretion and the same appeal route (PayPal's Buyer Protection Program (UK), 2026-09-07; (Ireland), 2024-05-28).", "UK accounts: a user unhappy with PayPal's handling of a complaint can go to the Financial Ombudsman Service or the FCA; Irish accounts to the CSSF, the European Consumer Centres Network or a Fin-Net body (PayPal User Agreement (UK), PayPal UK Ltd, 2026-07-15, and (Ireland), 2026-01-22, Complaints).", "US accounts: disputes between a user and PayPal itself, as distinct from buyer and seller disputes, go to informal resolution and then arbitration under terms changed on 2026-09-14 (US Policy Updates page, last updated 2026-08-06).", "Agreements for regions other than the US, the UK and Ireland were not read." ], "applies_to": "PayPal accounts under the US User Agreement; UK and Irish accounts as noted in exceptions", "caveat": "This facet is Orca's reading of where the rules leave judgement open, so it is capped at medium; every line cites the rule that leaves the decision open.", "related": [ "paypal:return", "paypal:liability", "paypal:finality", "paypal:limits", "paypal:participants", "paypal:messages" ], "basis": { "sources": "Read 2026-09-19 with a plain fetch: PayPal's Purchase Protection Program (US) and PayPal's Seller Protection Program (US), both last updated 2026-01-26, in full; PayPal User Agreement (US), PayPal, Inc., last updated 2026-09-14 (https://www.paypal.com/us/legalhub/paypal/useragreement-full), sections Payment review, Holds, Limitations, and Reserves, Court Orders, Payments that are invalidated and reversed; US Policy Updates page, last updated 2026-08-06; PayPal Disputes OpenAPI specification customer_disputes_v1.json, Disputes 1.11; PayPal developer guide, Disputes Overview (undated); PayPal Business Resource Center article on dispute transactions (2026-07-17); PayPal's Buyer Protection Program (UK), 2026-09-07, and (Ireland), 2024-05-28; PayPal User Agreement (UK), 2026-07-15, and (Ireland), 2026-01-22, Complaints. Nothing is quoted. Medium, the cap for this facet.", "confidence": "medium" }, "currency": { "effective_since": "2026-09-14", "effective_note": "Dated from the US User Agreement edition read (last updated 2026-09-14). The US protection program pages were last updated 2026-01-26. The US Policy Updates page (last updated 2026-08-06) listed no notice with a later effective date on 2026-09-19.", "source_edition": "PayPal User Agreement (US) 2026-09-14; Purchase Protection and Seller Protection (US) 2026-01-26; Disputes 1.11; UK and Ireland Buyer Protection 2026-09-07 and 2024-05-28", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.paypal.com/us/legalhub/paypal/useragreement-full", "source_class": "authoritative_primary", "source_title": "PayPal User Agreement (US), last updated 2026-09-14", "checked_on": "2026-09-19", "checked_by": "validator session 2026-09-19", "notes": "Confirms PayPal's sole discretion over payment review, holds, account limitations and business reserves, the confidential and proprietary basis for those decisions, the court order and legal process provision, and that the card issuer or bank decides a chargeback or bank reversal while PayPal only relays evidence. Does not itself address the appeal stage names, which come from the Disputes specification and developer guide." } ] }, "rail_name": "PayPal (staged wallet)", "governing_authority": "PayPal (regional entities; US: PayPal, Inc.)", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "paypal:finality", "id": "finality", "rail": "paypal", "kind": "rail-fact", "facet": "finality", "name": "When does a PayPal payment become final, and can it be reversed?", "statement": "PayPal's agreements set no moment at which a received payment becomes final for the payee. The credit appears on PayPal's own books straight away, but a goods and services payment stays open to reversal through three separate processes: a claim the buyer files with PayPal, a chargeback the buyer takes to the card issuer, or a reversal through the buyer's bank. The seller carries that exposure for the full amount plus fees. Separately from reversal, PayPal may keep a received payment unavailable: a risk hold usually lasts up to 21 days, and money tied to a challenged payment can be held until the matter ends, for up to 180 days. Two layers must be kept apart: the booking between PayPal accounts, which is immediate, and the payee's right to keep the money, which is never fixed by a date in PayPal's rules.", "details": [ { "label": "No finality rule", "value": "The US agreement contains no clause making a payment irrevocable for the payee. It instead makes the payee answerable to PayPal for the whole payment plus any fees whenever that payment is later refunded, invalidated or reversed, whatever the reason.", "citation": "PayPal User Agreement (US), last updated 2026-09-14, Selling and Accepting Payments, Refunds, Reversals and Chargebacks (General information; Payments that are invalidated and reversed)", "rests_on": "rule" }, { "label": "Grounds for reversal", "value": "The grounds PayPal names fall into three groups. Buyer remedies: a PayPal Purchase Protection claim or a Venmo claim that the seller loses, a card chargeback the Seller Protection program does not cover, and a bank reversal that PayPal's investigation finds fraudulent. Seller conduct: no fulfilment or no proof of shipment or delivery when asked, no timely answer to PayPal about a claim or chargeback, and activity in breach of PayPal's agreements. Payment defects: the payment was unauthorized, or PayPal sent it by mistake.", "citation": "PayPal User Agreement (US), 2026-09-14, Payments that are invalidated and reversed", "rests_on": "rule" }, { "label": "How long a buyer can claim with PayPal", "value": "Item Not Received: up to 180 days after the buyer sent the payment. Significantly Not as Described: 30 days after delivery or fulfilment, or 180 days after payment, whichever ends first. Card chargeback and bank reversal deadlines are set by those rails, not by PayPal.", "citation": "PayPal's Purchase Protection Program (US), last updated 2026-01-26, Opening Disputes: Timeframes; PayPal User Agreement (US), 2026-09-14, Payments that are invalidated and reversed", "rests_on": "rule" }, { "label": "Risk holds", "value": "PayPal may make a received payment unavailable when it judges the risk high. Such a hold usually ends within 21 days of receipt, and PayPal may release it sooner at its discretion, for example once tracking is uploaded. A payment challenged as one that should be reversed can instead be held until the matter is resolved, capped at 180 days; a court order or legal process can extend a hold beyond that.", "citation": "PayPal User Agreement (US), 2026-09-14, Restricted Activities, Holds, and Other Actions We May Take, Holds; Court Orders, Regulatory Requirements, or Other Legal Processes", "rests_on": "rule" }, { "label": "Hold when a dispute opens", "value": "Once a buyer opens a dispute, PayPal holds all funds tied to that transaction in the seller's account until the dispute is resolved or closed.", "citation": "PayPal's Purchase Protection Program (US), 2026-01-26, Online Dispute Resolution Process, Step 1", "rests_on": "rule" }, { "label": "Payments outside the protection programs", "value": "Personal payments sent through the friends and family function are excluded from both Purchase Protection and Seller Protection, so no PayPal claim for non-receipt or misdescription lies against them. They remain inside the agreement's rules on unauthorized transactions and errors, and a card-funded one can still meet a chargeback [Inference: the agreement does not single out friends and family payments in its chargeback text].", "citation": "PayPal's Purchase Protection Program (US), 2026-01-26, Ineligible Items and Transactions; PayPal's Seller Protection Program (US), 2026-01-26, Ineligible Items and Transactions", "rests_on": "rule" } ], "exceptions": [ "UK and Irish accounts: the agreements describe the same exposure under Reversals, carried out by PayPal setting off what the payee owes against the account, and both say the card issuer, not PayPal, decides a chargeback (PayPal User Agreement (UK), PayPal UK Ltd, 2026-07-15, and PayPal User Agreement (Ireland), PayPal (Europe) S.à r.l. et Cie, S.C.A., 2026-01-22, Refunds and reversals of payments).", "Irish accounts funded from a bank account: the payer grants PayPal a SEPA Direct Debit mandate and keeps the right to claim a refund from their own bank for 8 weeks after the debit, so a bank-funded payment stays exposed for at least that long (PayPal User Agreement (Ireland), 2026-01-22, Linking and Unlinking a Funding Source).", "Where the Seller Protection program applies (US sellers; Unauthorized Transaction and Item Not Received claims, and chargebacks for unauthorized card use or bank reversals), the seller may keep the full amount even though the buyer is paid back (PayPal's Seller Protection Program (US), 2026-01-26, What's Eligible).", "Agreements for regions other than the US, the UK and Ireland were not read." ], "applies_to": "Payments received into PayPal accounts under the US User Agreement; UK and Irish accounts as noted in exceptions", "caveat": "Do not read an available PayPal balance as a final payment: availability ends a hold, not the exposure to reversal. And PayPal's lifecycle stage named CHARGEBACK is PayPal's own claim stage, not a card chargeback.", "related": [ "paypal:return", "paypal:liability", "paypal:settlement", "paypal:recall", "paypal:decision-points", "us-ach:finality", "visa:finality" ], "basis": { "sources": "Read 2026-09-19 with a plain fetch: PayPal User Agreement (US), PayPal, Inc., last updated 2026-09-14 (https://www.paypal.com/us/legalhub/paypal/useragreement-full), sections Refunds, Reversals and Chargebacks, Holds, and Court Orders, Regulatory Requirements, or Other Legal Processes; PayPal's Purchase Protection Program (US) and PayPal's Seller Protection Program (US), both last updated 2026-01-26; PayPal User Agreement (UK), PayPal UK Ltd, 2026-07-15, and PayPal User Agreement (Ireland), 2026-01-22, sections Refunds and reversals of payments and Linking and Unlinking a Funding Source. The agreements have no section numbers and are cited by heading. Nothing is quoted. High because the absence of a finality rule and the reversal and hold rules follow directly from PayPal's own agreements.", "confidence": "high" }, "currency": { "effective_since": "2026-09-14", "effective_note": "Dated from the US User Agreement edition read (last updated 2026-09-14); the change that took effect that day concerned disputes between users and PayPal, not payment reversals. The US protection program pages were last updated 2026-01-26. The US Policy Updates page (last updated 2026-08-06) listed no notice with a later effective date on 2026-09-19.", "source_edition": "PayPal User Agreement (US) 2026-09-14; Purchase Protection and Seller Protection (US) 2026-01-26; UK User Agreement 2026-07-15; Ireland User Agreement 2026-01-22", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.paypal.com/us/legalhub/paypal/useragreement-full", "source_class": "authoritative_primary", "source_title": "PayPal User Agreement (US), last updated 2026-09-14", "checked_on": "2026-09-19", "checked_by": "validator session 2026-09-19", "notes": "Confirms the absence of a payment finality clause, the full list of grounds on which a payment can be invalidated and reversed, the seller's liability for the full amount plus fees, the 21 day risk hold with a 180 day cap for a challenged payment, and the exclusion of friends and family payments from both protection programs." } ] }, "rail_name": "PayPal (staged wallet)", "governing_authority": "PayPal (regional entities; US: PayPal, Inc.)", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "paypal:hours", "id": "hours", "rail": "paypal", "kind": "rail-fact", "facet": "hours", "name": "When does PayPal process payments, and which days count?", "statement": "The US agreement sets no operating hours or cut-off for PayPal-to-PayPal payments; the service runs online and the agreement promises no time for completing a payment. What the agreement does fix is the Business Day: Monday to Friday, less ten named US holidays, and most consumer deadlines are counted in Business Days. Timing that depends on the funding rail, such as e-check clearing, is stated in Business Days too. The UK and Irish agreements add an execution rule with a 4 pm cut-off.", "details": [ { "label": "No service window", "value": "The US agreement states no hours during which payments are accepted or completed and no cut-off time for PayPal-to-PayPal payments. It says PayPal makes reasonable efforts to process bank and card debits and credits on time but gives no warranty on how long processing takes.", "citation": "PayPal User Agreement (US), last updated 2026-09-14, read in full; Disclaimer of Warranty and Release, No warranty", "rests_on": "rule" }, { "label": "Business Day", "value": "Monday through Friday, excluding days PayPal's US offices treat as holidays. Ten holidays are named. Four fall on fixed dates: 1 January, 4 July, 11 November and 25 December; one on a Saturday moves to the Friday before, one on a Sunday to the Monday after. Six float: the third Monday of January and of February, the last Monday of May, the first Monday of September, the second Monday of October, and the fourth Thursday of November.", "citation": "PayPal User Agreement (US), 2026-09-14, Miscellaneous, Business Days", "rests_on": "rule" }, { "label": "Deadlines counted in Business Days", "value": "A personal account holder must ask to stop a recurring automatic payment at least 3 Business Days before it is due. For a reported error, PayPal decides within 10 Business Days or gives a provisional credit within that time if it needs longer, and reports results within 3 Business Days of finishing. Mail from PayPal counts as received 3 Business Days after sending; electronic notices count as received 24 hours after posting or emailing.", "citation": "PayPal User Agreement (US), 2026-09-14, Automatic payments; In case of Errors or questions about your electronic transfers; Communications Between You and Us", "rests_on": "rule" }, { "label": "E-check", "value": "An e-check payment reaches the recipient only after the bank transfer is processed, which usually takes 4 to 7 Business Days and longer when the bank account is outside the US.", "citation": "PayPal User Agreement (US), 2026-09-14, E-check", "rests_on": "rule" }, { "label": "Seller completion", "value": "Some sellers take up to 30 days to complete a purchase the buyer has authorised; the payment shows as a pending order and the authorisation lasts until completion but no more than 30 days.", "citation": "PayPal User Agreement (US), 2026-09-14, How to purchase something or make a donation", "rests_on": "rule" } ], "exceptions": [ "UK and Irish accounts: a payment leaves the payer's account within the Business Day after PayPal receives a complete instruction, or within two Business Days if the instruction arrives on a day that is not a Business Day or after 4 pm (Irish local time in the Irish agreement); a later execution date can be requested (PayPal User Agreement (UK), PayPal UK Ltd, 2026-07-15, and (Ireland), 2026-01-22, How long will my payment take?).", "The UK and Irish agreements use Business Days for their own deadlines but their definitions of Business Day were not compared with the US one.", "Card and bank funding legs follow the operating days of their own rails.", "Agreements for regions other than the US, the UK and Ireland were not read." ], "applies_to": "PayPal accounts under the US User Agreement; UK and Irish accounts as noted in exceptions", "caveat": "No clock time for PayPal-to-PayPal payments appears in the US agreement; do not infer a 24/7 settlement guarantee from the absence of hours.", "related": [ "paypal:settlement", "paypal:consumer-law", "paypal:recall" ], "basis": { "sources": "Read 2026-09-19 with a plain fetch: PayPal User Agreement (US), PayPal, Inc., last updated 2026-09-14 (https://www.paypal.com/us/legalhub/paypal/useragreement-full), read in full, sections Business Days, Automatic payments, E-check, In case of Errors or questions about your electronic transfers, Communications Between You and Us, How to purchase something or make a donation, No warranty; PayPal User Agreement (UK), PayPal UK Ltd, 2026-07-15, and PayPal User Agreement (Ireland), 2026-01-22, section How long will my payment take?. Nothing is quoted. Medium because the central point, that no service hours exist, is an absence read across a long agreement.", "confidence": "medium" }, "currency": { "effective_since": "2026-09-14", "effective_note": "Dated from the US User Agreement edition read (last updated 2026-09-14). The UK agreement read was last updated 2026-07-15 and the Ireland agreement 2026-01-22. The US Policy Updates page (last updated 2026-08-06) listed no notice with a later effective date on 2026-09-19.", "source_edition": "PayPal User Agreement (US) 2026-09-14; UK User Agreement 2026-07-15; Ireland User Agreement 2026-01-22", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.paypal.com/us/legalhub/paypal/useragreement-full", "source_class": "authoritative_primary", "source_title": "PayPal User Agreement (US), last updated 2026-09-14", "checked_on": "2026-09-19", "checked_by": "validator session 2026-09-19", "notes": "Confirms the Business Day definition and its ten named holidays with the weekend shift rule, the absence of a stated service window or cut off time for PayPal to PayPal payments, the 3 Business Day automatic payment stop notice, the e-check clearing time of four to seven Business Days, and the 30 day cap on seller order completion." } ] }, "rail_name": "PayPal (staged wallet)", "governing_authority": "PayPal (regional entities; US: PayPal, Inc.)", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "paypal:liability", "id": "liability", "rail": "paypal", "kind": "rail-fact", "facet": "liability", "name": "Who bears the loss when a PayPal payment is reversed?", "statement": "By default the seller does. Whatever path reverses a payment (a PayPal claim, a card chargeback or a bank reversal), the seller owes PayPal the full amount plus fees, and PayPal may take it from the balance, from linked payment methods, or by collection. The Seller Protection program shifts the loss to PayPal in a narrow set of cases: US sellers, claims that the buyer did not authorise the payment or did not receive the item, and chargebacks or bank reversals for unauthorised use, each only when the seller meets shipping and evidence conditions. Misdescription claims are never covered. On top of the reversed amount, sellers pay a dispute fee whose rate rises for sellers with a high share of disputes, or a chargeback fee on card payments that bypass PayPal accounts. On the buyer side, PayPal covers the full amount of unauthorised activity in a PayPal account when the user cooperates and reports in time.", "details": [ { "label": "Seller owes the reversed amount", "value": "A seller whose payment is refunded, invalidated or reversed owes PayPal the full amount plus fees, converted at PayPal's rate where needed. PayPal first uses the balance, then linked payment methods; any remainder is a negative balance the seller must fund at once, failing which PayPal may pursue collection, set it off, or limit the account.", "citation": "PayPal User Agreement (US), last updated 2026-09-14, Refunds, Reversals and Chargebacks, General information; Payments that are invalidated and reversed; Amounts owed to PayPal", "rests_on": "rule" }, { "label": "What Seller Protection covers", "value": "Three kinds of loss: a buyer's Unauthorized Transaction claim where the payment took place in an environment PayPal hosts; a buyer's Item Not Received claim filed with PayPal; and a successful card chargeback for unauthorised use or a bank reversal of a bank-funded payment. There is no cap on the number of payments covered. Significantly Not as Described claims, whether filed with PayPal or the card issuer, and Item Not Received claims taken to the card issuer are excluded.", "citation": "PayPal's Seller Protection Program (US), last updated 2026-01-26, What's Eligible; Ineligible Items and Transactions", "rests_on": "rule" }, { "label": "Conditions a seller must meet", "value": "The seller's primary address is in the US; the item is a shippable physical good (intangible goods and in-store QR code payments have their own conditions); it went to the address shown on the transaction and was not redirected; the seller answers PayPal's requests on time and gives valid proof of shipment, or proof of delivery for Item Not Received. For an Unauthorized Transaction claim the payment must be marked eligible or partially eligible and the item shipped no later than two days after PayPal's notice. Integrated checkout sellers must also run the current PayPal Checkout version and pass session data.", "citation": "PayPal's Seller Protection Program (US), 2026-01-26, Basic Requirements; Item Not Received Additional Requirement; Intangible Goods Additional Requirements; Establishing Proof of Shipment or Proof of Delivery", "rests_on": "rule" }, { "label": "Payments never covered", "value": "Friends and family payments, payouts, bill payment services and payments received through a business account's assigned account number; card payments from buyers paying without a PayPal account (guest checkout and standard card payments) where the seller's account is registered in one of 30 listed countries; and categories such as vehicles, real estate, cash equivalents, gambling and items sent after PayPal said not to.", "citation": "PayPal's Seller Protection Program (US), 2026-01-26, Ineligible Items and Transactions", "rests_on": "rule" }, { "label": "Dispute fee and the dispute ratio", "value": "On payments made through a buyer's PayPal account or PayPal Guest Checkout, the seller pays a dispute fee once the case is decided, whichever of the three paths the buyer used. The High Volume rate applies when the seller's dispute ratio for the previous three calendar months is 1.5 percent or more and the seller had more than 100 sales in those months; otherwise the Standard rate applies. The ratio counts Item Not Received and Significantly Not as Described cases from all three paths and leaves out unauthorised claims. Unescalated inquiries, cases settled directly with the buyer, unauthorised claims filed with PayPal, and cases the seller wins are among those carrying no Standard fee. Fee amounts sit on fee pages that were not read.", "citation": "PayPal User Agreement (US), 2026-09-14, Dispute fees", "rests_on": "rule" }, { "label": "Chargeback fee", "value": "For card payments that do not go through a buyer's PayPal account or Guest Checkout, PayPal charges the seller a chargeback fee for handling any chargeback, whether or not the buyer wins it.", "citation": "PayPal User Agreement (US), 2026-09-14, Chargeback fees", "rests_on": "rule" }, { "label": "Buyer's unauthorised activity", "value": "PayPal covers a user for the full amount of unauthorised activity in their PayPal account if the user cooperates and follows the reporting steps. A user who reports more than 60 days after the statement showing the transfer may lose later losses PayPal could have prevented with a timely report. Letting someone else use one's login does not count as unauthorised.", "citation": "PayPal User Agreement (US), 2026-09-14, Liability for Unauthorized Transactions and Other Errors (Protection from Unauthorized Transactions; What is not considered an Unauthorized Transaction; Reporting an Unauthorized Transaction)", "rests_on": "rule" }, { "label": "Clawback after suspension", "value": "If PayPal suspends a seller's protection eligibility for restricted activity, it may recover amounts the seller kept under Seller Protection in the 30 days before the suspension, and may charge High Volume dispute fees regardless of the ratio.", "citation": "PayPal User Agreement (US), 2026-09-14, Actions We May Take if You Engage in Any Restricted Activities", "rests_on": "rule" } ], "exceptions": [ "UK and Irish accounts: a reversal is carried out by PayPal setting off what the payee owes, which can include PayPal's own liability to the payer and the payer's funding provider. The UK dispute ratio is stated as the transaction amount of Item Not Received and Significantly Not as Described claims against total sales for the previous three months, with the same 1.5 percent and 100-sale thresholds (PayPal User Agreement (UK), PayPal UK Ltd, 2026-07-15, Reversals; Dispute fees; PayPal User Agreement (Ireland), 2026-01-22, Reversals).", "UK and Irish accounts: an unauthorised transaction must be reported within 13 months of the payment, and PayPal owes nothing where the user was grossly negligent or acted intentionally in keeping the account unsafe (PayPal User Agreement (UK), 2026-07-15, and (Ireland), 2026-01-22, Resolving Problems).", "The UK and Irish Seller Protection pages were not read; only the one-paragraph summaries in their agreements were.", "Card network monitoring programs and dispute ratios belong to the card rails and are not stated here.", "Agreements for regions other than the US, the UK and Ireland were not read." ], "applies_to": "Sellers and buyers with PayPal accounts under the US User Agreement; UK and Irish accounts as noted in exceptions", "caveat": "Seller Protection and Purchase Protection are separate: a buyer can win a Purchase Protection claim while the seller keeps the money under Seller Protection, in which case PayPal bears the loss. Fee amounts are not asserted.", "related": [ "paypal:return", "paypal:finality", "paypal:refund", "paypal:decision-points", "paypal:consumer-law", "paypal-dispute:UNAUTHORISED", "paypal-dispute:MERCHANDISE_OR_SERVICE_NOT_RECEIVED", "paypal-dispute:MERCHANDISE_OR_SERVICE_NOT_AS_DESCRIBED" ], "basis": { "sources": "Read 2026-09-19 with a plain fetch: PayPal User Agreement (US), PayPal, Inc., last updated 2026-09-14 (https://www.paypal.com/us/legalhub/paypal/useragreement-full), sections Refunds, Reversals and Chargebacks, Dispute fees, Chargeback fees, Amounts owed to PayPal, Actions We May Take if You Engage in Any Restricted Activities, Liability for Unauthorized Transactions and Other Errors; PayPal's Seller Protection Program (US), last updated 2026-01-26 (https://www.paypal.com/us/legalhub/paypal/seller-protection), in full; PayPal User Agreement (UK), PayPal UK Ltd, 2026-07-15, and PayPal User Agreement (Ireland), 2026-01-22, sections Reversals, Dispute fees, Resolving Problems. Nothing is quoted. High because each rule is stated in PayPal's own agreements; no fee amount is asserted.", "confidence": "high" }, "currency": { "effective_since": "2026-09-14", "effective_note": "Dated from the US User Agreement edition read (last updated 2026-09-14). The Seller Protection page read was last updated 2026-01-26, the UK agreement 2026-07-15 and the Ireland agreement 2026-01-22. The US Policy Updates page (last updated 2026-08-06) listed no notice with a later effective date on 2026-09-19; its 2026-09-01 fee notice concerned Bill Pay for business accounts, not dispute fees.", "source_edition": "PayPal User Agreement (US) 2026-09-14; Seller Protection (US) 2026-01-26; UK User Agreement 2026-07-15; Ireland User Agreement 2026-01-22", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.paypal.com/us/legalhub/paypal/useragreement-full", "source_class": "authoritative_primary", "source_title": "PayPal User Agreement (US), last updated 2026-09-14", "checked_on": "2026-09-19", "checked_by": "validator session 2026-09-19", "notes": "Confirms that a seller owes PayPal the full reversed amount plus fees, the dispute fee ratio (1.5 percent and more than 100 sales over the previous three months sets the High Volume rate), the cases carrying no Standard or High Volume fee, the chargeback fee on transactions outside a buyer's PayPal account or Guest Checkout, the buyer's cover for unauthorised activity with its 60 day reporting rule, and the clawback of Seller Protection amounts kept in the 30 days before a suspension." } ] }, "rail_name": "PayPal (staged wallet)", "governing_authority": "PayPal (regional entities; US: PayPal, Inc.)", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "paypal:limits", "id": "limits", "rail": "paypal", "kind": "rail-fact", "facet": "limits", "name": "What limits apply to PayPal payment amounts?", "statement": "The US agreement publishes no fixed maximum for a PayPal payment. It reserves to PayPal the power to cap what a user may send, withdraw or convert, and to narrow the payment methods offered on a transaction, and it says business-account transfers in are subject to daily, weekly and monthly caps without stating them. The dollar figures the agreement does contain are thresholds for protections, not caps on payments.", "details": [ { "label": "Sending", "value": "PayPal may, at its discretion, limit how much a user can send, including money sent for purchases. No figure is given.", "citation": "PayPal User Agreement (US), last updated 2026-09-14, Sending Money to a Friend or Family Member, Sending money", "rests_on": "rule" }, { "label": "Withdrawals", "value": "PayPal may cap withdrawals and may delay one, for example while it confirms the user authorised it or after other payments to the account were reversed. Completing two of three verification steps (a verified bank account, a linked and confirmed card, a social security number) may lift the cap.", "citation": "PayPal User Agreement (US), 2026-09-14, Restrictions on transfers or withdrawals from PayPal accounts", "rests_on": "rule" }, { "label": "Funding methods and conversions", "value": "To manage risk PayPal may restrict which payment methods a transaction can use, including for particular sellers or third-party sites, and may cap the amount or number of currency conversions.", "citation": "PayPal User Agreement (US), 2026-09-14, How to purchase something or make a donation; Holding currency other than U.S. dollars", "rests_on": "rule" }, { "label": "Business account caps not stated", "value": "Transfers into a US business account, cash added at stores, and debits made with a business account's assigned account and routing number are each subject to per-transaction or periodic caps that the agreement mentions but does not quantify; it points to the Help Center.", "citation": "PayPal User Agreement (US), 2026-09-14, Receiving Funds, Holding a Balance, or Transferring Funds, Business accounts", "rests_on": "rule" }, { "label": "Thresholds that are not payment limits", "value": "A cross-border personal Send Money payment counts as a Remittance Transfer, with its own error rights, only from 15 US dollars upward. Non-fungible tokens priced above 10,000 US dollars are outside Seller Protection altogether, and those at or below it are covered only against Unauthorized Transaction claims.", "citation": "PayPal User Agreement (US), 2026-09-14, Remittance Transfer Errors, What is a Remittance Transfer; PayPal's Seller Protection Program (US), last updated 2026-01-26, Ineligible Items and Transactions", "rests_on": "rule" } ], "exceptions": [ "UK and Irish accounts: PayPal may set sending limits at its discretion, shows them in the account, and may refuse a payment that exceeds the limit it states when the user tries to pay (PayPal User Agreement (UK), PayPal UK Ltd, 2026-07-15, and (Ireland), 2026-01-22, Sending limits; When we may refuse to make your payment).", "UK accounts: reimbursement for authorised push payment fraud on money sent out by Faster Payments or CHAPS is capped at 85,000 pounds per claim; this caps a refund, not a payment (PayPal User Agreement (UK), 2026-07-15, Authorised Push Payment (APP) Fraud).", "The card or bank funding the payment may impose its own limits, and a card issuer may charge a cash-advance fee when a credit card funds a personal payment (PayPal User Agreement (US), 2026-09-14, Fees for Sending Money to Friends and Family).", "Agreements for regions other than the US, the UK and Ireland, and the PayPal Help Center pages the agreement points to, were not read." ], "applies_to": "PayPal accounts under the US User Agreement; UK and Irish accounts as noted in exceptions", "caveat": "No published amount limit is not the same as no limit: each account carries limits PayPal sets and shows only inside the account.", "related": [ "paypal:decision-points", "paypal:consumer-law", "paypal:liability" ], "basis": { "sources": "Read 2026-09-19 with a plain fetch: PayPal User Agreement (US), PayPal, Inc., last updated 2026-09-14 (https://www.paypal.com/us/legalhub/paypal/useragreement-full), read in full, sections Sending money, Restrictions on transfers or withdrawals from PayPal accounts, How to purchase something or make a donation, Holding currency other than U.S. dollars, Business accounts, Remittance Transfer Errors, Fees for Sending Money to Friends and Family; PayPal's Seller Protection Program (US), last updated 2026-01-26; PayPal User Agreement (UK), PayPal UK Ltd, 2026-07-15, and PayPal User Agreement (Ireland), 2026-01-22, sections Sending limits and When we may refuse to make your payment, and the UK section Authorised Push Payment (APP) Fraud. Nothing is quoted. Medium because the finding is the absence of a published limit.", "confidence": "medium" }, "currency": { "effective_since": "2026-09-14", "effective_note": "Dated from the US User Agreement edition read (last updated 2026-09-14). The Seller Protection page read was last updated 2026-01-26, the UK agreement 2026-07-15 and the Ireland agreement 2026-01-22. The US Policy Updates page (last updated 2026-08-06) listed no notice with a later effective date on 2026-09-19.", "source_edition": "PayPal User Agreement (US) 2026-09-14; Seller Protection (US) 2026-01-26; UK User Agreement 2026-07-15; Ireland User Agreement 2026-01-22", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.paypal.com/us/legalhub/paypal/useragreement-full", "source_class": "authoritative_primary", "source_title": "PayPal User Agreement (US), last updated 2026-09-14", "checked_on": "2026-09-19", "checked_by": "validator session 2026-09-19", "notes": "Confirms that PayPal reserves discretion to limit sending, withdrawals and currency conversions without publishing a figure, that business account transfer caps are mentioned but not quantified, the 15 US dollar remittance transfer floor, and the 10,000 US dollar Seller Protection threshold for non-fungible tokens read on the Seller Protection page." } ] }, "rail_name": "PayPal (staged wallet)", "governing_authority": "PayPal (regional entities; US: PayPal, Inc.)", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "paypal:messages", "id": "messages", "rail": "paypal", "kind": "rail-fact", "facet": "messages", "name": "What interface carries PayPal dispute information, and what does it hold?", "statement": "PayPal does not use ISO 20022 or ISO 8583 messages toward its users. Dispute information reaches a merchant through PayPal's own Disputes REST API (paths under /v1/customer/disputes) or through the Resolution Center web pages. PayPal publishes the API as an OpenAPI file in its own GitHub repository under the Apache License 2.0; the repository holds version 1.11 and the developer site serves 1.12. Each dispute object carries one of ten reason values, a channel saying where the buyer went, a lifecycle stage, an overall status, response deadlines, and, for card cases, the issuer's own reason code.", "details": [ { "label": "Reason values", "value": "The dispute_reason field takes ten values: MERCHANDISE_OR_SERVICE_NOT_RECEIVED, MERCHANDISE_OR_SERVICE_NOT_AS_DESCRIBED, UNAUTHORISED, CREDIT_NOT_PROCESSED, DUPLICATE_TRANSACTION, INCORRECT_AMOUNT, PAYMENT_BY_OTHER_MEANS, CANCELED_RECURRING_BILLING, PROBLEM_WITH_REMITTANCE and OTHER. The served 1.12 schema has the same ten. The product details of a dispute may carry sub-reasons DAMAGED, DIFFERENT, MISSING_PARTS or OTHER, and the service details DAMAGED, DIFFERENT, INCOMPLETE or OTHER.", "citation": "PayPal Disputes OpenAPI specification, customer_disputes_v1.json, Disputes 1.11, schemas dispute_reason, sub_reasons, definitions-sub_reasons, product_details, service_details; Disputes v1 schema served at developer.paypal.com, Disputes 1.12, schema dispute_reason", "rests_on": "rule" }, { "label": "Channel", "value": "INTERNAL for a dispute the buyer filed with PayPal, EXTERNAL for one the buyer took to the card issuer or bank, ALERT for an issuer's warning that a chargeback may follow.", "citation": "Disputes 1.11, schema dispute_channel", "rests_on": "rule" }, { "label": "Lifecycle stage", "value": "INQUIRY (buyer and seller talk without PayPal deciding), CHARGEBACK (escalated to PayPal to decide; INTERNAL only; PayPal's claim stage and expressly not a card chargeback), PRE_ARBITRATION (the seller's first appeal) and ARBITRATION (the seller's second appeal).", "citation": "Disputes 1.11, schema dispute_lifecycle_stage; PayPal developer guide, Disputes lifecycle stages reference (undated, read 2026-09-19)", "rests_on": "rule" }, { "label": "Status, state and outcome", "value": "An overall status shared by both parties (OPEN, WAITING_FOR_BUYER_RESPONSE, WAITING_FOR_SELLER_RESPONSE, UNDER_REVIEW, RESOLVED, OTHER), a per-party dispute_state including APPEALABLE, and on resolution an outcome such as RESOLVED_BUYER_FAVOUR, RESOLVED_SELLER_FAVOUR or RESOLVED_WITH_PAYOUT, with an adjudication reason drawn from a long list (118 values in 1.11, 146 in 1.12).", "citation": "Disputes 1.11, schemas status, dispute_state, adjudication_reason; Disputes 1.12, schemas dispute_outcome_code, adjudication_reason", "rests_on": "rule" }, { "label": "Deadlines and card codes", "value": "Each dispute carries seller_response_due_date and buyer_response_due_date; a party that misses its date loses the dispute to the other. The external_reason_code field holds the card issuer's own chargeback reason code, in the issuer's format, and only for unbranded (card) transactions.", "citation": "Disputes 1.11, schema dispute, properties seller_response_due_date, buyer_response_due_date, external_reason_code", "rests_on": "rule" }, { "label": "Seller actions and evidence", "value": "The API lets a seller send messages, make or answer offers, accept a claim, escalate, provide evidence or supporting information, acknowledge a returned item and appeal. Evidence is typed (76 types in 1.11, 85 in 1.12); the developer guide pairs each reason except PROBLEM_WITH_REMITTANCE with the evidence it expects, most often a refund reference or proof of fulfilment.", "citation": "Disputes 1.11, paths under /v1/customer/disputes/{id} and schema evidence; Disputes 1.12, schema evidence_type; PayPal developer guide, Dispute reasons and evidence (undated, read 2026-09-19)", "rests_on": "guidance" } ], "exceptions": [ "Creating, settling and changing the status of a dispute through the API is possible only in the sandbox; in live use merchants respond to disputes buyers create (Disputes 1.11, info description; PayPal developer guide, Disputes lifecycle stages reference).", "The card network messages that carry a chargeback, and the ACH or SEPA messages that carry a bank reversal, belong to those rails; PayPal relays their outcome in its own format.", "The developer site's Terms of Service and Developer Agreement were not read; the Apache License 2.0 covers the specification files in the repository, not PayPal's agreements or guide pages." ], "applies_to": "PayPal's Disputes API for merchants and partners, all regions", "caveat": "The same reason value labels both a PayPal claim and a card chargeback or bank reversal; read dispute_channel before acting on a reason.", "related": [ "paypal:return", "paypal:participants", "paypal:decision-points", "paypal-dispute:MERCHANDISE_OR_SERVICE_NOT_RECEIVED", "paypal-dispute:MERCHANDISE_OR_SERVICE_NOT_AS_DESCRIBED", "paypal-dispute:UNAUTHORISED", "paypal-dispute:CREDIT_NOT_PROCESSED", "paypal-dispute:DUPLICATE_TRANSACTION", "paypal-dispute:INCORRECT_AMOUNT", "paypal-dispute:PAYMENT_BY_OTHER_MEANS", "paypal-dispute:CANCELED_RECURRING_BILLING", "paypal-dispute:PROBLEM_WITH_REMITTANCE", "paypal-dispute:OTHER" ], "basis": { "sources": "Read 2026-09-19: PayPal Disputes OpenAPI specification customer_disputes_v1.json, Disputes 1.11 (https://raw.githubusercontent.com/paypal/paypal-rest-api-specifications/main/openapi/customer_disputes_v1.json; repository https://github.com/paypal/paypal-rest-api-specifications, last pushed 2026-04-07, LICENSE file Apache License 2.0), schemas compared by script; Disputes v1 schema served at https://developer.paypal.com/api/customer-disputes/v1/schema.json, Disputes 1.12, compared by script; PayPal developer guide pages Disputes lifecycle stages reference and Dispute reasons and evidence (https://developer.paypal.com/disputes/disputes-lifecycle.md and /disputes/reasons-evidence.md, undated). Enum values are given as PayPal writes them; nothing else is quoted. High because every value comes from PayPal's own interface definition.", "confidence": "high" }, "currency": { "effective_since": "2026-04-07", "effective_note": "Dated from the last push to PayPal's specification repository (2026-04-07), which holds Disputes 1.11; the developer site served Disputes 1.12 on 2026-09-19 with the same ten reason values and the same channel and stage values. The date each value first appeared is unknown.", "source_edition": "Disputes 1.11 (repository); Disputes 1.12 (served); developer guide as read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://raw.githubusercontent.com/paypal/paypal-rest-api-specifications/main/openapi/customer_disputes_v1.json", "source_class": "authoritative_primary", "source_title": "PayPal Disputes OpenAPI specification, customer_disputes_v1.json, Disputes 1.11", "checked_on": "2026-09-19", "checked_by": "validator session 2026-09-19", "notes": "Confirms the ten dispute_reason values, the three dispute_channel values, the four dispute_lifecycle_stage values, the status and dispute_state enumerations, the seller_response_due_date, buyer_response_due_date and external_reason_code fields on the dispute object, and the product and service sub reason lists. Repository info.version reads 1.11, matching the record." } ] }, "rail_name": "PayPal (staged wallet)", "governing_authority": "PayPal (regional entities; US: PayPal, Inc.)", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "paypal:participants", "id": "participants", "rail": "paypal", "kind": "rail-fact", "facet": "participants", "name": "Who takes part in a PayPal payment and its disputes?", "statement": "PayPal is both rule-writer and operator: one PayPal entity per region contracts with every user of that region. Users hold personal or business accounts, and the account type sets what they may do. Around them sit parties PayPal relies on or answers to: the card issuers, card networks and banks that fund payments and decide chargebacks and bank reversals, the card network member banks that process card payments PayPal takes for sellers, the FDIC-insured Program Banks that hold some US balances, and the partners and marketplaces that bring sellers to PayPal.", "details": [ { "label": "Regional PayPal entities read", "value": "PayPal, Inc. for US accounts (a US resident individual aged 18 or over, or a business organised or operating in the US or its territories), governed by Delaware law. PayPal UK Ltd for residents of the UK, Guernsey, the Isle of Man and Jersey, authorised by the FCA as an electronic money institution. PayPal (Europe) S.à r.l. et Cie, S.C.A. for users in the European Economic Area, licensed in Luxembourg as a credit institution and supervised by the CSSF; its Irish agreement was read.", "citation": "PayPal User Agreement (US), last updated 2026-09-14, Welcome to PayPal!; Governing law; PayPal User Agreement (UK), PayPal UK Ltd, 2026-07-15, Welcome to PayPal!; Information about us; PayPal User Agreement (Ireland), 2026-01-22, Welcome to PayPal!; Information about us", "rests_on": "rule" }, { "label": "Personal and business accounts", "value": "A personal account is for personal, family or household use and may send and ask for personal transactions and buy goods and services. A business account is for commercial activity even if unincorporated, may sell and take donations, cannot receive personal transactions, and may give employees access. PayPal may close or convert an account used for the other purpose.", "citation": "PayPal User Agreement (US), 2026-09-14, Opening a PayPal Account (Personal accounts; Business accounts)", "rests_on": "rule" }, { "label": "Card network member banks", "value": "A seller whose card receipts through PayPal pass network volume thresholds, fall in network-defined categories, or come from buyers without PayPal accounts must sign a Commercial Entity Agreement with each card network member bank processing them; those agreements form part of the user agreement.", "citation": "PayPal User Agreement (US), 2026-09-14, Commercial entity status", "rests_on": "rule" }, { "label": "Banks behind US balances and account numbers", "value": "FDIC-insured Program Banks chosen by PayPal hold US dollar balances PayPal places with them as agent and custodian in stated cases. The Bancorp Bank, N.A. issues the account and routing numbers PayPal may assign to US business accounts. Synchrony Bank provides the separate PayPal Savings deposit account.", "citation": "PayPal User Agreement (US), 2026-09-14, Receiving Funds, Holding a Balance, or Transferring Funds (Personal accounts; PayPal Savings; Business accounts)", "rests_on": "rule" }, { "label": "Parties in a dispute", "value": "PayPal's developer guide names six roles: the buyer who files, the merchant who responds, PayPal as processor and, for internal cases, decider; the bank or card issuer that decides chargebacks and ACH returns; the card network that sets chargeback rules and timelines; and the partner platform that onboards merchants in connected integrations, where merchants carry the financial liability.", "citation": "PayPal developer guide, Disputes Overview, Parties involved in dispute management (undated, read 2026-09-19)", "rests_on": "guidance" }, { "label": "Marketplaces", "value": "A seller on a marketplace or third-party application offering PayPal must also follow that platform's buyer protection rules, which can affect how claims run, and PayPal may hold the seller's payments on the platform's instruction.", "citation": "PayPal User Agreement (US), 2026-09-14, Marketplace sellers; Holds related to Marketplace transactions", "rests_on": "rule" } ], "exceptions": [ "Buyers without a PayPal account can pay through PayPal Guest Checkout or standard card payments; Purchase Protection covers only payments sent from the buyer's own PayPal account, so such payments fall outside it [Inference: Guest Checkout is not named there], and for sellers registered in 30 listed countries they are expressly outside Seller Protection (PayPal's Purchase Protection Program (US), 2026-01-26, and PayPal's Seller Protection Program (US), 2026-01-26, Ineligible Items and Transactions).", "Venmo is PayPal-owned but runs under its own user agreement and Protected Purchase Program; a lost Venmo claim can still reverse a PayPal seller's payment (PayPal User Agreement (US), 2026-09-14, Payments that are invalidated and reversed).", "Braintree (Enterprise Payments) card processing is a card acquiring service outside this rail; a PayPal article notes that for those merchants Seller Protection covers only purchases made with the Pay with PayPal button (PayPal Business Resource Center article on dispute transactions, 2026-07-17, footnote 3).", "PayPal entities and agreements for regions other than the US, the UK and Ireland were not read." ], "applies_to": "PayPal accounts under the US, UK and Irish user agreements", "caveat": "PayPal is not a bank in the US and does not take deposits there; the banks named hold balances or issue account numbers but are not parties to PayPal's payment rules.", "related": [ "paypal:settlement", "paypal:decision-points", "paypal:messages", "paypal:liability" ], "basis": { "sources": "Read 2026-09-19 with a plain fetch: PayPal User Agreement (US), PayPal, Inc., last updated 2026-09-14 (https://www.paypal.com/us/legalhub/paypal/useragreement-full), sections Welcome to PayPal!, Opening a PayPal Account, Receiving Funds, Holding a Balance, or Transferring Funds, Commercial entity status, Marketplace sellers, Holds, Payments that are invalidated and reversed, Governing law; PayPal User Agreement (UK), PayPal UK Ltd, 2026-07-15, and PayPal User Agreement (Ireland), 2026-01-22, opening sections; PayPal's Purchase Protection Program and Seller Protection Program (US), 2026-01-26; PayPal developer guide, Disputes Overview (https://developer.paypal.com/disputes/overview.md, undated); PayPal Business Resource Center article on dispute transactions (https://www.paypal.com/us/brc/article/customer-disputes-claims-chargebacks-bank-reversals, dated 2026-07-17). Nothing is quoted. High because the parties are named in PayPal's own agreements; the dispute-role line is marked guidance.", "confidence": "high" }, "currency": { "effective_since": "2026-09-14", "effective_note": "Dated from the US User Agreement edition read (last updated 2026-09-14). The UK agreement read was last updated 2026-07-15 and the Ireland agreement 2026-01-22. The US Policy Updates page (last updated 2026-08-06) listed no notice with a later effective date on 2026-09-19.", "source_edition": "PayPal User Agreement (US) 2026-09-14; UK User Agreement 2026-07-15; Ireland User Agreement 2026-01-22; developer guide as read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.paypal.com/us/legalhub/paypal/useragreement-full", "source_class": "authoritative_primary", "source_title": "PayPal User Agreement (US), last updated 2026-09-14", "checked_on": "2026-09-19", "checked_by": "validator session 2026-09-19", "notes": "Confirms the three regional entities and their governing law or regulator, the personal and business account definitions, the Commercial Entity Agreement requirement with card network member banks, the Program Banks and Bancorp and Synchrony roles, and the marketplace seller obligation. The dispute role table is confirmed separately in PayPal's developer guide, which the record marks as guidance." } ] }, "rail_name": "PayPal (staged wallet)", "governing_authority": "PayPal (regional entities; US: PayPal, Inc.)", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "paypal:recall", "id": "recall", "rail": "paypal", "kind": "rail-fact", "facet": "recall", "name": "Can the sender of a PayPal payment cancel or recall it?", "statement": "No. Once a payment has reached the recipient's account, the US agreement gives the sender no step to pull it back; the UK and Irish agreements say so outright, allowing cancellation only of payments under a billing agreement. Money returns to the sender without a dispute only where the payment never completed: the recipient declines it, fails to claim it, or PayPal's own risk review cancels it. Future automatic payments can be stopped ahead of time. Anything else goes through a refund from the recipient or one of the reversal processes in the return fact.", "details": [ { "label": "No sender recall", "value": "Neither the buying part nor the sending part of the US agreement gives the payer a way to cancel or recall a payment once the recipient has it. Unlinking a payment method stops only later charges; PayPal may still re-present or charge it for payments already authorised and for errors, disputes and claims about earlier ones.", "citation": "PayPal User Agreement (US), last updated 2026-09-14, read in full; Revoking your authorization", "rests_on": "rule" }, { "label": "Declined or unclaimed personal payments", "value": "A friend or family recipient with an eligible account may decline the money; it then goes back, fees included, to the card, PayPal Credit or balance used, or to a balance when a bank-funded payment cannot go back to the bank. Money sent to someone without an eligible account is refunded if they never open one and claim it.", "citation": "PayPal User Agreement (US), 2026-09-14, Sending Money to a Friend or Family Member, Sending money", "rests_on": "rule" }, { "label": "Unclaimed and pending purchases", "value": "A purchase paid to a seller with no PayPal account is refunded if the seller does not open one within 30 days. Where a seller takes time to complete an order, the buyer's authorisation lapses after 30 days at most.", "citation": "PayPal User Agreement (US), 2026-09-14, How to purchase something or make a donation", "rests_on": "rule" }, { "label": "Payment review", "value": "When PayPal holds a payment it judges high-risk and does not clear it, PayPal cancels the payment and returns the money to the buyer unless the law requires otherwise.", "citation": "PayPal User Agreement (US), 2026-09-14, Payment review (buying and selling parts)", "rests_on": "rule" }, { "label": "Stopping future automatic payments", "value": "A personal account holder can cancel a recurring automatic payment in account settings, through the Help Center or by phone, at least 3 Business Days before the next one is due; if PayPal then fails to stop it, PayPal is liable for the loss. Cancelling does not undo money already owed to the seller. A seller must let buyers stop such a payment up to 3 Business Days before it is scheduled and must not restart it without the buyer's written authorisation.", "citation": "PayPal User Agreement (US), 2026-09-14, Automatic payments (buying part); Accepting preauthorized payments", "rests_on": "rule" }, { "label": "PayPal's own re-presentment of bank debits", "value": "The recall power runs the other way for bank funding: if the payer's bank rejects a PayPal transfer, PayPal may present it again up to two times, and topping up the PayPal balance meanwhile does not stop the re-presentment.", "citation": "PayPal User Agreement (US), 2026-09-14, Bank account transfers", "rests_on": "rule" } ], "exceptions": [ "UK and Irish accounts: a payment instruction cannot be cancelled once given, except one under a billing agreement; a payment the recipient refuses, or does not claim within 30 days, comes back to the payer's balance (PayPal User Agreement (UK), PayPal UK Ltd, 2026-07-15, and (Ireland), 2026-01-22, Cancelling your payment instruction; When your payment is not accepted by the recipient; Refunds to your account).", "UK and Irish accounts: a payment sent to the wrong recipient or for the wrong amount can be raised as an incorrect payment within 13 months; PayPal traces it and puts the account right where the error is PayPal's, but not where the payer gave the wrong details (PayPal User Agreement (UK), 2026-07-15, and (Ireland), 2026-01-22, Resolving Problems).", "UK accounts: money a user sent out of PayPal to a UK bank account by Faster Payments or CHAPS after being tricked may be reimbursed under the authorised push payment fraud rules, up to 85,000 pounds per claim, for payments from 7 October 2024 (PayPal User Agreement (UK), 2026-07-15, Authorised Push Payment (APP) Fraud).", "Agreements for regions other than the US, the UK and Ireland were not read." ], "applies_to": "Payments sent from PayPal accounts under the US User Agreement; UK and Irish accounts as noted in exceptions", "caveat": "A sender who paid the wrong person has no recall right under the US agreement; the misdirected payment category in PayPal's developer guide describes a buyer complaint, not a recall.", "related": [ "paypal:return", "paypal:refund", "paypal:finality", "paypal:consumer-law", "us-ach:R01", "us-ach:R09" ], "basis": { "sources": "Read 2026-09-19 with a plain fetch: PayPal User Agreement (US), PayPal, Inc., last updated 2026-09-14 (https://www.paypal.com/us/legalhub/paypal/useragreement-full), read in full, sections Revoking your authorization, Sending money, How to purchase something or make a donation, Payment review, Automatic payments, Accepting preauthorized payments, Bank account transfers; PayPal User Agreement (UK), PayPal UK Ltd, 2026-07-15, and PayPal User Agreement (Ireland), 2026-01-22, sections Cancelling your payment instruction, When your payment is not accepted by the recipient, Refunds to your account, Resolving Problems, and the UK section Authorised Push Payment (APP) Fraud; PayPal developer guide, Disputes Overview (undated), common buyer issues. Nothing is quoted. High because the absence of a recall right is stated outright in the UK and Irish agreements and matches the US agreement read in full.", "confidence": "high" }, "currency": { "effective_since": "2026-09-14", "effective_note": "Dated from the US User Agreement edition read (last updated 2026-09-14). The UK agreement read was last updated 2026-07-15 and the Ireland agreement 2026-01-22. The US Policy Updates page (last updated 2026-08-06) listed no notice with a later effective date on 2026-09-19.", "source_edition": "PayPal User Agreement (US) 2026-09-14; UK User Agreement 2026-07-15; Ireland User Agreement 2026-01-22", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.paypal.com/us/legalhub/paypal/useragreement-full", "source_class": "authoritative_primary", "source_title": "PayPal User Agreement (US), last updated 2026-09-14", "checked_on": "2026-09-19", "checked_by": "validator session 2026-09-19", "notes": "Confirms that the agreement gives the sender no cancellation or recall step once a payment reaches the recipient, the decline and 30 day unclaimed rules for personal and purchase payments, the payment review cancellation rule, the 3 Business Day automatic payment stop right, and PayPal's own right to re-present a rejected bank debit up to two times." } ] }, "rail_name": "PayPal (staged wallet)", "governing_authority": "PayPal (regional entities; US: PayPal, Inc.)", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "paypal:refund", "id": "refund", "rail": "paypal", "kind": "rail-fact", "facet": "refund", "name": "How does a PayPal seller refund a buyer, and where does the money go?", "statement": "A refund is a new movement the seller starts, not an undoing of the original payment. Under the US agreement the money normally goes back to the instrument the buyer paid with; bank-funded and in-store purchases have fallbacks to a balance or to money waiting to be claimed. Exchange rates, currency and fees follow fixed rules: the original rate applies only within one day of the payment, and PayPal keeps the fees the seller paid on the sale. When a seller loses a PayPal claim, the refund is compulsory and the seller also loses the fees.", "details": [ { "label": "Where the money goes", "value": "Card, PayPal Credit and balance payments are normally refunded to the same instrument. For a bank-funded purchase on a personal account, PayPal may offer the Balance Account, otherwise tries the bank, then the Balance Account, and failing both leaves the money waiting to be claimed; a business account falls back from the bank to its own balance. In-store purchases are refunded to the Balance Account or business balance, or wait to be claimed. A purchase funded with card rewards is refunded as a dollar amount, and the issuer decides whether rewards come back.", "citation": "PayPal User Agreement (US), last updated 2026-09-14, Sending Money and Buying, Refunds", "rests_on": "rule" }, { "label": "Exchange rate and currency", "value": "If PayPal converted currency on the payment, a refund within one day uses the rate applied to the original payment; a later refund uses the rate on the refund date. The refund comes in the currency paid, or failing that the primary holding currency, or failing that US dollars.", "citation": "PayPal User Agreement (US), 2026-09-14, Sending Money and Buying, Refunds", "rests_on": "rule" }, { "label": "Fees on a refund", "value": "When a seller refunds, PayPal keeps the fees charged on the sale. A seller is answerable for the full amount of any refunded payment plus fees, with conversion at PayPal's rate where needed.", "citation": "PayPal User Agreement (US), 2026-09-14, Refunds, Reversals and Chargebacks, General information", "rests_on": "rule" }, { "label": "Seller's published policy", "value": "A seller taking PayPal must publish a refunds and returns policy and customer service contact details.", "citation": "PayPal User Agreement (US), 2026-09-14, Your customer service information, refunds and returns policy, and privacy policy", "rests_on": "rule" }, { "label": "Refund forced by a lost claim", "value": "A seller that loses a PayPal or Venmo purchase protection claim gives up the full price and the original shipping, gets no refund of PayPal fees, and may not get the item back; on a counterfeit item it must refund in full. The claim counts as settled only when the refund runs through PayPal or Venmo, or when PayPal accepts evidence that the buyer agreed another resolution.", "citation": "PayPal User Agreement (US), 2026-09-14, Impact of various purchase protection processes on sellers", "rests_on": "rule" }, { "label": "Refund as dispute evidence", "value": "In PayPal's dispute interface a seller answers most reasons by pointing to a refund already issued, giving its refund identifier as PROOF_OF_REFUND evidence.", "citation": "PayPal developer guide, Dispute reasons and evidence (undated, read 2026-09-19); PayPal Disputes OpenAPI specification, Disputes 1.11, schema evidence", "rests_on": "guidance" } ], "exceptions": [ "UK and Irish accounts: a refunded or refused payment goes back to the payer's PayPal balance, from which PayPal may pass it on to the original funding source; the same one-day exchange-rate rule applies, and PayPal is not liable for a refund smaller than the payment unless the refund is an incorrect payment (PayPal User Agreement (UK), PayPal UK Ltd, 2026-07-15, and (Ireland), 2026-01-22, Refunds to your account; Risks when receiving refunds).", "UK and Irish accounts: the seller alone answers for its obligations to the payer and for exchange-rate differences on a refund, and PayPal keeps the fees on a commercial transaction refund (PayPal User Agreement (UK), 2026-07-15, and (Ireland), 2026-01-22, Refunds and reversals of payments, Refunds).", "A refund the payer's bank or card issuer forces is a reversal, not a seller refund; see the return fact. An Irish payer's 8-week SEPA Direct Debit refund is claimed from their own bank, not from the seller.", "Agreements for regions other than the US, the UK and Ireland were not read." ], "applies_to": "Refunds of purchases made with PayPal accounts under the US User Agreement; UK and Irish accounts as noted in exceptions", "caveat": "A refund does not return the seller's PayPal fees. And a seller refund made outside PayPal does not settle a PayPal claim unless PayPal accepts evidence that the buyer agreed to it.", "related": [ "paypal:return", "paypal:liability", "paypal:recall", "paypal-dispute:CREDIT_NOT_PROCESSED", "sepa-sdd-core:refund" ], "basis": { "sources": "Read 2026-09-19 with a plain fetch: PayPal User Agreement (US), PayPal, Inc., last updated 2026-09-14 (https://www.paypal.com/us/legalhub/paypal/useragreement-full), sections Refunds (buying part), Refunds, Reversals and Chargebacks, Your customer service information, refunds and returns policy, and privacy policy, Impact of various purchase protection processes on sellers; PayPal User Agreement (UK), PayPal UK Ltd, 2026-07-15, and PayPal User Agreement (Ireland), 2026-01-22, sections Refunds to your account, Risks when receiving refunds, Refunds; PayPal developer guide, Dispute reasons and evidence (https://developer.paypal.com/disputes/reasons-evidence.md, undated); PayPal Disputes OpenAPI specification customer_disputes_v1.json, Disputes 1.11. Nothing is quoted. High because each rule is stated in PayPal's agreements; the evidence line is marked guidance.", "confidence": "high" }, "currency": { "effective_since": "2026-09-14", "effective_note": "Dated from the US User Agreement edition read (last updated 2026-09-14). The UK agreement read was last updated 2026-07-15 and the Ireland agreement 2026-01-22. The US Policy Updates page (last updated 2026-08-06) listed no notice with a later effective date on 2026-09-19.", "source_edition": "PayPal User Agreement (US) 2026-09-14; UK User Agreement 2026-07-15; Ireland User Agreement 2026-01-22; Disputes 1.11", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.paypal.com/us/legalhub/paypal/useragreement-full", "source_class": "authoritative_primary", "source_title": "PayPal User Agreement (US), last updated 2026-09-14", "checked_on": "2026-09-19", "checked_by": "validator session 2026-09-19", "notes": "Confirms where a refund goes for each funding source and its fallbacks, the one day exchange rate rule and the currency fallback order, that PayPal keeps its fees on a refund, the seller's published policy duty, and the forced refund consequences of losing a Purchase Protection or Venmo claim including the counterfeit item rule." } ] }, "rail_name": "PayPal (staged wallet)", "governing_authority": "PayPal (regional entities; US: PayPal, Inc.)", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "paypal:return", "id": "return", "rail": "paypal", "kind": "rail-fact", "facet": "return", "name": "How can money come back after a PayPal payment, and who decides?", "statement": "Apart from a refund the seller chooses to give (see the refund fact), money goes back to a PayPal payer through one of three processes, and each has a different decider. A claim filed with PayPal under its buyer protection program is decided by PayPal. A chargeback filed with the card issuer that funded the payment is decided by that issuer under card network rules, with PayPal only passing evidence along. A reversal through the payer's bank is decided under the bank rail's rules. PayPal's dispute interface labels the first INTERNAL and the other two EXTERNAL, and uses the same ten reason values for all of them, so the reason alone never says which process is running. A card-funded buyer must choose between PayPal and the card issuer; the two cannot run together.", "details": [ { "label": "Claim with PayPal", "value": "Covers two problems only: the item never arrived (Item Not Received) or what arrived is materially not what was ordered (Significantly Not as Described). The buyer opens a dispute within the time allowed, may then talk with the seller, and must escalate it to a claim within 20 days of opening or PayPal closes it; the seller or PayPal may escalate too. PayPal decides at its sole discretion, and a decision stands unless an appeal succeeds on new information or a process error.", "citation": "PayPal's Purchase Protection Program (US), last updated 2026-01-26, opening paragraphs; Online Dispute Resolution Process, Steps 1, 2 and 5", "rests_on": "rule" }, { "label": "Filing windows for a PayPal claim", "value": "Item Not Received: within 180 days after paying. Significantly Not as Described: within 30 days after delivery or fulfilment, capped at 180 days after paying. Unauthorized transactions and errors follow the user agreement's own timelines instead.", "citation": "PayPal's Purchase Protection Program (US), 2026-01-26, Opening Disputes: Timeframes", "rests_on": "rule" }, { "label": "Card chargeback", "value": "Where a card funded the payment, the buyer may instead dispute it with the card issuer, whose rights can be wider than PayPal's. The issuer, not PayPal, decides whether the chargeback succeeds. In such an external dispute PayPal opens a case, tells the merchant, and forwards the merchant's refund or evidence through the card network to the issuer.", "citation": "PayPal User Agreement (US), last updated 2026-09-14, Payments that are invalidated and reversed; PayPal's Purchase Protection Program (US), 2026-01-26, Dispute with PayPal or Your Card Issuer; PayPal developer guide, Disputes Overview, External disputes (undated, read 2026-09-19)", "rests_on": "rule" }, { "label": "Bank reversal", "value": "Where a bank account funded the payment, the buyer's bank can reverse it; PayPal's developer guide calls this an ACH return for US accounts. The agreement lets PayPal reverse the seller's payment when its own investigation of such a bank reversal finds fraud.", "citation": "PayPal developer guide, Disputes Overview, Types of external disputes (undated, read 2026-09-19); PayPal User Agreement (US), 2026-09-14, Payments that are invalidated and reversed", "rests_on": "guidance" }, { "label": "One path at a time", "value": "If a buyer with an open PayPal claim also disputes the same payment with the card issuer, PayPal closes its claim. A buyer who went to the issuer first cannot later claim with PayPal. A buyer who loses with PayPal can still go to the issuer, and if PayPal's delay pushed the buyer past the issuer's deadline and cost part of the recovery, PayPal makes up the shortfall less anything already recovered.", "citation": "PayPal's Purchase Protection Program (US), 2026-01-26, Dispute with PayPal or Your Card Issuer", "rests_on": "rule" }, { "label": "Channel and stage labels", "value": "The Disputes API marks each case with a channel: INTERNAL (filed with PayPal), EXTERNAL (filed with the card issuer or bank) or ALERT (an issuer's warning before a chargeback). Its lifecycle stage named CHARGEBACK is PayPal's own claim stage for INTERNAL cases, and PayPal states it is not a card chargeback.", "citation": "PayPal Disputes OpenAPI specification, customer_disputes_v1.json, Disputes 1.11, schemas dispute_channel and dispute_lifecycle_stage", "rests_on": "rule" }, { "label": "Pre-chargeback alert", "value": "The developer guide says a merchant who receives a pre-chargeback alert can avoid the chargeback and its fees by refunding within 20 hours, without fulfilling the order.", "citation": "PayPal developer guide, Disputes Overview, Types of external disputes (undated, read 2026-09-19)", "rests_on": "guidance" } ], "exceptions": [ "UK accounts: the Buyer Protection page frames three options, a PayPal claim, a card issuer claim or other statutory rights, and says a PayPal claim that is denied or closed does not stop the buyer relying later on card issuer or statutory rights; a buyer who goes to the issuer first still cannot claim with PayPal later (PayPal's Buyer Protection Program (UK), last updated 2026-09-07).", "Irish accounts funded from a bank: the payer keeps an 8-week right to reclaim a SEPA Direct Debit from their own bank (PayPal User Agreement (Ireland), 2026-01-22, Linking and Unlinking a Funding Source).", "UK and Irish accounts: unexpected billing agreement payments, incorrect payments and unauthorised transactions are raised under the agreement's Resolving Problems section, not under Buyer Protection (PayPal User Agreement (UK), 2026-07-15, and (Ireland), 2026-01-22, Resolving Problems).", "No PayPal claim lies for friends and family payments, payments not sent from the buyer's PayPal account, payouts, bill payment services, and several excluded categories such as vehicles, real estate and cash equivalents (PayPal's Purchase Protection Program (US), 2026-01-26, Ineligible Items and Transactions).", "Agreements for regions other than the US, the UK and Ireland were not read." ], "applies_to": "Goods and services payments made from PayPal accounts under the US User Agreement; UK and Irish accounts as noted in exceptions", "caveat": "Never apply PayPal's 180-day, 30-day or 20-day figures to an EXTERNAL case: a card chargeback runs on the card network's time limits and a bank reversal on the bank rail's.", "related": [ "paypal:refund", "paypal:liability", "paypal:finality", "paypal:recall", "paypal:consumer-law", "paypal:messages", "paypal-dispute:MERCHANDISE_OR_SERVICE_NOT_RECEIVED", "paypal-dispute:MERCHANDISE_OR_SERVICE_NOT_AS_DESCRIBED", "paypal-dispute:UNAUTHORISED", "us-ach:return", "sepa-sdd-core:refund", "sepa-sdd-core:MD06", "visa:return" ], "basis": { "sources": "Read 2026-09-19 with a plain fetch: PayPal's Purchase Protection Program (US), last updated 2026-01-26 (https://www.paypal.com/us/legalhub/paypal/buyer-protection), in full; PayPal User Agreement (US), PayPal, Inc., last updated 2026-09-14, section Payments that are invalidated and reversed; PayPal Disputes OpenAPI specification customer_disputes_v1.json, Disputes 1.11 (https://raw.githubusercontent.com/paypal/paypal-rest-api-specifications/main/openapi/customer_disputes_v1.json, Apache License 2.0); PayPal developer guide, Disputes Overview (https://developer.paypal.com/disputes/overview.md, undated); PayPal's Buyer Protection Program (UK), 2026-09-07; PayPal User Agreement (UK), 2026-07-15, and (Ireland), 2026-01-22. Nothing is quoted. High because the three paths, their deciders and the choice rule follow directly from PayPal's agreements; the two guidance lines are marked.", "confidence": "high" }, "currency": { "effective_since": "2026-09-14", "effective_note": "Dated from the US User Agreement edition read (last updated 2026-09-14). The US Purchase Protection page was last updated 2026-01-26, the UK Buyer Protection page 2026-09-07. The specification is Disputes 1.11 in PayPal's repository (last pushed 2026-04-07); the developer site serves 1.12 with the same channel and stage values. The US Policy Updates page (last updated 2026-08-06) listed no notice with a later effective date on 2026-09-19.", "source_edition": "Purchase Protection (US) 2026-01-26; PayPal User Agreement (US) 2026-09-14; Disputes 1.11; UK Buyer Protection 2026-09-07; UK User Agreement 2026-07-15; Ireland User Agreement 2026-01-22", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.paypal.com/us/legalhub/paypal/buyer-protection", "source_class": "authoritative_primary", "source_title": "PayPal's Purchase Protection Program (US), last updated 2026-01-26", "checked_on": "2026-09-19", "checked_by": "validator session 2026-09-19", "notes": "Confirms the Item Not Received and Significantly Not as Described claim types and their 180 day, 30 day and 20 day windows, the escalation and appeal steps, and the rule that a buyer must choose between a PayPal claim and a card issuer dispute with PayPal covering a shortfall caused by its own delay. Bank reversal and ACH return terminology are confirmed separately in PayPal's developer guide, marked as guidance." } ] }, "rail_name": "PayPal (staged wallet)", "governing_authority": "PayPal (regional entities; US: PayPal, Inc.)", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "paypal:settlement", "id": "settlement", "rail": "paypal", "kind": "rail-fact", "facet": "settlement", "name": "How does a PayPal payment settle, and what does the payee actually hold?", "statement": "A PayPal payment has two legs. The funding leg draws money from the payer's card, bank account or balance and settles on that instrument's own rail under that rail's rules. The purchase or transfer leg moves value between two PayPal accounts on PayPal's own books [Inference: PayPal does not publish its internal settlement mechanics]. What the payee then holds depends on the region's agreement: for a US account it is an unsecured claim on PayPal, not a bank deposit, with FDIC pass-through cover only for US dollar balances PayPal places at insured Program Banks in stated cases; for a UK account it is electronic money that PayPal must safeguard; for an Irish account it is electronic money issued by a Luxembourg credit institution and outside deposit guarantee cover.", "details": [ { "label": "Two legs", "value": "Linking a payment method authorises PayPal to charge it whenever the user pays or sends money with it; the recipient's PayPal account is then credited. PayPal describes itself as a payment service provider only, not an escrow agent or trustee for funds in an account.", "citation": "PayPal User Agreement (US), last updated 2026-09-14, Authorization to Charge Your Payment Method; Other Legal Terms, PayPal is only a payment service provider", "rests_on": "rule" }, { "label": "US bank funding", "value": "A bank-funded payment is an electronic transfer PayPal initiates from the payer's bank account. If the bank rejects it, PayPal may present it again up to two more times. With e-check, the recipient is paid only after the bank transfer clears, usually 4 to 7 Business Days and longer for a bank outside the US. The operator's developer guide calls a US bank reversal an ACH return.", "citation": "PayPal User Agreement (US), 2026-09-14, Bank account transfers; E-check; PayPal developer guide, Disputes Overview, types of external disputes (undated, read 2026-09-19)", "rests_on": "rule" }, { "label": "US card funding", "value": "PayPal may route a debit card payment over an ATM debit network or over the Visa, Mastercard or Discover network; payments made with the PayPal Debit Card inside PayPal checkout are booked directly against the Balance Account instead.", "citation": "PayPal User Agreement (US), 2026-09-14, Debit Card Transactions", "rests_on": "rule" }, { "label": "What a US balance is", "value": "A US balance, and money received into a personal account but not yet moved out, is an unsecured claim against PayPal, which is not a bank and takes no deposits. PayPal pools such funds, invests them in liquid investments under state money transmitter law, keeps the earnings, and holds the pool apart from its corporate funds. The user gets no interest and no ownership interest in the investments.", "citation": "PayPal User Agreement (US), 2026-09-14, Receiving Funds, Holding a Balance, or Transferring Funds (Personal accounts; Business accounts)", "rests_on": "rule" }, { "label": "US Program Banks", "value": "Where a user has opened a PayPal Debit Card account, enrolled in Direct Deposit, or used a PayPal crypto account, PayPal places the user's US dollar balance with one or more FDIC-insured Program Banks as agent and custodian, where it may qualify for pass-through FDIC insurance up to the applicable limits. That cover protects against a Program Bank failing, not against PayPal failing.", "citation": "PayPal User Agreement (US), 2026-09-14, Receiving Funds, Holding a Balance, or Transferring Funds", "rests_on": "rule" }, { "label": "US personal accounts hold no balance", "value": "A US personal account cannot keep money as a balance. Money received waits to be moved to a linked bank account or debit card, or paid out by check, unless the user opens a separate PayPal Balance Account linked to the personal account. US business accounts can hold a balance directly.", "citation": "PayPal User Agreement (US), 2026-09-14, Receiving Funds, Holding a Balance, or Transferring Funds", "rests_on": "rule" } ], "exceptions": [ "UK accounts: money in the account is electronic money issued by PayPal UK Ltd, an FCA-authorised electronic money institution. Funds received are segregated, and any still held at the end of the next business day go to a safeguarding account at an authorised credit institution; on insolvency they form a separate pool for users. The balance earns no interest and is outside the Financial Services Compensation Scheme (PayPal User Agreement (UK), PayPal UK Ltd, 2026-07-15, Information about us; Holding and using a PayPal balance; How we protect your PayPal balance).", "Irish accounts: money in the account is electronic money issued by PayPal (Europe) S.à r.l. et Cie, S.C.A., licensed in Luxembourg as a credit institution and supervised by the CSSF. Electronic money is neither a deposit nor an investment under Luxembourg law, so deposit guarantee and investor schemes do not cover it (PayPal User Agreement (Ireland), 2026-01-22, Information about us; Holding and using a PayPal balance).", "UK and Irish accounts: while a funding source carries reversal risk, PayPal may keep the resulting electronic money in a reserve part of the account; a bank-funded payment held this way is called an eCheque payment. Irish bank funding runs as a SEPA Direct Debit under a mandate the user grants PayPal (PayPal User Agreement (UK), 2026-07-15, and (Ireland), 2026-01-22, Risk of reversals to your funding source; Linking and Unlinking a Funding Source).", "US business accounts may be given an account and routing number issued by The Bancorp Bank, N.A., through which money arrives by bank transfer, usually available the day it is applied (PayPal User Agreement (US), 2026-09-14, Business accounts).", "Agreements for regions other than the US, the UK and Ireland were not read." ], "applies_to": "PayPal accounts under the US User Agreement; UK and Irish accounts as noted in exceptions", "caveat": "Settlement here has two meanings. The funding leg settles on the card network or bank rail and follows that rail's timing and finality. The PayPal-to-PayPal leg is a book entry whose timing PayPal does not describe. Neither makes the payment final for the payee; see the finality fact.", "related": [ "paypal:finality", "paypal:participants", "paypal:hours", "us-ach:settlement", "us-ach:finality", "sepa-sdd-core:settlement", "visa:settlement" ], "basis": { "sources": "Read 2026-09-19 with a plain fetch: PayPal User Agreement (US), PayPal, Inc., last updated 2026-09-14 (https://www.paypal.com/us/legalhub/paypal/useragreement-full), sections Authorization to Charge Your Payment Method, Receiving Funds, Holding a Balance, or Transferring Funds, Bank account transfers, E-check, Debit Card Transactions, PayPal is only a payment service provider; PayPal User Agreement (UK), PayPal UK Ltd, 2026-07-15, and PayPal User Agreement (Ireland), PayPal (Europe) S.à r.l. et Cie, S.C.A., 2026-01-22, sections on the balance, safeguarding and funding sources; PayPal developer guide, Disputes Overview (https://developer.paypal.com/disputes/overview.md, undated). Nothing is quoted. Medium because PayPal's internal booking and the timing of the PayPal-to-PayPal leg are inferred; the legal nature of the balance follows directly from the agreements.", "confidence": "medium" }, "currency": { "effective_since": "2026-09-14", "effective_note": "Dated from the US User Agreement edition read (last updated 2026-09-14). The UK agreement read was last updated 2026-07-15 and the Ireland agreement 2026-01-22. The US Policy Updates page (last updated 2026-08-06) listed no notice with a later effective date on 2026-09-19. The PayPal Balance Terms and Conditions, which also govern Balance Accounts, were not read.", "source_edition": "PayPal User Agreement (US) 2026-09-14; UK User Agreement 2026-07-15; Ireland User Agreement 2026-01-22; developer guide as read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.paypal.com/us/legalhub/paypal/useragreement-full", "source_class": "authoritative_primary", "source_title": "PayPal User Agreement (US), last updated 2026-09-14", "checked_on": "2026-09-19", "checked_by": "validator session 2026-09-19", "notes": "Confirms the payment method authorisation and payment service provider disclaimer, the bank transfer re-presentment and e-check timing, the debit card network routing, the unsecured claim status of a US balance and its Program Bank pass through cover, and that a US personal account cannot hold a balance without a linked Balance Account." } ] }, "rail_name": "PayPal (staged wallet)", "governing_authority": "PayPal (regional entities; US: PayPal, Inc.)", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "ph-instapay:consumer-law", "id": "consumer-law", "rail": "ph-instapay", "kind": "rail-fact", "facet": "consumer-law", "name": "What consumer protection law applies to an InstaPay transfer, and where does a customer complain?", "statement": "InstaPay customers are protected by general Philippine financial consumer law, not by rights written into the scheme. RA 11765, the Financial Products and Services Consumer Protection Act, is implemented for BSP-supervised institutions by Circular No. 1160; RA 12010, the Anti-Financial Account Scamming Act, by Circular No. 1215; and Circular No. 1195 sets redress standards specifically for account to account transfers through an ACH. A customer complains first to their own institution, which must run a free complaints unit and a round the clock fraud reporting channel, and may escalate to the BSP's Consumer Assistance Mechanism only after that.", "details": [ { "label": "The consumer protection framework", "value": "The BSP's financial consumer protection regulations implement RA 11765 for banks and non-bank institutions it supervises, including e-money issuers, and require each to run a consumer protection risk management system and standards of conduct.", "citation": "BSP Circular No. 1160 (2022), MORB/MORNBFI secs. 1001 to 1003", "rests_on": "law" }, { "label": "Redress standards for transfers through an ACH", "value": "Circular No. 1195 binds every clearing switch operator and ACH participant offering domestic account to account transfers, covering person to person, person to merchant and person to biller payments. It fixes the credit clock, the refund clock for failed transfers, fee rules, outage notices and status notifications, and it makes the sending institution responsible for keeping its customer informed on unauthorized and mistaken transfers.", "citation": "MORPS (updated December 2025) secs. 1104.2 and 1104.3 items a to e (from BSP Circular No. 1195, 2024)", "rests_on": "law" }, { "label": "First stop: the customer's own institution", "value": "Each institution must keep one free consumer assistance unit to take complaints, inquiries and requests, publish its complaint steps and turnaround times, and tell the customer where the complaint stands and how it ended.", "citation": "BSP Circular No. 1160, MORB sec. 1003, effective recourse, Financial Consumer Protection Assistance Mechanism", "rests_on": "law" }, { "label": "A fraud channel open all hours", "value": "Institutions must offer a free, actively monitored reporting channel available around the clock, and must acknowledge every report in writing straight away through the same channel. Under the anti-scam rules, a complaint through the sending institution's fraud channel is one of the ways a hold on disputed funds starts.", "citation": "BSP Circular No. 1160, MORB sec. 1003, reporting channels; MORPS sec. 1105.6 item a (from BSP Circular No. 1215, 2025)", "rests_on": "law" }, { "label": "Second stop: the BSP", "value": "A customer dissatisfied with the institution's handling may escalate to the BSP's Consumer Assistance Mechanism, including through the BSP Online Buddy, but only after complaining to the institution first. Disputed transaction complaints escalated this way follow Circular No. 1169 (2023).", "citation": "BSP Circular No. 1160, MORB sec. 1003, effective recourse; MORPS sec. 1105.25; BSP InstaPay FAQ (March 2021), complaints", "rests_on": "law" }, { "label": "Anti-scam law and data sharing", "value": "During coordinated verification of a disputed transaction, bank secrecy and data privacy laws do not apply to the information the institutions share, though it must be kept confined to that process. Institutions must also tell customers that cooperating is part of their duty under RA 12010 and that RA 11765 still bars any waiver of their consumer rights.", "citation": "MORPS secs. 1105.18 and 1105.4 item j (from BSP Circular No. 1215)", "rests_on": "law" }, { "label": "Fee disclosure", "value": "Institutions must disclose their electronic payment fees to the BSP, which publishes them, and must make the rules on collecting and returning transfer fees clear to consumers in public materials.", "citation": "BSP Circular No. 980 (2017), item b(2); BSP Memorandum No. M-2018-013; BSP Circular No. 1238 (2026), sec. 4; MORPS sec. 1104.3.c", "rests_on": "law" } ], "exceptions": [ "Disputes about the goods or services behind a payment are outside the Circular No. 1195 redress standards (MORPS sec. 1104.2).", "The anti-scam hold does not cover a sender's own keying error; erroneous transactions fall under Circular No. 1160 (MORPS sec. 1105.2).", "RA 11765, RA 12010 and Circular No. 1169 were not read for this record; their contents are stated only as the circulars read here describe them [Unverified]." ], "applies_to": "consumers holding bank or e-money accounts at BSP-supervised institutions who send or receive InstaPay transfers", "caveat": "These protections come from law and regulation that apply to every account to account transfer in the Philippines. They would apply equally to PESONet or an on-us transfer; InstaPay adds no consumer right of its own that is public.", "related": [ "ph-instapay:liability", "ph-instapay:recall", "ph-instapay:refund", "ph-instapay:return", "ph-instapay:decision-points", "ph-pesonet:consumer-law" ], "basis": { "sources": "BSP Circular No. 1160, 2022 (https://www.bsp.gov.ph/Regulations/Issuances/2022/1160.pdf), read in the relevant parts; BSP Manual of Regulations for Payment Systems, updated December 2025 (https://www.bsp.gov.ph/Regulations/MORPS/MORPS.pdf), secs. 1104 and 1105; BSP Circular No. 1195 (2024); BSP Circular No. 980 (2017); BSP Circular No. 1238 (2026); Memorandum M-2018-013 (https://www.bsp.gov.ph/Regulations/Issuances/2018/m013.pdf); BSP InstaPay FAQ, March 2021. Read 2026-09-18.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_note": "Circular No. 1160 dates from 2022-11-28; Circular No. 1195 compliance from 2024-12-31; Circular No. 1215 is dated 2025-06-10 per MORPS. Exact effectivity dates are not established here.", "source_edition": "BSP Circulars 980, 1160, 1195, 1238; MORPS updated December 2025; BSP InstaPay FAQ March 2021", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.bsp.gov.ph/Regulations/MORPS/MORPS.pdf", "source_class": "authoritative_primary", "source_title": "BSP Manual of Regulations for Payment Systems, updated December 2025", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms Circular No. 1195's redress standards at secs 1104.2 and 1104.3, the anti-scam data sharing rule at sec 1105.18 and duty to inform customers of RA 12010 cooperation and RA 11765 rights at sec 1105.4 item j, the fraud channel trigger at sec 1105.6 item a, and that disputed transaction complaints escalated to BSP CAM/BOB follow Circular No. 1169, 2023 at sec 1105.25." }, { "source_url": "https://www.bsp.gov.ph/Regulations/Issuances/2022/1160.pdf", "source_class": "authoritative_primary", "source_title": "BSP Circular No. 1160, Series of 2022, Regulations on Financial Consumer Protection", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the consumer protection risk management system requirement, the free consumer assistance unit and complaint-handling duties, and the round-the-clock reporting channel with immediate written acknowledgement, dated 28 November 2022 as the record's currency note states." } ] }, "rail_name": "Philippines InstaPay", "governing_authority": "Bangko Sentral ng Pilipinas", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "ph-instapay:decision-points", "id": "decision-points", "rail": "ph-instapay", "kind": "rail-fact", "facet": "decision-points", "name": "Where does InstaPay stop and a person or institution decide?", "statement": "A normal InstaPay transfer runs without anyone deciding: the switch checks prefunding, the receiving institution credits on the account number, all within seconds. Judgment enters at the edges. The receiving institution decides whether to return a transfer on fraud, money laundering or account grounds. The sending institution sets its customers' limits and fees within BSP rules. When a transfer is disputed as unauthorized or a scam, the institutions decide whether to hold funds, whether to extend the hold, whether to lift it when the payee objects, and in the end which side gets the money, and the sending institution decides how much of any loss it bears. For a mistaken transfer, the decisive yes belongs to the person who received it.", "details": [ { "label": "Receiving institution: credit or return", "value": "The receiving institution may return a transfer instead of crediting it, on grounds the BSP gives as open examples including fraud, money laundering or terrorist financing concerns and restrictions on the account, and may run its own extra anti-money laundering checks before crediting.", "citation": "BSP Circular No. 1195 (2024), glossary, returned transaction; BSP Circular No. 980 (2017), specific rules item c(4) (now MORPS sec. 201.4)", "rests_on": "law" }, { "label": "Sending institution: limits and fees", "value": "Each sending institution decides its own minimum amount and daily cap under the scheme ceiling, and its own sending fee, which must be cost based, below over the counter fees and fair across customer groups; its board must adopt the fee policy.", "citation": "BSP InstaPay FAQ (March 2021), limits and charges; BSP Circular No. 1238 (2026), sec. 2, MORPS sec. 201 item b", "rests_on": "law" }, { "label": "Holding disputed funds: whether and how long", "value": "The first hold of up to 5 days can rest on the complainant's word or a fraud system flag. Extending it by up to 25 days needs reasonable grounds from the transaction and what the institutions know of the account owners; the sending institution must ask, and a receiving institution may still reach its own view on the extension.", "citation": "MORPS (updated December 2025) secs. 1105.7 and 1105.10 (from BSP Circular No. 1215, 2025)", "rests_on": "law" }, { "label": "Lifting a hold when the payee objects", "value": "A payee can ask at any time for held funds to be released, with evidence the transfer was genuine. The institution evaluates the evidence and must release at once if it is substantiated.", "citation": "MORPS sec. 1105.14", "rests_on": "law" }, { "label": "Who ends up with held funds", "value": "At the end of verification the funds go back to the payee unless a court extends the hold, the payee waives the claim in writing, or the institutions reasonably conclude from what they gathered that the money came from muling, scams, illegal sources, or a transaction with no economic purpose, or similar grounds. That conclusion is a judgment, and it is expressly without prejudice to the losing party's other legal remedies.", "citation": "MORPS sec. 1105.19", "rests_on": "law" }, { "label": "How long verification may run", "value": "Where nothing could be held, the sending institution may stretch coordinated verification from 30 to as much as 60 days for reasons it judges meritorious under its own risk policy.", "citation": "MORPS sec. 1105.15 item c(2)", "rests_on": "law" }, { "label": "Sending institution: who bears a loss", "value": "On an unauthorized transaction the institution weighs the customer's conduct, its own and its agents' conduct, and its compliance with BSP rules, and decides the allocation; no public formula governs it.", "citation": "BSP Circular No. 1160 (2022), MORB sec. 1003, liability for losses arising from unauthorized transactions", "rests_on": "law" }, { "label": "The payee: consent to return a mistaken credit", "value": "For a transfer keyed to the wrong account, the BSP asks the recipient to authorize its return; the recovery effort both institutions make depends on that consent. [Inference: no rule read here lets an institution debit the recipient for a sender's keying error without it.]", "citation": "BSP InstaPay FAQ (March 2021), erroneous fund transfers; BSP Circular No. 1160, MORB sec. 1003, erroneous transactions", "rests_on": "guidance" }, { "label": "Rule-setting: PPMI, the participants and the BSP", "value": "The participants agree the prefunding thresholds and turnaround times, PPMI writes the ACH rules, and the BSP reviews and approves them before they bind. Those choices set every timing and cap in this profile that no circular fixes.", "citation": "MORPS secs. 101.5 item c and 701.2 item d; BSP Memorandum No. M-2018-012, item 3; BSP Memorandum No. M-2022-031, item 2.a", "rests_on": "law" } ], "exceptions": [ "The switch's prefunding test is not a judgment: a payment the account cannot cover is rejected automatically (MORPS sec. 701.2 item f(1)(c)).", "The receiving institution may not decide to take longer than 2 to 3 seconds to credit after the clearing advice (MORPS sec. 1104.3.a).", "An institution may not decide to charge the recipient of a person to person transfer (BSP Circular No. 1238, sec. 2).", "A hold beyond 30 days in total is not the institutions' decision; only a court can extend it (MORPS sec. 1105.5)." ], "applies_to": "points in an InstaPay transfer or its aftermath where a rule leaves the outcome to a participant, a customer, PPMI or the BSP", "caveat": "This facet is Orca's reading of where the public rules leave judgment open, and it caps at medium confidence. Every line names the rule that leaves the decision open; none predicts how a decision will go. The private InstaPay rules may narrow some of these choices.", "related": [ "ph-instapay:finality", "ph-instapay:settlement", "ph-instapay:hours", "ph-instapay:limits", "ph-instapay:return", "ph-instapay:recall", "ph-instapay:refund", "ph-instapay:liability", "ph-instapay:consumer-law", "ph-instapay:messages", "ph-instapay:participants", "ph-pesonet:decision-points" ], "basis": { "sources": "BSP Manual of Regulations for Payment Systems, updated December 2025 (https://www.bsp.gov.ph/Regulations/MORPS/MORPS.pdf), secs. 101.5, 201.4, 701.2, 1104.3 and 1105; BSP Circulars No. 980 (2017), 1160 (2022), 1195 (2024), 1238 (2026); Memoranda M-2018-012 and M-2022-031; BSP InstaPay FAQ, March 2021. Read 2026-09-18.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_note": "Draws on rules from 2017 to 2026; the most recent are Circular No. 1215 (dated 2025-06-10 per MORPS) and Circular No. 1238 (signed 2026-06-17, effective 15 days after publication) [Unverified: effectivity dates].", "source_edition": "MORPS updated December 2025; BSP Circulars 980, 1160, 1195, 1238; BSP InstaPay FAQ March 2021", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.bsp.gov.ph/Regulations/MORPS/MORPS.pdf", "source_class": "authoritative_primary", "source_title": "BSP Manual of Regulations for Payment Systems, updated December 2025", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the PSMB rule-setting role at sec 101.5 item c, the fee-policy and AML-check discretion at sec 201.4 items b and c, the initial 5 day and extended 25 day hold assessment at secs 1105.7 and 1105.10, the payee release right at sec 1105.14, the outcome test at sec 1105.19, and the 30 to 60 day verification extension at sec 1105.15 item c(2)." }, { "source_url": "https://www.bsp.gov.ph/Regulations/Issuances/2022/1160.pdf", "source_class": "authoritative_primary", "source_title": "BSP Circular No. 1160, Series of 2022, Regulations on Financial Consumer Protection", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the open, unweighted list of factors an institution considers when allocating loss on an unauthorized transaction (customer conduct, institution and agent conduct, compliance with BSP requirements)." } ] }, "rail_name": "Philippines InstaPay", "governing_authority": "Bangko Sentral ng Pilipinas", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "ph-instapay:finality", "id": "finality", "rail": "ph-instapay", "kind": "rail-fact", "facet": "finality", "name": "When does an InstaPay transfer become final, and can it be reversed?", "statement": "Finality on InstaPay has two layers that happen at different times. The payee is credited within seconds of the clearing advice, and the BSP describes that credit as final. The banks settle with each other later, as net positions in the BSP's Peso RTGS, and a settlement there is final and irrevocable by regulation; money found not to be owed comes back only as a new obligation, never as an unwinding. What the InstaPay ACH's own rules say about finality between participants is not public. A final credit can still be held after the fact under the anti-scam rules, and a mistaken credit can be sent back if the receiver agrees, but neither is a reversal of the original payment.", "details": [ { "label": "What the BSP means by an instant payment", "value": "The BSP's settlement rules define an instant retail payment as one in which the message and the payee's access to final funds both happen in real time or close to it, as near to around the clock as possible. InstaPay is the ACH built for that stream.", "citation": "BSP Circular No. 1000 (2018-04-23), sec. 1 policy statement; restated as a definition in Circular No. 1135 (2022-01-21) and consolidated in the Manual of Regulations for Payment Systems (MORPS, updated December 2025) sec. 701", "rests_on": "law" }, { "label": "The customer layer: credit in seconds", "value": "The receiving institution must credit the payee within 2 to 3 seconds of getting the clearing advice from the clearing switch operator. The BSP's own consumer FAQ describes InstaPay credits as made almost immediately and with finality.", "citation": "MORPS sec. 1104.3.a (from BSP Circular No. 1195, 2024); BSP Memorandum No. M-2018-012, item 3; BSP InstaPay FAQ (March 2021), answer on erroneous fund transfers", "rests_on": "law" }, { "label": "The interbank layer: settlement in the Peso RTGS", "value": "Each ACH settles its clearing results through the BSP's RTGS system via its clearing switch operator. Once the RTGS has debited and credited the settlement accounts for a payment a CSO sends, the settlement is final and irrevocable and is not reversed for any reason. If the amount later proves not to have been due, the settlement stands and giving it back is a new obligation between the receiving and the sending participant.", "citation": "BSP Circular No. 980 (2017), Appendix, part D item f; MORPS sec. 1401.9, item g (Peso RTGS rules, finality of settlement)", "rests_on": "law" }, { "label": "Credit comes before settlement, and prefunding covers the gap", "value": "Because the payee is paid before net positions settle, each direct participant (or its settlement sponsor) must prefund a dedicated demand deposit account at the BSP so that it covers its net obligation at every point in a cycle. The switch refuses any payment the account cannot cover, so a payment that reaches the payee is already backed by central bank money. [Inference: this is how customer finality can come before interbank settlement without credit risk to the receiver.]", "citation": "MORPS sec. 701.2 items c and f(1) (from BSP Circulars No. 1000 and No. 1135)", "rests_on": "law" }, { "label": "The ACH's own finality rule is not public", "value": "The payment system management body must set rules that make payments clear and settle with finality, subject to BSP approval, and the rulebooks, including exception handling, are kept by that body and given to the BSP on request. PPMI does not publish the InstaPay rulebook, so the precise interbank moment of finality inside InstaPay is not stated here.", "citation": "MORPS sec. 101.5 item c; MORPS sec. 1203.4 (from BSP Circular No. 1223, 2025); BSP Memorandum No. M-2022-031, item 2.a", "rests_on": "law" }, { "label": "How money comes back without a reversal", "value": "Three routes exist and each is separate from the original payment. A transfer that was rejected, returned or timed out before it was credited goes back to the sender under a one hour clock. A transfer disputed as unauthorized or a scam can be held at the receiving institution and, after verification, debited and sent back. A transfer the sender keyed wrongly comes back only if the receiver authorizes it. See the return, recall and liability facts.", "citation": "MORPS sec. 1104.3.b; MORPS secs. 1105.5 and 1105.19 (from BSP Circular No. 1215, 2025); BSP InstaPay FAQ (March 2021), answer on erroneous fund transfers", "rests_on": "law" } ], "exceptions": [ "A payment the switch rejects for lack of prefunding never becomes final: a participant whose instant payment position reaches zero cannot send until it is positive again (MORPS sec. 701.2 item f(1)(c)).", "A timed-out transfer may or may not have succeeded; the BSP's definition leaves its outcome open, and the sender is refunded within one hour under the return rule (MORPS sec. 1104.3.b; BSP Circular No. 1195 glossary).", "Funds already credited can be held for up to 30 calendar days in total under the anti-scam rules; during the hold they count as credited but cannot be withdrawn (MORPS sec. 1105.5).", "Settlement finality in the RTGS does not decide who bears a loss between customer and bank; that is a matter for the consumer protection rules (see ph-instapay:liability)." ], "applies_to": "a peso account-to-account credit transfer through the InstaPay ACH between accounts at BSP-supervised banks and e-money issuers in the Philippines", "caveat": "Do not read the BSP's word 'finality' as 'nothing can ever come back'. It means the credit to the payee and the interbank settlement are not unwound. Money can still move back through a hold under the anti-scam rules or with the receiver's consent, as a new movement.", "related": [ "ph-instapay:settlement", "ph-instapay:return", "ph-instapay:recall", "ph-instapay:liability", "ph-pesonet:finality" ], "basis": { "sources": "BSP Manual of Regulations for Payment Systems, updated December 2025 (https://www.bsp.gov.ph/Regulations/MORPS/MORPS.pdf), secs. 101.5, 701, 1104, 1105, 1203.4, 1401.9; BSP Circular No. 980 (2017, https://www.bsp.gov.ph/Regulations/Issuances/2017/c980.pdf); Circular No. 1000 (2018, .../2018/c1000.pdf); Circular No. 1135 (2022, .../2022/1135.pdf); Circular No. 1195 (2024, .../2024/1195.pdf); Memoranda M-2018-012 and M-2022-031; BSP InstaPay FAQ, March 2021 (https://www.bsp.gov.ph/PaymentAndSettlement/FAQ_Instapay.pdf). All read 2026-09-18 by plain GET, text extracted with pypdf. The InstaPay ACH operating guidelines were not available.", "confidence": "medium" }, "currency": { "effective_since": "2018-04-23", "effective_note": "Circular No. 1000 dates from 2018-04-23 and took effect on publication; the customer credit clock dates from M-2018-012 (2018-03-21) and was restated by Circular No. 1195 in 2024. The RTGS finality text is as consolidated in MORPS, December 2025. The interbank finality point in the InstaPay rulebook is unknown.", "source_edition": "MORPS updated December 2025; BSP Circulars 980, 1000, 1135, 1195; BSP InstaPay FAQ, March 2021", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.bsp.gov.ph/Regulations/MORPS/MORPS.pdf", "source_class": "authoritative_primary", "source_title": "BSP Manual of Regulations for Payment Systems, updated December 2025", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the 2 to 3 second customer credit deadline at sec 1104.3.a, the prefunding and rejection-at-zero rule at sec 701.2 item f(1), RTGS settlement finality word for word at sec 1401.9 item g including that repayment of an amount not due is a new obligation, and that the PSMB's own finality rule is not public per sec 1203.4." }, { "source_url": "https://www.bsp.gov.ph/PaymentAndSettlement/FAQ_Instapay.pdf", "source_class": "public_primary", "source_title": "BSP InstaPay Frequently Asked Questions, March 2021", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the consumer-facing description that InstaPay credits are made almost immediately and with finality, and the erroneous-transfer guidance that recovery depends on the receiver's authorization." } ] }, "rail_name": "Philippines InstaPay", "governing_authority": "Bangko Sentral ng Pilipinas", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "ph-instapay:hours", "id": "hours", "rail": "ph-instapay", "kind": "rail-fact", "facet": "hours", "name": "When does InstaPay run, and how fast must the payee be credited?", "statement": "InstaPay is offered around the clock, every day of the year, including weekends and holidays, and the receiving institution must credit the payee within 2 to 3 seconds of the clearing advice. Those two facts are public. The ACH's own operating hours, maintenance windows, response timeouts and the times of its settlement cycles in the RTGS sit in the InstaPay operating guidelines, which PPMI does not publish, so the 24x7 statement rests on the BSP's and PPMI's public pages rather than on the rule text.", "details": [ { "label": "Service availability", "value": "The BSP's consumer FAQ describes InstaPay as available at all hours on every day of the year, and PPMI's page repeats that it runs through weekends and holidays.", "citation": "BSP InstaPay FAQ (March 2021), answers on what InstaPay is and how it compares; PPMI InstaPay page (philpayments.org.ph/instapay, page footer 2025, read 2026-09-18), key benefits", "rests_on": "guidance" }, { "label": "Credit to the payee: 2 to 3 seconds", "value": "For near real time transfers the receiving institution has 2 to 3 seconds from receiving the switch's clearing advice to credit the payee's account. This is a BSP rule, not a scheme service target.", "citation": "MORPS (updated December 2025) sec. 1104.3.a (from BSP Circular No. 1195, 2024); BSP Memorandum No. M-2018-012, item 3", "rests_on": "law" }, { "label": "The one hour clock when it fails", "value": "If the transfer is rejected, returned or times out, the sender's money must be back in their account within one hour of their instruction, whatever the hour of day.", "citation": "MORPS sec. 1104.3.b (from BSP Circular No. 1195)", "rests_on": "law" }, { "label": "Near 24x7 is the regulatory aim", "value": "The BSP's definition of an instant retail payment asks for availability as close to every hour of every day as possible, which leaves room for downtime. Scheduled and unscheduled downtime must be announced to the BSP, to participants and to customers under rules the ACH guidelines set.", "citation": "MORPS sec. 701 (definition carried from BSP Circular No. 1000 sec. 1 and Circular No. 1135); MORPS sec. 1104.3.d", "rests_on": "law" }, { "label": "What is not public", "value": "The allowable response time before a transfer counts as timed out, any maintenance window, and the times of InstaPay's settlement cycles in the Peso RTGS are set in the ACH operating guidelines. None of them is stated in any public BSP or PPMI page read here.", "citation": "BSP Circular No. 1195, glossary, definition of timed-out transaction (which defers to the ACH operating guidelines); MORPS sec. 1203.4", "rests_on": "law" }, { "label": "Clock convention", "value": "Payment messages must use one time convention, either UTC or local time with its offset; the ISO 20022 harmonisation that requires it has a two year transition. Philippine local time is UTC+8. [Inference: the offset is general knowledge, not taken from a BSP text.]", "citation": "MORPS sec. 1203.3 item a(4) and footnote (from BSP Circular No. 1223, 2025)", "rests_on": "law" } ], "exceptions": [ "A participant's own channels can be closed or limited even when the switch is up; the BSP asks institutions to offer electronic payments in all their delivery channels where applicable, and to justify in writing any channel where they do not (BSP Memorandum No. M-2018-012, item 4).", "Receive-only participants (8 of 96 at 2026-08-31) cannot originate InstaPay at any hour (BSP InstaPay participant list, as of 2026-08-31).", "InstaPay for Business, launched 2026-07-29, is reported to run on the same 24x7 basis (BusinessWorld, 2026-07-30) [Unverified: news only]." ], "applies_to": "InstaPay credit transfers between participating banks and e-money issuers in the Philippines", "caveat": "The 2 to 3 second figure is a deadline for crediting after the clearing advice arrives, not an end to end promise from the sender's tap. A slow or failed step earlier in the chain falls under the one hour refund rule instead.", "related": [ "ph-instapay:finality", "ph-instapay:settlement", "ph-instapay:return", "ph-pesonet:hours" ], "basis": { "sources": "BSP InstaPay FAQ, March 2021 (https://www.bsp.gov.ph/PaymentAndSettlement/FAQ_Instapay.pdf); PPMI InstaPay page (https://www.philpayments.org.ph/instapay), read 2026-09-18; BSP Manual of Regulations for Payment Systems, updated December 2025 (https://www.bsp.gov.ph/Regulations/MORPS/MORPS.pdf), secs. 701, 1104.3, 1203.3, 1203.4; BSP Circular No. 1195 (2024); Memorandum M-2018-012; BSP InstaPay participant list as of 2026-08-31; BusinessWorld, 2026-07-30. The InstaPay operating guidelines are not published, so this record is flagged primary_not_public.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_note": "24x7 service has been stated since the BSP FAQ of March 2021 and is current on PPMI's page read 2026-09-18. The 2 to 3 second clock dates from M-2018-012 (2018-03-21), restated in Circular No. 1195 (2024). The Circular No. 1223 time convention must be in place within two years of that circular's effectivity [Unverified: effectivity date not established].", "source_edition": "BSP InstaPay FAQ March 2021; PPMI InstaPay page as read 2026-09-18; MORPS updated December 2025", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "primary_not_public": true, "corroboration": [ { "source_url": "https://www.bsp.gov.ph/PaymentAndSettlement/FAQ_Instapay.pdf", "source_class": "public_primary", "source_title": "BSP InstaPay Frequently Asked Questions, March 2021", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms InstaPay is offered 24x7 all year round and that transfers are credited almost immediately and with finality; does not state a response timeout, maintenance window or RTGS cycle time, which the record correctly says are not public." }, { "source_url": "https://www.philpayments.org.ph/instapay", "source_class": "public_primary", "source_title": "PPMI InstaPay page, philpayments.org.ph, read 2026-09-18", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Independent second source, different organisation and host from the BSP FAQ. Confirms 24/7 availability including weekends and holidays in PPMI's own wording; does not address the 2 to 3 second credit deadline or the timeout window, which rest on MORPS sec 1104.3 instead." } ] }, "rail_name": "Philippines InstaPay", "governing_authority": "Bangko Sentral ng Pilipinas", "snapshot": "2026-09-18", "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "not_public", "label": "the operator's own text", "needs": "what the operator's own text says, which Orca has not read", "detail": "Bangko Sentral ng Pilipinas's own text is not the source for this rail fact: it is not public, or not under terms Orca can use. It rests on 2 named public sources, so a term set by agreement rather than by a published rule is not Orca's to state.", "from": "currency.primary_not_public" } ] }, { "uid": "ph-instapay:liability", "id": "liability", "rail": "ph-instapay", "kind": "rail-fact", "facet": "liability", "name": "Who bears the loss on an unauthorized, fraudulent or mistaken InstaPay transfer?", "statement": "No fixed loss split is written into any public rule. The BSP's consumer protection rules make the customer's own institution the first stop and require it to protect the customer while it investigates, to report the outcome within three banking days of finishing, and to reverse the transaction if it proves unauthorized or fraudulent. How much of a loss the institution then carries is weighed case by case against the institution's compliance with BSP rules, its own and its agents' conduct, and the customer's conduct. Under the anti-scam law an institution that fails to hold disputed funds when it should is liable for the resulting loss, including restitution. A sender's own keying error stays with the sender unless the money is recovered, since institutions may rely on the account number alone.", "details": [ { "label": "The sender's institution handles the claim", "value": "Disputes over transfers and claims of unauthorized transactions are lodged with the originating institution, which is primarily responsible for assisting the customer and giving redress, and must bring the receiving institution in at once.", "citation": "BSP Circular No. 1160 (2022), MORB/MORNBFI sec. 1003, unauthorized transactions; MORPS (updated December 2025) sec. 1104.3.e (from BSP Circular No. 1195, 2024)", "rests_on": "law" }, { "label": "Protection while the claim is open", "value": "While the investigation runs, the customer is not left out of pocket without recourse: the institution may offer a provisional credit the customer cannot yet withdraw, funds still sitting at the receiving end are to be held, measures such as blocking an account may be used, and any interest or fees on the disputed amount are paused.", "citation": "BSP Circular No. 1160, MORB sec. 1003, unauthorized transactions", "rests_on": "law" }, { "label": "The outcome and the reversal", "value": "The institution must tell the customer formally within three banking days after its investigation ends. If the transaction was unauthorized or fraudulent it must reverse or correct it, with any interest and fees, or make a provisional credit final; if nothing wrong occurred, it may take back the provisional credit after telling the customer.", "citation": "BSP Circular No. 1160, MORB sec. 1003, unauthorized transactions", "rests_on": "law" }, { "label": "How the loss is weighed", "value": "The rule gives no percentage or cap. It leaves the list of factors open and names three kinds: whether the institution breached consumer protection or other BSP requirements, what the institution and anyone acting for it (staff, agents, outsourced providers) did or failed to do, and how the customer behaved before, during and after the transaction.", "citation": "BSP Circular No. 1160, MORB sec. 1003, liability for losses arising from unauthorized transactions", "rests_on": "law" }, { "label": "Failing to hold scam proceeds costs the institution", "value": "Under the rules implementing RA 12010, an institution that should have held funds in a disputed transaction and did not is liable for the loss or damage that follows, including restitution to the account owner. An institution that holds funds too long or without following the procedure faces BSP administrative action, while one that holds in line with the rules has a safe harbor from liability.", "citation": "MORPS secs. 1105.22, 1105.23 and 1105.27 (from BSP Circular No. 1215, 2025)", "rests_on": "law" }, { "label": "The customer's side of the bargain", "value": "Institutions must remind account owners of their own part: reporting a disputed transaction at once and helping the investigation, reading statements and alerts, switching on offered safeguards such as limits and multi-factor login, keeping contact details up to date, and never sharing passwords, PINs or one-time codes. [Inference: these are among the customer actions an institution may weigh when allocating a loss.]", "citation": "MORPS sec. 1105.3 item a; BSP Circular No. 1160, MORB sec. 1003, protection of consumer assets against fraud and misuse", "rests_on": "law" }, { "label": "Mistaken account numbers", "value": "Institutions may credit on the account number alone, must tell customers so, and are not liable for relying on it. A sender who types the wrong number therefore bears the loss unless recovery succeeds.", "citation": "BSP Circular No. 980 (2017), specific rules item c(3) (now MORPS sec. 201.4); BSP Circular No. 1160, MORB sec. 1003, erroneous transactions", "rests_on": "law" }, { "label": "Between the institutions", "value": "How losses from holding, verifying and releasing disputed funds are settled among institutions is left to an industry protocol the BSP reviews; the ACH guidelines also allocate cost to the party at fault for failed transfers. Neither document is public.", "citation": "MORPS sec. 1105.4 item h; MORPS sec. 1104.3.c", "rests_on": "law" } ], "exceptions": [ "The anti-scam hold and its liability rules do not apply to erroneous transactions (MORPS sec. 1105.2).", "Where a court extends a hold, the 30 day limit and the release rules give way to the court order (MORPS secs. 1105.5 and 1105.19).", "A person who reports a transfer as disputed maliciously or in bad faith can be criminally liable (MORPS sec. 1105.24, citing RA 12010).", "The same BSP rules apply to every BSP-supervised institution and every account to account transfer, not only to InstaPay; nothing in them is specific to this ACH." ], "applies_to": "losses on InstaPay transfers that were unauthorized, fraudulent, or sent to the wrong account, as between the customer, their institution and the receiving institution", "caveat": "There is no Philippine equivalent here of a fixed consumer liability cap; the outcome depends on the institution's assessment and, if the customer disputes it, on escalation to the BSP or the courts. RA 12010 and RA 11765 were not read directly for this record.", "related": [ "ph-instapay:recall", "ph-instapay:refund", "ph-instapay:finality", "ph-instapay:consumer-law", "ph-instapay:decision-points", "ph-pesonet:liability" ], "basis": { "sources": "BSP Circular No. 1160, 2022 (https://www.bsp.gov.ph/Regulations/Issuances/2022/1160.pdf), MORB sec. 1003, read in the relevant parts; BSP Manual of Regulations for Payment Systems, updated December 2025 (https://www.bsp.gov.ph/Regulations/MORPS/MORPS.pdf), secs. 201.4, 1104.3 and 1105; BSP Circular No. 980 (2017). Read 2026-09-18. RA 12010 and RA 11765 were not read; they are cited only as the circulars cite them.", "confidence": "medium" }, "currency": { "effective_since": "2025-06-10", "effective_note": "The holding and liability rules are Circular No. 1215, dated 2025-06-10 per MORPS; the unauthorized transaction rules are Circular No. 1160 (2022). Effectivity dates of both circulars are not established here [Unverified].", "source_edition": "BSP Circular No. 1160 (2022); MORPS updated December 2025", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.bsp.gov.ph/Regulations/Issuances/2022/1160.pdf", "source_class": "authoritative_primary", "source_title": "BSP Circular No. 1160, Series of 2022, Regulations on Financial Consumer Protection", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the originating institution's primary responsibility, the provisional credit and hold protections during investigation, the three banking day notice after investigation, reversal or making the provisional credit final, the open list of liability-weighing factors, and the account-number-matching safe harbor at MORB sec 1003." }, { "source_url": "https://www.bsp.gov.ph/Regulations/MORPS/MORPS.pdf", "source_class": "authoritative_primary", "source_title": "BSP Manual of Regulations for Payment Systems, updated December 2025", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the sec 1104.3.e duty on the originating institution, the sec 1105.22 liability for failing to hold funds including restitution, the sec 1105.23 administrative action for improper holding, and the sec 1105.27 safe harbor for compliant holding." } ] }, "rail_name": "Philippines InstaPay", "governing_authority": "Bangko Sentral ng Pilipinas", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "judgement", "label": "your bank's own terms", "needs": "whose terms decide it: the bank's, the participant's or the scheme's", "detail": "There is no Philippine equivalent here of a fixed consumer liability cap; the outcome depends on the institution's assessment and, if the customer disputes it, on escalation to the BSP or the courts.", "from": "caveat" }, { "kind": "judgement", "label": "a legal question", "needs": "a legal question Orca does not answer", "detail": "There is no Philippine equivalent here of a fixed consumer liability cap; the outcome depends on the institution's assessment and, if the customer disputes it, on escalation to the BSP or the courts.", "from": "caveat" } ] }, { "uid": "ph-instapay:limits", "id": "limits", "rail": "ph-instapay", "kind": "rail-fact", "facet": "limits", "name": "What amount limits apply to InstaPay, and who sets them?", "statement": "An ordinary InstaPay transfer is capped at PHP 50,000 per transaction, and nothing at scheme level stops a customer repeating it during the day. Each sending institution may add its own minimum and its own daily ceiling. Since 2026-07-29 a separate InstaPay for Business tier, offered at first by five institutions, lets business and corporate accounts send up to PHP 500,000 per transaction, with no scheme cap on count or daily value; that figure rests on two news reports of the BSP's launch briefing, not on published rule text. Both caps are ACH rules that PPMI does not publish.", "details": [ { "label": "The ordinary cap", "value": "PHP 50,000 per transaction. The BSP says customers may send up to that amount as many times a day as they like at scheme level, and PPMI's page gives the same per transaction maximum.", "citation": "BSP InstaPay FAQ (March 2021), answer on minimum and maximum transaction limits; PPMI InstaPay page (philpayments.org.ph/instapay, read 2026-09-18), overview and key benefits", "rests_on": "guidance" }, { "label": "Your institution's own limits", "value": "The BSP tells customers to ask their bank or e-money issuer whether it sets a minimum amount or a daily aggregate limit. Those figures are commercial, set per institution, and not collected in any public list read here.", "citation": "BSP InstaPay FAQ (March 2021), answer on minimum and maximum transaction limits", "rests_on": "guidance" }, { "label": "InstaPay for Business: PHP 500,000", "value": "Launched by the BSP and PPMI on 2026-07-29 for business-to-consumer and business-to-business disbursements from business or corporate accounts, with a per transaction ceiling of PHP 500,000 and no scheme limit on the number of transfers or their daily total. Person-to-person transfers stay at PHP 50,000. Two independent reports, each in its own words, state the figure.", "citation": "GMA News, 'BSP, PPMI roll out Direct Debit PH, expand InstaPay', 2026-07-29 (gmanetwork.com); BusinessWorld, 'PHL rolls out interoperable direct debit facility and Instapay for businesses', 2026-07-30 (bworldonline.com)", "rests_on": "guidance" }, { "label": "Who offers the business tier", "value": "At launch: Philippine National Bank, Wise Pilipinas, DCPay Philippines, GoTyme Bank and RCBC, with twelve more institutions reported as intending to join. A sender whose institution does not offer it is held to the ordinary cap.", "citation": "GMA News, 2026-07-29; BusinessWorld, 2026-07-30", "rests_on": "practice" }, { "label": "Limits inside the business tier", "value": "BusinessWorld reports the BSP as saying that sending institutions may set and enforce their own limits on the business tier, and that receiving institutions check configured limits and may run checks after the fact, reporting the results to the sender's institution. [Unverified: one report only.]", "citation": "BusinessWorld, 2026-07-30, quoting the BSP", "rests_on": "guidance" }, { "label": "Liquidity can bind before the cap", "value": "A payment the sending participant's prefunded BSP account cannot cover is rejected by the switch whatever its size, so the participant's funding acts as an overall limit on what it can send in a cycle.", "citation": "MORPS (updated December 2025) sec. 701.2 item f(1)(c) (from BSP Circulars No. 1000 and No. 1135)", "rests_on": "law" }, { "label": "Where the caps are written", "value": "Neither figure appears in any BSP circular read here. They are set by the InstaPay ACH under PPMI, whose rulebooks go to the BSP on request and are not published. The BSP's return rules list an amount above the allowable limit as one reason a receiving institution may return a transfer.", "citation": "MORPS sec. 1203.4 (from BSP Circular No. 1223, 2025); BSP Circular No. 1195, glossary, definition of returned transaction", "rests_on": "law" } ], "exceptions": [ "An institution may set a lower per transaction or daily limit than the scheme cap, or a minimum amount (BSP InstaPay FAQ, March 2021).", "Receive-only participants cannot send at all (BSP InstaPay participant list, as of 2026-08-31: 8 of 96 are receive only).", "The PHP 500,000 tier is limited to business or corporate accounts at participating institutions; how eligibility is checked is not public [Unverified].", "A BSP official said in July 2025 that the BSP was studying a higher general limit; no change to the PHP 50,000 person-to-person cap had been announced by 2026-09-18 (GMA News, 2025-07-15) [Unverified: no BSP text read]." ], "applies_to": "each InstaPay credit transfer, ordinary or under the InstaPay for Business tier, sent from a Philippine bank or e-money account", "caveat": "Quote PHP 50,000 as the scheme ceiling for a person to person transfer, not as the customer's own limit: the sending institution's limit is often lower and is what the customer meets first. Do not quote PHP 500,000 unless the sender is a business at an institution that offers the business tier.", "related": [ "ph-instapay:settlement", "ph-instapay:hours", "ph-instapay:participants", "ph-pesonet:limits" ], "basis": { "sources": "BSP InstaPay FAQ, March 2021 (https://www.bsp.gov.ph/PaymentAndSettlement/FAQ_Instapay.pdf); PPMI InstaPay page (https://www.philpayments.org.ph/instapay), read 2026-09-18; GMA News, 2026-07-29 (https://www.gmanetwork.com/news/money/economy/996620/bsp-ppmi-roll-out-direct-debit-ph-expand-instapay/story/); BusinessWorld, 2026-07-30 (https://bworldonline.com/top-stories/2026/07/30/766781/phl-rolls-out-interoperable-direct-debit-facility-and-instapay-for-businesses/); GMA News, 2025-07-15 (https://www.gmanetwork.com/news/money/economy/952693/bsp-mulls-increase-in-instapay-s-p50-000-limit-per-transaction/story/); BSP Manual of Regulations for Payment Systems, updated December 2025, secs. 701.2 and 1203.4; BSP Circular No. 1195 glossary. All read 2026-09-18 by plain GET. Manila Bulletin and Manila Times returned 403 or a challenge to a plain fetch and were not used. The InstaPay rulebook is not published, so this record is flagged primary_not_public.", "confidence": "medium" }, "currency": { "effective_since": "2026-07-29", "effective_note": "The PHP 500,000 InstaPay for Business tier launched on 2026-07-29. The PHP 50,000 ordinary cap is stated in the BSP FAQ of March 2021 and is current on PPMI's page read 2026-09-18; the date it was first set is not established here.", "source_edition": "BSP InstaPay FAQ March 2021; PPMI InstaPay page as read 2026-09-18; GMA News 2026-07-29; BusinessWorld 2026-07-30", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "primary_not_public": true, "corroboration": [] }, "rail_name": "Philippines InstaPay", "governing_authority": "Bangko Sentral ng Pilipinas", "snapshot": "2026-09-18", "source_class": null, "effective_status": "draft", "effective_status_reason": null, "boundaries": [ { "kind": "not_public", "label": "the operator's own text", "needs": "what the operator's own text says, which Orca has not read", "detail": "Bangko Sentral ng Pilipinas's own text is not the source for this rail fact: it is not public, or not under terms Orca can use. It rests on 0 named public sources, so a term set by agreement rather than by a published rule is not Orca's to state.", "from": "currency.primary_not_public" } ] }, { "uid": "ph-instapay:messages", "id": "messages", "rail": "ph-instapay", "kind": "rail-fact", "facet": "messages", "name": "What message standard does InstaPay use, and what must a payment carry?", "statement": "The InstaPay message specifications are not public: they sit in the rulebooks PPMI maintains and shows to the BSP on request. What is public is the direction of travel. Circular No. 1223 (2025) requires retail payment systems, domestic and cross-border, to move to ISO 20022, with structured party data, ISO external code lists, an end to end reference, one time convention, and the right ISO message for each business function, and to retire message translators, within two years of the circular taking effect and with at least one use case done in the first year. The only InstaPay messages the BSP documents in public are the settlement legs between the switch and the Peso RTGS.", "details": [ { "label": "Where the specification lives", "value": "Developing and maintaining rulebooks, including message specifications, protocols and exception handling, is the payment system management body's job; the BSP may ask to review them, and PPMI must review them every year. Neither PPMI's site nor the BSP's publishes the InstaPay message specification.", "citation": "MORPS (updated December 2025) sec. 1203.4 (from BSP Circular No. 1223, 2025); PPMI InstaPay page and BSP NRPS regulatory framework page, both read 2026-09-18", "rests_on": "law" }, { "label": "ISO 20022 is now required", "value": "Participants in retail payment systems must use ISO 20022 and the message type that fits each business function. The BSP's footnote points to the CPMI core set, giving credit transfer, status, return and investigation messages as examples.", "citation": "MORPS sec. 1203.3 item a(5) and its footnote; MORPS secs. 1203.1 and 1203.2", "rests_on": "law" }, { "label": "What a payment message must carry", "value": "Names of both parties, with a common minimum of postal address structured where possible; account identifiers; standard identifiers for institutions in the chain, with BIC or LEI for cross-border payments and for enterprise payments above agreed thresholds; an end to end reference that stays the same from sender to beneficiary, and a UETR on cross-border payments; ISO external codes for payment processes; and remittance information carried whole, or referenced if sent separately.", "citation": "MORPS sec. 1203.3 items a(1) and a(2)", "rests_on": "law" }, { "label": "Time, characters and records", "value": "Every message must use one time convention, UTC or local time with its offset, and a character set in line with market practice. Participants must keep transaction records for at least five years and be able to retrieve payment status, and receiving institutions must show end users at least the sender's details and the reference.", "citation": "MORPS sec. 1203.3 items a(3), a(4) and b(1) and b(2)", "rests_on": "law" }, { "label": "The transition clock", "value": "Full compliance, meaning translators and adaptors retired and every in-scope use case harmonised, is due two years after Circular No. 1223 takes effect, with at least one use case in the first year. An industry project team led by PPMI, with the switch operators as technical experts, plans and reports on it, and enforcement is suspended during the transition. [Inference: some InstaPay flows run today on formats other than ISO 20022 or through translators.]", "citation": "BSP Circular No. 1223 (2025), sec. 3 (transitory provision), consolidated as MORPS sec. 1203.7", "rests_on": "law" }, { "label": "The settlement legs the BSP documents", "value": "The switch submits InstaPay's batch settlement to the Peso RTGS as an institution to institution credit transfer (pacs.009), receives a payment status report (pacs.002) and debit or credit notifications (camt.054), and, as the only switch that currently does, receives settlement account balance reports (camt.052).", "citation": "BSP Philippine Rulebook on Payments and Settlements (ISO 20022), v1.6 (2026-05-29), secs. 4.17, 4.25 and 4.26, business scenario 3", "rests_on": "law" }, { "label": "What the sender must supply", "value": "At minimum, the receiving bank or e-money issuer, the payee's account number and the amount. Payment can also be started by scanning a QR Ph code under the national QR standard.", "citation": "BSP InstaPay FAQ (March 2021), answer on how to use InstaPay; PPMI InstaPay page (read 2026-09-18), QR use cases; BSP Circular No. 1055 (2019), national QR code standard, title as listed on the BSP NRPS page", "rests_on": "guidance" } ], "exceptions": [ "Switch operators must run pre-validation checks for interoperability, and ACH participants answer for the accuracy and completeness of the data they send (MORPS sec. 1203.3, closing paragraph).", "Where the Circular No. 1223 rulebooks are later superseded by another messaging standard, they stop applying (MORPS sec. 1203.4).", "The reason codes carried on InstaPay rejections and returns are in the private rulebooks; the code lists in the BSP's ISO 20022 rulebook are RTGS codes, not InstaPay codes (BSP ISO 20022 rulebook v1.6, sec. 1 scope)." ], "applies_to": "messages exchanged between InstaPay participants and the switch, and between the switch and the BSP's Peso RTGS", "caveat": "Do not map InstaPay failures to the ISO reason codes in the BSP's RTGS rulebook. Those govern bank to bank messages in the RTGS. InstaPay's own codes are not published.", "related": [ "ph-instapay:settlement", "ph-instapay:return", "ph-instapay:hours", "ph-instapay:participants", "ph-pesonet:messages" ], "basis": { "sources": "BSP Circular No. 1223, 2025, corrected copy (https://www.bsp.gov.ph/Regulations/Issuances/2025/1223(corrected%20copy).pdf), read in full; BSP Manual of Regulations for Payment Systems, updated December 2025 (https://www.bsp.gov.ph/Regulations/MORPS/MORPS.pdf), sec. 1203; BSP Philippine Rulebook on Payments and Settlements (ISO 20022) v1.6 (https://www.bsp.gov.ph/PaymentAndSettlement/ISO20022-Rulebook.pdf); BSP InstaPay FAQ, March 2021; PPMI InstaPay page read 2026-09-18. Read 2026-09-18. The InstaPay message specification is not published, so this record is flagged primary_not_public.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_note": "Circular No. 1223 takes effect 15 days after publication; MORPS dates it 2025-11-28 while the corrected copy read shows a November 2025 signature date that could not be read cleanly. Full ISO 20022 compliance is due two years after effectivity, about late 2027 [Inference]. The current InstaPay format is unknown.", "source_edition": "BSP Circular No. 1223 corrected copy; MORPS updated December 2025; BSP ISO 20022 rulebook v1.6", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "primary_not_public": true, "corroboration": [] }, "rail_name": "Philippines InstaPay", "governing_authority": "Bangko Sentral ng Pilipinas", "snapshot": "2026-09-18", "source_class": null, "effective_status": "draft", "effective_status_reason": null, "boundaries": [ { "kind": "not_public", "label": "the operator's own text", "needs": "what the operator's own text says, which Orca has not read", "detail": "Bangko Sentral ng Pilipinas's own text is not the source for this rail fact: it is not public, or not under terms Orca can use. It rests on 0 named public sources, so a term set by agreement rather than by a published rule is not Orca's to state.", "from": "currency.primary_not_public" } ] }, { "uid": "ph-instapay:participants", "id": "participants", "rail": "ph-instapay", "kind": "rail-fact", "facet": "participants", "name": "Who takes part in InstaPay, and in what roles?", "statement": "InstaPay is an automated clearing house in the Philippine sense: a binding multilateral agreement among its participants for one payment stream, governed by PPMI as the industry payment system management body, operated by BancNet as clearing switch operator, settled in the BSP's Peso RTGS and overseen by the BSP. At 2026-08-31 it had 96 participants, 88 able to send and receive and 8 receive only, spread across universal and commercial banks, thrift banks, rural banks, digital banks and e-money issuers. Participation is direct, or indirect through a sponsor that clears and settles for the sponsored institution and answers for its compliance.", "details": [ { "label": "Participant count and mix", "value": "96 participants at 2026-08-31: e-money issuers and other non-bank institutions 28, universal and commercial banks 22, thrift banks 20, rural banks 20, digital banks 6. Of the 96, 8 can only receive, 5 of them rural banks.", "citation": "BSP, InstaPay ACH Participants, source BancNet, as of 2026-08-31 (bsp.gov.ph/PaymentAndSettlement/Instapay Participants.pdf)", "rests_on": "guidance" }, { "label": "Rule-maker: PPMI", "value": "The Philippine Payments Management, Inc. was recognised by the Monetary Board in January 2018 as the payment system management body under the NRPS framework and was later accredited under the National Payment Systems Act. Every clearing participant must follow the rules and policies the PSMB sets, and qualified direct participants are expected to be members.", "citation": "BSP Circular Letter CL-2018-005 (2018-01); BSP Circular No. 980 (2017), Appendix, parts A.1.d and B.1.d; BSP Circular Letter CL-2020-036 (title only; scanned, not read)", "rests_on": "law" }, { "label": "Operator: BancNet", "value": "BancNet, Inc. operates InstaPay and holds BSP authority as operator of a designated payment system; InstaPay itself was designated a Prominently Important Payment System in 2022. The switch operator may not take part in governing the system.", "citation": "BSP Circular Letter CL-2022-055 (2022-07); BSP Memorandum No. M-2022-031; BSP Circular No. 980, subsec. on NRPS key principles (now MORPS sec. 201.3)", "rests_on": "law" }, { "label": "Who can be a direct participant", "value": "Four things make an institution a direct clearing participant: it clears through an ACH and carries final responsibility for the obligations that clearing creates; it has a way to settle, either its own BSP settlement account with RTGS membership or a sponsor that has one; it holds customer money in bank or e-money accounts; and the BSP has licensed it to provide electronic payment services.", "citation": "BSP Circular No. 980, Annex A, definition of direct clearing participant; BSP Circular No. 1033 (2019), electronic payment and financial services approval (title as listed on the BSP NRPS page)", "rests_on": "law" }, { "label": "Sponsored participation", "value": "An institution that does not qualify as a direct participant, or has no RTGS membership, can join through a sponsor that clears and settles on its behalf. The sponsor is accountable for the sponsored institution's compliance with the PSMB and ACH rules.", "citation": "BSP InstaPay FAQ (March 2021), how InstaPay operates; BSP PESONet FAQ (2018), how a BSFI can join (the sponsorship rule stated for NRPS ACHs)", "rests_on": "guidance" }, { "label": "Only accounts at supervised institutions", "value": "A transfer is in scope only when both payer and payee hold accounts at BSP-supervised institutions licensed for electronic payment services, and only in pesos between accounts in the Philippines; sending to an account overseas or at a non-participant is not possible.", "citation": "BSP Circular No. 980, Appendix, part B.1.a(ii); BSP InstaPay FAQ (March 2021), answers on overseas and non-participating institutions", "rests_on": "law" }, { "label": "Obligations of participants in a designated system", "value": "Because InstaPay is a designated system, its participants must answer BSP surveys and information requests, open relevant records to BSP examiners, take part in operator tests, follow the governing body's rules, and keep the rules they agree to consistent with the international principles for financial market infrastructures.", "citation": "BSP Memorandum No. M-2022-031, part 1", "rests_on": "law" }, { "label": "One stream, one ACH, open access", "value": "Each payment stream may fall under only one ACH, bilateral clearing outside the NRPS structure is not allowed, and any qualified institution may join. [Inference: InstaPay Cash-in and InstaPay for Business, launched 2026-07-29, are use cases within the InstaPay ACH rather than separate ACHs.]", "citation": "BSP Circular No. 980, Appendix, parts A.1.e, C.1.b and C.1.c; BSP Memorandum No. M-2018-012, item 1; GMA News, 2026-07-29", "rests_on": "law" } ], "exceptions": [ "Receive-only participants (8 at 2026-08-31) are reachable but cannot originate (BSP InstaPay participant list, as of 2026-08-31).", "Corporate cash management arrangements are allowed alongside the ACH only without exclusivity terms that make it hard or costly for recipients to receive from other institutions (BSP Memorandum No. M-2018-012, item 1).", "A July 2026 report cites InstaPay volume data from the 'Payment Network of the Philippines Inc.'; its relation to BancNet is not established here (GMA News, 2026-07-29) [Unverified]." ], "applies_to": "institutions that send, receive, operate or govern InstaPay transfers in the Philippines", "caveat": "The participant list changes monthly and counts every institution that can receive, not only those that let customers send. Check the current BSP list before stating that a given bank or wallet offers InstaPay sending.", "related": [ "ph-instapay:settlement", "ph-instapay:messages", "ph-instapay:hours", "ph-instapay:limits", "ph-instapay:decision-points", "ph-pesonet:participants" ], "basis": { "sources": "BSP InstaPay participant list as of 2026-08-31 (https://www.bsp.gov.ph/PaymentAndSettlement/Instapay%20Participants.pdf); BSP Circular No. 980, 2017 (https://www.bsp.gov.ph/Regulations/Issuances/2017/c980.pdf), with Appendix and Annex A; Circular Letters CL-2018-005 and CL-2022-055 (https://www.bsp.gov.ph/Regulations/Issuances/2022/CL-2022-055.pdf); Memoranda M-2018-012 and M-2022-031; BSP InstaPay FAQ, March 2021; BSP PESONet FAQ, 2018; GMA News, 2026-07-29. Read 2026-09-18. CL-2020-036 is scanned and was not read.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_note": "Counts are as of 2026-08-31 and change monthly. Governance roles date from Circular No. 980 (2017) and CL-2018-005; BancNet's designation as operator from CL-2022-055 (July 2022).", "source_edition": "BSP InstaPay participant list as of 2026-08-31; BSP Circular No. 980; CL-2022-055; M-2022-031", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.bsp.gov.ph/PaymentAndSettlement/Instapay%20Participants.pdf", "source_class": "public_primary", "source_title": "BSP InstaPay ACH Participants list, source BancNet, as of 31 August 2026", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the count and category breakdown exactly: 96 total, 88 sender/receiver and 8 receiver only, 22 universal and commercial banks, 20 thrift banks, 20 rural banks, 6 digital banks, 28 e-money and other non-bank institutions." }, { "source_url": "https://www.bsp.gov.ph/Regulations/Issuances/2017/c980.pdf", "source_class": "authoritative_primary", "source_title": "BSP Circular No. 980, Series of 2017, National Retail Payment System Framework", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the Annex A definition of direct clearing participant (licensed for electronic payment services, holds customer funds, clears through an ACH bearing final responsibility, and settles through its own or a sponsor's BSP account), the sponsorship structure, and the one-ACH-per-stream rule in the Appendix." } ] }, "rail_name": "Philippines InstaPay", "governing_authority": "Bangko Sentral ng Pilipinas", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "ph-instapay:recall", "id": "recall", "rail": "ph-instapay", "kind": "rail-fact", "facet": "recall", "name": "Can a sender cancel or recall an InstaPay transfer after it is sent?", "statement": "No public rule gives an InstaPay sender a right to cancel or recall a transfer once it is credited. What exists depends on why the sender wants it back. A transfer the sender keyed to the wrong account or for the wrong amount is an erroneous transaction: the sender reports it to their own institution, both institutions must make reasonable efforts to recover it, and in practice the money comes back only if the receiver agrees. A transfer the sender did not authorize, or was tricked into, is a disputed transaction under the anti-scam law: the institutions may hold the funds for up to 30 days while they verify, and send them back if the claim holds. Neither route is a scheme recall message.", "details": [ { "label": "No cancellation once sent", "value": "The BSP describes InstaPay credits as immediate and final and tells senders to check the account details before confirming. No BSP or PPMI page read here describes a sender cancellation or recall request within the InstaPay scheme.", "citation": "BSP InstaPay FAQ (March 2021), answer on erroneous fund transfers; PPMI InstaPay page, read 2026-09-18", "rests_on": "guidance" }, { "label": "Wrong account or wrong amount", "value": "A mistake the sender made in keying the payee account number or the amount is an erroneous transaction. The sender should report it to their own institution at once with the details needed to trace it; where the payee is at another institution, the sender's institution passes it on, and both are to make reasonable efforts to recover the money under existing rules and industry conventions.", "citation": "BSP Circular No. 1160 (2022), MORB/MORNBFI sec. 1003, erroneous transactions; BSP Circular No. 1195 (2024), glossary, definition of erroneous transaction", "rests_on": "law" }, { "label": "The receiver's consent decides", "value": "The BSP's FAQ asks a person who receives money they cannot explain to contact their institution and authorize its return. [Inference: no text read here lets an institution debit a payee for a sender's keying error without that consent; the recovery effort depends on it.]", "citation": "BSP InstaPay FAQ (March 2021), answer on erroneous fund transfers", "rests_on": "guidance" }, { "label": "Account number matching is enough", "value": "Institutions may credit on the account number alone; the payee name need not match. They must tell customers this, and they are not liable for relying on the number. That is why a mistyped number reaches a stranger rather than failing.", "citation": "BSP Circular No. 980 (2017), subsec. on specific rules, item c(3) (now MORPS sec. 201.4)", "rests_on": "law" }, { "label": "Unauthorized or scam transfers: hold and verify", "value": "When the source account owner complains through the sending institution's 24/7 fraud channel, or a fraud monitoring system flags the transfer, the sending institution asks every receiving institution in the chain to hold the funds, for up to 5 calendar days at first and up to 25 more where the grounds hold, never more than 30 in all without a court order. The institutions then verify together. If verification or a written waiver by the payee supports the claim, the held amount is debited and sent back to the source institution.", "citation": "MORPS (updated December 2025) secs. 1105.5, 1105.6, 1105.7, 1105.10, 1105.11 and 1105.19 (from BSP Circular No. 1215, 2025, implementing RA 12010)", "rests_on": "law" }, { "label": "The payee can challenge a hold", "value": "A payee whose funds are held may at any time ask their institution to lift the hold by showing the transfer was legitimate, and the institution must release the funds early if the showing is substantiated.", "citation": "MORPS sec. 1105.14", "rests_on": "law" }, { "label": "The RTGS recall is not an InstaPay recall", "value": "The BSP's ISO 20022 rulebook describes cancellation and recall messages, but that rulebook governs the Peso RTGS between its participants, not InstaPay transfers between customers.", "citation": "BSP Philippine Rulebook on Payments and Settlements (ISO 20022), v1.6 (2026-05-29), secs. 1 and 2.1 (scope)", "rests_on": "law" } ], "exceptions": [ "The anti-scam hold does not apply to erroneous transactions (MORPS sec. 1105.2).", "Held funds already withdrawn or moved on cannot be held; the institutions report what remains and trace onward transfers (MORPS sec. 1105.8).", "A person who reports a transfer as disputed maliciously or in bad faith can be criminally liable under RA 12010 (MORPS sec. 1105.24).", "The InstaPay operating guidelines may contain an interbank recovery procedure for erroneous transfers; they are not public [Unverified]." ], "applies_to": "InstaPay transfers already credited to the payee, where the sender wants the money back because of a keying error, an unauthorized debit or a scam", "caveat": "Tell a sender who mistyped an account number that recovery is an effort, not a right, and depends on the receiver. Tell a scam victim to report at once through the bank's fraud channel, because the hold can only catch funds still in the receiving account.", "related": [ "ph-instapay:finality", "ph-instapay:return", "ph-instapay:liability", "ph-instapay:consumer-law", "ph-instapay:decision-points", "ph-pesonet:recall" ], "basis": { "sources": "BSP InstaPay FAQ, March 2021 (https://www.bsp.gov.ph/PaymentAndSettlement/FAQ_Instapay.pdf); BSP Circular No. 1160, 2022 (https://www.bsp.gov.ph/Regulations/Issuances/2022/1160.pdf), MORB sec. 1003; BSP Circular No. 1195 (2024) glossary; BSP Circular No. 980 (2017); BSP Manual of Regulations for Payment Systems, updated December 2025 (https://www.bsp.gov.ph/Regulations/MORPS/MORPS.pdf), secs. 201.4 and 1105; BSP ISO 20022 rulebook v1.6 scope. Read 2026-09-18. RA 12010 itself was not read.", "confidence": "medium" }, "currency": { "effective_since": "2025-06-10", "effective_note": "The hold and verification rules are Circular No. 1215, dated 2025-06-10 per MORPS; its industry protocol had one year from effectivity to become fully operational. The erroneous transaction route is Circular No. 1160 (2022). The effectivity date of Circular No. 1215 is not established here [Unverified].", "source_edition": "MORPS updated December 2025; BSP Circulars 980, 1160, 1195, 1215; BSP InstaPay FAQ March 2021", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.bsp.gov.ph/Regulations/MORPS/MORPS.pdf", "source_class": "authoritative_primary", "source_title": "BSP Manual of Regulations for Payment Systems, updated December 2025", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the 5 plus 25 day hold structure and 30 day cap at secs 1105.5, 1105.7 and 1105.10, the payee's right to challenge a hold at sec 1105.14, and that the ISO 20022 rulebook's cancellation and recall messages govern the RTGS, not InstaPay, per the rulebook's own scope." }, { "source_url": "https://www.bsp.gov.ph/Regulations/Issuances/2022/1160.pdf", "source_class": "authoritative_primary", "source_title": "BSP Circular No. 1160, Series of 2022, Regulations on Financial Consumer Protection", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms erroneous transaction handling: the sender reports to their own institution, the OFI informs the RFI where they differ, and both make reasonable efforts to recover the funds." } ] }, "rail_name": "Philippines InstaPay", "governing_authority": "Bangko Sentral ng Pilipinas", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "ph-instapay:refund", "id": "refund", "rail": "ph-instapay", "kind": "rail-fact", "facet": "refund", "name": "Is there a refund right on InstaPay, and who pays the fees?", "statement": "InstaPay is a push payment with no refund right of the kind a card or direct debit gives: once a transfer the sender authorized is credited, nothing in the public rules lets the sender claim it back because they changed their mind or a purchase went wrong, and the BSP's redress rules expressly leave disputes about the goods or services outside their scope. What the rules do fix is money and fees on failure: an uncredited transfer comes back within the hour, a sender pays no fee for a transfer that failed or was lost to an outage, and the recipient of a person to person transfer receives the full amount with nothing deducted.", "details": [ { "label": "No refund for the underlying purchase", "value": "The BSP's redress standards for account to account transfers cover the transfer itself and state that they do not cover disputes over the delivery of the products or services the payment was for. A buyer's remedy against a seller lies outside InstaPay.", "citation": "MORPS (updated December 2025) sec. 1104.2 (from BSP Circular No. 1195, 2024)", "rests_on": "law" }, { "label": "Money back when the transfer fails", "value": "A rejected, returned or timed-out InstaPay transfer, a double debit, or a failure from the sending institution's own control lapse must be restored to the sender within one hour of the instruction. See ph-instapay:return.", "citation": "MORPS sec. 1104.3.b", "rests_on": "law" }, { "label": "No fee for a failed transfer", "value": "A sender may not be charged for an unsuccessful transfer or for one that did not go through because the switch or a participant was down; who absorbs the cost is decided under the ACH guidelines by finding the party at fault. When a collected fee must be returned, it goes back on the same clock as the money.", "citation": "MORPS sec. 1104.3.c (from BSP Circular No. 1195)", "rests_on": "law" }, { "label": "The recipient pays nothing", "value": "The receiving institution may not charge the sending institution or the sender for crediting, and for person to person transfers the recipient must get the full amount with no charge or deduction. The 2026 amendment states this rule for person to person transfers specifically. [Unverified: whether the earlier, general wording in Circular No. 980 still governs other use cases after Circular No. 1238.]", "citation": "BSP Circular No. 1238 (2026-06-17), sec. 2, amending MORPS sec. 201 item b(1)(d); BSP Circular No. 980 (2017), item b(1)(c); BSP Memorandum No. M-2018-012, item 2", "rests_on": "law" }, { "label": "What a sender may be charged", "value": "Since Circular No. 1238, sending fees must be backed by the institution's own cost analysis, kept lower than over the counter fees, and fair across customer groups; a fee for sending to another institution should not differ materially from the fee for sending within the same institution plus the switch cost directly attributable to it.", "citation": "BSP Circular No. 1238, sec. 2, MORPS sec. 201 item b(1)(a) to (c), and Appendix 201-2; BSP Memorandum No. M-2024-015", "rests_on": "law" }, { "label": "The fee freeze has been lifted", "value": "From 2021 the BSP froze InstaPay and PESONet person to person fee increases, and M-2023-037 kept the freeze in place. The Monetary Board approved lifting it on 2026-06-04, to take effect together with Circular No. 1238, on the ground that zero fees for small merchant payments and a person to person pricing structure are now in place. After that date sending fees are governed by the cost based rules above rather than by a freeze.", "citation": "BSP Memorandum No. M-2026-025 (June 2026); BSP Memorandum No. M-2023-037 (December 2023); BSP Circular No. 1238 (2026-06-17)", "rests_on": "law" }, { "label": "QR payments to merchants", "value": "PPMI states that a consumer paying a merchant by QR Ph person to merchant pays no fee, while an InstaPay QR person to person transfer may carry the sender's institution's fee.", "citation": "PPMI InstaPay page (philpayments.org.ph/instapay, read 2026-09-18), FAQs on QR Ph P2M", "rests_on": "guidance" } ], "exceptions": [ "An unauthorized or fraudulent transfer is not a refund case but a liability case: after investigation the institution must reverse it or make a provisional credit permanent (BSP Circular No. 1160, MORB sec. 1003); see ph-instapay:liability.", "Funds recovered through the anti-scam hold are returned to the source institution, which is a recovery of held funds, not a refund right against the sender's own bank (MORPS sec. 1105.19).", "Merchant fees on QR Ph person to merchant payments are borne by the merchant and set under the merchant acquisition rules, not the consumer pricing rules (BSP Circular No. 1238, sec. 3, MORPS sec. 503.7 item c; GMA News, 2026-07-29)." ], "applies_to": "InstaPay transfers between Philippine bank and e-money accounts, as to the return of money and fees; not the sale behind the payment", "caveat": "Do not tell a buyer who paid by InstaPay that they can get a refund from the rail. They cannot. They can get their money back only if the transfer failed, if it was unauthorized or a scam, or if the payee agrees.", "related": [ "ph-instapay:return", "ph-instapay:recall", "ph-instapay:liability", "ph-instapay:consumer-law", "ph-pesonet:refund" ], "basis": { "sources": "BSP Manual of Regulations for Payment Systems, updated December 2025 (https://www.bsp.gov.ph/Regulations/MORPS/MORPS.pdf), secs. 1104.2 and 1104.3; BSP Circular No. 1238, 2026-06-17 (https://www.bsp.gov.ph/Regulations/Issuances/2026/1238.pdf), read in full; BSP Circular No. 980 (2017); Memoranda M-2018-012, M-2023-037, M-2024-015 and M-2026-025 (https://www.bsp.gov.ph/Regulations/Issuances/2026/M-2026-025.pdf); PPMI InstaPay page read 2026-09-18. Read 2026-09-18.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_note": "Recipient-pays-nothing dates from Circular No. 980 (2017). The fee return and no-fee-on-failure rules apply from 2024-12-31 (Circular No. 1195 compliance date). Circular No. 1238 was signed 2026-06-17 and takes effect 15 days after publication; the publication date is not established here [Unverified]. The fee moratorium ends on the same effectivity date as Circular No. 1238 (M-2026-025).", "source_edition": "MORPS updated December 2025; BSP Circular No. 1238 (2026); M-2023-037; M-2026-025; PPMI InstaPay page as read 2026-09-18", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.bsp.gov.ph/Regulations/MORPS/MORPS.pdf", "source_class": "authoritative_primary", "source_title": "BSP Manual of Regulations for Payment Systems, updated December 2025", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the goods-and-services carve-out at sec 1104.2, the one hour money-back rule at sec 1104.3.b, and the no-fee-for-failure rule at sec 1104.3.c." }, { "source_url": "https://www.bsp.gov.ph/Regulations/Issuances/2026/1238.pdf", "source_class": "authoritative_primary", "source_title": "BSP Circular No. 1238, Series of 2026, signed 17 June 2026, amending the National Retail Payment System Framework", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms MB Resolution No. 498 dated 4 June 2026, the P2P recipient-pays-nothing rule, and the cost-based, fair, below-OTC pricing rules with the cost categories in Appendix 201-2, exactly as the record states them." }, { "source_url": "https://www.bsp.gov.ph/Regulations/Issuances/2026/M-2026-025.pdf", "source_class": "authoritative_primary", "source_title": "BSP Memorandum No. M-2026-025, June 2026, lifting the fee moratorium", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the Monetary Board lifted the InstaPay and PESONet fee moratorium under Resolution No. 498 of 4 June 2026, effective concurrently with Circular No. 1238 of 17 June 2026, grounded in zero fees for small merchant payments and the new P2P pricing structure." } ] }, "rail_name": "Philippines InstaPay", "governing_authority": "Bangko Sentral ng Pilipinas", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "ph-instapay:return", "id": "return", "rail": "ph-instapay", "kind": "rail-fact", "facet": "return", "name": "What happens when an InstaPay transfer does not reach the payee, and how fast does the money come back?", "statement": "The BSP names four ways a transfer can fail before the payee is paid: the switch rejects it, the receiving institution returns it, no answer comes back in time so it times out, or it never reaches the switch or the receiver at all. For InstaPay, a rejected, returned or timed-out transfer must be back in the sender's account within one hour of the sender's instruction, and so must a double debit or a failure caused by a lapse in the sending institution's own controls. None of this covers a transfer the sender did not authorize or one the sender keyed wrongly; those follow other rules. The codes that say why a transfer failed are in the ACH's private guidelines.", "details": [ { "label": "Rejected: stopped by the switch", "value": "A transfer the clearing switch operator refuses, for reasons the ACH operating guidelines list, is never credited. One reason the BSP's own rules fix is lack of prefunding: the switch must refuse any instant payment the sending participant's BSP account cannot cover.", "citation": "BSP Circular No. 1195 (2024), glossary, definition of rejected transaction; MORPS (updated December 2025) sec. 701.2 item f(1)(c)", "rests_on": "law" }, { "label": "Returned: sent back by the receiving institution", "value": "The receiving institution may decline to credit and send the transfer back. The BSP's examples are open ended: a restriction on the payee's account, a concern about fraud, money laundering or terrorist financing, an amount above what is allowed, and an account number that does not exist.", "citation": "BSP Circular No. 1195, glossary, definition of returned transaction", "rests_on": "law" }, { "label": "Timed out: no answer in time", "value": "Where the switch or the receiving institution does not respond within the time the ACH guidelines allow, the transfer is timed out, and the BSP expressly leaves open whether it succeeded. The sender still gets the money back on the one hour clock; how the ACH then reconciles a timed-out transfer that did credit is not public.", "citation": "BSP Circular No. 1195, glossary, definition of timed-out transaction; MORPS sec. 1104.3.b", "rests_on": "law" }, { "label": "The one hour clock", "value": "For instant payments, the sending institution must restore the debited amount to the sender within one hour of receiving the sender's instruction, for rejected, returned and timed-out transfers alike. The same hour applies to a transfer debited more than once and to an unsuccessful transfer caused by the sending institution's own control lapse.", "citation": "MORPS sec. 1104.3.b (from BSP Circular No. 1195)", "rests_on": "law" }, { "label": "Fees come back on the same clock", "value": "Where the ACH guidelines say a fee must be returned, the sending institution returns it on the same one hour timeline, and a sender pays no fee at all for an unsuccessful transfer or one lost to a switch or participant outage.", "citation": "MORPS sec. 1104.3.c (from BSP Circular No. 1195)", "rests_on": "law" }, { "label": "Telling the sender", "value": "The ACH guidelines must require the sending institution to tell the sender the true status of the transfer promptly, with follow-ups until it is resolved, in wording common to all participants.", "citation": "MORPS sec. 1104.3.a, items (1) and (2)", "rests_on": "law" }, { "label": "Reason codes are not public", "value": "The reasons the switch may reject, the allowed response time, and the codes carried on a rejection or return are defined in the InstaPay operating guidelines and PSMB rulebooks, which are kept by PPMI and shown to the BSP on request. They were not found on any BSP or PPMI page.", "citation": "MORPS sec. 1203.4 (from BSP Circular No. 1223, 2025); BSP Circular No. 1195, glossary", "rests_on": "law" } ], "exceptions": [ "The one hour rule does not apply to unauthorized transactions or to erroneous transactions keyed by the sender (MORPS sec. 1104.3.b, final paragraph); see ph-instapay:recall and ph-instapay:liability.", "A disputed transfer already credited may instead be held and, after verification, sent back under the anti-scam rules, which run on a 30 day scale, not one hour (MORPS secs. 1105.5 and 1105.19).", "Circular No. 1195 took effect on publication in June 2024 but gave participants and switch operators until 2024-12-31 to comply and to revise the ACH guidelines (BSP Circular No. 1195, sec. 3)." ], "applies_to": "InstaPay transfers that are rejected, returned, timed out or otherwise not credited, and double debits, between the sender's institution and the sender", "caveat": "A return on InstaPay is a failed credit put right, not a way to get back money that reached the payee. Once the payee is credited, the return rules stop and the recall, liability and anti-scam rules take over.", "related": [ "ph-instapay:finality", "ph-instapay:settlement", "ph-instapay:limits", "ph-instapay:recall", "ph-instapay:refund", "ph-instapay:messages", "ph-pesonet:return" ], "basis": { "sources": "BSP Circular No. 1195, 2024 (https://www.bsp.gov.ph/Regulations/Issuances/2024/1195.pdf), glossary and sec. 1104.3, read in full; BSP Manual of Regulations for Payment Systems, updated December 2025 (https://www.bsp.gov.ph/Regulations/MORPS/MORPS.pdf), secs. 701.2, 1104.3, 1105, 1203.4. Read 2026-09-18. Every line rests on BSP text cited by section; the ACH codes and timeouts are not public and are stated only as absent.", "confidence": "high" }, "currency": { "effective_since": "2024-12-31", "effective_note": "Circular No. 1195 (Monetary Board Resolution No. 616, 2024-05-30) took effect on publication in June 2024; 2024-12-31 is the compliance deadline it set for participants, switch operators and revised ACH guidelines. The exact publication date is not established here.", "source_edition": "BSP Circular No. 1195 (2024); MORPS updated December 2025", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.bsp.gov.ph/Regulations/MORPS/MORPS.pdf", "source_class": "authoritative_primary", "source_title": "BSP Manual of Regulations for Payment Systems, updated December 2025", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the four failure categories (rejected, returned, timed-out, unauthorized excluded) at MORPS sec 1104.3.b, the one hour refund clock for instant payments and its extension to double debits and control-lapse failures, the fee return rule at sec 1104.3.c, the sender notification duty at sec 1104.3.a, and that reason codes and response-time limits sit in the private ACH operating guidelines per sec 1203.4." }, { "source_url": "https://www.bsp.gov.ph/Regulations/Issuances/2024/1195.pdf", "source_class": "authoritative_primary", "source_title": "BSP Circular No. 1195, Series of 2024, Consumer Redress Mechanism Standards for Account-to-Account Electronic Fund Transfers", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the glossary definitions of rejected, returned and timed-out transaction exactly as the record states them, including the open-ended return examples (invalid account, account restriction, over-limit amount, fraud or AML or terrorist financing concern) and that a timed-out transfer may or may not have succeeded." } ] }, "rail_name": "Philippines InstaPay", "governing_authority": "Bangko Sentral ng Pilipinas", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "ph-instapay:settlement", "id": "settlement", "rail": "ph-instapay", "kind": "rail-fact", "facet": "settlement", "name": "How and where do InstaPay payments settle between institutions?", "statement": "InstaPay clears each payment in real time through its switch, run by BancNet, and settles the resulting obligations between participants later, in central bank money, through the BSP's Peso RTGS. Every direct participant, or the settlement sponsor acting for it, must keep a prefunded demand deposit account at the BSP that covers its net obligation at every moment of a cycle. The switch watches each position against that balance, warns at agreed thresholds, refuses any payment the balance cannot cover, and stops a participant from sending once its position reaches zero. Settlement cycle times and the ACH's own settlement rules are not public.", "details": [ { "label": "Settlement asset and venue", "value": "Each ACH, through its clearing switch operator, settles its clearing results on its own in the RTGS system the BSP operates. For InstaPay that is the BSP's Peso RTGS (PhilPaSSplus), and the switch submits the batch settlement for its participants as a bank-to-bank credit transfer message.", "citation": "BSP Circular No. 980 (2017), Appendix, part D item f; BSP Philippine Rulebook on Payments and Settlements (ISO 20022), v1.6 (2026-05-29), secs. 4.25 and 4.26 and business scenario 3", "rests_on": "law" }, { "label": "A prefunded account at the BSP", "value": "A direct clearing participant, or its settlement sponsor, keeps a demand deposit account at the BSP used only for its net clearing obligations from electronic payments, and must fund it ahead so it covers that obligation at every point of a settlement cycle, allowing for weekends and holidays. Separate accounts for instant and batch payments were required; MORPS now lets a participant use one account with prior BSP approval.", "citation": "MORPS (updated December 2025) sec. 701.2 items a to c and e (from BSP Circulars No. 1000, 2018, and No. 1135, 2022)", "rests_on": "law" }, { "label": "What the switch does with that balance", "value": "BancNet, as switch operator, takes each participant's BSP account balance at the start of each cycle and tracks net obligations against it. When a position crosses a threshold the participants agreed, it alerts the participant at once. A payment that the account would not fully cover, or that would push the position below zero, is rejected; a participant at zero cannot send again until incoming payments or a deposit lift it.", "citation": "MORPS sec. 701.2 items d and f(1)(a) to (c); BSP Circular No. 1000, subsec. b to d", "rests_on": "law" }, { "label": "Net obligations, settled in the gross system", "value": "What InstaPay settles at the BSP is each participant's net clearing obligation, prefunded in its BSP account; the word gross belongs to the venue, PhilPaSSplus, the BSP's real time gross settlement system, not to how InstaPay payments are grouped. The BSP's own InstaPay FAQ says this of InstaPay by name, and MORPS says net clearing obligations for every clearing participant. The RTGS rulebook's example that labels the InstaPay batch gross shows a message layout: its flow section covers a gross or a net batch in the same message, and in the example each line moves money between one participant and the switch operator's account rather than between the two banks of a customer payment. [Inference: the label describes the message, not the settlement design.]", "citation": "BSP InstaPay FAQ, answer on how InstaPay operates; MORPS sec. 701.2 item a; BSP Philippine Rulebook on Payments and Settlements (ISO 20022), v1.6, sec. 4.25 and business scenario 3 (InstaPay)", "rests_on": "law" }, { "label": "Sponsors for institutions outside the RTGS", "value": "An InstaPay participant without RTGS membership settles through a sponsorship with an RTGS member that holds a BSP account. The BSP describes prefunding as what lets small and large institutions join on equal terms.", "citation": "BSP InstaPay FAQ (March 2021), answer on how InstaPay operates; BSP Circular No. 980, Annex A, definition of direct clearing participant", "rests_on": "guidance" }, { "label": "Accounts count toward reserves and may be drawn down", "value": "A bank's settlement account balance counts toward its reserve requirement, and a participant that finds its prefunding excessive against its highest likely obligation may withdraw the surplus, as long as its required reserves stay whole.", "citation": "MORPS secs. 701.2 item g and 701.4", "rests_on": "law" }, { "label": "Balance reports to the switch", "value": "When the account credited in PhilPaSSplus is a participant's Secured Settlement Account (SSA), whether by the participant's own intra-account liquidity transfer or in a switch's batch settlement, the BSP sends the clearing switch operators a copy of the balance report; the BSP rulebook says InstaPay is the only one that receives it at present. [Inference: this is how BancNet keeps positions current during the day.]", "citation": "BSP Philippine Rulebook on Payments and Settlements (ISO 20022), v1.6, sec. 4.17, settlement confirmation step, and sec. 4.25, step 3", "rests_on": "law" }, { "label": "Cycle times and the ACH's settlement rules", "value": "How many InstaPay settlement cycles run each day, when they close, and the threshold values the participants agreed are set in the InstaPay ACH agreement and operating guidelines, which PPMI does not publish. Circular No. 1196 (2024), signed 2024-06-27, amended the settlement guidelines only to require separate BSP accounts for instant and batch payments unless the BSP approves a single one; it sets no cycle times.", "citation": "MORPS sec. 701.2 item d; MORPS sec. 1203.4; BSP Circular No. 1196 (2024), sec. 1, amending MORPS sec. 701.2 items b and e", "rests_on": "law" } ], "exceptions": [ "The BSP may take enforcement action against a participant that breaches the settlement arrangement even where the ACH's own sanctions also apply (MORPS sec. 701.2, closing paragraph).", "The RTGS itself can refuse a switch's settlement instruction, for example after the settlement cut-off or with an invalid account (BSP ISO 20022 rulebook v1.6, sec. 4.26); what the ACH then does is in its private rules.", "Use of a single settlement account instead of separate instant and batch accounts needs prior BSP approval (MORPS sec. 701.2 items b and e)." ], "applies_to": "interbank settlement of obligations arising from InstaPay transfers among direct participants and settlement sponsors holding demand deposit accounts at the BSP", "caveat": "Settlement here is between institutions and happens after the payee has been paid. A customer never sees a settlement cycle on InstaPay; what a customer sees is a rejection when the sender's institution is not prefunded.", "related": [ "ph-instapay:finality", "ph-instapay:limits", "ph-instapay:participants", "ph-pesonet:settlement" ], "basis": { "sources": "BSP Manual of Regulations for Payment Systems, updated December 2025 (https://www.bsp.gov.ph/Regulations/MORPS/MORPS.pdf), secs. 701 and 1203.4; BSP Circular No. 980 (2017); Circular No. 1000 (2018); Circular No. 1135 (2022, https://www.bsp.gov.ph/Regulations/Issuances/2022/1135.pdf); BSP Philippine Rulebook on Payments and Settlements (ISO 20022) v1.6, 2026-05-29 (https://www.bsp.gov.ph/PaymentAndSettlement/ISO20022-Rulebook.pdf); BSP InstaPay FAQ, March 2021; BSP Circular Letter CL-2022-055 for BancNet as operator. All read 2026-09-18. Circular No. 1196 (https://www.bsp.gov.ph/Regulations/Issuances/2024/1196.pdf) has no text layer; both rendered pages were read on 2026-09-22; it amends only sec. 701.2 items b and e (separate or single DDAs), saying nothing on gross or net. The gross or net detail line was rewritten on 2026-09-22 from the BSP InstaPay FAQ (https://www.bsp.gov.ph/PaymentAndSettlement/FAQ_Instapay.pdf) and the rulebook sec. 4.25 and scenario 3, read again that day. On 2026-09-23 the FAQ, the rulebook and MORPS were opened again: the FAQ's two pages carry no printed date, and the March 2021 date comes from the file's own properties, which title it INSTAPAY FAQ (032021) and give a creation date of 2021-03-15; the balance report line was narrowed to the SSA case the rulebook describes at secs. 4.17 and 4.25.", "confidence": "medium" }, "currency": { "effective_since": "2022-01-21", "effective_note": "The current settlement text is Circular No. 1000 (2018) as amended by Circular No. 1135 (signed 2022-01-21, effective on publication), consolidated in MORPS sec. 701 as of December 2025. The single account option in items b and e comes from Circular No. 1196 (2024, signed 2024-06-27, effective on publication), read 2026-09-22, which MORPS does not credit.", "source_edition": "MORPS updated December 2025; BSP ISO 20022 rulebook v1.6 (2026-05-29); BSP InstaPay FAQ March 2021, read again 2026-09-22", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.bsp.gov.ph/Regulations/MORPS/MORPS.pdf", "source_class": "authoritative_primary", "source_title": "BSP Manual of Regulations for Payment Systems, updated December 2025", "checked_on": "2026-09-23", "checked_by": "validator-opus-2026-09-23", "notes": "Confirms at sec 701.2 the DDA kept at the BSP for net clearing obligations and prefunded to cover them at any point of a cycle (items a and c), separate instant and batch accounts unless the BSP approves one (items b and e), agreed thresholds and the switch's alerts, rejection of uncovered payments and suspension at a zero position (items d and f(1)), surplus withdrawal without a reserve shortfall (item g), BSP enforcement alongside ACH sanctions (closing paragraph), reserve eligibility at sec 701.4, and that rulebooks are the management body's responsibility, shown to the BSP on request, at sec 1203.4." }, { "source_url": "https://www.bsp.gov.ph/PaymentAndSettlement/ISO20022-Rulebook.pdf", "source_class": "authoritative_primary", "source_title": "BSP Philippine Rulebook on Payments and Settlements (ISO 20022), PhilPaSSplus, v1.6, 2026-05-29", "checked_on": "2026-09-23", "checked_by": "validator-opus-2026-09-23", "notes": "Confirms that a clearing switch operator submits one batch settlement message for its participants whose flow covers either a gross or a net batch (sec 4.25), that PhilPaSSplus may reject it after the cut-off or for an invalid account (sec 4.26), that the BancNet InstaPay example labelled gross has each line running between a participant and the switch operator rather than between two customer banks (business scenario 3), and that when a Secured Settlement Account is credited the BSP copies the balance report to the switch operators, InstaPay alone at present (secs 4.17 and 4.25). Does not itself say whether InstaPay settles gross or net." }, { "source_url": "https://www.bsp.gov.ph/PaymentAndSettlement/FAQ_Instapay.pdf", "source_class": "public_primary", "source_title": "BSP InstaPay FAQ (file titled INSTAPAY FAQ 032021, created 2021-03-15)", "checked_on": "2026-09-23", "checked_by": "validator-opus-2026-09-23", "notes": "Confirms that InstaPay settles through the BSP real time gross settlement system, that what is settled there is each participant's net clearing obligation, prefunded in its DDA at the BSP, that prefunding lets small and large institutions take part on equal terms, and that a participant without PhilPaSS membership takes part through a sponsor that is a member. The pages carry no printed date; the March 2021 date is from the file properties." } ] }, "rail_name": "Philippines InstaPay", "governing_authority": "Bangko Sentral ng Pilipinas", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "ph-pesonet:consumer-law", "id": "consumer-law", "rail": "ph-pesonet", "kind": "rail-fact", "facet": "consumer-law", "name": "What consumer protection law applies to a PESONet transfer, and where does a customer complain?", "statement": "PESONet customers are protected by general Philippine financial consumer law, not by rights written into the scheme. RA 11765, the Financial Products and Services Consumer Protection Act, is implemented for BSP-supervised institutions by Circular No. 1160; RA 12010, the Anti-Financial Account Scamming Act, by Circular No. 1215; and Circular No. 1195 sets redress standards specifically for account to account transfers through an ACH. A customer complains first to their own institution, which must run a free complaints unit and a round the clock fraud reporting channel, and may escalate to the BSP's Consumer Assistance Mechanism only after that.", "details": [ { "label": "The consumer protection framework", "value": "The BSP's financial consumer protection regulations implement RA 11765 for banks and non-bank institutions it supervises, including e-money issuers, and require each to run a consumer protection risk management system and standards of conduct.", "citation": "BSP Circular No. 1160 (2022), MORB/MORNBFI secs. 1001 to 1003", "rests_on": "law" }, { "label": "Redress standards for transfers through an ACH", "value": "Circular No. 1195 binds every clearing switch operator and ACH participant offering domestic account to account transfers, covering person to person, person to merchant and person to biller payments. It fixes the credit clock, the refund clock for failed transfers, fee rules, outage notices and status notifications, and it makes the sending institution responsible for keeping its customer informed on unauthorized and mistaken transfers.", "citation": "MORPS (updated December 2025) secs. 1104.2 and 1104.3 items a to e (from BSP Circular No. 1195, 2024)", "rests_on": "law" }, { "label": "First stop: the customer's own institution", "value": "Each institution must keep one free consumer assistance unit to take complaints, inquiries and requests, publish its complaint steps and turnaround times, and tell the customer where the complaint stands and how it ended.", "citation": "BSP Circular No. 1160, MORB sec. 1003, effective recourse, Financial Consumer Protection Assistance Mechanism", "rests_on": "law" }, { "label": "A fraud channel open all hours", "value": "Institutions must offer a free, actively monitored reporting channel available around the clock, and must acknowledge every report in writing straight away through the same channel. Under the anti-scam rules, a complaint through the sending institution's fraud channel is one of the ways a hold on disputed funds starts.", "citation": "BSP Circular No. 1160, MORB sec. 1003, reporting channels; MORPS sec. 1105.6 item a (from BSP Circular No. 1215, 2025)", "rests_on": "law" }, { "label": "Second stop: the BSP", "value": "A customer dissatisfied with the institution's handling may escalate to the BSP's Consumer Assistance Mechanism, including through the BSP Online Buddy, but only after complaining to the institution first. Disputed transaction complaints escalated this way follow Circular No. 1169 (2023).", "citation": "BSP Circular No. 1160, MORB sec. 1003, effective recourse; MORPS sec. 1105.25", "rests_on": "law" }, { "label": "Anti-scam law and data sharing", "value": "During coordinated verification of a disputed transaction, bank secrecy and data privacy laws do not apply to the information the institutions share, though it must be kept confined to that process. Institutions must also tell customers that cooperating is part of their duty under RA 12010 and that RA 11765 still bars any waiver of their consumer rights.", "citation": "MORPS secs. 1105.18 and 1105.4 item j (from BSP Circular No. 1215)", "rests_on": "law" }, { "label": "Fee disclosure", "value": "Institutions must disclose their electronic payment fees to the BSP, which publishes them, and must make the rules on collecting and returning transfer fees clear to consumers in public materials.", "citation": "BSP Circular No. 980 (2017), item b(2); BSP Memorandum No. M-2018-013; BSP Circular No. 1238 (2026), sec. 4; MORPS sec. 1104.3.c", "rests_on": "law" } ], "exceptions": [ "Disputes about the goods or services behind a payment are outside the Circular No. 1195 redress standards (MORPS sec. 1104.2).", "The anti-scam hold does not cover a sender's own keying error; erroneous transactions fall under Circular No. 1160 (MORPS sec. 1105.2).", "RA 11765, RA 12010 and Circular No. 1169 were not read for this record; their contents are stated only as the circulars read here describe them [Unverified].", "Businesses are not shut out: the BSP's definition of a financial consumer covers juridical as well as natural persons with a financial transaction at a supervised institution, so a company paying payroll or suppliers by PESONet can use the same complaint routes (BSP Circular No. 1160, sec. 1001, definition of financial consumer)." ], "applies_to": "consumers holding bank or e-money accounts at BSP-supervised institutions who send or receive PESONet transfers", "caveat": "These protections come from law and regulation that apply to every account to account transfer in the Philippines, InstaPay and on-us transfers included. PESONet adds no consumer right of its own that is public.", "related": [ "ph-pesonet:liability", "ph-pesonet:recall", "ph-pesonet:refund", "ph-pesonet:return", "ph-instapay:consumer-law", "ph-pesonet:decision-points" ], "basis": { "sources": "BSP Circular No. 1160, 2022 (https://www.bsp.gov.ph/Regulations/Issuances/2022/1160.pdf), read in the relevant parts; BSP Manual of Regulations for Payment Systems, updated December 2025 (https://www.bsp.gov.ph/Regulations/MORPS/MORPS.pdf), secs. 1104 and 1105; BSP Circular No. 1195 (2024); BSP Circular No. 980 (2017); BSP Circular No. 1238 (2026); Memorandum M-2018-013 (https://www.bsp.gov.ph/Regulations/Issuances/2018/m013.pdf). Read 2026-09-18.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_note": "Circular No. 1160 dates from 2022-11-28; Circular No. 1195 compliance from 2024-12-31; Circular No. 1215 is dated 2025-06-10 per MORPS. Exact effectivity dates are not established here.", "source_edition": "BSP Circulars 980, 1160, 1195, 1238; MORPS updated December 2025", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.bsp.gov.ph/Regulations/MORPS/MORPS.pdf", "source_class": "authoritative_primary", "source_title": "BSP Manual of Regulations for Payment Systems, updated December 2025", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms Circular No. 1195's redress standards at secs 1104.2 and 1104.3, the anti-scam data sharing rule at sec 1105.18 and sec 1105.4 item j, the fraud channel trigger at sec 1105.6 item a, and the Circular No. 1169 escalation route at sec 1105.25; these BSP rules apply to every account to account transfer, PESONet included." }, { "source_url": "https://www.bsp.gov.ph/Regulations/Issuances/2022/1160.pdf", "source_class": "authoritative_primary", "source_title": "BSP Circular No. 1160, Series of 2022, Regulations on Financial Consumer Protection", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the consumer protection risk management system requirement, the free consumer assistance unit, the round-the-clock reporting channel, and that a financial consumer includes juridical persons, dated 28 November 2022 as the record's currency note states." } ] }, "rail_name": "Philippines PESONet", "governing_authority": "Bangko Sentral ng Pilipinas", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "ph-pesonet:decision-points", "id": "decision-points", "rail": "ph-pesonet", "kind": "rail-fact", "facet": "decision-points", "name": "Where does PESONet stop and a person or institution decide?", "statement": "Most of a PESONet cycle is mechanical: cut-off, netting, a funding check, settlement, file release, credit. The choices sit around it. Each sending institution chooses its own customer cut-offs, limits and fees. Each participant decides whether and when to fund its BSP account for a cycle, and a participant that does not fund has all its payments dropped. The receiving institution decides whether to return a transfer on account, fraud or money laundering grounds. The participants collectively decide how many cycles run and when, and PPMI writes it into rules the BSP approves. After a disputed or mistaken transfer, the same judgments apply as on every Philippine account to account transfer: whether to hold, extend and release funds, how to share a loss, and whether the recipient agrees to give mistaken money back.", "details": [ { "label": "Participants collectively: the schedule", "value": "The BSP's PESONet FAQ says the number and timing of cycles are set by collective agreement of the ACH participants and can grow as the industry needs; that is how PESONet went from one cycle a day to three. The switch cut-offs and credit targets every customer relies on therefore rest on an industry decision.", "citation": "BSP PESONet FAQ (2018), key feature 2; BSP PESONet 3MBS FAQ (as of 2024-08-27), question 2", "rests_on": "guidance" }, { "label": "Each participant: fund or drop out of the cycle", "value": "A participant decides how much to prefund for each cycle and whether to top up before the cut-off or within the grace period. If it does not fund, the switch leaves out every instruction it sent for that cycle, and penalties under the ACH rules follow.", "citation": "MORPS (updated December 2025) sec. 701.2 items c and f(2)(c) to (e) (from BSP Circular No. 1135, 2022)", "rests_on": "law" }, { "label": "Sending institution: cut-offs, limits and fees", "value": "Each bank or e-money issuer sets its own customer cut-off for each PESONet window, may set its own per transaction or daily limits by channel, and sets its sending fee within the cost based rules of Circular No. 1238.", "citation": "PPMI PESONet page (read 2026-09-18), batch cycles and limits and fees; BSP Circular No. 1238 (2026), sec. 2, MORPS sec. 201 item b", "rests_on": "law" }, { "label": "Receiving institution: credit or return", "value": "The receiving institution may return a transfer uncredited on grounds the BSP gives as open examples, among them account restrictions and fraud or money laundering concerns, and may run extra anti-money laundering checks before crediting.", "citation": "BSP Circular No. 1195 (2024), glossary, returned transaction; BSP Circular No. 980 (2017), specific rules item c(4) (now MORPS sec. 201.4)", "rests_on": "law" }, { "label": "Disputed transfers: hold, extend, lift, release", "value": "Institutions decide whether reasonable grounds justify extending a hold beyond the first 5 days, whether a payee's evidence justifies lifting it early, and at the end whether what they found supports sending the money back to the source rather than releasing it to the payee. A court, not an institution, decides any hold beyond 30 days.", "citation": "MORPS secs. 1105.5, 1105.10, 1105.14 and 1105.19 (from BSP Circular No. 1215, 2025)", "rests_on": "law" }, { "label": "Sending institution: who bears a loss", "value": "On an unauthorized transaction the institution weighs its own compliance, its and its agents' conduct, and the customer's conduct, and decides the allocation; no public formula governs it.", "citation": "BSP Circular No. 1160 (2022), MORB sec. 1003, liability for losses arising from unauthorized transactions", "rests_on": "law" }, { "label": "The recipient: consent to return a mistaken credit", "value": "For a transfer keyed to the wrong account, both institutions must try to recover the funds, but the recipient's agreement is what makes it happen. [Inference: no rule read here lets an institution debit the recipient for a sender's keying error without it.]", "citation": "BSP Circular No. 1160, MORB sec. 1003, erroneous transactions; BSP InstaPay FAQ (March 2021), erroneous fund transfers (the BSP's general guidance on mistaken credits)", "rests_on": "law" }, { "label": "PPMI and the BSP: the rules themselves", "value": "PPMI writes the PESONet rules, including thresholds, grace periods and penalties, and the BSP reviews and approves them before they bind.", "citation": "MORPS sec. 101.5 item c; BSP Memorandum No. M-2022-031, item 2.a", "rests_on": "law" } ], "exceptions": [ "The receiving institution may not decide to credit later than two hours after the clearing advice, or the next cycle (MORPS sec. 1104.3.a).", "An institution may not decide to charge the recipient of a person to person transfer (BSP Circular No. 1238, sec. 2).", "Exclusion of an unfunded participant's instructions is automatic, not discretionary, once the grace period passes (MORPS sec. 701.2 item f(2)(c))." ], "applies_to": "points in a PESONet transfer or its aftermath where a rule leaves the outcome to a participant, a customer, PPMI or the BSP", "caveat": "This facet is Orca's reading of where the public rules leave judgment open, and it caps at medium confidence. Every line names the rule that leaves the decision open; none predicts how a decision will go. The private PESONet rules may narrow some of these choices.", "related": [ "ph-pesonet:finality", "ph-pesonet:settlement", "ph-pesonet:hours", "ph-pesonet:limits", "ph-pesonet:return", "ph-pesonet:recall", "ph-pesonet:refund", "ph-pesonet:liability", "ph-pesonet:consumer-law", "ph-pesonet:messages", "ph-pesonet:participants", "ph-instapay:decision-points" ], "basis": { "sources": "BSP Manual of Regulations for Payment Systems, updated December 2025 (https://www.bsp.gov.ph/Regulations/MORPS/MORPS.pdf), secs. 101.5, 201.4, 701.2, 1104.3 and 1105; BSP Circulars No. 980 (2017), 1135 (2022), 1160 (2022), 1195 (2024), 1238 (2026); Memorandum M-2022-031; BSP PESONet FAQ 2018; BSP PESONet 3MBS FAQ as of 2024-08-27; BSP InstaPay FAQ March 2021; PPMI PESONet page read 2026-09-18. Read 2026-09-18.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_note": "Draws on rules from 2017 to 2026; the most recent are Circular No. 1215 (dated 2025-06-10 per MORPS) and Circular No. 1238 (signed 2026-06-17, effective 15 days after publication) [Unverified: effectivity dates].", "source_edition": "MORPS updated December 2025; BSP Circulars 980, 1135, 1160, 1195, 1238; BSP PESONet FAQs 2018 and 2024", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.bsp.gov.ph/Regulations/MORPS/MORPS.pdf", "source_class": "authoritative_primary", "source_title": "BSP Manual of Regulations for Payment Systems, updated December 2025", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the PSMB rule-setting role at sec 101.5 item c, the participant funding decision and automatic drop-out at sec 701.2 items c and f(2)(c) to (e), the receiving institution's return discretion at sec 201.4 item c(4), and the hold, extend, lift and release judgments at secs 1105.5, 1105.10, 1105.14 and 1105.19." }, { "source_url": "https://www.bsp.gov.ph/Regulations/Issuances/2022/1160.pdf", "source_class": "authoritative_primary", "source_title": "BSP Circular No. 1160, Series of 2022, Regulations on Financial Consumer Protection", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the open, unweighted list of factors an institution considers when allocating loss on an unauthorized transaction." } ] }, "rail_name": "Philippines PESONet", "governing_authority": "Bangko Sentral ng Pilipinas", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "ph-pesonet:finality", "id": "finality", "rail": "ph-pesonet", "kind": "rail-fact", "facet": "finality", "name": "When does a PESONet transfer become final, and can it be reversed?", "statement": "PESONet settles before it clears. Each batch's net positions must settle in the participants' accounts at the BSP before the switch releases the incoming files, so a receiving institution only ever credits money that has already moved in central bank funds, and settlement in the Peso RTGS is final and irrevocable by regulation. The payee is then credited within two hours of the clearing advice or by the next cycle. PPMI tells customers a processed transfer is generally final and cannot be reversed. Money can still come back by other routes, a return before credit, a hold under the anti-scam rules, or a mistaken credit the receiver agrees to send back, but none unwinds the settled payment.", "details": [ { "label": "Settle before clear", "value": "The BSP describes PESONet's settlement risk control as settling each batch's netting results across the participants' demand deposit accounts at the BSP first, and only when that succeeds for everyone does the switch release the inward clearing file. Receiving institutions cannot start crediting beneficiaries until they have that file.", "citation": "BSP PESONet FAQ (2018), key feature 1 and expected change 2", "rests_on": "guidance" }, { "label": "A participant that cannot fund drops out of the cycle", "value": "A participant short of funds must top up its BSP account before the cut-off or within the agreed grace period. If it does not, the switch removes all of that participant's instructions from the cycle's net results, and after a settlement failure report from the BSP it recomputes the net settlement without them. Those payments are not settled in that cycle and so are not final.", "citation": "MORPS (updated December 2025) sec. 701.2 item f(2)(c) and (d) (from BSP Circular No. 1135, 2022)", "rests_on": "law" }, { "label": "Settlement in the Peso RTGS is final", "value": "Each ACH's switch operator settles its results in the BSP's RTGS. When the RTGS has debited and credited the settlement accounts for what the switch sent, the settlement is final and irrevocable; if an amount turns out not to have been due, the settlement stays and repayment is a new obligation between the two participants.", "citation": "BSP Circular No. 980 (2017), Appendix, part D item f; MORPS sec. 1401.9 item g", "rests_on": "law" }, { "label": "Then the payee is credited", "value": "For batched transfers the receiving institution must credit the beneficiary no later than two hours after it receives the clearing advice, or by the next settlement cycle where there are several a day. The BSP's 2024 FAQ says a one hour grace period was allowed during the rollout of three cycles.", "citation": "MORPS sec. 1104.3.a (from BSP Circular No. 1195, 2024); BSP Memorandum No. M-2018-012, item 3; BSP PESONet 3MBS FAQ (as of 2024-08-27), question 3", "rests_on": "law" }, { "label": "What PPMI tells customers", "value": "PPMI's page says that once processed, a PESONet transfer is generally final and cannot be reversed.", "citation": "PPMI PESONet page (philpayments.org.ph/pesonet, read 2026-09-18), FAQ on cancelling a transfer", "rests_on": "guidance" }, { "label": "The ACH's own finality rule is not public", "value": "The PSMB must set rules that clear and settle payments with finality, subject to BSP approval, and keeps the rulebooks, which it shows to the BSP on request. The PESONet rulebook is not published, so any cancellation window before a batch closes, if one exists, is not stated here.", "citation": "MORPS secs. 101.5 item c and 1203.4 (from BSP Circular No. 1223, 2025)", "rests_on": "law" } ], "exceptions": [ "A transfer rejected by the switch or returned by the receiving institution comes back to the sender within two hours of the settlement report; that is a return, not a reversal (MORPS sec. 1104.3.b).", "Credited funds can be held for up to 30 calendar days in total under the anti-scam rules and then sent back if the dispute is upheld (MORPS secs. 1105.5 and 1105.19).", "Whether a sender's bank will stop a transfer that it has taken but not yet submitted to a batch is a matter for that bank; no public rule addresses it [Inference]." ], "applies_to": "a peso account-to-account credit transfer through the PESONet batch ACH between accounts at BSP-supervised banks and e-money issuers in the Philippines", "caveat": "On PESONet the order is the opposite of InstaPay: interbank settlement comes first and the customer credit follows, so a PESONet payee is never credited with money that has not settled. Do not carry InstaPay's seconds-level timing over to PESONet.", "related": [ "ph-instapay:finality", "ph-pesonet:settlement", "ph-pesonet:hours", "ph-pesonet:return", "ph-pesonet:recall", "ph-pesonet:liability" ], "basis": { "sources": "BSP PESONet FAQ, 2018 (https://www.bsp.gov.ph/PaymentAndSettlement/FAQ_PESONet.pdf); BSP PESONet 3MBS FAQ as of 2024-08-27 (https://www.bsp.gov.ph/PaymentAndSettlement/FAQs_3MBS_of_the_PESONet.pdf); BSP Manual of Regulations for Payment Systems, updated December 2025 (https://www.bsp.gov.ph/Regulations/MORPS/MORPS.pdf), secs. 101.5, 701.2, 1104.3, 1105, 1203.4, 1401.9; BSP Circular No. 980 (2017); Circular No. 1135 (2022); Memorandum M-2018-012; PPMI PESONet page (https://www.philpayments.org.ph/pesonet). Read 2026-09-18. The PESONet ACH operating guidelines were not available.", "confidence": "medium" }, "currency": { "effective_since": "2022-01-21", "effective_note": "Batch settlement rules are Circular No. 1135 (signed 2022-01-21), consolidated in MORPS sec. 701 as of December 2025. Circular No. 1196 (2024) amended the settlement guidelines and is a scanned image not read here [Unverified: whether it changed anything in this record].", "source_edition": "MORPS updated December 2025; BSP PESONet FAQ 2018; BSP PESONet 3MBS FAQ as of 2024-08-27; PPMI PESONet page as read 2026-09-18", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.bsp.gov.ph/Regulations/MORPS/MORPS.pdf", "source_class": "authoritative_primary", "source_title": "BSP Manual of Regulations for Payment Systems, updated December 2025", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the participant funding drop-out rule at sec 701.2 item f(2)(c) and (d), RTGS settlement finality word for word at sec 1401.9 item g, the two hour or next-cycle credit deadline at sec 1104.3.a, and that the PESONet rulebook's own finality rule is not public per sec 1203.4." }, { "source_url": "https://www.bsp.gov.ph/PaymentAndSettlement/FAQ_PESONet.pdf", "source_class": "public_primary", "source_title": "BSP PESONet Frequently Asked Questions, 2018", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the settle-before-clear description, that net settlement across BSP accounts happens before the switch releases the inward file to receiving institutions." } ] }, "rail_name": "Philippines PESONet", "governing_authority": "Bangko Sentral ng Pilipinas", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "ph-pesonet:hours", "id": "hours", "rail": "ph-pesonet", "kind": "rail-fact", "facet": "hours", "name": "When does PESONet run, and when does the payee get the money?", "statement": "PESONet clears and settles only on banking days, in three batches with switch cut-offs at 10:00, 13:00 and 16:00 Philippine time; the midday batch was added on 2024-07-08. A customer can usually submit at any hour, but anything after the last cut-off, or on a weekend or holiday, waits for the first batch of the next banking day. By regulation the payee must be credited within two hours of the clearing advice or by the next cycle, which PPMI shows as credit by about 13:00, 16:00 and 19:00 for the three batches. Each bank sets its own earlier cut-off for customers. The cycle times come from BSP and PPMI public pages; the rule text behind them is not published.", "details": [ { "label": "Banking days only", "value": "Transfers are cleared in batches at set times within the banking day. Sent before a cut-off, they are normally credited the same banking day; sent after the last cut-off, on a weekend or on a holiday, they are credited the next banking day.", "citation": "PPMI PESONet page (philpayments.org.ph/pesonet, read 2026-09-18), key features, timing and cut-offs, and FAQ on transfer time; BSP PESONet FAQ (2018), what is PESONet", "rests_on": "guidance" }, { "label": "Three switch cut-offs", "value": "10:00, 13:00 and 16:00. The 10:00 batch picks up everything received from just after 16:00 on the previous banking day up to 10:00; the 13:00 and 16:00 batches take what arrives in the three hours before each.", "citation": "BSP PESONet 3MBS FAQ (as of 2024-08-27), question 2 and its cycle table; PPMI PESONet page (read 2026-09-18), PESONet cut-off table", "rests_on": "guidance" }, { "label": "When the payee is credited", "value": "PPMI's table pairs the three cut-offs with credit to the beneficiary by 13:00, 16:00 and 19:00, adding that some institutions credit the next banking day. The BSP rule behind it is a ceiling of two hours after the receiving institution gets the clearing advice, or no later than the next cycle.", "citation": "PPMI PESONet page (read 2026-09-18), credit to the beneficiary account table; MORPS (updated December 2025) sec. 1104.3.a (from BSP Circular No. 1195, 2024)", "rests_on": "law" }, { "label": "The rollout grace hour", "value": "When three cycles began, the BSP said receiving institutions were allowed one extra hour during the initial rollout, up to three hours in all to credit customers. Whether that grace still applies is not stated in any later public text read here. [Unverified]", "citation": "BSP PESONet 3MBS FAQ (as of 2024-08-27), question 3", "rests_on": "guidance" }, { "label": "Your bank's cut-off comes first", "value": "The published times are switch cut-offs. Each bank or e-money issuer sets and announces its own earlier cut-off for each window, and that is the time a customer must meet.", "citation": "PPMI PESONet page (read 2026-09-18), batch cycles and timing notes", "rests_on": "guidance" }, { "label": "Failed transfers come back within two hours of the report", "value": "A PESONet transfer rejected by the switch or returned by the receiving institution must be back in the sender's account within two hours of the sending institution receiving the switch's settlement report.", "citation": "MORPS sec. 1104.3.b", "rests_on": "law" }, { "label": "What is not public", "value": "The grace period for funding after a cut-off, the RTGS settlement windows for each batch, and any change to the schedule are set in the PESONet ACH rules, which PPMI does not publish. Circular No. 1196 (2024), whose title concerns settlement and which may touch cycles, was not read.", "citation": "MORPS secs. 701.2 item f(2)(c) and 1203.4; BSP NRPS regulatory framework page, issuance list", "rests_on": "law" } ], "exceptions": [ "The 2018 BSP FAQ describes one clearing cycle a day; that is out of date since 2024-07-08 (BSP PESONet FAQ, 2018; BSP PESONet 3MBS FAQ, 2024).", "The BSP's InstaPay FAQ comparison table describes PESONet as same day and available 24/7 on banking days only; read with the PPMI page, this means customers can submit at any time but batches run on banking days [Inference].", "Philippine time is UTC+8 [Inference: general knowledge, not taken from a BSP text]." ], "applies_to": "PESONet credit transfers between participating banks and e-money issuers in the Philippines", "caveat": "Quote the bank's own cut-off to a customer, not the 10:00, 13:00 and 16:00 switch cut-offs, and never promise same day credit for a transfer submitted after the bank's last cut-off or on a non-banking day.", "related": [ "ph-pesonet:settlement", "ph-pesonet:finality", "ph-instapay:hours", "ph-pesonet:return" ], "basis": { "sources": "BSP PESONet 3MBS FAQ as of 2024-08-27 (https://www.bsp.gov.ph/PaymentAndSettlement/FAQs_3MBS_of_the_PESONet.pdf); PPMI PESONet page (https://www.philpayments.org.ph/pesonet), read 2026-09-18; BSP PESONet FAQ, 2018 (https://www.bsp.gov.ph/PaymentAndSettlement/FAQ_PESONet.pdf); BSP InstaPay FAQ, March 2021, comparison table; BSP Manual of Regulations for Payment Systems, updated December 2025, secs. 701.2, 1104.3, 1203.4. Read 2026-09-18. The two cycle-time sources are from different organisations (BSP and PPMI) in their own wording. The PESONet rulebook is not published, so this record is flagged primary_not_public.", "confidence": "medium" }, "currency": { "effective_since": "2024-07-08", "effective_note": "Third (13:00) cycle added 2024-07-08 per the BSP 3MBS FAQ. Cut-off and credit times are current on PPMI's page read 2026-09-18.", "source_edition": "BSP PESONet 3MBS FAQ as of 2024-08-27; PPMI PESONet page as read 2026-09-18; MORPS updated December 2025", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "primary_not_public": true, "corroboration": [ { "source_url": "https://www.bsp.gov.ph/PaymentAndSettlement/FAQs_3MBS_of_the_PESONet.pdf", "source_class": "public_primary", "source_title": "BSP PESONet 3MBS Frequently Asked Questions, as of 27 August 2024", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the three cut-offs 10:00, 13:00 and 16:00, the cycle coverage windows, the midday cycle added 8 July 2024, the two hour credit ceiling, and the one hour rollout grace allowing up to three hours, all as the record states them." }, { "source_url": "https://www.philpayments.org.ph/pesonet", "source_class": "public_primary", "source_title": "PPMI PESONet page, philpayments.org.ph, read 2026-09-18", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Independent second source, different organisation and host from the BSP FAQ. Confirms the same three cut-offs (10:00, 1:00pm, 4:00pm) paired with credit times 1:00pm, 4:00pm and 7:00pm in PPMI's own wording, and that each bank sets its own earlier cut-off." } ] }, "rail_name": "Philippines PESONet", "governing_authority": "Bangko Sentral ng Pilipinas", "snapshot": "2026-09-18", "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "not_public", "label": "the operator's own text", "needs": "what the operator's own text says, which Orca has not read", "detail": "Bangko Sentral ng Pilipinas's own text is not the source for this rail fact: it is not public, or not under terms Orca can use. It rests on 2 named public sources, so a term set by agreement rather than by a published rule is not Orca's to state.", "from": "currency.primary_not_public" } ] }, { "uid": "ph-pesonet:liability", "id": "liability", "rail": "ph-pesonet", "kind": "rail-fact", "facet": "liability", "name": "Who bears the loss on an unauthorized, fraudulent or mistaken PESONet transfer?", "statement": "The loss rules for PESONet are the BSP's general rules for every account to account transfer, the same as for InstaPay; no fixed loss split is written into any public rule. The BSP's consumer protection rules make the customer's own institution the first stop and require it to protect the customer while it investigates, to report the outcome within three banking days of finishing, and to reverse the transaction if it proves unauthorized or fraudulent. How much of a loss the institution then carries is weighed case by case against the institution's compliance with BSP rules, its own and its agents' conduct, and the customer's conduct. Under the anti-scam law an institution that fails to hold disputed funds when it should is liable for the resulting loss, including restitution. A sender's own keying error stays with the sender unless the money is recovered, since institutions may rely on the account number alone.", "details": [ { "label": "The sender's institution handles the claim", "value": "Disputes over transfers and claims of unauthorized transactions are lodged with the originating institution, which is primarily responsible for assisting the customer and giving redress, and must bring the receiving institution in at once.", "citation": "BSP Circular No. 1160 (2022), MORB/MORNBFI sec. 1003, unauthorized transactions; MORPS (updated December 2025) sec. 1104.3.e (from BSP Circular No. 1195, 2024)", "rests_on": "law" }, { "label": "Protection while the claim is open", "value": "While the investigation runs, the customer is not left out of pocket without recourse: the institution may offer a provisional credit the customer cannot yet withdraw, funds still sitting at the receiving end are to be held, measures such as blocking an account may be used, and any interest or fees on the disputed amount are paused.", "citation": "BSP Circular No. 1160, MORB sec. 1003, unauthorized transactions", "rests_on": "law" }, { "label": "The outcome and the reversal", "value": "The institution must tell the customer formally within three banking days after its investigation ends. If the transaction was unauthorized or fraudulent it must reverse or correct it, with any interest and fees, or make a provisional credit final; if nothing wrong occurred, it may take back the provisional credit after telling the customer.", "citation": "BSP Circular No. 1160, MORB sec. 1003, unauthorized transactions", "rests_on": "law" }, { "label": "How the loss is weighed", "value": "The rule gives no percentage or cap. It leaves the list of factors open and names three kinds: whether the institution breached consumer protection or other BSP requirements, what the institution and anyone acting for it (staff, agents, outsourced providers) did or failed to do, and how the customer behaved before, during and after the transaction.", "citation": "BSP Circular No. 1160, MORB sec. 1003, liability for losses arising from unauthorized transactions", "rests_on": "law" }, { "label": "Failing to hold scam proceeds costs the institution", "value": "Under the rules implementing RA 12010, an institution that should have held funds in a disputed transaction and did not is liable for the loss or damage that follows, including restitution to the account owner. An institution that holds funds too long or without following the procedure faces BSP administrative action, while one that holds in line with the rules has a safe harbor from liability.", "citation": "MORPS secs. 1105.22, 1105.23 and 1105.27 (from BSP Circular No. 1215, 2025)", "rests_on": "law" }, { "label": "The customer's side of the bargain", "value": "Institutions must remind account owners of their own part: reporting a disputed transaction at once and helping the investigation, reading statements and alerts, switching on offered safeguards such as limits and multi-factor login, keeping contact details up to date, and never sharing passwords, PINs or one-time codes. [Inference: these are among the customer actions an institution may weigh when allocating a loss.]", "citation": "MORPS sec. 1105.3 item a; BSP Circular No. 1160, MORB sec. 1003, protection of consumer assets against fraud and misuse", "rests_on": "law" }, { "label": "Mistaken account numbers", "value": "Institutions may credit on the account number alone, must tell customers so, and are not liable for relying on it. A sender who types the wrong number therefore bears the loss unless recovery succeeds.", "citation": "BSP Circular No. 980 (2017), specific rules item c(3) (now MORPS sec. 201.4); BSP Circular No. 1160, MORB sec. 1003, erroneous transactions", "rests_on": "law" }, { "label": "Between the institutions", "value": "How losses from holding, verifying and releasing disputed funds are settled among institutions is left to an industry protocol the BSP reviews; the ACH guidelines also allocate cost to the party at fault for failed transfers. Neither document is public.", "citation": "MORPS sec. 1105.4 item h; MORPS sec. 1104.3.c", "rests_on": "law" } ], "exceptions": [ "The anti-scam hold and its liability rules do not apply to erroneous transactions (MORPS sec. 1105.2).", "Where a court extends a hold, the 30 day limit and the release rules give way to the court order (MORPS secs. 1105.5 and 1105.19).", "A person who reports a transfer as disputed maliciously or in bad faith can be criminally liable (MORPS sec. 1105.24, citing RA 12010).", "The same BSP rules apply to every BSP-supervised institution and every account to account transfer; nothing in them is specific to PESONet. One practical difference: a PESONet credit lands only after the batch settles, so a quickly reported scam may catch funds before the payee can move them [Inference]." ], "applies_to": "losses on PESONet transfers that were unauthorized, fraudulent, or sent to the wrong account, as between the customer, their institution and the receiving institution", "caveat": "There is no Philippine equivalent here of a fixed consumer liability cap; the outcome depends on the institution's assessment and, if the customer disputes it, on escalation to the BSP or the courts. RA 12010 and RA 11765 were not read directly for this record.", "related": [ "ph-pesonet:recall", "ph-pesonet:refund", "ph-pesonet:finality", "ph-instapay:liability", "ph-pesonet:consumer-law", "ph-pesonet:decision-points" ], "basis": { "sources": "BSP Circular No. 1160, 2022 (https://www.bsp.gov.ph/Regulations/Issuances/2022/1160.pdf), MORB sec. 1003, read in the relevant parts; BSP Manual of Regulations for Payment Systems, updated December 2025 (https://www.bsp.gov.ph/Regulations/MORPS/MORPS.pdf), secs. 201.4, 1104.3 and 1105; BSP Circular No. 980 (2017). Read 2026-09-18. RA 12010 and RA 11765 were not read; they are cited only as the circulars cite them.", "confidence": "medium" }, "currency": { "effective_since": "2025-06-10", "effective_note": "The holding and liability rules are Circular No. 1215, dated 2025-06-10 per MORPS; the unauthorized transaction rules are Circular No. 1160 (2022). Effectivity dates of both circulars are not established here [Unverified].", "source_edition": "BSP Circular No. 1160 (2022); MORPS updated December 2025", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.bsp.gov.ph/Regulations/Issuances/2022/1160.pdf", "source_class": "authoritative_primary", "source_title": "BSP Circular No. 1160, Series of 2022, Regulations on Financial Consumer Protection", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the originating institution's primary responsibility, the provisional credit and hold protections, the three banking day notice, reversal or making the provisional credit final, the open list of liability-weighing factors, and the account-number-matching safe harbor at MORB sec 1003." }, { "source_url": "https://www.bsp.gov.ph/Regulations/MORPS/MORPS.pdf", "source_class": "authoritative_primary", "source_title": "BSP Manual of Regulations for Payment Systems, updated December 2025", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms sec 1104.3.e, the sec 1105.22 liability for failing to hold funds including restitution, the sec 1105.23 administrative action for improper holding, and the sec 1105.27 safe harbor; these rules apply to every account to account transfer, PESONet included." } ] }, "rail_name": "Philippines PESONet", "governing_authority": "Bangko Sentral ng Pilipinas", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "judgement", "label": "your bank's own terms", "needs": "whose terms decide it: the bank's, the participant's or the scheme's", "detail": "There is no Philippine equivalent here of a fixed consumer liability cap; the outcome depends on the institution's assessment and, if the customer disputes it, on escalation to the BSP or the courts.", "from": "caveat" }, { "kind": "judgement", "label": "a legal question", "needs": "a legal question Orca does not answer", "detail": "There is no Philippine equivalent here of a fixed consumer liability cap; the outcome depends on the institution's assessment and, if the customer disputes it, on escalation to the BSP or the courts.", "from": "caveat" } ] }, { "uid": "ph-pesonet:limits", "id": "limits", "rail": "ph-pesonet", "kind": "rail-fact", "facet": "limits", "name": "What amount limits apply to PESONet, and who sets them?", "statement": "PESONet sets no scheme-wide minimum or maximum amount. Both the BSP and PPMI say so in public, and PPMI adds that each bank or e-money issuer may impose its own per transaction or daily limits depending on the channel. In practice the ceilings a customer meets are their institution's channel limits and, behind them, the institution's prefunded position at the BSP for the cycle. The PESONet rulebook is not public, so the absence of a scheme limit rests on those two public statements rather than on rule text.", "details": [ { "label": "No scheme limit", "value": "PPMI states that PESONet itself imposes no minimum or maximum amount. The BSP's comparison of transfer methods lists PESONet, like checks, as having no limit, against InstaPay's PHP 50,000.", "citation": "PPMI PESONet page (philpayments.org.ph/pesonet, read 2026-09-18), key features and limits and fees; BSP InstaPay FAQ (March 2021), comparison table", "rests_on": "guidance" }, { "label": "Institution and channel limits", "value": "The customer's bank or e-money issuer may set per transaction or daily limits, and they may differ by channel. These are commercial choices and are not collected in any public list read here.", "citation": "PPMI PESONet page (read 2026-09-18), key features and limits and fees", "rests_on": "guidance" }, { "label": "Suited to larger and bulk payments", "value": "PPMI and the BSP present PESONet as the route for higher value, bulk and non-urgent payments such as payroll, supplier payments and government disbursements, and as an electronic alternative to checks.", "citation": "PPMI PESONet page (read 2026-09-18), overview and when to use; BSP PESONet FAQ (2018), prospective use cases", "rests_on": "guidance" }, { "label": "Funding acts as a limit per cycle", "value": "Each participant must prefund its BSP settlement account for its net obligation in every cycle; if it cannot, all of its instructions are dropped from that cycle. A very large payment therefore depends on the sending institution having funded for it.", "citation": "MORPS (updated December 2025) sec. 701.2 items c and f(2)(c) (from BSP Circular No. 1135, 2022)", "rests_on": "law" }, { "label": "Large amounts still meet AML checks", "value": "Each institution screens and monitors its own customer's transactions for anti-money laundering purposes and may add procedures before sending or crediting. [Inference: a large PESONet transfer may be delayed by those checks even without a scheme limit.]", "citation": "BSP Circular No. 980 (2017), specific rules item c(1), c(2) and c(4) (now MORPS sec. 201.4)", "rests_on": "law" }, { "label": "Where a limit would be written", "value": "Any ACH-level cap would be in the PESONet rulebook, which PPMI keeps and shows to the BSP on request but does not publish. The BSP's return rules list an amount over the allowable limit as one reason a receiving institution may return a transfer.", "citation": "MORPS sec. 1203.4 (from BSP Circular No. 1223, 2025); BSP Circular No. 1195 (2024), glossary, returned transaction", "rests_on": "law" } ], "exceptions": [ "An institution may set a lower limit, per transaction or per day, and may set different limits by channel (PPMI PESONet page, read 2026-09-18).", "Direct Debit PH, a separate stream launched 2026-07-29, lets payers set a maximum amount in each mandate; that is not a PESONet credit transfer limit (GMA News, 2026-07-29; BusinessWorld, 2026-07-30)." ], "applies_to": "each PESONet credit transfer sent from a Philippine bank or e-money account", "caveat": "'No limit' means no scheme cap, not that a customer can send any amount. The sending institution's own limits, and its funding for the cycle, decide what actually goes through.", "related": [ "ph-pesonet:settlement", "ph-pesonet:hours", "ph-instapay:limits", "ph-pesonet:participants" ], "basis": { "sources": "PPMI PESONet page (https://www.philpayments.org.ph/pesonet), read 2026-09-18; BSP InstaPay FAQ, March 2021 (https://www.bsp.gov.ph/PaymentAndSettlement/FAQ_Instapay.pdf), comparison table; BSP PESONet FAQ, 2018 (https://www.bsp.gov.ph/PaymentAndSettlement/FAQ_PESONet.pdf); BSP Manual of Regulations for Payment Systems, updated December 2025, secs. 201.4, 701.2, 1203.4; BSP Circular No. 980 (2017); BSP Circular No. 1195 (2024). Read 2026-09-18. The two no-limit statements are from different organisations (PPMI and BSP) in their own wording. The PESONet rulebook is not published, so this record is flagged primary_not_public.", "confidence": "medium" }, "currency": { "effective_since": "2021-03-16", "effective_note": "The date is that of the earliest source read that states no PESONet limit (BSP InstaPay FAQ, modified 2021-03-16), not a confirmed start date; no source read gives the date from which PESONet has had no scheme limit. Current on PPMI's page read 2026-09-18.", "source_edition": "PPMI PESONet page as read 2026-09-18; BSP InstaPay FAQ March 2021", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "primary_not_public": true, "corroboration": [ { "source_url": "https://www.philpayments.org.ph/pesonet", "source_class": "public_primary", "source_title": "PPMI PESONet page, philpayments.org.ph, read 2026-09-18", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms PESONet imposes no scheme-wide minimum or maximum amount and that the provider may impose its own per transaction or daily limits by channel, in PPMI's own wording." }, { "source_url": "https://www.bsp.gov.ph/PaymentAndSettlement/FAQ_Instapay.pdf", "source_class": "public_primary", "source_title": "BSP InstaPay Frequently Asked Questions, March 2021, comparison table", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Independent second source, different organisation and host from the PPMI page. The BSP's own transfer-method comparison table lists PESONet with no limit against InstaPay's PHP 50,000, confirming the no-scheme-limit claim from the regulator's side." } ] }, "rail_name": "Philippines PESONet", "governing_authority": "Bangko Sentral ng Pilipinas", "snapshot": "2026-09-18", "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "not_public", "label": "the operator's own text", "needs": "what the operator's own text says, which Orca has not read", "detail": "Bangko Sentral ng Pilipinas's own text is not the source for this rail fact: it is not public, or not under terms Orca can use. It rests on 2 named public sources, so a term set by agreement rather than by a published rule is not Orca's to state.", "from": "currency.primary_not_public" } ] }, { "uid": "ph-pesonet:messages", "id": "messages", "rail": "ph-pesonet", "kind": "rail-fact", "facet": "messages", "name": "What message standard does PESONet use, and what must a payment carry?", "statement": "The PESONet file and message specifications are not public; they are in the rulebooks PPMI maintains and shows the BSP on request. PESONet works in batches: participants send payment instructions to the switch, which settles the netted result in the Peso RTGS and then releases an inward clearing file to each receiving institution. Circular No. 1223 (2025) requires all retail payment systems to move to ISO 20022, with structured data, ISO external codes, an end to end reference and one time convention, and to retire translators within two years of taking effect. The only PESONet messages the BSP documents are the settlement legs between PCHC and the RTGS.", "details": [ { "label": "Where the specification lives", "value": "Rulebooks, including message specifications, protocols and exception handling, are the payment system management body's responsibility; the BSP may ask to review them and PPMI must update them yearly. No PESONet file or message specification is published on PPMI's or the BSP's site.", "citation": "MORPS (updated December 2025) sec. 1203.4 (from BSP Circular No. 1223, 2025); PPMI PESONet page and BSP NRPS regulatory framework page, both read 2026-09-18", "rests_on": "law" }, { "label": "Batch files, one payer to many payees", "value": "PESONet moves money from one payer account to one or several payee accounts, processes instructions in bulk, and delivers each cycle's credits to receiving institutions as an inward clearing file released after settlement.", "citation": "BSP PESONet FAQ (2018), what is PESONet and key feature 1; BSP PESONet 3MBS FAQ (as of 2024-08-27), question 1", "rests_on": "guidance" }, { "label": "ISO 20022 is now required", "value": "Participants must use ISO 20022 and the message that fits each business function, with ISO external codes; each message must carry party names and a minimum structured address, account and institution identifiers, a reference kept intact end to end, and complete remittance data or a pointer to it, in one time convention (UTC or local with offset).", "citation": "MORPS secs. 1203.2 and 1203.3 items a(1) to a(5)", "rests_on": "law" }, { "label": "The transition clock", "value": "Two years from Circular No. 1223 taking effect to retire translators and adaptors and harmonise every in-scope use case, with at least one use case in year one; an industry team headed by PPMI, with PCHC and BancNet as technical experts, runs it, and enforcement waits until the transition ends. [Inference: some PESONet flows use non-ISO formats or translators today.]", "citation": "BSP Circular No. 1223 (2025), sec. 3, consolidated as MORPS sec. 1203.7", "rests_on": "law" }, { "label": "Settlement legs with the RTGS", "value": "PCHC submits PESONet's batch net result to the Peso RTGS as an institution to institution credit transfer (pacs.009) and receives a status report (pacs.002) with credit or debit notifications. The BSP rulebook says only InstaPay, not PESONet, currently receives the settlement account balance report (camt.052).", "citation": "BSP Philippine Rulebook on Payments and Settlements (ISO 20022), v1.6 (2026-05-29), secs. 4.17, 4.25 and 4.26 and the PESONet business scenarios", "rests_on": "law" }, { "label": "What the sender must supply", "value": "PPMI lists the recipient's bank or e-money issuer, the account name and number, the amount, and a reference or purpose where the institution asks for one.", "citation": "PPMI PESONet page (read 2026-09-18), FAQ on details needed", "rests_on": "guidance" }, { "label": "Records and transparency", "value": "Participants must keep transaction records for at least five years and be able to retrieve payment status; receiving institutions must show end users at least the sender's details and a reference number.", "citation": "MORPS sec. 1203.3 items b(1) and b(2)", "rests_on": "law" } ], "exceptions": [ "Switch operators must pre-validate for interoperability, while participants answer for accurate and complete data (MORPS sec. 1203.3, closing paragraph).", "The reject and return codes on PESONet are in the private rulebooks; the BSP rulebook's code annexes are RTGS codes (BSP ISO 20022 rulebook v1.6, sec. 1 scope).", "Account name is listed by PPMI as a detail to supply, but institutions may credit on account number alone (BSP Circular No. 980, specific rules item c(3))." ], "applies_to": "files and messages exchanged between PESONet participants and PCHC, and between PCHC and the BSP's Peso RTGS", "caveat": "Do not assume PESONet today uses ISO 20022 end to end; the BSP's 2025 mandate exists because retail systems did not. The current format is unknown.", "related": [ "ph-pesonet:settlement", "ph-pesonet:return", "ph-instapay:messages", "ph-pesonet:participants" ], "basis": { "sources": "BSP Circular No. 1223, 2025, corrected copy (https://www.bsp.gov.ph/Regulations/Issuances/2025/1223(corrected%20copy).pdf); BSP Manual of Regulations for Payment Systems, updated December 2025 (https://www.bsp.gov.ph/Regulations/MORPS/MORPS.pdf), sec. 1203; BSP ISO 20022 rulebook v1.6 (https://www.bsp.gov.ph/PaymentAndSettlement/ISO20022-Rulebook.pdf); BSP PESONet FAQ, 2018; BSP PESONet 3MBS FAQ as of 2024-08-27; PPMI PESONet page read 2026-09-18; BSP Circular No. 980 (2017). Read 2026-09-18. The PESONet specification is not published, so this record is flagged primary_not_public.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_note": "Circular No. 1223 takes effect 15 days after publication; MORPS dates it 2025-11-28. Full compliance due two years after effectivity, about late 2027 [Inference]. The current PESONet format is unknown.", "source_edition": "BSP Circular No. 1223 corrected copy; MORPS updated December 2025; BSP ISO 20022 rulebook v1.6; PPMI PESONet page as read 2026-09-18", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "primary_not_public": true, "corroboration": [] }, "rail_name": "Philippines PESONet", "governing_authority": "Bangko Sentral ng Pilipinas", "snapshot": "2026-09-18", "source_class": null, "effective_status": "draft", "effective_status_reason": null, "boundaries": [ { "kind": "not_public", "label": "the operator's own text", "needs": "what the operator's own text says, which Orca has not read", "detail": "Bangko Sentral ng Pilipinas's own text is not the source for this rail fact: it is not public, or not under terms Orca can use. It rests on 0 named public sources, so a term set by agreement rather than by a published rule is not Orca's to state.", "from": "currency.primary_not_public" } ] }, { "uid": "ph-pesonet:participants", "id": "participants", "rail": "ph-pesonet", "kind": "rail-fact", "facet": "participants", "name": "Who takes part in PESONet, and in what roles?", "statement": "PESONet was the first automated clearing house under the BSP's National Retail Payment System: a binding multilateral agreement among its participants for batch credit transfers, governed by PPMI as the industry payment system management body, operated by the Philippine Clearing House Corporation as clearing switch operator, settled in the BSP's Peso RTGS and overseen by the BSP. At 2026-08-31 it had 126 participants, all listed as able to send and receive, across universal and commercial banks, thrift banks, rural banks, digital banks and e-money issuers. Participation is direct, or indirect through a sponsoring direct participant that clears and settles for the sponsored institution and answers for its compliance.", "details": [ { "label": "Participant count and mix", "value": "126 participants at 2026-08-31: rural banks 45, universal and commercial banks 40, thrift banks 21, e-money issuers and other non-bank institutions 14, digital banks 6. The list shows every participant as sender and receiver.", "citation": "BSP, PESONet ACH Participants, source Philippine Clearing House Corporation, as of 2026-08-31 (bsp.gov.ph/PaymentAndSettlement/PESONet Participants.pdf)", "rests_on": "guidance" }, { "label": "Rule-maker: PPMI", "value": "The Philippine Payments Management, Inc. was recognised by the Monetary Board in January 2018 as the payment system management body under the NRPS framework and was later accredited under the National Payment Systems Act. Every clearing participant must follow the rules and policies the PSMB sets, and qualified direct participants are expected to be members.", "citation": "BSP Circular Letter CL-2018-005 (2018-01); BSP Circular No. 980 (2017), Appendix, parts A.1.d and B.1.d; BSP Circular Letter CL-2020-036 (title only; scanned, not read)", "rests_on": "law" }, { "label": "Operator: PCHC", "value": "The Philippine Clearing House Corporation operates PESONet and holds BSP authority as operator of a designated payment system; PESONet was designated a Prominently Important Payment System in 2022. The BSP's 2018 FAQ described PCHC's role as a two-year transitional designation; PCHC remains the operator named in the 2022 designation and on the 2026 participant list. The switch operator may not take part in governing the system.", "citation": "BSP Circular Letter CL-2022-055 (2022-07); BSP Memorandum No. M-2022-031; BSP PESONet FAQ (2018), clearing switch operator; BSP Circular No. 980, subsec. on NRPS key principles (now MORPS sec. 201.3)", "rests_on": "law" }, { "label": "Who can be a direct participant", "value": "Four things make an institution a direct clearing participant: it clears through an ACH and carries final responsibility for the obligations that clearing creates; it has a way to settle, either its own BSP settlement account with RTGS membership or a sponsor that has one; it holds customer money in bank or e-money accounts; and the BSP has licensed it to provide electronic payment services.", "citation": "BSP Circular No. 980, Annex A, definition of direct clearing participant; BSP Circular No. 1033 (2019), electronic payment and financial services approval (title as listed on the BSP NRPS page)", "rests_on": "law" }, { "label": "Direct or sponsored", "value": "An institution may join as a direct clearing participant, or, if it does not qualify, be sponsored into clearing by a direct participant that clears and settles on its behalf. The sponsor is accountable for the sponsored institution's compliance with the PSMB and ACH rules. Institutions that meet the direct criteria approach PPMI or the PESONet working group to join.", "citation": "BSP PESONet FAQ (2018), how a BSFI can join", "rests_on": "guidance" }, { "label": "Only accounts at supervised institutions", "value": "A transfer is in scope only when both payer and payee hold accounts at BSP-supervised institutions licensed for electronic payment services, and only in pesos within the Philippines.", "citation": "BSP Circular No. 980, Appendix, part B.1.a(ii); BSP Circular No. 980, subsec. on purpose and scope (now MORPS sec. 201.2)", "rests_on": "law" }, { "label": "Obligations of participants in a designated system", "value": "Because PESONet is a designated system, its participants must answer BSP surveys and information requests, open relevant records to BSP examiners, take part in operator tests, follow the governing body's rules, and keep the rules they agree to consistent with the international principles for financial market infrastructures.", "citation": "BSP Memorandum No. M-2022-031, part 1", "rests_on": "law" }, { "label": "One stream, one ACH, open access", "value": "Each payment stream may fall under only one ACH, bilateral clearing outside the NRPS structure is not allowed, and any qualified institution may join. [Inference: Direct Debit PH, launched 2026-07-29 and chaired from the PESONet side, runs under its own ACH agreement, since BusinessWorld reports a separate Direct Debit PH ACH agreement as a condition of joining.]", "citation": "BSP Circular No. 980, Appendix, parts A.1.e, C.1.b and C.1.c; BSP Memorandum No. M-2018-012, item 1; BusinessWorld, 2026-07-30", "rests_on": "law" } ], "exceptions": [ "Corporate cash management arrangements are allowed alongside the ACH only without exclusivity terms that make it hard or costly for recipients to receive from other institutions (BSP Memorandum No. M-2018-012, item 1).", "A July 2026 report quotes a PESONet official as putting membership at over 128, against 126 on the BSP list as of 2026-08-31 (GMA News, 2026-07-29) [Unverified: the difference is not explained]." ], "applies_to": "institutions that send, receive, operate or govern PESONet transfers in the Philippines", "caveat": "The participant list changes monthly. Check the current BSP list before stating that a given bank or wallet offers PESONet, and remember a participant's customers may still meet channel or product restrictions.", "related": [ "ph-pesonet:settlement", "ph-pesonet:messages", "ph-pesonet:hours", "ph-instapay:participants", "ph-pesonet:limits", "ph-pesonet:decision-points" ], "basis": { "sources": "BSP PESONet participant list as of 2026-08-31 (https://www.bsp.gov.ph/PaymentAndSettlement/PESONet%20Participants.pdf); BSP Circular No. 980, 2017 (https://www.bsp.gov.ph/Regulations/Issuances/2017/c980.pdf), with Appendix and Annex A; Circular Letters CL-2018-005 and CL-2022-055 (https://www.bsp.gov.ph/Regulations/Issuances/2022/CL-2022-055.pdf); Memoranda M-2018-012 and M-2022-031; BSP PESONet FAQ, 2018; BSP PESONet 3MBS FAQ as of 2024-08-27 (first ACH under NRPS); GMA News, 2026-07-29; BusinessWorld, 2026-07-30. Read 2026-09-18. CL-2020-036 is scanned and was not read.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_note": "Counts are as of 2026-08-31 and change monthly. Governance roles date from Circular No. 980 (2017) and CL-2018-005; PCHC's designation as operator from CL-2022-055 (July 2022).", "source_edition": "BSP PESONet participant list as of 2026-08-31; BSP Circular No. 980; CL-2022-055; M-2022-031", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.bsp.gov.ph/PaymentAndSettlement/PESONet%20Participants.pdf", "source_class": "public_primary", "source_title": "BSP PESONet ACH Participants list, source Philippine Clearing House Corporation, as of 31 August 2026", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the count and category breakdown exactly: 126 total, all listed sender/receiver, 40 universal and commercial banks, 21 thrift banks, 45 rural banks, 6 digital banks, 14 e-money and other non-bank institutions." }, { "source_url": "https://www.bsp.gov.ph/Regulations/Issuances/2017/c980.pdf", "source_class": "authoritative_primary", "source_title": "BSP Circular No. 980, Series of 2017, National Retail Payment System Framework", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the Annex A definition of direct clearing participant, the sponsorship structure, and the one-ACH-per-stream rule in the Appendix." } ] }, "rail_name": "Philippines PESONet", "governing_authority": "Bangko Sentral ng Pilipinas", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "ph-pesonet:recall", "id": "recall", "rail": "ph-pesonet", "kind": "rail-fact", "facet": "recall", "name": "Can a sender cancel or recall a PESONet transfer after it is sent?", "statement": "PPMI tells customers that a processed PESONet transfer is generally final and cannot be reversed, and no public rule gives a sender a recall right. The routes that exist are the same BSP rules that govern every account to account transfer in the Philippines: a sender's own keying error goes to the sender's institution, which with the receiving institution must try to recover it, and in practice needs the receiver's consent; an unauthorized or scam transfer can trigger a hold of up to 30 days on the funds and, if the claim holds, their return. The only PESONet-specific difference is timing: because transfers wait for a batch, a sender who acts before the bank's cut-off may be able to stop a transfer that has not yet been submitted, at the bank's discretion.", "details": [ { "label": "Generally final once processed", "value": "PPMI's answer to whether a PESONet transfer can be cancelled is that once processed it is generally final and cannot be reversed. No BSP or PPMI page read here describes a scheme cancellation or recall request.", "citation": "PPMI PESONet page (philpayments.org.ph/pesonet, read 2026-09-18), FAQ on cancelling a transfer", "rests_on": "guidance" }, { "label": "Before the batch", "value": "A transfer waits at the sending bank until that bank's cut-off for the next cycle. [Inference: whether a customer can withdraw it in that window is the bank's own policy; PPMI's wording 'once processed' implies it may be possible before processing. No public rule addresses it.]", "citation": "PPMI PESONet page (read 2026-09-18), batch cycles and cancellation FAQ; BSP PESONet 3MBS FAQ (as of 2024-08-27), cycle table", "rests_on": "practice" }, { "label": "Wrong account or wrong amount", "value": "A keying error by the sender is an erroneous transaction. The sender reports it at once to their own institution, which informs the receiving institution, and both make reasonable efforts to recover the money under BSP rules and industry conventions. Because institutions may credit on the account number alone and are not liable for relying on it, recovery depends on the receiver.", "citation": "BSP Circular No. 1160 (2022), MORB/MORNBFI sec. 1003, erroneous transactions; BSP Circular No. 980 (2017), specific rules item c(3) (now MORPS sec. 201.4)", "rests_on": "law" }, { "label": "Unauthorized or scam transfers", "value": "On a complaint through the sending institution's round the clock fraud channel, or a fraud system flag, the institutions can hold the disputed funds for an initial 5 days, extend by up to 25 more on reasonable grounds, verify together, and return the funds to the source institution if verification or the payee's written waiver supports the claim. The rules cover every account to account transfer, PESONet included.", "citation": "MORPS (updated December 2025) secs. 1105.2, 1105.5 to 1105.11 and 1105.19 (from BSP Circular No. 1215, 2025)", "rests_on": "law" }, { "label": "The payee can object", "value": "The payee may ask at any time to have a hold lifted, with evidence the transfer was legitimate, and the institution must release the funds early if the evidence holds up.", "citation": "MORPS sec. 1105.14", "rests_on": "law" } ], "exceptions": [ "The anti-scam hold does not apply to erroneous transactions (MORPS sec. 1105.2).", "Funds already withdrawn or moved on cannot be held; the institutions report what remains (MORPS sec. 1105.8).", "The PESONet operating guidelines may hold an interbank procedure for erroneous transfers; they are not public [Unverified]." ], "applies_to": "PESONet transfers a sender wants back because of a keying error, an unauthorized debit or a scam", "caveat": "A PESONet payee is credited only after settlement and up to hours after the sender acts, so a scam victim who reports before the batch or before the credit has the best chance that the funds are still there to hold [Inference].", "related": [ "ph-pesonet:finality", "ph-pesonet:return", "ph-pesonet:hours", "ph-instapay:recall", "ph-pesonet:liability", "ph-pesonet:consumer-law", "ph-pesonet:decision-points" ], "basis": { "sources": "PPMI PESONet page (https://www.philpayments.org.ph/pesonet), read 2026-09-18; BSP PESONet 3MBS FAQ as of 2024-08-27; BSP Circular No. 1160, 2022 (https://www.bsp.gov.ph/Regulations/Issuances/2022/1160.pdf), MORB sec. 1003; BSP Circular No. 980 (2017); BSP Manual of Regulations for Payment Systems, updated December 2025 (https://www.bsp.gov.ph/Regulations/MORPS/MORPS.pdf), secs. 201.4 and 1105. Read 2026-09-18. RA 12010 itself was not read.", "confidence": "medium" }, "currency": { "effective_since": "2025-06-10", "effective_note": "The hold and verification rules are Circular No. 1215, dated 2025-06-10 per MORPS; the erroneous transaction route is Circular No. 1160 (2022). Effectivity dates are not established here [Unverified].", "source_edition": "MORPS updated December 2025; BSP Circulars 980, 1160, 1215; PPMI PESONet page as read 2026-09-18", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.bsp.gov.ph/Regulations/MORPS/MORPS.pdf", "source_class": "authoritative_primary", "source_title": "BSP Manual of Regulations for Payment Systems, updated December 2025", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the 5 plus 25 day hold structure and 30 day cap at secs 1105.5 to 1105.11, and the payee's right to challenge a hold at sec 1105.14; these rules apply to every account to account transfer, PESONet included." }, { "source_url": "https://www.philpayments.org.ph/pesonet", "source_class": "public_primary", "source_title": "PPMI PESONet page, philpayments.org.ph, read 2026-09-18", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms in PPMI's own words that once processed a PESONet transfer is generally final and cannot be reversed, and that no scheme cancellation or recall request is described." } ] }, "rail_name": "Philippines PESONet", "governing_authority": "Bangko Sentral ng Pilipinas", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "ph-pesonet:refund", "id": "refund", "rail": "ph-pesonet", "kind": "rail-fact", "facet": "refund", "name": "Is there a refund right on PESONet, and who pays the fees?", "statement": "PESONet is a credit push with no refund right: a transfer the sender authorized and the payee received cannot be claimed back from the rail because the purchase went wrong, and the BSP's redress standards leave disputes over goods and services outside their scope. The fixed rules are about failure and fees. A failed transfer comes back within two hours of the settlement report, the sender pays no fee for a failed transfer or one lost to an outage, the recipient pays nothing, and since Circular No. 1238 sending fees must be cost based. The freeze on PESONet and InstaPay fee increases was lifted with that circular.", "details": [ { "label": "No refund for the underlying purchase", "value": "The redress standards apply to the transfer, and expressly exclude dispute resolution about delivery of the goods or services behind it.", "citation": "MORPS (updated December 2025) sec. 1104.2 (from BSP Circular No. 1195, 2024)", "rests_on": "law" }, { "label": "Money and fees back when the transfer fails", "value": "Rejected and returned PESONet transfers, double debits and failures from the sending institution's own control lapse are restored within two hours of the settlement report; returnable fees go back on the same clock, and no fee may be charged for an unsuccessful transfer or one lost to an outage. See ph-pesonet:return.", "citation": "MORPS secs. 1104.3.b and 1104.3.c", "rests_on": "law" }, { "label": "The recipient pays nothing", "value": "The receiving institution may not charge for crediting, and for person to person transfers the recipient must get the full amount without deduction. The BSP's PESONet FAQ lists full receipt by the recipient among the changes PESONet brought. [Unverified: whether the general Circular No. 980 wording still governs non person to person PESONet use cases after Circular No. 1238.]", "citation": "BSP Circular No. 1238 (2026-06-17), sec. 2, amending MORPS sec. 201 item b(1)(d); BSP Circular No. 980 (2017), item b(1)(c); BSP PESONet FAQ (2018), expected change 4", "rests_on": "law" }, { "label": "What a sender may be charged", "value": "Sending fees must rest on the institution's own analysis of its costs, stay below over the counter fees, and not load one group of customers with the cost of serving another; the fee to send to another institution should not differ materially from the fee within the institution plus the directly attributable switch cost.", "citation": "BSP Circular No. 1238, sec. 2, MORPS sec. 201 item b(1)(a) to (c), and Appendix 201-2", "rests_on": "law" }, { "label": "The fee freeze has been lifted", "value": "The moratorium on PESONet and InstaPay person to person fee increases, kept in place by M-2023-037, was lifted by Monetary Board decision of 2026-06-04, effective together with Circular No. 1238.", "citation": "BSP Memorandum No. M-2026-025 (June 2026); BSP Memorandum No. M-2023-037 (December 2023)", "rests_on": "law" }, { "label": "Fees vary by institution", "value": "PPMI tells customers that PESONet fees differ by institution and channel, that some offer caps or promotions, and to check the official fee schedule of their bank or e-money issuer.", "citation": "PPMI PESONet page (philpayments.org.ph/pesonet, read 2026-09-18), limits and fees", "rests_on": "guidance" } ], "exceptions": [ "An unauthorized or fraudulent transfer is a liability case, not a refund: after investigation the institution must reverse it or make a provisional credit permanent (BSP Circular No. 1160, MORB sec. 1003); see ph-pesonet:liability.", "Funds recovered through the anti-scam hold go back to the source institution as recovered funds, not as a refund right (MORPS sec. 1105.19).", "Direct Debit PH, a separate stream, has its own mandate cancellation safeguards; they are not PESONet refund rights (GMA News, 2026-07-29)." ], "applies_to": "PESONet transfers between Philippine bank and e-money accounts, as to the return of money and fees; not the sale behind the payment", "caveat": "A PESONet payment used to pay a supplier or a bill is not reversible through the rail. The payer's remedy for a bad purchase is against the seller.", "related": [ "ph-pesonet:return", "ph-pesonet:recall", "ph-instapay:refund", "ph-pesonet:liability", "ph-pesonet:consumer-law" ], "basis": { "sources": "BSP Manual of Regulations for Payment Systems, updated December 2025 (https://www.bsp.gov.ph/Regulations/MORPS/MORPS.pdf), secs. 1104.2, 1104.3, 1105.19; BSP Circular No. 1238, 2026-06-17 (https://www.bsp.gov.ph/Regulations/Issuances/2026/1238.pdf); BSP Memoranda M-2023-037 and M-2026-025 (https://www.bsp.gov.ph/Regulations/Issuances/2026/M-2026-025.pdf); BSP Circular No. 980 (2017); BSP PESONet FAQ, 2018; PPMI PESONet page, read 2026-09-18. Read 2026-09-18.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_note": "Recipient-pays-nothing dates from Circular No. 980 (2017); failure and fee rules from the Circular No. 1195 compliance date, 2024-12-31. Circular No. 1238 and the end of the fee moratorium take effect 15 days after that circular's publication; the publication date is not established here [Unverified].", "source_edition": "MORPS updated December 2025; BSP Circular No. 1238 (2026); M-2026-025; PPMI PESONet page as read 2026-09-18", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.bsp.gov.ph/Regulations/MORPS/MORPS.pdf", "source_class": "authoritative_primary", "source_title": "BSP Manual of Regulations for Payment Systems, updated December 2025", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the goods-and-services carve-out at sec 1104.2, and the two hour money-back and no-fee-for-failure rules at secs 1104.3.b and 1104.3.c." }, { "source_url": "https://www.bsp.gov.ph/Regulations/Issuances/2026/1238.pdf", "source_class": "authoritative_primary", "source_title": "BSP Circular No. 1238, Series of 2026, signed 17 June 2026, amending the National Retail Payment System Framework", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms MB Resolution No. 498 dated 4 June 2026, the P2P recipient-pays-nothing rule, and the cost-based, fair, below-OTC pricing rules with the cost categories in Appendix 201-2." }, { "source_url": "https://www.bsp.gov.ph/Regulations/Issuances/2026/M-2026-025.pdf", "source_class": "authoritative_primary", "source_title": "BSP Memorandum No. M-2026-025, June 2026, lifting the fee moratorium", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the Monetary Board lifted the InstaPay and PESONet fee moratorium under Resolution No. 498 of 4 June 2026, effective concurrently with Circular No. 1238 of 17 June 2026." } ] }, "rail_name": "Philippines PESONet", "governing_authority": "Bangko Sentral ng Pilipinas", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "ph-pesonet:return", "id": "return", "rail": "ph-pesonet", "kind": "rail-fact", "facet": "return", "name": "What happens when a PESONet transfer does not reach the payee, and how fast does the money come back?", "statement": "A PESONet transfer that the switch rejects, or that the receiving institution returns uncredited, must be back in the sender's account within two hours of the sending institution receiving the switch's settlement report for that cycle. The same two hours apply to a double debit and to a failure caused by a lapse in the sending institution's own controls. Unlike InstaPay's one hour rule, the batch rule is timed from the settlement report, not from the customer's instruction, and it does not name timed-out transfers. Unauthorized and mistaken transfers are outside it. The reason codes are in the ACH's private guidelines.", "details": [ { "label": "Rejected by the switch", "value": "A transfer the clearing switch operator refuses under the ACH guidelines is never credited. The BSP's own rules add one certain case: if a participant fails to fund its BSP account for a cycle, the switch drops every one of its instructions from that cycle's net results.", "citation": "BSP Circular No. 1195 (2024), glossary, rejected transaction; MORPS (updated December 2025) sec. 701.2 item f(2)(c)", "rests_on": "law" }, { "label": "Returned by the receiving institution", "value": "The receiving institution may send a transfer back uncredited. The BSP's examples are open ended: a problem with the payee's account such as a restriction or a number that does not exist, an amount above what is allowed, or concerns about fraud, money laundering or terrorist financing.", "citation": "BSP Circular No. 1195, glossary, returned transaction", "rests_on": "law" }, { "label": "The two hour clock", "value": "For batch clearing and settlement, the sending institution must restore the debited amount within two hours of receiving the switch's settlement report, for rejected and returned transfers, for a transfer debited more than once, and for an unsuccessful transfer caused by its own control lapse.", "citation": "MORPS sec. 1104.3.b (from BSP Circular No. 1195)", "rests_on": "law" }, { "label": "Fees come back too", "value": "Where the ACH guidelines require a fee to be returned, it goes back on the same two hour clock, and no fee may be charged for an unsuccessful transfer or one lost to an outage of the switch or a participant.", "citation": "MORPS sec. 1104.3.c", "rests_on": "law" }, { "label": "Status notices", "value": "The sending institution must keep the sender informed of the true status of the transfer, with updates until it is resolved, in wording common to all participants.", "citation": "MORPS sec. 1104.3.a, item (1)", "rests_on": "law" }, { "label": "Reason codes are not public", "value": "The rejection reasons, return reasons and the codes that carry them are defined in the PESONet operating guidelines and PSMB rulebooks, which PPMI keeps and does not publish.", "citation": "MORPS sec. 1203.4 (from BSP Circular No. 1223, 2025)", "rests_on": "law" } ], "exceptions": [ "The return rules do not apply to unauthorized or erroneous transactions (MORPS sec. 1104.3.b, final paragraph); see ph-pesonet:recall and ph-pesonet:liability.", "Timed-out transfers are named in the one hour instant payment rule but not in the batch rule; how a timed-out PESONet transfer is refunded is not stated in the public text (MORPS sec. 1104.3.b) [Inference: the batch design, where settlement precedes release, may make timeouts rare].", "Participants had until 2024-12-31 to comply with Circular No. 1195 and to revise the ACH guidelines (BSP Circular No. 1195, sec. 3)." ], "applies_to": "PESONet transfers that are rejected, returned or otherwise not credited, and double debits, between the sender's institution and the sender", "caveat": "Two hours from the settlement report can mean the same afternoon or the next banking day, depending on the cycle; a sender's money is not back within two hours of their instruction.", "related": [ "ph-pesonet:finality", "ph-pesonet:settlement", "ph-pesonet:hours", "ph-instapay:return", "ph-pesonet:recall", "ph-pesonet:refund", "ph-pesonet:messages" ], "basis": { "sources": "BSP Circular No. 1195, 2024 (https://www.bsp.gov.ph/Regulations/Issuances/2024/1195.pdf), glossary and sec. 1104.3, read in full; BSP Manual of Regulations for Payment Systems, updated December 2025 (https://www.bsp.gov.ph/Regulations/MORPS/MORPS.pdf), secs. 701.2, 1104.3, 1203.4. Read 2026-09-18.", "confidence": "high" }, "currency": { "effective_since": "2024-12-31", "effective_note": "Circular No. 1195 took effect on publication in June 2024; 2024-12-31 is its compliance deadline for participants, switch operators and revised ACH guidelines. The exact publication date is not established here.", "source_edition": "BSP Circular No. 1195 (2024); MORPS updated December 2025", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.bsp.gov.ph/Regulations/MORPS/MORPS.pdf", "source_class": "authoritative_primary", "source_title": "BSP Manual of Regulations for Payment Systems, updated December 2025", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the two hour refund clock for batch payments at MORPS sec 1104.3.b, timed from the settlement report rather than the instruction, its extension to double debits and control-lapse failures, the fee return rule at sec 1104.3.c, and that reason codes sit in the private ACH operating guidelines per sec 1203.4; confirms the switch drops an unfunded participant's instructions from a cycle at sec 701.2 item f(2)(c)." }, { "source_url": "https://www.bsp.gov.ph/Regulations/Issuances/2024/1195.pdf", "source_class": "authoritative_primary", "source_title": "BSP Circular No. 1195, Series of 2024, Consumer Redress Mechanism Standards for Account-to-Account Electronic Fund Transfers", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the glossary definitions of rejected and returned transaction, including the open-ended return examples the record lists, and that the return rules exclude unauthorized and erroneous transactions." } ] }, "rail_name": "Philippines PESONet", "governing_authority": "Bangko Sentral ng Pilipinas", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "ph-pesonet:settlement", "id": "settlement", "rail": "ph-pesonet", "kind": "rail-fact", "facet": "settlement", "name": "How and where do PESONet payments settle between institutions?", "statement": "PESONet is a deferred net settlement system with three batch cycles each banking day. The switch, run by the Philippine Clearing House Corporation, nets each cycle's instructions and sends the net result to the BSP's Peso RTGS, where it settles in the participants' prefunded demand deposit accounts. A participant short of funds must top up before the cut-off or within a grace period; if it does not, all its instructions are dropped from that cycle and the net result is recomputed without them. Only after settlement does the switch release the files that let receiving institutions credit their customers.", "details": [ { "label": "Operator and venue", "value": "The Philippine Clearing House Corporation operates PESONet as its clearing switch and holds BSP authority as operator of a designated payment system. Each ACH settles its own clearing results in the BSP's RTGS through its switch; PCHC submits PESONet's batch net result there as an institution to institution credit transfer.", "citation": "BSP Circular Letter CL-2022-055 (2022-07); BSP Circular No. 980 (2017), Appendix, part D item f; BSP Philippine Rulebook on Payments and Settlements (ISO 20022), v1.6 (2026-05-29), secs. 4.25 and 4.26 and the PESONet business scenario", "rests_on": "law" }, { "label": "Prefunded accounts at the BSP", "value": "Each direct participant, or its settlement sponsor, keeps a demand deposit account at the BSP for its net obligations from electronic payments and funds it ahead to cover each cycle, taking into account how many cycles run in a day and longer gaps over weekends and holidays. Instant and batch payments were to use separate accounts; a single account is allowed with prior BSP approval, and PPMI reports PESONet moved to a single account in 2024.", "citation": "MORPS (updated December 2025) sec. 701.2 items a to c and e (from BSP Circulars No. 1000 and No. 1135); PPMI News and Updates page, report of the 2024 annual membership meeting (held 2025-06-16), read 2026-09-18", "rests_on": "law" }, { "label": "How the switch checks funding", "value": "Before the first cycle of the day PCHC records each participant's BSP account balance, and it gives participants timely data on their net obligations against that balance for every cycle so they can add funds in time.", "citation": "MORPS sec. 701.2 items d and f(2)(a) and (b)", "rests_on": "law" }, { "label": "When a participant is short", "value": "A short participant must fund its account before the settlement cut-off or within the grace period the participants agreed. If it misses that, the switch leaves every one of its instructions out of the net results sent to the BSP for that cycle; if the BSP reports a settlement failure, the switch reprocesses and sends a revised net settlement without the short participant. Late funding also draws penalties under the ACH rules.", "citation": "MORPS sec. 701.2 item f(2)(c) to (e) (from BSP Circular No. 1135, 2022)", "rests_on": "law" }, { "label": "Three cycles a day", "value": "PESONet settles three times each banking day, at 10:00, 13:00 and 16:00; the midday cycle was added on 2024-07-08. The first cycle carries what came in after the previous day's last cut-off. See ph-pesonet:hours.", "citation": "BSP PESONet 3MBS FAQ (as of 2024-08-27), questions 2 and 3; PPMI PESONet page (read 2026-09-18), batch cycles", "rests_on": "guidance" }, { "label": "Reserves and surplus funds", "value": "A bank's settlement account counts toward its reserve requirement, and surplus prefunding beyond the highest likely obligation and agreed threshold may be withdrawn if reserves stay whole.", "citation": "MORPS secs. 701.2 item g and 701.4", "rests_on": "law" }, { "label": "What is not public", "value": "The length of the grace period, the penalty scale and the settlement thresholds are in the PESONet ACH rules, which PPMI does not publish. Circular No. 1196 (2024), which amended the settlement guidelines and may concern cycles, is a scanned image and was not read.", "citation": "MORPS secs. 701.2 and 1203.4; BSP NRPS regulatory framework page, issuance list (title of Circular No. 1196)", "rests_on": "law" } ], "exceptions": [ "The RTGS can reject the switch's instruction, for example after the settlement cut-off or with an invalid account (BSP ISO 20022 rulebook v1.6, sec. 4.26).", "The BSP may act against a participant that breaches the settlement arrangement regardless of ACH sanctions (MORPS sec. 701.2, closing paragraph).", "The 2018 BSP FAQ describes PCHC as switch operator for a two-year transitional period and one cycle a day; both statements are out of date (BSP PESONet FAQ, 2018; CL-2022-055; BSP PESONet 3MBS FAQ, 2024)." ], "applies_to": "interbank settlement of obligations arising from PESONet transfers among direct participants and settlement sponsors holding demand deposit accounts at the BSP", "caveat": "A missed funding call by one participant does not stop a cycle; it removes that participant's payments from it. A customer whose bank misses funding sees a delayed or rejected transfer, not a settlement failure.", "related": [ "ph-pesonet:finality", "ph-instapay:settlement", "ph-pesonet:hours", "ph-pesonet:limits", "ph-pesonet:participants" ], "basis": { "sources": "BSP Manual of Regulations for Payment Systems, updated December 2025 (https://www.bsp.gov.ph/Regulations/MORPS/MORPS.pdf), secs. 701 and 1203.4; BSP Circular No. 980 (2017); Circular No. 1135 (2022, https://www.bsp.gov.ph/Regulations/Issuances/2022/1135.pdf); BSP Circular Letter CL-2022-055; BSP ISO 20022 rulebook v1.6 (https://www.bsp.gov.ph/PaymentAndSettlement/ISO20022-Rulebook.pdf); BSP PESONet 3MBS FAQ as of 2024-08-27 (https://www.bsp.gov.ph/PaymentAndSettlement/FAQs_3MBS_of_the_PESONet.pdf); BSP PESONet FAQ 2018; PPMI PESONet page and News and Updates page (https://www.philpayments.org.ph). Read 2026-09-18. Circular No. 1196 has no text layer and was not read.", "confidence": "medium" }, "currency": { "effective_since": "2024-07-08", "effective_note": "Three daily cycles since 2024-07-08 (BSP 3MBS FAQ). The batch settlement rules date from Circular No. 1135 (signed 2022-01-21). What Circular No. 1196 (2024) changed is not established [Unverified].", "source_edition": "MORPS updated December 2025; BSP PESONet 3MBS FAQ as of 2024-08-27; BSP ISO 20022 rulebook v1.6", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.bsp.gov.ph/Regulations/MORPS/MORPS.pdf", "source_class": "authoritative_primary", "source_title": "BSP Manual of Regulations for Payment Systems, updated December 2025", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the prefunded DDA rules at sec 701.2 items a to c and e, the funding-check and drop-out procedure at sec 701.2 item f(2), and the reserve and surplus-withdrawal rule at secs 701.2 item g and 701.4." }, { "source_url": "https://www.philpayments.org.ph/news-and-updates", "source_class": "public_primary", "source_title": "PPMI News and Updates page, report of the 2024 Annual Membership Meeting held 16 June 2025", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms PESONet's 2024 key milestones included the transition to a single DDA and three daily clearing cycles, supporting the record's claim that PESONet moved to a single settlement account in 2024." } ] }, "rail_name": "Philippines PESONet", "governing_authority": "Bangko Sentral ng Pilipinas", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "pix:consumer-law", "id": "consumer-law", "rail": "pix", "kind": "rail-fact", "facet": "consumer-law", "name": "What protects an end user on Pix, and where does the rulebook stop?", "statement": "Pix is unusual among instant rails in building consumer protection into the payment rules rather than leaving it to statute. The protections are mostly preventive: a default ceiling of R$1,000.00 after dark, a limit panel the customer controls inside the same app they pay from, cuts that bite immediately while increases are made to wait a day or two, a freeze the receiving bank must apply the moment suspicious money lands, and a fraud recovery the customer's own bank can open on their complaint. What the rulebook does not do is give the customer a right to be made whole. It allocates loss between banks and stops. Compensation comes from law outside these documents, and even the general customer relationship resolution the BCB relies on for banks does not reach payment institutions, which is what many Pix providers are.", "details": [ { "label": "The rulebook obliges a good experience, in terms", "value": "The Regulamento does not treat user experience as a commercial matter. Art. 86 makes it a duty of every participant, and its list of required qualities comes down to three tests an operator can apply: can the customer find and finish a Pix quickly and without needless steps, do the on-screen commands say plainly what will happen, and is the outcome secure, correct and visible to the customer. The duty reaches every Pix journey a participant offers, from managing keys in the DICT and proving who the user is to sending, receiving and returning money, and since 2024 the Pix Automatico and Pix Agendado features. The article gives the full list of qualities and journeys.", "citation": "Resolucao BCB n. 1/2020 and annexed Regulamento Pix, consolidated text, VersaoNormativo 41, art. 86 caput incisos I to IX and par. unico incisos I to IX (inciso IX added by Resolucao BCB n. 402 de 22/7/2024)", "rests_on": "rule" }, { "label": "The night ceiling is the single most concrete protection", "value": "After dark, a payment from one individual to another is capped at R$1,000.00 by default. The customer can lift it by asking, but nobody has to opt in to the protection. The BCB set it because night is when coercion payments happen, and it left the choice of clock, the payer's registered home town or Brasilia, to the bank.", "citation": "Instrucao Normativa BCB n. 512/2024, consolidated text, VersaoNormativo 4, art. 3 par. 7 (wording by IN BCB n. 669 de 29/9/2025) with paragraphs 2 to 6", "rests_on": "rule" }, { "label": "Cuts are immediate, increases are slow on purpose", "value": "Tightening is instant and loosening is deliberately slow. A cut must be honoured the moment it is asked for. An increase is the bank's choice to grant or refuse, and whichever it decides, the reply and any new limit arrive no sooner than 24 hours and no later than 48 hours after the request. Pix Automatico is the exception: the bank has 8 hours at most to answer an increase. Two other changes run on the same 24 to 48 hour timetable: moving the start of the night period, and registering an account for a limit of its own.", "citation": "Instrucao Normativa BCB n. 512/2024, consolidated text, VersaoNormativo 4, arts. 11, 12 caput and paragraphs 1 and 2, 13 and 14", "rests_on": "rule" }, { "label": "The limit panel must be where the customer already is", "value": "Banks serving individuals must put limit management inside the app the customer pays from, not on a website or behind a phone call. It has to reach every limit the customer can hold: the general Pix limit, each product limit (contactless, Pix Automatico, Pix Agendado, and withdrawal and change), and ceilings attached to a named payee. A customer who wants a limit of zero is entitled to that too.", "citation": "Instrucao Normativa BCB n. 512/2024, consolidated text, VersaoNormativo 4, arts. 10 caput and paragraphs 1 and 2, and 3 par. 14", "rests_on": "rule" }, { "label": "A freeze the customer never has to ask for", "value": "The protection that works fastest needs no complaint at all. Where the receiving bank suspects fraud it must lock the money as it credits it, for up to 72 hours, and tell its own customer at once. The payer never sees this happen and cannot trigger it; it is the receiving bank's duty, weighed against factors the rule lists.", "citation": "Resolucao BCB n. 1/2020 and annexed Regulamento Pix, consolidated text, VersaoNormativo 41, art. 39-B caput and paragraphs 2 to 6", "rests_on": "rule" }, { "label": "A complaint can start a recovery", "value": "A customer complaint is enough to set the recovery machinery going: the payer's bank must open a funds recovery once, on the back of that complaint, it holds a well founded suspicion that the payment was fraudulent. The DICT manual reaches wider than the Regulamento here, having the bank open one whenever it identifies suspected fraud itself, with or without a complaint. Fraud for this purpose is drawn broadly, and its four grounds divide by whether the customer authorised the payment at all. Where the customer did authorise it, the grounds are a scam, social engineering included and reaching a Pix Automatico payment as well, and coercion or extortion. Where the customer did not, the grounds are a payment the customer did not authorise by digital authentication, and a payment a third party authenticated and authorised after obtaining the means of initiating it, which the customer does not recognise.", "citation": "Resolucao BCB n. 1/2020 and annexed Regulamento Pix, consolidated text, VersaoNormativo 41, art. 78-N (introduced by Resolucao BCB n. 493 de 28/8/2025); Manual Operacional do Diretorio de Identificadores de Contas Transacionais (DICT), versao 8.5, effective 2026-09-01 and 2026-10-26, section 10 footnote 7 for the four fraud grounds, section 10.1 SituationType values, section 20 opening paragraphs for the trigger", "rests_on": "rule" }, { "label": "A fee rule and a disclosure rule", "value": "Two instruments split the job between them. The Regulamento takes disclosure: participants must publish to end users, individuals and businesses alike, the fees, the free allowances and any benefits attached to sending and receiving a Pix, and must do so at least on their own websites, somewhere easy to find and read. Charging itself is set by Resolucao BCB n. 19/2020. That instrument bars a fee on an individual for sending money as a transfer or as a purchase and for receiving a transfer, leaves a business chargeable on either leg, and gives an individual the first eight withdrawal or cashback sends of a month free. Both of those have a catch: the sending bans fall away at a branch or over the telephone where an electronic route was available, and the count of eight can be set against free withdrawals the customer took outside Pix. Where a fee is charged, the customer has to be able to find its amount three ways over: on the receipt for that transaction, on the account statements, both the ordinary one and the annual consolidated fee statement, and ahead of time in the fee table the institution publishes on its website and its other electronic channels.", "citation": "Resolucao BCB n. 1/2020 and annexed Regulamento Pix, consolidated text, VersaoNormativo 41, art. 87 caput and paragrafo unico; Resolucao BCB n. 19/2020, consolidated text, VersaoNormativo 3, arts. 3 including paragrafos 1 and 2, 4 and 7 (art. 3 inciso I as worded from 2021-11-01 by Resolucao BCB n. 136/2021)", "rests_on": "rule" }, { "label": "Where disagreements go", "value": "When the parties cannot sort it out themselves, disputes about applying the Regulamento, between banks or between a bank and a customer, follow procedures the BCB sets in a manual of its own. Payments started through a payment initiation service take a different route: either the complaint handling of Resolucao Conjunta n. 1 de 4/5/2020, or the dispute machinery Open Finance participants run among themselves.", "citation": "Resolucao BCB n. 1/2020 and annexed Regulamento Pix, consolidated text, VersaoNormativo 41, art. 91 caput (wording from 2023-01-01, Resolucao BCB n. 269/2022) and art. 91 par. unico incisos I and II", "rests_on": "rule" }, { "label": "The general customer protection resolution has a hole in it", "value": "Resolucao CMN n. 4.949/2021 gives bank customers a baseline of general duties: fair and equitable treatment that takes account of vulnerable customers, products matched to what the customer actually needs, and honest information and paperwork. In practice that last group covers how rights, costs and risks are explained, how plainly contracts and statements are written, whether a statement names who was paid, and whether getting documents, closing an account or switching institution is made needlessly hard; art. 4 sets out the full list. That resolution expressly does not apply to payment institutions, which must instead follow whatever the BCB issues for them. Many Pix providers are payment institutions, so a customer's baseline protection depends on what kind of licence their provider holds.", "citation": "Resolucao CMN n. 4.949/2021, consolidated text, VersaoNormativo 2, arts. 1 caput and par. 1 (wording from 2024-03-01 by Resolucao CMN n. 5.117/2024), 2, 3 and 4 incisos I to VII", "rests_on": "rule" }, { "label": "What the BCB says the rulebook is", "value": "The BCB has put on record what kind of instrument the Pix rulebook is. In the note appended to IN BCB n. 512/2024 it relies on Voto 280/2021-BCB to say the Regulamento and everything that fills it out are contractual rather than binding regulation, which is its reason for changing them without prior regulatory impact analysis. That matters to anyone reasoning about what a customer can sue on.", "citation": "Instrucao Normativa BCB n. 512/2024, consolidated text, VersaoNormativo 4, NOTA appended to the published text, citing Voto 280/2021-BCB paragraph 8", "rests_on": "guidance" } ], "exceptions": [ "None of these rules gives the end user a right to compensation. The Regulamento allocates loss between participants (arts. 41-H and 41-I) and is silent on what the customer may recover from their own bank.", "Brazil's consumer statute, Lei n. 8.078/1990, and its general application to payment services were not read for this record, so how it interacts with these rules is [Unverified] here.", "IN BCB n. 512/2024 binds participants acting as transactional account providers for natural person clients, and those offering withdrawal facilitation. A business customer gets none of the limit protections in this record by right (IN BCB n. 512/2024 art. 2).", "The Requisitos Minimos para a Experiencia do Usuario manual is the document that turns art. 86 into concrete requirements, and it governs how the limit panel and the unblocking notice must be presented. It was fetched for this record and could not be read: the PDF's text layer did not extract.", "The dispute procedures themselves live in the Manual de Resolucao de Disputas, listed on the BCB Pix normas page and not opened for this record, so this record names the route and not what happens along it." ], "applies_to": "protections available to an end user of Pix in Brazil, set by the Pix rules and by the BCB's general customer relationship rules, and the boundary where the rulebook hands off to law", "caveat": "Read the protections as preventive and the remedies as absent. Pix is good at stopping money leaving and at freezing it once it lands, and it says nothing about who pays the victim when both fail. Before advising a user, establish two things the rulebook makes decisive: whether their provider is a bank or a payment institution, and whether their limit was set by default or by their own earlier request to raise it.", "related": [ "pix:limits", "pix:liability", "pix:refund", "pix:return", "pix:hours", "pix:decision-points" ], "basis": { "sources": "Regulamento Pix, annex to Resolucao BCB n. 1/2020, consolidated version 41, read for this record from the BCB normativos data endpoint: arts. 39-B, 41-H, 41-I, 78-N, 86, 87 and 91. Instrucao Normativa BCB n. 512 de 30/8/2024, consolidated text from the same endpoint, including the NOTA appended to it: arts. 2, 3, 10, 11, 12, 13 and 14. Resolucao CMN n. 4.949 de 30/9/2021, consolidated text from the same endpoint: arts. 1 to 5. Manual Operacional do DICT, version 8.5, section 10 and 10.1 for the definition of fraud and the SituationType values. No secondary source was used. The Requisitos Minimos para a Experiencia do Usuario manual, the Manual de Resolucao de Disputas and Resolucao BCB n. 19/2020 were not read.", "confidence": "medium" }, "currency": { "effective_since": "2024-11-01", "effective_to": null, "effective_note": "The user experience article dates from the original 2020 Regulamento and gained its Pix Automatico journeys through Resolucao BCB n. 402/2024. The limit protections come from IN BCB n. 512/2024, published 2024-09-03, substantially rewritten by IN BCB n. 669 de 29/9/2025 and amended again from 2025-12-01 and 2026-10-01. The complaint driven funds recovery is newer still, from Resolucao BCB n. 493 de 28/8/2025. Confidence is medium rather than high because the two documents that would carry the customer facing detail, the Requisitos Minimos manual and the Manual de Resolucao de Disputas, were not read, and because no Brazilian consumer statute was consulted.", "source_edition": "Regulamento Pix (Resolucao BCB n. 1/2020), consolidated version 41; IN BCB n. 512/2024 consolidated text, amendments listed through IN BCB n. 746 de 18/6/2026; Resolucao CMN n. 4.949/2021 consolidated text; Manual Operacional do DICT 8.5", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "rail_name": "Pix", "governing_authority": "Banco Central do Brasil", "snapshot": "2026-09-17", "source_class": null, "effective_status": "draft", "effective_status_reason": null, "boundaries": [] }, { "uid": "pix:decision-points", "id": "decision-points", "rail": "pix", "kind": "rail-fact", "facet": "decision-points", "name": "Where does Pix hand the outcome to a human or a bank's judgment?", "statement": "Settlement on Pix is mechanical and almost everything around it is not. The rail decides nothing about whether a payment should have happened: it checks form, funds and the receiving side's answer, and settles. Judgment is pushed outward to the two banks, and the rules usually say a decision must be made without saying how to make it. The load-bearing ones are whether a suspicion of fraud is well founded, whether to freeze money on arrival, whether a customer's story justifies opening a recovery, whether to accept an infraction notice about one's own customer, and whether to raise a limit. Some of these decide whether money is recoverable at all, and several run on clocks measured in minutes or hours.", "details": [ { "label": "Is the suspicion well founded", "value": "The phrase separates two worlds. Mere suspicion obliges the receiving bank to freeze for up to 72 hours; well founded suspicion obliges both banks to reject outright and opens the fraud recovery path. The rules give factors but no threshold, and the same facts can be read either way by two institutions.", "citation": "Resolucao BCB n. 1/2020 and annexed Regulamento Pix, consolidated text, VersaoNormativo 41, arts. 38 inciso II, 39 inciso I, 39-B caput and 41-B caput inciso I", "rests_on": "rule" }, { "label": "Whether to hold a payment before it settles", "value": "The payer's bank decides whether a payment is suspicious enough to sit on, and the decision is worth minutes: up to 30 on a business day between 08:00 and 20:00 Brasilia time, up to 60 otherwise. Holding buys analysis time and gives the customer a chance to cancel, and it is the only cancellation window on the rail. Withdrawal, change and Open Finance smart transfers are outside it.", "citation": "Manual de Tempos do Pix, versao 7.0, section 2", "rests_on": "rule" }, { "label": "Whether to freeze money as it lands", "value": "The receiving bank's precautionary hold is the fastest protection Pix has and the one with the least guidance attached. The rule names what the assessment must take in without saying how much each counts: what is known about the receiving customer (notices of infraction already against them, and how recently the account was opened), what is known about the payer and the pair (the payer's profile, and whether the two deal with each other regularly), and when the payment arrived. Anything else is left to the bank. Since September 2025 business accounts are exposed to it as well as personal ones.", "citation": "Resolucao BCB n. 1/2020 and annexed Regulamento Pix, consolidated text, VersaoNormativo 41, art. 39-B caput and paragraphs 1 and 4, with par. 7 revoked by Resolucao BCB n. 506 de 26/9/2025", "rests_on": "rule" }, { "label": "What to do at the end of 72 hours", "value": "A hold ends in one of two places and the bank picks which. Where it now has grounds for well founded suspicion, the money goes back to the payer under the MED. Where it does not, the hold lifts at once and the customer is told. Nothing extends the 72 hours.", "citation": "Resolucao BCB n. 1/2020 and annexed Regulamento Pix, consolidated text, VersaoNormativo 41, art. 39-B paragraphs 5 and 6 incisos I and II", "rests_on": "rule" }, { "label": "Whether to open a recovery on the customer's word", "value": "The payer's bank decides whether a complaint amounts to well founded suspicion. Opening is consequential in both directions: it freezes money in accounts several hops away and marks users as fraud suspects when notices are accepted, and it can only ever be done once for a given payment, so a case opened badly cannot be reopened later.", "citation": "Resolucao BCB n. 1/2020 and annexed Regulamento Pix, consolidated text, VersaoNormativo 41, art. 78-N (introduced by Resolucao BCB n. 493 de 28/8/2025); Manual Operacional do Diretorio de Identificadores de Contas Transacionais (DICT), versao 8.5, effective 2026-09-01 and 2026-10-26, sections 20.1.1 and 20.1.10", "rests_on": "rule" }, { "label": "Whether to accept an infraction notice about your own customer", "value": "Each notified bank judges whether its customer really was part of the dispersion, and the manual pushes it toward accepting: it should accept even with an empty account, because rejecting cuts the chain for every account further down. Accepting marks the customer as fraud whether or not money moves. Rejecting without just cause makes the bank answerable for the loss, and no source read defines just cause.", "citation": "Manual Operacional do Diretorio de Identificadores de Contas Transacionais (DICT), versao 8.5, effective 2026-09-01 and 2026-10-26, section 20.1.5; Resolucao BCB n. 1/2020 and annexed Regulamento Pix, consolidated text, VersaoNormativo 41, arts. 78-G caput and 41-I caput inciso I", "rests_on": "rule" }, { "label": "Whether to cancel a recovery you opened", "value": "The recovering bank has to keep testing its own case, and must kill it where it concludes this is not fraud, even after the other banks have finished their analysis. It also has 72 hours after the analysis stage to start the return, during which it may still be deciding. Letting the clock run out and cancelling look identical to the customer and differ entirely in what the bank owes the other participants.", "citation": "Manual Operacional do Diretorio de Identificadores de Contas Transacionais (DICT), versao 8.5, effective 2026-09-01 and 2026-10-26, sections 20.1.5, 20.1.6 and 20.1.10", "rests_on": "rule" }, { "label": "Whether to honour a return request at all", "value": "Having accepted the notice, the receiving bank still chooses whether to pay, and may answer in full, in part, or not at all. A nil answer needs one of three stated reasons, one of which is simply a generic reason the other two do not cover, which leaves the bank considerable room.", "citation": "Manual Operacional do Diretorio de Identificadores de Contas Transacionais (DICT), versao 8.5, effective 2026-09-01 and 2026-10-26, section 17, closing field table", "rests_on": "rule" }, { "label": "The operational failure route is narrower than it sounds", "value": "Operational failure means the bank broke something, not that the customer regrets something. The manual points to duplicated payments, payments made for an amount the customer did not instruct, and money leaving before the customer confirmed. It shuts the door on a long list of near misses: the payer typed the wrong key, the payer sent two payments when one was meant, the bank failed to debit or to reconcile or to show the entry on the statement, and anything that is really a scam. Where the facts do not fit, the receiving bank must reject with invalid_request.", "citation": "Manual Operacional do Diretorio de Identificadores de Contas Transacionais (DICT), versao 8.5, effective 2026-09-01 and 2026-10-26, section 17.1", "rests_on": "rule" }, { "label": "Whether to raise a customer's limit", "value": "Cuts are not a decision, they must be honoured immediately. Increases are entirely the bank's call, and the rule governs only the timing of the answer: 24 to 48 hours in general, at most 8 hours for Pix Automatico. Since the TED peg was removed in September 2025 there is no regulated floor to appeal to, so the same customer can properly be told different things by different banks.", "citation": "Instrucao Normativa BCB n. 512/2024, consolidated text, VersaoNormativo 4, arts. 11 and 12 caput with paragraphs 1 and 2 (art. 3 par. 7 and par. 8 pegs revoked by IN BCB n. 669 de 29/9/2025)", "rests_on": "rule" }, { "label": "Whether to lift a block on a flagged account", "value": "A customer whose account has been shut out of Pix after an accepted notice can complain, and their bank must then reassess and lift the restriction if it concludes the notice should be cancelled. The rule creates the duty to look again and says nothing about what should persuade the bank.", "citation": "Resolucao BCB n. 1/2020 and annexed Regulamento Pix, consolidated text, VersaoNormativo 41, art. 89 par. 10 (introduced by Resolucao BCB n. 425 de 16/10/2024, in effect from 2024-11-01)", "rests_on": "rule" }, { "label": "Where the DICT decides instead of a person", "value": "Two decisions on this rail are made by an algorithm rather than by anyone accountable to the customer. The tracing graph is built from parameters the recovering bank supplies against minimum criteria the BCB sets and does not publish, and the choice of which accounts to freeze is made by the DICT's own prioritization algorithm under stated properties rather than a published rule. Neither the recovering bank nor the frozen customer's bank picks the path.", "citation": "Manual Operacional do Diretorio de Identificadores de Contas Transacionais (DICT), versao 8.5, effective 2026-09-01 and 2026-10-26, sections 20.1.2 and 20.1.3", "rests_on": "rule" } ], "exceptions": [ "Some decisions are not decisions at all. Blocking on an infraction notice is mandatory and immediate, a limit cut must be honoured at once, and an order that misses its settlement window is killed by the system without anyone choosing (Manual Operacional do DICT 8.5 section 20.1.4; IN BCB n. 512/2024 art. 11; Manual de Tempos 1.1).", "Where a payment is settled outside the SPI and falls short of the traceability criteria, the judgment moves inside one institution: it blocks, assesses and returns on its own, or the settling participant intermediates between two participants it serves (Manual Operacional do DICT 8.5 section 20.1.8).", "The minimum criteria the BCB requires participants to use in assessing suspicion of fraud are to be published in a specific document under art. 39-C, added by Resolucao BCB n. 506/2025. No such document was located for this record, so how far these judgments are actually standardised is open.", "Disputes that cannot be settled between the parties go to BCB procedures in the Manual de Resolucao de Disputas, which was not opened, so who decides at the end of the line is named here and not described (Regulamento Pix art. 91).", "This record reads judgment out of rule text. Where a rule is silent, an operator should assume the practice varies by institution rather than assume a default [Inference]." ], "applies_to": "points in a Pix payment, return, hold or fraud recovery where the rules require a judgment rather than prescribing an outcome", "caveat": "Orca's reading of where a rule leaves judgment to a bank is never better than medium confidence, and on this rail two things sharpen the point. Several judgments run on very short clocks, so a slow operations team loses the option rather than exercising it. And two of the most consequential steps, which accounts get traced and which get frozen, are made by an algorithm the BCB has not published, so no amount of reading the rules will tell an operator why a particular account was picked.", "related": [ "pix:finality", "pix:return", "pix:recall", "pix:refund", "pix:liability", "pix:limits", "pix:consumer-law" ], "basis": { "sources": "Regulamento Pix, annex to Resolucao BCB n. 1/2020, consolidated version 41, read for this record from the BCB normativos data endpoint: arts. 38, 39, 39-B, 39-C, 41-B, 41-C, 41-I, 78-F, 78-G, 78-N, 89 and 91. Manual Operacional do DICT, version 8.5, read for this record: sections 10.1, 17, 17.1, 20.1.1 to 20.1.10. Manual de Tempos do Pix, version 7.0, section 2. Instrucao Normativa BCB n. 512 de 30/8/2024, arts. 11 and 12. The judgments identified here are Orca's reading of those texts, not a list the BCB publishes. No secondary source was used.", "confidence": "medium" }, "currency": { "effective_since": "2026-09-01", "effective_to": null, "effective_note": "The decision points described here reflect the Regulamento at consolidated version 41 and Manual Operacional do DICT 8.5, whose first tranche took effect 2026-09-01. The newest additions are the complaint driven funds recovery under Resolucao BCB n. 493 de 28/8/2025 and the removal of the natural person limit on precautionary holds by Resolucao BCB n. 506 de 26/9/2025. Where a rule changes what a bank must decide, this record changes with it; where practice varies without a rule change, this record will not show it.", "source_edition": "Regulamento Pix (Resolucao BCB n. 1/2020), consolidated version 41; Manual Operacional do DICT 8.5; Manual de Tempos do Pix 7.0; IN BCB n. 512/2024 consolidated text", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.bcb.gov.br/estabilidadefinanceira/exibenormativo?tipo=Resolução%20BCB&numero=1", "source_class": "authoritative_primary", "source_title": "Resolucao BCB n. 1/2020 and annexed Regulamento Pix, consolidated text, VersaoNormativo 41", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the well founded versus mere suspicion distinction that separates a 72 hour freeze from an outright reject (arts. 38 inciso II, 39 inciso I, 39-B caput), the freeze assessment factors and the two way outcome when the 72 hours end (art. 39-B paragraphs 1, 4, 5 and 6), the complaint driven funds recovery the payer's bank may open (art. 78-N), the duty to accept an infraction notice and the just cause standard for rejecting one (arts. 78-G caput and 41-I caput inciso I), and the reconsideration duty on a blocked account (art. 89 par. 10). Manual Operacional do DICT 8.5 sections 10.1, 17, 17.1 and 20.1.1 to 20.1.10, Manual de Tempos do Pix 7.0 section 2, and Instrucao Normativa BCB n. 512/2024 arts. 11 and 12 were also read and match the record; this corroboration records the Resolucao BCB n. 1/2020 source only." } ] }, "rail_name": "Pix", "governing_authority": "Banco Central do Brasil", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "pix:finality", "id": "finality", "rail": "pix", "kind": "rail-fact", "facet": "finality", "name": "When does a Pix become final, and can it be reversed?", "statement": "A Pix settles in seconds and, once settled, the credit order is irrevocable and unconditional. The sender cannot cancel it and the payer's bank cannot pull it back. That is the whole of finality, and it is not the whole of the answer. Money can still come back three ways, none of which reverses the original payment: the receiving user can send an ordinary devolucao (return) within 90 days, the payer's bank can raise a case under the Mecanismo Especial de Devolucao (MED) for fraud or for its own operational failure, and the receiving bank can put a precautionary hold (bloqueio cautelar) of up to 72 hours on suspect funds the moment it credits them. Every one of those is a new money movement, decided by somebody else.", "details": [ { "label": "The moment of finality", "value": "Finality has one instant, not a window. Nothing about a settled Pix can be undone or made conditional afterwards, and the instant that counts is when the BCB's own books show both Conta PI balances changed. Before that instant there is no payment; after it there is no taking it back.", "citation": "Regulamento do Sistema de Pagamentos Instantaneos (SPI), anexo a Resolucao BCB n. 195/2022, consolidated text, VersaoNormativo 6, art. 40 caput and art. 40 par. 1", "rests_on": "rule" }, { "label": "How fast that has to happen", "value": "The clock is a settlement deadline, not a service target. On the primary channel the payment has 40 seconds from the moment the payer's PSP takes the order to the moment it settles; on the secondary channel, which carries only scheduled payments, it has 45 minutes. Run out of clock and the payment does not arrive late, it is killed, and once the order is inside the SPI it is the SPI that kills it.", "citation": "Manual de Tempos do Pix, versao 7.0, sections 1.1 and 1.2", "rests_on": "rule" }, { "label": "The system presumes the order is good", "value": "The SPI takes a properly formed order at face value. It checks form, funds and the receiving side's answer, and it does not ask whether the payer meant to send it. Legitimacy is assumed, which is why every argument about whether a payment should have happened is fought after settlement rather than before it.", "citation": "Regulamento do Sistema de Pagamentos Instantaneos (SPI), anexo a Resolucao BCB n. 195/2022, consolidated text, VersaoNormativo 6, art. 41, with arts. 34, 36 and 37", "rests_on": "rule" }, { "label": "There is no sender cancellation and no cancellation message", "value": "The Pix rules give the payer or the payer's PSP no way to cancel or amend a settled payment. The SPI message catalog has no camt.056 and no recall message. The only cancellation messages in the catalog, camt.055 and pain.011, cancel a scheduled debit or a Pix Automatico authorization before it is paid, not a settled payment.", "citation": "Catalogo de Servicos do SFN, Volume VI, Pagamentos Instantaneos, versao 5.12, dated 2026-03-27, message chapter, pp. 17 to 21 (absence of a cancellation message for a settled payment); Manual de Tempos do Pix, versao 7.0, sections 3.3 and 3.4", "rests_on": "rule" }, { "label": "One cancellation window does exist, before settlement", "value": "The only cancel button on this rail lives inside the fraud hold. While the payer's PSP is sitting on a suspect payment under its extended authorization window, it owes the payer two things: word that the payment is being looked at, and a way to call it off. That window is up to 30 minutes on business days between 08:00 and 20:00 Brasilia time and up to 60 minutes at any other hour or day. It closes when the payment settles.", "citation": "Manual de Tempos do Pix, versao 7.0, section 2", "rests_on": "rule" }, { "label": "Second layer: a return is a new payment, not a reversal", "value": "A devolucao moves funds that are already available in the receiving user's account back to the payer, as its own value message (pacs.004). It presupposes sufficient funds in that account, it may be partial, and it may be repeated until the original amount is reached. Nothing about the original payment is undone.", "citation": "Resolucao BCB n. 1/2020 and annexed Regulamento Pix, consolidated text, VersaoNormativo 41, arts. 40 par. 2 and 41-A caput inciso I", "rests_on": "rule" }, { "label": "Third layer: the money can be frozen the instant it lands", "value": "A suspicious payment can arrive and be frozen in the same breath. Where the receiving user's PSP suspects fraud, the hold goes on at the same moment as the credit, lasts no more than 72 hours, and buys the bank time to decide whether the suspicion is well founded. The payment is final, the receiver still cannot spend it.", "citation": "Resolucao BCB n. 1/2020 and annexed Regulamento Pix, consolidated text, VersaoNormativo 41, art. 39-B caput and paragraphs 2, 4 and 5", "rests_on": "rule" }, { "label": "Fourth layer: finality does not settle who bears the loss", "value": "A settled Pix can still be clawed back through the MED where there is well founded suspicion of fraud, where a participant's information technology systems failed, or where a Pix Automatico payment was sent without a valid authorization. The MED expressly does not cover disputes about the underlying deal, and it does not cover funds that reached a good faith third party.", "citation": "Resolucao BCB n. 1/2020 and annexed Regulamento Pix, consolidated text, VersaoNormativo 41, arts. 41-B caput incisos I to III and 41-B par. 1", "rests_on": "rule" }, { "label": "Settlement outside the SPI", "value": "Where both accounts sit at one participant, settlement is done in that participant's own systems. Where two participants use the same settling participant in the SPI, settlement between them is done in the settling participant's systems. Those payments are still Pix, carry the same 40 second and 45 minute limits, and must be reported to the BCB within 30 days of settlement.", "citation": "Resolucao BCB n. 1/2020 and annexed Regulamento Pix, consolidated text, VersaoNormativo 41, arts. 33 par. unico and 34; Manual de Tempos do Pix, versao 7.0, sections 1.3 and 1.4", "rests_on": "rule" } ], "exceptions": [ "A payment that does not settle inside its window never becomes final. It is rejected by the SPI, or by the settling participant when it is settled outside the SPI (Manual de Tempos 1.1, 1.2, 1.3).", "Where the payer's PSP has no available balance in its Conta PI at the moment the SPI tries to block the amount, the order is immediately and definitively rejected and no finality attaches (Regulamento do SPI art. 36 par. 4).", "Pix Saque and the cash portion of Pix Troco are outside the MED entirely, so for those the only route back is the ordinary return, started by the withdrawal facilitator or the withdrawal agent within one hour of finding it due (Regulamento Pix arts. 41-B par. 2 and 41 paragraphs 2 and 4).", "For Pix Automatico sent in error by the payer's PSP, the payer's PSP must make its own client whole from its own funds whether or not it ever recovers the money, so finality against the receiver does not decide the payer's position (Regulamento Pix arts. 41-A par. 2 inciso I and 11-V).", "Finality binds the participants and the SPI. It does not decide a consumer's claim against their own bank under Brazilian consumer and banking law, which runs on its own footing and is not part of the Pix rulebook [Unverified: no consumer statute was read for this record]." ], "applies_to": "a Pix credit transfer in Brazilian reais between transactional accounts held at Pix participants, settled in the SPI or in a participant's own systems", "caveat": "Do not tell an operator that a Pix is irreversible full stop. It is irrevocable, and it is clawable. The practical question is never whether the payment is final, it is which of the three paths fits the facts and whose deadline has already run: 90 days for an ordinary return, 80 days to open a fraud recovery, 72 hours for a precautionary hold, one hour for a Pix Saque return.", "related": [ "pix:settlement", "pix:hours", "pix:return", "pix:recall", "pix:refund", "pix:liability", "pix:consumer-law", "pix:decision-points" ], "basis": { "sources": "Regulamento do SPI, annex to Resolucao BCB n. 195 de 3/3/2022 (consolidated text read for this record from the BCB normativos data endpoint): arts. 34 to 42, in particular art. 36 (prior blocking of funds), art. 37 (confirmation of capacity to receive), art. 40 (irrevocability and the moment of settlement), art. 41 (presumption of legitimacy), art. 42 (maximum settlement time). Regulamento Pix, annex to Resolucao BCB n. 1 de 12/8/2020, consolidated version 41 (read for this record from the same endpoint): arts. 33, 34, 36, 38, 39-B, 40, 40-A, 41, 41-A, 41-B, 11-V. Manual de Tempos do Pix, version 7.0: sections 1.1 to 1.4 and 2. Catalogo de Servicos do SFN, Volume VI, version 5.12, message chapter, for the absence of any cancellation message for a settled payment. No secondary source was used.", "confidence": "high" }, "currency": { "effective_since": "2022-04-01", "effective_to": null, "effective_note": "The irrevocability provision cited sits in the Regulamento do SPI approved by Resolucao BCB n. 195/2022, which took effect 2022-04-01 and revoked Circular BCB n. 4.027/2020. Pix itself has run since November 2020 under that revoked Circular, and the drafter did not read it, so whether the same wording existed from the start is [Unverified]. The 40 second and 45 minute limits are Manual de Tempos 7.0; earlier versions were not read.", "source_edition": "Regulamento do SPI (Resolucao BCB n. 195/2022), consolidated text as published on the BCB normativos page, latest amendment listed Resolucao BCB n. 554 de 24/3/2026; Regulamento Pix (Resolucao BCB n. 1/2020), consolidated version 41; Manual de Tempos do Pix 7.0; Catalogo de Servicos do SFN Vol. VI 5.12 dated 2026-03-27", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.bcb.gov.br/estabilidadefinanceira/exibenormativo?tipo=Resolução%20BCB&numero=195", "source_class": "authoritative_primary", "source_title": "Regulamento do Sistema de Pagamentos Instantaneos (SPI), anexo a Resolucao BCB n. 195/2022, consolidated text, VersaoNormativo 6", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms irrevocability and unconditional effect of a settled credit order once Conta PI balances change (art. 40), the presumption of legitimacy for a properly formed order (art. 41), prior blocking of the issuing participant's funds and its 2026-03-30 wording adding the minimum operating balance (art. 36), and the balance swap mechanics (arts. 37 to 39). Manual de Tempos do Pix 7.0 sections 1.1 to 1.4 (40 second and 45 minute clocks) and the SPI message catalog 5.12 (absence of a camt.056) were also read and support the record's other detail lines; this corroboration records the Regulamento do SPI source only." } ] }, "rail_name": "Pix", "governing_authority": "Banco Central do Brasil", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "pix:hours", "id": "hours", "rail": "pix", "kind": "rail-fact", "facet": "hours", "name": "When is Pix open, and what runs on a different clock?", "statement": "Pix is open all the time. The SPI settles credit orders 24 hours a day on every day of the year, the DICT key directory answers on the same terms, and a direct participant must stay connected and funded on those terms too. Underneath that single answer sit four other clocks an operator has to keep straight: messages are stamped in UTC while the rules speak Brasilia time, some DICT functions need only be offered to end users from 08:00 to 20:00, the night period from 20:00 to 06:00 carries its own value limit, and a suspected fraud may be held for 30 or 60 minutes depending on the hour and the day.", "details": [ { "label": "The SPI never closes", "value": "There is no cutoff to miss and no weekend to wait for. Settlement is available to participants at every hour of every day of the year. The BCB reserves the right to set other hours only for functions that move no money.", "citation": "Regulamento do Sistema de Pagamentos Instantaneos (SPI), anexo a Resolucao BCB n. 195/2022, consolidated text, VersaoNormativo 6, art. 8 caput and par. unico", "rests_on": "rule" }, { "label": "An instant payment is defined as always available", "value": "Continuous availability is built into the definition rather than bolted on. What the SPI regulation calls an instant payment is one where the money travels and lands in real time, on a service that runs every hour of every day. A rail that closed would not be offering instant payments at all.", "citation": "Regulamento do Sistema de Pagamentos Instantaneos (SPI), anexo a Resolucao BCB n. 195/2022, consolidated text, VersaoNormativo 6, art. 2 inciso II", "rests_on": "rule" }, { "label": "Banks must be open too", "value": "The obligation to be up runs to the banks, not just the system. A direct participant has to stay plugged into the SPI and able to send and receive at any hour of any day, keep its Conta PI managed on the same footing, and keep its contact numbers answerable on the same footing. The BCB watches the system itself in unbroken shifts.", "citation": "Regulamento do Sistema de Pagamentos Instantaneos (SPI), anexo a Resolucao BCB n. 195/2022, consolidated text, VersaoNormativo 6, arts. 18 incisos II and III, 15 par. 4, and 11 par. unico", "rests_on": "rule" }, { "label": "The DICT never closes either", "value": "Since 2023 the whole of the key directory runs on the same terms as the SPI, every hour of every day. That covers registering, deleting, changing, porting and claiming a key, querying one, raising an infraction notice, verifying registered keys and asking for a return.", "citation": "Resolucao BCB n. 1/2020 and annexed Regulamento Pix, consolidated text, VersaoNormativo 41, art. 79 (wording from 2023-01-01, Resolucao BCB n. 269/2022)", "rests_on": "rule" }, { "label": "What a bank must offer its own customers is narrower", "value": "Key registration, deletion, portability and ownership claim need only be offered to end users from 08:00 to 20:00 Brasilia time, on every day of the year. A participant may offer them outside those hours at its own discretion, during the hours the DICT is up. So the directory is always open and a customer may still find their own app will not register a key at 03:00.", "citation": "Resolucao BCB n. 1/2020 and annexed Regulamento Pix, consolidated text, VersaoNormativo 41, art. 80 caput (wording from 2021-11-01, Resolucao BCB n. 103/2021) and art. 80 par. unico", "rests_on": "rule" }, { "label": "Payment clocks: 40 seconds or 45 minutes", "value": "A Pix on the primary message channel must settle within 40 seconds. A Pix on the secondary channel, which carries only Pix Agendado and scheduled Pix Cobranca, has 45 minutes. The same two limits apply to payments settled outside the SPI, where the participant responsible for settlement issues the rejection instead of the SPI.", "citation": "Manual de Tempos do Pix, versao 7.0, sections 1.1, 1.2 and 1.3", "rests_on": "rule" }, { "label": "The fraud hold runs on business hours", "value": "Where a payer's PSP suspects fraud it may take up to 30 minutes to authorize initiation between 08:00 and 20:00 Brasilia time on business days, and up to 60 minutes at all other times and days. Pix with the purpose of withdrawal or change, and Open Finance smart transfers, are outside that extension. The payer must be told the payment is under analysis and offered the option to cancel.", "citation": "Manual de Tempos do Pix, versao 7.0, section 2", "rests_on": "rule" }, { "label": "The night period is a value rule, not a closing", "value": "For payments from a natural person, the night period is in general 20:00 to 06:00 and the day period 06:00 to 20:00, measured either at the payer's registered domicile or in Brasilia time at each participant's choice. A participant may offer the user the option to move the start of night to 22:00, in which case the day period runs to 22:00. Pix keeps working through the night; only the ceiling changes.", "citation": "Instrucao Normativa BCB n. 512/2024, consolidated text, VersaoNormativo 4, art. 3 paragraphs 2, 3, 4, 5 and 6", "rests_on": "rule" }, { "label": "Messages are in UTC, rules speak Brasilia", "value": "All SPI messages carry timestamps in UTC, marked with the Z indicator, and Brasilia standard time is UTC minus three hours. The same UTC rule applies to the DICT and its participants. Where the SPI and a participant's clocks differ, the time on the Banco Central do Brasil's own equipment prevails for all purposes.", "citation": "Catalogo de Servicos do SFN, Volume VI, Pagamentos Instantaneos, versao 5.12, dated 2026-03-27, date and time section, p. 12; Resolucao BCB n. 1/2020 and annexed Regulamento Pix, consolidated text, VersaoNormativo 41, art. 82 caput and par. unico; Regulamento do Sistema de Pagamentos Instantaneos (SPI), anexo a Resolucao BCB n. 195/2022, consolidated text, VersaoNormativo 6, art. 10", "rests_on": "rule" }, { "label": "Availability is measured and has a floor", "value": "The SPI regulation defines an availability index as the hours the SPI actually ran expressed as a percentage of the hours it was meant to be open to participants, counted over the last three months, and it binds the BCB, in its role as the system's manager and operator, to hold that index at or above 99.90 percent. The Manual de Tempos carries the same target for the SPI and gives the DICT its own two, 99.9 percent for key queries and 99.8 percent for every other DICT operation. All three are worked out monthly: the SPI index and the DICT query index over a rolling three months, the index for the DICT's other operations over a rolling twelve. It also says what an outage is for this purpose: at least 80 percent of requests answered with errors the service or its infrastructure caused, lasting beyond 36 seconds on the SPI and beyond 30 seconds on the DICT.", "citation": "Regulamento do Sistema de Pagamentos Instantaneos (SPI), anexo a Resolucao BCB n. 195/2022, consolidated text, VersaoNormativo 6, arts. 2 inciso XVI and 5 inciso III; Manual de Tempos do Pix, versao 7.0, sections 6.1.2 and 6.2.3", "rests_on": "rule" } ], "exceptions": [ "The BCB may suspend SPI services temporarily for a specific period where extraordinary facts justify it (Regulamento do SPI art. 9).", "A participant may offer key registration, deletion, portability and ownership claim outside 08:00 to 20:00, so hours differ bank by bank and are not published centrally (Regulamento Pix art. 80 par. unico).", "Brasilia time has had no daylight saving since 2019, so the UTC minus three offset the catalog states holds year round [Inference: the catalog states the standard time offset and does not mention daylight saving; the decree abolishing it was not read].", "Pix Agendado scheduled between 20:00 and 24:00 for settlement the next day, to a different natural person, is capped at R$1,000.00 for that window, a night rule attached to the moment of scheduling rather than the moment of payment (IN BCB n. 512/2024 art. 7 par. 7).", "Pix Automatico carries its own message deadlines rather than the payment clock: 1 minute for a pain.012 acknowledging a pain.009, 1 hour for the receiving PSP to close an authorization, and 12 hours for a pain.012 or camt.029 acknowledging a cancellation (Manual de Tempos 3.1 to 3.4)." ], "applies_to": "availability of the SPI, the DICT and Pix participants, and the time windows that govern a Pix, a key operation and a fraud hold", "caveat": "Availability and reachability are different questions. The rail is up at 03:00; whether the customer's own bank will register a key, raise their limit, or answer a fraud call at 03:00 is set per participant and nowhere published. When a timing question matters, ask which clock: message time is UTC, rule time is Brasilia, and the fraud hold and the night limit both turn on the local hour.", "related": [ "pix:settlement", "pix:finality", "pix:limits", "pix:messages", "pix:consumer-law" ], "basis": { "sources": "Regulamento do SPI, annex to Resolucao BCB n. 195 de 3/3/2022, consolidated text read for this record from the BCB normativos data endpoint: arts. 2 incisos II and XVI, 8, 9, 10, 11, 13, 15 and 18. Regulamento Pix, annex to Resolucao BCB n. 1/2020, consolidated version 41: arts. 79, 80 and 82. Manual de Tempos do Pix, version 7.0: sections 1.1 to 1.3, 2, 3.1 to 3.4, 6.1.2 and 6.2.3. Instrucao Normativa BCB n. 512 de 30/8/2024, consolidated text read for this record from the same endpoint: arts. 3 and 7. Catalogo de Servicos do SFN, Volume VI, version 5.12, p. 12. No secondary source was used.", "confidence": "high" }, "currency": { "effective_since": "2022-04-01", "effective_to": null, "effective_note": "The 24 by 7 availability of the SPI is stated in the Regulamento do SPI in force since 2022-04-01; the equivalent provision in the revoked Circular BCB n. 4.027/2020 was not read, so the position before that date is [Unverified]. The current wording of art. 79 of the Regulamento Pix, extending 24 by 7 to every DICT function, took effect 2023-01-01. The night period definition comes from IN BCB n. 512/2024, published 2024-09-03 and amended by IN BCB n. 669 de 29/9/2025.", "source_edition": "Regulamento do SPI (Resolucao BCB n. 195/2022), consolidated text, latest amendment listed Resolucao BCB n. 554 de 24/3/2026; Regulamento Pix (Resolucao BCB n. 1/2020), consolidated version 41; Manual de Tempos do Pix 7.0; IN BCB n. 512/2024 as amended through IN BCB n. 746/2026; Catalogo de Servicos do SFN Vol. VI 5.12", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.bcb.gov.br/estabilidadefinanceira/exibenormativo?tipo=Resolução%20BCB&numero=195", "source_class": "authoritative_primary", "source_title": "Regulamento do Sistema de Pagamentos Instantaneos (SPI), anexo a Resolucao BCB n. 195/2022, consolidated text, VersaoNormativo 6", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the SPI runs every hour of every day with no scheduled cutoff (art. 8), the definition of an instant payment as continuously available (art. 2 inciso II), and direct participant uptime duties (arts. 15, 18). Regulamento Pix arts. 79, 80 and 82 (DICT hours since 2023, the 8h-20h customer facing window, and UTC messaging against Brasilia rule time) and Manual de Tempos do Pix 7.0 sections 1.1, 1.2 and 2 (40 second and 45 minute clocks, 30 and 60 minute fraud hold with the withdrawal, change and smart transfer exceptions) were also read and match the record; this corroboration records the Regulamento do SPI source only." } ] }, "rail_name": "Pix", "governing_authority": "Banco Central do Brasil", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "pix:liability", "id": "liability", "rail": "pix", "kind": "rail-fact", "facet": "liability", "name": "Who bears the loss when a Pix goes wrong?", "statement": "The Regulamento allocates loss between participants and says very little about the end user. Three allocations are express: the participant that asked for a MED return is responsible for it, the receiving user's PSP answers for damage caused by not returning where it rejected an infraction notice without just cause, and the payer's PSP eats a faulty Pix Automatico payment out of its own pocket. Beyond that the rulebook works by duty rather than by liability: participants must reject suspect payments, must hold suspect funds, must run a fraud risk management solution and must block accounts tied to accepted infraction notices, and a failure to do those is a supervision and penalty matter with the BCB, not a stated compensation right. What the user can claim from their own bank comes from Brazilian law outside this rulebook, and the BCB itself has recorded that the Pix rulebook is contractual rather than a binding regulatory act.", "details": [ { "label": "The requesting participant owns the MED return", "value": "Whoever asked for the MED return carries it. The bank that opened the case answers for it, subject only to what the receiving bank separately answers for under art. 41-I.", "citation": "Resolucao BCB n. 1/2020 and annexed Regulamento Pix, consolidated text, VersaoNormativo 41, art. 41-H", "rests_on": "rule" }, { "label": "A bad rejection makes the receiving bank answerable", "value": "A receiving bank that turns down an infraction notice without good reason, where that notice was attached to a return request, is on the hook for the damage its refusal causes. A second ground once existed, refusing the return for want of the customer's authorization; it was dropped in 2024.", "citation": "Resolucao BCB n. 1/2020 and annexed Regulamento Pix, consolidated text, VersaoNormativo 41, art. 41-I caput inciso I (wording by Resolucao BCB n. 269/2022) and inciso II (revoked by Resolucao BCB n. 403 de 22/7/2024)", "rests_on": "rule" }, { "label": "Pix Automatico: the payer's bank pays first", "value": "On this one product the paying bank absorbs the loss up front. It reimburses its own customer in full, from its own money, and then goes to the DICT to try to collect from the other side, where it gets paid only if the funds are still sitting there. The rulebook makes the point explicitly: choosing to offer Pix Automatico is accepting this, whatever the state of the receiving account.", "citation": "Resolucao BCB n. 1/2020 and annexed Regulamento Pix, consolidated text, VersaoNormativo 41, arts. 41-A par. 2 incisos I and II and 11-V", "rests_on": "rule" }, { "label": "The duty to reject, on both sides", "value": "Both banks carry a list of situations in which they must refuse a payment rather than exercise judgment. Well founded suspicion of fraud binds both sides. Beyond that, each side must refuse what it is placed to check: the paying bank where it cannot properly authenticate its own customer or that customer is under United Nations sanctions, the receiving bank where it cannot properly identify the payee. Product rules add more. A Pix Automatico payment that departs from what was agreed is refused on either side, measured by the paying bank against the customer's authorization and by the receiving bank against the charge behind it. Withdrawal and change payments are refused where they break their parameters (paying side) or arrive through a withdrawal agent that was never approved (receiving side). And the paying bank must refuse once the authorization time has run out. Arts. 38 and 39 carry the complete lists.", "citation": "Resolucao BCB n. 1/2020 and annexed Regulamento Pix, consolidated text, VersaoNormativo 41, arts. 38 incisos I, II, IV, V, VI and VII, and 39 incisos I to IV (wordings by Resolucoes BCB n. 181/2022, n. 402/2024 and n. 425/2024)", "rests_on": "rule" }, { "label": "The duty to freeze on arrival", "value": "Suspicion obliges a hold, not an enquiry. Where the receiving bank suspects fraud it locks the funds at the same moment it credits them, for no more than 72 hours, and tells the customer straight away. The assessment has a required minimum content, the same one described in pix:decision-points: facts about the receiving customer and their account, the payer's profile and history with the receiver, and the timing of the payment, with room for anything else the bank thinks relevant.", "citation": "Resolucao BCB n. 1/2020 and annexed Regulamento Pix, consolidated text, VersaoNormativo 41, art. 39-B caput and paragraphs 1 to 6 and 8 (introduced by Resolucao BCB n. 147/2021, in force from 2021-11-16)", "rests_on": "rule" }, { "label": "The hold is no longer limited to individuals", "value": "Precautionary holds used to be confined to accounts of natural persons, with sole traders carved out. Resolucao BCB n. 506 de 26/9/2025 removed that limit, so a company's account is now exposed to the same freeze on suspicion.", "citation": "Resolucao BCB n. 1/2020 and annexed Regulamento Pix, consolidated text, VersaoNormativo 41, art. 39-B par. 7 (revoked by Resolucao BCB n. 506/2025)", "rests_on": "rule" }, { "label": "Fraud risk management is a stated obligation with contents", "value": "Fraud control is a named duty with minimum contents, not a matter of good practice. The article asks for robust security across the whole Pix lifecycle, from account opening and key management through authenticating payers, identifying payees and starting a payment, to money moving in and out of accounts, and for that last area it sets a floor. The bank must run a fraud engine fed at least by the DICT's security data and able to spot payments that do not fit the customer, so that it can act on them through the tools the rules already give it: freezing on arrival, refusing outright, or taking the longer authorization window. Around the engine it keeps its own security database on customers, refreshed from the DICT at least twice a year, and keeps the engine's documentation ready for the BCB. Separately, it must publish anti fraud guidance wherever a customer can start a Pix.", "citation": "Resolucao BCB n. 1/2020 and annexed Regulamento Pix, consolidated text, VersaoNormativo 41, art. 89 caput incisos I to V and paragraphs 1, 3 and 4 (introduced by Resolucao BCB n. 403 de 22/7/2024, in effect from 2024-11-01)", "rests_on": "rule" }, { "label": "An accepted notice shuts the account out of Pix", "value": "Accepting an infraction notice, or raising a fraud marking of its own, obliges the bank to shut that customer and that account out of Pix in both directions, with returns the only thing still allowed. If the customer complains, the bank has to look again, and lift the block if it decides the notice ought to be cancelled.", "citation": "Resolucao BCB n. 1/2020 and annexed Regulamento Pix, consolidated text, VersaoNormativo 41, art. 89 paragraphs 2 (wording by Resolucao BCB n. 506/2025) and 10 (by Resolucao BCB n. 425/2024)", "rests_on": "rule" }, { "label": "Access devices must be registered", "value": "For a natural person, key operations and payments must start from a device registered in advance; returns are exempt. An unregistered device may be allowed to pay only within a value and on terms the BCB fixes in a separate document.", "citation": "Resolucao BCB n. 1/2020 and annexed Regulamento Pix, consolidated text, VersaoNormativo 41, art. 89 paragraphs 6, 7, 8 and 9 (wordings by Resolucao BCB n. 457 de 6/3/2025)", "rests_on": "rule" }, { "label": "Where disagreements go", "value": "When the parties cannot sort it out themselves, disputes about applying the Regulamento, between banks or between a bank and a customer, follow procedures the BCB sets in a manual of its own. Payments started through a payment initiation service take a different route: either the complaint handling of Resolucao Conjunta n. 1 de 4/5/2020, or the dispute machinery Open Finance participants run among themselves.", "citation": "Resolucao BCB n. 1/2020 and annexed Regulamento Pix, consolidated text, VersaoNormativo 41, art. 91 caput (wording from 2023-01-01, Resolucao BCB n. 269/2022) and art. 91 par. unico incisos I and II", "rests_on": "rule" }, { "label": "Non compliance is a supervision matter", "value": "Enforcement runs to the BCB, not between the parties. The Regulamento devotes a chapter to checking whether participants are following it and to the penalties that follow. Leaving Pix does not close the door: a departing participant stays answerable for what happened on its watch, through dispute resolution or penalty proceedings.", "citation": "Resolucao BCB n. 1/2020 and annexed Regulamento Pix, consolidated text, VersaoNormativo 41, Chapter XIX (title as amended by Resolucao BCB n. 161 de 10/11/2021) and art. 30 par. 2", "rests_on": "rule" }, { "label": "What the BCB says the rulebook is", "value": "The BCB has put on record what kind of instrument the Pix rulebook is. In the note appended to IN BCB n. 512/2024 it relies on Voto 280/2021-BCB to say the Regulamento and everything that fills it out are contractual rather than binding regulation, which is its reason for changing them without prior regulatory impact analysis. That matters to anyone reasoning about what a customer can sue on.", "citation": "Instrucao Normativa BCB n. 512/2024, consolidated text, VersaoNormativo 4, NOTA appended to the published text, citing Voto 280/2021-BCB paragraph 8", "rests_on": "guidance" } ], "exceptions": [ "The Regulamento allocates loss between participants. It states no compensation right for an end user against their own PSP, and the drafter read no Brazilian consumer or banking statute, so what a defrauded payer can claim is [Unverified] here.", "Liability for a payment initiated through a payment initiation service is not settled by these articles; it runs through the Open Finance framework and Resolucao Conjunta n. 1/2020 (Regulamento Pix art. 91 par. unico).", "The Manual de Resolucao de Disputas and the Manual de Penalidades, both listed on the BCB Pix normas page, set the actual procedures and the actual penalties. Neither was opened for this record, so this record describes the hooks and not the outcomes.", "Just cause for rejecting an infraction notice is not defined in the Regulamento. The DICT manual requires the rejecting participant to give its reasons in free text, which leaves the standard to the parties and, on dispute, to the BCB (Manual Operacional do DICT 8.5 section 10.1).", "A participant that fails to keep its Conta PI funded bears the liquidity risk expressly, and the Regulamento records that participants declare themselves aware of operational and liquidity risk on joining (Regulamento Pix art. 88)." ], "applies_to": "allocation of loss and of duty between Pix participants for a payment that was fraudulent, erroneous or wrongly authorized, and the hooks by which the BCB enforces it", "caveat": "Do not read this facet as an answer to who pays the victim. Pix allocates duties between banks and leaves the customer's remedy to law and contract outside the rulebook, and the BCB itself calls the rulebook contractual. The one place the rules do reach the customer directly is Pix Automatico, where the payer's own bank must make them whole regardless of recovery.", "related": [ "pix:finality", "pix:return", "pix:recall", "pix:refund", "pix:consumer-law", "pix:participants", "pix:decision-points" ], "basis": { "sources": "Regulamento Pix, annex to Resolucao BCB n. 1/2020, consolidated version 41, read for this record from the BCB normativos data endpoint: arts. 11-V, 30 par. 2, 38, 38-A, 39, 39-A, 39-B, 39-C, 41-A, 41-H, 41-I, 78-F to 78-N, 88, 89, 91, and Chapter XIX. Manual Operacional do DICT, version 8.5, section 10.1 on closing an infraction notice. Instrucao Normativa BCB n. 512 de 30/8/2024, the NOTA appended to its published text, for the BCB's own characterisation of the Regulamento. No secondary source was used. The Manual de Resolucao de Disputas and the Manual de Penalidades were not opened.", "confidence": "high" }, "currency": { "effective_since": "2024-11-01", "effective_to": null, "effective_note": "The core allocation articles 41-H and 41-I date from Resolucao BCB n. 103 de 8/6/2021, in effect from 2021-11-16. The fraud risk management duties in art. 89, which are the bulk of this record, were introduced by Resolucao BCB n. 403 de 22/7/2024 with effect from 2024-11-01 and have been amended repeatedly since, most recently by Resolucao BCB n. 506 de 26/9/2025 which revoked the natural person only limit on precautionary holds. Art. 39-C, requiring participants to adopt minimum BCB fraud assessment criteria, was added by the same resolution and points to a document that was not located for this record.", "source_edition": "Regulamento Pix (Resolucao BCB n. 1/2020), consolidated version 41, amendments listed through Resolucao BCB n. 559 de 23/4/2026; Manual Operacional do DICT 8.5; IN BCB n. 512/2024 consolidated text", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.bcb.gov.br/estabilidadefinanceira/exibenormativo?tipo=Resolução%20BCB&numero=1", "source_class": "authoritative_primary", "source_title": "Resolucao BCB n. 1/2020 and annexed Regulamento Pix, consolidated text, VersaoNormativo 41", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the requesting participant's responsibility for a MED return subject to art. 41-I (art. 41-H), the receiving bank's liability for rejecting an infraction notice without just cause and the 2024 removal of the missing-authorization ground (art. 41-I caput inciso I, inciso II revoked by Resolucao BCB n. 403/2024), the payer's bank funding a faulty Pix Automatico payment from its own money before seeking reimbursement (art. 41-A par. 2 incisos I and II), the duty to reject lists on both sides (arts. 38 and 39), the duty to freeze on arrival and its September 2025 extension to business accounts (art. 39-B, par. 7 revoked by Resolucao BCB n. 506/2025), the fraud risk management obligation covering account opening, key management, authentication and identification, initiation and the movement of funds, including the DICT fed fraud engine and the twice yearly refreshed security database (art. 89 caput incisos I to V and paragraphs 1, 3 and 4), the account block on an accepted or self raised notice (art. 89 par. 2), access device registration for natural persons (art. 89 paragraphs 6 to 9), dispute routing (art. 91), and enforcement running to the BCB with departing participants staying answerable (Chapter XIX title and art. 30 par. 2). Manual Operacional do DICT 8.5 section 10.1 and Instrucao Normativa BCB n. 512/2024's appended NOTA on the Regulamento's contractual character were also read and match the record; this corroboration records the Resolucao BCB n. 1/2020 source only." } ] }, "rail_name": "Pix", "governing_authority": "Banco Central do Brasil", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "pix:limits", "id": "limits", "rail": "pix", "kind": "rail-fact", "facet": "limits", "name": "What limits apply to a Pix, and who sets them?", "statement": "The SPI itself has no maximum payment amount. Every limit a payer meets is set by their own bank, and the BCB tells the bank how to set it. For a natural person paying another natural person, the night limit is R$1,000.00 unless the user asks for more, and the day limit must be built from a risk and behaviour profile rather than copied from a TED ceiling. Withdrawal and change have their own hard ceilings, contactless has R$500.00 per payment, a participant reaching the network through an uncertified technology provider is capped at R$15,000.00 per payment, and no participant may cap the number of Pix a user sends or receives. Cuts to a limit take effect at once; increases take between 24 and 48 hours, and 8 hours for Pix Automatico.", "details": [ { "label": "The network sets no ceiling", "value": "The SPI accepts a credit order whatever its size. There is no network transaction limit to quote, and no minimum either.", "citation": "Regulamento do Sistema de Pagamentos Instantaneos (SPI), anexo a Resolucao BCB n. 195/2022, consolidated text, VersaoNormativo 6, art. 32", "rests_on": "rule" }, { "label": "Why a bank may set a limit at all", "value": "A bank does not get to cap a customer for commercial reasons. The only grounds the rule allows are fraud risk and the risk of breaching money laundering and terrorist financing rules, judged against who the payer is and how they behave. Until September 2025 the article also told banks to look across at comparable instruments; that benchmark has been taken out.", "citation": "Resolucao BCB n. 1/2020 and annexed Regulamento Pix, consolidated text, VersaoNormativo 41, art. 37 caput (wording by Resolucao BCB n. 506/2025)", "rests_on": "rule" }, { "label": "The night limit for person to person", "value": "Between one individual and another, the default ceiling after dark is R$1,000.00, and it stands unless the customer asks for something different. Night usually means 20:00 to 06:00, or 22:00 to 06:00 where the bank offers that choice and the customer takes it. Which clock decides is the bank's call: the payer's registered home town, or Brasilia.", "citation": "Instrucao Normativa BCB n. 512/2024, consolidated text, VersaoNormativo 4, art. 3 par. 7 (wording by IN BCB n. 669 de 29/9/2025) with art. 3 paragraphs 1 to 6", "rests_on": "rule" }, { "label": "The day limit is no longer pegged to TED", "value": "Until IN BCB n. 669/2025 the day limit for a natural person receiver had to equal the daily TED limit and the limit for a legal person receiver likewise. Those provisions are revoked. In their place the bank must fit the limit to the individual user's risk and behaviour, and the minimum inputs fall into two kinds: what the bank knows about the customer (how long the relationship has run, what their transaction record shows, and how they habitually use their channels) and what it knows about the payment in hand (how strongly it was authenticated, and whether the payee was registered in advance for a daily ceiling of its own). Art. 3 par. 13 lists them.", "citation": "Instrucao Normativa BCB n. 512/2024, consolidated text, VersaoNormativo 4, art. 3 paragraphs 7 and 8 as revoked and replaced, with art. 3 par. 13 (introduced by IN BCB n. 669/2025)", "rests_on": "rule" }, { "label": "The user can drive the limit in both directions", "value": "Limit control has to live in the same app the customer pays from. It must let the customer move the general Pix limit and each product limit (contactless, Pix Automatico, Pix Agendado, and withdrawal and change), and register particular accounts or payees for a daily ceiling of their own. Both directions are required, and a customer who wants a limit of zero is entitled to it.", "citation": "Instrucao Normativa BCB n. 512/2024, consolidated text, VersaoNormativo 4, arts. 10 caput and par. 2 (incisos as amended by IN BCB n. 629 de 5/6/2025) and 3 par. 14", "rests_on": "rule" }, { "label": "Cuts are immediate, increases are slow on purpose", "value": "Tightening is instant and loosening is deliberately slow. A cut must be honoured the moment it is asked for. An increase is the bank's choice to grant or refuse, and whichever it decides, the reply and any new limit arrive no sooner than 24 hours and no later than 48 hours after the request. Pix Automatico is the exception: the bank has 8 hours at most to answer an increase. Two other changes run on the same 24 to 48 hour timetable: moving the start of the night period, and registering an account for a limit of its own.", "citation": "Instrucao Normativa BCB n. 512/2024, consolidated text, VersaoNormativo 4, arts. 11, 12 caput and paragraphs 1 and 2, 13 and 14", "rests_on": "rule" }, { "label": "Withdrawal and change carry hard ceilings", "value": "Two separate ceilings apply. The first is on the cash a withdrawal agent or withdrawal facilitator hands over in one transaction: R$3,000.00 in the daytime window of 06:00 to 20:00, R$1,000.00 overnight from 20:00 to 06:00. The second is the per period allowance a bank gives a natural person payer: at night it is fixed at exactly R$1,000.00, and by day the bank picks a figure no lower than R$1,000.00 and no higher than R$3,000.00. A customer who asks for more must be granted it up to those same figures. With Pix Troco, only the cash handed over counts against the ceiling.", "citation": "Instrucao Normativa BCB n. 512/2024, consolidated text, VersaoNormativo 4, arts. 5 and 6 caput, paragraphs 1, 3, 4 and 5", "rests_on": "rule" }, { "label": "Contactless and initiation without redirection", "value": "From 2025-12-01 a participant must set a limit on payments started by approximation. No single such payment may exceed R$500.00, the general Pix limits keep applying on top, and inside that ceiling the payer may choose a daily limit. Payments started through a shared payment initiation service without redirection carry the same R$500.00 per payment ceiling. If the user's general Pix limit is lower, it governs. Both articles are revoked from 2026-10-01 by IN BCB n. 746 de 18/6/2026, and what replaces them was not read.", "citation": "Instrucao Normativa BCB n. 512/2024, consolidated text, VersaoNormativo 4, arts. 16-A and 16-C (introduced by IN BCB n. 629/2025, in force from 2025-12-01)", "rests_on": "rule" }, { "label": "A ceiling aimed at the weakest technical link", "value": "The BCB put a R$15,000.00 per payment cap on participants it considers technically exposed: payment institutions of the kind described in Resolucao BCB n. 1/2020 art. 3 par. 9, and any participant that reaches the network through a technology service provider. Getting out from under it takes two things, an accredited provider and an independent auditor's reasonable assurance that the participant keeps its signing keys to itself and runs the other required controls. Payments to the National Treasury and FGTS Digital charges sit outside the cap whatever the participant.", "citation": "Resolucao BCB n. 1/2020 and annexed Regulamento Pix, consolidated text, VersaoNormativo 41, art. 37 paragraphs 3, 4, 5 and 6 (introduced by Resolucao BCB n. 496 de 5/9/2025, amended by n. 503 de 18/9/2025 and n. 506 de 26/9/2025)", "rests_on": "rule" }, { "label": "No limit on how many", "value": "Value is the only thing a Pix limit may measure. A participant cannot cap how many payments an end user sends or receives.", "citation": "Resolucao BCB n. 1/2020 and annexed Regulamento Pix, consolidated text, VersaoNormativo 41, art. 37-A (introduced by Resolucao BCB n. 79/2021, in force from 2021-04-01)", "rests_on": "rule" }, { "label": "Limits an operator will not see in a return", "value": "A return under Chapter XI Section I does not count against the payer's Pix limits. And each limit stands on its own: the general Pix limit and the limits for withdrawal and change, Pix Automatico and Pix Agendado are set separately, as are the limits for paying a natural person and paying a legal person.", "citation": "Instrucao Normativa BCB n. 512/2024, consolidated text, VersaoNormativo 4, arts. 3 paragraphs 11 and 12, 6 par. 2, 7 par. 6 and 9 par. 5", "rests_on": "rule" } ], "exceptions": [ "A participant may set limits above the figures in arts. 3, 7 and 9 for an individual account where the user expressly asks and the participant agrees (IN BCB n. 512/2024 art. 15). The published figures are defaults, not caps, except where the article says the limit may not exceed a number.", "Where the geolocation of the device initiating the payment cannot be identified, a participant may set different limits, including zero (IN BCB n. 512/2024 art. 3 par. 15).", "IN BCB n. 512/2024 applies only to participants acting as transactional account providers for natural person clients, and to those offering withdrawal facilitation. Limits for legal person payers are left to art. 37 of the Regulamento and the participant (IN BCB n. 512/2024 art. 2).", "The BCB may waive the R$15,000.00 cap for up to 90 days on request, where the participant documents its guarantees and security improvements and the BCB finds them adequate (Regulamento Pix art. 37 par. 5).", "Limits on device registration for unregistered access devices are set in a separate document, IN BCB n. 491 de 23/7/2024, which this record does not describe [Unverified: fetched for this record but not read].", "From 2026-10-01 IN BCB n. 746/2026 revokes arts. 16-A and 16-C and rewrites art. 10 par. 2 and art. 12 caput, so the contactless figures in this record have a known expiry date. The text of IN BCB n. 746/2026 was not read for this record [Unverified]." ], "applies_to": "value limits faced by a payer sending a Pix, set by the payer's transactional account provider under BCB rules, and the ceilings the BCB sets directly", "caveat": "There is no such thing as the Pix limit. Ask which product, which period, which side, and whether the user has asked to change it. The one number an operator can rely on without asking is the R$1,000.00 night default for a payment to a natural person, and even that yields to an express request from the user. Since IN BCB n. 669/2025 there is no longer any regulated floor tied to TED, so two banks may quite properly give the same customer very different day limits.", "related": [ "pix:hours", "pix:consumer-law", "pix:participants", "pix:settlement", "pix:decision-points" ], "basis": { "sources": "Instrucao Normativa BCB n. 512 de 30/8/2024, consolidated text read for this record from the BCB normativos data endpoint, as amended by IN BCB n. 562/2024, n. 629/2025, n. 669/2025 and n. 746/2026: arts. 2, 3, 5, 6, 7, 9, 10, 11, 12, 13, 14, 15, 16, 16-A, 16-B, 16-C and 18. Regulamento Pix, annex to Resolucao BCB n. 1/2020, consolidated version 41: arts. 37 and 37-A. Regulamento do SPI, annex to Resolucao BCB n. 195/2022: art. 32. No secondary source was used. The record does not describe IN BCB n. 491/2024 on access device registration, which sets separate limits for unregistered devices.", "confidence": "high" }, "currency": { "effective_since": "2025-09-29", "effective_to": null, "effective_note": "The night limit figure of R$1,000.00 has been in IN BCB n. 512/2024 since publication on 2024-09-03, but the article that now carries it was rewritten by IN BCB n. 669 de 29/9/2025, which also revoked the TED peg for day limits and added the risk profile criteria. The contactless articles took effect 2025-12-01; IN BCB n. 746/2026 rewrites art. 10 par. 2 and art. 12 caput and revokes arts. 16-A and 16-C from 2026-10-01, which will supersede the contactless detail line. The R$15,000.00 PSTI cap came in with Resolucao BCB n. 496 de 5/9/2025. Limits move faster than anything else on this rail; treat any figure older than a quarter as suspect.", "source_edition": "IN BCB n. 512/2024, consolidated text as published on the BCB normativos page, amendments listed through IN BCB n. 746 de 18/6/2026; Regulamento Pix (Resolucao BCB n. 1/2020), consolidated version 41; Regulamento do SPI (Resolucao BCB n. 195/2022)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.bcb.gov.br/estabilidadefinanceira/exibenormativo?tipo=Instrução%20Normativa%20BCB&numero=512", "source_class": "authoritative_primary", "source_title": "Instrucao Normativa BCB n. 512/2024, consolidated text, VersaoNormativo 4", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the R$1,000.00 night default for an individual payer subject to an express user request (art. 3 par. 7), the risk and behaviour criteria that replaced the TED peg for the day limit (art. 3 par. 13), the in app limit panel reaching every product limit down to zero (art. 10 caput and paragraphs 1, 2 and 14), the immediate cut versus 24 to 48 hour increase timing with the 8 hour Pix Automatico exception (arts. 11, 12, 13 and 14), the withdrawal and change ceilings of R$3,000.00 by day and R$1,000.00 by night (arts. 5 and 6), the R$500.00 contactless and shared initiation ceilings effective 2025-12-01 (arts. 16-A and 16-C, both listed for revocation from 2026-10-01 by Instrucao Normativa BCB n. 746/2026), and that a return does not count against the payer's limits (art. 3 paragraphs 11 and 12). Regulamento Pix art. 32 (no SPI network ceiling), art. 37 (fraud and money laundering basis for a limit, TED benchmark removed by Resolucao BCB n. 506/2025) and art. 37 paragraphs 3 to 6 (the R$15,000.00 technically exposed participant cap and its exemptions) were also read and match the record; this corroboration records the Instrucao Normativa BCB n. 512/2024 source only." } ] }, "rail_name": "Pix", "governing_authority": "Banco Central do Brasil", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "pix:messages", "id": "messages", "rail": "pix", "kind": "rail-fact", "facet": "messages", "name": "What messages carry a Pix, and what is not a message at all?", "statement": "Pix runs on ISO 20022 XML, but only for settlement. A payment is a pacs.008 answered by a pacs.002; a return is a pacs.004 answered by another pacs.002; Pix Automatico adds the pain and camt families for authorizations and instructions. Everything about disputes lives somewhere else entirely: infraction notices, return requests and the whole fraud recovery run over the DICT's REST API, so an operator looking for a dispute message in the catalog will not find one. The catalog also has no request for payment and no recall: pain.013 here is a recurring payment instruction, not an RFP, and there is no camt.056. Two catalog versions are usually live at once, published about six months before they reach production.", "details": [ { "label": "The standard and the envelope", "value": "Messages are ISO 20022 XML, restricted to what the BCB needs, and each one is wrapped with a business application header (head.001) inside an Envelope element. Message versions are named in the XSD filename and do not track the catalog version, so one catalog release can carry several message versions.", "citation": "Catalogo de Servicos do SFN, Volume VI, Pagamentos Instantaneos, versao 5.12, dated 2026-03-27, pp. 10 and 11", "rests_on": "rule" }, { "label": "The payment pair", "value": "A payment is a pacs.008 and its answer is a pacs.002. The pacs.008 travels twice, from the payer's bank to the SPI and from the SPI to the receiving bank, and pacs.002 travels back on the same path. Nothing else is needed for a working payment, though an admi.002 may report a non terminal error along the way.", "citation": "Catalogo de Servicos do SFN, Volume VI, Pagamentos Instantaneos, versao 5.12, dated 2026-03-27, pp. 14 and 18", "rests_on": "rule" }, { "label": "The return pair, and its four reasons", "value": "A return is a pacs.004 with its own pacs.002 answer. The reason field carries exactly four values, and the same four in catalog 5.12.1 and 5.13.1: MD06 where the receiving customer asked for it, SL02 for withdrawal and change, BE08 for an operational failure under the special mechanism, and FR01 for well founded suspicion of fraud under the same mechanism.", "citation": "Definicoes detalhadas das mensagens do Catalogo do SPI, archives spi.5.12.1.zip and spi.5.13.1.zip, archives spi.5.12.1.zip and spi.5.13.1.zip, PACS004.xlsx domain table for RtrRsnInf/Rsn/Cd", "rests_on": "rule" }, { "label": "Rejection reasons live on the pacs.002", "value": "Catalog 5.12.1 carries 43 rejection reason codes on the pacs.002; 5.13.1 adds DS02 and DU03 for 45. Each entry in the domain table names which side raises it, the SPI or the receiving bank, which is information the ISO code name does not carry. The status field itself is separate and holds only four values.", "citation": "Definicoes detalhadas das mensagens do Catalogo do SPI, archives spi.5.12.1.zip and spi.5.13.1.zip, archives spi.5.12.1.zip and spi.5.13.1.zip, PACS002.xlsx domain tables for StsRsnInf/Rsn/Cd and TxSts; release notes in spi.5.13.1.zip naming DS02 and DU03 as additions", "rests_on": "rule" }, { "label": "Two channels, and the first message picks one", "value": "The primary channel carries anything expecting an immediate answer; the secondary carries what does not. A pacs.008 goes to the secondary channel only when its payment priority type is PAGAGD, meaning a scheduled payment. Whichever channel that first pacs.008 takes governs every later message in the operation. A return breaks the pattern: a pacs.004 and its answers always take the primary channel whatever the original payment did.", "citation": "Catalogo de Servicos do SFN, Volume VI, Pagamentos Instantaneos, versao 5.12, dated 2026-03-27, pp. 13 and 14", "rests_on": "rule" }, { "label": "Pix Automatico: authorization messages", "value": "Setting up a recurring authorization uses pain.009 to ask, pain.012 to answer and confirm, and pain.011 to cancel, with a pain.012 acknowledging the cancellation. All of them pass through the SPI, which relays between the two banks rather than acting on them.", "citation": "Catalogo de Servicos do SFN, Volume VI, Pagamentos Instantaneos, versao 5.12, dated 2026-03-27, p. 19", "rests_on": "rule" }, { "label": "Pix Automatico: instruction messages", "value": "Once an authorization exists, the payee's bank sends payment instructions as pain.013 and the payer's bank acknowledges with pain.014. On the due date the payer's bank starts an ordinary scheduled payment. Cancelling an instruction or a charge before it settles is a camt.055 answered by a camt.029, and either side may send it.", "citation": "Catalogo de Servicos do SFN, Volume VI, Pagamentos Instantaneos, versao 5.12, dated 2026-03-27, p. 20", "rests_on": "rule" }, { "label": "Reporting payments that never touched the SPI", "value": "Payments settled inside a participant still have to be visible to the fraud tracing machinery, so participants report them with trck.002 and the system answers with camt.025 to say whether the record was stored. A failed store has to be corrected and resent until it succeeds. This pair exists because tracing money across hops only works if the map includes payments that never reached the SPI.", "citation": "Catalogo de Servicos do SFN, Volume VI, Pagamentos Instantaneos, versao 5.12, dated 2026-03-27, pp. 18 and 19", "rests_on": "rule" }, { "label": "Disputes are REST, not ISO", "value": "Nothing in the ISO catalog carries a dispute. Infraction notices, return requests and every stage of a funds recovery are endpoints on the DICT API, with names like createFundsRecovery, createFraudMarker and RefundFundsRecovery, and their domain values are lowercase words such as refund_request, scam or mule_account rather than ISO codes. An integration that only speaks ISO cannot participate in the MED at all.", "citation": "Manual Operacional do Diretorio de Identificadores de Contas Transacionais (DICT), versao 8.5, effective 2026-09-01 and 2026-10-26, sections 10, 10.1, 17 and 20.1.1", "rests_on": "rule" }, { "label": "Resending is safe, by design", "value": "The rail guarantees idempotency with a 24 hour window on payments and returns, and it is enforced at the level of the individual operation rather than the message. Resending an operation the other side has already processed returns the earlier answer instead of doing the work twice; the same identifier carrying different content returns an error. The key differs by message: IdFimAFim on a pacs.008, IdOperacao on a pacs.004, idSolicitacaoRecorrencia on a pain.009.", "citation": "Catalogo de Servicos do SFN, Volume VI, Pagamentos Instantaneos, versao 5.12, dated 2026-03-27, pp. 15, 16 and 18", "rests_on": "rule" }, { "label": "Two catalogs alive at once", "value": "A catalog release reaches the SPI about three months after the BCB publishes it, and the two most recent releases were spaced identically: 5.12 was published 2026-03-27 and went into SPI production 2026-06-28, 5.13 was published 2026-07-24 and goes into production 2026-10-25, each 93 days. Participant testing opens about two weeks before production, on 2026-06-15 and 2026-10-13. Through the whole gap the site lists both releases with their full document sets, so a reader can meet either, and a code that exists only in the newer one is not valid yet. Each message definition archive carries release notes cumulative back to the first catalog of November 2019 and a spreadsheet of what changed against the preceding release.", "citation": "Comunicacao eletronica de dados page on bcb.gov.br, read through its public page data endpoint: the Catalogo de Servicos do SFN schedules for versions 5.12 and 5.13, publication, homologation and SPI production dates, under Comunicados 44.424 and 45.630; Definicoes detalhadas das mensagens do Catalogo do SPI, archives spi.5.12.1.zip and spi.5.13.1.zip, NotasDeVersao.pdf and notasVersaoDiff/NotasVersaoDiff5.13.1v5.12.1.xlsx in spi.5.13.1.zip", "rests_on": "rule" } ], "exceptions": [ "There is no request for payment on Pix. pain.013 is a Pix Automatico or scheduled payment instruction between banks, not a request a payee sends a payer, and it travels only on the secondary channel (Catalogo 5.12 pp. 13 and 20).", "There is no camt.056 and no other recall message. The only cancellations in the catalog act before a payment settles (Catalogo 5.12 message chapter).", "admi.002 carries no code list at all. It reports message level and non terminal processing errors in free text, and it travels back on whichever channel brought the message it answers (Catalogo 5.12 pp. 13 and 17).", "pibr.001 and pibr.002 move no money. They are connectivity tests, and pibr.002 echoes back on the channel the pibr.001 arrived on (Catalogo 5.12 pp. 13, 17 and 18).", "Catalog 5.13.1 also removes Pix Automatico codes across pain.011, pain.012, pain.014 and camt.029 relative to 5.12.1, so an integration built on the current catalog needs work before 2026-10-25. The exact count was taken from Orca's Pix rail brief (docs/rails/pix.md) and not recounted for this record [Unverified]." ], "applies_to": "the ISO 20022 messages carried by the SPI for Pix, and the boundary between them and the DICT REST interface", "caveat": "The catalog is not the whole interface. Half of what an operator has to build for Pix, everything to do with keys and everything to do with disputes, is REST against the DICT and is specified in a different manual on a different release cycle. Do not size a Pix integration from the message catalog alone, and do not expect an ISO code to exist for a dispute step.", "related": [ "pix:settlement", "pix:return", "pix:recall", "pix:hours", "pix:participants" ], "basis": { "sources": "Catalogo de Servicos do SFN, Volume VI, Pagamentos Instantaneos, version 5.12 dated 2026-03-27, read for this record: pp. 9 to 22, covering the envelope and versioning, date and time, transmission channels, idempotency and the message chapter. Definicoes detalhadas das mensagens do Catalogo do SPI, archives spi.5.12.1.zip and spi.5.13.1.zip, both fetched and opened for this record: PACS004.xlsx and PACS002.xlsx domain tables. Manual Operacional do DICT, version 8.5, sections 10, 10.1, 17 and 20, for the REST side. Comunicacao eletronica de dados page on bcb.gov.br, read through its public page data endpoint, for catalog versions and production dates. No secondary source was used.", "confidence": "high" }, "currency": { "effective_since": "2026-06-28", "effective_to": null, "effective_note": "Catalog 5.12.1 has been in SPI production since 2026-06-28 and is the version this record describes. Catalog 5.13.1 was published 2026-07-24 and enters production 2026-10-25, adding DS02 and DU03 to the pacs.002 rejection reasons and removing nine Pix Automatico codes; the pacs.004 return reasons are unchanged between the two. On 2026-10-25 this record needs a new version, not an edit.", "source_edition": "Catalogo de Servicos do SFN Vol. VI version 5.12 dated 2026-03-27; message definition archives spi.5.12.1.zip (production 2026-06-28) and spi.5.13.1.zip (production 2026-10-25); Manual Operacional do DICT 8.5", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.bcb.gov.br/content/estabilidadefinanceira/cedsfn/Catalogos/Catalogo_de_Servicos_do_SFN_Volume_VI_Versao_512.pdf", "source_class": "authoritative_primary", "source_title": "Catalogo de Servicos do SFN, Volume VI, Pagamentos Instantaneos, versao 5.12, dated 2026-03-27", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the ISO 20022 envelope and head.001 wrapper, the pacs.008/pacs.002 payment pair, the pacs.004/pacs.002 return pair with its four reason codes unchanged between 5.12.1 and 5.13.1 (MD06, SL02, BE08, FR01, cross checked against the PACS004.xlsx domain table in spi.5.12.1.zip and spi.5.13.1.zip), the primary and secondary channel split, the absence of camt.056 and of any request for payment message, and the idempotency window. The comunicacaodados page data confirms catalog 5.12.1 SPI production on 2026-06-28 and 5.13.1 on 2026-10-25, stated plainly in the record's currency fields. Manual Operacional do DICT 8.5 sections 10, 17 and 20 were also read and support the REST-versus-ISO claim; this corroboration records the Catalogo source only." } ] }, "rail_name": "Pix", "governing_authority": "Banco Central do Brasil", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "pix:participants", "id": "participants", "rail": "pix", "kind": "rail-fact", "facet": "participants", "name": "Who can be in Pix, and what does each kind of membership let you do?", "statement": "Membership is compulsory above a size threshold and open below it. Any bank or payment institution the BCB has authorised, holding more than five hundred thousand live customer accounts, has to join; everyone else may. Once in, a participant picks one of five roles in the scheme, and separately picks whether it reaches the SPI and the DICT directly or through somebody else. Those two choices are independent, and they decide almost everything operational: whether the institution holds its own settlement account at the central bank, whether another participant vouches for it to the BCB, and whether its payments settle in central bank money at all. Participants are identified by ISPB, not by a routing number, and the BCB publishes the list.", "details": [ { "label": "Who has to join", "value": "The threshold is more than five hundred thousand live customer accounts, counting demand deposit, savings and prepaid payment accounts, at an institution the BCB has authorised to operate. Crossing it after the rule came in starts a 90 day clock to apply as a transactional account provider. Everyone below the line may join voluntarily.", "citation": "Resolucao BCB n. 1/2020 and annexed Regulamento Pix, consolidated text, VersaoNormativo 41, art. 3 caput and paragraphs 1, 2 and 3 inciso I (wording by Resolucao BCB n. 429 de 11/11/2024)", "rests_on": "rule" }, { "label": "Five roles, and they are not interchangeable", "value": "The scheme recognises the transactional account provider, which is the ordinary consumer facing role; the government entity, reserved to the National Treasury for its own collections and payments; the special settler, which exists only to settle for other participants and does not serve end users; the initiator, whose only business in Pix is payment initiation services; and the user institution, which joins solely to pay and be paid on its own account.", "citation": "Resolucao BCB n. 1/2020 and annexed Regulamento Pix, consolidated text, VersaoNormativo 41, art. 23 caput incisos I to V with paragraphs 1, 2, 3, 4 and 6 (inciso V and par. 6 added by Resolucao BCB n. 403 de 22/7/2024)", "rests_on": "rule" }, { "label": "Direct or indirect is a separate question", "value": "A Pix role says nothing about how the institution reaches the infrastructure. In the SPI, a direct participant holds its own Conta PI at the BCB and settles on it; an indirect participant settles through a direct one. Access to the DICT is likewise direct or indirect, and an institution can be direct in one and indirect in the other.", "citation": "Regulamento do Sistema de Pagamentos Instantaneos (SPI), anexo a Resolucao BCB n. 195/2022, consolidated text, VersaoNormativo 6, art. 2 inciso I and Chapter IV; Manual Operacional do Diretorio de Identificadores de Contas Transacionais (DICT), versao 8.5, effective 2026-09-01 and 2026-10-26, flows in sections 3 to 9, 15, 17 and 20, each written twice for direct and indirect access", "rests_on": "rule" }, { "label": "What a direct SPI participant signs up to", "value": "Direct access is an operational commitment, not a status. The institution has to stay connected and able to send and receive at every hour of every day, keep enough money in its Conta PI to cover its own traffic and that of everyone it settles for, keep systems able to meet the times in the Manual de Tempos, watch its own account for atypical or potentially fraudulent movement in real time and stop processing if it suspects compromise, and tell the BCB at once about anything wrong with the system.", "citation": "Regulamento do Sistema de Pagamentos Instantaneos (SPI), anexo a Resolucao BCB n. 195/2022, consolidated text, VersaoNormativo 6, arts. 17 inciso VI and 18 incisos I, II, III letters a and b, and VII (wordings by Resolucoes BCB n. 412/2024, n. 524/2025 and n. 554/2026)", "rests_on": "rule" }, { "label": "Somebody has to vouch for a smaller institution", "value": "A participant that reaches Pix through another institution is a contracting participant, and the one carrying it is the responsible participant. The responsible participant attests to the BCB that the smaller institution meets the participation requirements, checks that it follows the minimum regulation applied to it, settles for it, and reports to the BCB any sign that it is failing or has grounds for removal. It may use independent auditors to do that, and it may not use what it learns for anything else or treat contracting participants unequally.", "citation": "Resolucao BCB n. 1/2020 and annexed Regulamento Pix, consolidated text, VersaoNormativo 41, art. 27 caput incisos I to IV with paragraphs 1, 2 and 3 (wordings by Resolucoes BCB n. 429/2024, n. 506/2025 and n. 559 de 23/4/2026)", "rests_on": "rule" }, { "label": "Who is allowed to be a responsible participant is narrowing", "value": "From 2026-03-05 the role is confined to a participant that is a transactional account provider or special settler, is direct in the SPI, sits in prudential segment S1 to S4, and is not a service confederation or a credit cooperative. It must also have robust machinery and the technical and operational capacity to run risk management and anti money laundering work for itself and for those it carries.", "citation": "Resolucao BCB n. 1/2020 and annexed Regulamento Pix, consolidated text, VersaoNormativo 41, art. 26 caput incisos I to IV (wording from 2026-03-05 by Resolucao BCB n. 496 de 5/9/2025) and art. 26 par. unico", "rests_on": "rule" }, { "label": "Payment institutions can join before they are fully authorised", "value": "A payment institution that does not yet meet the criteria to be authorised becomes part of the Brazilian payment system from the moment it applies to join Pix, and until it is authorised it must meet a reduced set of rules covering operational and liquidity risk management, cyber security and cloud contracting, anti money laundering controls, and United Nations sanctions procedures. That is the door through which a great many Pix providers came in.", "citation": "Resolucao BCB n. 1/2020 and annexed Regulamento Pix, consolidated text, VersaoNormativo 41, art. 3 paragraphs 4 and 5 inciso I letters a to d (wordings by Resolucoes BCB n. 403/2024 and n. 429/2024)", "rests_on": "rule" }, { "label": "Leaving takes 90 days and does not end responsibility", "value": "Voluntary departure needs 90 days notice to the BCB, which may allow a shorter period. An institution whose participation is compulsory can only ask to leave if it is winding up its electronic money issuance or demand deposit business, and the request has to carry a closure date and a plan for closing the accounts. Either way the departing participant stays answerable for what happened while it was a member.", "citation": "Resolucao BCB n. 1/2020 and annexed Regulamento Pix, consolidated text, VersaoNormativo 41, art. 30 caput and paragraphs 1, 2, 3 and 4 (wordings by Resolucoes BCB n. 403/2024 and n. 425 de 16/10/2024)", "rests_on": "rule" }, { "label": "A responsible participant that walks away owes notice too", "value": "Ending service to a contracting participant takes 90 days notice to that participant, and the contract may set a longer one. The exception is termination for failing the participation requirements, which the contract must provide for and which needs no notice period.", "citation": "Resolucao BCB n. 1/2020 and annexed Regulamento Pix, consolidated text, VersaoNormativo 41, arts. 28 and 29 caput with paragraphs 1 and 2", "rests_on": "rule" }, { "label": "How participants are identified, and where to find them", "value": "Pix identifies institutions by ISPB, the Brazilian payment system identifier, which is what appears in messages rather than any account routing number. The BCB publishes the participant list on its own site, and the DICT manual points participants at that list when they need another participant's CNPJ, for instance to address a Pix Automatico reimbursement.", "citation": "Manual Operacional do Diretorio de Identificadores de Contas Transacionais (DICT), versao 8.5, effective 2026-09-01 and 2026-10-26, section 17.3 and its footnote 24 pointing at bcb.gov.br/estabilidadefinanceira/participantespix; Definicoes detalhadas das mensagens do Catalogo do SPI, archives spi.5.12.1.zip and spi.5.13.1.zip, spi.5.12.1.zip, PACS002.xlsx domain table entries RC09 and RC10 on participant identification", "rests_on": "rule" } ], "exceptions": [ "Indirect participation does not exempt anyone from the rules; it changes who settles and who vouches. An indirect participant still owes its own customers the experience, limit, fraud and return duties in the Regulamento.", "A special settler that would otherwise be barred from serving end users may provide payment initiation services, if it meets the requirements of Resolucao BCB n. 80 de 25/3/2021 (Regulamento Pix art. 23 par. 5, added by Resolucao BCB n. 403/2024).", "Participants reaching the network through a technology service provider, and payment institutions of the kind in Resolucao BCB n. 1/2020 art. 3 par. 9, face a R$15,000.00 per payment ceiling unless they clear the accreditation and audit conditions (Regulamento Pix art. 37 paragraphs 3 and 4).", "The procedures for joining, changing role, changing access method or changing responsible participant live in Instrucao Normativa BCB n. 511 de 30/8/2024, and the procedures for direct SPI participation and opening a Conta PI in IN BCB n. 243 de 16/3/2022. Neither was read for this record, so this record describes the scheme and not the application process.", "Minimum capital for participation is set separately, in IN BCB n. 16 de 18/9/2020 and IN BCB n. 748 de 18/6/2026, neither of which was read [Unverified: titles taken from the BCB Pix normas page]." ], "applies_to": "membership of the Pix arrangement and of the SPI and DICT infrastructures, and the obligations each form of membership carries", "caveat": "Ask two questions about any Pix counterparty, not one. Its scheme role tells you what it is allowed to do with end users; its access method tells you whether its payments touch central bank money and who answers for it to the BCB. A large consumer brand can be an indirect participant riding on somebody else's Conta PI, and the institution actually settling and vouching is the one whose failure would take the brand offline.", "related": [ "pix:settlement", "pix:limits", "pix:liability", "pix:messages", "pix:hours" ], "basis": { "sources": "Resolucao BCB n. 1 de 12/8/2020, consolidated text read for this record from the BCB normativos data endpoint: art. 3 with its paragraphs. Regulamento Pix, annex to the same resolution, consolidated version 41: Chapter VII in full, arts. 23 to 32, with art. 37. Regulamento do SPI, annex to Resolucao BCB n. 195/2022: art. 2, Chapter IV and arts. 15 to 18. Manual Operacional do DICT, version 8.5: the direct and indirect access flows throughout, and section 17.3 with footnote 24. Definicoes detalhadas das mensagens do Catalogo do SPI, spi.5.12.1.zip, PACS002.xlsx. No secondary source was used. The BCB participant list page itself was not opened for this record, and the Instrucoes Normativas on joining and on capital were not read.", "confidence": "high" }, "currency": { "effective_since": "2026-03-05", "effective_to": null, "effective_note": "The membership threshold and the core roles date from the original 2020 texts. The user institution role was added by Resolucao BCB n. 403 de 22/7/2024. The narrowing of who may act as a responsible participant, to direct SPI participants in segments S1 to S4 excluding confederations and credit cooperatives, takes effect 2026-03-05 under Resolucao BCB n. 496 de 5/9/2025 and is the newest change in this record. Resolucao BCB n. 559 de 23/4/2026 further reworded art. 27 inciso I. Existing arrangements that no longer qualify under the narrowed art. 26 will have to move, and this record does not describe how [Unverified].", "source_edition": "Resolucao BCB n. 1/2020 and its annexed Regulamento, consolidated version 41, amendments listed through Resolucao BCB n. 559 de 23/4/2026; Regulamento do SPI (Resolucao BCB n. 195/2022) consolidated text; Manual Operacional do DICT 8.5; SPI catalog 5.12.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.bcb.gov.br/estabilidadefinanceira/exibenormativo?tipo=Resolução%20BCB&numero=1", "source_class": "authoritative_primary", "source_title": "Resolucao BCB n. 1/2020 and annexed Regulamento Pix, consolidated text, VersaoNormativo 41", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the 500,000 account compulsory membership threshold and 90 day clock (art. 3), the five scheme roles including the 2024-added user institution role (art. 23 incisos I to V, checked as role names only, not as a translated descriptive list), the responsible participant duties and the 2026-03-05 narrowing to direct SPI participants in segments S1 to S4 (arts. 26, 27), and the 90 day departure notice (art. 30). Regulamento do SPI arts. 2, and Chapter IV (direct versus indirect access) and Manual Operacional do DICT 8.5 section 17.3 footnote 24 (participant list pointer) were also read and match the record; this corroboration records the Resolucao BCB n. 1/2020 source only." } ] }, "rail_name": "Pix", "governing_authority": "Banco Central do Brasil", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "pix:recall", "id": "recall", "rail": "pix", "kind": "rail-fact", "facet": "recall", "name": "Can the payer's side pull a Pix back, and what does asking actually do?", "statement": "There is no recall message on Pix. The catalog has no camt.056 and nothing equivalent, and a settled credit order is irrevocable. What the payer's PSP has instead is the Mecanismo Especial de Devolucao, worked through the DICT REST interface rather than through ISO messages, and it opens only on three grounds: well founded suspicion of fraud, an operational failure in a participant's own systems, or a faulty Pix Automatico payment. Fraud cases run as a Recuperacao de Valores, which the DICT itself instruments: it traces where the money went across several hops, picks a path, raises infraction notices, and the receiving banks must freeze immediately. A dispute about the goods or service is not a ground, and money that reached a good faith third party is out of scope.", "details": [ { "label": "No cancellation, no recall message", "value": "Two things close this door. Settlement cannot be undone, and the rulebook hands the paying side no power to undo it anyway. The message catalog matches: there is no camt.056 and nothing playing its part. The two cancellation messages that do exist, camt.055 and pain.011, work on a future debit or on a standing Pix Automatico permission, so both are spent by the time a payment settles.", "citation": "Regulamento do Sistema de Pagamentos Instantaneos (SPI), anexo a Resolucao BCB n. 195/2022, consolidated text, VersaoNormativo 6, art. 40; Catalogo de Servicos do SFN, Volume VI, Pagamentos Instantaneos, versao 5.12, dated 2026-03-27, message chapter pp. 17 to 21 (absence of a recall message)", "rests_on": "rule" }, { "label": "What the special mechanism is for", "value": "The MED is the rulebook's answer to money that should not have gone where it went, and it has exactly three doors. Two are about something breaking: a failure in the IT systems of either bank in the chain, and a Pix Automatico payment the payer's bank should not have let through, whether it went out through that bank's own error, had no live authorization behind it, or departed from the terms the customer authorized. The third is fraud, where the suspicion that Pix was used to commit it is well founded.", "citation": "Resolucao BCB n. 1/2020 and annexed Regulamento Pix, consolidated text, VersaoNormativo 41, art. 41-B caput incisos I, II and III (wording by Resolucao BCB n. 402 de 22/7/2024)", "rests_on": "rule" }, { "label": "Two grounds it never covers", "value": "Two doors are shut. Where fraud money has landed with a third party acting in good faith, the mechanism does not reach it; and an argument about the deal behind the payment belongs to the parties, not to the MED. Operational failure is narrowed too: if the customer really did send that payment and the amount they entered really did reach the payee, nothing failed.", "citation": "Resolucao BCB n. 1/2020 and annexed Regulamento Pix, consolidated text, VersaoNormativo 41, arts. 41-B par. 1 incisos I and II (by Resolucao BCB n. 167/2021) and 41-B par. 3 (by Resolucao BCB n. 403 de 22/7/2024)", "rests_on": "rule" }, { "label": "Who actually sends the money back", "value": "Every MED return is executed by the receiving customer's bank; the payer's bank never touches the other account. Usually the trigger is a request the payer's bank sends through the DICT, after which it waits. The receiving bank may also act without being asked: where the failure was in its own systems, where it detected the conduct itself, or where it had placed a hold and now judges the suspicion well founded.", "citation": "Resolucao BCB n. 1/2020 and annexed Regulamento Pix, consolidated text, VersaoNormativo 41, art. 41-C caput incisos I and II with inciso II letters a, b and c (wording by Resolucao BCB n. 269/2022 and n. 402/2024)", "rests_on": "rule" }, { "label": "The request goes over DICT, not over ISO", "value": "Asking is a REST call, not a message on the settlement rail. The request names the payment being contested, by its EndToEndId or, for a return, its RtrId, states an amount, and picks one of exactly three reasons: fraud where the suspicion is well founded, pix_automatico where the payer's bank sent a recurring payment it should not have, and operational_flaw where the payer's bank broke something. Free text comments ride along.", "citation": "Manual Operacional do Diretorio de Identificadores de Contas Transacionais (DICT), versao 8.5, effective 2026-09-01 and 2026-10-26, section 17, opening field table", "rests_on": "rule" }, { "label": "For fraud, the DICT drives the whole thing", "value": "A fraud case runs as a Recuperacao de Valores, and almost nothing in it is decided by a person. The recovering bank makes one move, opening the case against the contested payment, which becomes the root transaction. Everything between that and the money coming back is the DICT's own work: it assembles the payments made onward out of the root account into a tracking graph, each further layer being what the previous layer's receivers then paid away; it narrows the graph to the ordered route the funds most likely took as they were dispersed; and it raises the infraction notices against the payments on that route itself, which the banks receiving them answer by freezing the funds at once, before anyone has assessed anything. Human judgment re-enters at two points only: each notified bank rules on whether its own customer really was part of spreading the money, and requests for repayment, with the repayment itself where a balance survives, follow from those rulings.", "citation": "Manual Operacional do Diretorio de Identificadores de Contas Transacionais (DICT), versao 8.5, effective 2026-09-01 and 2026-10-26, section 20 opening paragraphs and graph depth note; section 20.1 stage list I to VI", "rests_on": "rule" }, { "label": "The window to ask is 80 days", "value": "The contested transaction must fall inside a window the DICT checks on opening: 80 days, whether it is an original payment (pacs.008) or a return (pacs.004). A transaction gets one Recuperacao de Valores in its lifetime, even if that one is cancelled, and none at all if a standalone infraction notice has already contested it.", "citation": "Manual Operacional do Diretorio de Identificadores de Contas Transacionais (DICT), versao 8.5, effective 2026-09-01 and 2026-10-26, section 20.1.1 (the 80 day figure for a pacs.004 applies from 2026-09-01; version 8.4 said 30 days)", "rests_on": "rule" }, { "label": "Asking freezes money immediately", "value": "An infraction notice is not a question, it is an instruction to freeze. The receiving bank must lock down the amount asked for on receipt, up to whatever balance is there, and keep topping the block up as new money arrives until it reaches the figure. Where several recoveries land on the same payment the amounts stack, capped at the payment itself.", "citation": "Manual Operacional do Diretorio de Identificadores de Contas Transacionais (DICT), versao 8.5, effective 2026-09-01 and 2026-10-26, section 20.1.4; Resolucao BCB n. 1/2020 and annexed Regulamento Pix, consolidated text, VersaoNormativo 41, art. 41-D caput inciso II and par. 1 (wording by Resolucao BCB n. 559 de 23/4/2026, in force from 2026-07-01)", "rests_on": "rule" }, { "label": "The recovering bank must police its own request", "value": "The bank that opened the case also has to judge its own customer's story, and must kill the case where it decides this is not fraud or a scam, even if the other banks have already looked at the notices and closed them. Killing it obliges the bank to hand back whatever money it has collected. And it is one way only: a cancelled case cannot be reopened on the same payment.", "citation": "Manual Operacional do Diretorio de Identificadores de Contas Transacionais (DICT), versao 8.5, effective 2026-09-01 and 2026-10-26, sections 20.1.5, 20.1.10 and 20.1.1", "rests_on": "rule" }, { "label": "Fraud marking is a separate thing from asking for money", "value": "Two endpoints raise infraction notices and they do different jobs. createFundsRecovery starts a recovery, and the DICT generates the notices itself as part of it. createFraudMarker does nothing but flag CPFs, CNPJs and keys of the marking bank's own customers who were mixed up in Pix fraud. The second asks for no money at all.", "citation": "Manual Operacional do Diretorio de Identificadores de Contas Transacionais (DICT), versao 8.5, effective 2026-09-01 and 2026-10-26, section 10 opening text and section 10.2", "rests_on": "rule" } ], "exceptions": [ "The MED does not apply to a Pix with the purpose of withdrawal, nor to the cash portion of a Pix with the purpose of change (Regulamento Pix art. 41-B par. 2).", "No Recuperacao de Valores may be opened for a pacs.008 carrying purpose IPRT, because such a payment is itself a return made during the tracing stage and its receiver never contested anything (Manual Operacional do DICT 8.5, section 20.1.1 and its footnote).", "A return made for an operational failure cannot be contested (Manual Operacional do DICT 8.5, section 20.1.9).", "Payments settled outside the SPI can be recovered only where they meet the minimum traceability criteria the BCB sets. Where they do not, the participant must run the return outside the DICT, in line with MED rules: inside one participant it handles the block, the analysis and the return itself; between two participants under one settling participant, the settling participant intermediates (Manual Operacional do DICT 8.5, section 20.1.8).", "Operational failure and Pix Automatico requests do not need a prior infraction notice at all; only fraud requests do (Manual Operacional do DICT 8.5, section 17.1 footnote 23)." ], "applies_to": "a request by the payer's PSP to get a settled Pix back, through the Mecanismo Especial de Devolucao and the DICT, as distinct from an ordinary return started by the receiving user", "caveat": "Asking is not a message and it is not free. Opening a Recuperacao de Valores freezes money in accounts the payer's bank has never seen, across hops the DICT chooses, and marks users as fraud suspects when notices are accepted whether or not any money comes back. The recovering bank carries the duty to cancel a case it should not have opened, and it cannot open a second one on the same transaction.", "related": [ "pix:finality", "pix:return", "pix:refund", "pix:liability", "pix:messages", "pix:decision-points" ], "basis": { "sources": "Regulamento Pix, annex to Resolucao BCB n. 1/2020, consolidated version 41, read for this record from the BCB normativos data endpoint: Chapter XI Section II in full, arts. 41-B to 41-I, with art. 78-F on infraction notices and art. 78-N on the funds recovery function. Regulamento do SPI, annex to Resolucao BCB n. 195/2022, art. 40. Manual Operacional do DICT, version 8.5 (effective 2026-09-01 and 2026-10-26), read for this record: section 10 and 10.1 and 10.2, section 17 with 17.1, 17.2 and 17.3, section 20 with 20.1 and its subsections 20.1.1 to 20.1.11. Manual Operacional do DICT version 8.4 was read alongside it for the change in the contestation window. Catalogo de Servicos do SFN, Volume VI, version 5.12, message chapter, for the absence of a recall message. No secondary source was used.", "confidence": "high" }, "currency": { "effective_since": "2026-09-01", "effective_to": null, "effective_note": "The MED itself dates from Resolucao BCB n. 103 de 8/6/2021, in force from 2021-11-01 with effects from 2021-11-16, and was reshaped into the Recuperacao de Valores by Resolucao BCB n. 493 de 28/8/2025 with art. 78-N. The 80 day window for contesting a return took effect 2026-09-01 with Manual Operacional do DICT 8.5; version 8.4, still at the manual's main URL, says 30 days. A further tranche of 8.5 takes effect 2026-10-26, adding the graph depth attribute to the infraction notice. Art. 41-D par. 1 gains a new wording on 2026-07-01 under Resolucao BCB n. 559/2026 and art. 41-G is revoked on the same date.", "source_edition": "Regulamento Pix (Resolucao BCB n. 1/2020), consolidated version 41; Manual Operacional do DICT version 8.5, published under the versoes_futuras path with effect from 2026-09-01 and 2026-10-26; Manual Operacional do DICT version 8.4 dated 2026-07-01 for comparison; SPI catalog 5.12 dated 2026-03-27", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "rail_name": "Pix", "governing_authority": "Banco Central do Brasil", "snapshot": "2026-09-17", "source_class": null, "effective_status": "draft", "effective_status_reason": null, "boundaries": [] }, { "uid": "pix:refund", "id": "refund", "rail": "pix", "kind": "rail-fact", "facet": "refund", "name": "Does anyone have a right to be refunded, and how does the money get back?", "statement": "Pix gives one unconditional refund right and it is narrow: where the payer's PSP sent a faulty Pix Automatico payment, it must make its own client whole from its own funds, whether or not it ever recovers a cent. Everything else is conditional on money still being there. A fraud recovery that reaches the return stage gives the recovering bank 72 hours to start it, and each receiving bank pays back only up to what it blocked; it may reject for no balance, for a closed relationship, or for a generic reason, and the fraud marking stays either way. The money comes back by four different routes depending on where in the chain it sits: a pacs.004 from the root account, a pacs.008 with purpose IPRT from a later hop, a pacs.008 with purpose REFU to the payer's PSP for Pix Automatico, and a reversed pacs.008 where the contested transaction was itself a return.", "details": [ { "label": "Pix Automatico: the payer's bank pays first", "value": "On this one product the paying bank absorbs the loss up front. It reimburses its own customer in full, from its own money, and then goes to the DICT to try to collect from the other side, where it gets paid only if the funds are still sitting there. The rulebook makes the point explicitly: choosing to offer Pix Automatico is accepting this, whatever the state of the receiving account.", "citation": "Resolucao BCB n. 1/2020 and annexed Regulamento Pix, consolidated text, VersaoNormativo 41, arts. 41-A par. 2 incisos I and II and 11-V", "rests_on": "rule" }, { "label": "Everything else presupposes funds", "value": "Outside that case a return is limited by what is in the receiving customer's account. The rulebook builds every return on the assumption that the money is still sitting there, and names the Pix Automatico ground as the one place that assumption is set aside.", "citation": "Resolucao BCB n. 1/2020 and annexed Regulamento Pix, consolidated text, VersaoNormativo 41, arts. 41-A caput inciso I and 41-A par. 1", "rests_on": "rule" }, { "label": "The 72 hour clock on the return stage", "value": "When the analysis stage ends, and assuming the DICT has not already shut the case because nothing can come back, the recovering bank has three days to pull the trigger on the return stage. Miss it and the DICT closes the case as complete, with no money moved. The bank is free to keep weighing the merits during those three days.", "citation": "Manual Operacional do Diretorio de Identificadores de Contas Transacionais (DICT), versao 8.5, effective 2026-09-01 and 2026-10-26, section 20.1.6", "rests_on": "rule" }, { "label": "How much each bank has to pay back", "value": "Returns go out one at a time, in an order the DICT sets, and each one is squeezed by two ceilings at once: the amount that bank was told to freeze, and whatever is still outstanding on the original payment after everything already returned. Every payment goes to the person who was defrauded, and never for more than was frozen.", "citation": "Manual Operacional do Diretorio de Identificadores de Contas Transacionais (DICT), versao 8.5, effective 2026-09-01 and 2026-10-26, section 20.1.6", "rests_on": "rule" }, { "label": "Four different ways the money travels", "value": "The route depends on where in the chain the money sits. Straight from the account that received the disputed payment, it goes back as a pacs.004 tagged FR01, unless what was disputed was itself a return, in which case it is a pacs.008 with the original two parties swapped. From an account further down the chain, the bank debits its customer and sends a pacs.008 in its own name, tagged IPRT. For a botched Pix Automatico, a pacs.008 tagged REFU addressed to the payer's bank by its CNPJ. For an operational failure, a pacs.004 tagged BE08.", "citation": "Manual Operacional do Diretorio de Identificadores de Contas Transacionais (DICT), versao 8.5, effective 2026-09-01 and 2026-10-26, sections 20.1.6 and 17.3; Definicoes detalhadas das mensagens do Catalogo do SPI, archives spi.5.12.1.zip and spi.5.13.1.zip, PACS004.xlsx domain table for BE08 and FR01", "rests_on": "rule" }, { "label": "Grounds a receiving bank may give for paying nothing", "value": "Closing a request, the receiving bank says it paid in full, paid part, or paid nothing. A nil answer has to name one of three reasons: the account is empty, the customer is gone, or something else the first two do not cover. A fourth, invalid_request, exists only on the operational failure route. Paying part is what happens when there was less in the account than was asked for.", "citation": "Manual Operacional do Diretorio de Identificadores de Contas Transacionais (DICT), versao 8.5, effective 2026-09-01 and 2026-10-26, section 17, closing field table and the paragraphs that follow it", "rests_on": "rule" }, { "label": "Rejecting the refund does not undo the fraud mark", "value": "Accepting the notice and paying the money are separate decisions. A bank can accept the notice and still refuse to pay, and where it does, nothing moves but the customer and their key stay flagged as fraud, because the flag comes from accepting the notice and not from paying.", "citation": "Manual Operacional do Diretorio de Identificadores de Contas Transacionais (DICT), versao 8.5, effective 2026-09-01 and 2026-10-26, section 17 and section 20.1.5; Resolucao BCB n. 1/2020 and annexed Regulamento Pix, consolidated text, VersaoNormativo 41, art. 78-G par. unico (wording by Resolucao BCB n. 425 de 16/10/2024)", "rests_on": "rule" }, { "label": "Accepting even with no money is expected", "value": "An empty account is not a reason to refuse the notice. A bank that concludes its customer was part of the dispersion is expected to accept anyway, because the chain has to stay connected for the accounts further down to be reached at all. Refusing breaks it for everyone below.", "citation": "Manual Operacional do Diretorio de Identificadores de Contas Transacionais (DICT), versao 8.5, effective 2026-09-01 and 2026-10-26, section 20.1.5", "rests_on": "rule" }, { "label": "The operational failure route is narrower than it sounds", "value": "Operational failure means the bank broke something, not that the customer regrets something. The manual points to duplicated payments, payments made for an amount the customer did not instruct, and money leaving before the customer confirmed. It shuts the door on a long list of near misses: the payer typed the wrong key, the payer sent two payments when one was meant, the bank failed to debit or to reconcile or to show the entry on the statement, and anything that is really a scam. Where the facts do not fit, the receiving bank must reject with invalid_request.", "citation": "Manual Operacional do Diretorio de Identificadores de Contas Transacionais (DICT), versao 8.5, effective 2026-09-01 and 2026-10-26, section 17.1", "rests_on": "rule" }, { "label": "Money must be unblocked at only three moments", "value": "Frozen money stays frozen until one of exactly three things happens: the bank rejects the notice, the bank closes the return request, or the case is cancelled or closed out. There is no clock that releases it, so a long running case means a long running freeze, and the customer must be told the moment it lifts.", "citation": "Manual Operacional do Diretorio de Identificadores de Contas Transacionais (DICT), versao 8.5, effective 2026-09-01 and 2026-10-26, section 20.1.7", "rests_on": "rule" } ], "exceptions": [ "Where a recovery is cancelled after money has already come back, the recovering PSP must return what it received to each receiving PSP, subject to funds in its own user's account, and a receiving PSP of a later hop must credit its own client because that pacs.008 was paid in the participant's own name (Manual Operacional do DICT 8.5, section 20.1.10).", "Where a participant's own value limits force it to split a return into several transactions, it reports the total actually returned in EffectiveRefundedAmount and may name any one of the transactions as the identifier (Manual Operacional do DICT 8.5, section 17).", "Since version 8.4 a receiving PSP no longer has to keep monitoring the account after a partial return or a rejection for lack of balance, for fraud, operational failure or Pix Automatico reasons; the DICT sends MonitorAccount as false in all cases (Manual Operacional do DICT 8.5, sections 17 and 20.1.6).", "The period within which the payer's PSP must refund its own Pix Automatico client from its own funds is left to a specific BCB document, which this record does not name [Unverified: IN BCB n. 513/2024 on Pix Automatico procedures was fetched for this record but not read].", "For Pix Saque and the cash portion of Pix Troco there is no refund path at all under the MED. The only route is the ordinary return by the facilitator or agent, within one hour of finding it due (Regulamento Pix arts. 41-B par. 2 and 41 paragraphs 2 and 4)." ], "applies_to": "the stage at which money actually moves back to a payer under the Mecanismo Especial de Devolucao, and the one case where a participant must pay its own client regardless", "caveat": "A blocked amount is not a refunded amount. The chain runs open case, block, analyse, then return, and the case can die at any of them: the recovering bank can miss its 72 hours, a receiving bank can reject with no balance, or the recovering bank can cancel. The one promise an operator can make without qualification is the Pix Automatico one, because there the payer's own bank pays first and chases later.", "related": [ "pix:finality", "pix:return", "pix:recall", "pix:liability", "pix:consumer-law", "pix:decision-points" ], "basis": { "sources": "Manual Operacional do DICT, version 8.5, read for this record: section 17 with the opening and closing field tables and 17.1 and 17.3, section 20.1.5, 20.1.6, 20.1.7 and 20.1.10. Regulamento Pix, annex to Resolucao BCB n. 1/2020, consolidated version 41, read for this record from the BCB normativos data endpoint: arts. 11-V, 41-A, 41-B, 41-C, 41-D, 41-H, 41-I and 78-G. Definicoes detalhadas das mensagens do Catalogo do SPI, archive spi.5.12.1.zip, PACS004.xlsx domain table for BE08 and FR01. No secondary source was used. The BCB document setting the period for the Pix Automatico self funded refund was not read.", "confidence": "high" }, "currency": { "effective_since": "2026-09-01", "effective_to": null, "effective_note": "The self funded Pix Automatico refund duty came in with Resolucao BCB n. 402 de 22/7/2024. The Recuperacao de Valores shape of the fraud path, including the 72 hour return stage clock and the IPRT route from later hops, is Manual Operacional do DICT 8.4 dated 2026-07-01 and 8.5 effective 2026-09-01, on the footing of Resolucao BCB n. 493 de 28/8/2025. Version 8.5 changed the contestation window for a return from 30 to 80 days; the refund mechanics in this record are otherwise the same in 8.4 and 8.5.", "source_edition": "Manual Operacional do DICT version 8.5, effective 2026-09-01 and 2026-10-26; Regulamento Pix (Resolucao BCB n. 1/2020), consolidated version 41; SPI catalog 5.12.1 dated 2026-03-27", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.bcb.gov.br/content/estabilidadefinanceira/pix/Regulamento_Pix/versoes_futuras/X_ManualOperacionaldoDICT-versao8-5.pdf", "source_class": "authoritative_primary", "source_title": "Manual Operacional do Diretorio de Identificadores de Contas Transacionais (DICT), versao 8.5, effective 2026-09-01 and 2026-10-26", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the 72 hour clock on the return stage and its automatic completion if missed (section 20.1.6), the sequential per-return ceilings, the four routes the refund travels (pacs.004 from the root account, reversed pacs.008 where the contested transaction was itself a return, pacs.008 tagged IPRT from a later hop) (section 20.1.6), the three closing reasons for paying nothing (no_balance, account_closure, other) and the separate invalid_request reason for the operational failure route (section 17), and the three moments money may be unblocked (section 20.1.7). Regulamento Pix arts. 41-A and 11-V (the Pix Automatico self funded refund) and the PACS004.xlsx domain table for BE08 and FR01 were also read and match the record; this corroboration records the DICT manual source only." } ] }, "rail_name": "Pix", "governing_authority": "Banco Central do Brasil", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "pix:return", "id": "return", "rail": "pix", "kind": "rail-fact", "facet": "return", "name": "Can a settled Pix be returned, by whom and by when?", "statement": "Yes, and only the receiving side can do it. An ordinary devolucao is started by the receiving user, on their own initiative or because the payer asked them to, through their own PSP. It is a fresh value message (pacs.004) carrying reason MD06, it needs funds actually sitting in the receiving user's account, it may be partial and repeated up to the original amount, and it must be started within 90 days of the original payment. The payer's bank cannot force it. Pix Saque and the cash part of Pix Troco follow a different track: the withdrawal facilitator or agent starts the return, only for its own error or for a disagreement before the cash changes hands, within one hour of finding it due, under reason SL02, and the 90 day rule does not apply to them.", "details": [ { "label": "Who may start one", "value": "Control sits entirely on the receiving side. The person who got the money decides whether to send it back, whether they thought of it themselves or the payer talked them into it, and their own bank carries out the instruction. It only works on funds that have already landed and are still sitting in the account, and it can cover part of the payment rather than all of it.", "citation": "Resolucao BCB n. 1/2020 and annexed Regulamento Pix, consolidated text, VersaoNormativo 41, arts. 40 caput and 40 par. 1 (wording from 2021-11-16, Resolucao BCB n. 103/2021)", "rests_on": "rule" }, { "label": "What the receiving user's bank then does", "value": "The customer names an amount. Their bank then takes that amount out of the account with the customer's say so, pushes it to the payer's bank, and tags it with a reason. None of those steps is discretionary once the customer has authorized the debit.", "citation": "Resolucao BCB n. 1/2020 and annexed Regulamento Pix, consolidated text, VersaoNormativo 41, arts. 41 caput and 41 par. 1 (wording from 2021-11-16 and inclusion by Resolucao BCB n. 135/2021)", "rests_on": "rule" }, { "label": "The 90 day window", "value": "Three months is the outer edge for any Pix return, counted from the day of the original payment, and it covers special mechanism returns as well as ordinary ones. Two things fall outside it: a Pix made to withdraw cash, and the cash half of a Pix Troco.", "citation": "Resolucao BCB n. 1/2020 and annexed Regulamento Pix, consolidated text, VersaoNormativo 41, art. 41-A caput inciso II (wording by Resolucao BCB n. 167 de 24/11/2021)", "rests_on": "rule" }, { "label": "Funds must actually be there", "value": "A return moves real money out of the receiving customer's account, so the account has to have it. Nothing in the ordinary rule obliges the receiving bank to cover a shortfall. The single carve out is the faulty Pix Automatico case, where the payer's bank has to reimburse its own customer from its own pocket.", "citation": "Resolucao BCB n. 1/2020 and annexed Regulamento Pix, consolidated text, VersaoNormativo 41, arts. 41-A caput inciso I and 41-A paragraphs 1 and 2 (introduced by Resolucao BCB n. 402 de 22/7/2024)", "rests_on": "rule" }, { "label": "Partial and repeated returns", "value": "Multiple partial returns of the same transaction are allowed until the total amount to be returned is reached. A single transaction can therefore generate a string of pacs.004 messages rather than one.", "citation": "Resolucao BCB n. 1/2020 and annexed Regulamento Pix, consolidated text, VersaoNormativo 41, art. 40 par. 2 (wording from 2021-11-16, Resolucao BCB n. 103/2021)", "rests_on": "rule" }, { "label": "The reason code an operator will see", "value": "The pacs.004 return reason list holds exactly four codes and did not change between catalog 5.12.1 and 5.13.1. MD06 is a return requested by the receiving user, the ordinary case described in this record. SL02 covers withdrawal and change. BE08 and FR01 belong to the special mechanism, for operational failure and for well founded suspicion of fraud.", "citation": "Definicoes detalhadas das mensagens do Catalogo do SPI, archives spi.5.12.1.zip and spi.5.13.1.zip, archive spi.5.12.1.zip, PACS004.xlsx domain table for RtrRsnInf/Rsn/Cd, and the same table in spi.5.13.1.zip", "rests_on": "rule" }, { "label": "A return travels on the fast channel and is idempotent", "value": "A pacs.004 always travels on the primary message channel, as do the pacs.002 responses to it, whatever channel the original payment used. Returns are covered by the Pix idempotency principle with a 24 hour window, keyed on the pacs.004 IdOperacao: resending the same operation returns the answer already given rather than paying twice.", "citation": "Catalogo de Servicos do SFN, Volume VI, Pagamentos Instantaneos, versao 5.12, dated 2026-03-27, transmission channels chapter p. 14, idempotency chapter pp. 15 and 16, and money transfer messages p. 18", "rests_on": "rule" }, { "label": "Pix Saque and Pix Troco: a different starter and a one hour clock", "value": "Cash changes who is in charge. For a withdrawal or change payment the return comes from the withdrawal facilitator, where it runs the service itself, or from the withdrawal agent, and only on two grounds: that side got the transaction wrong, or the parties fell out before any cash was handed over. The customer has to raise it there and then, and where the counter is electronic a way to do so must be provided. Once the facilitator or agent accepts the return is owed, it has one hour.", "citation": "Resolucao BCB n. 1/2020 and annexed Regulamento Pix, consolidated text, VersaoNormativo 41, arts. 40-A caput and incisos I and II with paragraphs 1 and 2, and 41 paragraphs 2 and 4 (wording by Resolucao BCB n. 172 de 9/12/2021)", "rests_on": "rule" }, { "label": "Pix Troco needs two returns", "value": "For a Pix Troco, a separate transaction must be used to return the cash made available, kept apart from the return of the purchase amount. In code terms that is SL02 for the cash leg and MD06 for the purchase leg, and only the cash leg carries the one hour clock and sits outside the 90 day rule.", "citation": "Resolucao BCB n. 1/2020 and annexed Regulamento Pix, consolidated text, VersaoNormativo 41, arts. 41 par. 3 and 41-A caput inciso II; Definicoes detalhadas das mensagens do Catalogo do SPI, archives spi.5.12.1.zip and spi.5.13.1.zip, PACS004.xlsx SL02 comment", "rests_on": "rule" }, { "label": "Returns do not consume the payer's limits", "value": "Transactions that are returns under Chapter XI Section I of the Regulamento must not count against the value limits a participant sets for the payer.", "citation": "Instrucao Normativa BCB n. 512/2024, consolidated text, VersaoNormativo 4, art. 3 par. 12", "rests_on": "rule" } ], "exceptions": [ "A return of a return is not allowed. The SPI itself rejects it, on a pacs.002 carrying AG13, and the domain table names the SPI as the party that raises that code (spi.5.12.1.zip PACS002.xlsx domain table for StsRsnInf/Rsn/Cd).", "Where the receiving user's account has no funds, there is nothing to return. The rule creates no obligation on the receiving PSP to fund the return itself, outside the Pix Automatico case in art. 41-A par. 2.", "A devolucao can itself be contested. The receiving user of the returned funds may open a fraud recovery against a pacs.004 within 80 days of it, unless that return was made for an operational failure (Manual Operacional do DICT 8.5, sections 20.1.1 and 20.1.9).", "Returns are exempt from the requirement that a natural person initiate a Pix only from a previously registered access device (Regulamento Pix art. 89 par. 6, wording by Resolucao BCB n. 457 de 6/3/2025).", "An account whose holder is subject to an accepted infraction notice or a transactional fraud marking is barred from sending or receiving Pix, except for returns (Regulamento Pix art. 89 par. 2, wording by Resolucao BCB n. 506 de 26/9/2025)." ], "applies_to": "an ordinary devolucao of a settled Pix under Chapter XI Section I of the Regulamento Pix, including the withdrawal and change variants, and not the special mechanism", "caveat": "Do not read devolucao as an ACH return. Nobody on the payer's side can pull the money; the payer can only ask, and the receiving user decides. If an operator needs the money back without the receiver's goodwill, the ordinary return is the wrong instrument and the question becomes whether the facts fit the special mechanism, which is a narrower door with a shorter clock.", "related": [ "pix:finality", "pix:recall", "pix:refund", "pix:limits", "pix:messages", "pix:liability" ], "basis": { "sources": "Regulamento Pix, annex to Resolucao BCB n. 1 de 12/8/2020, consolidated version 41, read for this record from the BCB normativos data endpoint: Chapter XI Section I in full, arts. 40, 40-A, 41, 41-A, together with arts. 41-B par. 2 and 89 paragraphs 2 and 6. Definicoes detalhadas das mensagens do Catalogo do SPI, archives spi.5.12.1.zip and spi.5.13.1.zip, PACS004.xlsx domain table for the four return reason codes and PACS002.xlsx domain table for AG13. Catalogo de Servicos do SFN, Volume VI, version 5.12, pp. 14 to 18. Manual Operacional do DICT, version 8.5, sections 20.1.1 and 20.1.9, for contestation of a return. Instrucao Normativa BCB n. 512/2024 art. 3 par. 12. No secondary source was used.", "confidence": "high" }, "currency": { "effective_since": "2021-11-16", "effective_to": null, "effective_note": "The current shape of the ordinary return, including the 90 day window and the rule that the receiving user starts it on their own account or at the payer's request, came in with Resolucao BCB n. 103 de 8/6/2021, in force from 2021-11-01 with effects from 2021-11-16. Before that, art. 42 of the Regulamento held the 90 day rule and was revoked at the same date. The withdrawal and change variants were added by Resolucao BCB n. 135/2021 and reworded by n. 167/2021 and n. 172/2021. The four pacs.004 reason codes are unchanged between catalog 5.12.1 and 5.13.1, so the 5.13.1 production date of 2026-10-25 does not disturb this record.", "source_edition": "Regulamento Pix (Resolucao BCB n. 1/2020), consolidated version 41, amendments listed through Resolucao BCB n. 559 de 23/4/2026; SPI catalog 5.12.1 dated 2026-03-27, in SPI production since 2026-06-28; Manual Operacional do DICT 8.5", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.bcb.gov.br/estabilidadefinanceira/exibenormativo?tipo=Resolução%20BCB&numero=1", "source_class": "authoritative_primary", "source_title": "Resolucao BCB n. 1/2020 and annexed Regulamento Pix, consolidated text, VersaoNormativo 41", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the receiving user starts an ordinary devolucao on its own account or at the payer's request (art. 40), the 90 day window counted from the original transaction with withdrawal and change carved out (art. 41-A caput inciso II), multiple partial returns until the total is reached (art. 40 par. 2), and the one hour clock for the withdrawal facilitator or agent once it finds a Saque or Troco return due (art. 40-A, art. 41 pars. 2 and 4). The PACS004.xlsx domain table in spi.5.12.1.zip and spi.5.13.1.zip confirms the four return reason codes are unchanged between catalogs, and AG13 as the SPI-raised reject of a return of a return. This corroboration records the Resolucao BCB n. 1/2020 source only." } ] }, "rail_name": "Pix", "governing_authority": "Banco Central do Brasil", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "pix:settlement", "id": "settlement", "rail": "pix", "kind": "rail-fact", "facet": "settlement", "name": "How does a Pix actually settle, and in whose money?", "statement": "A Pix between two participants settles gross, one payment at a time, in central bank money, across Conta PI accounts that direct participants hold at the Banco Central do Brasil. There is no netting and no clearing cycle. The SPI blocks the payer bank's funds on receipt, asks the receiving bank to confirm it can take the payment, then swaps the two balances; that swap is settlement. A Pix between two users of the same bank, or two banks that settle through the same settling participant, never reaches the SPI and settles in that participant's own books. It is still a Pix and still carries the same clock.", "details": [ { "label": "What the SPI is", "value": "The SPI is the BCB's own settlement engine for Pix. It settles one payment at a time, in full, across accounts the direct participants hold at the central bank, and it moves nothing but credits. There is no netting stage and no clearing house standing between the two banks.", "citation": "Regulamento do Sistema de Pagamentos Instantaneos (SPI), anexo a Resolucao BCB n. 195/2022, consolidated text, VersaoNormativo 6, art. 2 inciso I, with art. 31", "rests_on": "rule" }, { "label": "Credit push only, national currency, immediate", "value": "Three things are fixed about every order the SPI will take: it is in reais, it is for settlement now rather than later, and it runs between the Conta PI accounts of two different direct participants. An order outside those bounds is thrown out. What is not fixed is size, because the system carries any amount.", "citation": "Regulamento do Sistema de Pagamentos Instantaneos (SPI), anexo a Resolucao BCB n. 195/2022, consolidated text, VersaoNormativo 6, arts. 32 and 33, with art. 33 par. unico", "rests_on": "rule" }, { "label": "Step one: the SPI blocks the sending bank's funds", "value": "The first thing the SPI does with an arriving order is take the money out of reach. It reserves the amount in the sending bank's Conta PI, which only works if the balance is there, and that reservation is the moment the system counts the order as accepted. From then on the funds are earmarked for this payment.", "citation": "Regulamento do Sistema de Pagamentos Instantaneos (SPI), anexo a Resolucao BCB n. 195/2022, consolidated text, VersaoNormativo 6, art. 36 caput and paragraphs 1 and 2", "rests_on": "rule" }, { "label": "Balance checks need not follow arrival order", "value": "The SPI may check available balance, and may effect settlement in the issuing participant's Conta PI, out of the order in which payment orders arrived. A bank cannot assume its own queue discipline holds inside the system.", "citation": "Regulamento do Sistema de Pagamentos Instantaneos (SPI), anexo a Resolucao BCB n. 195/2022, consolidated text, VersaoNormativo 6, arts. 36 par. 3 and 38 par. unico", "rests_on": "rule" }, { "label": "Step two: the receiving bank confirms it can take the payment", "value": "Nothing settles until the receiving side says it can take it. The SPI hands the order to whoever holds the receiving user's account, direct or indirect, which checks the user and account details and answers back. Whatever that check costs in seconds comes out of the same settlement budget, not on top of it.", "citation": "Regulamento do Sistema de Pagamentos Instantaneos (SPI), anexo a Resolucao BCB n. 195/2022, consolidated text, VersaoNormativo 6, art. 37 caput and par. unico", "rests_on": "rule" }, { "label": "Step three: the balance swap is settlement", "value": "Settlement is a single bookkeeping act. An order that has not expired and that carries the receiving side's confirmation goes straight through, drawing on the amount already reserved, and the payment counts as settled the instant the Conta PI balances change on the BCB's books. The SPI stamps that instant in UTC.", "citation": "Regulamento do Sistema de Pagamentos Instantaneos (SPI), anexo a Resolucao BCB n. 195/2022, consolidated text, VersaoNormativo 6, arts. 38 caput, 39 and 40 paragraphs 1 and 2", "rests_on": "rule" }, { "label": "The bank's own authorization step comes first", "value": "Before any of this the payer's own bank has to authorize the payment, and the rule tells it exactly what authorization means: security checks done, enough money found in the customer's account, and the amount reserved so settlement can begin. Where the payment will never leave the bank, finding the money is enough and no reservation is needed.", "citation": "Resolucao BCB n. 1/2020 and annexed Regulamento Pix, consolidated text, VersaoNormativo 41, art. 36 caput and par. 1", "rests_on": "rule" }, { "label": "Two message channels, two clocks", "value": "Payments with an expectation of an immediate answer run on the primary channel and settle within 40 seconds. Only Pix Agendado and scheduled Pix Cobranca run on the secondary channel, marked PAGAGD in the payment priority type, and settle within 45 minutes. The first pacs.008 fixes the channel for every later message of that operation, and a return (pacs.004) always goes on the primary channel.", "citation": "Catalogo de Servicos do SFN, Volume VI, Pagamentos Instantaneos, versao 5.12, dated 2026-03-27, transmission channels chapter, pp. 13 and 14; Manual de Tempos do Pix, versao 7.0, sections 1.1 and 1.2", "rests_on": "rule" }, { "label": "Settlement outside the SPI", "value": "Where both accounts sit at one participant, settlement is done in that participant's own systems. Where two participants use the same settling participant in the SPI, settlement between them is done in the settling participant's systems. Those payments are still Pix, carry the same 40 second and 45 minute limits, and must be reported to the BCB within 30 days of settlement.", "citation": "Resolucao BCB n. 1/2020 and annexed Regulamento Pix, consolidated text, VersaoNormativo 41, arts. 33 par. unico and 34; Manual de Tempos do Pix, versao 7.0, sections 1.3 and 1.4", "rests_on": "rule" }, { "label": "Liquidity for the Conta PI", "value": "Funding the Conta PI is a round the clock obligation, not a business day one. A direct participant must keep it able to cover its own payments and those of every indirect participant it settles for, on every day of the year. The BCB offers a liquidity provision service for that, and clearing houses may offer their own on top.", "citation": "Regulamento do Sistema de Pagamentos Instantaneos (SPI), anexo a Resolucao BCB n. 195/2022, consolidated text, VersaoNormativo 6, art. 18 inciso III; Resolucao BCB n. 1/2020 and annexed Regulamento Pix, consolidated text, VersaoNormativo 41, arts. 43 and 44", "rests_on": "rule" }, { "label": "Service levels, not just deadlines", "value": "Beside the hard maximum times, the BCB sets monthly service level indicators with percentile targets: the payer's PSP has 0.9 seconds at the 50th percentile and 1.5 seconds at the 95th to create the pacs.008, the receiving side has 1.4 and 2.3 seconds to authorize, and the payer's end to end experience is measured at 6.0 seconds at the 50th percentile and 10.0 seconds at the 99th.", "citation": "Manual de Tempos do Pix, versao 7.0, sections 4.1.1.1, 4.1.1.2 and 4.1.2.1", "rests_on": "rule" } ], "exceptions": [ "Insufficient available balance in the issuing participant's Conta PI at the moment of the block, or reaching the minimum operating balance the participant has configured, causes immediate and definitive rejection of the order (Regulamento do SPI art. 36 par. 4, wording in force from 2026-03-30 by Resolucao BCB n. 554/2026).", "The BCB may suspend SPI services temporarily for a stated period where extraordinary facts justify it, telling participants in good time (Regulamento do SPI art. 9).", "Service level indicators exclude several transaction types, among them Pix Agendado, scheduled Pix Cobranca, payments held under the extended fraud authorization window, and returns (Manual de Tempos 4.1.1.1 and 4.1.2.1).", "Clock skew is the participant's problem: clocks of servers at different institutions may not be used together to compute indicators, and each institution must keep its own servers synchronized (Manual de Tempos 4.1, premises a and b).", "Settlement for a Pix Saque or Pix Troco carries an extra reimbursement layer between participants, set by separate Instrucoes Normativas, which this record does not describe [Unverified: IN BCB n. 199/2021 and n. 200/2021 were listed on the Pix normas page and not opened]." ], "applies_to": "settlement of a Pix credit order, whether in the SPI between Conta PI accounts or in a participant's own systems", "caveat": "Do not model Pix as a clearing rail. There is no cycle, no net position and no settlement window to miss. What a bank must manage is a funded Conta PI at every hour of every day and a system that answers the SPI inside seconds, because a payment that is not settled inside 40 seconds is not delayed, it is rejected.", "related": [ "pix:finality", "pix:hours", "pix:limits", "pix:messages", "pix:participants" ], "basis": { "sources": "Regulamento do SPI, annex to Resolucao BCB n. 195 de 3/3/2022, consolidated text read for this record from the BCB normativos data endpoint: art. 2 (definitions), arts. 8 to 12 (hours and monitoring), art. 18 (direct participant duties), arts. 31 to 43 (type and value, issuance, prior blocking, confirmation of capacity to receive, settlement, irrevocability, maximum settlement time). Regulamento Pix, annex to Resolucao BCB n. 1/2020, consolidated version 41: arts. 33, 34, 36, 43, 44. Manual de Tempos do Pix, version 7.0: sections 1.1 to 1.4 and 4.1 with its subsections. Catalogo de Servicos do SFN, Volume VI, version 5.12: transmission channels chapter, pp. 13 and 14. No secondary source was used.", "confidence": "high" }, "currency": { "effective_since": "2022-04-01", "effective_to": null, "effective_note": "The Regulamento do SPI approved by Resolucao BCB n. 195/2022 took effect 2022-04-01 and revoked Circular BCB n. 4.027/2020, which governed SPI settlement before it. That Circular was not read, so how far the mechanics described here predate 2022-04-01 is [Unverified]. Art. 36 par. 4 carries a newer wording effective 2026-03-30 (Resolucao BCB n. 554/2026) adding the configurable minimum operating balance.", "source_edition": "Regulamento do SPI (Resolucao BCB n. 195/2022), consolidated text, latest amendment listed Resolucao BCB n. 554 de 24/3/2026; Regulamento Pix (Resolucao BCB n. 1/2020), consolidated version 41; Manual de Tempos do Pix 7.0; Catalogo de Servicos do SFN Vol. VI 5.12 dated 2026-03-27", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.bcb.gov.br/estabilidadefinanceira/exibenormativo?tipo=Resolução%20BCB&numero=195", "source_class": "authoritative_primary", "source_title": "Regulamento do Sistema de Pagamentos Instantaneos (SPI), anexo a Resolucao BCB n. 195/2022, consolidated text, VersaoNormativo 6", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms gross, one at a time, central bank money settlement with no netting (art. 2 inciso I, art. 31), the credit-push/national-currency/immediate order constraints with no value ceiling (arts. 32, 33), the prior blocking of the sending bank's funds and its 2026-03-30 minimum operating balance wording (art. 36), the receiving bank's confirmation step (art. 37), and the balance swap as the moment of settlement (arts. 38 to 40). Regulamento Pix arts. 33, 34, 36, 43 and 44 (settlement outside the SPI and Conta PI liquidity) and Manual de Tempos do Pix 7.0 sections 1.1 to 1.4 and 4.1 (channel clocks and service level indicators) were also read and match the record; this corroboration records the Regulamento do SPI source only." } ] }, "rail_name": "Pix", "governing_authority": "Banco Central do Brasil", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "rtp:consumer-law", "id": "consumer-law", "rail": "rtp", "kind": "rail-fact", "facet": "consumer-law", "name": "What consumer law applies, and what does it give a consumer that the rules do not?", "statement": "Where any part of an RTP payment is subject to the Electronic Fund Transfer Act, the EFTA and Regulation E govern first, the Operating Rules and New York law apply only so far as they are consistent, and Article 4-A is excluded. That matters because Regulation E gives a consumer an error resolution right with its own deadlines, enforced against the consumer's own bank, that exists whether or not the receiving bank ever agrees to return a cent. TCH's own guidance puts the investigation duty for consumer-account payments on the sending bank.", "details": [ { "label": "Which law wins", "value": "For an RTP payment any part of which is subject to the EFTA, the rights and obligations of a participant and a consumer customer are governed by the EFTA and Regulation E to the extent applicable, and then, only so far as consistent with them, by these rules and New York law excluding Article 4-A.", "citation": "TCH RTP Operating Rules, edition effective 2026-06-01, Rule I.F.2", "rests_on": "rule" }, { "label": "Same rule for errors and unauthorized payments", "value": "For an erroneous or unauthorized payment any part of which is subject to the EFTA, the rights and responsibilities of the parties are governed by applicable law including the EFTA and Regulation E.", "citation": "TCH RTP Operating Rules, edition effective 2026-06-01, Rule II.J.1.b", "rests_on": "rule" }, { "label": "Who investigates", "value": "TCH's public guidance states that RTP transfers from consumer accounts are subject to Regulation E and that sending participants are responsible for investigating and resolving alleged errors and unauthorized transactions from consumer accounts. It adds that sending participants may also have liability for unauthorized transactions initiated by commercial customers under Article 4-A.", "citation": "TCH RTP Request for Return of Funds Guidelines and Suggested Practices, dated 2021-01-21 (marked Public; guidance, not rule), operating guidelines page, footnote 1", "rests_on": "guidance" }, { "label": "Who counts as a consumer", "value": "The rules define a consumer as a natural person, and say the rules exist in part to ensure consumer protection.", "citation": "TCH RTP Operating Rules, edition effective 2026-06-01, Rule I.A.10 and Rule I.B", "rests_on": "rule" }, { "label": "What Regulation E counts as an error", "value": "Error includes an unauthorized electronic fund transfer, an incorrect transfer to or from the account, an omitted transfer, a computational or bookkeeping error by the institution, and a consumer request for documentation or clarification about a transfer.", "citation": "Regulation E, 12 CFR 1005.11(a), as published by the Consumer Financial Protection Bureau at consumerfinance.gov, read 2026-09-17", "rests_on": "law" }, { "label": "The consumer's deadline", "value": "The consumer's notice of an alleged error must reach the institution no later than 60 days after the institution sends the periodic statement on which the alleged error appears. Notice may be oral or written; the institution may require written confirmation within 10 business days.", "citation": "Regulation E, 12 CFR 1005.11(b), as published by the Consumer Financial Protection Bureau at consumerfinance.gov, read 2026-09-17", "rests_on": "law" }, { "label": "The bank's deadline", "value": "The institution must investigate promptly and determine whether an error occurred within 10 business days, reporting the result within 3 business days after that. It may take up to 45 days instead if it provisionally credits the consumer's account within 10 business days. Longer periods apply to new accounts and certain point of sale transactions.", "citation": "Regulation E, 12 CFR 1005.11(c), as published by the Consumer Financial Protection Bureau at consumerfinance.gov, read 2026-09-17", "rests_on": "law" }, { "label": "Why RTP consumer payments are not treated as exempt wires", "value": "[Inference] Regulation E excludes transfers through Fedwire or similar systems used primarily for transfers between financial institutions or between businesses. RTP is used for consumer payments, and TCH's own guidance treats consumer-account RTP transfers as subject to Regulation E, so the exclusion is not read as covering them.", "citation": "Regulation E, 12 CFR 1005.3(c)(3), as published by the Consumer Financial Protection Bureau at consumerfinance.gov, read 2026-09-17; with the TCH guidelines dated 2021-01-21, footnote 1", "rests_on": "law" }, { "label": "A consumer control the rules do give", "value": "A customer may elect not to receive Requests for Payment from a given sender, or all Requests for Payment, and a receiving participant may decline a payment where the account owner has said it does not wish to accept all or certain RTP payments.", "citation": "TCH RTP Operating Rules, edition effective 2026-06-01, Rule II.F.2.c and Rule V.C.2", "rests_on": "rule" } ], "exceptions": [ "Regulation E attaches to the account and the transfer, not to the rail. A payment between two business accounts over RTP is governed by the rules and Article 4-A, with no Regulation E error resolution (Rule I.F.1).", "Whether a consumer push payment that the consumer authorized but was tricked into making is an error under 12 CFR 1005.11(a) is not settled by any source read for this record, and the Operating Rules do not address it. Treat any answer as [Unverified].", "The Operating Rules do not create the consumer right; they yield to it. A consumer's remedy runs against their own bank under Regulation E, not against the receiving bank, and not through the Request for Return of Funds process (Rule I.F.2, Rule VII.D.1).", "Requests for Payment from a consumer message sender have their own legitimate purpose test: the request must go to a message receiver who knows the sender and would reasonably expect it (Rule VII.B.3.b).", "State consumer law is not addressed by the rules beyond the general choice of New York law; applicable law is defined to include US federal, state, provincial and local law (Rule I.A.5)." ], "applies_to": "RTP payments any part of which is subject to the Electronic Fund Transfer Act, which in practice means payments to or from a consumer asset account in the United States", "caveat": "The 60 day Regulation E clock runs from the periodic statement, not from the payment, and the bank's clock runs from the consumer's notice. Neither is connected to the ten banking day Request for Return of Funds window. A sending bank can be inside its Regulation E duty to recredit its customer while the money is never coming back from the receiving bank.", "related": [ "rtp:liability", "rtp:refund", "rtp:finality", "rtp:recall", "rtp:decision-points" ], "basis": { "sources": "TCH RTP Operating Rules, edition effective 2026-06-01 (marked PUBLIC), read in full for this record: Rule I.A.5 and I.A.10 (applicable law, consumer), I.B (purpose includes consumer protection), I.F.2 (EFTA consumer payments), II.F.2.c (customers may opt out of Requests for Payment), II.J.1.b (erroneous and unauthorized consumer payments), III.C.3 (receiver name on consumer originations), V.C.2 (account owner opt-out), VII.B.3.b (consumer message sender legitimate purpose), VII.D.1. TCH RTP Request for Return of Funds Guidelines and Suggested Practices, dated 2021-01-21 (marked Public), footnote 1 on the operating guidelines page. Regulation E, 12 CFR 1005.3 and 1005.11, as published by the Consumer Financial Protection Bureau at consumerfinance.gov and read 2026-09-17; eCFR refused a plain fetch, and the regulation text was read through the CFPB's own presentation rather than section by section, so the Regulation E detail lines are not high confidence.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_note": "Rule I.F.2 is present in the edition effective 2026-06-01 and the 2021 guidelines state the same position, so the substance predates 2021. Regulation E error resolution timings at 12 CFR 1005.11 are long-standing; the drafter did not check for amendments and the CFPB's position on fraudulently induced consumer payments is an active policy area [Unverified].", "source_edition": "TCH RTP Operating Rules, edition effective 2026-06-01 (marked PUBLIC), Rule I.F.2; Regulation E, 12 CFR 1005, current text as presented by the CFPB on 2026-09-17", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.theclearinghouse.org/-/media/New/TCH/Documents/Payment-Systems/RTP/RTP-Operating-Rules-Effective-June-1-2026pdf.pdf", "source_class": "authoritative_primary", "source_title": "RTP Operating Rules, edition effective 2026-06-01, The Clearing House", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms the EFTA/Regulation E precedence for EFTA consumer payments (I.F.2); the same precedence for erroneous or unauthorized consumer payments (II.J.1.b); the consumer definition and the consumer-protection purpose (I.A.10, I.B); and the customer's ability to opt out of Requests for Payment, plus the account owner's ability to opt out of accepting RTP payments (II.F.2.c, V.C.2). Does not address the Regulation E detail lines, which rest on eCFR, or the footnote 1 investigation-duty line, which rests on the 2021 guidelines." }, { "source_url": "https://www.theclearinghouse.org/-/media/New/TCH/Documents/Payment-Systems/RTP_Request_for_Returns_v02-19-2021.pdf", "source_class": "public_primary", "source_title": "RTP Request for Return of Funds Guidelines and Suggested Practices, dated 2021-01-21, The Clearing House", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms the footnote 1 detail: RTP transfers from consumer accounts are subject to Regulation E, sending participants investigate and resolve alleged consumer-account errors and unauthorized transactions, and sending participants may also have Article 4-A liability for unauthorized commercial transactions. Does not address the rule-based or Regulation E detail lines." }, { "source_url": "https://www.ecfr.gov/current/title-12/chapter-X/part-1005/subject-group-ECFR3b20437305a7373/section-1005.11", "source_class": "authoritative_primary", "source_title": "Regulation E, 12 CFR 1005.11 and 1005.3, eCFR current text (fetched via the eCFR versioner API with compressed responses, 2026-09-17)", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms 1005.11(a)'s error definition (unauthorized transfer, incorrect transfer, omitted transfer, computational/bookkeeping error, and a documentation/clarification request); 1005.11(b)'s 60 day consumer notice deadline running from the periodic statement and the 10 business day written-confirmation allowance; 1005.11(c)'s 10 business day determination and 3 business day reporting deadlines, the 45 day extension conditioned on a 10 business day provisional credit, and longer periods for new accounts and point of sale transactions; and 1005.3(c)(3)'s exclusion of Fedwire and similar wire systems used primarily between financial institutions or businesses. Does not address whether a consumer-authorized but fraudulently induced RTP payment is a Regulation E error, which the record leaves as an open question, and does not address any rule-based detail line." } ] }, "rail_name": "RTP", "governing_authority": "The Clearing House", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "rtp:decision-points", "id": "decision-points", "rail": "rtp", "kind": "rail-fact", "facet": "decision-points", "name": "Where does the rail stop and a human decide?", "statement": "The payment itself leaves almost nothing to judgment: it is released, accepted and settled in seconds against tests a machine applies. Everything about getting money back is judgment, and nearly all of it belongs to the receiving bank. It decides whether to accept, whether to post after accepting without posting, and whether to return funds at all, and the last of those is a decision no rule compels in either direction. Two further decisions sit with TCH: how it interprets its own rules, binding on everyone, and how it decides a Request for Payment warranty arbitration.", "details": [ { "label": "Receiving bank: accept, accept without posting, or reject", "value": "The receiving participant chooses its response. Its discretion is bounded, since it agrees to accept all conforming payment messages unless one of three conditions applies, but two of those conditions rest on its own judgment: that an account is being monitored for suspected fraudulent or other illegal activity, and that the message cannot be accepted for legal or regulatory compliance reasons.", "citation": "TCH RTP Operating Rules, edition effective 2026-06-01, Rule V.C.1 and V.C.3, with Rule V.E", "rests_on": "rule" }, { "label": "Receiving bank: whether to post after accepting without posting", "value": "Having taken settlement without giving the receiver funds, the receiving participant decides whether to make funds available. It is expected to decide by 11:59 p.m. local time the next business day, except where it is reviewing the payment for sanctions compliance, where no deadline is stated.", "citation": "TCH RTP Operating Rules, edition effective 2026-06-01, Rule V.E.2.c and Rule V.E.2.d", "rests_on": "rule" }, { "label": "Receiving bank: whether to return funds at all", "value": "This is the decision that matters most and the one the rules leave most open. The receiving participant must respond to a Request for Return of Funds and is under no obligation to return the funds. No rule states what it should weigh.", "citation": "TCH RTP Operating Rules, edition effective 2026-06-01, Rule VII.D.1", "rests_on": "rule" }, { "label": "Receiving bank: whether to accept an offered indemnity", "value": "Where a request arrives with the standard optional indemnity, the receiving participant has no obligation to accept the offer, to block the funds, or to return them. The guidance says it may return the funds with or without its customer's debit authority, or ignore the indemnity and follow its normal process.", "citation": "TCH RTP Operating Rules, edition effective 2026-06-01, Rule VII.D.3; TCH guidelines dated 2021-01-21, operating guideline 6.IV", "rests_on": "rule" }, { "label": "The beneficiary, in practice", "value": "The rules do not require the receiver's consent to a return, but TCH's guidance frames the request as generally requiring contact with and approval from the beneficiary, and devotes its lessons learned to how a creditor bank should try to reach them. In practice the money comes back when a customer agrees to let it.", "citation": "TCH RTP Request for Return of Funds Guidelines and Suggested Practices, dated 2021-01-21 (marked Public; guidance, not rule), operating guideline 2.I and the lessons learned page", "rests_on": "guidance" }, { "label": "Sending bank: whether to execute at all", "value": "The rules speak of a sending participant that chooses to execute a sender's payment instruction, which is where its fraud and risk screening decision sits. Screening must happen before the message is submitted and must be available every hour of every day.", "citation": "TCH RTP Operating Rules, edition effective 2026-06-01, Rule III.B and Rule III.A.2", "rests_on": "rule" }, { "label": "Sending bank: how to confirm a consumer's intended recipient", "value": "For a consumer-originated payment the sending participant may either give the sender the receiver name associated with the routing information, or design into the origination process another means of confirming with reasonable assurance that the instruction points at the intended recipient. Which of the two, and what counts as reasonable assurance, is the bank's call.", "citation": "TCH RTP Operating Rules, edition effective 2026-06-01, Rule III.C.3", "rests_on": "rule" }, { "label": "Sending bank: whether to pass a customer's request into the network", "value": "The guidance expects a debtor bank to intermediate and validate a customer's request before submitting it, to remind the customer that RTP gives no chargeback right, to ask why the customer wants the money back, and to have a person speak to the customer where the reason is not error, an unauthorized payment, or claimed fraudulent inducement.", "citation": "TCH RTP Request for Return of Funds Guidelines and Suggested Practices, dated 2021-01-21 (marked Public; guidance, not rule), operating guideline 9", "rests_on": "guidance" }, { "label": "Sending bank: whether to pay a warranty claim", "value": "On a Request for Payment warranty claim, the message sending participant investigates and decides within 20 business days whether to pay. Three reasons are taken away from it: inability to recover from its own customer, the other bank's lack of a legal duty to recredit, and the other bank not having recredited yet.", "citation": "TCH RTP Operating Rules, edition effective 2026-06-01, Rule VII.C.6.a, VII.C.6.b and VII.C.6.c.ii", "rests_on": "rule" }, { "label": "TCH: interpretation, and it binds everyone", "value": "TCH has the sole discretion, right and authority to interpret the Operating Rules, and any such interpretation is binding on all participants. This is why a published rules interpretation can change practice without any rules edition changing.", "citation": "TCH RTP Operating Rules, edition effective 2026-06-01, Rule I.C", "rests_on": "rule" }, { "label": "TCH: arbitration, and who carries the burden", "value": "TCH decides whether a warranty was breached, and decides in its own determination whether the request collected payment for a purchase of goods or services in the ordinary course of business, which is what fixes the burden of proof on one side or the other. The decision is final and binding with no appeal to the courts.", "citation": "TCH RTP Operating Rules, edition effective 2026-06-01, Rule VII.C.7.b.iv, VII.C.7.c.i and VII.C.7.c.iv", "rests_on": "rule" }, { "label": "TCH: discretion over the running of the system", "value": "TCH decides in its sole discretion whether to reject a non-conforming message, whether to treat a message as erroneous or duplicate and not process it, the frequency and timing of reconciliation windows, whether to impose origination controls on a participant, the category of any rules violation and the amount of a fine, and whether to assess, suspend or waive a fine. In an emergency the chief executive officer may halt messaging or modify the rules.", "citation": "TCH RTP Operating Rules, edition effective 2026-06-01, Rule IV.A.2, IV.A.3, IV.E, VI.F.1, IX.B, X.B.3.a.i and X.B.7", "rests_on": "rule" }, { "label": "Funding provider: how much a member bank may send", "value": "A funding provider sets the net send limit for each non-funding group member, and the total of those limits may exceed its own prefunded requirement. That judgment decides whether a small bank's payments go out during a busy window.", "citation": "TCH RTP Operating Rules, edition effective 2026-06-01, Rule VI.D.5.a", "rests_on": "rule" } ], "exceptions": [ "The release of a payment is not a judgment call: the system releases or rejects on the prefunded position and net send limit tests (Rule VI.E.1 and VI.E.3).", "The receiving participant cannot decide to take longer than the specification allows; silence becomes a system cancellation (Rule IV.A.4).", "The receiving participant cannot decide to refuse a payment for being too large, since it may not set a lower transaction limit and size is not a permitted reject reason (Rule II.C.2.b, Rule V.C).", "TCH expressly declines the liability decision: it will not be a party to a dispute between participants over an erroneous or unauthorized payment, which leaves that judgment to the two banks and their lawyers (Rule II.J.5).", "Rule changes are decided by the RTP Business Committee under delegated authority, and the implementation date is announced with the change, which is the decision point that sets every effective date in this profile (Rule I.G.1 to I.G.5)." ], "applies_to": "the points in an RTP payment or exception where a rule leaves the outcome to a participant, to TCH, or to a customer", "caveat": "This facet is Orca's reading of where the rulebook leaves judgment open, not a statement by TCH, and it caps at medium confidence for that reason. Every line names the rule that leaves the decision open; none of them asserts how the decision will go.", "related": [ "rtp:finality", "rtp:return", "rtp:recall", "rtp:refund", "rtp:liability", "rtp:consumer-law", "rtp:participants", "rtp:hours", "rtp:settlement", "rtp:limits", "rtp:messages" ], "basis": { "sources": "TCH RTP Operating Rules, edition effective 2026-06-01 (marked PUBLIC), read in full for this record: Rule I.C (TCH interpretation), I.G (rule changes), II.C.2.b, II.J.5, III.A.2, III.B, III.C.3, IV.A.2 to IV.A.4, IV.E, V.C, V.E, V.E.2.c and d, VI.D.5.a, VI.E.1 and VI.E.3, VI.F.1, VII.C.6, VII.C.7, VII.D.1, VII.D.3, IX.B, X.B.3.a.i, X.B.7. TCH RTP Request for Return of Funds Guidelines and Suggested Practices, dated 2021-01-21 (marked Public; guidance, not rule), operating guidelines 2, 6 and 9 and the lessons learned page. The selection of which provisions count as decision points is Orca's reading, which is why this facet caps at medium.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_note": "Every provision cited is present in the edition effective 2026-06-01. Earlier editions were not read. This facet is a reading of that edition and should be re-read whenever a new edition takes effect, which for RTP has been about three times a year.", "source_edition": "TCH RTP Operating Rules, edition effective 2026-06-01 (marked PUBLIC); TCH RTP Request for Return of Funds Guidelines and Suggested Practices, dated 2021-01-21 (marked Public)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.theclearinghouse.org/-/media/New/TCH/Documents/Payment-Systems/RTP/RTP-Operating-Rules-Effective-June-1-2026pdf.pdf", "source_class": "authoritative_primary", "source_title": "RTP Operating Rules, edition effective 2026-06-01, The Clearing House", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms the receiving bank's bounded accept/accept-without-posting/reject discretion (V.C.1, V.C.3, V.E); the accept-without-posting posting decision and its 11:59 p.m. next-business-day expectation, with a sanctions exception (V.E.2.c, V.E.2.d); the receiving bank's unconditional discretion whether to honor a Request for Return of Funds (VII.D.1); the sending bank's fraud/risk screening discretion and 24x7 availability (III.A.2, III.B); the consumer name-confirmation method choice (III.C.3); the Request for Payment warranty claim investigation and 20 business day decision, with the three barred negative-response reasons (VII.C.6.a-c); TCH's binding interpretation authority (I.C); TCH's arbitration determination and burden-of-proof allocation (VII.C.7.b.iv, VII.C.7.c.i, VII.C.7.c.iv); TCH's operational discretion over rejecting non-conforming messages, treating messages as erroneous/duplicate, reconciliation window timing, origination controls, fine categorization, and fine assessment/suspension/waiver, plus CEO emergency authority (IV.A.2, IV.A.3, IV.E, VI.F.1, IX.B, X.B.3.a.i, X.B.7); and the funding provider's net send limit discretion (VI.D.5.a). Does not address the two guidance-sourced lines on beneficiary contact in practice and debtor-bank intermediation of return requests, which rest on the 2021 guidelines." }, { "source_url": "https://www.theclearinghouse.org/-/media/New/TCH/Documents/Payment-Systems/RTP_Request_for_Returns_v02-19-2021.pdf", "source_class": "public_primary", "source_title": "RTP Request for Return of Funds Guidelines and Suggested Practices, dated 2021-01-21, The Clearing House", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms that a return of funds generally requires contact with and approval from the beneficiary, and that creditor banks should take reasonable measures to reach beneficiaries (operating guideline 2.I, lessons learned page); and the expectation that a debtor FI intermediate and validate a customer's return request, remind the customer RTP gives no chargeback right, ask the reason, and have a person speak to the customer where the reason is not error, unauthorized payment, or claimed fraudulent inducement (operating guideline 9). Does not address the rule-based detail lines." } ] }, "rail_name": "RTP", "governing_authority": "The Clearing House", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "rtp:finality", "id": "finality", "rail": "rtp", "kind": "rail-fact", "facet": "finality", "name": "When does an RTP payment become final, and can it be reversed?", "statement": "An RTP credit transfer is final and irrevocable once the receiving participant accepts it and the RTP System records settlement, and the sending participant has no right to cancel or amend it. That is not the whole answer. Finality has layers: settlement between the two banks, acceptance under Article 4-A of the New York Uniform Commercial Code, and a consumer's separate rights under the EFTA. A settled payment can still be asked for through a Request for Return of Funds, which the receiving participant must answer but need not honor.", "details": [ { "label": "What the system does", "value": "The rules describe RTP as a system through which participants initiate credit transfers and receive final and irrevocable settlement for them, around the clock.", "citation": "TCH RTP Operating Rules, edition effective 2026-06-01, Rule I.E", "rests_on": "rule" }, { "label": "The moment of settlement finality", "value": "Settlement is complete when the RTP System has recorded both the decrease in the sending participant's net position and the increase in the receiving participant's net position, which are treated as simultaneous. Completion of settlement is final settlement of the payment and final discharge of the sending participant's obligation to pay the receiving participant.", "citation": "TCH RTP Operating Rules, edition effective 2026-06-01, Rule VI.E.6", "rests_on": "rule" }, { "label": "What triggers the obligation to pay", "value": "The sending participant becomes obligated to pay when the receiving participant sends an accept or an accept without posting message to the RTP System. The RTP System records the crediting entries on receipt of either message.", "citation": "TCH RTP Operating Rules, edition effective 2026-06-01, Rule III.D and Rule VI.E.4", "rests_on": "rule" }, { "label": "No cancellation and no amendment by the sender's bank", "value": "A payment message cannot be cancelled or amended by the sending participant once it has been sent to the RTP System. The only cancellation the rules provide is by the RTP System itself, when the receiving participant does not respond in time.", "citation": "TCH RTP Operating Rules, edition effective 2026-06-01, Rule III.E, with Rule IV.A.4", "rests_on": "rule" }, { "label": "Second layer: acceptance under Article 4-A is not the same event", "value": "A payment message accepted without posting is immediately and finally settled, and yet is not accepted for purposes of Article 4-A of the New York Uniform Commercial Code until the receiving participant sends a follow up payment acknowledgement message. So a payment can be finally settled between banks while the 4-A consequences of acceptance have not attached.", "citation": "TCH RTP Operating Rules, edition effective 2026-06-01, Rule V.E.2.b and Rule V.E.2.d", "rests_on": "rule" }, { "label": "Third layer: finality does not decide who bears a loss", "value": "For an erroneous or unauthorized payment that is not subject to the EFTA, the rights and responsibilities of the parties are governed by applicable law including Article 4-A, except where the rules modify it as funds transfer system rules. Where any part of the payment is subject to the EFTA, they are governed by the EFTA and Regulation E.", "citation": "TCH RTP Operating Rules, edition effective 2026-06-01, Rule II.J.1.a and Rule II.J.1.b, with Rule I.F", "rests_on": "law" }, { "label": "A final payment can still be asked back", "value": "A participant may send a Request for Return of Funds for any reason, including an unauthorized or erroneous payment. It is not a cancellation of the payment. The receiving participant must respond to it and is under no obligation to return the funds.", "citation": "TCH RTP Operating Rules, edition effective 2026-06-01, Rule VII.D and Rule VII.D.1", "rests_on": "rule" }, { "label": "Money that comes back is a new payment", "value": "If the receiving side agrees to return funds, the return is initiated as a new credit transfer or another electronic payment method. The request message itself moves no money and there is no reversal of the original payment.", "citation": "TCH RTP Request for Return of Funds Guidelines and Suggested Practices, dated 2021-01-21 (marked Public; guidance, not rule), use case page and guideline 4", "rests_on": "guidance" } ], "exceptions": [ "A payment message that the receiving participant does not answer within the time set in the RTP Technical Specifications is cancelled by the RTP System and never settles, so no finality attaches (Rule IV.A.4).", "A rejected payment message is not settled at all (Rule V.E.3.c).", "Accept without posting settles finally between the banks but gives the receiver no funds. If the receiving participant then decides not to make funds available, it must promptly refund the sending participant, unless legally prohibited (Rule V.E.2.e).", "Finality binds the participants. It does not decide a consumer's claim under the EFTA and Regulation E, or a commercial claim under Article 4-A, both of which run on their own timetables (Rule I.F, Rule II.J).", "TCH may cancel or refuse a payment message it believes to be erroneous or a duplicate before it reaches the receiving participant (Rule IV.A.3)." ], "applies_to": "RTP credit transfers sent through the RTP network operated by The Clearing House, between a sender account and a receiver account both located in the United States", "caveat": "Do not read finality as an answer to \"can the money come back\". It cannot come back by reversal, and it can come back by agreement. The operational question for a payments team is not whether the payment is final, but whether the receiving bank and its customer will agree to send a new payment, which no rule compels them to do.", "related": [ "rtp:settlement", "rtp:hours", "rtp:recall", "rtp:return", "rtp:refund", "rtp:liability", "rtp:consumer-law", "rtp:decision-points" ], "basis": { "sources": "TCH RTP Operating Rules, edition effective 2026-06-01 (marked PUBLIC), read in full for this record: Rule I.E (description of the system), I.F (choice of law), II.J (erroneous and unauthorized payments), III.D (obligation to pay), III.E (no right to cancel or amend), IV.A.3 and IV.A.4 (TCH cancellation and time-out), V.E.2 (accept without posting), V.E.3.c (rejected payments are not settled), VI.E.4 and VI.E.6 (settlement entries and completion of settlement), VII.D and VII.D.1 (Request for Return of Funds). TCH RTP Request for Return of Funds Guidelines and Suggested Practices, dated 2021-01-21 (marked Public; guidance, not rule), use case page and guidelines 2 and 4, for how funds actually move back.", "confidence": "high" }, "currency": { "effective_since": "Long-standing", "effective_note": "The provisions cited are present in the edition effective 2026-06-01. The drafter did not read earlier editions, so the date each provision first took effect is [Unverified]. The 2021 guidelines describe the same finality position, so the substance predates 2021.", "source_edition": "TCH RTP Operating Rules, edition effective 2026-06-01 (marked PUBLIC); TCH RTP Request for Return of Funds Guidelines and Suggested Practices, dated 2021-01-21 (marked Public)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.theclearinghouse.org/-/media/New/TCH/Documents/Payment-Systems/RTP/RTP-Operating-Rules-Effective-June-1-2026pdf.pdf", "source_class": "authoritative_primary", "source_title": "RTP Operating Rules, edition effective 2026-06-01, The Clearing House", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms system description and 24x7x365 (I.E); settlement finality moment and simultaneity (VI.E.4, VI.E.6); obligation to pay trigger (III.D); no cancellation or amendment by sending participant (III.E); accept without posting settles finally but is not 4-A acceptance until follow-up acknowledgement (V.E.2.b); choice of law and EFTA carve-out (I.F, II.J.1); Request for Return of Funds is not a cancellation and carries no obligation to return (VII.D, VII.D.1); time-out cancellation (IV.A.4) and rejected payments not settled (V.E.3.c). Does not address the guidance-sourced line on funds returning as a new payment method, which rests on the 2021 guidelines." }, { "source_url": "https://www.theclearinghouse.org/-/media/New/TCH/Documents/Payment-Systems/RTP_Request_for_Returns_v02-19-2021.pdf", "source_class": "public_primary", "source_title": "RTP Request for Return of Funds Guidelines and Suggested Practices, dated 2021-01-21, The Clearing House", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms the guidance-sourced detail that funds a creditor FI agrees to return move as a new credit transfer or alternate electronic payment method, not a reversal of the original payment (use case page). Does not address the rule-based finality layers, which rest on the Operating Rules." } ] }, "rail_name": "RTP", "governing_authority": "The Clearing House", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "rtp:hours", "id": "hours", "rail": "rtp", "kind": "rail-fact", "facet": "hours", "name": "When is the rail open, and what clock do its deadlines run on?", "statement": "The RTP network is open all the time: 24 hours a day, 7 days a week, every week of the year, including weekends and bank holidays. There is no cut-off, and a receiving participant is forbidden from creating one. Three different clocks still matter. Payments run on the RTP Day, which is a calendar day in Eastern Time. Non-payment message deadlines run on banking days. Funding runs on Fedwire's operating day, which does close.", "details": [ { "label": "Network availability", "value": "The system makes funds available to receivers in real time, twenty four hours a day, seven days a week, fifty two weeks a year.", "citation": "TCH RTP Operating Rules, edition effective 2026-06-01, Rule I.E", "rests_on": "rule" }, { "label": "The payment clock", "value": "An RTP Day is the calendar day in which a payment is made, beginning at 12:00 a.m. and ending at 11:59:59 p.m. Eastern Time.", "citation": "TCH RTP Operating Rules, edition effective 2026-06-01, Rule I.A.89", "rests_on": "rule" }, { "label": "No cut-off times", "value": "Notwithstanding section 4-A-106 of the New York Uniform Commercial Code, a receiving participant may not establish a cut-off time for receiving payment messages that would push the payment onto a different RTP Day, or otherwise delay funds availability.", "citation": "TCH RTP Operating Rules, edition effective 2026-06-01, Rule V.B", "rests_on": "rule" }, { "label": "How fast the receiving bank must answer a payment", "value": "A receiving participant must respond to a payment message within the timeframe established in the RTP Technical Specifications. The rules do not state that timeframe, and the specifications are not public, so the figure is not available from a public source. If the receiving participant does not answer in time, the RTP System cancels the payment message and notifies both participants.", "citation": "TCH RTP Operating Rules, edition effective 2026-06-01, Rule V.A and Rule IV.A.4", "rests_on": "rule" }, { "label": "The accept without posting clock", "value": "A receiving participant that accepts without posting is expected to decide whether it will make funds available by 11:59 p.m. local time the next business day following its accept without posting message.", "citation": "TCH RTP Operating Rules, edition effective 2026-06-01, Rule V.E.2.c", "rests_on": "rule" }, { "label": "The banking day clock for return requests", "value": "A receiving participant must answer a Request for Return of Funds within ten banking days. For this purpose a banking day is that part of any business day on which an office of a participant is open to the public for carrying on substantially all of its banking functions, so a 24x7 payment sits behind a business-hours deadline.", "citation": "TCH RTP Operating Rules, edition effective 2026-06-01, Rule VII.D.2", "rests_on": "rule" }, { "label": "The Fedwire clock for funding", "value": "Supplemental funding must reach the prefunded balance account no later than the next opening of Fedwire if the shortfall arises while Fedwire is closed, or the next close of Fedwire if it arises during Fedwire hours. Participants that have not enabled the FedNow Liquidity Management Transfer service must prefund in advance of the Fedwire close to cover activity while it is shut.", "citation": "TCH RTP Operating Rules, edition effective 2026-06-01, Rule VI.D.2.b and Rule VI.D.3.a", "rests_on": "rule" }, { "label": "What the operator tells the market", "value": "TCH's public RTP network pages describe the network as running 24/7/365, with availability around the clock including bank holidays, weekends and after hours.", "citation": "The Clearing House, RTP network pages at theclearinghouse.org/payment-systems/rtp, read 2026-09-17", "rests_on": "practice" } ], "exceptions": [ "Payment processing is continuous, but the deadlines attached to exception handling are not: the accept without posting decision runs on business days and local time, and the Request for Return of Funds response runs on banking days (Rule V.E.2.c, Rule VII.D.2).", "The next business day expectation for an accept without posting decision does not apply where the payment is being reviewed for compliance with sanctions laws, and that review has no stated deadline (Rule V.E.2.c).", "Requests for return of funds sent for claimed fraud (FRAD) or breach of a Request for Payment warranty (UPAY) are not held to the ten banking day response deadline; the receiving participant is expected to answer promptly once its investigation ends (Rule VII.D.2).", "Funding availability depends on Fedwire's operating day, not on RTP's hours, unless the participant has enabled the FedNow Liquidity Management Transfer service (Rule VI.D.3).", "In an emergency the TCH Chief Executive Officer may direct participants to stop submitting messages or may modify the rules or specifications, which can interrupt availability (Rule IV.E)." ], "applies_to": "the RTP network operated by The Clearing House, for all participants and all message types", "caveat": "24x7 describes when a payment can be sent and settled. It does not describe when a human at the receiving bank will look at an exception. A payment sent at 2 a.m. on a Sunday settles at 2 a.m. on a Sunday, and a request to get it back can sit for ten banking days.", "related": [ "rtp:finality", "rtp:settlement", "rtp:recall", "rtp:return", "rtp:limits" ], "basis": { "sources": "TCH RTP Operating Rules, edition effective 2026-06-01 (marked PUBLIC), read in full for this record: Rule I.A.89 (RTP Day), I.E (round the clock operation), IV.A.4 (time-out), IV.E (emergencies), V.A (immediate response), V.B (no inconsistent cut-off times), V.E.2.c (accept without posting decision deadline), VI.D.2.b and VI.D.3 (Fedwire-linked funding deadlines), VII.D.2 (ten banking days, and the banking day definition). The Clearing House public RTP network pages at theclearinghouse.org/payment-systems/rtp, read 2026-09-17 (public_primary), for the 24/7/365 description only.", "confidence": "high" }, "currency": { "effective_since": "Long-standing", "effective_note": "The provisions cited are present in the edition effective 2026-06-01. Round the clock operation has been the design since the network launched in 2017 [Unverified: earlier editions were not read].", "source_edition": "TCH RTP Operating Rules, edition effective 2026-06-01 (marked PUBLIC)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.theclearinghouse.org/-/media/New/TCH/Documents/Payment-Systems/RTP/RTP-Operating-Rules-Effective-June-1-2026pdf.pdf", "source_class": "authoritative_primary", "source_title": "RTP Operating Rules, edition effective 2026-06-01, The Clearing House", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms round the clock operation, twenty-four hours a day, seven days a week, fifty-two weeks a year (I.E); the RTP Day definition (I.A.89); the ban on receiving participant cut-off times (V.B); the unstated payment response time-out sitting in the gated Technical Specifications, with time-out cancellation on non-response (V.A, IV.A.4); the accept without posting decision deadline of 11:59 p.m. local time the next business day, with a sanctions review exception (V.E.2.c); the ten banking day Request for Return of Funds deadline and the banking day definition (VII.D.2); the Fedwire-linked supplemental funding deadlines (VI.D.2.b, VI.D.3.a)." }, { "source_url": "https://www.theclearinghouse.org/payment-systems/rtp", "source_class": "public_primary", "source_title": "The Clearing House, RTP network page", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms the practice-sourced detail line: TCH's public RTP page describes the network as 24/7/365 with availability around the clock including bank holidays, weekends and after hours. Does not address any of the rule-based timing details." } ] }, "rail_name": "RTP", "governing_authority": "The Clearing House", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "rtp:liability", "id": "liability", "rail": "rtp", "kind": "rail-fact", "facet": "liability", "name": "Who bears the loss when a payment goes wrong?", "statement": "The rulebook mostly declines to answer. For a payment with no consumer leg, loss allocation is left to Article 4-A of the New York Uniform Commercial Code as modified by the rules, and TCH says plainly it will not be a party to a liability dispute between participants. The rules do decide a few things: a receiving participant may rely on the account number and need not check the name against it, a participant may enforce the rules against another only where the rules give it a legal right, and a compliant participant may be entitled to restitution where another's non-compliance caused direct harm. The one place the rules impose a payment obligation between banks is the Request for Payment warranty claim.", "details": [ { "label": "Which law decides", "value": "For a payment no part of which is subject to the EFTA, the rights and obligations of the sending and receiving participants are governed by these rules and by New York law including Article 4-A. Where the rules and Article 4-A conflict, the rules govern as funds transfer system rules.", "citation": "TCH RTP Operating Rules, edition effective 2026-06-01, Rule I.F.1", "rests_on": "law" }, { "label": "Erroneous and unauthorized payments", "value": "For a commercial erroneous or unauthorized payment, rights and responsibilities are governed by applicable law including Article 4-A, except so far as the rules modify it. For one any part of which is subject to the EFTA, they are governed by the EFTA and Regulation E.", "citation": "TCH RTP Operating Rules, edition effective 2026-06-01, Rule II.J.1.a and Rule II.J.1.b", "rests_on": "law" }, { "label": "TCH does not decide liability disputes", "value": "TCH shall not be a party to any dispute between participants about liability for erroneous or unauthorized payments. That determination is left to the participants, including through dispute resolution or judicial process.", "citation": "TCH RTP Operating Rules, edition effective 2026-06-01, Rule II.J.5, with Rule X.D.3", "rests_on": "rule" }, { "label": "Duty to cooperate, not to pay", "value": "Participants must reasonably cooperate among themselves and with TCH in attempts to address and recover unauthorized and erroneous payments, without prejudice to their rights under Article 4-A or the EFTA. Cooperation is not an obligation to return money.", "citation": "TCH RTP Operating Rules, edition effective 2026-06-01, Rule II.J.3, with Rule VII.D.1", "rests_on": "rule" }, { "label": "Account number governs, not the name", "value": "A receiving participant may rely on the receiver's account number in the payment message and is under no obligation to confirm that the message describes the receiver consistently by name and account number. This is where misdirected payment loss tends to settle on the sending side.", "citation": "TCH RTP Operating Rules, edition effective 2026-06-01, Rule V.D", "rests_on": "rule" }, { "label": "The sending bank's duty on consumer payments", "value": "For payments originating from consumer accounts, the sending participant must give the sender the name of the receiver associated with the routing information the sender supplied, or build into the origination process another means of confirming with reasonable assurance that the instruction points at the intended recipient.", "citation": "TCH RTP Operating Rules, edition effective 2026-06-01, Rule III.C.3", "rests_on": "rule" }, { "label": "Failure to make funds available", "value": "Where a receiving participant responded accept and then fails to make funds available to the receiver, that is resolved between the receiving participant and the receiver under section 4-A-404(1) or other applicable law, and the receiving participant may also face rules enforcement.", "citation": "TCH RTP Operating Rules, edition effective 2026-06-01, Rule V.E.1.a", "rests_on": "rule" }, { "label": "One bank suing another", "value": "The right to enforce the rules lies solely with TCH. A participant may enforce against another participant only where the rules give that participant a legal right, and then only through legal process or mutually agreed arbitration. A compliant participant may be entitled to restitution where another's non-compliance caused direct harm to it or its customer.", "citation": "TCH RTP Operating Rules, edition effective 2026-06-01, Rule X.D.1 and Rule X.D.2", "rests_on": "rule" }, { "label": "The one compulsory interbank payment obligation", "value": "A message sending participant that breaches the Request for Payment warranty must pay the claim, on its own positive response or on a binding TCH arbitration decision. This is the exception to TCH staying out of disputes.", "citation": "TCH RTP Operating Rules, edition effective 2026-06-01, Rule VII.C.6.d and Rule VII.C.7.c.iv", "rests_on": "rule" }, { "label": "Loss caused by TCH itself", "value": "For an unauthorized payment caused by TCH, TCH may submit a proof of loss under a financial institution bond or computer crime policy and distribute any recovery. Any loss not paid is borne pro rata by each participant, based on its daily average payment count over the preceding 30 calendar days. TCH's liability under this rule is strictly limited to the amount the insurer pays.", "citation": "TCH RTP Operating Rules, edition effective 2026-06-01, Rule II.J.6.a and Rule II.J.6.c", "rests_on": "rule" }, { "label": "Settlement account exposure", "value": "Funding participants and funding agents indemnify the prefunded balance account bank and each other Federal Reserve Bank, pro rata by average daily RTP usage, and are jointly and severally liable for any unrecovered amount. A defaulting participant owes the others what its default added to their share, plus interest at 1% over the effective federal funds rate.", "citation": "TCH RTP Operating Rules, edition effective 2026-06-01, Rule VI.H.1, VI.H.6 and VI.H.7", "rests_on": "rule" }, { "label": "Fines are separate from loss", "value": "TCH may fine a participant for any rules violation, in three categories with per violation and per occurrence schedules topping out at $100,000 per violation for categories 1 and 2. A fine is not compensation to the harmed participant.", "citation": "TCH RTP Operating Rules, edition effective 2026-06-01, Rule X.B.1 and Rule X.B.3.a.ii", "rests_on": "rule" } ], "exceptions": [ "Where any part of the payment is subject to the EFTA, Regulation E displaces this analysis and Article 4-A does not apply (Rule I.F.2).", "A Request for Payment warranty claim is decided by TCH in a binding arbitration, which is the one liability question TCH does adjudicate (Rule VII.C.7).", "The general limitation of TCH's liability sits in the RTP Participation Rules, a separate rulebook that was not read for this record, so the ceiling on TCH's exposure is not stated here (referred to at Rule II.J.6.c).", "Fraud reporting obligations, and the consequences of failing them, sit in the Risk Management and Fraud Control Requirements schedule, which is not public (Rule II.G).", "A payment sent to the wrong account because a social identifier resolved badly is the sending participant's risk management problem; the rules require risk management over any directory it uses and point at the irrevocable nature of RTP payments, without allocating the loss (Rule III.F)." ], "applies_to": "RTP participants, and the allocation of loss on erroneous, unauthorized and misdirected RTP payments", "caveat": "Nothing in this rulebook makes the receiving bank pay. If your recovery plan depends on the other bank returning money, you have no rule behind you outside the Request for Payment warranty claim; you have a request and a duty on the other side to answer it.", "related": [ "rtp:finality", "rtp:refund", "rtp:recall", "rtp:settlement", "rtp:consumer-law", "rtp:decision-points", "rtp:participants" ], "basis": { "sources": "TCH RTP Operating Rules, edition effective 2026-06-01 (marked PUBLIC), read in full for this record: Rule I.F (choice of law), II.G (fraud reporting), II.J.1, II.J.3, II.J.4, II.J.5 and II.J.6 (erroneous and unauthorized payments, cooperation, TCH not a party, loss caused by TCH), III.C.3 (receiver name for consumer payments), III.F (directory services), V.D (reliance on account number), V.E.1.a (failure to make funds available), VI.H (indemnification and joint and several liability), VII.C.6.d and VII.C.7 (warranty claim payment obligation), VII.D.1 (no duty to return), X.B (fines), X.D (participant liability to other participants). The RTP Participation Rules, which carry the general limitation of liability, were not read.", "confidence": "high" }, "currency": { "effective_since": "Long-standing", "effective_note": "The provisions cited are present in the edition effective 2026-06-01. Earlier editions were not read, so first effective dates are [Unverified]. The Request for Payment warranty claims process is a newer addition than the rest of this framework [Inference].", "source_edition": "TCH RTP Operating Rules, edition effective 2026-06-01 (marked PUBLIC)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.theclearinghouse.org/-/media/New/TCH/Documents/Payment-Systems/RTP/RTP-Operating-Rules-Effective-June-1-2026pdf.pdf", "source_class": "authoritative_primary", "source_title": "RTP Operating Rules, edition effective 2026-06-01, The Clearing House", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms Article 4-A and choice of law for commercial and consumer payments (I.F.1, I.F.2, II.J.1); that TCH will not be a party to a liability dispute between participants, and the cooperation-not-payment duty (II.J.3, II.J.5, X.D.3); that a receiving participant may rely on the account number and need not confirm the name matches it (V.D); the consumer-payment name-confirmation duty on the sending participant (III.C.3); failure to make funds available after an accept resolved under 4-A-404(1) (V.E.1.a); the sole enforcement right lying with TCH, with a participant's narrow right to enforce and restitution for direct harm (X.D.1, X.D.2); the RFP warranty payment obligation as the one compulsory interbank payment (VII.C.6.d, VII.C.7.c.iv); TCH's own insured-loss allocation, pro rata by 30-day average payment count, and its liability capped at insurer payment (II.J.6.a, II.J.6.c); the Prefunded Balance Account indemnification, pro rata by average daily RTP usage, joint and several liability, and the 1% over federal funds default interest rate (VI.H.1, VI.H.6, VI.H.7); and the three-category, per-violation and per-occurrence fine schedule topping out at $100,000 per violation for categories 1 and 2 (X.B.1, X.B.3.a.ii)." } ] }, "rail_name": "RTP", "governing_authority": "The Clearing House", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "rtp:limits", "id": "limits", "rail": "rtp", "kind": "rail-fact", "facet": "limits", "name": "What limits apply to an RTP payment, and who sets them?", "statement": "The network limit is $10,000,000 per payment, raised from $1,000,000 effective 2025-02-09. A sending participant may set a lower limit for its own senders; a receiving participant may not set one for its receivers. Underneath the per-payment limit sit liquidity limits that cap what a bank can send in practice: its prefunded position, a net send limit if it funds through a funding provider, and any origination control TCH chooses to impose. Those figures are set per participant and TCH does not publish them.", "details": [ { "label": "Network transaction limit", "value": "An RTP payment may not exceed the general transaction limit of $10,000,000.", "citation": "TCH RTP Operating Rules, edition effective 2026-06-01, Rule II.C.2", "rests_on": "rule" }, { "label": "When the current limit took effect", "value": "TCH announced the increase to $10,000,000 on 2024-12-04, effective 2025-02-09. The previous limit was $1,000,000, in place since April 2022, which had itself replaced $100,000.", "citation": "The Clearing House, \"Higher $10 Million RTP Network Transaction Limit Empowers New Uses\", dated 2024-12-04, theclearinghouse.org", "rests_on": "guidance" }, { "label": "A sending bank may go lower", "value": "Sending participants may establish a lower transaction limit for their senders. So the limit a corporate actually faces is its own bank's, which may be well below the network limit and is not published anywhere.", "citation": "TCH RTP Operating Rules, edition effective 2026-06-01, Rule II.C.2.a", "rests_on": "rule" }, { "label": "A receiving bank may not", "value": "Receiving participants may not establish a lower transaction limit for their receivers. A receiving participant cannot refuse a payment for being too large; its permitted reject reasons are the ones in Rule V.C.", "citation": "TCH RTP Operating Rules, edition effective 2026-06-01, Rule II.C.2.b, with Rule V.C", "rests_on": "rule" }, { "label": "Liquidity limit: the prefunded position", "value": "The system will not release a payment message unless the sending participant's or its funding provider's current prefunded position covers the amount. The prefunded requirement is a dollar amount determined by TCH per participant and is not published.", "citation": "TCH RTP Operating Rules, edition effective 2026-06-01, Rule VI.E.1 and Rule I.A.67", "rests_on": "rule" }, { "label": "Liquidity limit: net send limit", "value": "A funding provider must set a limit on the negative net position each non-funding group member may incur during a reconciliation window. The system will not release a payment that would push the member past that limit. The total of these limits for a group may exceed the funding provider's prefunded requirement.", "citation": "TCH RTP Operating Rules, edition effective 2026-06-01, Rule VI.D.5.a and Rule VI.E.1", "rests_on": "rule" }, { "label": "Operational limit: TCH origination controls", "value": "To manage operational risk, TCH may establish controls on the gross value of RTP payments a participant may originate during an RTP Day. The rules state the power without stating any value.", "citation": "TCH RTP Operating Rules, edition effective 2026-06-01, Rule IX.B", "rests_on": "rule" }, { "label": "No netting of fees against principal", "value": "A participant may not reduce the principal amount of an RTP payment to collect fees. It may charge its customers separately.", "citation": "TCH RTP Operating Rules, edition effective 2026-06-01, Rule II.D", "rests_on": "rule" }, { "label": "No stated minimum", "value": "The Operating Rules read for this record state a maximum and no minimum payment amount.", "citation": "TCH RTP Operating Rules, edition effective 2026-06-01, Rule II.C (absence of a minimum)", "rests_on": "rule" } ], "exceptions": [ "The $10,000,000 figure is a ceiling, not an entitlement. A sender's actual limit is whatever its own bank sets under Rule II.C.2.a, and that figure is not public for any bank.", "A bank funding through a funding provider is additionally capped by its net send limit, which resets to zero at the opening of each reconciliation window (Rule VI.D.5.b).", "TCH may raise a participant's prefunded requirement, or take other action, if it does not hold an adequate position while Fedwire is closed (Rule VI.D.3.a).", "Limits on Request for Payment messages, non-payment messages and returns of funds are not stated in the Operating Rules; any such limits would sit in the RTP Technical Specifications, which are gated." ], "applies_to": "each individual RTP credit transfer, and the aggregate sending capacity of an RTP participant", "caveat": "Do not quote $10,000,000 to a customer as their limit. It is the network ceiling. Their bank's own limit, their prefunded position and, for a bank inside a non-funding group, its net send limit all bite first, and none of the three is published.", "related": [ "rtp:settlement", "rtp:finality", "rtp:participants", "rtp:hours" ], "basis": { "sources": "TCH RTP Operating Rules, edition effective 2026-06-01 (marked PUBLIC), read in full for this record: Rule I.A.67 (prefunded requirement), II.C.2 with subsections a and b (transaction limit and who may lower it), II.D (no fee netting), V.C (permitted reject reasons), VI.D.3.a and VI.D.5 (prefunded position management and net send limits), VI.E.1 (release condition), IX.B (origination controls). The Clearing House, \"Higher $10 Million RTP Network Transaction Limit Empowers New Uses\", dated 2024-12-04 (public_primary), for the effective date and the limit history. The Clearing House public RTP network pages, read 2026-09-17 (public_primary), which state up to $10 million per transaction.", "confidence": "high" }, "currency": { "effective_since": "2025-02-09", "effective_note": "The $10,000,000 limit took effect 2025-02-09, per TCH's announcement of 2024-12-04. The rule that a sending participant may lower the limit and a receiving participant may not is older and its first effective date is [Unverified]. A limit change supersedes this record; the watch reads the TCH announcement pages.", "source_edition": "TCH RTP Operating Rules, edition effective 2026-06-01 (marked PUBLIC), Rule II.C.2; TCH announcement dated 2024-12-04", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.theclearinghouse.org/-/media/New/TCH/Documents/Payment-Systems/RTP/RTP-Operating-Rules-Effective-June-1-2026pdf.pdf", "source_class": "authoritative_primary", "source_title": "RTP Operating Rules, edition effective 2026-06-01, The Clearing House", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms the ,000,000 network transaction limit (II.C.2); that a sending participant may set a lower limit and a receiving participant may not (II.C.2.a, II.C.2.b); the prefunded position release condition with no published dollar figure (VI.E.1, I.A.67); the funding provider net send limit on non-funding group members (VI.D.5.a); TCH's undisclosed origination controls (IX.B); the ban on netting fees against principal (II.D); and the absence of any stated minimum in Rule II.C." }, { "source_url": "https://www.theclearinghouse.org/payment-systems/Articles/2024/12/Higher_10_Million_RTP_Network_Transaction_Limit_Empowers_New_Uses_12-04-2024", "source_class": "public_primary", "source_title": "The Clearing House, Higher $10 Million RTP Network Transaction Limit Empowers New Uses, dated 2024-12-04", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms the guidance-sourced effective-date history: the $10,000,000 limit was announced 2024-12-04 and became effective 2025-02-09; the prior $1,000,000 limit had been in place since April 2022, itself replacing a $100,000 limit. Does not address the rule-based detail lines." } ] }, "rail_name": "RTP", "governing_authority": "The Clearing House", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "rtp:messages", "id": "messages", "rail": "rtp", "kind": "rail-fact", "facet": "messages", "name": "What messages exist on this rail, and what standard are they in?", "statement": "RTP runs on ISO 20022, through TCH's own usage rules called the RTP Technical Specifications. The Operating Rules name the business message families and say the specifications define their format, but they do not publish the ISO message identifiers or the code lists, and the specifications themselves are gated behind the RTP Documentation Agreement. Four ISO identifiers are confirmed by a public TCH document: pacs.008 for the credit transfer, pacs.002 for the status message, camt.056 for the Request for Return of Funds and camt.029 for the response to it.", "details": [ { "label": "The standard", "value": "Participants must comply with the RTP Technical Specifications, whose messaging specifications and terminology are based on the ISO 20022 Universal financial industry message scheme.", "citation": "TCH RTP Operating Rules, edition effective 2026-06-01, Rule II.A and Rule I.D", "rests_on": "rule" }, { "label": "ISO terminology has no legal effect", "value": "The ISO 20022 terms used in the messages, including agent, creditor and debtor, have no legal effect on the status or nature of the payment or the relationships between the parties. Where the specifications and the rules are inconsistent, the rules govern.", "citation": "TCH RTP Operating Rules, edition effective 2026-06-01, Rule I.D", "rests_on": "rule" }, { "label": "Payment messages and their responses", "value": "A payment message instructs the receiving participant to pay a fixed US dollar amount. A payment message response is an accept, an accept without posting, or a reject.", "citation": "TCH RTP Operating Rules, edition effective 2026-06-01, Rule I.A.58 and Rule I.A.59", "rests_on": "rule" }, { "label": "Payment-related messages", "value": "The named payment-related messages are the Request for Payment, the Request for Information, the Remittance Advice, the Payment Acknowledgement, and the Request for Return of Funds. Their responses are the Response to Request for Payment, the Response to Request for Information, and the Response to Request for Return of Funds.", "citation": "TCH RTP Operating Rules, edition effective 2026-06-01, Rule I.A.60 and Rule I.A.61", "rests_on": "rule" }, { "label": "ISO identifiers confirmed by a public TCH document", "value": "The credit transfer is pacs.008, the Request for Return of Funds is camt.056, and the Response to Request for Return of Funds is camt.029. All participants are required to support the receipt, acknowledgement and response to camt.056, pacs.002 and camt.029.", "citation": "TCH RTP Request for Return of Funds Guidelines and Suggested Practices, dated 2021-01-21 (marked Public; guidance, not rule), use case page and operating guideline 3", "rests_on": "guidance" }, { "label": "The rest of the catalogue is not public", "value": "The Operating Rules do not give ISO identifiers for the Request for Payment, the Request for Information, the Remittance Advice or the Payment Acknowledgement, and no public TCH document read for this record does either. The RTP Message Specifications, which hold the identifiers and the permitted code lists, are covered by the RTP Documentation Agreement and were not opened.", "citation": "TCH RTP Operating Rules, edition effective 2026-06-01, Rule I.A.95 (the specifications are made available to participants); Orca's RTP rail brief (docs/rails/rtp.md), Blocked section, dated 2026-09-17", "rests_on": "rule" }, { "label": "Reason codes live in the specifications, not the rules", "value": "A receiving participant must include a valid and most appropriate reason code with a reject message as specified in the RTP Technical Specifications. The Operating Rules name only a handful of codes in passing: FRAD and UPAY as return request reasons, CUST as a negative response reason, and RJCR as the negative response status.", "citation": "TCH RTP Operating Rules, edition effective 2026-06-01, Rule V.E.3.b and Rule VII.D.2 and VII.D.4", "rests_on": "rule" }, { "label": "Fields the rules do mandate", "value": "An on behalf of payment must be identified with the intermediary local instrument code, with the payer as ultimate debtor and any initiating customer as the initiating party; a payee must be identified as ultimate creditor. Name fields must carry legal names and may not hold an email address, social media handle or reference number unless expressly permitted.", "citation": "TCH RTP Operating Rules, edition effective 2026-06-01, Rule II.H.1 and Rule II.H.2", "rests_on": "rule" }, { "label": "Tokens in messages", "value": "Any participant may send or receive payment messages, Requests for Payment or Remittance Advices containing Tokens, whether or not it is enrolled in the Token Service. A token-bearing message is identified by a Token Participant Identifier, and TCH publishes the list of those identifiers on its public website.", "citation": "TCH RTP Operating Rules, edition effective 2026-06-01, Rule II.M.1 and Rule II.M.2", "rests_on": "rule" }, { "label": "What must reach the customer", "value": "Participants must make available to their customers the message fields the specifications designate as required to be made available, with stated exceptions for offensive content, rejected payments, opted-out Requests for Payment, and customers not enrolled in online or mobile banking.", "citation": "TCH RTP Operating Rules, edition effective 2026-06-01, Rule II.F.2", "rests_on": "rule" } ], "exceptions": [ "ISO 20022's own public catalogue could not be consulted: iso20022.org returned HTTP 403 to a plain fetch on 2026-09-17, and no user agent was spoofed. Generic ISO message names are therefore not cited here.", "A code valid in the ISO external code sets is not necessarily permitted on RTP; the TCH specification decides, and that specification is gated (Rule V.E.3.b, Rule I.D).", "Older bank and processor guides describe RTP messages from the 2017 to 2019 specification versions, which may not match the current version [Unverified].", "The RTP Technical Specifications are versioned separately from the Operating Rules and change on their own cycle, so a message fact can go stale without any rules edition changing (Rule I.A.95)." ], "applies_to": "all messages exchanged between RTP participants and the RTP System", "caveat": "This facet is deliberately thin. The authoritative message catalogue and every permitted code list sit in documents Orca has not accepted the terms for, so what is recorded here is only what TCH states in its public rulebook and its public guidance. Absence of a message from this record is a gap in Orca, not evidence the message does not exist.", "related": [ "rtp:return", "rtp:recall", "rtp:refund", "rtp:finality", "rtp:participants", "rtp:settlement" ], "basis": { "sources": "TCH RTP Operating Rules, edition effective 2026-06-01 (marked PUBLIC), read in full for this record: Rule I.A.43, I.A.56, I.A.58 to I.A.61, I.A.76 to I.A.86 (message definitions), I.A.95 (RTP Technical Specifications), I.D (ISO 20022 basis and precedence), II.A (compliance), II.F.2 (information to customers), II.H (payment transparency fields), II.M (Tokens), V.E.3.b (reject reason codes), VII.A (non-payment messages), VII.D.2 and VII.D.4 (FRAD, UPAY, CUST, RJCR named in the rules). TCH RTP Request for Return of Funds Guidelines and Suggested Practices, dated 2021-01-21 (marked Public; guidance, not rule), use case page and operating guidelines 3, 10 and 11, for pacs.008, pacs.002, camt.056 and camt.029. The RTP Message Specifications and the per-message technical documents were not opened, as recorded under Blocked in Orca's RTP rail brief (docs/rails/rtp.md). iso20022.org returned HTTP 403 to a plain fetch on 2026-09-17.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_note": "The message families and the ISO 20022 basis are present in the edition effective 2026-06-01, and the four confirmed identifiers appear in the 2021 guidelines. The RTP Message Specifications are at version 5.0 and the reports specification at 5.2 per Orca's RTP rail brief (docs/rails/rtp.md), neither consulted, so the current message set is [Unverified].", "source_edition": "TCH RTP Operating Rules, edition effective 2026-06-01 (marked PUBLIC); TCH RTP Request for Return of Funds Guidelines and Suggested Practices, dated 2021-01-21 (marked Public)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.theclearinghouse.org/-/media/New/TCH/Documents/Payment-Systems/RTP/RTP-Operating-Rules-Effective-June-1-2026pdf.pdf", "source_class": "authoritative_primary", "source_title": "RTP Operating Rules, edition effective 2026-06-01, The Clearing House", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms the ISO 20022 basis of the RTP Technical Specifications and that ISO terms have no legal effect on the payment's status (I.D, II.A); the payment message and response definitions, and the named payment-related messages (I.A.58-61); that the specifications, not the rules, hold reason codes, with only FRAD, UPAY, CUST and RJCR named in passing (V.E.3.b, VII.D.2, VII.D.4); the payment transparency and name-field requirements (II.H.1, II.H.2); that any participant may send or receive Token-bearing messages whether or not enrolled, identified by a Token Participant Identifier that TCH publishes on its public website (II.M.1, II.M.2); and the customer information-availability duty and its exceptions (II.F.2). Does not address the guidance-sourced line naming pacs.008, camt.056 and camt.029, which rests on the 2021 guidelines." }, { "source_url": "https://www.theclearinghouse.org/-/media/New/TCH/Documents/Payment-Systems/RTP_Request_for_Returns_v02-19-2021.pdf", "source_class": "public_primary", "source_title": "RTP Request for Return of Funds Guidelines and Suggested Practices, dated 2021-01-21, The Clearing House", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms pacs.008 for the credit transfer, camt.056 for the Request for Return of Funds, and camt.029 for the response, and that all participants must support receipt, acknowledgement and response to camt.056, pacs.002 and camt.029 (use case page, operating guideline 3). Does not address the rule-based detail lines." } ] }, "rail_name": "RTP", "governing_authority": "The Clearing House", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "rtp:participants", "id": "participants", "rail": "rtp", "kind": "rail-fact", "facet": "participants", "name": "Who can be on this rail, in what roles, and who cannot?", "statement": "Only a depository institution that has signed the RTP Participant Agreement and Indemnity is a participant. The eligibility tests themselves sit in the RTP Participation Rules, a separate rulebook the drafter did not read. Participants divide by funding role rather than by size: they fund for themselves, fund through an agent, or send against a funding provider's position. Non-banks cannot be participants, though a payment service provider with a TCH agreement can be a sender, and a third-party service provider can act for a participant. Both accounts in a payment must be in the United States, and banks may not use RTP as a correspondent rail.", "details": [ { "label": "What a participant is", "value": "A participant is a depository institution that has entered into an RTP Participant Agreement and Indemnity. Prospective participants must satisfy the requirements in the RTP Participation Rules, and a participant must comply at all times with the Operating Rules, the Technical Specifications, the Risk Management and Fraud Control Requirements and the Information Security Standards and Requirements.", "citation": "TCH RTP Operating Rules, edition effective 2026-06-01, Rule I.A.50 and Rule II.A", "rests_on": "rule" }, { "label": "Funding roles", "value": "A funding participant funds for itself over Fedwire. A non-funding participant either holds a position through a funding manager acting as its agent, or holds no position at all as a member of a non-funding group behind a funding provider. Funding agent covers funding managers and funding providers. Participants that only receive have no prefunded requirement.", "citation": "TCH RTP Operating Rules, edition effective 2026-06-01, Rule I.A.26 to I.A.29, Rule I.A.41 and I.A.42, Rule I.A.67, Rule VI.B", "rests_on": "rule" }, { "label": "Receive-only banks", "value": "A receive-only bank can certify against an RTP persona that lets it send credit transfers solely to return funds, which TCH's guidance encourages. Banks with that capability are described in the market as Receive plus.", "citation": "TCH RTP Request for Return of Funds Guidelines and Suggested Practices, dated 2021-01-21 (marked Public; guidance, not rule), use case note 2 and the lessons learned page", "rests_on": "guidance" }, { "label": "Non-banks", "value": "A payment service provider, defined as a money services business acting as a money transmitter that sends payments to complete payments between other parties, may be a sender under a PSP Agreement with TCH, subject to a PSP application, annual certification and compliance criteria. A PSP is a sender, not a participant.", "citation": "TCH RTP Operating Rules, edition effective 2026-06-01, Rule I.A.62, I.A.68, I.A.69 and I.A.70", "rests_on": "rule" }, { "label": "Agents", "value": "A third-party service provider is an entity a participant designates to act as its agent under the Participation Rules and the Operating Rules, and TCH may audit it directly. A participant may act as a third-party service provider for another participant.", "citation": "TCH RTP Operating Rules, edition effective 2026-06-01, Rule I.A.104, Rule II.B.1.b.i and Rule IX.A.1.c", "rests_on": "rule" }, { "label": "Geographic limit", "value": "RTP may be used only for payments between a sender and a receiver whose accounts are located in the United States, meaning the fifty states, the District of Columbia and Puerto Rico. Where a payment is sent or received for another person, that person must be resident or domiciled in the United States.", "citation": "TCH RTP Operating Rules, edition effective 2026-06-01, Rule II.E.2 and Rule I.A.110", "rests_on": "rule" }, { "label": "No correspondent participation", "value": "A participant may not submit a payment message instructed by, or paying, a foreign depository institution. Payments involving a domestic depository institution as sender or receiver are allowed only under the five listed exceptions, and the sending participant warrants to TCH that each such payment meets them.", "citation": "TCH RTP Operating Rules, edition effective 2026-06-01, Rule II.B.1 and Rule II.B.2", "rests_on": "rule" }, { "label": "On behalf of senders", "value": "A participant may send on behalf of payments for a sender or an initiating customer, subject to risk-based due diligence on both, transparency controls, payer identity verification and OFAC screening of payer names. Nested on behalf of activity is prohibited.", "citation": "TCH RTP Operating Rules, edition effective 2026-06-01, Rule II.I.1, Rule II.I.2 and Rule II.H.4", "rests_on": "rule" }, { "label": "How many are on the network", "value": "TCH's public RTP page stated over 1,357 participants as of August 2026 and more than 1.7 billion transactions processed since the network began in 2017. TCH publishes the list of participating financial institutions on a public page, by name and state, without routing numbers and without a stated total.", "citation": "The Clearing House, RTP network pages and RTP Network Participating Financial Institutions page at theclearinghouse.org, read 2026-09-17", "rests_on": "practice" }, { "label": "Getting removed", "value": "TCH may limit, condition, suspend or terminate a participant for non-compliance, and may do the same to a customer's use of the system for misuse or abuse. Revoking the authorization for TCH fee debits is treated as notice of termination.", "citation": "TCH RTP Operating Rules, edition effective 2026-06-01, Rule X.C.2, Rule X.C.3 and Rule VIII.B.4", "rests_on": "rule" } ], "exceptions": [ "The eligibility criteria for becoming a participant are in the RTP Participation Rules, which were not read for this record. This record states who participates, not what a bank must demonstrate to be admitted (Rule II.A).", "The five exceptions to the correspondent participation ban permit payments involving domestic depository institutions in specific structures, including a participant sending for itself and a participant acting as a third-party service provider for another (Rule II.B.1.b.i to v).", "Token participants are a separate enrolment under the Token Service Rules, which are not part of the Operating Rules; any participant may still send and receive token-bearing messages without enrolling (Rule I.I.1 and Rule II.M.1).", "Indirect domestic send and on line originator arrangements were added by the editions effective 2026-09-30 and 2026-10-04, which were not read for this record [Unverified: from the watch log in Orca's RTP rail brief, docs/rails/rtp.md].", "The participant count is a moving figure published by the operator for marketing purposes, not a rule, and should be re-read rather than quoted from this record." ], "applies_to": "institutions and non-bank senders using the RTP network in the United States", "caveat": "Reachability is not participation. A bank appearing on TCH's participating institutions list may be receive-only, which means it can take a payment and cannot send one, including cannot send one back, unless it has certified for the return-of-funds persona.", "related": [ "rtp:settlement", "rtp:limits", "rtp:messages", "rtp:hours", "rtp:liability" ], "basis": { "sources": "TCH RTP Operating Rules, edition effective 2026-06-01 (marked PUBLIC), read in full for this record: Rule I.A.26 to I.A.29, I.A.31, I.A.41, I.A.42, I.A.48, I.A.50, I.A.62, I.A.67 to I.A.70, I.A.104, I.A.110 (definitions), I.I.1 (Token Service), II.A (eligibility and compliance), II.B (no correspondent participation), II.E.2 (foreign payments), II.H.4 (no nested on behalf of activity), II.I (minimum requirements for sending on behalf of payments), II.M (Tokens), VI.B (funding roles), VIII.B.4 (revocation as termination notice), IX.A.1.c (audit of third-party service providers), X.C (additional penalties). TCH RTP Request for Return of Funds Guidelines and Suggested Practices, dated 2021-01-21 (marked Public), use case note 2 and lessons learned, for receive-only personas. The Clearing House public RTP network pages and the RTP Network Participating Financial Institutions page, read 2026-09-17 (public_primary), for the participant count and the published list. The RTP Participation Rules were not read.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_note": "The roles and restrictions cited are present in the edition effective 2026-06-01. The participant count is as TCH published it for August 2026, read 2026-09-17, and moves continuously. Editions effective 2026-09-30 and 2026-10-04 add indirect domestic send and on line originator arrangements and were not read [Unverified: from the watch log in Orca's RTP rail brief, docs/rails/rtp.md].", "source_edition": "TCH RTP Operating Rules, edition effective 2026-06-01 (marked PUBLIC); TCH public RTP pages read 2026-09-17", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "rail_name": "RTP", "governing_authority": "The Clearing House", "snapshot": "2026-09-17", "source_class": null, "effective_status": "draft", "effective_status_reason": null, "boundaries": [] }, { "uid": "rtp:recall", "id": "recall", "rail": "rtp", "kind": "rail-fact", "facet": "recall", "name": "Can a sent payment be recalled, and who decides?", "statement": "No party can recall an RTP payment. The sending participant cannot cancel or amend it once it has gone to the system, and the only cancellation in the rules is the system's own time-out. What exists instead is the Request for Return of Funds, a non-payment message asking the receiving participant to send the money back. The receiving participant must answer it within ten banking days, and is free to say no. The decision belongs to the receiving bank, and in practice to its customer.", "details": [ { "label": "No cancellation by the sender's bank", "value": "A payment message cannot be cancelled or amended by the sending participant once it has been sent to the RTP System.", "citation": "TCH RTP Operating Rules, edition effective 2026-06-01, Rule III.E", "rests_on": "rule" }, { "label": "The only cancellation the rules provide", "value": "A payment message can be cancelled by the RTP System on a time-out, when the receiving participant fails to respond within the timeframe in the RTP Technical Specifications. Both participants are notified.", "citation": "TCH RTP Operating Rules, edition effective 2026-06-01, Rule III.E and Rule IV.A.4", "rests_on": "rule" }, { "label": "A request may be sent for any reason", "value": "A participant may send a Request for Return of Funds for any reason, including an unauthorized or erroneous payment or a payment made in response to a fraudulent Request for Payment.", "citation": "TCH RTP Operating Rules, edition effective 2026-06-01, Rule VII.D", "rests_on": "rule" }, { "label": "It is not a cancellation, and it carries no 4-A liability", "value": "A Request for Return of Funds is not a cancellation of the payment, so a participant that sends one has no liability to the receiving participant under section 4-A-211(6) of the New York Uniform Commercial Code.", "citation": "TCH RTP Operating Rules, edition effective 2026-06-01, Rule VII.D", "rests_on": "rule" }, { "label": "Answer required, return not", "value": "A receiving participant must respond to a Request for Return of Funds with a Response to Request for Return of Funds, and is under no obligation to return the funds.", "citation": "TCH RTP Operating Rules, edition effective 2026-06-01, Rule VII.D.1", "rests_on": "rule" }, { "label": "The response deadline", "value": "The receiving participant must send its response within ten banking days of receiving the request, except where the request is sent for claimed fraud (FRAD) or breach of a Request for Payment warranty (UPAY). For those the receiving participant may take longer to investigate and is expected to answer promptly once the investigation ends.", "citation": "TCH RTP Operating Rules, edition effective 2026-06-01, Rule VII.D.2", "rests_on": "rule" }, { "label": "When to send one", "value": "Requests should be submitted within 60 calendar days of the original credit transfer to allow investigation. Fraud claims and requests about payments made against a Request for Payment claimed to lack a legitimate purpose are outside the 60 day and 10 day expectations and follow the bank's own policies.", "citation": "TCH RTP Request for Return of Funds Guidelines and Suggested Practices, dated 2021-01-21 (marked Public; guidance, not rule), operating guideline 5", "rests_on": "guidance" }, { "label": "An indemnity does not compel a return", "value": "A participant may offer an indemnity with its request under the RTP Request for Return of Funds Indemnity Schedule. The receiving participant has no obligation to accept the offer, to block funds, or to return funds where one has been offered.", "citation": "TCH RTP Operating Rules, edition effective 2026-06-01, Rule VII.D.3; guidelines dated 2021-01-21, operating guideline 6", "rests_on": "rule" }, { "label": "Asking twice", "value": "A sending participant may not resubmit a request for the same payment after a negative response given because the receiver refused to return the funds, unless TCH requires the resubmission. The guidelines allow one further request after a non-response or inability to contact the beneficiary, after no response inside the ten banking day service level, after a partial return for the balance, or by agreement.", "citation": "TCH RTP Operating Rules, edition effective 2026-06-01, Rule VII.D.4; guidelines dated 2021-01-21, operating guideline 8", "rests_on": "rule" }, { "label": "If the answer is yes, money moves as a new payment", "value": "The return is initiated by a new credit transfer or another electronic payment method: an RTP credit transfer, a wire, an ACH credit, or, discouraged, a check. Funds should reach the original sender within two business days of the positive response. A partial return is allowed and is flagged on the response.", "citation": "TCH RTP Request for Return of Funds Guidelines and Suggested Practices, dated 2021-01-21 (marked Public; guidance, not rule), operating guidelines 2, 4 and 10", "rests_on": "guidance" } ], "exceptions": [ "A payment that has not yet been accepted is a different situation: the system, not any participant, may cancel it on time-out (Rule IV.A.4), and TCH may decline to process a message it believes erroneous or duplicate (Rule IV.A.3).", "The ten banking day deadline does not apply to FRAD or UPAY requests (Rule VII.D.2).", "The 60 calendar day submission expectation is guidance, not a rule, and does not apply to fraud claims or Request for Payment warranty matters (guidelines, operating guideline 5).", "A separate and compulsory path exists for a Request for Payment warranty breach: the message receiving participant uses the Request for Return of Funds message to start a warranty claim, and a message sending participant that gives a positive response or loses the arbitration must return the funds (Rule VII.C.3.a, VII.C.6.d and VII.C.7.d). That is an obligation, unlike an ordinary request.", "There is no bulk recall. The guidelines state the network has no message or utility supporting a bulk return of funds, and direct bank to bank contact is recommended for mass duplicate files (guidelines, use case note 1)." ], "applies_to": "a settled RTP credit transfer that the sending side wants back, and a payment message that has not yet been accepted", "caveat": "The reason codes carried on a Request for Return of Funds (FRAD, UPAY, DUPL, TECH, UAPA) and the response codes (CUST, NOAS, IPAY, PECR) are described in reason-code records under corpus/rtp-return-request where they exist; at snapshot the corpus holds records for the request reasons and for CUST and NOAS, not for IPAY or PECR. A new code, UAPA, applies to fraudulently induced payments [Unverified: from the watch log in Orca's RTP rail brief, docs/rails/rtp.md, dated 2026-09-17, not re-read for this record].", "related": [ "rtp:finality", "rtp:return", "rtp:settlement", "rtp:refund", "rtp:messages", "rtp:decision-points", "rtp:hours" ], "basis": { "sources": "TCH RTP Operating Rules, edition effective 2026-06-01 (marked PUBLIC), read in full for this record: Rule III.E (no right to cancel or amend), IV.A.3 and IV.A.4 (TCH cancellation and time-out), VII.C.3, VII.C.6 and VII.C.7 (Request for Payment warranty claims, which use the same message but create an obligation), VII.D and its subsections 1 to 4 (Request for Return of Funds, response duty, ten banking days with the FRAD and UPAY exception, indemnity, resubmission bar). TCH RTP Request for Return of Funds Guidelines and Suggested Practices, dated 2021-01-21 (marked Public; guidance, not rule), use case note 1 and operating guidelines 2, 4, 5, 6, 8 and 10.", "confidence": "high" }, "currency": { "effective_since": "Long-standing", "effective_note": "The provisions cited are present in the edition effective 2026-06-01. The ten banking day response deadline and the FRAD exemption are recorded in the 2019-11-18 rule change summary, as cited in Orca's rtp-return-request:FRAD entry [Unverified: that summary was not read for this record]. From 2027-03-01 fraud reports are to be sent within 2 business days of the fraud determination, which will change the request timing [Unverified: from the watch log in Orca's RTP rail brief, docs/rails/rtp.md].", "source_edition": "TCH RTP Operating Rules, edition effective 2026-06-01 (marked PUBLIC), Rule VII.D; TCH RTP Request for Return of Funds Guidelines and Suggested Practices, dated 2021-01-21 (marked Public)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.theclearinghouse.org/-/media/New/TCH/Documents/Payment-Systems/RTP/RTP-Operating-Rules-Effective-June-1-2026pdf.pdf", "source_class": "authoritative_primary", "source_title": "RTP Operating Rules, edition effective 2026-06-01, The Clearing House", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms no cancellation or amendment by the sending participant, and the RTP System time-out as the only cancellation (III.E, IV.A.4); that a Request for Return of Funds may be sent for any reason and is not a cancellation with no 4-A-211(6) liability (VII.D); the response requirement with no duty to return funds (VII.D.1); the ten banking day response deadline with the FRAD/UPAY exception (VII.D.2); the indemnity offer creating no obligation to accept, block, or return (VII.D.3); and the resubmission bar after a CUST-reason RJCR response, with the TCH-required exception (VII.D.4)." }, { "source_url": "https://www.theclearinghouse.org/-/media/New/TCH/Documents/Payment-Systems/RTP_Request_for_Returns_v02-19-2021.pdf", "source_class": "public_primary", "source_title": "RTP Request for Return of Funds Guidelines and Suggested Practices, dated 2021-01-21, The Clearing House", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms the guidance-sourced 60 calendar day submission expectation and the fraud/illegitimate-RFP exemption from the 60 day/10 day timeframes (operating guideline 5); that funds a creditor FI agrees to return move as a new RTP credit transfer, wire, ACH credit, or discouraged check, within two business days of a positive response (operating guidelines 2 and 4); and that there is no bulk return of funds capability, with direct bank contact recommended for mass duplicate files (use case note 1)." } ] }, "rail_name": "RTP", "governing_authority": "The Clearing House", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "rtp:refund", "id": "refund", "rail": "rtp", "kind": "rail-fact", "facet": "refund", "name": "Does anyone have a right to be refunded, and on what grounds?", "statement": "RTP gives no general refund right. Sending a payment you regret buys you a request the other bank can decline. There are two places where the rules do compel money back, and both are narrow: a receiving participant that accepted without posting and then declines to post must refund the sending participant, and a bank whose customer was harmed by a Request for Payment that breached the RFP warranty can bring a claim the other bank must investigate, answer in 20 business days, and pay if it agrees or loses the arbitration. Consumer rights under the EFTA run separately and are not a rail rule.", "details": [ { "label": "The default", "value": "There is no obligation on the receiving participant to return funds once a payment has settled. It must answer a Request for Return of Funds; it need not honor it.", "citation": "TCH RTP Operating Rules, edition effective 2026-06-01, Rule VII.D.1", "rests_on": "rule" }, { "label": "Compulsory refund 1: accept without posting, then decline", "value": "A receiving participant that accepted without posting and determines not to make funds available must promptly refund the amount to the sending participant, by a new payment message if it is also a sending participant, or through another payment mechanism if it is not, unless it is legally prohibited from refunding.", "citation": "TCH RTP Operating Rules, edition effective 2026-06-01, Rule V.E.2.e, with V.E.2.e.i and V.E.2.e.ii", "rests_on": "rule" }, { "label": "Compulsory refund 2: breach of the Request for Payment warranty", "value": "A message sending participant warrants to TCH and to the message receiving participant that each Request for Payment is made for a legitimate purpose and is not part of a fraudulent scheme to induce payment, harassing, or otherwise unlawful. The receiving side's bank may bring a claim for breach of that warranty.", "citation": "TCH RTP Operating Rules, edition effective 2026-06-01, Rule VII.B.2.d, with Rule I.A.80", "rests_on": "rule" }, { "label": "Who may bring a warranty claim, and by when", "value": "A message receiving participant may claim if its customer made a responding payment against the Request for Payment, the claim is initiated within 95 calendar days of the date of that payment, it has obtained a customer statement meeting the stated content requirements, and it has determined the statement if true would support a valid claim.", "citation": "TCH RTP Operating Rules, edition effective 2026-06-01, Rule VII.C.1 and Rule VII.C.2", "rests_on": "rule" }, { "label": "Grounds that support a warranty claim", "value": "No legitimate purpose, which for a business sender means the request was not for a current sale or an amount due, and for a consumer sender means the sender is not known to the receiver and the receiver did not reasonably expect the request; the request was used to solicit a payment in a fraudulent scheme to induce it; it was harassing in language or frequency; or it was otherwise unlawful.", "citation": "TCH RTP Operating Rules, edition effective 2026-06-01, Rule VII.C.5.a to VII.C.5.d, with Rule VII.B.3", "rests_on": "rule" }, { "label": "A quality dispute is not a ground", "value": "A complaint about the quality or delivery of goods or services does not by itself support a claim of breach of the RFP warranty.", "citation": "TCH RTP Operating Rules, edition effective 2026-06-01, Rule VII.C.5.e", "rests_on": "rule" }, { "label": "Warranty claim timetable", "value": "The message sending participant must investigate and respond within 20 business days of the calendar day the claim was initiated. On a positive response it must return the amount of the responding payment by the end of the business day immediately following the response, and the message receiving participant must credit its customer by the end of the business day after it receives the funds.", "citation": "TCH RTP Operating Rules, edition effective 2026-06-01, Rule VII.C.6.b and Rule VII.C.6.d", "rests_on": "rule" }, { "label": "What happens on a refusal", "value": "After a negative response, or no response inside 20 business days, the message receiving participant may take the claim to a TCH arbitration by filing within 45 calendar days. TCH decides within 30 calendar days of receiving the required information, the decision is final and binding with no appeal to the courts, and a participant found to have breached must return the funds within 5 business days.", "citation": "TCH RTP Operating Rules, edition effective 2026-06-01, Rule VII.C.7.a.ii, VII.C.7.c.iii, VII.C.7.c.iv and VII.C.7.d.i", "rests_on": "rule" }, { "label": "Reasons a bank may not give for refusing", "value": "A message sending participant may not refuse a warranty claim solely because it cannot recover the funds from its own customer, because the other bank has no legal duty to recredit its customer, or because the other bank has not recredited its customer yet.", "citation": "TCH RTP Operating Rules, edition effective 2026-06-01, Rule VII.C.6.c.ii", "rests_on": "rule" }, { "label": "Who has to prove what", "value": "Where the Request for Payment collected payment for the receiver's purchase of goods or services in the ordinary course of business, as determined by TCH, the claiming bank carries the burden. For all other claims the message sending participant carries the burden of rebutting the claim.", "citation": "TCH RTP Operating Rules, edition effective 2026-06-01, Rule VII.C.7.b.iv", "rests_on": "rule" } ], "exceptions": [ "A payment that was not made in response to a Request for Payment has no warranty claim path at all. The RFP warranty attaches to the request message, so a push payment a victim was talked into making by other means falls back to a discretionary Request for Return of Funds.", "Where any part of the payment is subject to the EFTA, the consumer's rights come from the EFTA and Regulation E, not from these rules, and the rules yield to them (Rule I.F.2, Rule II.J.1.b).", "The refund obligation after an accept without posting does not apply where the receiving participant is legally prohibited from refunding; it must instead tell the sending participant the amount is blocked (Rule V.E.2.e.iii).", "A claim may be brought as a mass claim covering multiple requests from the same message sender on substantially similar facts, and that may shift the burden even for goods and services purchases (Rule VII.C.7.a.iii and VII.C.7.b.v).", "The unsuccessful party in an arbitration pays a cost recovery fee set by TCH, and a participant found to have violated the rules during the proceeding may be fined regardless of who wins (Rule VII.C.7.c.vi and VII.C.7.c.vii)." ], "applies_to": "settled RTP credit transfers, and in particular payments made in response to a Request for Payment", "caveat": "The RFP warranty claim is the closest thing RTP has to a scam reimbursement scheme, and it is narrower than it looks: it needs a Request for Payment to have been used, a customer statement, and a claim inside 95 calendar days of the payment. It is a claim between banks, not a consumer right, and nothing in Rule VII.C requires a bank to recredit its customer before the money comes back.", "related": [ "rtp:finality", "rtp:return", "rtp:recall", "rtp:consumer-law", "rtp:liability", "rtp:decision-points" ], "basis": { "sources": "TCH RTP Operating Rules, edition effective 2026-06-01 (marked PUBLIC), read in full for this record: Rule I.A.80 and I.A.82 (RFP warranty, responding payment), I.F.2 and II.J.1.b (EFTA precedence), V.E.2.e (refund after accept without posting), VII.B.2.d and VII.B.3 (the warranty and legitimate purposes), VII.C.1 to VII.C.7 (prerequisites, customer statement, claim initiation, grounds, obligations, timetable, arbitration and return of funds). No secondary source was used.", "confidence": "high" }, "currency": { "effective_since": "Long-standing", "effective_note": "The Request for Payment warranty claims process at Rule VII.C is present in the edition effective 2026-06-01. It is a newer addition than the Request for Return of Funds mechanism [Inference: the 2021 guidelines describe requests for return but no warranty claims process]. The date it first took effect is [Unverified]; earlier editions were not read.", "source_edition": "TCH RTP Operating Rules, edition effective 2026-06-01 (marked PUBLIC), Rule VII.B and Rule VII.C", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.theclearinghouse.org/-/media/New/TCH/Documents/Payment-Systems/RTP/RTP-Operating-Rules-Effective-June-1-2026pdf.pdf", "source_class": "authoritative_primary", "source_title": "RTP Operating Rules, edition effective 2026-06-01, The Clearing House", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms no default obligation to return funds (VII.D.1); the compulsory refund after a declined accept without posting (V.E.2.e); the RFP Warranty and the receiving side's right to claim (VII.B.2.d, I.A.80); the 95 calendar day claim window and the four prerequisites, including the customer statement (VII.C.1, VII.C.2); the four grounds supporting a claim and that a goods/services quality complaint alone is not one (VII.C.5); the 20 business day investigation and response deadline, with the three barred negative-response reasons (VII.C.6.b, VII.C.6.c.ii); the return timetable on a positive response (VII.C.6.d); the 45 calendar day arbitration filing window, the burden of proof allocation, the 30 calendar day TCH decision, finality with no court appeal, the cost recovery fee on the unsuccessful party, and the independent fine exposure (VII.C.7); and the 5 business day return of funds after a breach determination (VII.C.7.d)." } ] }, "rail_name": "RTP", "governing_authority": "The Clearing House", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "rtp:return", "id": "return", "rail": "rtp", "kind": "rail-fact", "facet": "return", "name": "Is there a return, and what can stop a payment before it settles?", "statement": "RTP has no return. There is no message by which a receiving participant sends a settled payment back the way an ACH RDFI returns an entry, because RTP is credit push only and a settled payment is final. What RTP has instead is a reject, which happens before settlement and means the payment never settles at all, and, after settlement, a request that the receiving bank may decline. Anyone carrying ACH R-code intuition onto this rail will get the timing and the actor wrong.", "details": [ { "label": "Credit push only", "value": "RTP is a credit push system: the payer's bank originates the financial message on the payer's authorization. The network does not permit debit pull transactions, so there is no originated debit for a receiving bank to return.", "citation": "TCH RTP Request for Return of Funds Guidelines and Suggested Practices, dated 2021-01-21 (marked Public; guidance, not rule), operating guideline 1.I", "rests_on": "guidance" }, { "label": "The pre-settlement stop is a reject", "value": "A reject message means the receiving participant has rejected the payment message. The system then notifies the sending participant. Rejected RTP payments are not settled.", "citation": "TCH RTP Operating Rules, edition effective 2026-06-01, Rule V.E.3.a and Rule V.E.3.c", "rests_on": "rule" }, { "label": "A receiving bank may only reject for listed reasons", "value": "A receiving participant agrees to accept all conforming payment messages unless the receiver account is closed, invalid, under fraud or illegal activity monitoring, or is not a transaction account under Regulation D; or the account owner has said it does not wish to accept all or certain RTP payments; or the message cannot be accepted for legal or regulatory compliance reasons. Being too large is not on the list.", "citation": "TCH RTP Operating Rules, edition effective 2026-06-01, Rule V.C.1, V.C.2 and V.C.3", "rests_on": "rule" }, { "label": "A reject carries a reason code the rules do not list", "value": "The receiving participant must include a valid and most appropriate reason code with the reject message, as specified in the RTP Technical Specifications. The Operating Rules do not publish the code list and the specifications are gated behind the RTP Documentation Agreement, so the permitted reject codes are not available from a public source.", "citation": "TCH RTP Operating Rules, edition effective 2026-06-01, Rule V.E.3.b", "rests_on": "rule" }, { "label": "The system can stop a payment too", "value": "TCH may reject a payment message that does not comply with the rules or the specifications, may decline to process messages it believes erroneous or duplicate, and cancels a payment message if the receiving participant does not respond in time. The system also rejects a payment message when the sending side's prefunded position does not cover it.", "citation": "TCH RTP Operating Rules, edition effective 2026-06-01, Rule IV.A.2, Rule IV.A.3, Rule IV.A.4 and Rule VI.E.3", "rests_on": "rule" }, { "label": "A cancelled payment can be sent again, as a new payment", "value": "A payment message cancelled on time-out may only be resubmitted if it is formatted as and meets the requirements for a new payment message.", "citation": "TCH RTP Operating Rules, edition effective 2026-06-01, Rule IV.A.4.a", "rests_on": "rule" }, { "label": "After settlement there is no return, only a request", "value": "Once the payment has settled the only mechanism is a Request for Return of Funds, which is a non-payment message that moves no money. The receiving participant must respond and has no obligation to return the funds.", "citation": "TCH RTP Operating Rules, edition effective 2026-06-01, Rule VII.D and Rule VII.D.1", "rests_on": "rule" }, { "label": "One case where a refund is compulsory", "value": "A receiving participant that accepted without posting and then decides not to make funds available must promptly refund the sending participant, unless legally prohibited. That is the only circumstance in the Operating Rules where money must come back after settlement, and it still moves as a new payment.", "citation": "TCH RTP Operating Rules, edition effective 2026-06-01, Rule V.E.2.e", "rests_on": "rule" } ], "exceptions": [ "The rules give the receiving participant no obligation to give the receiver status information when it rejected under Rule V.C.1, V.C.2 or V.C.3 (Rule II.F.1.a).", "Fraud or unauthorized payment is not a permitted reject reason under Rule V.C. A receiving participant that suspects fraud on an incoming payment may reject only if the account is being monitored for suspected fraudulent or other illegal activity, or on legal or compliance grounds.", "A payment blocked for legal reasons after an accept without posting is neither refunded nor posted; the receiving participant must tell the sending participant the amount has been blocked (Rule V.E.2.e.iii).", "Returning funds after a payment has been accepted and acknowledged, because of the receiving bank's own system trouble, was held to be a rules violation in a TCH rules interpretation dated 2024-07-25 [Unverified: the interpretation was not re-read for this record]." ], "applies_to": "RTP credit transfers, both before settlement (reject, cancellation) and after settlement (no return path)", "caveat": "The word return on this rail means a Request for Return of Funds, which is a request. It does not mean an ACH-style return, and a reject is not a return either: a reject happens before settlement, is sent by a different actor for a different reason set, and leaves the payment unsettled.", "related": [ "rtp:finality", "rtp:settlement", "rtp:recall", "rtp:refund", "rtp:messages", "rtp:decision-points" ], "basis": { "sources": "TCH RTP Operating Rules, edition effective 2026-06-01 (marked PUBLIC), read in full for this record: Rule II.F.1.a (no status duty after certain rejects), IV.A.2 to IV.A.4 (TCH review, exception transactions, time-out), V.C (general acceptance requirement and the permitted reject reasons), V.E.2.e (refund after accept without posting), V.E.3 (reject), VI.E.3 (system reject for insufficient position), VII.D and VII.D.1 (Request for Return of Funds). TCH RTP Request for Return of Funds Guidelines and Suggested Practices, dated 2021-01-21 (marked Public; guidance, not rule), operating guideline 1. TCH rules interpretation dated 2024-07-25 on return of funds following an accept response, cited from Orca's RTP rail brief (docs/rails/rtp.md) and not re-read for this record.", "confidence": "high" }, "currency": { "effective_since": "Long-standing", "effective_note": "The provisions cited are present in the edition effective 2026-06-01, and the 2021 guidelines describe the same credit-push, no-return design, so the substance predates 2021. Earlier editions were not read.", "source_edition": "TCH RTP Operating Rules, edition effective 2026-06-01 (marked PUBLIC); TCH RTP Request for Return of Funds Guidelines and Suggested Practices, dated 2021-01-21 (marked Public)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.theclearinghouse.org/-/media/New/TCH/Documents/Payment-Systems/RTP/RTP-Operating-Rules-Effective-June-1-2026pdf.pdf", "source_class": "authoritative_primary", "source_title": "RTP Operating Rules, edition effective 2026-06-01, The Clearing House", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms the reject message and pre-settlement stop, and that rejected payments are not settled (V.E.3.a, V.E.3.c); the closed list of permitted reject reasons, excluding payment size (V.C.1-3); the reject reason code requirement sitting in the gated Technical Specifications (V.E.3.b); TCH's own review, rejection of non-conforming or believed-erroneous/duplicate messages, and time-out cancellation (IV.A.2-4); resubmission of a cancelled payment only as a new payment message (IV.A.4.a); the Request for Return of Funds as the only post-settlement mechanism, with no obligation to return funds (VII.D, VII.D.1); the compulsory refund after a declined accept without posting (V.E.2.e); and no status-information duty after certain rejects (II.F.1.a)." }, { "source_url": "https://www.theclearinghouse.org/-/media/New/TCH/Documents/Payment-Systems/RTP_Request_for_Returns_v02-19-2021.pdf", "source_class": "public_primary", "source_title": "RTP Request for Return of Funds Guidelines and Suggested Practices, dated 2021-01-21, The Clearing House", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Confirms the guidance-sourced detail that RTP is a credit push system originated on the payer's authorization and does not permit debit pull transactions (operating guideline 1.I). Does not address the rule-based reject and cancellation mechanics." } ] }, "rail_name": "RTP", "governing_authority": "The Clearing House", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "rtp:settlement", "id": "settlement", "rail": "rtp", "kind": "rail-fact", "facet": "settlement", "name": "How does settlement work, when does it happen, and in what money?", "statement": "RTP is prefunded and settles payment by payment, in US dollars, at the moment the receiving participant accepts. Every sending participant, or the funding provider standing behind it, must already hold enough in a joint prefunded balance account before the system will release its payment. Settlement is recorded as simultaneous position entries, not as a later batch, so there is no settlement window and no interbank credit risk between the moment of acceptance and the moment of settlement.", "details": [ { "label": "Money", "value": "A payment message instructs the receiving participant to pay a fixed amount denominated in US dollars. The rules provide for no other currency.", "citation": "TCH RTP Operating Rules, edition effective 2026-06-01, Rule I.A.57 and Rule I.A.58", "rests_on": "rule" }, { "label": "Prefunding is a precondition to release", "value": "The RTP System will not release a sending participant's payment message to the receiving participant unless the sending participant's current prefunded position, or its funding provider's, is equal to or greater than the amount of the payment. If the condition is not met the system rejects the payment message.", "citation": "TCH RTP Operating Rules, edition effective 2026-06-01, Rule VI.E.1 and Rule VI.E.3", "rests_on": "rule" }, { "label": "Reservation on release", "value": "On release, the system records entries that reserve the amount by decreasing the sending participant's net position, so the position cannot be drawn below the reserved amount before the payment is cancelled, rejected or settled. Cancellation or rejection un-reserves the amount.", "citation": "TCH RTP Operating Rules, edition effective 2026-06-01, Rule VI.E.2", "rests_on": "rule" }, { "label": "The settlement event", "value": "On the system's receipt of the receiving participant's accept or accept without posting message, it credits the reserved amount by increasing the receiving participant's net position. Receipt of that message and the recording of the entries are deemed simultaneous.", "citation": "TCH RTP Operating Rules, edition effective 2026-06-01, Rule VI.E.4", "rests_on": "rule" }, { "label": "When settlement is complete", "value": "Settlement is complete when the system has recorded both the decrease in the sending participant's net position and the increase in the receiving participant's net position, which recordings are deemed simultaneous. That completion is final settlement and final discharge of the sending participant's obligation to pay.", "citation": "TCH RTP Operating Rules, edition effective 2026-06-01, Rule VI.E.6", "rests_on": "rule" }, { "label": "Where the money sits", "value": "Prefunded balances are held in a single special deposit account, the Prefunded Balance Account, established by the Prefunded Balance Account Bank for the joint benefit of all funding participants and funding agents. Individual participants hold positions recorded by the RTP System against that one account, not separate accounts.", "citation": "TCH RTP Operating Rules, edition effective 2026-06-01, Rule I.A.65 and Rule I.A.66", "rests_on": "rule" }, { "label": "The account is at a Federal Reserve Bank", "value": "[Inference] The rules do not name the Prefunded Balance Account Bank, but they require funding participants to indemnify that bank and each other Federal Reserve Bank, and they let it recover claims by directing the Federal Reserve Bank that holds a participant's master account to debit it. The Federal Reserve Board has separately issued an order on the payment of interest on RTP joint account balances, which treats the account as a joint account at a Reserve Bank.", "citation": "TCH RTP Operating Rules, edition effective 2026-06-01, Rule VI.H.1 and Rule VI.H.4; Federal Reserve Board, Order Concerning the Payment of Interest on RTP joint account balances (federalreserve.gov, public; text not extracted for this record)", "rests_on": "rule" }, { "label": "How participants move funding in and out", "value": "Supplemental funding reaches the prefunded balance account through Fedwire, or through the FedNow Liquidity Management Transfer service where the participant has enabled it. Excess liquidity comes back out as a Fedwire payment on request.", "citation": "TCH RTP Operating Rules, edition effective 2026-06-01, Rule VI.D.2.b, Rule VI.D.2.c and Rule VI.G.1", "rests_on": "rule" }, { "label": "Reconciliation windows", "value": "TCH reports positions after the close of each reconciliation window and decides the frequency and timing of those windows in its sole discretion. A participant's net position resets to zero at the opening of a window, which constrains how much a non-funding group member can send in one window.", "citation": "TCH RTP Operating Rules, edition effective 2026-06-01, Rule VI.F.1 and Rule VI.D.5.b, citing Rule VI.C.4.b.iii", "rests_on": "rule" }, { "label": "Banks that do not fund for themselves", "value": "A non-funding group member settles against its funding provider's prefunded position and has no right to request disbursement from the prefunded balance account. The funding provider must pay a member with a positive net position, and be paid by a member with a negative one, at least once each Fedwire operating day.", "citation": "TCH RTP Operating Rules, edition effective 2026-06-01, Rule VI.B.3.b, Rule VI.G.3 and Rule VI.G.3.a", "rests_on": "rule" } ], "exceptions": [ "A payment that never reaches acceptance is never settled: a time-out cancellation under Rule IV.A.4 and a reject under Rule V.E.3.c both leave the position entries un-reserved (Rule VI.E.5).", "Accept without posting settles exactly as accept does, so the interbank settlement is final while the receiver has no funds (Rule V.E.2.b).", "Fedwire hours, not RTP hours, govern funding movements. When Fedwire is closed a participant must have prefunded in advance unless it uses the FedNow Liquidity Management Transfer service, and TCH may raise its prefunded requirement if it does not (Rule VI.D.3.a).", "Liquidity transfers between funding providers and participants made over RTP itself when Fedwire is closed must be reported to TCH within ten banking days (Rule VI.D.3.c)." ], "applies_to": "RTP credit transfers and the funding and settlement arrangements of RTP participants and funding agents in the United States", "caveat": "\"Prefunded\" here does not mean a balance the sending bank can see at the Federal Reserve. It is a position the RTP System records against one joint account, and the individual participant's right is a right to request disbursement of excess liquidity, payable only out of that account's balance (Rule VI.G.4).", "related": [ "rtp:finality", "rtp:hours", "rtp:limits", "rtp:participants" ], "basis": { "sources": "TCH RTP Operating Rules, edition effective 2026-06-01 (marked PUBLIC), read in full for this record: Rule I.A.26, I.A.28, I.A.57, I.A.58, I.A.65, I.A.66, I.A.67 (definitions), Rule VI.B (funding agents, managers, providers and non-funding participants), Rule VI.D (monitoring positions, supplemental funding, net send limits), Rule VI.E (settlement procedures), Rule VI.F (position reports), Rule VI.G (disbursements), Rule VI.H (indemnification of the prefunded balance account bank). Federal Reserve Board, Order Concerning the Payment of Interest on RTP joint account balances, and the Board's guidelines for evaluating joint account requests at Reserve Banks (federalreserve.gov, public_primary), for the joint account arrangement only; the order's own text was not extracted for this record.", "confidence": "high" }, "currency": { "effective_since": "Long-standing", "effective_note": "The settlement mechanics cited are present in the edition effective 2026-06-01. Earlier editions were not read, so the date each provision first took effect is [Unverified]. The FedNow Liquidity Management Transfer alternative is a later addition than the original Fedwire-only funding model [Inference].", "source_edition": "TCH RTP Operating Rules, edition effective 2026-06-01 (marked PUBLIC), Rule VI", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.theclearinghouse.org/-/media/New/TCH/Documents/Payment-Systems/RTP/RTP-Operating-Rules-Effective-June-1-2026pdf.pdf", "source_class": "authoritative_primary", "source_title": "RTP Operating Rules, edition effective 2026-06-01, The Clearing House", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms USD-only payment messages (I.A.57/58); prefunding as a precondition to release and system rejection when insufficient (VI.E.1, VI.E.3); reservation and un-reservation of the net position on release, cancellation or rejection (VI.E.2); the settlement event on receipt of accept or accept without posting and simultaneity (VI.E.4); completion of settlement and final discharge (VI.E.6); the single joint Prefunded Balance Account (I.A.65, I.A.66); indemnification of the Prefunded Balance Account Bank and each other Federal Reserve Bank, and recovery by directing a debit to a participant's Federal Reserve master account (VI.H.1, VI.H.4); Fedwire and FedNow Liquidity Management Transfer funding paths (VI.D.2); reconciliation window discretion (VI.F.1); non-funding group member settlement against a funding provider's position (VI.B.3.b, VI.G.3). Does not itself name the Prefunded Balance Account Bank as a Federal Reserve Bank; that remains an inference from the indemnification language plus an unread Federal Reserve order." } ] }, "rail_name": "RTP", "governing_authority": "The Clearing House", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sa-sarie:consumer-law", "id": "consumer-law", "rail": "sa-sarie", "kind": "rail-fact", "facet": "consumer-law", "name": "What does the law give a consumer on this rail, beyond the rulebook?", "statement": "A sarie user's protections come from SAMA's rules for the institutions it supervises, not from sarie's own documents. SAMA's consumer protection rules require banks to tell customers by SMS of every movement on their accounts, give 30 days' notice of changed terms, set and disclose transfer limits, handle complaints through published, free channels, and pay back technical-error gains and channel-breach losses. SAMA's 2025 fee guide caps what an individual can be charged for a transfer and requires prior consent to fees. Licensed payment and e-money institutions have the Regulations' fixed complaint clock on top: acknowledgement in 48 hours, a full answer in ten calendar days, thirty at the outside. A customer who is not satisfied can go to SAMA, and a dispute between parties to a payment system must first go through an amicable settlement window of up to 30 days before a court or SAMA's Banking Disputes Committee.", "details": [ { "label": "Notice of every debit and credit", "value": "Banks and payment companies must tell customers straight away, by SMS, of money leaving or entering their accounts.", "citation": "SAMA Financial Consumer Protection Principles and Rules, circular 44006639 of 2022-08-23 (1444-01-26 H), section 4, rule 8 (English page)", "rests_on": "law" }, { "label": "Terms, limits and fees in the open", "value": "A change to a customer's terms needs 30 days' notice by SMS and other documented channels, with a way to object. Banks must set limits on transfers, tell customers what they are, and revisit them yearly. Under the 2025 fee guide an institution must disclose every fee, get the customer's prior consent through a documented channel, text the customer when a fee is taken, may not charge for a low or empty balance, and must stay within the individual-customer caps (the sarie-related caps are in the limits fact).", "citation": "Financial Consumer Protection Principles and Rules (circular 44006639), section 3 rule 4 and section 4 rule 9; SAMA Guide to Financial Institutions Services Fees, circular 472038000 of 2025-12-22 (1447-07-02 H), arts. 3, 4, 8 and 9 (Arabic original)", "rests_on": "law" }, { "label": "Complaints at a bank", "value": "A bank must take complaints through several channels, at least a toll-free number, branches or website, app and email, publish how it handles them, give the customer a reference and the handling period by SMS, send a documented outcome, and point the customer to a higher level or to the competent authority if they are not satisfied. The rules read set no fixed number of days for a bank's answer.", "citation": "Financial Consumer Protection Principles and Rules (circular 44006639), section 2 principle 7, section 3 rules 17, 18, 19 and 22", "rests_on": "law" }, { "label": "Complaints at a payment or e-money institution", "value": "The Regulations give licensed payment and e-money institutions a clock: acknowledge within 48 hours, answer fully within ten calendar days, and if that is impossible for reasons outside their control, send a holding reply with reasons and a date, never beyond thirty calendar days from receipt. SAMA also takes complaints from users directly and may follow them up with the provider.", "citation": "Implementing Regulations of the Law of Payments, circular 44093096 of 2023-06-13 (1444-11-24 H), art. 129(4) and 129(7) (English translation)", "rests_on": "law" }, { "label": "Disputes", "value": "A dispute between parties to a payment system and payment service providers must go through amicable settlement, lasting no more than 30 days unless both sides agree in writing to extend, before a competent judicial authority hears it. The Regulations assign such disputes, and grievances against SAMA's decisions, to the Banking Disputes Committee.", "citation": "Law of Payments and Payment Services, Royal Decree M/26 of 1443-03-22 H (2021-10-28), arts. 13 and 14; Implementing Regulations art. 130 (English translations)", "rests_on": "law" } ], "exceptions": [ "The complaint clock in Implementing Regulations art. 129 binds licensed payment and e-money institutions; banks are held to the Regulations only as far as SAMA specifies (art. 48(2)), and SAMA's separate complaint rules and its complaint management system circular (1185 of 2025-07-01) were seen by title and not read for this record [Unverified: whether a fixed answer deadline applies to banks].", "The fee caps protect individual customers; business customers' fees are left to each institution within the fee guide's reasonableness criteria (art. 10).", "A legal person dealing with a payment institution in a business context may contract out of some protections as SAMA determines (Implementing Regulations art. 51)." ], "applies_to": "individual and business customers of Saudi banks and licensed payment and e-money institutions using sarie", "caveat": "These are SAMA's conduct rules for supervised institutions, read in English translation except the fee guide. They apply to a sarie payment because of who the customer's institution is, not because of anything in sarie's rules.", "related": [ "sa-sarie:refund", "sa-sarie:liability", "sa-sarie:limits" ], "basis": { "sources": "SAMA rulebook portal, read 2026-09-18: Financial Consumer Protection Principles and Rules, circular 44006639 (2022-08-23, 1444-01-26 H), English page; Law of Payments and Payment Services (M/26) arts. 13 and 14 and Implementing Regulations (circular 44093096) arts. 48, 51, 129 and 130, English translations (public_primary: the portal's terms deny it legal effect and say official channels govern); Guide to Financial Institutions Services Fees, circular 472038000 (2025-12-22), Arabic original (authoritative_primary). Medium because the governing Arabic texts of the consumer rules and the Regulations were not read. Nothing is quoted.", "confidence": "medium" }, "currency": { "effective_since": "2026-02-20", "effective_note": "Dated from the fee guide, which takes effect 60 days after publication on SAMA's website [Inference: 2026-02-20 if published on its circular date of 2025-12-22, 1447-07-02 H]. The consumer rules date from 2022-08-23 (1444-01-26 H) and the Regulations from 2023-06-13 (1444-11-24 H).", "source_edition": "Financial Consumer Protection Principles and Rules, circular 44006639 (2022-08-23); SAMA fee guide, circular 472038000 (2025-12-22); Law of Payments M/26 (2021-10-28); Implementing Regulations circular 44093096 (2023-06-13)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://rulebook.sama.gov.sa/en/entiresection/1989", "source_class": "public_primary", "source_title": "SAMA Financial Consumer Protection Principles and Rules, circular 44006639, 2022-08-23, English translation, full text", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms SMS notice of every debit and credit under section 4 rule 8, the 30 day notice of changed terms and the annual review of disclosed transfer limits under section 3 rule 4 and section 4 rule 9, and the bank complaint channels, reference number and escalation duties under section 2 principle 7 and section 3 rules 17, 18, 19 and 22. Confirms the rules set no fixed number of days for a bank to answer a complaint, unlike the fixed clock in the Implementing Regulations for licensed payment and e-money institutions. Does not address the Implementing Regulations complaint clock or the dispute settlement articles." } ] }, "rail_name": "Saudi Arabia sarie (instant payments)", "governing_authority": "Saudi Central Bank (SAMA)", "snapshot": "2026-09-18", "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sa-sarie:decision-points", "id": "decision-points", "rail": "sa-sarie", "kind": "rail-fact", "facet": "decision-points", "name": "Where does a person or institution have to make a judgment call?", "statement": "On sarie the judgment calls that are visible in public sit with three parties. The customer decides how far to open quick transfers (up to the cap), whether to register an alias, and whether the name the account check shows is the person they mean to pay. The customer's own institution decides limits, whether to refuse or hold a payment it suspects, whether a disputed payment was unauthorised, and how hard to chase money sent to the wrong person, with the recipient's institution deciding how far to help. SAMA decides whether sarie counts as systemically important, can order access, and can direct a provider to act, up to refunding a payer. Where the sarie member documents leave judgment to the operator or to banks is not public.", "details": [ { "label": "The customer: how open to be", "value": "Customers choose their own quick-transfer limit anywhere up to the SAR 2,500 cap (one bank starts it at zero), and choose whether to consent to registering an alias with Saudi Payments, which they can later change or remove.", "citation": "Bank Albilad, Sarie instant payments page (bankalbilad.com.sa, read 2026-09-18); Riyad Bank, Instant Payment Service (SARIE) page (riyadbank.com, read 2026-09-18), limits section; Banque Saudi Fransi FransiGlobal Sarie leaflet dated 2024-04-15 (bsf.sa)", "rests_on": "practice" }, { "label": "The customer: is this the right payee?", "value": "Banks must run account verification before a new beneficiary is added and activated, which puts the payee's name and bank in front of the customer. Deciding whether that name matches the intended payee is the customer's call, and a payer who gives wrong details bears the mistake under the Regulations for licensed payment institutions.", "citation": "SAMA circular 44075612, 2023-04-16 (1444-09-25 H), item 1 (English translation); The Saudi Investment Bank, SARIE service page (saib.com.sa, read 2026-09-18); Implementing Regulations of the Law of Payments, circular 44093096 of 2023-06-13 (1444-11-24 H), art. 86(1)", "rests_on": "rule" }, { "label": "The payer's institution: limits and stops", "value": "Banks set, disclose and review each customer's transfer limits. A licensed payment or e-money institution may refuse an order or suspend an account only on stated grounds, one of which is its own suspicion of fraud, money laundering or terrorist financing, and must then give reasons and say how to fix the problem.", "citation": "SAMA Financial Consumer Protection Principles and Rules, circular 44006639 of 2022-08-23 (1444-01-26 H), section 4 rule 9; Implementing Regulations arts. 70 and 73(1) to 73(2)", "rests_on": "law" }, { "label": "The payer's institution: was it unauthorised?", "value": "For a licensed payment or e-money institution, deciding whether a disputed payment was authorised is in the first instance the provider's, but the burden is on it to prove authentication and correct recording. It may delay the refund only on reasonable grounds to suspect the user's own fraud, reported in writing to SAMA; where the complaint reaches SAMA, SAMA weighs the evidence itself.", "citation": "Implementing Regulations arts. 79(2), 79(3), 87(3) and 89(3)", "rests_on": "law" }, { "label": "Both institutions: how hard to chase misdirected money", "value": "The payer's provider must make reasonable efforts to recover a misdirected payment and decides what that means; the recipient's provider must cooperate as far as possible, which leaves it the judgment on what is possible. A recipient's provider holding funds for someone with no account there may, but need not, send them back.", "citation": "Implementing Regulations arts. 77 and 86(2)", "rests_on": "law" }, { "label": "SAMA", "value": "SAMA decides whether a payment system is systemically important, may apply the finality article to a system that is not, may order a systemically important system to admit an applicant, and may direct a provider to take specific action over a misdirected payment, including refunding the payer.", "citation": "Law of Payments and Payment Services, Royal Decree M/26 of 1443-03-22 H (2021-10-28), art. 7(6); Implementing Regulations arts. 101, 115(9), 52(3) and 86(4)", "rests_on": "law" } ], "exceptions": [ "The Regulations' provisions cited (arts. 70 to 89) bind licensed payment and e-money institutions; banks are held to them only as far as SAMA specifies under art. 48(2) [Unverified: which provisions SAMA has applied to banks].", "Where sarie's own rules leave discretion to Saudi Payments or to member banks, for example on holds, rejects or returns, is not public.", "No public text read gives any party a judgment call over a customer tricked into authorising a payment; that case is not addressed [Inference]." ], "applies_to": "sarie instant credit transfers between participating Saudi banks and their customers; SAMA's powers over payment systems and providers", "caveat": "This is Orca's reading of where SAMA's public rules leave a decision open. It is capped at medium, and every line rests on a cited rule or published practice, not on sarie's own documents, which are not public.", "related": [ "sa-sarie:limits", "sa-sarie:liability", "sa-sarie:recall", "sa-sarie:participants" ], "basis": { "sources": "SAMA rulebook portal, English pages read 2026-09-18 (public_primary; the portal's terms deny it legal effect): account verification circular 44075612 (2023-04-16); Financial Consumer Protection Principles and Rules, circular 44006639 (2022-08-23); Law of Payments M/26 art. 7; Implementing Regulations circular 44093096 arts. 48, 52, 70, 73, 77, 79, 86, 87, 89, 101 and 115. Participant bank pages read 2026-09-18: Bank Albilad (bankalbilad.com.sa), Riyad Bank (riyadbank.com), The Saudi Investment Bank (saib.com.sa), Banque Saudi Fransi leaflet dated 2024-04-15 (bsf.sa). sarie's own allocation of discretion is in member documents that are not public, hence primary_not_public; the facet caps at medium. Nothing is quoted.", "confidence": "medium" }, "currency": { "effective_since": "2023-06-13", "effective_note": "Dated from the Implementing Regulations (2023-06-13, 1444-11-24 H). Account verification applies from 2023-05-11 (circular 44075612); the consumer rules from 2022-08-23 (1444-01-26 H). Bank pages as read 2026-09-18.", "source_edition": "SAMA circular 44075612 (2023-04-16); Financial Consumer Protection Principles and Rules, circular 44006639 (2022-08-23); Law of Payments M/26 (2021-10-28); Implementing Regulations circular 44093096 (2023-06-13); bank pages as read 2026-09-18, BSF leaflet 2024-04-15", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "primary_not_public": true, "corroboration": [ { "source_url": "https://rulebook.sama.gov.sa/en/article-73-2", "source_class": "public_primary", "source_title": "Implementing Regulations of the Law of Payments, Article 73, Part 6 Relevant Payment Services, circular 44093096, 2023-06-13, English translation", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms a payment service provider may refuse an order or suspend an account only on stated grounds, including its own suspicion of fraud, money laundering or terrorism financing, and must then give the user objectively justifiable reasons and how to fix the problem. Supports the record's claim that the payer's institution has a judgment call over limits and stops, subject to art. 48(2) on whether banks are held to it." }, { "source_url": "https://www.riyadbank.com/personal-banking/digital-banking-key-features/sarie", "source_class": "secondary", "source_title": "Riyad Bank, Instant Payment Service (SARIE) page, riyadbank.com, read 2026-09-18", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the customer configures their own quick transfer limit up to the SAR 2,500 maximum and that the limit defaults to zero until raised, and that adding a beneficiary is optional below SAR 2,500 but mandatory above it. Supports the record's claim that the customer decides how open to be with quick transfers." } ] }, "rail_name": "Saudi Arabia sarie (instant payments)", "governing_authority": "Saudi Central Bank (SAMA)", "snapshot": "2026-09-18", "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "not_public", "label": "the operator's own text", "needs": "what the operator's own text says, which Orca has not read", "detail": "Saudi Central Bank (SAMA)'s own text is not the source for this rail fact: it is not public, or not under terms Orca can use. It rests on 2 named public sources, so a term set by agreement rather than by a published rule is not Orca's to state.", "from": "currency.primary_not_public" } ] }, { "uid": "sa-sarie:finality", "id": "finality", "rail": "sa-sarie", "kind": "rail-fact", "facet": "finality", "name": "When does a sarie payment become final, and can it be reversed?", "statement": "Saudi law makes a final payment order irreversible, but it leaves the moment of finality to each systemically important system's own operating rules, and sarie's rules are not public. So the answer comes in layers. In law, a payment order that has reached settlement finality is locked, so its sender can no longer undo or alter it, and the Regulations keep that protection when a member fails [Inference: read from the insolvency cut-off rule], subject to a cut-off on the day an insolvency order is published. Whether that statutory shield covers sarie depends on SAMA having designated it systemically important, or applying the finality article to it anyway, and neither designation was found in public. In practice, banks present a sarie transfer as instant and give the sender no cancel option in any page read. Money that went to the wrong person, or left without the customer's authority, comes back, if at all, through separate recovery and refund duties, not by undoing the payment.", "details": [ { "label": "The statutory rule", "value": "Article 6 of the Law gives full legal force to several kinds of arrangement and bars anyone from undoing or altering them: guarantee and default management arrangements, clearing arrangements, settlement transactions, and final payment orders. Article 1 leaves the moment itself to each systemically important system's rulebook: settlement finality is the point, as those rules fix it, from which the member that issued an order loses the power to undo or alter it.", "citation": "Law of Payments and Payment Services, Royal Decree M/26 of 1443-03-22 H (2021-10-28), arts. 1 (definitions of Settlement Finality and Final Payment Order) and 6 (English translation)", "rests_on": "law" }, { "label": "The system's rules must fix the moment", "value": "Law art. 10(1) puts the timing in the system's own hands: a systemically important system's operating rules must say at what point a member's order becomes final, and separately at what point it reaches settlement finality, covering orders that cross more than one system. Article 115 adds that those rules must complete settlement by the intended settlement time and date and leave no doubt about when a final order counts as settled. Once final settlement has happened it is permanent: nobody can unwind it, pay it back or annul it, though this must sit alongside the insolvency procedures the same article preserves.", "citation": "Law of Payments art. 10(1); Implementing Regulations, circular 44093096 of 2023-06-13 (1444-11-24 H), art. 115(1) to 115(3) and 115(6) (English translation)", "rests_on": "law" }, { "label": "Where the shield stops", "value": "The cut-off is the end of the Saudi calendar day on which an insolvency-type order against the system or one of its members becomes enforceable after due publication and notice, or, for a voluntary winding up, the end of the day it is completed. Final payment orders started after that point fall outside article 6 of the Law. The orders that count are those for reorganisation, bankruptcy, winding up or a halt to the business.", "citation": "Implementing Regulations art. 115(7)", "rests_on": "law" }, { "label": "Does it reach sarie?", "value": "Only if SAMA has classified sarie as systemically important, or has chosen to apply the finality article to it as a non-systemic system, which the Regulations allow. SAMA's published 2015 list of systemically important systems predates sarie and names three systems: SADAD, the Saudi Payment Network and a real time gross settlement system (the SARIE RTGS [Inference: the English translation labels it with another system's name]). The 2026 oversight framework explains how classification works but lists no systems. No public designation of sarie was found [Unverified].", "citation": "Implementing Regulations arts. 101 and 115(9); SAMA, Criteria for Systemically Important Payment Systems in the Kingdom of Saudi Arabia, 2015-01-22 (1436-04-02 H) (English translation); SAMA Oversight Framework on Payment Systems and their Operators, circular 472047719 of 2026-03-08 (1447-09-19 H), arts. 6 and 7 (Arabic original)", "rests_on": "law" }, { "label": "The scheme layer is not public", "value": "Whatever sarie's rules say about the moment a payment becomes final, and about whether the paying bank can stop one before that moment, sits in the membership agreement and member documents SAMA required banks to follow at launch. None of them is public.", "citation": "SAMA circular 42047169, Instant Payments Launch (SARIE), 2021-02-17 (1442-07-06 H), item 1", "rests_on": "rule" }, { "label": "The customer layer: no cancel, but recovery and refund duties", "value": "Banks describe sarie as delivering money to the payee instantly and offer no cancellation of a sent instant transfer on any page read. For licensed payment and e-money institutions, the Regulations fix an order from the moment it reaches the payer's provider, after which the user cannot withdraw it; they then make the provider try to recover funds sent to a wrong identifier and refund an unauthorised payment by the end of the next business day. Banks are held to these duties only as far as SAMA specifies [Unverified: which of them SAMA has applied to banks].", "citation": "Bank Albilad, Sarie instant payments page (bankalbilad.com.sa, read 2026-09-18); SAB, SARIE local transfers page (sab.com, read 2026-09-18); Implementing Regulations arts. 1 (definition of Payment Service Provider), 48(2), 74(1), 86 and 89(2)", "rests_on": "law" } ], "exceptions": [ "A transfer above the single payment ceiling is not a sarie payment; it goes by the ordinary local transfer route, and its finality is governed by that system's rules, not sarie's.", "Where a payer's provider suspects fraud by the user and tells SAMA in writing, the Regulations lift its next-business-day refund duty for an unauthorised payment (Implementing Regulations art. 89(3)), so the payer's own position can stay open while the payment itself is final.", "SAMA may exclude a systemically important system from parts of the finality article by a published decision effective the next day (Implementing Regulations art. 115(8)).", "Finality between banks does not settle a customer's claim against their bank under SAMA's consumer rules, which run separately." ], "applies_to": "sarie instant credit transfers in Saudi riyals between participating Saudi banks", "caveat": "Do not tell anyone a sarie payment is irreversible because the law says so; the law's shield attaches to systems SAMA has designated, and no designation of sarie was found. Say instead that no public route exists for the sender to cancel, and point to the recovery, refund and complaint paths.", "related": [ "sa-sarie:settlement", "sa-sarie:hours", "sa-sarie:return", "sa-sarie:recall", "sa-sarie:refund", "sa-sarie:liability", "sa-sarie:consumer-law", "sa-sarie:decision-points" ], "basis": { "sources": "SAMA rulebook portal, read 2026-09-18: Law of Payments and Payment Services (M/26, 1443-03-22 H, 2021-10-28), arts. 1, 6 and 10; Implementing Regulations (circular 44093096, 2023-06-13, 1444-11-24 H), arts. 1, 48, 74, 86, 89, 101 and 115; Criteria for Systemically Important Payment Systems (2015-01-22); launch circular 42047169 (2021-02-17). These are English translations on a portal whose terms deny them legal effect (public_primary). The 2026 Oversight Framework was read in its Arabic original (authoritative_primary). Participant bank pages: Bank Albilad (bankalbilad.com.sa) and SAB (sab.com), each in its own wording. The sarie operating rules, where finality is defined, are not public, hence primary_not_public and medium. Nothing is quoted.", "confidence": "medium" }, "currency": { "effective_since": "2023-06-13", "effective_note": "Dated from the Implementing Regulations (2023-06-13, 1444-11-24 H), which carry the finality article; the Law itself (1443-03-22 H, 2021-10-28) entered into force 180 days after publication in the Official Gazette [Unverified: publication date not found]. sarie launched in February 2021, before both; what applied to it before then is not public.", "source_edition": "Law of Payments M/26 (2021-10-28); Implementing Regulations circular 44093096 (2023-06-13); SIPS criteria (2015-01-22); Oversight Framework circular 472047719 (2026-03-08); SAMA circular 42047169 (2021-02-17); bank pages as read 2026-09-18", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "primary_not_public": true, "corroboration": [ { "source_url": "https://rulebook.sama.gov.sa/en/article-6-24", "source_class": "public_primary", "source_title": "Law of Payments and Payment Services, Article 6, Royal Decree M/26, 2021-10-28, English translation", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms that final payment orders, settlement transactions, clearing arrangements, and default management and guarantee arrangements are deemed binding and enforceable and may not be modified, reversed or revoked. Does not address whether sarie is a systemically important payment system or the insolvency cut off." }, { "source_url": "https://rulebook.sama.gov.sa/en/article-115", "source_class": "public_primary", "source_title": "Implementing Regulations of the Law of Payments, Article 115, Finality and Bankruptcy, circular 44093096, 2023-06-13, English translation", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms that a systemically important system's operating rules must complete final settlement no later than the intended settlement time and date, remove doubt about when a final payment order counts as settled, and make final settlement irrevocable, subject to the cut off at the end of the calendar day an enforceable winding up or bankruptcy order takes effect or the day a voluntary winding up is completed. Confirms SAMA may exclude a system from part of the article by a published decision and may apply some or all of the article to a system that is not systemically important. Does not confirm whether SAMA has designated sarie a systemically important payment system." }, { "source_url": "https://www.bankalbilad.com.sa/en/personal/digital-channels/pages/instant-payments.aspx", "source_class": "secondary", "source_title": "Bank Albilad, Sarie Service for instant payments, bankalbilad.com.sa, read 2026-09-19", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms the bank presents a sarie transfer as received instantly by the beneficiary and describes no way for a customer to cancel a sent instant transfer, supporting the claim that no public route lets a sender cancel one. Does not address the statutory finality framework or whether sarie is designated systemically important." } ] }, "rail_name": "Saudi Arabia sarie (instant payments)", "governing_authority": "Saudi Central Bank (SAMA)", "snapshot": "2026-09-18", "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "not_public", "label": "the operator's own text", "needs": "what the operator's own text says, which Orca has not read", "detail": "Saudi Central Bank (SAMA)'s own text is not the source for this rail fact: it is not public, or not under terms Orca can use. It rests on 3 named public sources, so a term set by agreement rather than by a published rule is not Orca's to state.", "from": "currency.primary_not_public" } ] }, { "uid": "sa-sarie:hours", "id": "hours", "rail": "sa-sarie", "kind": "rail-fact", "facet": "hours", "name": "When does this rail operate, and when do payments move?", "statement": "sarie runs all day, every day, including weekends and public holidays, and participant banks tell customers the money reaches the payee at once. No SAMA circular read sets the operating hours; the 24/7 claim comes from participant banks' own pages and from a signed article by a SAMA assistant governor. The hours that do stop are the older SARIE RTGS's: a transfer above sarie's single payment ceiling is not an instant payment at all, and banks send it through the ordinary local transfer route inside business hours, same day or next business day.", "details": [ { "label": "Always on", "value": "Four participant banks, each in its own words, describe sarie transfers as available around the clock on every day of the year, one naming weekends and holidays expressly, and say the payee receives the funds immediately. A SAMA assistant governor, writing in a trade journal in May 2025, describes the instant payment system as delivering payments in real time 24/7.", "citation": "SAB, SARIE local transfers page (sab.com, read 2026-09-18), Sarie features; Bank Albilad, Sarie instant payments page (bankalbilad.com.sa, read 2026-09-18), benefits; The Saudi Investment Bank, SARIE service page (saib.com.sa, read 2026-09-18); Riyad Bank, Instant Payment Service (SARIE) page (riyadbank.com, read 2026-09-18), features; A. A. Aldeheem, Saudi Central Bank: Driving Transformation in Digital Payments, International Banker, 2025-05-28", "rests_on": "practice" }, { "label": "What SAMA's public texts say about hours", "value": "Nothing directly. The launch circular sets duties on limits, fees, branding and staff briefing but says nothing about operating hours, and no later sarie circular found on the rulebook portal sets them. The working-hours circulars found on the portal are, by their titles, about the Saudi Rapid Financial Transfer System, the RTGS, not the instant payment system.", "citation": "SAMA circular 42047169, Instant Payments Launch (SARIE), 2021-02-17 (1442-07-06 H), items 1 to 6; rulebook.sama.gov.sa search results for sarie and instant payment, and the Payment Systems and Payment Services Providers circulars list (titles of circulars 472020433 of 2025-09-17 and 106887820 of 2025-02-24), read 2026-09-18", "rests_on": "rule" }, { "label": "Larger transfers wait for business hours", "value": "Banks say a transfer above SAR 20,000 is handled as an ordinary local bank transfer rather than an instant one, and one says it is processed in official working hours. One bank lists the RTGS cut-off for such transfers as 15:30 at branches and 14:30 on electronic channels, Sunday to Thursday. SAMA's 2025 fee guide prices transfers above SAR 20,000 separately for same business day and next business day execution, which only makes sense for a route with business days [Inference: that route is the SARIE RTGS].", "citation": "Bank Albilad Sarie page, limits section; Riyad Bank SARIE page, limits section; SAB SARIE page, SARIE features and cut-off schedule; SAMA Guide to Financial Institutions Services Fees, issued by circular 472038000 of 2025-12-22 (1447-07-02 H), art. 9 tariff items 31 and 32 (Arabic original)", "rests_on": "practice" }, { "label": "Business-day rules for non-bank providers", "value": "For licensed payment institutions and e-money institutions, the Implementing Regulations treat an order received outside the provider's stated business hours as received at the start of the next business day, and require a domestic riyal transfer to reach the payee's provider by the end of the following business day unless the user agrees otherwise. These are outer limits for providers, not sarie's operating hours, and banks are bound by them only as far as SAMA specifies.", "citation": "Implementing Regulations of the Law of Payments, circular 44093096 of 2023-06-13 (1444-11-24 H), arts. 1 (definition of Payment Service Provider), 48(2), 72(2) and 76(1)", "rests_on": "law" } ], "exceptions": [ "Transfers above the single payment ceiling (SAR 20,000 as banks publish it) do not run on sarie's clock; they follow the RTGS business day, which one bank lists as Sunday to Thursday, and SAMA issues yearly circulars on RTGS hours for Ramadan and the Eid holidays [Unverified: those circulars were seen by title in the portal's circular list and not opened for this record].", "Planned maintenance windows or outages, if any, are set in the member documents and service levels that are not public.", "A bank may hold or refuse an individual transfer for fraud or compliance reasons, so always-on availability of the system does not mean every payment is credited at once." ], "applies_to": "sarie instant payments between accounts at participating Saudi banks, within the single payment ceiling", "caveat": "Ask which system carried the payment before quoting hours. Within the ceiling, sarie runs continuously; above it, or for services still on the SARIE RTGS, business days and cut-offs apply.", "related": [ "sa-sarie:limits", "sa-sarie:settlement" ], "basis": { "sources": "Participant banks' own public pages, each in its own wording, read 2026-09-18: SAB (sab.com), Bank Albilad (bankalbilad.com.sa), The Saudi Investment Bank (saib.com.sa), Riyad Bank (riyadbank.com). Signed article by SAMA's Assistant Governor for Executive Affairs in International Banker, 2025-05-28 (secondary: a trade journal, not a SAMA publication). SAMA rulebook portal: launch circular 42047169 (English translation, public_primary); Guide to Financial Institutions Services Fees under circular 472038000 (Arabic original read, authoritative_primary); Implementing Regulations circular 44093096 (English translation). The operating hours are in the member documents, which are not public, hence primary_not_public and medium. SAMA's own sarie product page reset a plain connection and was not read. Nothing is quoted.", "confidence": "medium" }, "currency": { "effective_since": "2021-02-17", "effective_note": "Dated from the launch circular (2021-02-17, 1442-07-06 H); the service went live around 2021-02-21. The fee guide lines date from circular 472038000 of 2025-12-22 (1447-07-02 H), in force 60 days after publication. Bank pages as read 2026-09-18.", "source_edition": "Bank pages as read 2026-09-18; International Banker article 2025-05-28; SAMA circular 42047169 (2021-02-17); SAMA fee guide (circular 472038000, 2025-12-22); Implementing Regulations circular 44093096 (2023-06-13)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "primary_not_public": true, "corroboration": [ { "source_url": "https://rulebook.sama.gov.sa/en/instant-payments-launch-sarie", "source_class": "public_primary", "source_title": "Instant Payments Launch (SARIE), circular 42047169, 2021-02-17, English translation", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the launch circular sets duties on transaction limits, customer fees, branding and staff briefing and says nothing about operating hours for the instant payment system. Does not confirm or deny continuous availability." }, { "source_url": "https://www.sab.com/en/personal/payments-and-transfers/sarie/", "source_class": "secondary", "source_title": "SAB, SARIE and Sarie local transfers page, sab.com, read 2026-09-18", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms Sarie instant transfers are available 24 hours a day 7 days a week including holidays and weekends, and separately that the bank's ordinary local SARIE transfer route has a cut off of 15:30 at branches and 14:30 on electronic channels, Sunday to Thursday. Supports the record's distinction between the always-on instant payment route and the older business-hours route for larger transfers." } ] }, "rail_name": "Saudi Arabia sarie (instant payments)", "governing_authority": "Saudi Central Bank (SAMA)", "snapshot": "2026-09-18", "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "not_public", "label": "the operator's own text", "needs": "what the operator's own text says, which Orca has not read", "detail": "Saudi Central Bank (SAMA)'s own text is not the source for this rail fact: it is not public, or not under terms Orca can use. It rests on 2 named public sources, so a term set by agreement rather than by a published rule is not Orca's to state.", "from": "currency.primary_not_public" } ] }, { "uid": "sa-sarie:liability", "id": "liability", "rail": "sa-sarie", "kind": "rail-fact", "facet": "liability", "name": "Who bears the loss when a payment goes wrong?", "statement": "Nothing sarie publishes allocates losses between banks; that allocation, if any, is in the member documents. What is public is SAMA's allocation between a provider and its own customer. For banks, SAMA's consumer rules put losses from a breach or weak security of the bank's electronic channels on the bank, and require it to protect customers' money against fraud. For licensed payment and e-money institutions, the Regulations go further: the provider carries unauthorised payments and must prove a disputed payment was authenticated and recorded properly; the payer's share is capped at SAR 150 for a lost, stolen or misused instrument, rises to the whole loss for fraud or gross negligence with credentials, and falls to nothing once the payer has reported the problem or where the provider skipped the strong authentication SAMA requires. A payer who keys the wrong payee bears that mistake.", "details": [ { "label": "Banks: channel failures and fraud controls", "value": "SAMA requires every financial institution it supervises to protect customers' assets against fraud with effective detection and control systems, to keep electronic channels available and secure, to compensate customers for direct losses caused by penetration or weak security of those channels, and to state the purpose in any one-time password message, for example a money transfer.", "citation": "SAMA Financial Consumer Protection Principles and Rules, circular 44006639 of 2022-08-23 (1444-01-26 H), section 2 principle 5 and section 3 rule 12 (English page)", "rests_on": "law" }, { "label": "Non-bank providers: the provider carries unauthorised payments", "value": "A licensed payment or e-money institution is liable for payments made without the payer's authority. If the payer says a payment was unauthorised or wrongly executed, the provider has to prove it was authenticated, correctly recorded and not affected by a fault, and if it alleges fraud by the payer it must prove that too in the dispute process.", "citation": "Implementing Regulations of the Law of Payments, circular 44093096 of 2023-06-13 (1444-11-24 H), arts. 1 (definition of Payment Service Provider), 79(2), 79(3) and 87(1) (English translation)", "rests_on": "law" }, { "label": "Non-bank providers: the payer's share", "value": "Three outcomes for the payer. Nothing, once they have reported the loss or misuse, where the provider gave them no way to report, or where the provider did not apply strong authentication that SAMA requires, unless the payer acted fraudulently. Up to SAR 150, where a lost, stolen or misused instrument was used, unless the loss could not have been detected beforehand or was caused by the provider's own staff, agents or branches. Everything, where the payer acted fraudulently or, deliberately or through gross negligence, failed to keep the instrument and credentials safe.", "citation": "Implementing Regulations art. 88(1) to 88(4)", "rests_on": "law" }, { "label": "Wrong payee details", "value": "A provider is not liable where the payer supplied the wrong payee identifier or bank details; its duty is a reasonable attempt at recovery, which the recall fact describes.", "citation": "Implementing Regulations art. 86(1)", "rests_on": "law" }, { "label": "Between providers", "value": "Where one provider's liability to its customer is really caused by another provider, including one that failed to use the authentication SAMA requires, the one at fault must compensate the one that paid. If the payee or the payee's provider refuses strong authentication SAMA requires, it must reimburse the payer's provider for what it paid out. How sarie itself splits losses between member banks is not public.", "citation": "Implementing Regulations arts. 85 and 88(5); SAMA circular 42047169, Instant Payments Launch (SARIE), 2021-02-17 (1442-07-06 H), item 1 (member documents not public)", "rests_on": "law" } ], "exceptions": [ "The Regulations' allocation (arts. 79 to 89) binds licensed payment and e-money institutions; banks are held to it only as far as SAMA specifies under art. 48(2), and which provisions SAMA has applied to banks was not found [Unverified].", "A customer tricked into authorising a transfer to a fraudster is outside the unauthorised-payment rules, which cover payments started by someone without authority; no public text read allocates that loss [Inference from the definition in Implementing Regulations art. 1].", "A provider that has reasonable grounds to suspect the user of fraud, and reports them to SAMA in writing, need not make the immediate refund (Implementing Regulations art. 89(3)); liability is then settled through investigation, complaint or dispute." ], "applies_to": "losses on sarie instant credit transfers between a payer and their bank or licensed payment provider; interbank allocation is not public", "caveat": "For a bank customer, the firm public rule is SAMA's consumer rule on channel security and technical errors, not the Regulations' SAR 150 cap, which is written for licensed payment and e-money institutions.", "related": [ "sa-sarie:refund", "sa-sarie:recall", "sa-sarie:consumer-law", "sa-sarie:decision-points" ], "basis": { "sources": "SAMA rulebook portal, English pages read 2026-09-18: Financial Consumer Protection Principles and Rules, circular 44006639 (2022-08-23), section 2 principle 5 and section 3 rule 12; Implementing Regulations circular 44093096 (2023-06-13), arts. 1, 48, 79, 85, 86, 87, 88 and 89; launch circular 42047169 (2021-02-17). English pages on a portal whose terms deny it legal effect (public_primary). The interbank allocation, if any, is in sarie member documents that are not public, hence primary_not_public and medium. Nothing is quoted.", "confidence": "medium" }, "currency": { "effective_since": "2023-06-13", "effective_note": "Dated from the Implementing Regulations (2023-06-13, 1444-11-24 H); the consumer rules date from circular 44006639 (2022-08-23, 1444-01-26 H).", "source_edition": "Financial Consumer Protection Principles and Rules, circular 44006639 (2022-08-23); Implementing Regulations circular 44093096 (2023-06-13); SAMA circular 42047169 (2021-02-17)", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "primary_not_public": true, "corroboration": [] }, "rail_name": "Saudi Arabia sarie (instant payments)", "governing_authority": "Saudi Central Bank (SAMA)", "snapshot": "2026-09-18", "source_class": null, "effective_status": "draft", "effective_status_reason": null, "boundaries": [ { "kind": "not_public", "label": "the operator's own text", "needs": "what the operator's own text says, which Orca has not read", "detail": "Saudi Central Bank (SAMA)'s own text is not the source for this rail fact: it is not public, or not under terms Orca can use. It rests on 0 named public sources, so a term set by agreement rather than by a published rule is not Orca's to state.", "from": "currency.primary_not_public" } ] }, { "uid": "sa-sarie:limits", "id": "limits", "rail": "sa-sarie", "kind": "rail-fact", "facet": "limits", "name": "How much can move in one payment, and who sets the limit?", "statement": "SAMA sets two ceilings for sarie and requires every member to respect them: a single transaction limit for any payment, and a lower quick transfer limit for paying someone the customer has not added and activated as a beneficiary. The public circular names both limits without giving the numbers. Participant banks publish them as SAR 20,000 per payment and SAR 2,500 for a quick transfer by IBAN or alias, the latter set by the customer at any level up to the cap, with some banks starting it at zero. A larger transfer is not refused; the bank sends it by the ordinary local transfer route instead. SAMA also caps what a bank may charge an individual for these transfers, which Orca records here because the schema has no fees facet.", "details": [ { "label": "Two ceilings, set by SAMA", "value": "Every sarie member must keep to a maximum for a single payment and a separate, lower maximum for a quick transfer, meaning a payment made without first activating the payee as a beneficiary. The public translation of the launch circular gives no figures for either.", "citation": "SAMA circular 42047169, Instant Payments Launch (SARIE), 2021-02-17 (1442-07-06 H), item 2 (English translation on the rulebook portal)", "rests_on": "rule" }, { "label": "SAR 20,000 per payment", "value": "Participant banks, in their own wording, give SAR 20,000 as the most a single instant transfer can carry to a saved or activated beneficiary. SAMA's 2025 fee guide uses the same figure as the line between its instant-transfer fee bands and its higher same-day and next-day bands, which fits a ceiling at that amount [Inference].", "citation": "Bank Albilad, Sarie instant payments page (bankalbilad.com.sa, read 2026-09-18), limits section; Riyad Bank, Instant Payment Service (SARIE) page (riyadbank.com, read 2026-09-18), limits section; Banque Saudi Fransi, FransiGlobal Instant Payment Sarie leaflet dated 2024-04-15 (bsf.sa); SAMA Guide to Financial Institutions Services Fees, circular 472038000 of 2025-12-22 (1447-07-02 H), art. 9 tariff items 29 to 32 (Arabic original)", "rests_on": "practice" }, { "label": "SAR 2,500 for a quick transfer, and the customer picks the level", "value": "Paying by IBAN or alias without activating the payee is allowed up to SAR 2,500. Within that cap the customer chooses their own limit in the bank's app; one bank says the limit sits at zero until the customer raises it. Above SAR 2,500 the payee must be added and activated first.", "citation": "Bank Albilad Sarie page, how-to and limits sections; SAB, SARIE local transfers page (sab.com, read 2026-09-18), Sarie features; The Saudi Investment Bank, SARIE service page (saib.com.sa, read 2026-09-18); Riyad Bank SARIE page, limits section and FAQ 1", "rests_on": "practice" }, { "label": "Above the ceiling the payment changes route, not fate", "value": "Banks say a transfer larger than SAR 20,000 still goes, as an ordinary local bank transfer outside sarie, and one says it is processed within official working hours.", "citation": "Riyad Bank SARIE page, limits section; Bank Albilad Sarie page, limits section; Banque Saudi Fransi FransiGlobal Sarie leaflet (2024-04-15)", "rests_on": "practice" }, { "label": "Each bank must also set and disclose its own transfer limits", "value": "Apart from sarie's ceilings, SAMA's consumer rules require every bank and payment company to have a maximum for transfers, as for several other channels; it must look at that maximum again at least yearly and disclose it to a customer when the service begins. Licensed payment and e-money institutions also need a risk-based policy on user transaction limits, may change it only after SAMA gives its non-objection, and must use SAMA's own figures where SAMA directs.", "citation": "SAMA Financial Consumer Protection Principles and Rules, circular 44006639 of 2022-08-23 (1444-01-26 H), section 4, rule 9; Implementing Regulations of the Law of Payments, circular 44093096 of 2023-06-13 (1444-11-24 H), art. 70", "rests_on": "law" }, { "label": "Fee caps (recorded here because there is no fees facet)", "value": "For individual customers, SAMA's 2025 fee guide caps a transfer from a bank or e-money account to another in the Kingdom at SAR 0.5 up to SAR 2,500 and SAR 1 from there to SAR 20,000, before VAT; the guide ties its transfer section to the sarie launch circular. Transfers above SAR 20,000 carry higher caps that depend on channel and timing: SAR 7 electronic or SAR 25 at a branch for same business day, SAR 5 or SAR 15 for next business day. Transfers inside one bank or one e-money provider are free. The 2021 launch circular had set the sarie caps at SAR 0.5 up to SAR 500 and SAR 1 above; the guide replaces conflicting provisions. Several banks' pages still show the older SAR 500 band [Unverified: whether those pages are stale or the banks charge below the cap].", "citation": "SAMA Guide to Financial Institutions Services Fees, circular 472038000 of 2025-12-22 (1447-07-02 H), art. 9 tariff items 28 to 32 and footnote 3, art. 11(2) (Arabic original); SAMA circular 42047169 (2021-02-17), item 3; Riyad Bank SARIE page, FAQ 2; The Saudi Investment Bank SARIE page, fees table", "rests_on": "law" } ], "exceptions": [ "The fee caps in art. 9 of the 2025 guide apply to individual customers; fees for business customers are left to each institution, within the guide's art. 10 criteria of reasonableness.", "Both ceilings are published by participant banks, not by SAMA in any public text read, and may have changed since the pages were written [Unverified: current values in the member documents].", "A bank may set a customer's own limit below the sarie ceilings, and SAMA's consumer rules require it to have and disclose such limits; the sarie ceilings are maximums, not entitlements.", "Payments through a licensed payment institution or e-money wallet are subject to that provider's own SAMA-approved limits policy; whether such providers send on sarie directly was not established." ], "applies_to": "sarie instant payments in Saudi riyals between accounts at participating Saudi banks; fee caps for individual customers of institutions SAMA supervises", "caveat": "Quote SAR 20,000 and SAR 2,500 as what banks publish, not as SAMA's text. For fees, the governing figure is SAMA's 2025 guide (SAR 0.5 up to SAR 2,500), not the SAR 500 band still printed on some bank pages.", "related": [ "sa-sarie:hours", "sa-sarie:participants", "sa-sarie:consumer-law" ], "basis": { "sources": "SAMA rulebook portal, read 2026-09-18: launch circular 42047169 (English translation marked Translated Document; public_primary; Arabic scan not read); Guide to Financial Institutions Services Fees (dalil ta'rifat khadamat al-mu'assasat al-maliyya), Arabic original at rulebook.sama.gov.sa/ar/node/10681 with its covering circular 472038000 at /ar/node/10697, read in Arabic (authoritative_primary; the English page says the text is available only in Arabic); Financial Consumer Protection Principles and Rules, circular 44006639 (English page); Implementing Regulations circular 44093096 (English translation). Participant banks' own public pages, read 2026-09-18: Bank Albilad (bankalbilad.com.sa), SAB (sab.com), The Saudi Investment Bank (saib.com.sa), Riyad Bank (riyadbank.com), Banque Saudi Fransi leaflet dated 2024-04-15 (bsf.sa). Riyad Bank and Banque Saudi Fransi use near-identical wording, so they count as one source for independence; Bank Albilad and SAB each write their own. The figures are in member documents that are not public, hence primary_not_public and medium. Nothing is quoted.", "confidence": "medium" }, "currency": { "effective_since": "2026-02-20", "effective_note": "The fee guide (circular 472038000 of 2025-12-22, 1447-07-02 H) takes effect 60 days after publication on SAMA's website [Inference: 2026-02-20 if published on the circular date; the publication date was not found]. The two ceilings date from the launch circular of 2021-02-17 (1442-07-06 H); their values are as banks published them when read on 2026-09-18.", "source_edition": "SAMA fee guide, circular 472038000 (2025-12-22); SAMA circular 42047169 (2021-02-17); Financial Consumer Protection Principles and Rules, circular 44006639 (2022-08-23); Implementing Regulations circular 44093096 (2023-06-13); bank pages as read 2026-09-18, BSF leaflet 2024-04-15", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "primary_not_public": true, "corroboration": [ { "source_url": "https://rulebook.sama.gov.sa/ar/entiresection/10681", "source_class": "authoritative_primary", "source_title": "دليل تعرفة خدمات المؤسسات المالية (Guide to Financial Institutions Services Fees), circular 472038000, 2025-12-22, Arabic original, full text", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms article 9 items 28 to 32 exactly: transfers within the same bank or e-money provider are free, SAR 0.5 for transfers up to SAR 2,500, SAR 1 for transfers above SAR 2,500 and up to SAR 20,000, and for transfers above SAR 20,000 SAR 25 at a branch or SAR 7 electronically for same business day and SAR 15 at a branch or SAR 5 electronically for next business day, all before VAT. Confirms footnote 3 ties the transfer items to sarie launch circular 42047169, dated there as 1442-07-07H. Confirms article 11(2): the guide takes effect 60 days after publication on SAMA's website and replaces the prior banking tariff. Does not state the SAR 20,000 or SAR 2,500 transaction limits themselves, which the transfer bands assume rather than set." }, { "source_url": "https://www.bankalbilad.com.sa/en/personal/digital-channels/pages/instant-payments.aspx", "source_class": "secondary", "source_title": "Bank Albilad, Sarie Service for instant payments, bankalbilad.com.sa, read 2026-09-19", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms a maximum single transaction of SAR 20,000 for an added and activated beneficiary and SAR 2,500 for a transfer to a non-added beneficiary by alias, that the customer sets their own quick transfer limit up to SAR 2,500, and that a transfer above SAR 20,000 is processed as an ordinary transfer within official working hours rather than refused." }, { "source_url": "https://www.riyadbank.com/personal-banking/digital-banking-key-features/sarie", "source_class": "secondary", "source_title": "Riyad Bank, Instant Payment Service SARIE page, riyadbank.com, read 2026-09-19", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms SAR 20,000 as the maximum for a transfer to a saved or added beneficiary, with a transfer above that amount processed by the normal local bank transfer method. Confirms SAR 2,500 as the maximum for a quick transfer by IBAN or alias, that the user can set the limit within that range, and that it defaults to zero until raised. Its own fee FAQ still shows SAR 0.5 up to SAR 500 and SAR 1 above, an older figure than the 2025 fee guide." } ] }, "rail_name": "Saudi Arabia sarie (instant payments)", "governing_authority": "Saudi Central Bank (SAMA)", "snapshot": "2026-09-18", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "not_public", "label": "the operator's own text", "needs": "what the operator's own text says, which Orca has not read", "detail": "Saudi Central Bank (SAMA)'s own text is not the source for this rail fact: it is not public, or not under terms Orca can use. It rests on 3 named public sources, so a term set by agreement rather than by a published rule is not Orca's to state.", "from": "currency.primary_not_public" } ] }, { "uid": "sa-sarie:messages", "id": "messages", "rail": "sa-sarie", "kind": "rail-fact", "facet": "messages", "name": "What messages carry a payment and its exceptions on this rail?", "statement": "sarie is built on ISO 20022, according to a SAMA assistant governor writing in 2025, but SAMA publishes no message catalogue, usage guidelines, status or reason codes for it. What the public can see are the services the messages carry: a credit transfer to an account identified by IBAN or by a registered alias, an account verification check that returns the payee's name and bank before a payee is added or a quick transfer is sent, an alias register held by Saudi Payments, and, at some banks, a lookup of which banks hold active accounts for a national ID or residence permit. Which ISO messages implement each, and what a reject or return looks like, is in member documents that are not public.", "details": [ { "label": "Standard", "value": "The instant payment system was developed to the ISO 20022 standard, per a SAMA assistant governor. A Saudi business publication says the same and adds that it was built with technology partners. No SAMA circular read names the standard.", "citation": "A. A. Aldeheem, Saudi Central Bank: Driving Transformation in Digital Payments, International Banker, 2025-05-28; Tanmeya, Instant Payments, Instant Shift: How Sarie's 24/7 Model is Reshaping Consumer Banking (tanmeya.com.sa, read 2026-09-18)", "rests_on": "guidance" }, { "label": "Account verification before a new payee", "value": "Since May 2023 every bank must run an account verification check before it finishes adding and activating a beneficiary for transfers on either the instant payment system or the RTGS, following an operational and technical requirements document and the system's rules. One bank describes it as showing the payee's name and bank from the IBAN, for both new beneficiaries and quick transfers.", "citation": "SAMA circular 44075612, 2023-04-16 (1444-09-25 H), items 1 and 2 and closing paragraph (readiness by 2023-05-11) (English translation); The Saudi Investment Bank, SARIE service page (saib.com.sa, read 2026-09-18), account verification", "rests_on": "rule" }, { "label": "Addressing by alias", "value": "A payment can be addressed to a mobile number, national ID or residence permit number, email or, for companies, a commercial registration number, which the payee has registered through their bank with Saudi Payments, by consent. One bank's corporate instructions ask the payer for the payee's bank as well as the alias [Unverified: whether the system can resolve the bank from the alias alone].", "citation": "Banque Saudi Fransi, FransiGlobal Instant Payment Sarie leaflet dated 2024-04-15 (bsf.sa); Bank Albilad, Sarie instant payments page (bankalbilad.com.sa, read 2026-09-18); Riyad Bank, Instant Payment Service (SARIE) page (riyadbank.com, read 2026-09-18)", "rests_on": "practice" }, { "label": "Account finder", "value": "At least one bank offers a lookup that lists which participating banks hold active accounts for a given national ID or residence permit number, limited to banks in the sarie service.", "citation": "The Saudi Investment Bank SARIE service page, account finder service", "rests_on": "practice" }, { "label": "What is not public", "value": "The message set and its versions, the status and reason codes for rejects and returns, field rules, and the technical specifications for verification and alias lookup. SAMA's launch circular points members to technical and operational documents shared by Saudi Payments. The only return and rejection code list found on SAMA's portal belongs to the AFAQ cross-currency service, not to sarie.", "citation": "SAMA circular 42047169, Instant Payments Launch (SARIE), 2021-02-17 (1442-07-06 H), items 1 and 4; rulebook.sama.gov.sa search for sarie and instant payment, read 2026-09-18; SAMA Operating Rules for Cross Currency Payments using AFAQ Service, circular 42068309 of 2021-05-05 (1442-09-24 H), Appendix 2 (English page, breadcrumb and code table read 2026-09-18)", "rests_on": "rule" } ], "exceptions": [ "SAMA's 2020 amendment on beneficiary identification (circular 42008925, 2020-10-05, 1442-02-18 H) lets a legal-entity sender identify the payee by ID number instead of name alongside the IBAN. It amends the SARIE RTGS operating rules and predates the instant payment system; whether sarie applies the same rule is [Unverified].", "A transfer above the single payment ceiling travels in the ordinary local transfer route's messages, not sarie's.", "Which ISO 20022 messages sarie uses (for example pacs.008 for the credit and pacs.002 for status) is not public; any such mapping is [Speculation] until a published source states it." ], "applies_to": "sarie instant credit transfers, account verification and alias addressing between participating Saudi banks", "caveat": "Do not map sarie to ISO message names or reason codes from another scheme. The only SAMA code list found in public is AFAQ's, whose codes cover cross-currency and cross-border failures that cannot occur on a domestic riyal instant payment.", "related": [ "sa-sarie:participants", "sa-sarie:return", "sa-sarie:decision-points" ], "basis": { "sources": "Signed article by SAMA's Assistant Governor for Executive Affairs in International Banker, 2025-05-28 (secondary); Tanmeya article on sarie (tanmeya.com.sa, undated as read, secondary and weak: it cites no source). SAMA rulebook portal, English translations read 2026-09-18: circular 44075612 (2023-04-16), circular 42008925 (2020-10-05), launch circular 42047169 (2021-02-17), and the AFAQ Operating Rules Appendix 2 (circular 42068309, 2021-05-05) for what the portal's one code list covers (public_primary). Participant bank pages read 2026-09-18: The Saudi Investment Bank, Bank Albilad, Riyad Bank, Banque Saudi Fransi leaflet dated 2024-04-15. The message specifications are member documents that are not public, hence primary_not_public and low. Nothing is quoted.", "confidence": "low" }, "currency": { "effective_since": "2023-05-11", "effective_note": "Dated from the readiness deadline for account verification in circular 44075612 (issued 2023-04-16, 1444-09-25 H). ISO 20022 as the standard dates from launch in February 2021 per the 2025 article. Bank pages as read 2026-09-18.", "source_edition": "International Banker article 2025-05-28; SAMA circular 44075612 (2023-04-16); SAMA circular 42008925 (2020-10-05); SAMA circular 42047169 (2021-02-17); bank pages as read 2026-09-18, BSF leaflet 2024-04-15", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "primary_not_public": true, "corroboration": [ { "source_url": "https://rulebook.sama.gov.sa/en/implementation-account-verification-service-through-instant-payments-system-ips-and-saudi-rapid", "source_class": "public_primary", "source_title": "Implementation of the Account Verification Service Through IPS and RTGS, circular 44075612, 2023-04-16, English translation", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms every bank must implement account verification before completing addition and activation of a beneficiary for transfers on both the instant payment system and the RTGS, following the service's own operational and technical requirements document, with a 2023-05-11 readiness deadline. Does not name a message standard or list any status or reason codes." }, { "source_url": "https://www.saib.com.sa/en/sarie-service", "source_class": "secondary", "source_title": "The Saudi Investment Bank, SARIE Service page, saib.com.sa, read 2026-09-18", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the bank runs an account verification check returning the payee's name and bank from the IBAN before both a quick transfer and an add or activate beneficiary request, and offers an account finder listing which participating banks hold an active account for a national ID or Iqama number. Confirms aliasing by mobile number, national ID, Iqama or email for transfers up to SAR 2,500. Does not name a message standard or describe reject or return codes." } ] }, "rail_name": "Saudi Arabia sarie (instant payments)", "governing_authority": "Saudi Central Bank (SAMA)", "snapshot": "2026-09-18", "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "not_public", "label": "the operator's own text", "needs": "what the operator's own text says, which Orca has not read", "detail": "Saudi Central Bank (SAMA)'s own text is not the source for this rail fact: it is not public, or not under terms Orca can use. It rests on 2 named public sources, so a term set by agreement rather than by a published rule is not Orca's to state.", "from": "currency.primary_not_public" } ] }, { "uid": "sa-sarie:participants", "id": "participants", "rail": "sa-sarie", "kind": "rail-fact", "facet": "participants", "name": "Who can be on this rail, in what roles, and who cannot?", "statement": "sarie is SAMA's system: SAMA owns it and writes its rules, and a bank takes part by signing a membership agreement and following technical and operational documents that Saudi Payments, the team running the project, hands to members. Everything public points to licensed banks in the Kingdom as the members, and participant banks describe the service as transfers between local banks. Whether a licensed payment institution or e-money institution can join directly, or only reach sarie through a bank, is not stated in any public text read. Customers are not participants; they reach sarie through their bank, and to be paid by alias they register a mobile number, national ID, residence permit number or email with their bank, which shares it with Saudi Payments with their consent.", "details": [ { "label": "Membership is by agreement with SAMA's system", "value": "SAMA's launch circular binds every participating member to sign the sarie membership agreement and to follow the latest technical documents, operational documents and service level agreements that the Saudi Payments team shared with members before launch. None of those documents is public.", "citation": "SAMA circular 42047169, Instant Payments Launch (SARIE), 2021-02-17 (1442-07-06 H), item 1 (English translation on the rulebook portal)", "rests_on": "rule" }, { "label": "Who the members are", "value": "The launch circular sits among SAMA's banking sector circulars and speaks to banks: it tells them to brief their staff and to rename the service in their channels. The 2023 account verification circular is addressed to banks and financial institutions and sets a deadline for all banks to finish technical approvals. Participant banks describe sarie as transfers among local banks, and one says the payee's bank must be among the banks registered for the service. No public text read names a non-bank as a direct member [Unverified: whether any licensed payment institution or e-money institution is a direct member].", "citation": "SAMA circular 42047169 (2021-02-17), items 5 and 6; SAMA circular 44075612 (2023-04-16, 1444-09-25 H), opening and closing paragraphs; The Saudi Investment Bank, SARIE service page (saib.com.sa, read 2026-09-18); Bank Albilad, Sarie instant payments page (bankalbilad.com.sa, read 2026-09-18)", "rests_on": "rule" }, { "label": "Who owns and who runs it", "value": "SAMA owns the system and is its rule-writer and overseer. Saudi Payments is the body that circulated the technical documents, handles bank onboarding for new services, and holds the alias register customers consent to share data with. Participant banks describe Saudi Payments as owned by SAMA [Unverified: no SAMA text read states the ownership or operating mandate of Saudi Payments].", "citation": "SAMA circular 42047169 (2021-02-17), items 1 and 4; SAMA circular 44075612 (2023-04-16), onboarding paragraph; Banque Saudi Fransi, FransiGlobal Instant Payment Sarie leaflet dated 2024-04-15 (bsf.sa), requirements section; The Saudi Investment Bank, SARIE service page", "rests_on": "rule" }, { "label": "Fair access is a legal duty on operators", "value": "Under the Law of Payments, a payment system operator must give access on appropriate and fair commercial terms. The Implementing Regulations add that operators must make their systems available to members fairly, openly and transparently, and let SAMA order the operator of a systemically important system to admit an applicant, or order a direct member to take an applicant on as an indirect member.", "citation": "Law of Payments and Payment Services, Royal Decree M/26 of 1443-03-22 H (2021-10-28), art. 8(1); Implementing Regulations, circular 44093096 of 2023-06-13 (1444-11-24 H), art. 52(2) and 52(3)", "rests_on": "law" }, { "label": "Customers join the alias register by consent", "value": "To send or receive by alias a customer must hold an active account, agree through the bank's channel to share certain personal data with Saudi Payments, and register the identifier; they can replace or remove it later. One bank says proxy transfers must be switched on by explicit consent and can be switched off in its digital channels.", "citation": "Banque Saudi Fransi FransiGlobal Sarie leaflet (2024-04-15), requirements; The Saudi Investment Bank SARIE page, requirements; Riyad Bank, Instant Payment Service (SARIE) page (riyadbank.com, read 2026-09-18), limits section", "rests_on": "practice" } ], "exceptions": [ "The name SARIE also belongs to SAMA's real time gross settlement system, live since 1997, which has its own members and rules. Anything said here about membership is about the instant payment system only; the launch circular frames sarie as a successor in that line, not as the same system (circular 42047169, second paragraph).", "Implementing Regulations art. 52(3) lets SAMA force access only to a systemically important payment system; whether sarie is designated as one was not established, so whether that power reaches sarie is [Unverified].", "Participant banks' corporate channels (for example Banque Saudi Fransi's FransiGlobal) offer sarie to business users as well as individuals; the membership position of those users is the same as any customer's: they are not participants." ], "applies_to": "the sarie instant payment system (IPS) in Saudi Arabia, launched February 2021; not the SARIE RTGS", "caveat": "Do not name Saudi Payments as the rule-writer. SAMA issues the rules and circulars; Saudi Payments circulates the technical and operational documents and runs onboarding. The membership agreement and the member documents are not public, so every statement here about who may join is drawn from what SAMA's circulars and participant banks say in public.", "related": [ "sa-sarie:messages", "sa-sarie:settlement", "sa-sarie:decision-points" ], "basis": { "sources": "SAMA rulebook portal (rulebook.sama.gov.sa), English pages read 2026-09-18: circular 42047169 Instant Payments Launch (SARIE), 2021-02-17 (1442-07-06 H), marked Translated Document; circular 44075612 on the account verification service, 2023-04-16 (1444-09-25 H), marked Translated Document; Law of Payments and Payment Services (M/26, 1443-03-22 H, 2021-10-28) art. 8; Implementing Regulations (circular 44093096, 2023-06-13, 1444-11-24 H) art. 52. The portal's terms say it carries translations with no legal effect and that the Arabic originals govern; the Arabic scans were not read, so these are public_primary. Participant banks' own public pages, each in its own wording: The Saudi Investment Bank SARIE page (saib.com.sa), Bank Albilad Sarie page (bankalbilad.com.sa), Banque Saudi Fransi FransiGlobal Sarie leaflet dated 2024-04-15 (bsf.sa), Riyad Bank SARIE page (riyadbank.com). The membership agreement and member documents are not public, hence primary_not_public and medium. Nothing is quoted.", "confidence": "medium" }, "currency": { "effective_since": "2021-02-17", "effective_note": "Dated from the launch circular (1442-07-06 H), which gives the launch as 2021-02-21 in one sentence and asks for approvals before 2021-02-20 in the next. The access duties date from the Implementing Regulations of 2023-06-13 (1444-11-24 H). Bank pages are as read 2026-09-18.", "source_edition": "SAMA circular 42047169 (2021-02-17); SAMA circular 44075612 (2023-04-16); Law of Payments M/26 (2021-10-28); Implementing Regulations circular 44093096 (2023-06-13); bank pages as read 2026-09-18, BSF leaflet 2024-04-15", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "primary_not_public": true, "corroboration": [ { "source_url": "https://rulebook.sama.gov.sa/en/article-52-5", "source_class": "public_primary", "source_title": "Implementing Regulations of the Law of Payments, Article 52, Part 5 Consumer Protection and Financial Inclusion, circular 44093096, 2023-06-13, English translation", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms payment system operators must make their systems available to members on a fair, open and transparent basis, and that SAMA may require the operator of a systemically important payment system to admit an applicant as a direct or indirect member. Does not name sarie's own members or state whether a non-bank can join directly." }, { "source_url": "https://www.saib.com.sa/en/sarie-service", "source_class": "secondary", "source_title": "The Saudi Investment Bank, SARIE Service page, saib.com.sa, read 2026-09-18", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the payee's bank must be among the banks registered for IPS services and that registration for alias transfers requires agreeing to share personal data with Saudi Payments. Supports the record's claim that sarie's public description names local banks as members and does not mention non-bank participants." } ] }, "rail_name": "Saudi Arabia sarie (instant payments)", "governing_authority": "Saudi Central Bank (SAMA)", "snapshot": "2026-09-18", "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "not_public", "label": "the operator's own text", "needs": "what the operator's own text says, which Orca has not read", "detail": "Saudi Central Bank (SAMA)'s own text is not the source for this rail fact: it is not public, or not under terms Orca can use. It rests on 2 named public sources, so a term set by agreement rather than by a published rule is not Orca's to state.", "from": "currency.primary_not_public" } ] }, { "uid": "sa-sarie:recall", "id": "recall", "rail": "sa-sarie", "kind": "rail-fact", "facet": "recall", "name": "Can the sender or the sending bank pull a payment back, and how?", "statement": "No public source describes a way for a sender or a sending bank to recall a sarie payment, and banks' pages offer no cancel option for an instant transfer. What the law provides, for licensed payment and e-money institutions, is a recovery effort rather than a recall: once the provider has the order the user cannot revoke it, and if the user keyed the wrong payee identifier the provider is not liable, but it must make reasonable efforts to get the money back with the payee's provider's help, may charge for that under the contract, and must hand over what it knows if recovery fails. SAMA can direct the provider to take further steps, including refunding the payer. Whether SAMA has applied these duties to banks, and whether sarie's member documents contain a recall message or procedure, is not public.", "details": [ { "label": "No cancel once sent", "value": "A user of a licensed payment or e-money institution cannot revoke a payment order after the provider has received it, unless the provider agrees; the provider may charge for an agreed revocation only if the contract says so. For banks no equivalent public sarie rule was found, and bank pages present the transfer as reaching the payee instantly.", "citation": "Implementing Regulations of the Law of Payments, circular 44093096 of 2023-06-13 (1444-11-24 H), arts. 1 (definition of Payment Service Provider), 48(2), 74(1), 74(5) and 74(6) (English translation); Bank Albilad, Sarie instant payments page (bankalbilad.com.sa, read 2026-09-18); SAB, SARIE local transfers page (sab.com, read 2026-09-18)", "rests_on": "law" }, { "label": "Wrong payee details: recovery, not reversal", "value": "Misdirection by the user takes liability off the payer's provider, but not the work. Getting the money back is a joint job: the recipient's provider must help as far as it can, the payer's provider must make a reasonable attempt, and the user can be billed for that attempt where the contract provides for it. SAMA can step in and order particular steps, a refund to the payer among them. If nothing comes back, the payer can ask in writing for the information the provider holds and pursue the recipient directly.", "citation": "Implementing Regulations art. 86(1) to 86(4)", "rests_on": "law" }, { "label": "sarie's own procedure is not public", "value": "Any recall request message, deadline, or duty on the receiving bank to freeze or return funds would sit in the member documents Saudi Payments shared with banks at launch, which are not public.", "citation": "SAMA circular 42047169, Instant Payments Launch (SARIE), 2021-02-17 (1442-07-06 H), item 1", "rests_on": "rule" }, { "label": "A priced cancellation exists, but not for sarie", "value": "One bank's fee table lists a charge for asking another local bank to cancel or amend a transfer by SWIFT message, alongside its same-day and next-day local transfer fees; its sarie fees are listed separately. The cancellation service appears to belong to the ordinary local transfer route [Inference].", "citation": "The Saudi Investment Bank, SARIE service page (saib.com.sa, read 2026-09-18), fees table", "rests_on": "practice" } ], "exceptions": [ "A payment the customer did not authorise is not a recall case; the payer's provider must refund it under the Regulations, subject to the conditions in the liability fact.", "A transfer above the single payment ceiling goes by the ordinary local transfer route, where a bank may offer a priced cancellation or amendment request.", "Whether a bank can stop a sarie payment in the moments before it settles, for example on a fraud alert, depends on member rules that are not public [Unverified]." ], "applies_to": "sarie instant credit transfers between participating Saudi banks; the recovery duty as written binds licensed payment and e-money institutions", "caveat": "Tell a sender who used the wrong alias or IBAN to contact their own bank at once and ask for a recovery request, and not to expect the payment to be reversed. Whether and how fast the money comes back depends on the recipient and the recipient's bank.", "related": [ "sa-sarie:finality", "sa-sarie:return", "sa-sarie:liability", "sa-sarie:refund" ], "basis": { "sources": "SAMA rulebook portal, English translations read 2026-09-18: Implementing Regulations circular 44093096 (2023-06-13), arts. 1, 48, 74 and 86; launch circular 42047169 (2021-02-17) (public_primary; the portal's terms deny it legal effect). Participant bank pages read 2026-09-18: Bank Albilad, SAB, The Saudi Investment Bank. A digital bank's sarie page that reportedly describes a recovery request by phone or chat refused a plain request (HTTP 403) and was not read. sarie's recall rules, if any, are in member documents that are not public, hence primary_not_public and low. Nothing is quoted.", "confidence": "low" }, "currency": { "effective_since": "2023-06-13", "effective_note": "Dated from the Implementing Regulations (2023-06-13, 1444-11-24 H). Nothing public dates any sarie-specific recall procedure. Bank pages as read 2026-09-18.", "source_edition": "Implementing Regulations circular 44093096 (2023-06-13); SAMA circular 42047169 (2021-02-17); bank pages as read 2026-09-18", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "primary_not_public": true, "corroboration": [ { "source_url": "https://rulebook.sama.gov.sa/en/article-86-2", "source_class": "public_primary", "source_title": "Implementing Regulations of the Law of Payments, Article 86, Part 6 Relevant Payment Services, circular 44093096, 2023-06-13, English translation", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms a provider is not liable for a payer's own wrong payee identifier or bank details, must make reasonable efforts to recover the funds with the payee's provider's cooperation, may charge a fee for the attempt under its contract, must give the payer available information if recovery fails, and that SAMA may direct specific actions including a refund to the payer. Does not describe any sarie-specific recall message or procedure." }, { "source_url": "https://www.saib.com.sa/en/sarie-service", "source_class": "secondary", "source_title": "The Saudi Investment Bank, SARIE Service page, saib.com.sa, read 2026-09-18", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the bank charges a separate fee for a cancellation or amendment request to another local bank by SWIFT message, listed apart from its sarie transfer fees, supporting the record's reading that this priced cancellation belongs to the ordinary local transfer route rather than to sarie." } ] }, "rail_name": "Saudi Arabia sarie (instant payments)", "governing_authority": "Saudi Central Bank (SAMA)", "snapshot": "2026-09-18", "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "not_public", "label": "the operator's own text", "needs": "what the operator's own text says, which Orca has not read", "detail": "Saudi Central Bank (SAMA)'s own text is not the source for this rail fact: it is not public, or not under terms Orca can use. It rests on 2 named public sources, so a term set by agreement rather than by a published rule is not Orca's to state.", "from": "currency.primary_not_public" } ] }, { "uid": "sa-sarie:refund", "id": "refund", "rail": "sa-sarie", "kind": "rail-fact", "facet": "refund", "name": "Does the payer have a right to get money back, and on what terms?", "statement": "A payer who authorised a sarie transfer to the right account has no general right to a refund in any public text read; sarie is a credit push the payer approves, with no mandate to dispute. Refund rights exist for things that went wrong on the provider's side or without the payer's authority, and they come from SAMA's conduct rules and the payments regulations, not from sarie's own rules. For bank customers, SAMA's consumer rules make a bank hand back, unasked and within five working days, money that reached it through a technical error, and compensate direct losses caused by a breach or weak security in its electronic channels. For customers of licensed payment and e-money institutions, the Regulations add refund duties for unauthorised payments (by the end of the next business day, if reported within six months), for failed or defective execution, and for systemic errors (within thirty calendar days).", "details": [ { "label": "No refund for an authorised, correct transfer", "value": "No SAMA circular or regulation read gives a payer a right to reverse or be refunded a credit transfer they authorised and that reached the account they named. The only no-questions refund in the Regulations is for payments started by or through the payee, such as direct debits, where the amount was open-ended and unexpectedly high, claimed within eight weeks; a sarie credit transfer is started by the payer.", "citation": "Implementing Regulations of the Law of Payments, circular 44093096 of 2023-06-13 (1444-11-24 H), arts. 1 (definition of Credit Transfer), 90 and 91(1) (English translation)", "rests_on": "law" }, { "label": "Bank errors come back without asking", "value": "A bank may not keep money it gained from a technical error or malfunction; it must pay each affected customer back within five working days without waiting for a claim, and fix the fault. Where customers suffer direct loss because a bank's electronic channels were penetrated or poorly secured, the bank must compensate them.", "citation": "SAMA Financial Consumer Protection Principles and Rules, circular 44006639 of 2022-08-23 (1444-01-26 H), section 3, rules 12 and 13 (English page)", "rests_on": "law" }, { "label": "Unauthorised payments, for non-bank providers", "value": "A licensed payment or e-money institution must put the account back as if an unauthorised payment had not happened, no later than the end of the business day after it learns of it, provided the payer reported it without undue delay and within six months of the debit. It may hold off only where it has reasonable grounds to suspect the user of fraud and reports those grounds to SAMA in writing. Any refund due after an investigation must be paid within seven days of the investigation ending.", "citation": "Implementing Regulations arts. 48(2), 87(1), 89(1), 89(2), 89(3), 89(6) and 89(8)", "rests_on": "law" }, { "label": "Failed, late or defective execution, for non-bank providers", "value": "Unless it can show the payment reached the payee's provider correctly, the payer's provider is answerable to the payer and must promptly restore the account; it also bears charges the payer incurred because of the failure. A provider that finds a systemic error must refund every affected user within thirty calendar days and tell SAMA.", "citation": "Implementing Regulations arts. 80(1), 80(2), 83(1), 83(2) and 84", "rests_on": "law" }, { "label": "Nothing sarie-specific is public", "value": "No sarie circular found sets a refund right, and the launch circular's member documents, where any scheme-level compensation rule would sit, are not public.", "citation": "SAMA circular 42047169, Instant Payments Launch (SARIE), 2021-02-17 (1442-07-06 H), item 1; rulebook.sama.gov.sa search for sarie and instant payment, read 2026-09-18", "rests_on": "rule" } ], "exceptions": [ "The Regulations' refund duties bind licensed payment and e-money institutions; banks are held to them only as far as SAMA specifies under art. 48(2), and which provisions SAMA has applied to banks was not found [Unverified].", "A payer defrauded into authorising a transfer (a scam) has no refund right in any text read; the unauthorised-payment rules cover payments started by someone without authority, not payments the payer was tricked into approving [Inference from the Regulations' definition of Unauthorized Payment Transactions in art. 1].", "A legal person using a payment institution in a business context may agree with it that some of these protections do not apply, as SAMA determines (Implementing Regulations art. 51)." ], "applies_to": "sarie instant credit transfers sent by customers of Saudi banks and, where they reach sarie, licensed payment and e-money institutions", "caveat": "Do not promise a refund for a sarie transfer the customer approved. The questions that decide it are whether the payment was authorised, whether the bank or provider erred, and whether the payer's provider is a bank or a licensed payment institution.", "related": [ "sa-sarie:liability", "sa-sarie:consumer-law", "sa-sarie:recall" ], "basis": { "sources": "SAMA rulebook portal, English pages read 2026-09-18: Financial Consumer Protection Principles and Rules, circular 44006639 (2022-08-23), section 3 rules 12 and 13; Implementing Regulations circular 44093096 (2023-06-13), arts. 1, 48, 51, 80, 83, 84, 87, 89, 90 and 91; launch circular 42047169 (2021-02-17). All are English pages on a portal whose terms deny it legal effect and say official channels govern (public_primary). Any sarie-level rule is in member documents that are not public, hence primary_not_public and medium. Nothing is quoted.", "confidence": "medium" }, "currency": { "effective_since": "2023-06-13", "effective_note": "Dated from the Implementing Regulations (2023-06-13, 1444-11-24 H). The consumer protection rules date from circular 44006639 (2022-08-23, 1444-01-26 H), effective from its date.", "source_edition": "Financial Consumer Protection Principles and Rules, circular 44006639 (2022-08-23); Implementing Regulations circular 44093096 (2023-06-13); SAMA circular 42047169 (2021-02-17)", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "primary_not_public": true, "corroboration": [] }, "rail_name": "Saudi Arabia sarie (instant payments)", "governing_authority": "Saudi Central Bank (SAMA)", "snapshot": "2026-09-18", "source_class": null, "effective_status": "draft", "effective_status_reason": null, "boundaries": [ { "kind": "not_public", "label": "the operator's own text", "needs": "what the operator's own text says, which Orca has not read", "detail": "Saudi Central Bank (SAMA)'s own text is not the source for this rail fact: it is not public, or not under terms Orca can use. It rests on 0 named public sources, so a term set by agreement rather than by a published rule is not Orca's to state.", "from": "currency.primary_not_public" } ] }, { "uid": "sa-sarie:return", "id": "return", "rail": "sa-sarie", "kind": "rail-fact", "facet": "return", "name": "Can the receiving side send a payment back, on what grounds, and by when?", "statement": "No public source read describes a return on sarie: no return message, no list of grounds, no deadline, and no rule on whether the receiving bank may or must send back a payment it cannot apply. Those rules, if they exist, are in the member documents SAMA told banks to follow, which are not public. The nearest public rule is general and binds licensed payment and e-money institutions rather than banks: a payee's provider may send funds back to the payer's provider when the payee holds no account with it, saying so. Account verification before a new payee is added is meant to stop the commonest cause of a return, a wrong account, before the payment is sent.", "details": [ { "label": "sarie's own return rules are not public", "value": "Nothing in the launch circular, the account verification circular, or any other sarie circular found on SAMA's portal sets out when or how a receiving bank returns an instant payment. The launch circular directs members to technical and operational documents and service levels shared by Saudi Payments, none of which is public.", "citation": "SAMA circular 42047169, Instant Payments Launch (SARIE), 2021-02-17 (1442-07-06 H), item 1; SAMA circular 44075612, 2023-04-16 (1444-09-25 H); rulebook.sama.gov.sa search for sarie and instant payment, read 2026-09-18", "rests_on": "rule" }, { "label": "The general rule for non-bank providers", "value": "A licensed payment or e-money institution that receives funds for a payee who has no account with it may send them back to the payer's provider with that explanation. The Regulations give it the option, not a duty, and set no deadline. Banks are held to this part of the Regulations only as far as SAMA specifies.", "citation": "Implementing Regulations of the Law of Payments, circular 44093096 of 2023-06-13 (1444-11-24 H), arts. 1 (definition of Payment Service Provider), 48(2) and 77 (English translation)", "rests_on": "law" }, { "label": "Prevention in place of returns", "value": "Banks must run account verification before a new beneficiary is added and activated for instant or RTGS transfers, and at least one bank offers the same check before a quick transfer, so the payer sees the payee's name and bank before sending.", "citation": "SAMA circular 44075612 (2023-04-16), item 1; The Saudi Investment Bank, SARIE service page (saib.com.sa, read 2026-09-18), account verification", "rests_on": "rule" } ], "exceptions": [ "Money sent to the right account of the wrong person, or obtained by fraud, is a recall or recovery question, not a return; see the recall and liability facts.", "The code list published on SAMA's portal with return codes belongs to the AFAQ cross-currency service (circular 42068309, Appendix 2) and does not describe sarie returns.", "Whether a receiving bank that cannot credit a sarie payment rejects it before settlement or returns it after is not public [Unverified]." ], "applies_to": "sarie instant credit transfers between participating Saudi banks", "caveat": "Absence in public is not absence in the rules. Treat any claim about sarie return grounds or deadlines as unsupported until a published source states them.", "related": [ "sa-sarie:recall", "sa-sarie:messages", "sa-sarie:finality" ], "basis": { "sources": "SAMA rulebook portal, English translations read 2026-09-18: launch circular 42047169 (2021-02-17); account verification circular 44075612 (2023-04-16); Implementing Regulations circular 44093096 (2023-06-13), arts. 1, 48 and 77; AFAQ Operating Rules Appendix 2 (circular 42068309) for scope only (public_primary). The Saudi Investment Bank SARIE page (saib.com.sa, read 2026-09-18). Participant bank pages from Bank Albilad, SAB, Riyad Bank and Banque Saudi Fransi were also read and say nothing about returns. sarie's return rules, if any, are in member documents that are not public, hence primary_not_public and low. Nothing is quoted.", "confidence": "low" }, "currency": { "effective_since": "Unknown", "effective_note": "No public text dates any sarie return rule. The general rule for non-bank providers dates from the Implementing Regulations of 2023-06-13 (1444-11-24 H); account verification from 2023-05-11 under circular 44075612.", "source_edition": "SAMA circular 42047169 (2021-02-17); SAMA circular 44075612 (2023-04-16); Implementing Regulations circular 44093096 (2023-06-13); bank pages as read 2026-09-18", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "primary_not_public": true, "corroboration": [ { "source_url": "https://rulebook.sama.gov.sa/en/article-77-2", "source_class": "public_primary", "source_title": "Implementing Regulations of the Law of Payments, Article 77, Part 6 Relevant Payment Services, circular 44093096, 2023-06-13, English translation", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms a provider may, not must, return received funds to the payer's provider when the payee holds no account with it, with an explanation, and sets no deadline for doing so. Does not describe any sarie-specific return rule, ground or deadline." }, { "source_url": "https://www.saib.com.sa/en/sarie-service", "source_class": "secondary", "source_title": "The Saudi Investment Bank, SARIE Service page, saib.com.sa, read 2026-09-18", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the bank runs the account verification check before both a quick transfer and an add or activate beneficiary request, supporting the record's claim that account verification is meant to prevent the commonest cause of a return, a wrong account, before the payment is sent. Says nothing about a return message, ground or deadline for sarie itself." } ] }, "rail_name": "Saudi Arabia sarie (instant payments)", "governing_authority": "Saudi Central Bank (SAMA)", "snapshot": "2026-09-18", "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "not_public", "label": "the operator's own text", "needs": "what the operator's own text says, which Orca has not read", "detail": "Saudi Central Bank (SAMA)'s own text is not the source for this rail fact: it is not public, or not under terms Orca can use. It rests on 2 named public sources, so a term set by agreement rather than by a published rule is not Orca's to state.", "from": "currency.primary_not_public" } ] }, { "uid": "sa-sarie:settlement", "id": "settlement", "rail": "sa-sarie", "kind": "rail-fact", "facet": "settlement", "name": "How and in what money do participants settle with each other?", "statement": "No public text read says how sarie participants settle with each other: not whether each payment settles gross and at once or in net batches, not how often, and not what happens overnight and at weekends when the RTGS is closed. The one public statement on the point comes from a SAMA assistant governor, who credits the SARIE RTGS with settling for the Kingdom's other core payment systems, sarie among them. Read with SAMA's role as owner of the national systems, that points to settlement in central bank money across participants' accounts at SAMA [Inference], but the mechanism, timing and any prefunding or collateral rules sit in member documents that are not public.", "details": [ { "label": "The only public statement", "value": "A May 2025 article by SAMA's Assistant Governor for Executive Affairs counts five core national payment systems, one of them sarie and another the SARIE RTGS. It dates the RTGS to May 1997 and gives it two jobs: carrying large interbank transfers, and acting as the settlement system for the other four.", "citation": "A. A. Aldeheem, Saudi Central Bank: Driving Transformation in Digital Payments, International Banker, 2025-05-28, section on underlying payment infrastructure", "rests_on": "guidance" }, { "label": "What is not published", "value": "The settlement model (gross per payment, deferred net, or prefunded positions), the settlement cycle, how sarie settles while the RTGS is outside its business day, and any liquidity, prefunding or collateral requirement. The launch circular sends members to technical and operational documents and service level agreements shared by Saudi Payments, none of which is public.", "citation": "SAMA circular 42047169, Instant Payments Launch (SARIE), 2021-02-17 (1442-07-06 H), item 1; absence of any settlement description in the sarie and instant payment circulars found on rulebook.sama.gov.sa, searched 2026-09-18", "rests_on": "rule" }, { "label": "What the law requires of a designated system", "value": "If SAMA has designated sarie systemically important, its operating rules must cover every operation and function, naming among them default management, guarantees and security, clearing, settlement procedures and payment orders, and SAMA may demand whatever documents or reports it wants as proof the rules comply. Separately, and whether or not a system is designated, operators and providers must hold the funds they move for members and customers apart from their own.", "citation": "Law of Payments and Payment Services, Royal Decree M/26 of 1443-03-22 H (2021-10-28), arts. 8(2) and 10; Implementing Regulations, circular 44093096 of 2023-06-13 (1444-11-24 H), art. 115(4) and 115(5)", "rests_on": "law" }, { "label": "SAMA as owner of the national systems", "value": "In its 2015 SIPS criteria SAMA presented itself as the only body that owns and runs the Kingdom's payment systems, as well as the one that regulates them. Its 2026 oversight framework brings into scope the national payment system, which the Implementing Regulations define by SAMA's direct or indirect ownership or operation. Neither text describes sarie's settlement.", "citation": "SAMA, Criteria for Systemically Important Payment Systems in the Kingdom of Saudi Arabia, 2015-01-22 (1436-04-02 H), opening paragraph (English translation); SAMA Oversight Framework on Payment Systems and their Operators, circular 472047719 of 2026-03-08 (1447-09-19 H), art. 6 (Arabic original); Implementing Regulations, circular 44093096 of 2023-06-13 (1444-11-24 H), art. 1 (definition of National Payment System)", "rests_on": "law" } ], "exceptions": [ "A transfer above the single payment ceiling is carried by the ordinary local transfer route and settles on that system's terms, not sarie's.", "Whether sarie is designated systemically important, which decides whether the statutory settlement and finality duties apply to it, was not established [Unverified].", "If any non-bank provider takes part through a bank, it settles through that bank, not with the system [Inference: no access rule for non-banks was found]." ], "applies_to": "interbank settlement of sarie instant payments between participating Saudi banks", "caveat": "Do not state that sarie settles gross and in real time, or in net cycles; neither is public. A customer's money arriving in seconds says nothing about when the banks settle between themselves.", "related": [ "sa-sarie:finality", "sa-sarie:participants", "sa-sarie:hours" ], "basis": { "sources": "Signed article by SAMA's Assistant Governor for Executive Affairs in International Banker, 2025-05-28 (secondary: a trade journal, though the author is a SAMA official). SAMA rulebook portal, read 2026-09-18: launch circular 42047169; Law of Payments arts. 8 and 10; Implementing Regulations arts. 1 and 115; SIPS criteria (2015) (English translations, public_primary); Oversight Framework circular 472047719 (Arabic original). The portal's terms state it has no legal effect and that content circulated through SAMA's official channels governs. The settlement model is in member documents that are not public, and only one source speaks to it, hence primary_not_public and low. Nothing is quoted.", "confidence": "low" }, "currency": { "effective_since": "Unknown", "effective_note": "No public text dates sarie's settlement arrangements. The International Banker article is dated 2025-05-28; the Implementing Regulations 2023-06-13 (1444-11-24 H); the Oversight Framework 2026-03-08 (1447-09-19 H).", "source_edition": "International Banker article 2025-05-28; SAMA circular 42047169 (2021-02-17); Law of Payments M/26 (2021-10-28); Implementing Regulations circular 44093096 (2023-06-13); SIPS criteria (2015-01-22); Oversight Framework circular 472047719 (2026-03-08)", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "primary_not_public": true, "corroboration": [] }, "rail_name": "Saudi Arabia sarie (instant payments)", "governing_authority": "Saudi Central Bank (SAMA)", "snapshot": "2026-09-18", "source_class": null, "effective_status": "draft", "effective_status_reason": null, "boundaries": [ { "kind": "not_public", "label": "the operator's own text", "needs": "what the operator's own text says, which Orca has not read", "detail": "Saudi Central Bank (SAMA)'s own text is not the source for this rail fact: it is not public, or not under terms Orca can use. It rests on 0 named public sources, so a term set by agreement rather than by a published rule is not Orca's to state.", "from": "currency.primary_not_public" } ] }, { "uid": "sepa-sct:consumer-law", "id": "consumer-law", "rail": "sepa-sct", "kind": "rail-fact", "facet": "consumer-law", "name": "What consumer law applies, and what does it give a consumer that the rules do not?", "statement": "The rulebook binds banks to each other and gives a customer nothing directly. Everything a consumer can rely on comes from two EU instruments the rulebook points at: the Payment Services Directive, as each Member State transposed it, for authorisation, execution and liability, and the SEPA Regulation for reach and for the right not to be told which country to bank in. The practical additions over the scheme are a refund for an unauthorised payment, a liability rule for a payment that failed or came late, a loss cap of EUR 50 on a stolen instrument, and a thirteen month window to complain.", "details": [ { "label": "Which instruments the rulebook names", "value": "Participation is conditional on complying with the SEPA Regulation, the Regulation on information accompanying transfers of funds, and Titles III and IV of the Payment Services Directive as they affect credit transfers made under this scheme.", "citation": "EPC125-05 SCT Rulebook 2025 v1.1 (effective 2025-10-05), section 5.1", "rests_on": "rule" }, { "label": "The rulebook gives a customer no rights", "value": "The rulebook is a contract among the EPC and the Participants. Anyone who is not a party to it takes neither rights nor obligations from it, and a customer is not a party. A customer's claim therefore runs on its own contract with its bank and on law, never on the rulebook.", "citation": "EPC125-05 SCT Rulebook 2025 v1.1, section 5.2", "rests_on": "rule" }, { "label": "Who counts as a consumer", "value": "A natural person who is not acting for business or professional purposes when it contracts for payment services. A sole trader paying a supplier is not one; the same person paying a plumber at home is.", "citation": "Regulation (EU) No 260/2012, Article 2 point (24)", "rests_on": "law" }, { "label": "What the law gives that the scheme does not: an unauthorised payment", "value": "A refund at once, and by the end of the next business day at the latest after the bank learns of the claim, with the account put back as it would have been and the value date no earlier than the debit. The bank carries the burden of proving the payment was properly authenticated and recorded, and the fact an instrument was used does not discharge it.", "citation": "Directive (EU) 2015/2366, Articles 72 and 73(1)", "rests_on": "law" }, { "label": "What the law gives that the scheme does not: a cap on the consumer's own loss", "value": "Where an unauthorised payment came from a lost, stolen or misappropriated instrument, the consumer's exposure stops at EUR 50. Fraud, or gross negligence in protecting credentials, removes that protection.", "citation": "Directive (EU) 2015/2366, Article 74(1)", "rests_on": "law" }, { "label": "What the law gives that the scheme does not: a failed or late payment", "value": "The payer's bank answers for correct execution unless it proves the receiving bank got the money on time, and the liable bank refunds or credits without undue delay and corrects the value date. Charges and interest the customer suffered come back too, and either bank must trace the payment on request, free of charge.", "citation": "Directive (EU) 2015/2366, Article 89", "rests_on": "law" }, { "label": "The complaint window", "value": "Thirteen months from the debit, and promptly once the customer knows. Where the bank never gave the customer the transaction information it owed, that limit does not run at all.", "citation": "Directive (EU) 2015/2366, Article 71(1)", "rests_on": "law" }, { "label": "What the SEPA Regulation adds", "value": "Reach, and the right not to be steered. A bank reachable for a domestic credit transfer has to be reachable for one sent from any Member State, and neither a payer nor a payee may be told which Member State the other account has to sit in.", "citation": "Regulation (EU) No 260/2012, Articles 3(1) and 9", "rests_on": "law" }, { "label": "What the scheme makes banks tell customers", "value": "Both sides owe their own customers adequate information about the risks, about who is responsible for what between the four parties including under the applicable legislation, about the service level, and about the charges. The sending side also owes its customers its cut-off times per channel and an explanation of any rejection.", "citation": "EPC125-05 SCT Rulebook 2025 v1.1, section 5.7 points 10, 14 and 25, and section 5.8 point 19", "rests_on": "rule" }, { "label": "Where verification of payee fits", "value": "It is a duty on the banks, not a right the rulebook grants a customer: a sending PSP processes a transfer only after running the check where law requires it, and a receiving PSP has to answer such a check. In law the service is free to every customer, and the customer has to be told what ignoring a mismatch warning does to the bank's liability and to its own refund rights.", "citation": "EPC125-05 SCT Rulebook 2025 v1.1, section 5.7 point 4 and section 5.8 point 6; Regulation (EU) No 260/2012 as amended by Regulation (EU) 2024/886, Articles 5b(2) and 5c(7)", "rests_on": "law" } ], "exceptions": [ "The rulebook warns that its own defined terms do not always carry the meaning the Payment Services Directive or the SEPA Regulation give the same or similar words. A rulebook term is not a legal term (EPC125-05 2025 v1.1, section 0.1.1).", "The Directive is a directive, not a regulation, so what a consumer actually holds is the national transposition in its own Member State, which can differ in detail. [Unverified: no national transposition was read for this record.]", "Non-consumer customers can be treated differently by agreement on several of these points. [Unverified: Article 61 of Directive (EU) 2015/2366, which sets out what may be disapplied for non-consumers, was not read for this record.]", "Outside the EEA, SEPA scheme countries including the United Kingdom and Switzerland are not bound by the Directive or the SEPA Regulation. Participants there take on obligations the rulebook calls substantially equivalent, as far as their own law allows (EPC125-05 2025 v1.1, section 5.14).", "A consumer that gave the wrong IBAN gets no consumer-law rescue. The payment counts as correctly executed towards whoever owns that account, and the bank owes only a genuine recovery attempt, for which it may charge if the framework contract says so (Directive (EU) 2015/2366, Article 88).", "The eight week unconditional refund consumers know from SEPA Direct Debit does not exist here. It is written for transactions the payee started (Directive (EU) 2015/2366, Articles 76 and 77)." ], "applies_to": "a consumer payer or payee on a SEPA Credit Transfer whose account is held in an EEA Member State, with the national transposition of the Payment Services Directive applying to it", "caveat": "Consumer protection on this rail is thinner than on a card or a direct debit, and the reason is structural: the consumer authorised the payment and gave the identifier. The law protects it well where somebody else moved the money, and barely at all where it moved the money itself for a bad reason. The honest answer to a consumer asking to undo a SEPA Credit Transfer is that the bank can ask, and the other side can refuse.", "related": [ "sepa-sct:finality", "sepa-sct:liability", "sepa-sct:refund", "sepa-sct:limits", "sepa-sct:participants", "sepa-sct:decision-points" ], "basis": { "sources": "EPC125-05 SEPA Credit Transfer Scheme Rulebook 2025 version 1.1 (effective 2025-10-05, marked Public), read for this record: sections 0.1.1, 1.8, 5.1, 5.2, 5.7 points 4, 10, 14 and 25, 5.8 points 6 and 19, and 5.14. Directive (EU) 2015/2366 consolidated 2024-04-08, Articles 71, 72, 73, 74(1), 76, 77, 88 and 89, and Regulation (EU) No 260/2012 (Article 2 point (24), Articles 3 and 9) as amended by Regulation (EU) 2024/886 (Articles 5b(2) and 5c(7)), all read on EUR-Lex for this record.", "confidence": "high" }, "currency": { "effective_since": "2025-10-05", "effective_note": "The 2025 SCT rulebook was issued and took effect on 2025-10-05, and Annex IV records that its verification of payee obligations were added in this edition to answer Article 5c of the amended SEPA Regulation. The Directive's consumer provisions date from 2015 as nationally transposed. The successor payment services package was not read for this record, so what may change is [Unverified].", "source_edition": "EPC125-05 SCT Scheme Rulebook 2025 version 1.1 (2025-10-05); Directive (EU) 2015/2366 consolidated 2024-04-08; Regulation (EU) No 260/2012 as amended by Regulation (EU) 2024/886", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "rail_name": "SEPA Credit Transfer", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": null, "effective_status": "draft", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sct:decision-points", "id": "decision-points", "rail": "sepa-sct", "kind": "rail-fact", "facet": "decision-points", "name": "Where does the rail stop and a human decide?", "statement": "Six places in the SCT flow where the rulebook stops prescribing and hands the outcome to a bank or a person. Whether a beneficiary agrees to give money back, and in some countries whether its bank even has to ask. Whether a sending bank accepts its own customer's recall request. Whether a receiving bank charges for saying yes. What a bank's cut-off is and what limits it puts on its customers. Whether an inquiry fee is billed. And, under the law rather than the scheme, whether a customer's claim that it did not authorise a payment is believed. Each line below names the provision that leaves the decision open.", "details": [ { "label": "The beneficiary's consent to give money back", "value": "The scheme's central discretion. On a Request for Recall, the beneficiary PSP puts the reason to its customer for consideration, and the rulebook says outright that getting the funds back turns on that customer's consent. A refusal is one of the listed negative answers.", "citation": "EPC125-05 SCT Rulebook 2025 v1.1 (effective 2025-10-05), section 4.3.2.4 and step 3, with CT-02.03R", "rests_on": "rule" }, { "label": "Whether the bank has to ask at all", "value": "On a Recall with the money still on the account, the receiving PSP has three possible positions depending on its national law and its account contract: debit and answer yes immediately, judge that it ought to ask the customer, or be obliged to obtain the customer's authorisation. The rulebook sets none of the three; it lists them.", "citation": "EPC125-05 SCT Rulebook 2025 v1.1, process steps CT-02.03 and CT-02.03A", "rests_on": "rule" }, { "label": "Whether the sending bank passes the request on", "value": "It may turn its own customer down where it judges the case does not fit one of the three Recall grounds, or where the window has closed. The same judgement applies to a Request for Recall that falls outside thirteen months or comes with no reason given.", "citation": "EPC125-05 SCT Rulebook 2025 v1.1, process step CT-02.01R and section 4.3.2.4 step 1", "rests_on": "rule" }, { "label": "Whether the receiving bank charges for a yes", "value": "Left to it entirely. A fee may be attached to a positive answer on a Recall or a Request for Recall, only to a positive answer, and only in those two procedures. No maximum appears anywhere in the rulebook.", "citation": "EPC125-05 SCT Rulebook 2025 v1.1, sections 4.3.2.3 and 4.3.2.4 step 4A", "rests_on": "rule" }, { "label": "Whether an inquiry fee or compensation is claimed", "value": "Also left to it. A receiving PSP may charge a handling fee for a positive answer to a claim of non-receipt or a value date claim, and where it was not the cause of a wrong value date it may claim interest as well, or may ask for payment before it corrects the date, or may correct the date first and bill later.", "citation": "EPC125-05 SCT Rulebook 2025 v1.1, section 4.4.2", "rests_on": "rule" }, { "label": "What a bank's own cut-off and limits are", "value": "The rulebook works in whole days and says cut-off times are outside its scope, leaving them to each PSP and its CSM. Value limits on a customer's products are set by the sending PSP on its own risk appetite, and settlement and value limits between banks come through their CSMs.", "citation": "EPC125-05 SCT Rulebook 2025 v1.1, sections 2.5 and 4.2.2", "rests_on": "rule" }, { "label": "Whether a rejected instruction is repaired", "value": "The sending PSP decides whether it is able and willing to repair and resend inside the execution time. If it does not, it has to tell its customer and put the money back. Nothing makes it repair anything.", "citation": "EPC125-05 SCT Rulebook 2025 v1.1, process step CT-01.03R", "rests_on": "rule" }, { "label": "Whether a fraud warning is acted on", "value": "On a fraud Recall the sending PSP may attach free text explaining the case, and the rulebook states plainly that receiving PSPs are under no duty to act on it. The equivalent field on a Request for Recall is the opposite: there the receiving PSP is obliged to act on what it says.", "citation": "EPC125-05 SCT Rulebook 2025 v1.1, section 4.6.1 attributes AT-R052 and AT-R073", "rests_on": "rule" }, { "label": "Whether a customer's denial is accepted", "value": "Under law rather than the scheme. Where a customer denies authorising a payment, its bank has to prove the transaction was authenticated, accurately recorded, properly booked and unaffected by any technical failure of its own, and the record of an instrument being used does not settle it. Refusing the refund on a suspicion of fraud is a decision the bank has to justify in writing to its national authority.", "citation": "Directive (EU) 2015/2366, Articles 72 and 73(1)", "rests_on": "law" }, { "label": "Whether a mismatch warning stops a payment", "value": "The customer's decision, and the law protects it. A payee verification service must not prevent the payer from authorising the transfer anyway, and the bank has to have explained beforehand what going ahead does to its liability and to the customer's refund rights.", "citation": "Regulation (EU) No 260/2012 as amended by Regulation (EU) 2024/886, Article 5c(5) and (7)", "rests_on": "law" } ], "exceptions": [ "Some of these are not really discretions in every country. Whether a receiving PSP may debit a customer without asking is fixed by national law and the account contract, so the same Recall is automatic in one Member State and a customer decision in another (EPC125-05 2025 v1.1, CT-02.03).", "The scheme constrains the discretion it grants in one direction only: the answer is compulsory even where the outcome is not. Fifteen Banking Business Days on a Recall or a Request for Recall, ten on an inquiry, and a receiving PSP that does not answer is in breach (EPC125-05 2025 v1.1, sections 4.3.2.3, 4.3.2.4 and 4.4.2).", "A negative answer is not free text. It has to carry one of the listed reasons, so a refusal is at least classified even when it is not explained (EPC125-05 2025 v1.1, CT-02.03R and AT-R057).", "The Return is deliberately not a discretion. Where the account cannot be credited the receiving PSP owes the money back inside three Banking Business Days, and no one is asked (EPC125-05 2025 v1.1, section 4.3.2.2).", "This list is Orca's reading of where the rulebook leaves judgement open. It is not an EPC list, and the EPC publishes none." ], "applies_to": "points in the SEPA Credit Transfer flow where the rulebook or the applicable law leaves the outcome to a Participant or to a payment service user rather than prescribing it", "caveat": "The honest summary for anyone building on this rail is that the scheme guarantees process, not outcome. Every deadline in it is a deadline to answer. None of them is a deadline to pay. An automated flow can be designed around the answering deadlines; it cannot be designed around the answers.", "related": [ "sepa-sct:finality", "sepa-sct:recall", "sepa-sct:refund", "sepa-sct:liability", "sepa-sct:consumer-law", "sepa-sct:limits", "sepa-sct:hours" ], "basis": { "sources": "EPC125-05 SEPA Credit Transfer Scheme Rulebook 2025 version 1.1 (effective 2025-10-05, marked Public), read for this record: sections 2.5, 4.2.2, 4.3.2.1 with CT-01.03R, 4.3.2.2, 4.3.2.3 with CT-02.01R, CT-02.03, CT-02.03A and CT-02.03R, 4.3.2.4 with steps 1, 3 and 4A, 4.4.2, and 4.6.1 (AT-R052, AT-R057, AT-R073). Directive (EU) 2015/2366 consolidated 2024-04-08, Articles 72 and 73, and Regulation (EU) No 260/2012 as amended by Regulation (EU) 2024/886, Article 5c(5) and (7), read on EUR-Lex.", "confidence": "medium" }, "currency": { "effective_since": "2025-10-05", "effective_note": "Every provision cited is in the 2025 SCT rulebook, issued and effective 2025-10-05, except the two law-based lines. The reading of these provisions as decision points is Orca's, made for this record, and the facet caps at medium confidence for that reason.", "source_edition": "EPC125-05 SCT Scheme Rulebook 2025 version 1.1 (2025-10-05); Directive (EU) 2015/2366 consolidated 2024-04-08; Regulation (EU) No 260/2012 as amended by Regulation (EU) 2024/886", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-09/EPC125-05%202025%20SCT%20Rulebook%20version%201.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC125-05 SCT Scheme Rulebook 2025 version 1.1", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the beneficiary consent discretion on RFRO (4.3.2.4 step 3, CT-02.03R), the three national-law-dependent postures on a Recall (CT-02.03, CT-02.03A), the sending PSP's own gatekeeping of recall grounds and windows (CT-02.01R, 4.3.2.4 step 1), the uncapped optional fee on a positive Recall or RFRO answer (4.3.2.3, 4.3.2.4 step 4A), the optional inquiry fee and compensation timing choices (4.4.2), cut-off times and value limits left to PSPs and CSMs (2.5, 4.2.2), the repair-or-return choice on a rejected instruction (CT-01.03R), and the AT-R052 not-obliged versus AT-R073 obliged asymmetry on fraud warnings (4.6.1). Does not independently confirm Directive 2015/2366 Articles 72 or 73(1), or Regulation 260/2012 Article 5c(5) and (7) as amended by 2024/886; EUR-Lex remains unreachable." } ] }, "rail_name": "SEPA Credit Transfer", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sct:finality", "id": "finality", "rail": "sepa-sct", "kind": "rail-fact", "facet": "finality", "name": "When does a SEPA Credit Transfer become final, and can it be reversed?", "statement": "A SEPA Credit Transfer is final between the two PSPs when the CSM settles it, and the scheme gives the sending side no way to reverse a settled transfer. Finality here has layers. The payer's own order stops being revocable under payment services law the moment its PSP has it. Settlement then clears the debt between the originator PSP and the beneficiary PSP. Even after that the beneficiary PSP may still send the money back as a Return, for a closed set of reasons, inside three Banking Business Days. Past that point only a Recall or a Request for Recall by the Originator is left, and both can be turned down.", "details": [ { "label": "What settlement is in this scheme", "value": "The rulebook's own glossary treats settlement as the point where the debt between the two PSPs is cleared, and the Settlement Date as the day that happens. Nothing about the customer's account is part of the definition.", "citation": "EPC125-05 SCT Rulebook 2025 v1.1 (issued and effective 2025-10-05), chapter 7 Defined Terms, entries Settlement and Settlement Date", "rests_on": "rule" }, { "label": "The scheme does not settle anything itself", "value": "Rules and infrastructure are kept apart on purpose. Each Participant picks its own CSM, and that CSM is the one that clears, forwards, handles the exception traffic and arranges for the two PSPs to settle.", "citation": "EPC125-05 SCT Rulebook 2025 v1.1, sections 1.5 and 3.3", "rests_on": "rule" }, { "label": "When the payer loses the right to revoke", "value": "Once the order is in the hands of the payer's PSP, the customer can no longer take it back. A future dated order is the one case with room left, and only until the close of the previous business day. Later than that, everyone involved has to agree, and where the payee started the transaction the payee has to agree too.", "citation": "Directive (EU) 2015/2366 (PSD2), consolidated text of 2024-04-08 on EUR-Lex, Article 80(1), (4) and (5)", "rests_on": "law" }, { "label": "When the money has to arrive", "value": "One Banking Business Day from receipt of the instruction to the beneficiary PSP's account. The rulebook states the deadline and attributes it to the Payment Services Directive, which sets the end of the next business day and allows one extra day when the order came in on paper.", "citation": "EPC125-05 SCT Rulebook 2025 v1.1, section 4.2.3; Directive (EU) 2015/2366, Article 83(1)", "rests_on": "law" }, { "label": "First exit after settlement: the Return", "value": "Where the beneficiary PSP cannot post the money to an account using what the message gave it, a wrong or closed account being the usual cause, it sends the transfer back. Three Banking Business Days from the Settlement Date, funds and message together.", "citation": "EPC125-05 SCT Rulebook 2025 v1.1, section 4.3.2.2 and process step CT-01.04R", "rests_on": "rule" }, { "label": "A credited beneficiary who wants to give the money back does not use a Return", "value": "Once the money is on the beneficiary's account, that door closes. A beneficiary who has second thoughts sends a fresh SEPA Credit Transfer back to the originator, which is a new payment with its own reference and its own execution time.", "citation": "EPC125-05 SCT Rulebook 2025 v1.1, section 4.3.2.2", "rests_on": "rule" }, { "label": "Second exit: a request the other side may refuse", "value": "Two request procedures survive the Return window. The originator PSP can raise a Recall, but only for a duplicate, a technical fault of its own, or fraud. Anything else the customer complains about goes as a Request for Recall by the Originator. Fifteen Banking Business Days to answer, and no is a permitted answer, including because the beneficiary said so.", "citation": "EPC125-05 SCT Rulebook 2025 v1.1, sections 4.3.2.3 and 4.3.2.4, with process steps CT-02.03R and step 4B", "rests_on": "rule" }, { "label": "A refusal closes the matter inside the scheme", "value": "Where the beneficiary turns down a Request for Recall, the rulebook treats that answer as settling what becomes of the original transfer for both PSPs. Neither procedure can be run twice on the same transaction.", "citation": "EPC125-05 SCT Rulebook 2025 v1.1, section 4.3.2.4, step 4B, and the single-request bullets in sections 4.3.2.3 and 4.3.2.4", "rests_on": "rule" }, { "label": "Finality does not decide who bears a loss", "value": "Law treats the IBAN as the whole of the instruction: pay that account and the payment counts as correct towards the person it belongs to. A customer who gave the wrong IBAN loses the non-execution claim, though its PSP still owes it a real attempt at recovery and the other PSP owes cooperation. Fault for a payment that failed, arrived late or arrived wrong is settled under those articles, not by the moment of settlement.", "citation": "Directive (EU) 2015/2366, Articles 88(1) to 88(3) and 89", "rests_on": "law" } ], "exceptions": [ "Before settlement there is nothing final to argue about. A Reject ends the transfer in the inter-PSP space and the originator gets its account put back (EPC125-05 2025 v1.1, section 4.3.2.1 and CT-01.03R).", "A Recall raised before the transaction settles never reaches the beneficiary PSP as a request. The CSM cancels it under whatever procedure it has agreed with its own participants (EPC125-05 2025 v1.1, section 4.3.2.3 and CT-02.02).", "Insolvency-law finality is a separate question, answered by Directive 98/26/EC and by each designated system's own rules rather than by this rulebook. [Unverified: Directive 98/26/EC was not read for this record, and CSM rulebooks are participant-only.]", "Unauthorised transactions sit outside all of this. The payer's PSP owes a refund at once, and by the next business day at the latest after it learns of the claim, unless it has grounds to suspect fraud and reports them to its national authority (Directive (EU) 2015/2366, Article 73(1)).", "Outside the EEA the Directive does not bite directly. Participants there take on obligations the rulebook describes as substantially equivalent to Titles III and IV, as far as their own law lets them (EPC125-05 2025 v1.1, section 5.14).", "A rejected instruction can be fixed and sent again inside the execution time. The scheme treats the repaired instruction as a brand new one, so its clock restarts (EPC125-05 2025 v1.1, CT-01.03R)." ], "applies_to": "SEPA Credit Transfers in euro between payment accounts of an Originator and a Beneficiary located in the countries listed in the EPC List of SEPA Scheme Countries, executed under the EPC SCT scheme", "caveat": "Do not read \"final\" as \"the money cannot come back\". On SCT it can come back three ways: a Return by the beneficiary PSP inside three Banking Business Days, a positive response to a Recall or a Request for Recall, and a fresh SCT sent by the beneficiary. Only the first is an obligation on the beneficiary PSP, and it exists only where the account could not be credited. Everything else depends on someone agreeing.", "related": [ "sepa-sct:settlement", "sepa-sct:hours", "sepa-sct:return", "sepa-sct:recall", "sepa-sct:refund", "sepa-sct:liability", "sepa-sct:consumer-law", "sepa-sct:decision-points" ], "basis": { "sources": "EPC125-05 SEPA Credit Transfer Scheme Rulebook 2025 version 1.1, issued and effective 2025-10-05 (marked Public), read for this record: sections 1.5 (separation of scheme from infrastructure), 3.3 (CSMs), 4.2.3 (maximum execution time), 4.3.1 and 4.3.2 (processing and exception flows, including CT-01.03R and CT-01.04R), 4.3.2.1 (Reject), 4.3.2.2 (Return), 4.3.2.3 (Recall), 4.3.2.4 (Request for Recall by the Originator), 5.14 (application of EU legislation between Participants), chapter 7 (defined terms Settlement, Settlement Date, Banking Business Day). Directive (EU) 2015/2366 (PSD2), consolidated text of 2024-04-08, read on EUR-Lex for this record: Articles 73, 78, 80, 83, 87, 88 and 89.", "confidence": "high" }, "currency": { "effective_since": "2025-10-05", "effective_note": "The 2025 SCT rulebook was issued and took effect on 2025-10-05. Version 1.1 changed only the date from which the unstructured address format stops being permitted, moving it from 22 November 2026 to 15 November 2026. The Return, Recall and Request for Recall provisions cited here are older than this edition; the date each first took effect is [Unverified] because earlier editions were not read. The next SCT rulebook is due for publication in November 2026 and effect in November 2027.", "source_edition": "EPC125-05 SCT Scheme Rulebook 2025 version 1.1 (2025-10-05); Directive (EU) 2015/2366 consolidated 2024-04-08", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-09/EPC125-05%202025%20SCT%20Rulebook%20version%201.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC125-05 SCT Scheme Rulebook 2025 version 1.1", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms settlement and settlement date definitions (chapter 7), scheme-infrastructure separation (section 1.5) and CSM role (section 3.3), one banking business day maximum execution time attributed to PSD2 (section 4.2.3), Reject before settlement next banking business day (4.3.2.1), Return by beneficiary PSP within three banking business days of settlement date and that a credited beneficiary must send a fresh SCT instead (4.3.2.2), Recall limited to duplicate, technical fault or fraud within 10 banking business days or 13 months for fraud with a 15 banking business day beneficiary PSP response window and one recall per transaction (4.3.2.3), Request for Recall by the Originator within 13 months with a 15 banking business day response window, one RFRO per transaction, and that the beneficiary's refusal finalises the matter for both PSPs (4.3.2.4), and application of EU legislation between participants outside the EEA (5.14). Does not independently confirm PSD2 Article 80 revocation timing, Article 73 unauthorised-transaction refund timing, or Articles 88 and 89 liability rules; EUR-Lex remains unreachable (HTTP 202 automated-access challenge on a plain compressed GET), consistent with the rail brief's prior finding." } ] }, "rail_name": "SEPA Credit Transfer", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sct:hours", "id": "hours", "rail": "sepa-sct", "kind": "rail-fact", "facet": "hours", "name": "When is the rail open, and what clock do its deadlines run on?", "statement": "SCT runs on Banking Business Days, which the rulebook pins to T2 days. Every inter-PSP deadline counts in them, from the one day execution time to the three day Return window to the fifteen day answer on a Recall, and a duty landing on any other day slides to the next one. Cut-off times exist but belong to each PSP and each CSM, and the rulebook says so in as many words. Two of the scheme's own windows do not count in business days at all: the fraud Recall and the Request for Recall by the Originator run for 13 months.", "details": [ { "label": "The unit of time", "value": "A Banking Business Day is a T2 day. That unit covers the inter-PSP leg of the payment and of every R-transaction and inquiry that follows it.", "citation": "EPC125-05 SCT Rulebook 2025 v1.1 (effective 2025-10-05), chapter 7 Defined Terms, entry Banking Business Day", "rests_on": "rule" }, { "label": "Why the scheme counts in those days", "value": "Banks are not open every day of the year for this work, so the rulebook measures the execution cycle in those days rather than calendar days. A duty falling due on a closed day is performed on the next open one, and the maximum execution time is read the same way.", "citation": "EPC125-05 SCT Rulebook 2025 v1.1, section 4.2.3", "rests_on": "rule" }, { "label": "When the clock starts", "value": "At the point of receipt of the instruction, which the rulebook leaves to the Payment Services Directive to define. In law that is when the payer's PSP has the order; an order arriving on a non-business day counts as arriving the next one, and a PSP may declare a late-in-the-day cut-off with the same effect.", "citation": "EPC125-05 SCT Rulebook 2025 v1.1, section 4.2.1; Directive (EU) 2015/2366, Article 78(1)", "rests_on": "law" }, { "label": "A future dated instruction", "value": "Where the customer asks for a later Requested Execution Date, that date becomes the starting point, and the rulebook points at Article 78(2) for how to read it. The customer keeps the right to pull the order until the close of the business day before.", "citation": "EPC125-05 SCT Rulebook 2025 v1.1, section 4.2.1; Directive (EU) 2015/2366, Articles 78(2) and 80(4)", "rests_on": "law" }, { "label": "Cut-off times are not scheme rules", "value": "A sending PSP has to tell its customers its cut-off, and it agrees another with its CSM, but the rulebook puts both outside its own scope. It works in whole days and leaves hours and minutes to Participants and CSMs.", "citation": "EPC125-05 SCT Rulebook 2025 v1.1, section 4.2.2 and chapter 7 Defined Terms entry Cut-off Time", "rests_on": "rule" }, { "label": "The deadlines, in Banking Business Days", "value": "One day to get the money to the beneficiary PSP's account. Reject, same day if possible and next day at the outside. Return, three days from the Settlement Date. Recall for a duplicate or a technical fault, ten days from the execution date. Answer to a Recall or a Request for Recall, fifteen days from receipt. Answer to an SCT inquiry, ten days from receipt.", "citation": "EPC125-05 SCT Rulebook 2025 v1.1, sections 4.2.3, 4.3.2.1, 4.3.2.2 with CT-01.04R, 4.3.2.3, 4.3.2.4 and 4.4.2", "rests_on": "rule" }, { "label": "The windows that are not in business days", "value": "Thirteen months, three times over. A fraud Recall reaches back that far from the execution date. A Request for Recall needs the original debit to fall inside the thirteen months before the sending PSP got the customer's request. An inquiry about non-receipt or a value date reaches back the same distance.", "citation": "EPC125-05 SCT Rulebook 2025 v1.1, sections 4.3.2.3, 4.3.2.4 step 1 and 4.4.1", "rests_on": "rule" }, { "label": "The thirteen months are not a coincidence", "value": "Law gives a customer thirteen months from the debit to raise an unauthorised or badly executed transaction, and requires it to speak up promptly once it knows. That limit falls away where the PSP never gave the customer the transaction information it owed.", "citation": "Directive (EU) 2015/2366, Article 71(1)", "rests_on": "law" }, { "label": "Communities may go faster", "value": "Groups of Participants are free to promise each other a shorter execution time. What they agree binds them and not the scheme.", "citation": "EPC125-05 SCT Rulebook 2025 v1.1, section 4.2.3", "rests_on": "rule" } ], "exceptions": [ "T2 days are named but not listed. Which calendar days are closed has to come from the Eurosystem. [Unverified: no Eurosystem calendar was read for this record.]", "A national holiday can change what a bank does for its own customers without touching the inter-PSP calendar, because the scheme's duty is measured against T2. [Inference from section 4.2.3; the rulebook does not address national holidays directly.]", "Paper-initiated payments get one more business day in law. The rulebook covers electronic inter-PSP traffic only and leaves that extra day between each Participant and its customers (EPC125-05 2025 v1.1, section 4.2.3 footnote 6; Directive (EU) 2015/2366, Article 83(1)).", "Law can stop the clock. The rulebook allows for the execution cycle being interrupted or halted by legal requirements, sanctions screening being the obvious case (EPC125-05 2025 v1.1, section 4.2.1).", "The one day rule cannot be contracted away here. The Directive's execution-time section applies to euro payments by its own scope provision, and the four business day maximum that parties may agree is available only outside that scope, which SCT is not (Directive (EU) 2015/2366, Article 82(1)(a) and 82(2))." ], "applies_to": "the inter-PSP timing of SEPA Credit Transfers and of the Rejects, Returns, Recalls, Requests for Recall and SCT inquiries that go with them", "caveat": "Two clocks matter and they are not the same. The scheme's clock runs in T2 days between PSPs. The customer's clock runs in the PSP's own business days and its own cut-off, which the scheme deliberately does not set. A payment submitted after a bank's cut-off on a Friday has not broken any scheme deadline; it simply has not been received yet.", "related": [ "sepa-sct:finality", "sepa-sct:settlement", "sepa-sct:return", "sepa-sct:recall", "sepa-sct:messages", "sepa-sct:decision-points" ], "basis": { "sources": "EPC125-05 SEPA Credit Transfer Scheme Rulebook 2025 version 1.1 (effective 2025-10-05, marked Public), read for this record: sections 4.2.1 (commencement of the execution time cycle), 4.2.2 (cut-off times), 4.2.3 (maximum execution time and Banking Business Days, with footnote 6), 4.3.2.1 to 4.3.2.4 (Reject, Return, Recall, Request for Recall deadlines), 4.4.1 and 4.4.2 (SCT inquiry reach and response deadline), chapter 7 (Banking Business Day, Cut-off Time). Directive (EU) 2015/2366 consolidated 2024-04-08, Articles 71(1), 78, 80(4), 82 and 83(1), read on EUR-Lex.", "confidence": "high" }, "currency": { "effective_since": "2025-10-05", "effective_note": "The 2025 SCT rulebook was issued and took effect on 2025-10-05. Annex IV to that edition records a change of TARGET2 into T2 in the Banking Business Day definition, which is a renaming of the Eurosystem service rather than a change of which days count [Inference]. The 2026 change request consultation EPC008-26 proposes a longer recall timeline for the duplicate and technical recall reasons for the 2027 rulebook; nothing is adopted.", "source_edition": "EPC125-05 SCT Scheme Rulebook 2025 version 1.1 (2025-10-05); Directive (EU) 2015/2366 consolidated 2024-04-08", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-09/EPC125-05%202025%20SCT%20Rulebook%20version%201.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC125-05 SCT Scheme Rulebook 2025 version 1.1", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms Banking Business Day defined as a T2 day (chapter 7), execution cycle commencing at receipt per PSD2 with the Requested Execution Date tied to Article 78(2) and the execution cycle interruptible by law (4.2.1), cut-off times left to PSPs and CSMs and out of scope (4.2.2, chapter 7 Cut-off Time), the one/three/ten/fifteen banking business day deadlines (4.2.3, 4.3.2.1-4.3.2.4), the 13 month fraud recall, RFRO and SCT inquiry reach-back windows (4.3.2.3, 4.3.2.4, 4.4.1), and that communities may agree a shorter execution time (4.2.3). Does not independently confirm Directive 2015/2366 Articles 71(1), 78(1), 78(2) or 80(4); EUR-Lex remains unreachable." } ] }, "rail_name": "SEPA Credit Transfer", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sct:liability", "id": "liability", "rail": "sepa-sct", "kind": "rail-fact", "facet": "liability", "name": "Who bears the loss when a payment goes wrong?", "statement": "Two layers, and they answer different questions. Between the two banks the rulebook is a contract: a Participant that breaks it, or is negligent, or has an operational failure, owes the other Participant its foreseeable losses, capped at the amount of the transfer even where the negligence was gross. Between a bank and its own customer the rulebook is silent and payment services law governs, which puts the loss on the PSPs for a payment that failed, arrived late or was never authorised, and on the customer for a wrong IBAN. Neither layer answers for a customer who was tricked into paying.", "details": [ { "label": "What makes one Participant liable to another", "value": "Three triggers, all limited to the transfer the two of them are party to: breaking the rulebook, a negligent act or omission, and an operational failure, by the Participant itself, its staff or its agents. What it owes is the other side's foreseeable losses, costs, damages, expenses including reasonable legal fees, taxes and claim liabilities.", "citation": "EPC125-05 SCT Rulebook 2025 v1.1 (effective 2025-10-05), section 5.9.1", "rests_on": "rule" }, { "label": "The cap, and what it survives", "value": "Nothing above the amount of the transfer itself, and that ceiling holds even against gross negligence. Only deliberate wrongdoing by the Participant or its people breaks it. A claimant that contributed to its own loss sees the ceiling cut proportionately.", "citation": "EPC125-05 SCT Rulebook 2025 v1.1, section 5.9.2 points 1 to 4", "rests_on": "rule" }, { "label": "What cannot be claimed at all", "value": "Losses that came out of a Participant's own risk management action, and any loss that is not foreseeable. The rulebook's test for foreseeable is narrow: it has to be the kind of loss Participants active in cross border SEPA payments meet regularly.", "citation": "EPC125-05 SCT Rulebook 2025 v1.1, section 5.9.2 points 5 and 6", "rests_on": "rule" }, { "label": "Outsourcing does not move the liability", "value": "A Participant may run the work itself, use an intermediary, or outsource all of it, and remains answerable under the rulebook either way. Using a CSM or an intermediary PSP is at the Participant's own risk, and it has to keep those arrangements consistent with the rulebook.", "citation": "EPC125-05 SCT Rulebook 2025 v1.1, sections 1.4 and 5.3", "rests_on": "rule" }, { "label": "Force majeure, and the EPC's own position", "value": "Circumstances beyond a Participant's control excuse a failure, a delay or a partial performance, with acts of God, crime, fire, flood and loss of energy supply given as examples. The EPC itself answers for nothing done or left undone in exercising a discretion unless bad faith is shown, and never for unforeseeable losses.", "citation": "EPC125-05 SCT Rulebook 2025 v1.1, sections 5.9.3 and 5.10", "rests_on": "rule" }, { "label": "Who the contract binds", "value": "The rulebook is a multilateral agreement between the EPC and each Participant, and between every Participant and every other. Anyone outside it, a customer included, gets no rights and no obligations from it. That is why a customer's claim never runs on the rulebook.", "citation": "EPC125-05 SCT Rulebook 2025 v1.1, section 5.2", "rests_on": "rule" }, { "label": "The customer layer: a payment that failed", "value": "The payer's PSP answers to the payer for correct execution unless it can show the receiving PSP got the money on time, in which case that PSP answers to the payee. The liable PSP refunds or credits without undue delay and puts the value date back where it should have been. On top of that, both PSPs answer for charges they caused and interest the customer suffered.", "citation": "Directive (EU) 2015/2366, Article 89(1) and 89(3)", "rests_on": "law" }, { "label": "The customer layer: a payment nobody authorised", "value": "The payer's PSP refunds at once, and by the end of the next business day at the latest after learning of the claim. Where the customer denies authorising it, the PSP has to prove the transaction was authenticated, accurately recorded, properly booked and unaffected by any failure of its own; the record of an instrument being used is not proof on its own.", "citation": "Directive (EU) 2015/2366, Articles 72 and 73(1)", "rests_on": "law" }, { "label": "The customer layer: a wrong IBAN", "value": "The customer bears it. Pay the account the IBAN names and the payment counts as correct towards whoever owns that account, and a customer that supplied the wrong one loses the non-execution claim. Its PSP still owes a genuine recovery attempt, the other PSP owes cooperation and information, and a charge for the recovery is allowed if the framework contract says so.", "citation": "Directive (EU) 2015/2366, Article 88(1) to (4)", "rests_on": "law" }, { "label": "The 2024 amendment moved one line", "value": "Verification of payee now sits between those two positions. A PSP that ran the check properly keeps the protection of the unique identifier rule. A payer's PSP that did not, and thereby caused a defective payment, refunds the payer without delay, and where the fault lay with the payee's PSP or an initiation service provider, that party compensates the payer's PSP.", "citation": "Regulation (EU) No 260/2012 as amended by Regulation (EU) 2024/886, Article 5c(8)", "rests_on": "law" }, { "label": "One liability the scheme prices itself", "value": "A receiving PSP that was not the cause of a wrong value date can bill the sending PSP interest at the euro short-term rate for the days the money sat wrongly dated, and may add a handling fee for the inquiry. That is the only compensation the rulebook quantifies.", "citation": "EPC125-05 SCT Rulebook 2025 v1.1, sections 4.4.2 and 4.4.4", "rests_on": "rule" } ], "exceptions": [ "Nothing in the rulebook makes a CSM liable to anyone. The rulebook binds Participants and the EPC, and what a CSM owes is a matter for its own contract (EPC125-05 2025 v1.1, sections 3.3 and 5.2).", "The liability provisions outlive participation. Sections 5.9 and 5.10 stay enforceable against a Participant after it leaves the scheme (EPC125-05 2025 v1.1, section 5.11).", "Outside the EEA the Directive does not bite directly. Participants there take on obligations the rulebook calls substantially equivalent to Titles III and IV, as far as their own law allows, which can leave a real gap (EPC125-05 2025 v1.1, section 5.14).", "A payment initiation service provider carries its own share. It has to prove that within its own sphere the transaction was authenticated, accurately recorded and unaffected by a failure of its service, and it compensates the account servicing PSP where it was at fault (Directive (EU) 2015/2366, Articles 72(1) and 73(2)).", "The rulebook's cap is between Participants only. It does not limit what a PSP owes its own customer under payment services law. [Inference: the rulebook says a non-party gets no rights under it, which is not the same as saying it caps nothing outside it.]", "Fraud by a customer, or gross negligence in keeping its credentials, removes the customer's protection for an unauthorised payment entirely, and the PSP has to bring supporting evidence to prove it (Directive (EU) 2015/2366, Articles 72(2) and 74(1))." ], "applies_to": "losses on a SEPA Credit Transfer, between two Participants under the rulebook and between a Participant and its own payment service user under payment services law", "caveat": "The gap worth naming is authorised push payment fraud. A customer tricked into sending a transfer has authorised it, so the unauthorised-payment refund does not reach it, and the IBAN was correct, so the wrong-identifier route does not either. What the rulebook offers is a Request for Recall the beneficiary can refuse. Verification of payee narrows the gap but does not close it.", "related": [ "sepa-sct:finality", "sepa-sct:refund", "sepa-sct:consumer-law", "sepa-sct:recall", "sepa-sct:participants", "sepa-sct:decision-points" ], "basis": { "sources": "EPC125-05 SEPA Credit Transfer Scheme Rulebook 2025 version 1.1 (effective 2025-10-05, marked Public), read for this record: sections 1.4, 3.3, 4.4.2, 4.4.4, 5.2, 5.3, 5.9.1, 5.9.2, 5.9.3, 5.10, 5.11 and 5.14. Directive (EU) 2015/2366 consolidated 2024-04-08, Articles 72, 73, 74(1), 88 and 89, and Regulation (EU) No 260/2012 as amended by Regulation (EU) 2024/886, Article 5c(8), both read on EUR-Lex for this record.", "confidence": "high" }, "currency": { "effective_since": "2025-10-05", "effective_note": "The 2025 SCT rulebook was issued and took effect on 2025-10-05. Annex IV records no change to chapter 5.9 or 5.10 in this edition, so the liability cap is older than it; the date it first took effect is [Unverified] because earlier editions were not read. The verification of payee liability shift came from Regulation (EU) 2024/886 and binds PSPs in euro area Member States from 2025-10-09.", "source_edition": "EPC125-05 SCT Scheme Rulebook 2025 version 1.1 (2025-10-05); Directive (EU) 2015/2366 consolidated 2024-04-08; Regulation (EU) No 260/2012 as amended by Regulation (EU) 2024/886", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-09/EPC125-05%202025%20SCT%20Rulebook%20version%201.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC125-05 SCT Scheme Rulebook 2025 version 1.1", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the three inter-PSP liability triggers of breach, negligence and operational failure (5.9.1), the transfer-amount cap surviving gross negligence and broken only by wilful intent, proportionate reduction for contributory negligence, the risk-management and unforeseeability carve-outs (5.9.2), force majeure (5.9.3), EPC's own bad-faith-only liability for discretion and no liability for unforeseeable loss (5.10), that the rulebook binds only the EPC and Participants (5.2), that using a CSM or intermediary is at the Participant's own risk and does not move liability (1.4, 5.3), and the interest compensation at the euro short-term rate as the one liability the rulebook quantifies for a wrong value date (4.4.2, 4.4.4). Does not independently confirm Directive 2015/2366 Articles 72, 73(1), 74(1), 88 or 89, or Regulation 260/2012 Article 5c(8) as amended by 2024/886, which cover the customer-facing liability layer; EUR-Lex remains unreachable." } ] }, "rail_name": "SEPA Credit Transfer", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sct:limits", "id": "limits", "rail": "sepa-sct", "kind": "rail-fact", "facet": "limits", "name": "What limits apply to a SEPA Credit Transfer, and who sets them?", "statement": "The SCT scheme sets no maximum amount of its own. What exists is a data limit: the amount field stops at 999,999,999.99 euro and cannot be zero, which lines up with the ceiling the SEPA Regulation says no scheme has to go above. Every limit a payer actually meets comes from somewhere else, either the sending bank's own risk appetite or the settlement and value limits Participants and communities hold against each other through their CSMs. None of those numbers are published by the EPC.", "details": [ { "label": "No scheme maximum, but a field ceiling", "value": "AT-T002 stops at 999,999,999 euro plus 99 cents at the top and cannot be zero at the bottom. The same width applies to the amount sent back on a positive answer to a Recall or a Request for Recall.", "citation": "EPC125-05 SCT Rulebook 2025 v1.1 (effective 2025-10-05), section 4.6.1, attributes AT-T002, AT-R054 and AT-R074", "rests_on": "rule" }, { "label": "Where that ceiling comes from", "value": "The SEPA Regulation's technical annex frees a scheme from having to carry anything above EUR 999 999 999,99, bars it from setting a floor, and says nobody has to process a zero amount.", "citation": "Regulation (EU) No 260/2012, Annex points (1)(f) and (1)(g), read on EUR-Lex", "rests_on": "law" }, { "label": "Who may impose a real limit", "value": "The sending PSP, on the products it sells its own customers, using its own risk judgement and controls. The scheme neither sets those limits nor asks to be told about them.", "citation": "EPC125-05 SCT Rulebook 2025 v1.1, section 2.5", "rests_on": "rule" }, { "label": "Limits between the banks", "value": "Participants and communities of them may also cap each other, typically through the CSM they share, for risk management reasons. Those caps are private arrangements and their values are nowhere in the public record.", "citation": "EPC125-05 SCT Rulebook 2025 v1.1, section 2.5", "rests_on": "rule" }, { "label": "The beneficiary PSP cannot lower the limit", "value": "Value limits are described only on the sending side. On the receiving side the duty runs the other way: pay the account the IBAN names, in full, subject only to anti money laundering obligations and any fee the customer itself agreed to have deducted. [Inference: the rulebook does not forbid a receiving side limit, it simply provides no basis for one.]", "citation": "EPC125-05 SCT Rulebook 2025 v1.1, sections 2.5 and 5.8 points 8 and 10", "rests_on": "rule" }, { "label": "The data limits that bite in practice", "value": "Remittance information runs to 140 characters, structured or not, and has to reach the beneficiary whole and unaltered. The law fixes the same 140 and lets a scheme be more generous.", "citation": "EPC125-05 SCT Rulebook 2025 v1.1, section 2.7; Regulation (EU) No 260/2012, Annex point (1)(c)", "rests_on": "law" }, { "label": "One limit the scheme does set on an exception", "value": "Each procedure runs once per transaction: one Recall, one Request for Recall, and neither may be raised again after the beneficiary PSP has answered. This is a count limit rather than an amount limit, and it was tightened in this edition.", "citation": "EPC125-05 SCT Rulebook 2025 v1.1, sections 4.3.2.3 and 4.3.2.4, with Annex IV entries for those sections", "rests_on": "rule" }, { "label": "Fees on a positive response are uncapped", "value": "A receiving PSP that agrees to send money back may bill the sending PSP for doing it, using AT-R055 on a Recall and AT-R075 on a Request for Recall. The rulebook allows any value inside the same field width, names no maximum, and permits the charge only where the answer is yes.", "citation": "EPC125-05 SCT Rulebook 2025 v1.1, sections 4.3.2.3 and 4.3.2.4, and section 4.6.1 attributes AT-R055 and AT-R075", "rests_on": "rule" } ], "exceptions": [ "No limit figure for this scheme is published by the EPC at all. What a given payer can send is a question for that payer's own bank.", "Currency is a limit of a different kind: euro at every stage, exception messages included, whatever the two accounts are denominated in (EPC125-05 2025 v1.1, section 2.4).", "Geography is a limit too: both accounts have to sit in a country or territory on the EPC's list. [Unverified: EPC409-09 was not read for this record.]", "The customer-set instant payment limit in the amended SEPA Regulation attaches to instant credit transfers, so it has no equivalent on this scheme (Regulation (EU) No 260/2012 as amended by Regulation (EU) 2024/886, Article 5a(6)).", "Nothing caps how many transactions may be sent, and the rulebook puts bulk presentation rules outside its own scope entirely (EPC125-05 2025 v1.1, section 4.5.1)." ], "applies_to": "the amount, the character count and the count of exception messages on a SEPA Credit Transfer under the EPC SCT scheme", "caveat": "The interesting number on this rail is almost never the scheme number. 999,999,999.99 euro is the width of a field. The number that stops a payment is the sending bank's own, set under section 2.5 with no duty to publish it, or a CSM's settlement limit that the payer will never see. Treat any single figure quoted as the SEPA limit with suspicion until it names whose limit it is.", "related": [ "sepa-sct:settlement", "sepa-sct:participants", "sepa-sct:messages", "sepa-sct:consumer-law", "sepa-sct:decision-points" ], "basis": { "sources": "EPC125-05 SEPA Credit Transfer Scheme Rulebook 2025 version 1.1 (effective 2025-10-05, marked Public), read for this record: sections 2.4, 2.5, 2.7, 4.3.2.3, 4.3.2.4, 4.5.1, 4.6.1 (AT-T002, AT-R054, AT-R055, AT-R074, AT-R075), 5.8, and Annex IV. Regulation (EU) No 260/2012, Annex points (1)(c), (1)(f) and (1)(g), and the same Regulation as amended by Regulation (EU) 2024/886, Article 5a(6), read on EUR-Lex for this record.", "confidence": "high" }, "currency": { "effective_since": "2025-10-05", "effective_note": "The 2025 SCT rulebook was issued and took effect on 2025-10-05. Annex IV to that edition records no change to section 2.5 or to AT-T002 for this scheme; the amount limit change made for the 2025 cycle was on the SCT Inst side, where a scheme maximum was removed. The amount range in AT-T002 predates this edition; the date it first took effect is [Unverified] because earlier editions were not read.", "source_edition": "EPC125-05 SCT Scheme Rulebook 2025 version 1.1 (2025-10-05); Regulation (EU) No 260/2012 consolidated as amended by Regulation (EU) 2024/886", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-09/EPC125-05%202025%20SCT%20Rulebook%20version%201.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC125-05 SCT Scheme Rulebook 2025 version 1.1", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the AT-T002 amount field ceiling of 999,999,999.99 euro with a non-zero floor and the same width on AT-R054/AT-R074 (4.6.1), that value limits sit with the originator PSP and between participants through their CSMs and are not scheme figures (2.5), the euro-only and 140 character remittance rules (2.4, 2.7), the beneficiary PSP's duty to credit the IBAN-named account in full subject only to anti-money-laundering checks and any agreed fee deduction (5.8 points 8 and 10), the one-recall and one-RFRO-per-transaction count limit (4.3.2.3, 4.3.2.4), and that fees on a positive recall or RFRO response are uncapped in the rulebook (AT-R055, AT-R075). Does not independently confirm Regulation 260/2012 Annex points (1)(c), (1)(f), (1)(g) or Article 5a(6) as amended by 2024/886; EUR-Lex remains unreachable." } ] }, "rail_name": "SEPA Credit Transfer", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sct:messages", "id": "messages", "rail": "sepa-sct", "kind": "rail-fact", "facet": "messages", "name": "What messages exist on this rail, and what standard are they in?", "statement": "The rulebook does not name a single ISO message. It works one level up, in eleven datasets and a list of attributes, and pushes the mapping to ISO 20022 XML into two Implementation Guidelines it makes binding but does not contain. So the answer has two halves. The scheme defines eleven business messages: the customer instruction, the inter-PSP payment, the Reject or Return, the advice to the beneficiary, the Recall and its answer, the Request for Recall and its answer, the inquiry and its answer, and an inter-PSP fee payment. Which pacs or camt message carries each is in the guidelines, which this record does not assert.", "details": [ { "label": "The eleven datasets", "value": "DS-01 the customer's instruction to its PSP, DS-02 the inter-PSP payment, DS-03 a Reject or a Return, DS-04 what the beneficiary PSP tells its customer, DS-05 a Recall, DS-06 the answer to a Recall, DS-07 a Request for Recall by the Originator, DS-08 the answer to it, DS-09 an SCT inquiry, DS-10 the answer to an inquiry, DS-11 an inter-PSP fee or compensation payment.", "citation": "EPC125-05 SCT Rulebook 2025 v1.1 (effective 2025-10-05), section 4.5", "rests_on": "rule" }, { "label": "Where the ISO mapping lives", "value": "Two documents outside the rulebook carry it: the Inter-PSP Implementation Guidelines for the bank to bank space and the Customer-to-PSP Implementation Guidelines for the customer side. Both set out how the ISO 20022 XML standards are implemented for this scheme, and the rulebook makes both binding supplements to itself.", "citation": "EPC125-05 SCT Rulebook 2025 v1.1, section 0.5.1 and chapter 7 entries for the two Implementation Guidelines", "rests_on": "rule" }, { "label": "Which standard, and why", "value": "ISO 20022 XML, not by the scheme's choice but by law: the SEPA Regulation's technical annex fixes it as the message format for transmitting payments between PSPs and through a retail payment system. The same annex fixes IBAN as the account identifier.", "citation": "Regulation (EU) No 260/2012, Article 5(1)(a) and (b) with Annex points (1)(a) and (1)(b)", "rests_on": "law" }, { "label": "When a bank must accept the customer-side format", "value": "Only where it offers its customers the service of taking bundled electronic instructions. A PSP that does offer it has to accept at least instructions built to the Customer-to-PSP Implementation Guidelines when a customer asks. Law adds that a PSP must use those formats on request for any customer, and must use them for a non-consumer, non-microenterprise customer sending bundled payments.", "citation": "EPC125-05 SCT Rulebook 2025 v1.1, sections 0.5.1 and 4.5.1; Regulation (EU) No 260/2012, Article 5(1)(b) and (d)", "rests_on": "law" }, { "label": "What every exception message has to carry", "value": "The path the original payment took, its data unaltered, enough of that data for an audit trail, the sending PSP's original reference, and a reason code. Rejects and Returns carry AT-R004, Recalls carry AT-R051, Requests for Recall carry AT-R071, inquiries carry AT-Q001, and the negative answer to a Recall carries AT-R057.", "citation": "EPC125-05 SCT Rulebook 2025 v1.1, sections 4.3.2.1 to 4.3.2.4 and 4.6.1", "rests_on": "rule" }, { "label": "Where the reason code values come from", "value": "The values are ISO 20022 external codes, maintained by the ISO 20022 Registration Authority, not by the EPC. What the EPC decides is which of them this scheme permits and what each one means inside it, which is what its reason code guidance sets out.", "citation": "EPC125-05 SCT Rulebook 2025 v1.1, sections 4.3.2.1 to 4.3.2.4 (each pointing at reference [15]); EPC135-18 v6.0 (2024-11-28), sections 1 and 3", "rests_on": "guidance" }, { "label": "The remittance field", "value": "One field, 140 characters, either structured or unstructured but not both, and it has to reach the beneficiary whole and unaltered through every hop. The rulebook recommends the ISO 11649 structured creditor reference where a payment relates to a single invoice.", "citation": "EPC125-05 SCT Rulebook 2025 v1.1, section 2.7; Regulation (EU) No 260/2012, Annex point (1)(c) and (1)(d)", "rests_on": "law" }, { "label": "The message change with a date on it", "value": "From 15 November 2026 an address may only be sent in hybrid or structured form, and an unstructured address will no longer be accepted. The EPC moved that date forward from 22 November 2026 in September 2025 to line up with the Swift standards release that month, and version 1.1 of this rulebook exists to carry the new date.", "citation": "EPC125-05 SCT Rulebook 2025 v1.1, IMPORTANT MESSAGE on the cover, section 0.2 change history for 2025 v1.1, and section 4.6.1 attributes AT-P005 and AT-E004", "rests_on": "rule" }, { "label": "An optional message extension", "value": "The Extended Remittance Information option adds features to both guidelines, and they bind only the Participants that joined the option. A Participant outside it that receives such a payment has to send it back, as a Reject or as a Return depending on whether it has settled.", "citation": "EPC125-05 SCT Rulebook 2025 v1.1, sections 0.5.1, 0.5.3, 2.7 and Annex V", "rests_on": "rule" }, { "label": "One message the scheme added for money between banks", "value": "DS-11 carries an inter-PSP fee or compensation payment, and every Participant has to implement it so that any sending PSP wishing to use the inquiry compensation feature can. The rulebook recommends settling those amounts that way.", "citation": "EPC125-05 SCT Rulebook 2025 v1.1, sections 4.4.4 and 4.5.11", "rests_on": "rule" } ], "exceptions": [ "The ISO message identifiers for this scheme, the pacs and camt names an implementer needs, are in the two Implementation Guidelines and not in the rulebook. This record does not assert them. [Unverified: EPC115-06 and EPC132-08 were not read for this record.]", "The ISO 20022 message versions each guideline pins move with the guideline, not with the rulebook, although both carry the same effective date. [Unverified: no guideline was read for this record.]", "A code that exists in the ISO external code sets is not usable on this scheme unless the EPC permits it. The reason code guidance is the list that matters (EPC135-18 v6.0, sections 1 and 3).", "Bulk presentation to a customer's own bank is expressly outside the scheme; between PSPs every payment is a single one, and bulk refers only to the physical layer described in the Inter-PSP guidelines (EPC125-05 2025 v1.1, sections 4.5.1 and 4.5.2).", "The BIC is not normally needed from the customer. It becomes mandatory on the customer-side dataset only where the sending PSP cannot derive it from the IBAN for an account held in a non-EEA SEPA country or territory, and it stays mandatory on the inter-PSP message (EPC125-05 2025 v1.1, section 4.5.1 remarks)." ], "applies_to": "the business messages of the SCT scheme and the ISO 20022 standard they are expressed in, in both the customer to PSP space and the inter-PSP space", "caveat": "An implementer cannot build from the rulebook. It gives datasets and attributes, and the field names, cardinalities and message identifiers live in the two Implementation Guidelines, which are binding and separate. Any record that names a pacs or camt message for SEPA without citing a guideline is asserting something the rulebook does not say.", "related": [ "sepa-sct:return", "sepa-sct:recall", "sepa-sct:settlement", "sepa-sct:limits", "sepa-sct:participants" ], "basis": { "sources": "EPC125-05 SEPA Credit Transfer Scheme Rulebook 2025 version 1.1 (effective 2025-10-05, marked Public), read for this record: the cover IMPORTANT MESSAGE, sections 0.1 (references), 0.2 (change history), 0.5.1, 0.5.3, 2.7, 4.3.2.1 to 4.3.2.4, 4.4.4, 4.5 with 4.5.1, 4.5.2 and 4.5.11, 4.6.1 (AT-P005, AT-E004, AT-R004, AT-R051, AT-R057, AT-R071, AT-Q001), chapter 7 and Annex V. EPC135-18 v6.0 (2024-11-28), sections 1 and 3. Regulation (EU) No 260/2012, Article 5(1) and Annex points (1)(a) to (1)(d), read on EUR-Lex.", "confidence": "high" }, "currency": { "effective_since": "2025-10-05", "effective_note": "The 2025 SCT rulebook was issued and took effect on 2025-10-05, and version 1.1 exists solely to move the end of the unstructured address format from 22 November 2026 to 15 November 2026. That date is the one message change with a future effect built into this edition. The Implementation Guidelines carry the same effective date as the rulebook but were not read for this record.", "source_edition": "EPC125-05 SCT Scheme Rulebook 2025 version 1.1 (2025-10-05); EPC135-18 v6.0 (2024-11-28); Regulation (EU) No 260/2012", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-09/EPC125-05%202025%20SCT%20Rulebook%20version%201.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC125-05 SCT Scheme Rulebook 2025 version 1.1; EPC135-18 v6.0 Guidance on Reason Codes for SCT R-transactions", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the eleven DS-01 to DS-11 datasets defined in section 4.5, that ISO 20022 XML implementation is pushed to the separate Inter-PSP and Customer-to-PSP Implementation Guidelines (0.5.1, 0.5.3), the ERI option scope and its reject-or-return rule (2.7, Annex V), the 15 November 2026 unstructured-address cutover moved forward from 22 November 2026 in v1.1 (cover notice, 0.2, section 4.6.1 AT-P005/AT-E004), DS-11 for inter-PSP fee and compensation payments (4.4.4, 4.5.11), and that reason code values are ISO external codes the EPC permits via EPC135-18 (referenced at each of 4.3.2.1-4.3.2.4). Does not independently confirm Regulation 260/2012 Article 5(1) or its Annex points (1)(a) to (1)(d); EUR-Lex remains unreachable." } ] }, "rail_name": "SEPA Credit Transfer", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sct:participants", "id": "participants", "rail": "sepa-sct", "kind": "rail-fact", "facet": "participants", "name": "Who can be on this rail, in what roles, and who cannot?", "statement": "A Participant is a payment service provider that signed the Adherence Agreement and meets nine eligibility tests, and the scheme insists it work both ways: every Participant has to send and to receive. Credit institutions authorised in the EEA, and payment institutions authorised under the Payment Services Directive, are treated as eligible by definition on most of the tests. CSMs and intermediary PSPs are not Participants at all, and neither is a customer. Adherence is per scheme, so being in SCT says nothing about being in SCT Inst or either direct debit scheme.", "details": [ { "label": "The four roles in a payment", "value": "The originator who instructs, the originator PSP that debits and sends, the beneficiary PSP that receives and credits, and the beneficiary who is paid. One Participant can be both PSPs on the same payment.", "citation": "EPC125-05 SCT Rulebook 2025 v1.1 (effective 2025-10-05), section 3.1", "rests_on": "rule" }, { "label": "Who is not in the scheme", "value": "CSMs, intermediary PSPs and payment initiation service providers all take part in the flow without being Participants. A Participant may use any of them, but doing so changes none of its own obligations and it carries the risk of that choice itself.", "citation": "EPC125-05 SCT Rulebook 2025 v1.1, sections 3.1, 3.4, 1.4 and 5.3", "rests_on": "rule" }, { "label": "Both directions, no exceptions", "value": "Every Participant has to offer the scheme's services as originator PSP and as beneficiary PSP. How it achieves reach is its own business, directly, through a CSM or through an intermediary, so long as reach and compliance actually result.", "citation": "EPC125-05 SCT Rulebook 2025 v1.1, sections 2.6 and 5.3", "rests_on": "rule" }, { "label": "The nine eligibility tests", "value": "Continuously, an applicant has to be in the business of providing banking or payment services and of holding and moving customer funds; hold a licence, either from the SEPA country it is incorporated in or from an EEA regulator; be solvent and able to pay its debts; hold enough liquidity and capital for its own regulatory regime; meet any rating criteria the scheme sets; comply with anti money laundering, sanctions and terrorist financing rules; take part directly or indirectly in at least one CSM; and run operational and risk controls suited to its business.", "citation": "EPC125-05 SCT Rulebook 2025 v1.1, section 5.4", "rests_on": "rule" }, { "label": "Who passes automatically", "value": "Credit institutions authorised under Article 8(1) of Directive 2013/36/EU by an EEA state, the bodies listed in points (2) to (23) of Article 2(5) of that Directive, and institutions licensed by a national competent authority in a non-EEA country the scheme's geography has been extended to and listed in EPC409-09.", "citation": "EPC125-05 SCT Rulebook 2025 v1.1, section 5.4", "rests_on": "rule" }, { "label": "Payment institutions get a partial pass", "value": "An applicant holding a payment institution authorisation under Article 11 of the Directive, or sitting in any other class of provider the Directive lists in Article 1.1, is treated as meeting five of the tests: the business test, the licensing test, the liquidity and capital test, the financial crime test, and the operational and risk controls test. The rest it still has to establish.", "citation": "EPC125-05 SCT Rulebook 2025 v1.1, section 5.4", "rests_on": "rule" }, { "label": "A sovereign treasury gets a different pass", "value": "The treasury of a sovereign state need not establish that it can pay its debts or that it meets any rating criteria, unless the circumstances are exceptional or it is not the treasury of an EEA state or Switzerland. It may be asked to show that it really is the state's own treasury rather than an organ under the state's control.", "citation": "EPC125-05 SCT Rulebook 2025 v1.1, section 5.4", "rests_on": "rule" }, { "label": "How you get in, and how you get out", "value": "An eligible undertaking applies to the EPC with a signed Adherence Agreement and supporting documentation, and becomes a Participant on a date the EPC sets. A rejection comes with reasons and can be appealed. Leaving needs six months' written notice, and the Participant stays bound for everything it did before it left.", "citation": "EPC125-05 SCT Rulebook 2025 v1.1, sections 5.5 and 5.11", "rests_on": "rule" }, { "label": "Where the list is", "value": "The EPC keeps a register of Participants with contact details, the date each joined, and details of those removed and when. Applying is consent to that publication, and any change of operational or contact detail has to be notified through the scheme management process.", "citation": "EPC125-05 SCT Rulebook 2025 v1.1, section 5.6", "rests_on": "rule" }, { "label": "What law requires on top", "value": "Reach is not only a scheme rule. A PSP reachable for a domestic credit transfer has to be reachable for one initiated from any Member State, and the scheme itself has to keep the same rules for national and cross border transfers and cover a majority of PSPs across a majority of Member States.", "citation": "Regulation (EU) No 260/2012, Articles 3(1) and 4(1)", "rests_on": "law" } ], "exceptions": [ "Adherence is per scheme. A Participant in SCT is not thereby in SCT Inst, SDD Core or SDD B2B, each of which has its own rulebook and its own adherence. [Inference: each scheme's rulebook carries its own Adherence Agreement and its own list of Participants; no single EPC statement to that effect was read.]", "Geography is set by a separate document, the EPC list of countries and territories in the schemes' scope, which is amended when the EPC Board admits a country. [Unverified: EPC409-09 was not read for this record.]", "A Participant outside the EEA is not bound by the Payment Services Directive directly and takes on substantially equivalent obligations through the rulebook instead, and even then not the provisions that only work inside the EEA authorisation framework (EPC125-05 2025 v1.1, section 5.14).", "A Participant has to tell the EPC Secretariat at once about anything material to its continued eligibility, and the Secretariat passes that to the other Participants and the management board (EPC125-05 2025 v1.1, section 5.4).", "How many Participants there are, and who they are, is not stated in the rulebook. The register is a separate EPC publication. [Unverified: the SCT list of Participants was not read for this record.]", "The EPC writes the rules and manages the scheme. It operates no network and settles nothing, so it is never a party to a payment (EPC125-05 2025 v1.1, sections 1.5 and 3.3)." ], "applies_to": "adherence to the EPC SEPA Credit Transfer scheme and the roles of the parties to a payment made under it", "caveat": "Do not read participation as reach in practice. The rulebook makes every Participant offer both directions, but the route between two Participants runs through CSMs that interoperate bilaterally, and the rulebook governs none of that. Two Participants are always reachable in principle; how a payment actually gets from one to the other is a CSM question the scheme leaves open.", "related": [ "sepa-sct:settlement", "sepa-sct:hours", "sepa-sct:messages", "sepa-sct:liability", "sepa-sct:consumer-law", "sepa-sct:limits" ], "basis": { "sources": "EPC125-05 SEPA Credit Transfer Scheme Rulebook 2025 version 1.1 (effective 2025-10-05, marked Public), read for this record: sections 1.4, 1.5, 2.1, 2.6, 3.1, 3.3, 3.4, 5.2, 5.3, 5.4, 5.5, 5.6, 5.11 and 5.14, and Annex I. Regulation (EU) No 260/2012, Articles 3 and 4, read on EUR-Lex.", "confidence": "high" }, "currency": { "effective_since": "2025-10-05", "effective_note": "The 2025 SCT rulebook was issued and took effect on 2025-10-05. Annex IV records that section 5.1 was reworded in this edition to refer to the SEPA Regulation and to the EPC's criteria for expanding the geographical scope. The eligibility tests themselves are older; the date they first took effect is [Unverified] because earlier editions were not read.", "source_edition": "EPC125-05 SCT Scheme Rulebook 2025 version 1.1 (2025-10-05); Regulation (EU) No 260/2012", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-09/EPC125-05%202025%20SCT%20Rulebook%20version%201.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC125-05 SCT Scheme Rulebook 2025 version 1.1", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the four-corner actor model (3.1), CSMs/intermediaries/PISPs as non-Participants (3.1, 3.4, 1.4, 5.3), the both-directions reach duty (2.6, 5.3), the nine eligibility tests verbatim in order (5.4), the automatic-pass categories for EEA credit institutions under Article 8(1) of Directive 2013/36/EU and Article 2(5) points 2-23 (5.4), the five-test partial pass for payment institutions under PSD2 Article 11 or Article 1.1 (5.4), the sovereign treasury carve-out from the solvency and rating tests (5.4), the immediate-notification duty to the Secretariat (5.4), and joining/leaving/register provisions (5.5, 5.6, 5.11). Does not independently confirm Regulation 260/2012 Articles 3(1) or 4(1); EUR-Lex remains unreachable." } ] }, "rail_name": "SEPA Credit Transfer", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sct:recall", "id": "recall", "rail": "sepa-sct", "kind": "rail-fact", "facet": "recall", "name": "Can a sent payment be recalled, and who decides?", "statement": "A settled SEPA Credit Transfer can be asked back two ways, and both are requests. A Recall comes from the originator PSP and is confined to three grounds: a duplicate, a technical fault that produced a wrong transfer, and fraud behind the instruction. Everything else, a payment to the wrong IBAN or for the wrong amount included, goes as a Request for Recall by the Originator, which exists because the customer asked for it. The windows differ sharply: ten Banking Business Days for the duplicate and technical grounds, thirteen months for fraud and for any Request for Recall. Either way the beneficiary PSP owes an answer in fifteen Banking Business Days and may say no. Money moves only if the beneficiary agrees, or if its PSP can debit the account without asking.", "details": [ { "label": "Who may start a Recall, and on what grounds", "value": "The sending PSP alone, on its own account or for its customer. Before raising one it has to satisfy itself that the case is a duplicate, a technical fault that produced a wrong transfer, or fraud behind the instruction. Nothing else qualifies.", "citation": "EPC125-05 SCT Rulebook 2025 v1.1 (effective 2025-10-05), section 4.3.2.3 and process steps CT-02.00 and CT-02.01", "rests_on": "rule" }, { "label": "The two windows", "value": "Ten Banking Business Days for a duplicate or a technical fault, thirteen months for fraud, both counted from the execution date of the original transfer. A sending PSP may turn its own customer down where the grounds do not fit or the window has closed.", "citation": "EPC125-05 SCT Rulebook 2025 v1.1, section 4.3.2.3 and process step CT-02.01R", "rests_on": "rule" }, { "label": "One request only", "value": "One Recall per transaction inside those windows, and none at all once the receiving PSP has answered. Silence past fifteen Banking Business Days buys the sending PSP a Request for Status Update, which can cover one earlier Recall or several, but never a second Recall.", "citation": "EPC125-05 SCT Rulebook 2025 v1.1, section 4.3.2.3 and process step CT-02.07, with the Annex IV entry for section 4.3.2.3", "rests_on": "rule" }, { "label": "The answer is compulsory, the return is not", "value": "The receiving PSP has to work every Recall and give a yes or a no inside fifteen Banking Business Days. Failing to answer puts it in breach of the rulebook. Where its own customer has gone quiet, it has to send a no that says exactly that.", "citation": "EPC125-05 SCT Rulebook 2025 v1.1, section 4.3.2.3 and process step CT-02.03", "rests_on": "rule" }, { "label": "Who actually decides", "value": "It depends on the country and the account contract. With the money still sitting on the account, the receiving PSP may be free to debit it and answer yes straight away, may judge that it should ask the customer first, or may have no choice but to get the customer's authorisation. So in some SEPA countries the bank decides and in others the customer does.", "citation": "EPC125-05 SCT Rulebook 2025 v1.1, process steps CT-02.03 and CT-02.03A", "rests_on": "rule" }, { "label": "The grounds for saying no", "value": "Seven of them: not enough money on the account, the account is closed, a legal obstacle set out in plain text, the customer refused, the customer never answered inside the fifteen days, the original transfer never arrived, and the money has already gone back.", "citation": "EPC125-05 SCT Rulebook 2025 v1.1, process step CT-02.03R and section 4.6.1 attribute AT-R057", "rests_on": "rule" }, { "label": "Which codes carry all this", "value": "AT-R051 holds the Recall reason, with values for duplicate, technical fault, fraud and a status chaser. The guidance turns those into DUPL, TECH and FRAD, a yes into FOCR, and the seven refusals into CUST for the customer's refusal, LEGL for a legal obstacle, AC04 closed, AM04 not enough money, NOAS no answer, NOOR original never received and ARDT already sent back.", "citation": "EPC125-05 SCT Rulebook 2025 v1.1, section 4.6.1 attributes AT-R051 and AT-R057; EPC135-18 v6.0 (2024-11-28), section 3", "rests_on": "guidance" }, { "label": "The other route, for every other reason", "value": "Where the customer wants its money back for a reason outside those three grounds, the sending PSP raises a Request for Recall by the Originator instead. Its reason field AT-R071 covers the wrong beneficiary account identifier, the wrong amount, a plain request with no reason stated, and a status chaser. The guidance maps the first three to AC03, AM09 and CUST.", "citation": "EPC125-05 SCT Rulebook 2025 v1.1, sections 4.3.2.4 and 4.6.1 attribute AT-R071; EPC135-18 v6.0 (2024-11-28), section 3", "rests_on": "guidance" }, { "label": "The warning the sending bank must give", "value": "Before raising one, the sending PSP has to tell its customer plainly that this may not get the money back, because the beneficiary has to consent. It also has to check that the original debit falls inside the thirteen months before the customer's request reached it.", "citation": "EPC125-05 SCT Rulebook 2025 v1.1, section 4.3.2.4 and step 1", "rests_on": "rule" }, { "label": "How the money comes back, and at what cost", "value": "On a yes, the receiving PSP debits its customer, having taken authorisation first where it needs it, and must answer on the response message rather than pushing a separate credit transfer. What arrives can be less than what left, because the receiving PSP may bill a fee for the service, carried in AT-R055 on a Recall and AT-R075 on a Request for Recall. Charging is allowed only where the answer is yes, only in these two procedures, and never touches a Return.", "citation": "EPC125-05 SCT Rulebook 2025 v1.1, sections 4.3.2.3 and 4.3.2.4 step 4A, with attributes AT-R054, AT-R055, AT-R074 and AT-R075", "rests_on": "rule" }, { "label": "What fraud lets the sending bank add", "value": "On a fraud Recall the sending PSP may attach free text in AT-R052, in a language the receiving PSP can read, and the receiving PSP is under no duty to do anything with it. The equivalent field on a Request for Recall, AT-R073, is the opposite: the receiving PSP is obliged to act on what it says.", "citation": "EPC125-05 SCT Rulebook 2025 v1.1, section 4.6.1 attributes AT-R052 and AT-R073", "rests_on": "rule" } ], "exceptions": [ "A Recall raised before the transaction settles is not a request to anyone. The CSM checks whether it has gone out yet and, if not, cancels it under whatever procedure it agreed with its own participants (EPC125-05 2025 v1.1, section 4.3.2.3 and CT-02.02).", "A refusal on a Request for Recall ends it. The rulebook treats the beneficiary's answer as settling what becomes of the original transfer for both PSPs (EPC125-05 2025 v1.1, section 4.3.2.4 step 4B).", "Thirteen months is also the outer limit law gives a customer for raising an unauthorised or badly executed transaction, counted from the debit (Directive (EU) 2015/2366, Article 71(1)).", "Neither procedure is a right to the money. Where the beneficiary has spent it, the answer comes back as not enough funds, and the scheme offers no partial return on a Recall. [Inference: the rulebook lets the returned amount differ from the original only on account of a fee, and describes no partial return.]", "A Request for Status Update is not a second Recall. It can cover one earlier request or several, and the receiving PSP owes nothing where it has already answered the original (EPC125-05 2025 v1.1, sections 4.3.2.3, 4.3.2.4 and 4.4.2).", "Whether a receiving PSP may debit its customer without asking comes from national law and the account contract, not the scheme, so one Recall can behave two different ways in two SEPA countries (EPC125-05 2025 v1.1, CT-02.03)." ], "applies_to": "a settled SEPA Credit Transfer that the sending side wants back, through either the Recall or the Request for Recall by the Originator procedure", "caveat": "Recall and Request for Recall are not two names for the same thing. The Recall belongs to the bank and is limited to its own errors and to fraud; the Request for Recall belongs to the customer and covers ordinary mistakes such as the wrong IBAN or the wrong amount. Getting the wrong one is a real failure mode: a customer's wrong-account claim sent as a Recall is outside the three permitted reasons.", "related": [ "sepa-sct:finality", "sepa-sct:return", "sepa-sct:refund", "sepa-sct:liability", "sepa-sct:messages", "sepa-sct:hours", "sepa-sct:decision-points" ], "basis": { "sources": "EPC125-05 SEPA Credit Transfer Scheme Rulebook 2025 version 1.1 (effective 2025-10-05, marked Public), read for this record: section 4.3.2.3 (Recall) with process steps CT-02.00 to CT-02.07, section 4.3.2.4 (Request for Recall by the Originator) with steps 1 to 5, sections 4.5.5 to 4.5.8 (DS-05 to DS-08), section 4.6.1 (AT-R051 to AT-R057, AT-R071 to AT-R075), and Annex IV entries for sections 4.3.2.3 and 4.3.2.4. EPC135-18 v6.0 (2024-11-28), sections 1 and 3, for the ISO codes DUPL, TECH, FRAD, FOCR, CUST, LEGL, AC04, AM04, NOAS, NOOR, ARDT, AC03 and AM09. Directive (EU) 2015/2366 consolidated 2024-04-08, Article 71(1), read on EUR-Lex.", "confidence": "high" }, "currency": { "effective_since": "2025-10-05", "effective_note": "The 2025 SCT rulebook was issued and took effect on 2025-10-05. Annex IV records that this edition added the single-Recall and single-Request rules, the bar on re-sending after a response, and the Request for Status Update wording. The 10 Banking Business Day and 13 month windows and the 15 Banking Business Day answer are older; the date each first took effect is [Unverified] because earlier editions were not read. The 2026 change request consultation EPC008-26 proposes simpler recall reason code attributes and a longer recall timeline for the duplicate and technical reasons for the 2027 rulebook; nothing is adopted.", "source_edition": "EPC125-05 SCT Scheme Rulebook 2025 version 1.1 (2025-10-05); EPC135-18 v6.0 (2024-11-28); Directive (EU) 2015/2366 consolidated 2024-04-08", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-09/EPC125-05%202025%20SCT%20Rulebook%20version%201.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC125-05 SCT Scheme Rulebook 2025 version 1.1; EPC135-18 v6.0 Guidance on Reason Codes for SCT R-transactions", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the Recall grounds (duplicate, technical fault, fraud only), the 10 banking business day and 13 month windows counted from execution date, the 15 banking business day compulsory response and one-recall-per-transaction rule, the AT-R051 four value range, the seven AT-R057 refusal reasons, the AT-R071 four value RFRO reason range, and the AT-R052 versus AT-R073 not-obliged versus obliged free text asymmetry, all against section 4.3.2.3 and 4.3.2.4 and 4.6.1. Confirms DUPL, TECH, FRAD, FOCR, CUST, LEGL and NOAS as EPC135-18 v6.0 section 3 codes. Does not independently confirm Directive 2015/2366 Article 71(1); EUR-Lex remains unreachable." } ] }, "rail_name": "SEPA Credit Transfer", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sct:refund", "id": "refund", "rail": "sepa-sct", "kind": "rail-fact", "facet": "refund", "name": "Does anyone have a right to be refunded, and on what grounds?", "statement": "The SCT rulebook gives nobody a refund right. It has no refund process at all, which is the sharpest difference between this scheme and SEPA Direct Debit, where a payer can claim its money back for eight weeks with no reason given. The rights that do exist on a credit transfer come from payment services law, and they turn on one question: was the payment authorised. An unauthorised payment has to be refunded almost at once. An authorised one the customer simply regrets has no refund at all, only the Request for Recall, which the beneficiary may turn down.", "details": [ { "label": "No refund in the scheme", "value": "The rulebook's exception processing runs to Rejects, Returns, Recalls and Requests for Recall by the Originator, plus an inquiry process for a missing payment or a wrong value date. None of them is a refund, and no section describes one.", "citation": "EPC125-05 SCT Rulebook 2025 v1.1 (effective 2025-10-05), sections 4.3.2 and 4.4", "rests_on": "rule" }, { "label": "Why there is none", "value": "A credit transfer is pushed by the payer, who authorised it before it moved. The refund rights in payment services law attach to transactions that the payee started, which is the direct debit shape, not this one.", "citation": "Directive (EU) 2015/2366, Article 76(1)", "rests_on": "law" }, { "label": "The eight week right does not exist here", "value": "The no-questions-asked refund that a SEPA Direct Debit payer can claim comes from the same articles, and applies specifically to direct debits under the SEPA Regulation. A payer who sent a credit transfer cannot use it.", "citation": "Directive (EU) 2015/2366, Article 76(1) fourth subparagraph and Article 77(1)", "rests_on": "law" }, { "label": "The one real refund right: an unauthorised payment", "value": "Where the customer did not authorise the transaction, its own PSP has to give the money back at once, and by the end of the next business day at the latest after it learns of the claim, and put the account back as it would have been, with a value date no later than the debit. The one way out is a reasonable suspicion of fraud, which the PSP has to report to its national authority in writing.", "citation": "Directive (EU) 2015/2366, Article 73(1)", "rests_on": "law" }, { "label": "What the customer has to do to keep that right", "value": "Speak up promptly once it knows, and in any case inside thirteen months of the debit. That limit does not apply where the PSP never gave the customer the transaction information it owed.", "citation": "Directive (EU) 2015/2366, Article 71(1)", "rests_on": "law" }, { "label": "What the customer may have to bear", "value": "Up to EUR 50 of the loss where an unauthorised payment came from a lost, stolen or misappropriated instrument. Fraud or gross negligence by the customer removes the protection entirely; a customer that acted in neither way bears nothing.", "citation": "Directive (EU) 2015/2366, Article 74(1)", "rests_on": "law" }, { "label": "The second refund right, from the 2024 amendment", "value": "Verification of payee changed the balance. A PSP that carried out the check properly is not on the hook when the payment goes to the wrong person on a wrong IBAN. A payer's PSP that did not carry it out, and thereby caused a defective payment, has to refund the payer without delay and restore the account.", "citation": "Regulation (EU) No 260/2012 as amended by Regulation (EU) 2024/886, Article 5c(8)", "rests_on": "law" }, { "label": "The refund that is really a liability claim", "value": "Where a payment the customer did authorise was not executed, executed badly or executed late, the payer's PSP owes it the money back without undue delay unless it can show the beneficiary PSP received the funds on time, in which case the duty shifts to that PSP. Either way the customer can demand an immediate trace, free of charge.", "citation": "Directive (EU) 2015/2366, Article 89(1)", "rests_on": "law" }, { "label": "What the scheme offers instead of a refund", "value": "Three things, none of them a right for the customer. A Return, where the account could not be credited, which the receiving PSP owes anyway. A Recall, for the sending bank's own duplicates, technical faults and fraud. A Request for Recall by the Originator for everything else, which is the customer's regret route and depends entirely on the beneficiary agreeing.", "citation": "EPC125-05 SCT Rulebook 2025 v1.1, sections 4.3.2.2, 4.3.2.3 and 4.3.2.4", "rests_on": "rule" }, { "label": "The compensation the scheme does guarantee", "value": "Not to the customer, but between banks. Where a receiving PSP was not the cause of a wrong value date, it can bill the sending PSP interest at the euro short-term rate for the days the money sat wrongly dated, plus a handling fee for the inquiry.", "citation": "EPC125-05 SCT Rulebook 2025 v1.1, sections 4.4.2 and 4.4.4", "rests_on": "rule" } ], "exceptions": [ "A payment to the wrong account because the customer gave the wrong IBAN is not a refund case at all. Law treats the payment as correctly executed towards whoever owns that account, and the customer's PSP owes only a real attempt at recovery (Directive (EU) 2015/2366, Article 88(1) to (3)).", "A payment initiation service provider in the chain does not change the customer's position. The account servicing PSP still refunds immediately, and recovers from the initiation service provider where that provider was at fault (Directive (EU) 2015/2366, Article 73(2)).", "A customer that ignored a verification of payee warning may find its position weaker. The law requires PSPs to tell customers what ignoring such a notification does to PSP liability and to their own refund rights (Regulation (EU) No 260/2012 as amended, Article 5c(7)).", "Outside the EEA the Directive does not apply directly; Participants there take on equivalent obligations through the rulebook, as far as their own law lets them (EPC125-05 2025 v1.1, section 5.14).", "Non-consumer customers can be treated differently. Several of these provisions may be varied by agreement where the customer is not a consumer. [Unverified: Article 61 of Directive (EU) 2015/2366, which sets that out, was not read for this record.]" ], "applies_to": "a payer whose SEPA Credit Transfer was unauthorised, badly executed or sent to the wrong payee, and a payer who simply wants an authorised transfer back", "caveat": "The question to ask first is whether the payment was authorised, because that single fact decides everything. Authorised and regretted leaves the customer with a request its beneficiary can refuse. Unauthorised puts the money back in the account by the end of the next business day. A customer tricked into authorising a payment itself sits between the two, and the EPC texts do not resolve that case.", "related": [ "sepa-sct:finality", "sepa-sct:recall", "sepa-sct:return", "sepa-sct:liability", "sepa-sct:consumer-law", "sepa-sct:decision-points" ], "basis": { "sources": "EPC125-05 SEPA Credit Transfer Scheme Rulebook 2025 version 1.1 (effective 2025-10-05, marked Public), read for this record: sections 4.3.2 (exception processing as a whole), 4.3.2.2, 4.3.2.3, 4.3.2.4, 4.4.2, 4.4.4 and 5.14. Directive (EU) 2015/2366 consolidated 2024-04-08, Articles 71(1), 73, 74(1), 76(1), 77(1), 88 and 89(1), and Regulation (EU) No 260/2012 as amended by Regulation (EU) 2024/886, Article 5c(7) and 5c(8), both read on EUR-Lex for this record.", "confidence": "high" }, "currency": { "effective_since": "2025-10-05", "effective_note": "The 2025 SCT rulebook was issued and took effect on 2025-10-05 and has never contained a refund process. The verification of payee refund duty in Article 5c(8) came from Regulation (EU) 2024/886 and binds PSPs in euro area Member States from 2025-10-09 and PSPs elsewhere from 2027-07-09. The Directive's refund provisions date from the 2015 Directive as transposed nationally; national transposition was not checked for this record.", "source_edition": "EPC125-05 SCT Scheme Rulebook 2025 version 1.1 (2025-10-05); Directive (EU) 2015/2366 consolidated 2024-04-08; Regulation (EU) No 260/2012 as amended by Regulation (EU) 2024/886", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "rail_name": "SEPA Credit Transfer", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": null, "effective_status": "draft", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sct:return", "id": "return", "rail": "sepa-sct", "kind": "rail-fact", "facet": "return", "name": "Is there a return, and what can stop a payment before it settles?", "statement": "Yes, and the two are different things. A Reject ends a transfer before the two PSPs settle. A Return sends a settled transfer back, only the beneficiary PSP can raise one, and it has three Banking Business Days from the Settlement Date to do it. Every permitted reason comes down to the same situation: the money could not be posted to an account using what the message carried. A Return is a duty, not a request, and nobody has to agree to it. It is also closed to a beneficiary who was paid and then changed its mind.", "details": [ { "label": "What a Reject is", "value": "Anything that stops a transfer from running normally before the two PSPs settle. Caught at the point where the customer hands the instruction over, the sending PSP owes its customer nothing more than the reason. Caught between PSPs, it goes back on the DS-03 message.", "citation": "EPC125-05 SCT Rulebook 2025 v1.1 (effective 2025-10-05), section 4.3.2.1", "rests_on": "rule" }, { "label": "Reject timing, and the second chance", "value": "Same day is the expectation, the next Banking Business Day the outside limit, and the CSM is held to the same outside limit for getting the message to the sending PSP. That PSP then either fixes the instruction and sends it again inside the execution time, or tells its customer and puts the money back. A repaired instruction counts as a brand new one with its own clock.", "citation": "EPC125-05 SCT Rulebook 2025 v1.1, section 4.3.2.1 and process step CT-01.03R", "rests_on": "rule" }, { "label": "What a Return is", "value": "The receiving PSP sending a settled transfer back because it cannot post the money to an account on the strength of what the message gave it. A wrong or non-existent account number and a closed account are the standard cases.", "citation": "EPC125-05 SCT Rulebook 2025 v1.1, section 4.3.2.2", "rests_on": "rule" }, { "label": "Return timing and amount", "value": "Three Banking Business Days from the Settlement Date, through the same CSM, message and funds together, for the amount the customer originally instructed. The sending PSP then credits its own customer on whatever timing they agreed.", "citation": "EPC125-05 SCT Rulebook 2025 v1.1, section 4.3.2.2 and process step CT-01.04R", "rests_on": "rule" }, { "label": "Same path, same data, one reference", "value": "Both go back the way the payment came, carrying the original data untouched, unless the two PSPs agreed a different route for a Return. Each keeps enough of the original for an audit trail, quotes the sending PSP's own reference, and carries a reason in AT-R004.", "citation": "EPC125-05 SCT Rulebook 2025 v1.1, sections 4.3.2.1 and 4.3.2.2, with attributes AT-R001 to AT-R004 in section 4.6.1", "rests_on": "rule" }, { "label": "What the reject reasons are", "value": "Available to the sending PSP or the CSM: a bad IBAN, a bad BIC, a duplicate, arrival after the CSM's cut-off, a wrong operation or transaction code or an unusable file format, a regulatory block, no reason given, either PSP not registered under that BIC at the CSM, an ERI transfer the receiver does not support, and a failed settlement.", "citation": "EPC125-05 SCT Rulebook 2025 v1.1, section 4.6.1, attribute AT-R004", "rests_on": "rule" }, { "label": "What the return reasons are", "value": "Available to the receiving PSP: a bad address on the account, a blocked account with no reason stated, a closed account, a bad account identifier, a bad BIC, a dead beneficiary, the beneficiary's own instruction, an account type that cannot take a credit transfer, a duplicate, a wrong operation or transaction code or an unusable file format, a regulatory block, an ERI transfer it does not support, its own BIC not registered at the CSM, and no reason given.", "citation": "EPC125-05 SCT Rulebook 2025 v1.1, section 4.6.1, attribute AT-R004", "rests_on": "rule" }, { "label": "Which ISO code goes with which reason", "value": "The EPC's guidance turns each rulebook reason into an ISO 20022 code and says which R-transaction may carry it. Usable on both: AC01 for a bad or non-existent account identifier, RC01 for a bad PSP identifier, AM05 for a duplicate, CNOR where the receiving PSP is not registered under that BIC. Return only: AC04 closed, AC06 blocked, AG01 wrong type of account, BE04 address missing or unusable, MD07 beneficiary has died. Reject only: TM01 after a CSM cut-off, DNOR where the sending PSP is not registered, ED05 where settlement failed.", "citation": "EPC135-18 v6.0 (2024-11-28), sections 1 and 3", "rests_on": "guidance" }, { "label": "The line a Return may not cross", "value": "Once the money is on the beneficiary's account, a Return is off the table. The beneficiary sends a fresh SEPA Credit Transfer instead, and where it does not hold the originator's IBAN it may quote an alternative identifier, if its PSP has agreed to offer that service.", "citation": "EPC125-05 SCT Rulebook 2025 v1.1, sections 4.3.2.2 and 4.5.1 remarks", "rests_on": "rule" }, { "label": "Where a Return sits against the law", "value": "Law treats the IBAN as the whole of the instruction: pay that account and the payment counts as correct towards the person it belongs to. A customer who gave the wrong IBAN loses the non-execution claim, but its PSP still owes a real attempt at recovery and the other PSP owes cooperation. A Return is the scheme's automated version of that recovery for the case where the account does not exist at all.", "citation": "Directive (EU) 2015/2366, Article 88(1) to (3)", "rests_on": "law" } ], "exceptions": [ "Some SEPA countries will not allow MD07 for data protection reasons. Where that is so, the guidance points at MS03 instead (EPC135-18 v6.0, section 3).", "MS03 is for the case where national law blocks a precise answer. Participants are told not to fall back on general codes where a specific one is available and lawful in the receiving PSP's country (EPC135-18 v6.0, sections 2 and 3).", "The leg from a sending PSP back to its own customer may follow a route the two of them agreed, rather than the path the payment took (EPC125-05 2025 v1.1, section 4.3.2.2).", "A Participant outside the ERI option that receives Extended Remittance Information has to send the transfer back, as a Reject or a Return depending on whether it has settled yet (EPC125-05 2025 v1.1, section 2.7).", "The two windows do not start on the same day. Three Banking Business Days for a Return counts from the Settlement Date; the Recall windows count from the execution date (EPC125-05 2025 v1.1, sections 4.3.2.2 and 4.3.2.3).", "Nothing in the scheme governs sending a returned payment again. A corrected payment is simply a new instruction with a new clock (EPC125-05 2025 v1.1, CT-01.03R). [Inference: the rulebook is silent on re-presentment, which is not the same as permitting it without limit.]" ], "applies_to": "SEPA Credit Transfers stopped before inter-PSP settlement by a Reject, and settled SEPA Credit Transfers sent back by the beneficiary PSP as a Return", "caveat": "SEPA vocabulary is precise and does not map onto ACH. A Reject is before settlement, a Return is after settlement, a Recall is a request by the sending bank, and a Request for Recall by the Originator is a request by the sending customer. Only the Return moves money back without anyone agreeing, and only where the account could not be credited.", "related": [ "sepa-sct:finality", "sepa-sct:recall", "sepa-sct:refund", "sepa-sct:messages", "sepa-sct:liability", "sepa-sct:decision-points" ], "basis": { "sources": "EPC125-05 SEPA Credit Transfer Scheme Rulebook 2025 version 1.1 (effective 2025-10-05, marked Public), read for this record: sections 2.7, 4.3.2.1 (Reject), 4.3.2.2 (Return), 4.3.2.3 (Recall, for the contrast), process steps CT-01.02R, CT-01.03R and CT-01.04R, 4.5.1 remarks, 4.5.3 (DS-03), 4.6.1 (AT-R001 to AT-R005). EPC135-18 v6.0 (2024-11-28), Guidance on reason codes for SCT R-transactions, sections 1, 2 and 3. Directive (EU) 2015/2366 consolidated 2024-04-08, Article 88, read on EUR-Lex.", "confidence": "high" }, "currency": { "effective_since": "2025-10-05", "effective_note": "The 2025 SCT rulebook was issued and took effect on 2025-10-05, and EPC135-18 v6.0 of 2024-11-28 states that it covers the 2023 and 2025 SCT rulebooks. Annex IV to the 2025 rulebook records no change to the Reject or Return sections. The three Banking Business Day Return window predates this edition; the date it first took effect is [Unverified] because earlier editions were not read.", "source_edition": "EPC125-05 SCT Scheme Rulebook 2025 version 1.1 (2025-10-05); EPC135-18 v6.0 (2024-11-28); Directive (EU) 2015/2366 consolidated 2024-04-08", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-09/EPC125-05%202025%20SCT%20Rulebook%20version%201.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC125-05 SCT Scheme Rulebook 2025 version 1.1; EPC135-18 v6.0 Guidance on Reason Codes for SCT R-transactions", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms Reject before settlement with next banking business day outside limit and repair-and-resend right (4.3.2.1, CT-01.03R), Return by beneficiary PSP within three banking business days of settlement date for the original amount, closed to a beneficiary who was already credited (4.3.2.2, CT-01.04R), the full AT-R004 reject and return reason lists including bad IBAN, bad BIC, duplicate, cut-off, regulatory reason and ERI option not supported (4.6.1), the ERI participant reject-or-return-depending-on-settlement rule word for word (2.7), and against EPC135-18 v6.0 section 3 the AC01, RC01, AM05, CNOR reason code mappings and the MD07 to MS03 data-protection substitution named in the exceptions. Does not independently confirm Directive 2015/2366 Article 88; EUR-Lex remains unreachable (HTTP 202 automated-access challenge)." } ] }, "rail_name": "SEPA Credit Transfer", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sct:settlement", "id": "settlement", "rail": "sepa-sct", "kind": "rail-fact", "facet": "settlement", "name": "How does settlement work, when does it happen, and in what money?", "statement": "The SCT scheme does not settle anything. It is a set of inter-PSP rules deliberately kept apart from infrastructure, and clearing and settlement belong to whichever CSM each Participant picked. The rulebook says what settlement is, puts a Settlement Date on every inter-PSP message, and hangs the Return window off that date. It does not say when settlement happens, in what money it happens, or in which system. Everything, including every exception message, is denominated in euro.", "details": [ { "label": "What settlement means here", "value": "The glossary treats it as the point where the debt between the two PSPs is cleared, and the Settlement Date as the day that happens. Nothing about the customer's account is part of the definition.", "citation": "EPC125-05 SCT Rulebook 2025 v1.1 (effective 2025-10-05), chapter 7 Defined Terms, entries Settlement and Settlement Date", "rests_on": "rule" }, { "label": "Who does it", "value": "One rulebook, many infrastructures: that is stated as a design choice. The CSM takes the transactions in, clears them, passes them on, carries the Return, Reject and Recall traffic, and puts the arrangements in place for the two PSPs to settle.", "citation": "EPC125-05 SCT Rulebook 2025 v1.1, sections 1.5 and 3.3", "rests_on": "rule" }, { "label": "The scheme names no CSM and no settlement model", "value": "What a Participant agrees with its CSM falls outside the scheme, and a CSM need not even be one company: clearing and settlement can sit with different actors. So a settlement cycle, a netting run or a cut-off observed at one CSM says nothing about the scheme.", "citation": "EPC125-05 SCT Rulebook 2025 v1.1, sections 3.1 (CSMs), 3.2 relationship 5, and 4.2.2 (cut-off times are out of scope of the rulebook)", "rests_on": "rule" }, { "label": "The Settlement Date travels on the message", "value": "AT-T051 carries it on the inter-PSP payment and is mandatory. Exception traffic carries its own: AT-R005 on a Return, AT-R056 on a positive answer to a Recall.", "citation": "EPC125-05 SCT Rulebook 2025 v1.1, sections 4.5.2 (DS-02) and 4.6.1 (AT-T051, AT-R005, AT-R056)", "rests_on": "rule" }, { "label": "What the Settlement Date governs", "value": "It starts the Return clock: three Banking Business Days from it, and the beneficiary PSP must have sent both the message and the money. The Recall clock is a different one, counted from the execution date of the original transaction instead.", "citation": "EPC125-05 SCT Rulebook 2025 v1.1, sections 4.3.2.2 with CT-01.04R, and 4.3.2.3", "rests_on": "rule" }, { "label": "Which days count", "value": "Inter-PSP deadlines run on Banking Business Days, which the glossary pins to T2 days, and that unit covers the payment, the R-transactions and the inquiries alike. A duty landing on any other day slides to the next Banking Business Day.", "citation": "EPC125-05 SCT Rulebook 2025 v1.1, section 4.2.3 and chapter 7 Defined Terms, entry Banking Business Day", "rests_on": "rule" }, { "label": "The money", "value": "Euro throughout, payments and exception messages alike. The two accounts can be denominated in anything; if a conversion is needed, one of the two PSPs does it outside the scheme's rules.", "citation": "EPC125-05 SCT Rulebook 2025 v1.1, section 2.4", "rests_on": "rule" }, { "label": "The full amount travels, and charges are shared", "value": "Nobody takes a slice out of the transfer on the way. Each side pays its own bank, which is what the scheme calls the SHA principle, and the law puts a matching duty on both PSPs and any intermediary to pass the amount on whole.", "citation": "EPC125-05 SCT Rulebook 2025 v1.1, sections 1.7 and 4.2.4 and chapter 7 entry Share or SHA; Directive (EU) 2015/2366, Article 81(1)", "rests_on": "law" }, { "label": "Value dating at the receiving end", "value": "The payee's value date cannot be later than the business day its PSP got the money, and where no conversion is involved, or only one between Member State currencies, the payee must be able to use the funds as soon as they land. The scheme's inquiry process is the machinery for fixing a value date that came out wrong.", "citation": "Directive (EU) 2015/2366, Article 87(1) and (2); EPC125-05 SCT Rulebook 2025 v1.1, section 4.4.2", "rests_on": "law" }, { "label": "Compensation when the value date was wrong", "value": "A beneficiary PSP that did not cause the error can bill the originator PSP for the interest lost. The calculation is the euro short-term rate as it stood on the first Banking Business Day of the month, on a 360 day basis, across the calendar days between the wrong value date and the right one, and only where that rate is above zero. A handling fee for the inquiry may be added on top.", "citation": "EPC125-05 SCT Rulebook 2025 v1.1, sections 4.4.2 and 4.4.4, with DS-10 attributes AT-Q006 and AT-Q007 and DS-11", "rests_on": "rule" } ], "exceptions": [ "Participants, and groups of them, may hold settlement and value limits against each other through their CSMs for risk reasons. Those are private arrangements, not scheme limits (EPC125-05 2025 v1.1, section 2.5).", "Settlement can itself be the thing that fails, and the scheme has a reject reason for exactly that, which the guidance maps to ISO code ED05 (EPC125-05 2025 v1.1, section 4.6.1; EPC135-18 v6.0, section 3).", "Miss a CSM's own deadline and the transaction comes back as TM01. The deadline belongs to the CSM; the rulebook does not set it (EPC125-05 2025 v1.1, sections 4.2.2 and 4.6.1; EPC135-18 v6.0, section 3).", "Where one Participant is on both ends there is no inter-PSP settlement to do. The rulebook allows that case without describing it (EPC125-05 2025 v1.1, section 3.1).", "Which CSMs reach each other, and whether the final leg lands in central bank money, is outside the rulebook. [Unverified: no CSM documentation was read for this record.]" ], "applies_to": "the inter-PSP leg of a SEPA Credit Transfer, between the originator PSP and the beneficiary PSP, through whichever CSM those Participants use", "caveat": "An answer about SEPA settlement timing cannot come from the rulebook. It comes from the CSM, and the CSM's detailed operational rules are participant material. When an agent needs to know when money actually moved, the honest answer is that the scheme sets a Settlement Date on the message and a maximum execution time to the beneficiary PSP's account, and everything else is the CSM's.", "related": [ "sepa-sct:finality", "sepa-sct:hours", "sepa-sct:limits", "sepa-sct:return", "sepa-sct:messages", "sepa-sct:participants" ], "basis": { "sources": "EPC125-05 SEPA Credit Transfer Scheme Rulebook 2025 version 1.1 (effective 2025-10-05, marked Public), read for this record: sections 1.5, 1.7, 2.4, 2.5, 3.1, 3.2, 3.3, 4.2.2, 4.2.3, 4.2.4, 4.3.2.2 with CT-01.04R, 4.3.2.3, 4.4.2, 4.4.4, 4.5.2 (DS-02), 4.6.1 (AT-T051, AT-R004, AT-R005, AT-R056, AT-Q006, AT-Q007), chapter 7 (Settlement, Settlement Date, Banking Business Day, Share or SHA). EPC135-18 v6.0 (2024-11-28), section 3, for the ISO codes ED05 and TM01. Directive (EU) 2015/2366 consolidated 2024-04-08, Articles 81 and 87, read on EUR-Lex.", "confidence": "high" }, "currency": { "effective_since": "2025-10-05", "effective_note": "The 2025 SCT rulebook was issued and took effect on 2025-10-05. Annex IV to that edition records a change of TARGET2 into T2 in the Banking Business Day definition in chapter 7. The separation of scheme from infrastructure and the euro-only rule are much older; the date each first took effect is [Unverified] because earlier editions were not read.", "source_edition": "EPC125-05 SCT Scheme Rulebook 2025 version 1.1 (2025-10-05); EPC135-18 v6.0 (2024-11-28); Directive (EU) 2015/2366 consolidated 2024-04-08", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-09/EPC125-05%202025%20SCT%20Rulebook%20version%201.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC125-05 SCT Scheme Rulebook 2025 version 1.1", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms settlement/settlement date glossary entries and that the scheme names no CSM or settlement model (sections 1.5, 3.1, 3.2, 3.3, 4.2.2 cut-off out of scope), euro-only processing including exceptions (2.4), value limits as private CSM arrangements (2.5), Settlement Date starting the three banking business day return clock while the recall clock runs from execution date (4.3.2.2, 4.3.2.3), Banking Business Day defined as a T2 day (chapter 7), the SHA charging principle and full-amount pass-through (1.7, 4.2.4), value dating and interest compensation on the euro short-term rate over a 360 day basis (4.4.2, 4.4.4), and the ED05/TM01 reason codes for settlement and CSM deadline failures against EPC135-18 v6.0 section 3. Does not independently confirm PSD2 Article 81 pass-through duty or Article 87 value-dating rule; EUR-Lex remains unreachable." } ] }, "rail_name": "SEPA Credit Transfer", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sct-inst:consumer-law", "id": "consumer-law", "rail": "sepa-sct-inst", "kind": "rail-fact", "facet": "consumer-law", "name": "What consumer law applies, and what does it give a consumer that the rules do not?", "statement": "The rulebook binds banks to each other and gives a customer nothing directly. A consumer's position comes from the Payment Services Directive as nationally transposed and from the SEPA Regulation, and on this rail the 2024 amendment to that Regulation did most of the work. It made instant payments something every bank has to offer, stopped them being priced above ordinary transfers, made verification of payee free and compulsory, gave the customer its own sending limit, and required a free notification of whether the money arrived. Those are rights that did not exist before 2024 and that the rulebook alone would never have given. The duty to check the payee is the law's. How the check runs between banks that join the EPC Verification Of Payee scheme, meaning what an answer can say, how long the payer's bank may wait for it and what the payer is told when none comes, is set by that scheme's rulebook, not by the law.", "details": [ { "label": "Which instruments the rulebook names", "value": "Participation is conditional on complying with the SEPA Regulation, the Regulation on information accompanying transfers of funds, and Titles III and IV of the Payment Services Directive as they affect credit transfers made under this scheme.", "citation": "EPC004-16 SCT Inst Rulebook 2025 v1.1 (effective 2025-10-05), section 5.1", "rests_on": "rule" }, { "label": "The rulebook gives a customer no rights", "value": "The rulebook is a contract among the EPC and the Participants. Anyone who is not a party to it takes neither rights nor obligations from it, and a customer is not a party.", "citation": "EPC004-16 SCT Inst Rulebook 2025 v1.1, section 5.2", "rests_on": "rule" }, { "label": "The right to have the service at all", "value": "Any bank already offering ordinary credit transfers both ways must offer instant ones to every customer, and an account that can take an ordinary transfer must take an instant one at any hour of any day. Euro area banks were due to receive from 9 January 2025 and to send from 9 October 2025; banks elsewhere in the Union, and payment and e-money institutions everywhere, follow in 2027.", "citation": "Regulation (EU) No 260/2012 as amended by Regulation (EU) 2024/886, Article 5a(1) and 5a(8), read in the consolidated text of 2024-04-08", "rests_on": "law" }, { "label": "The right not to be overcharged for speed", "value": "Speed cannot cost more. Whatever a bank charges a payer or a payee for an ordinary credit transfer of a given type is the ceiling for an instant one of the same type. Binding on euro area banks since 9 January 2025 and on the rest of the Union from 9 January 2027.", "citation": "Regulation (EU) No 260/2012 as amended by Regulation (EU) 2024/886, Article 5b(1) and (3)", "rests_on": "law" }, { "label": "The right to be warned before paying (IPR)", "value": "From the IPR, not from any rulebook. The payer's bank has to offer the check on every channel it offers for credit transfers, ordinary or instant, and has to run it once the payee details are in and before the payer is given the chance to authorise. With a name and an IBAN, the comparison is made by the payee's bank at the payer's bank's request. A near miss is shown to the payer as the name the payee's bank actually holds; a mismatch is reported together with a warning that authorising may send the money to an account the named payee does not hold. Where the payee is a legal person and the bank lets payers name it by a fiscal number, a European unique identifier or an LEI instead of a name, the payee's bank checks that identifier against the IBAN if it holds it, and a mismatch is reported the same way. Whatever the result, the payer can still authorise. The service is free to every customer, consumer or business. Euro area banks owe it from 9 October 2025, the rest of the Union from 9 July 2027.", "citation": "Regulation (EU) No 260/2012 as amended by Regulation (EU) 2024/886, Article 5c(1)(a) and (b), 5c(5), 5c(7) and 5c(9), and Article 5b(2)", "rests_on": "law" }, { "label": "What a warning ignored costs (IPR)", "value": "From the IPR. Banks must tell customers in advance how ignoring a payee check notification affects the bank's liability and the customer's refund rights. A bank that met its checking duties keeps the protection the Payment Services Directive gives it when money goes astray on a wrong unique identifier. If the payer's bank did not run the check properly, or a payment initiation service provider supplied wrong payee details, and a defective payment followed, the payer's bank refunds the payer without delay and restores the account; if the fault lay with the payee's bank or the initiation provider, that party makes good the payer's bank's loss. Any further loss to the payer is left to the contract and the law governing it.", "citation": "Regulation (EU) No 260/2012 as amended by Regulation (EU) 2024/886, Article 5c(7) and 5c(8)", "rests_on": "law" }, { "label": "What a payee check can answer (VOP rulebook)", "value": "From the EPC VOP rulebook; the law itself speaks only of a match, a mismatch and a near miss. For a name and IBAN check the payee's bank returns one of four results: match, close match (sent back with the name it holds for the account), no match, or verification check not possible. For a business payee, payer and bank may agree to check an identification code such as a VAT number or an LEI in place of the name, once the payer's bank has confirmed the payee's bank holds that kind of code; that check has no close match, and the payee's bank may instead answer that it does not support or know the code. On the wire the four name results are MTCH, CMTC, NMTC and NOAP.", "citation": "EPC218-23 Verification Of Payee Scheme Rulebook 2026 v1.1 (effective 2026-09-20), sections 3.2 and 3.2.1 with attributes AT-R001, AT-R010 and AT-R011; EPC103-24 VOP Inter-PSP API Specifications 2026 v1.1.1 (effective 2026-09-20), sections 4.2.5 and 4.2.6", "rests_on": "rule" }, { "label": "What each answer means is the payee's bank's call (VOP rulebook)", "value": "From the EPC VOP rulebook and the EPC's matching recommendations, not from the law. The bank holding the account decides whether a name matches and carries the liability for the answer it gives. What a payer should expect to see: a small slip, such as swapped letters, an initial for a first name or a known abbreviation, is meant to come back as a close match rather than a no match, and a close match only ever reveals the name of the holder the payer named, never that of a joint holder. The recommendations sit outside the rulebook and can be revised outside its change cycle.", "citation": "EPC288-23 EPC Recommendations for the Matching Processes v1.0 (2024-10-10), sections I, II and IV; EPC218-23 Verification Of Payee Scheme Rulebook 2026 v1.1 (effective 2026-09-20), sections 1.3 and 1.4", "rests_on": "guidance" }, { "label": "How long the check may take, and what silence means (VOP rulebook)", "value": "From the EPC VOP rulebook; the law gives no number of seconds, only that the check runs as soon as the payee details are given. Five seconds at most from the time stamp on the request to the answer arriving, with one second or less the stated preference; banks may agree a shorter limit between themselves. If nothing arrives in five seconds the payer's bank treats it as verification check not possible, tells the payer at once, and may offer to run the check again; an answer that turns up after the payer has been told is thrown away. For no match, not possible, or no answer at all the payer also gets the warning that authorising may send the money to an account the intended payee does not hold. How that warning is worded is left to each bank, and telling the payer about a match is optional.", "citation": "EPC218-23 Verification Of Payee Scheme Rulebook 2026 v1.1 (effective 2026-09-20), sections 3.3.1, 3.3.2 and 3.4 process steps PT-01.07 and PT-01.07R", "rests_on": "rule" }, { "label": "What the check covers (VOP rulebook)", "value": "From the EPC VOP rulebook. A check before an SCT or an SCT Inst to a payment account held at a PSP in a SEPA scheme country, available around the clock. Where the payer's own bank holds the account it checks it itself. The payer's bank must check whatever details it was given, save for exemptions the law allows and the payer agreed to. Between banks each request concerns one account, but a customer and its bank may agree to submit many as a bulk request. The payment that follows is outside the scheme, and the scheme may not be used to identify anyone for any purpose other than the intended payment.", "citation": "EPC218-23 Verification Of Payee Scheme Rulebook 2026 v1.1 (effective 2026-09-20), sections 1.3, 1.4, 3.2 and 3.5.1", "rests_on": "rule" }, { "label": "Who pays for the check between banks (VOP rulebook)", "value": "The VOP rulebook sets no charge between the payer's and the payee's bank for a check. Version 1.0 dropped the section on charging principles that the 2024 consultation draft, v0.1, had carried, and what remains is the EPC's right to charge members scheme fees. The payer's bank must still tell its customers about any charges that apply to the service. The law settles the customer side: under the IPR the check is free to every customer, business as well as consumer.", "citation": "EPC218-23 Verification Of Payee Scheme Rulebook 2026 v1.1 (effective 2026-09-20), sections 4.7 point 26 and 5.4, and Annex III entry for section 3.4 in the list of changes to v1.0; Regulation (EU) No 260/2012 as amended by Regulation (EU) 2024/886, Article 5b(2)", "rests_on": "rule" }, { "label": "What a wrong answer costs a bank (VOP rulebook and IPR)", "value": "Two regimes. Under the EPC VOP rulebook, between members only: the bank whose breach, negligence or operational failure on a check causes the other a loss is liable for it, up to the amount of the payment the check was for, a cap that survives gross negligence and falls away only for wilful intent, and that leaves the payer's own claims under law untouched. Under the IPR, which binds Union PSPs whether or not they joined the scheme: where the payee's bank failed its checking duty and the payer's bank had to refund, the payee's bank compensates the payer's bank for its financial damage, and the Article states no cap.", "citation": "EPC218-23 Verification Of Payee Scheme Rulebook 2026 v1.1 (effective 2026-09-20), sections 4.9.1 and 4.9.2; Regulation (EU) No 260/2012 as amended by Regulation (EU) 2024/886, Article 5c(8) third subparagraph", "rests_on": "rule" }, { "label": "The customer's own limit", "value": "An instant order that would breach a limit the customer has set is simply not carried out, and the bank must say so and show how the limit can be changed. The limit itself is the customer's to ask for and to shape: per payment or per day, whichever the customer picks, and adjustable at any time before an order is placed.", "citation": "Regulation (EU) No 260/2012 as amended by Regulation (EU) 2024/886, Article 5a(6)", "rests_on": "law" }, { "label": "The right to be told what happened, free", "value": "The payer's bank must tell the payer, at no charge, whether the money has been made available on the payee's account, and must do so the moment the confirmation arrives or, failing one, once ten seconds have passed. A payment initiation service provider that started the payment gets the same answer. Without a confirmation in those ten seconds the payer's bank must also put the account straight back as if the payment had never been made. The SCT Inst rulebook carries a matching duty on the sending PSP to inform the originator of either outcome, and leaves the wording and channel to the PSP.", "citation": "Regulation (EU) No 260/2012 as amended by Regulation (EU) 2024/886, Article 5a(4)(e) and 5a(5); EPC004-16 2025 v1.1, sections 3.1 and 4.2.3 B", "rests_on": "law" }, { "label": "Sanctions screening stops delaying payments", "value": "Screening against EU targeted financial sanctions happens on the customer base, not on each payment. A bank offering instant transfers checks all its customers at least once every calendar day, and straight away whenever such a measure is adopted or amended; in return, neither bank in a live instant transfer screens the payer or payee against those measures again while it runs. Other sanctions regimes and anti money laundering duties are untouched. Binding on every bank offering instant transfers from 9 January 2025.", "citation": "Regulation (EU) No 260/2012 as amended by Regulation (EU) 2024/886, Article 5d(1) to (3)", "rests_on": "law" }, { "label": "The older protections still apply", "value": "From the Payment Services Directive, as each Member State transposed it. An unauthorised payment is refunded at once and by the end of the next business day at the latest, unless the bank has reasonable grounds to suspect fraud and reports them in writing to the national authority. When a customer disputes authorisation or execution, it is the bank that must prove the payment was authenticated, correctly recorded and not affected by a technical fault. A payer's share of losses on a lost, stolen or misappropriated instrument stops at EUR 50, with no cap where the payer acted fraudulently or with intent or gross negligence. A payment not executed, defective or late is the banks' liability, except where the payer gave a wrong unique identifier. To obtain rectification the customer must notify without undue delay and within thirteen months of the debit, a limit that does not run if the bank failed to give the required payment information.", "citation": "Directive (EU) 2015/2366, Articles 71(1), 72, 73(1), 74(1), 88(2) and 89", "rests_on": "law" } ], "exceptions": [ "Business customers sending payment orders as a package may switch the payee check off, and back on at any time; consumers have no such option. When a business opts out, its bank has to warn it that the money may reach an account the intended payee does not hold (Regulation (EU) No 260/2012 as amended, Article 5c(6) and (7)).", "The rulebook warns that its own defined terms do not always carry the meaning the Payment Services Directive or the SEPA Regulation give the same or similar words (EPC004-16 2025 v1.1, section 0.1.1).", "The Directive is a directive, so what a consumer holds is the national transposition in its own Member State. [Unverified: no national transposition was read for this record.]", "A customer that is not a consumer may agree with its bank to set aside, wholly or partly, the Directive's rules on the burden of proof, the payer's EUR 50 cap and execution liability, among others, and to agree a different notification limit; Member States may extend consumer treatment to microenterprises (Directive (EU) 2015/2366, Article 61(1) and (3)).", "Outside the EEA, SEPA scheme countries including the United Kingdom and Switzerland are bound by neither instrument. Participants there take on obligations the rulebook calls substantially equivalent, as far as their own law allows, so the instant payment rights described here may simply not exist for their customers (EPC004-16 2025 v1.1, section 5.14).", "Banks outside the euro area get later deadlines throughout. With supervisory permission, one may also cap instant sending from national currency accounts at a per transaction limit of at least EUR 25 000 during hours when it handles no ordinary euro transfers for those accounts (Regulation (EU) No 260/2012 as amended, Articles 5a(2) and 5a(8)).", "The law has no list of exempt accounts for the payee check. What it does carve out: business customers who opt out for packages (Article 5c(6)); a paper order, which is checked when the bank receives it and not at all if the payer is not there at that moment (Article 5c(4)); and channels where the payer does not enter both IBAN and name, where the bank must instead let the payer confirm the payee some other way before authorising (Article 5c(1)(d)). Payments the Regulation does not cover at all, such as card payments and transfers between PSPs for their own account, carry no duty (Article 1(2)). The VOP rulebook defers to these carve-outs, requiring a check of all details given save legal exemptions the payer agreed to (EPC218-23 2026 v1.1, section 1.3)." ], "applies_to": "a consumer payer or payee on a SEPA Instant Credit Transfer whose account is held in an EEA Member State, with the national transposition of the Payment Services Directive applying to it, and the payee check the amended SEPA Regulation requires before such a payment, including where it runs under the EPC Verification Of Payee scheme", "caveat": "Almost everything a consumer gains on this rail came from the 2024 Regulation rather than from the scheme, and it is all preventive: a warning before paying, a limit the customer sets, a price cap, a notification. Once an instant payment has gone, consumer law does no more for it than it does for an ordinary SEPA Credit Transfer, and the money is already spendable.", "related": [ "sepa-sct-inst:finality", "sepa-sct-inst:liability", "sepa-sct-inst:refund", "sepa-sct-inst:limits", "sepa-sct-inst:participants", "sepa-sct-inst:decision-points", "sepa-sct-inst:hours" ], "basis": { "sources": "EPC004-16 SEPA Instant Credit Transfer Scheme Rulebook 2025 version 1.1 (effective 2025-10-05, marked Public), read for this record: sections 0.1.1, 3.1, 4.2.3 B, 5.1, 5.2, 5.7 point 4, 5.8 point 9, 5.14, and Annex IV. Regulation (EU) No 260/2012 as amended by Regulation (EU) 2024/886, Articles 1(1) and 1(2), 5a(1), 5a(2), 5a(4)(e), 5a(5), 5a(6), 5a(8), 5b, 5c and 5d, read in the consolidated text of 2024-04-08, and Directive (EU) 2015/2366, Articles 61, 71(1), 72, 73(1), 74(1), 88 and 89, read in its Official Journal text; both read from the Publications Office PDFs saved on 2026-09-24, whose public addresses are https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02012R0260-20240408 and https://eur-lex.europa.eu/eli/dir/2015/2366/oj. Also read for this record from the copies saved on 2026-09-23: EPC218-23 Verification Of Payee Scheme Rulebook 2026 v1.1 (issued 2026-03-16, effective 2026-09-20), sections 1.3, 1.4, 3.2, 3.2.1, 3.3.1, 3.3.2, 3.4, 3.5.1, 3.6.1, 4.7, 4.9, 5.4 and Annex III; EPC103-24 VOP Inter-PSP API Specifications 2026 v1.1.1, sections 4.2.5 and 4.2.6; EPC288-23 EPC Recommendations for the Matching Processes v1.0 (2024-10-10), sections I to IV.", "confidence": "high" }, "currency": { "effective_since": "2026-09-20", "effective_note": "The payee check lines rest on the 2026 Verification Of Payee rulebook v1.1 and API specification v1.1.1, both effective 2026-09-20 at 03:30 CET, which is why the record as a whole is dated from then; the matching recommendations are v1.0 of 2024-10-10 and can change outside the rulebook cycle. The 2025 SCT Inst rulebook was issued and took effect on 2025-10-05, four days before the 2025-10-09 deadline for euro area banks to offer sending instant credit transfers and to run verification of payee. The charges rule bound euro area banks, and the sanctions screening regime every bank offering instant transfers, from 2025-01-09. Banks outside the euro area follow between 2027-01-09 and 2028-06-09 depending on the obligation. The successor payment services package was not read for this record, so what may change is [Unverified].", "source_edition": "EPC004-16 SCT Inst Scheme Rulebook 2025 version 1.1 (2025-10-05); Regulation (EU) No 260/2012 as amended by Regulation (EU) 2024/886 (consolidated text of 2024-04-08); Directive (EU) 2015/2366 (Official Journal text of 2015-12-23); EPC218-23 Verification Of Payee Scheme Rulebook 2026 version 1.1 (2026-09-20); EPC103-24 VOP Inter-PSP API Specifications 2026 version 1.1.1 (2026-09-20); EPC288-23 v1.0 (2024-10-10)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-10/EPC004-16%202025%20SCT%20Instant%20Rulebook%20v1.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC004-16 SCT Inst Scheme Rulebook 2025 v1.1", "checked_on": "2026-09-24", "checked_by": "Claude validator (Sonnet)", "notes": "Confirms section 5.1: participation is conditional on complying with the SEPA Regulation, the funds-transfer information Regulation, and Titles III and IV of the Payment Services Directive as they affect this scheme's credit transfers. Confirms section 5.2: the rulebook is a contract among the EPC and Participants and gives no rights or obligations to anyone who is not a party to it, including a customer." }, { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2026-03/EPC218-23%20v1.1%202026%20Verification%20Of%20Payee%20Scheme%20Rulebook_0.pdf", "source_class": "authoritative_primary", "source_title": "EPC218-23 Verification Of Payee Scheme Rulebook 2026 v1.1", "checked_on": "2026-09-24", "checked_by": "Claude validator (Sonnet)", "notes": "Confirms section 3.2.1 and table 1: a name-and-IBAN check answers Match, No Match, Close Match with the held name, or Verification check not possible, and an identification-code check answers only Match, No Match or Verification check not possible, with no close match. Confirms section 3.3.2: the maximum execution time is 5 seconds, preferably 1 second or less, with a shorter bilateral or multilateral limit allowed. Confirms sections 4.9.1 and 4.9.2: a Participant is liable to another for loss from its breach, negligence or operational failure on a VOP request, capped at the payment amount, the cap surviving gross negligence but not wilful intent, without prejudice to claims under applicable law. Confirms section 4.7 point 26: a Requesting PSP must tell its Requesters about charges that apply to the service." }, { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2026-05/EPC103-24%20v1.1.1%20VOP%20API%20Specifications.pdf", "source_class": "authoritative_primary", "source_title": "EPC103-24 VOP Inter-PSP API Specifications 2026 v1.1.1", "checked_on": "2026-09-24", "checked_by": "Claude validator (Sonnet)", "notes": "Confirms sections 4.2.5 and 4.2.6: the wire codes for a name check are MTCH (Match), NMTC (No Match), CMTC (Close Match) and NOAP (Verification Check Not Possible)." }, { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2024-10/EPC288-23%20v1.0%20EPC%20Recommendations%20for%20the%20Matching%20Processes%20under%20the%20VOP%20Scheme%20Rulebook_0.pdf", "source_class": "authoritative_primary", "source_title": "EPC288-23 EPC Recommendations for the Matching Processes under the VOP Scheme Rulebook v1.0", "checked_on": "2026-09-24", "checked_by": "Claude validator (Sonnet)", "notes": "Confirms the Close Match scenarios: an inverted pair of letters, an initial standing in for a first name, and a commonly accepted abbreviation are each listed as grounds for a Close Match rather than a No Match. Confirms that with a Close Match response the Responding PSP discloses only the name of the Payment Counterparty named in the request and not the name of any other holder of the account. Confirms section IV: these recommendations can be revised by the PSMB outside the VOP rulebook's own change management cycle." }, { "source_url": "https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02012R0260-20240408", "source_class": "authoritative_primary", "source_title": "Regulation (EU) No 260/2012 (SEPA Regulation), consolidated text of 2024-04-08", "checked_on": "2026-09-24", "checked_by": "Claude validator (Sonnet)", "notes": "The copy read was the Official Journal PDF from the EU Publications Office, saved 2026-09-24. Confirms Article 5a(1), 5a(4)(e), 5a(5), 5a(6) and 5a(8) on the right to the instant service, the free arrival notification within 10 seconds and the fallback undo, and the customer's own sending limit with its staged compliance dates. Confirms Article 5b(1) to (3) on the charge ceiling and the free payee-verification service. Confirms Article 5c(1)(a), (1)(b), (1)(d), (4), (5), (6), (7), (8) and (9) on the warning before paying, its near-match and mismatch wording, the business opt-out and its own warning, the paper-order and non-IBAN-and-name carve-outs, what a wrong answer costs each PSP with no stated cap on the payee PSP's compensation, and the compliance dates. Confirms Article 5d(1) to (3) on once-daily plus event-triggered sanctions screening of the customer base and the ban on screening the same transaction again during execution." }, { "source_url": "https://eur-lex.europa.eu/eli/dir/2015/2366/oj", "source_class": "authoritative_primary", "source_title": "Directive (EU) 2015/2366 (PSD2), Official Journal text", "checked_on": "2026-09-24", "checked_by": "Claude validator (Sonnet)", "notes": "The copy read was the Official Journal PDF from the EU Publications Office, saved 2026-09-24. Confirms Article 61(1) and (3): a non-consumer payment service user may agree to set aside Articles 72, 74, 76, 77, 80 and 89 and different time limits from Article 71, and Member States may extend consumer treatment to microenterprises. Confirms Article 71(1): rectification needs notice without undue delay and within 13 months of the debit, a limit suspended where the PSP failed to give required information. Confirms Article 72: the PSP bears the burden of proving a payment was authenticated, accurately recorded and not affected by a technical fault. Confirms Article 73(1): an unauthorised payment is refunded immediately, by the end of the following business day at the latest, unless the PSP suspects fraud on reasonable grounds and reports it in writing to the national authority. Confirms Article 74(1): the payer's loss on an unauthorised transaction is capped at EUR 50 except where the payer acted fraudulently or with intent or gross negligence. Confirms Article 88(2) and (3): a PSP is not liable under Article 89 where the customer gave an incorrect unique identifier, but the payer's PSP must still make reasonable recovery efforts and, on written request once those fail, give the payer the information needed to sue. Confirms Article 89: PSP liability for non-executed, defective or late execution, including refund and account restoration duties." } ] }, "rail_name": "SEPA Instant Credit Transfer", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sct-inst:decision-points", "id": "decision-points", "rail": "sepa-sct-inst", "kind": "rail-fact", "facet": "decision-points", "name": "Where does the rail stop and a human decide?", "statement": "The payment itself leaves no room for judgement: five seconds, no cut-off, and every step is instant or automatic. All the discretion sits either side of it. Before the payment, a customer decides whether to go ahead past a mismatch warning and what ceiling to set on its own sending. After it, the beneficiary and its bank decide whether any money comes back, on a timetable measured in weeks. That contrast, seconds forward and weeks back, is the defining feature of this rail. Each line names the provision that leaves the decision open.", "details": [ { "label": "The customer's decision before the payment", "value": "Where the name and the IBAN do not match, the customer is told and warned, and then chooses. The law is explicit that running the check must not stop the payer authorising the transfer anyway, and the bank has to have explained beforehand what going ahead does to its liability and to the customer's refund rights. On a rail this fast, this is the last point at which anything can be stopped.", "citation": "Regulation (EU) No 260/2012 as amended by Regulation (EU) 2024/886, Article 5c(1)(a), 5c(5) and 5c(7)", "rests_on": "law" }, { "label": "The ceiling the customer sets", "value": "Also the customer's, on request: per day or per payment, its own choice, changeable at any time before an order goes in. An order that would break it must not be executed, and the bank has to say so and explain how to change it.", "citation": "Regulation (EU) No 260/2012 as amended by Regulation (EU) 2024/886, Article 5a(6)", "rests_on": "law" }, { "label": "The beneficiary's consent to give money back", "value": "The scheme's central discretion, and with no Return in this scheme it is the only one that matters. On a Request for Recall the beneficiary PSP puts the reason to its customer, and the rulebook says outright that getting the funds back turns on that customer's consent. A refusal is one of the listed negative answers.", "citation": "EPC004-16 SCT Inst Rulebook 2025 v1.1 (effective 2025-10-05), section 4.3.2.3 and step 3, with CT-02.03R", "rests_on": "rule" }, { "label": "Whether the bank has to ask at all", "value": "On a Recall with the money still on the account, the receiving PSP has three possible positions depending on its national law and its account contract: debit and answer yes immediately, judge whether it is necessary to ask the customer, or be obliged to obtain authorisation. The rulebook sets none of the three; it lists them.", "citation": "EPC004-16 SCT Inst Rulebook 2025 v1.1, process steps CT-02.03 and CT-02.03A", "rests_on": "rule" }, { "label": "Whether the sending bank passes the request on", "value": "It may turn its own customer down where it judges the case does not fit one of the three Recall grounds, or where the window has closed, and the same judgement applies to a Request for Recall outside thirteen months. It also chooses whether to send a Request for Recall instantly or not.", "citation": "EPC004-16 SCT Inst Rulebook 2025 v1.1, process step CT-02.01R and section 4.3.2.3", "rests_on": "rule" }, { "label": "Whether the receiving bank charges for a yes", "value": "Left to it entirely. A fee may be attached to a positive answer on a Recall or a Request for Recall, only to a positive answer. No maximum appears anywhere in the rulebook.", "citation": "EPC004-16 SCT Inst Rulebook 2025 v1.1, sections 4.3.2.2 and 4.3.2.3 step 4A", "rests_on": "rule" }, { "label": "What a bank does with ten seconds of silence", "value": "Releasing the customer's reservation is compulsory. What comes next is a choice of three: open the status investigation from the ninth second, use whatever other channels it has to find out, or simply wait for a confirmation to arrive. The scheme does not prefer any of them, sets no completion time for the investigation and no limit on repeating it.", "citation": "EPC004-16 SCT Inst Rulebook 2025 v1.1, sections 4.2.3 D and 4.4", "rests_on": "rule" }, { "label": "What a bank does with a very late success", "value": "Where a positive confirmation arrives after the customer's account was already restored, the sending PSP must tell the customer, and the rulebook then stops: anything further it does about that situation is outside the scheme, and the liability chapter caps what it can claim at the transaction amount.", "citation": "EPC004-16 SCT Inst Rulebook 2025 v1.1, section 4.2.3 D with CT-01.13R, and section 5.9.2 point 1", "rests_on": "rule" }, { "label": "What a bank's own limits are", "value": "With no scheme maximum left, the sending PSP's own value limits on its customers' products are set on its own risk appetite, within the law, and the settlement cover it holds is a matter for it and its CSM. Both are judgement calls no one publishes.", "citation": "EPC004-16 SCT Inst Rulebook 2025 v1.1, section 2.5", "rests_on": "rule" }, { "label": "Whether a customer's denial is accepted", "value": "Under law rather than the scheme. Where a customer denies authorising a payment, its bank has to prove the transaction was authenticated, accurately recorded, properly booked and unaffected by any technical failure of its own. Refusing the refund on a suspicion of fraud is a decision the bank has to justify in writing to its national authority.", "citation": "Directive (EU) 2015/2366, Articles 72 and 73(1)", "rests_on": "law" } ], "exceptions": [ "Whether a receiving PSP may debit a customer without asking is fixed by national law and the account contract, so the same Recall is automatic in one Member State and a customer decision in another (EPC004-16 2025 v1.1, CT-02.03).", "The scheme constrains the discretion it grants in one direction only: the answer is compulsory even where the outcome is not. Fifteen Banking Business Days on a Recall or a Request for Recall, and a receiving PSP that does not answer is in breach (EPC004-16 2025 v1.1, sections 4.3.2.2 and 4.3.2.3).", "A negative answer is not free text. It has to carry one of the listed reasons, so a refusal is at least classified even when it is not explained (EPC004-16 2025 v1.1, CT-02.03R and AT-R057).", "Inside the payment there is almost no discretion at all. Rejects are instant and reasoned, the time-out is mechanical, and a party that cannot meet the deadline is told what to do rather than asked (EPC004-16 2025 v1.1, sections 4.2.3 C and 4.3.2.1).", "Business customers can opt out of the payee check for bulk submissions, which removes the pre-payment decision point for those payments entirely (Regulation (EU) No 260/2012 as amended, Article 5c(6)).", "This list is Orca's reading of where the rulebook and the applicable law leave judgement open. It is not an EPC list, and the EPC publishes none." ], "applies_to": "points before and after a SEPA Instant Credit Transfer where the rulebook or the applicable law leaves the outcome to a Participant or to a payment service user rather than prescribing it", "caveat": "The asymmetry is the thing to design around. Forward, the rail gives an answer in five seconds and takes no judgement from anyone. Backward, it gives a request that can be refused after fifteen Banking Business Days. Anything that depends on being able to undo a payment belongs on the pre-payment side of that line, which in practice means the verification of payee warning and the customer's own limit.", "related": [ "sepa-sct-inst:finality", "sepa-sct-inst:recall", "sepa-sct-inst:refund", "sepa-sct-inst:liability", "sepa-sct-inst:consumer-law", "sepa-sct-inst:limits", "sepa-sct-inst:hours" ], "basis": { "sources": "EPC004-16 SEPA Instant Credit Transfer Scheme Rulebook 2025 version 1.1 (effective 2025-10-05, marked Public), read for this record: sections 2.5, 4.2.3 C and D with CT-01.13R, 4.3.2.1, 4.3.2.2 with CT-02.01R, CT-02.03, CT-02.03A and CT-02.03R, 4.3.2.3 with steps 3 and 4A, 4.4, 4.6.1 (AT-R057) and 5.9.2 point 1. Directive (EU) 2015/2366 consolidated 2024-04-08, Articles 72 and 73, and Regulation (EU) No 260/2012 as amended by Regulation (EU) 2024/886, Articles 5a(6), 5c(1)(a), 5c(5), 5c(6) and 5c(7), read on EUR-Lex.", "confidence": "medium" }, "currency": { "effective_since": "2025-10-05", "effective_note": "Every rulebook provision cited is in the 2025 SCT Inst rulebook, issued and effective 2025-10-05. The two pre-payment customer decisions came from Regulation (EU) 2024/886 and bind euro area PSPs from 2025-10-09 for the payee check and from the point the customer asks for the sending ceiling. The reading of these provisions as decision points is Orca's, made for this record, and the facet caps at medium confidence for that reason.", "source_edition": "EPC004-16 SCT Inst Scheme Rulebook 2025 version 1.1 (2025-10-05); Directive (EU) 2015/2366 consolidated 2024-04-08; Regulation (EU) No 260/2012 as amended by Regulation (EU) 2024/886", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-10/EPC004-16%202025%20SCT%20Instant%20Rulebook%20v1.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC004-16 SCT Inst Scheme Rulebook 2025 version 1.1", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the beneficiary consent discretion on RFRO (4.3.2.3 step 3, CT-02.03R), the three national-law-dependent Recall postures (CT-02.03, CT-02.03A), the sending PSP's own gatekeeping of grounds and windows (CT-02.01R, 4.3.2.3), the uncapped optional fee on a positive Recall or RFRO answer (4.3.2.2, 4.3.2.3 step 4A), the choice of what to do after ten seconds of silence including the optional status investigation (4.2.3 D, 4.4), the late-success handling and its liability cap (4.2.3 D, CT-01.13R, 5.9.2 point 1), and the sending PSP's own value limits with no scheme maximum (2.5). Does not independently confirm Directive 2015/2366 Articles 72 or 73(1), or Regulation 260/2012 Articles 5a(6), 5c(1)(a), 5c(5), 5c(6) or 5c(7) as amended by 2024/886; EUR-Lex remains unreachable." } ] }, "rail_name": "SEPA Instant Credit Transfer", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sct-inst:finality", "id": "finality", "rail": "sepa-sct-inst", "kind": "rail-fact", "facet": "finality", "name": "When does a SEPA Instant Credit Transfer become final, and can it be reversed?", "statement": "A SEPA Instant Credit Transfer is final within seconds. The beneficiary PSP releases the money to its customer only once it knows its positive confirmation got through to the inter-PSP space, and from that instant the customer can spend it. This scheme carries no post-settlement Return: a beneficiary PSP has no message for sending money back on its own, and a beneficiary who wants to give it back has to make a fresh payment. What is left is a Recall or a Request for Recall by the Originator, either of which the beneficiary PSP can turn down.", "details": [ { "label": "How fast final is", "value": "Five seconds is the target: by then the originator PSP should hold either a confirmation that its customer's money reached the beneficiary or a rejection. Seven seconds is the hard cut, measured to the beneficiary PSP's CSM. Nine seconds is when that answer has to be back with the originator PSP. All three run from the Time Stamp the originator PSP put on the transaction.", "citation": "EPC004-16 SCT Inst Rulebook 2025 v1.1 (issued and effective 2025-10-05), section 4.2.3 B and C", "rests_on": "rule" }, { "label": "The moment the beneficiary is paid", "value": "The beneficiary PSP does not release funds on hope. It waits for proof that its own CSM took the positive confirmation, by technical acknowledgement or another arrangement it has with that CSM. Only then does the customer get the use of the money, on whatever terms its account carries.", "citation": "EPC004-16 SCT Inst Rulebook 2025 v1.1, section 4.2.3 B, process step CT-01.09 and CT-01.10, and chapter 7 defined term Making/Make/Made Funds Available", "rests_on": "rule" }, { "label": "Settlement certainty comes before the payment, not after", "value": "Handing the transaction to its CSM is itself the originator PSP's authority for that CSM to hold cover against it, which the CSM does at once. So by the time the beneficiary PSP sees the transaction, it is already covered. The originator PSP's own duty to pay bites only when a positive confirmation reaches it.", "citation": "EPC004-16 SCT Inst Rulebook 2025 v1.1, section 4.3, principles 1 to 3", "rests_on": "rule" }, { "label": "There is no Return in this scheme", "value": "Three exception types exist and no more: Reject, Recall, Request for Recall by the Originator. The reason code guidance lists the same three. The rulebook goes further and says outright that it provides nothing for a beneficiary who wants to hand the money back, pointing that customer at its own PSP and at a new payment instead.", "citation": "EPC004-16 SCT Inst Rulebook 2025 v1.1, sections 4.3.2 and 4.3.2.4; EPC059-18 v7.0 (2025-10-05), section 1", "rests_on": "rule" }, { "label": "The only routes back, and both are requests", "value": "Once the payment has gone through, the originator PSP can raise a Recall, but only for a duplicate, a technical fault of its own, or fraud. Everything else the customer complains about goes as a Request for Recall by the Originator. Fifteen Banking Business Days to answer, and the answer may be no, including because the beneficiary refused.", "citation": "EPC004-16 SCT Inst Rulebook 2025 v1.1, sections 4.3.2.2 and 4.3.2.3, with process step CT-02.03R and step 4B", "rests_on": "rule" }, { "label": "Where the seconds come from", "value": "Law gives the whole chain ten seconds from the moment the payer's PSP has the order: by then the payee's PSP must have put the money on the payee's account and reported back. It also makes the payer's PSP tell its customer, at no charge, either when that report arrives or when ten seconds pass with nothing. The scheme's 5, 7 and 9 second marks are how the EPC fitted its process inside that.", "citation": "Regulation (EU) No 260/2012 as amended by Regulation (EU) 2024/886, Article 5a(4)(c) and 5a(4)(e), read on EUR-Lex; mapped to the rulebook sections by EPC004-16 2025 v1.1, Annex IV entries for sections 2.2 and 4.2.3", "rests_on": "law" }, { "label": "What happens when nothing comes back", "value": "Ten seconds of silence and the originator PSP has to put its customer's account back as it was, releasing the amount it had held. That is a customer-side step only. Towards the beneficiary PSP the cover stays in place, and the transaction is not treated as failed until some confirmation says it failed. A late positive confirmation means the payment worked after all.", "citation": "EPC004-16 SCT Inst Rulebook 2025 v1.1, section 4.2.3 D and process steps CT-01.11R, CT-01.12R and CT-01.13R; Regulation (EU) No 260/2012 as amended, Article 5a(5)", "rests_on": "rule" }, { "label": "Finality does not decide who bears a loss", "value": "Law treats the IBAN as the whole of the instruction: pay that account and the payment counts as correct towards the person it belongs to. A customer who gave the wrong IBAN loses the non-execution claim, though its PSP still owes it a real attempt at recovery. Since the 2024 amendment there is a second route: a PSP that skipped the verification of payee duty and so caused a defective payment has to give the payer its money back without delay.", "citation": "Directive (EU) 2015/2366, Articles 88 and 89; Regulation (EU) No 260/2012 as amended by Regulation (EU) 2024/886, Article 5c(8)", "rests_on": "law" } ], "exceptions": [ "A rejected transaction never gets near finality. The rejection can come from a party in the inter-PSP space, from the beneficiary PSP, or from the beneficiary PSP's CSM on a time-out, and in each case the originator PSP releases the amount it was holding (EPC004-16 2025 v1.1, section 4.3.2.1, CT-01.05R, CT-01.06R and CT-01.08R).", "Holding an amount is not debiting it. The originator's account is only formally debited on the positive confirmation, so for those few seconds the money has left nobody's account (EPC004-16 2025 v1.1, CT-01.08 and chapter 7 defined term Reservation of the Amount).", "Pairs or groups of Participants may agree to beat the 5 second target and the 7 second cut. Whatever they agree binds only them (EPC004-16 2025 v1.1, section 4.2.3 B and C).", "Insolvency-law finality is a separate question, answered by Directive 98/26/EC and by each designated system's own rules rather than by this rulebook. [Unverified: Directive 98/26/EC was not read for this record, and CSM rulebooks are participant-only.]", "Unauthorised transactions sit outside all of this. The payer's PSP owes a refund at once, and by the next business day at the latest after it learns of the claim, unless it has grounds to suspect fraud and reports them to its national authority (Directive (EU) 2015/2366, Article 73(1)).", "Outside the EEA neither the Directive nor the amended SEPA Regulation bites directly; those Participants take on equivalent obligations through the rulebook instead (EPC004-16 2025 v1.1, section 5.14)." ], "applies_to": "SEPA Instant Credit Transfers in euro between payment accounts of an Originator and a Beneficiary located in the countries listed in the EPC List of SEPA Scheme Countries, executed under the EPC SCT Inst scheme", "caveat": "The difference from SEPA Credit Transfer (SCT) is not speed, it is the missing Return. On SCT a beneficiary PSP that cannot credit the account has three Banking Business Days to send the money back on its own, as an obligation. On SCT Inst that obligation does not exist, because a transaction that cannot be credited is rejected in the same seconds instead. Once the funds are made available, every route back needs the beneficiary side to agree.", "related": [ "sepa-sct-inst:settlement", "sepa-sct-inst:hours", "sepa-sct-inst:return", "sepa-sct-inst:recall", "sepa-sct-inst:refund", "sepa-sct-inst:liability", "sepa-sct-inst:consumer-law", "sepa-sct-inst:decision-points" ], "basis": { "sources": "EPC004-16 SEPA Instant Credit Transfer Scheme Rulebook 2025 version 1.1, issued and effective 2025-10-05 (marked Public), read for this record: sections 2.2 (scope), 4.2.3 A to D (Time Stamp, target maximum execution time, time-out deadline, no confirmation after the deadline), 4.3 (processing principles), 4.3.1 (CT-01.01 to CT-01.10), 4.3.2 and 4.3.2.1 (Reject, CT-01.05R to CT-01.13R), 4.3.2.2 (Recall), 4.3.2.3 (Request for Recall by the Originator), 4.3.2.4 (beneficiary wishing to transfer back the funds), 5.14, chapter 7 (defined terms Made Funds Available, Reservation of the Amount, Settlement, Banking Business Day), Annex IV (which rulebook change answers which article of the amended SEPA Regulation). EPC059-18 v7.0 (2025-10-05), section 1. Regulation (EU) No 260/2012 as amended by Regulation (EU) 2024/886, Articles 5a and 5c, and Directive (EU) 2015/2366 consolidated 2024-04-08, Articles 73, 88 and 89, both read on EUR-Lex for this record.", "confidence": "high" }, "currency": { "effective_since": "2025-10-05", "effective_note": "The 2025 SCT Inst rulebook was issued and took effect on 2025-10-05. Version 1.1 changed only the date from which the unstructured address format stops being permitted, moving it from 22 November 2026 to 15 November 2026. The 5 second target replaced a 10 second target, and the 7 second time-out replaced a 20 second one, in this edition, to meet the amended SEPA Regulation (Annex IV, entries for sections 2.2 and 4.2.3). The next SCT Inst rulebook is due for publication in November 2026 and effect in November 2027.", "source_edition": "EPC004-16 SCT Inst Scheme Rulebook 2025 version 1.1 (2025-10-05); EPC059-18 v7.0 (2025-10-05); Regulation (EU) No 260/2012 as amended by Regulation (EU) 2024/886; Directive (EU) 2015/2366 consolidated 2024-04-08", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-10/EPC004-16%202025%20SCT%20Instant%20Rulebook%20v1.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC004-16 SCT Inst Scheme Rulebook 2025 version 1.1; EPC059-18 v7.0 Guidance on Reason Codes for SCT Inst R-transactions", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the 5 second target, 7 second CSM cut-off, 9 and 10 second originator-side deadlines (4.2.3 B, C, D), that the beneficiary PSP releases funds only after a technical acknowledgement from its own CSM (4.2.3 B), the three settlement-certainty principles including upfront reservation by the originator PSP's CSM (4.3), the three-exception-type limit with no Return and section 4.3.2.4's statement that the rulebook provides no exception processing for a beneficiary wishing to send funds back (4.3.2, 4.3.2.4), and the Recall/RFRO-only routes back (4.3.2.2, 4.3.2.3). Does not independently confirm Regulation 260/2012 Article 5a(4) and 5a(5) as amended by 2024/886, or Directive 2015/2366 Articles 88-89 and Regulation 260/2012 Article 5c(8); EUR-Lex remains unreachable. This directly supports the special-attention question: SCT Inst has no post-settlement return, and Recall/RFRO are the only paths back." } ] }, "rail_name": "SEPA Instant Credit Transfer", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sct-inst:hours", "id": "hours", "rail": "sepa-sct-inst", "kind": "rail-fact", "facet": "hours", "name": "When is the rail open, and what clock do its deadlines run on?", "statement": "SCT Inst never closes and has no cut-off. The payment is measured in seconds from a stamp the originator PSP puts on the transaction: 5 seconds to a confirmation, 7 to the hard cut, 9 for the answer to be back with the sending PSP, 10 before that PSP has to release the money it was holding. Banking Business Days still exist here, but only in the two request procedures that come after a completed payment, the Recall and the Request for Recall by the Originator.", "details": [ { "label": "Open all the time", "value": "Every hour, every calendar day, with the payment initiation channel the only qualifier. Because nothing closes, the scheme has no cut-off time at all.", "citation": "EPC004-16 SCT Inst Rulebook 2025 v1.1 (effective 2025-10-05), sections 2.2 and 4.2.2", "rests_on": "rule" }, { "label": "What may close", "value": "Only planned outages, and on terms: the gap has to be foreseeable, short, and announced to customers beforehand. A Participant may be off the network temporarily on that basis and no other.", "citation": "EPC004-16 SCT Inst Rulebook 2025 v1.1, sections 2.2 footnote 10, 4.2.2 footnote 14, and 5.3 last paragraph", "rests_on": "rule" }, { "label": "Where the always-open duty comes from", "value": "Law makes any PSP that sends and receives credit transfers do the same for instant ones, for every customer, and keeps every account that is reachable for ordinary transfers reachable for instant ones around the clock on any calendar day. The penalty regime carves out unreachability caused by planned maintenance or downtime announced in advance.", "citation": "Regulation (EU) No 260/2012 as amended by Regulation (EU) 2024/886, Article 5a(1) and Article 11(1c)", "rests_on": "law" }, { "label": "The clock that matters", "value": "AT-T056, stamped by the originator PSP and equal to the Time of Receipt, starts the execution cycle, and its precision runs to milliseconds or finer. In law, receipt is simply the moment the payer's PSP has the order, whatever the hour or the date.", "citation": "EPC004-16 SCT Inst Rulebook 2025 v1.1, sections 4.2.1, 4.2.3 A and 4.6.1 attribute AT-T056; Regulation (EU) No 260/2012 as amended by Regulation (EU) 2024/886, Article 5a(3)", "rests_on": "law" }, { "label": "The four second marks", "value": "5 seconds: the sending PSP should hold a confirmation or a rejection. 7 seconds: the receiving PSP's CSM must hold one. 9 seconds: it must have reached the sending PSP. 10 seconds with nothing at all: the sending PSP releases the amount it was holding on its customer's account. Each mark counts from the Time Stamp.", "citation": "EPC004-16 SCT Inst Rulebook 2025 v1.1, section 4.2.3 B, C and D", "rests_on": "rule" }, { "label": "Where the ten seconds come from", "value": "Law allows the chain ten seconds from receipt at the payer's PSP to the money being usable at the payee's and the report coming back, and makes the payer's PSP restore its customer's account at once when nothing arrives in that time. The scheme's three inner marks are how the EPC fitted its process inside that limit.", "citation": "Regulation (EU) No 260/2012 as amended by Regulation (EU) 2024/886, Articles 5a(4)(c) and 5a(5); EPC004-16 2025 v1.1 Annex IV, entries for section 4.2.3 B, C and D", "rests_on": "law" }, { "label": "Where Banking Business Days survive", "value": "A Banking Business Day is a T2 day, and in this scheme it governs nothing but the Recall and the Request for Recall. Those carry ten days for a duplicate or a technical fault, thirteen months for fraud and for any Request for Recall, and fifteen days for the receiving PSP to answer.", "citation": "EPC004-16 SCT Inst Rulebook 2025 v1.1, chapter 7 Defined Terms entry Banking Business Day, and sections 4.3.2.2 and 4.3.2.3", "rests_on": "rule" }, { "label": "A future dated instant payment", "value": "A customer may ask for a later date and time, and that moment becomes the Time of Receipt. The sending PSP holds the transaction until then, and must let the customer cancel it beforehand.", "citation": "EPC004-16 SCT Inst Rulebook 2025 v1.1, section 4.2.1; Regulation (EU) No 260/2012 as amended by Regulation (EU) 2024/886, Article 5a(3) second subparagraph", "rests_on": "law" }, { "label": "The investigation procedure has no clock", "value": "From the ninth second the sending PSP may start asking what happened. Everyone downstream owes an instant response, but the scheme fixes neither a completion time nor a cap on how many times the question may be repeated.", "citation": "EPC004-16 SCT Inst Rulebook 2025 v1.1, sections 4.2.3 D and 4.4", "rests_on": "rule" } ], "exceptions": [ "Pairs or groups of Participants may agree to beat the 5 second target and the 7 second cut. Whatever they agree binds only them (EPC004-16 2025 v1.1, section 4.2.3 B and C).", "The initiation channel qualifies the round-the-clock promise. A channel that is not itself always open, a branch counter for instance, does not make the scheme closed (EPC004-16 2025 v1.1, sections 2.2 and 4.2.2, with the chapter 7 definition of Payment Initiation Channel).", "Law moves the time of receipt in three cases: a paper order counts from when the payer's PSP keyed it into its systems, an order inside a package counts from when the PSP split the package, and an order off a non-euro account counts from when the amount was converted (Regulation (EU) No 260/2012 as amended, Article 5a(3)(a), (b) and (c)).", "T2 days are named but not listed. Which calendar days are closed has to come from the Eurosystem. [Unverified: no Eurosystem calendar was read for this record.]", "Central banks acting commercially may limit their instant sending hours to the hours in which they send ordinary transfers. A PSP in a non-euro Member State may, with its supervisor's prior permission granted on its euro liquidity, decline to send above a per transaction limit outside its own hours, and that limit cannot be set below EUR 25 000 (Regulation (EU) No 260/2012 as amended, Article 5a(2))." ], "applies_to": "the timing of SEPA Instant Credit Transfers, of the Rejects that stop them, and of the Recalls and Requests for Recall that follow them", "caveat": "Do not carry SEPA Credit Transfer (SCT) habits across. There is no cut-off, no value date to argue about and no business day in the payment flow, so an SCT Inst sent at 02:00 on 25 December is a normal payment. But the moment the payment is over and someone wants the money back, the scheme switches clocks: the Recall and Request for Recall windows count in T2 days, and T2 is closed on 25 December.", "related": [ "sepa-sct-inst:finality", "sepa-sct-inst:settlement", "sepa-sct-inst:return", "sepa-sct-inst:recall", "sepa-sct-inst:messages", "sepa-sct-inst:decision-points" ], "basis": { "sources": "EPC004-16 SEPA Instant Credit Transfer Scheme Rulebook 2025 version 1.1 (effective 2025-10-05, marked Public), read for this record: sections 2.2 with footnote 10, 4.2.1, 4.2.2 with footnote 14, 4.2.3 A to D, 4.3.2.2, 4.3.2.3, 4.4, 4.6.1 (AT-T056), 5.3, chapter 7 (Banking Business Day, Calendar Day, Payment Initiation Channel, Time of Receipt, Instant(ly), Immediate(ly)), Annex IV entries for sections 2.2 and 4.2.3. Regulation (EU) No 260/2012 as amended by Regulation (EU) 2024/886, Articles 5a(1) to 5a(5) and 11(1c), read on EUR-Lex for this record.", "confidence": "high" }, "currency": { "effective_since": "2025-10-05", "effective_note": "The 2025 SCT Inst rulebook was issued and took effect on 2025-10-05. The second marks changed in this edition: the target execution time went from 10 seconds to 5, the hard time-out from 20 seconds to 7, and the originator PSP's deadline for receiving the confirmation from the 25th second to the 9th, all to fit the 10 seconds the amended SEPA Regulation allows (Annex IV, entries for section 4.2.3 B and C). Any account of SCT Inst timing that still says 10 seconds target or 20 seconds time-out is describing the 2023 rulebook.", "source_edition": "EPC004-16 SCT Inst Scheme Rulebook 2025 version 1.1 (2025-10-05); Regulation (EU) No 260/2012 as amended by Regulation (EU) 2024/886", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-10/EPC004-16%202025%20SCT%20Instant%20Rulebook%20v1.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC004-16 SCT Inst Scheme Rulebook 2025 version 1.1", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms 24 hours a day, all calendar days of the year availability with footnote 10's planned-and-announced-outage qualifier (2.2), no cut-off (4.2.2), the AT-T056 time-of-receipt stamp at millisecond-or-finer precision (4.2.1, 4.2.3 A, 4.6.1), the 5/7/9/10 second marks (4.2.3 B, C, D), Banking Business Day as a T2 day governing only Recall and RFRO with the same 10 day/13 month/15 day figures already confirmed for the recall fact (chapter 7, 4.3.2.2, 4.3.2.3), and the uncapped, undeadlined status investigation procedure from the ninth second (4.2.3 D, 4.4). Does not independently confirm Regulation 260/2012 Article 5a(1), 5a(3), 5a(4)(c), 5a(5) or 11(1c) as amended by 2024/886; EUR-Lex remains unreachable." } ] }, "rail_name": "SEPA Instant Credit Transfer", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sct-inst:liability", "id": "liability", "rail": "sepa-sct-inst", "kind": "rail-fact", "facet": "liability", "name": "Who bears the loss when a payment goes wrong?", "statement": "Two layers, as on SEPA Credit Transfer (SCT), plus one risk this scheme creates for itself. Between the two banks a Participant that breaks the rulebook, is negligent, or has an operational failure owes the other its foreseeable losses, capped at the amount of the transaction even against gross negligence. Between a bank and its own customer, payment services law governs. The extra risk is the late positive confirmation: a sending PSP that already released its customer's reservation at ten seconds, and then learns at twenty that the payment worked, is out of pocket, and this edition spells out that the cap applies to that claim too.", "details": [ { "label": "What makes one Participant liable to another", "value": "Three triggers, all limited to the transaction the two of them are party to: breaking the rulebook, a negligent act or omission, and an operational failure, by the Participant itself, its staff or its agents. What it owes is the other side's foreseeable losses, costs, damages, expenses including reasonable legal fees, taxes and claim liabilities.", "citation": "EPC004-16 SCT Inst Rulebook 2025 v1.1 (effective 2025-10-05), section 5.9.1", "rests_on": "rule" }, { "label": "The cap, and the late confirmation", "value": "Nothing above the amount of the transaction. This edition spelled out that the same ceiling applies where a sending PSP claims for what it cost to restore its customer's account after a positive confirmation turned up more than ten seconds late, whether the delay came from the receiving PSP or from a CSM. It also says those compensation terms belong in the contracts between the parties.", "citation": "EPC004-16 SCT Inst Rulebook 2025 v1.1, section 5.9.2 point 1, with the Annex IV entry for section 5.9.2", "rests_on": "rule" }, { "label": "What the cap survives", "value": "Gross negligence does not break it. Only deliberate wrongdoing by the Participant or its people does. A claimant that contributed to its own loss sees the ceiling cut proportionately.", "citation": "EPC004-16 SCT Inst Rulebook 2025 v1.1, section 5.9.2 points 2 to 4", "rests_on": "rule" }, { "label": "What cannot be claimed at all", "value": "Losses that came out of a Participant's own risk management action, and any loss that is not foreseeable, with foreseeable defined narrowly as the kind of loss Participants active in cross border SEPA payments meet regularly.", "citation": "EPC004-16 SCT Inst Rulebook 2025 v1.1, section 5.9.2 points 5 and 6", "rests_on": "rule" }, { "label": "Where the settlement risk sits", "value": "On the sending side, continuously. It has to provide settlement certainty on every transaction, contract with a CSM on terms good enough to deliver it, and keep that certainty up until some confirmation arrives, including through the whole silent period after ten seconds.", "citation": "EPC004-16 SCT Inst Rulebook 2025 v1.1, section 5.7 points 7 and 9, and section 4.2.3 D", "rests_on": "rule" }, { "label": "Force majeure, and the EPC's own position", "value": "Circumstances beyond a Participant's control excuse a failure, a delay or a partial performance, with acts of God, crime, fire, flood and loss of energy supply given as examples. The EPC itself answers for nothing done or left undone in exercising a discretion unless bad faith is shown, and never for unforeseeable losses.", "citation": "EPC004-16 SCT Inst Rulebook 2025 v1.1, sections 5.9.3 and 5.10", "rests_on": "rule" }, { "label": "Who the contract binds", "value": "The rulebook is a multilateral agreement between the EPC and each Participant, and between every Participant and every other. Anyone outside it, a customer included, gets no rights and no obligations from it, which is why a customer's claim never runs on the rulebook.", "citation": "EPC004-16 SCT Inst Rulebook 2025 v1.1, section 5.2", "rests_on": "rule" }, { "label": "The customer layer: a payment that failed or came late", "value": "The payer's PSP answers to the payer for correct execution unless it can show the receiving PSP got the money on time, in which case that PSP answers to the payee. The liable PSP refunds or credits without undue delay and puts the value date back where it should have been, and both PSPs answer for charges they caused and interest the customer suffered.", "citation": "Directive (EU) 2015/2366, Article 89(1) and 89(3)", "rests_on": "law" }, { "label": "The customer layer: a payment nobody authorised", "value": "The payer's PSP refunds at once, and by the end of the next business day at the latest after learning of the claim. Where the customer denies authorising it, the PSP has to prove the transaction was authenticated, accurately recorded, properly booked and unaffected by any failure of its own; the record of an instrument being used is not proof on its own.", "citation": "Directive (EU) 2015/2366, Articles 72 and 73(1)", "rests_on": "law" }, { "label": "The customer layer: a wrong IBAN, after verification of payee", "value": "Pay the account the IBAN names and the payment counts as correct towards whoever owns it, so a customer that supplied the wrong one bears the loss, with only a recovery attempt owed to it. Since the 2024 amendment that protection is conditional: a PSP keeps it only if it ran the verification of payee service, and a payer's PSP that skipped it and thereby caused a defective payment has to refund the payer without delay.", "citation": "Directive (EU) 2015/2366, Article 88(1) to (3); Regulation (EU) No 260/2012 as amended by Regulation (EU) 2024/886, Article 5c(8)", "rests_on": "law" }, { "label": "Sanctions screening moved too", "value": "The law puts the screening obligation on the customer base rather than the payment: PSPs check their own customers against targeted financial restrictive measures right after any change and at least daily, and the two PSPs in a live instant transfer do not screen the payer or payee again during execution. Infringing that regime attracts the heaviest penalties in the amended Regulation.", "citation": "Regulation (EU) No 260/2012 as amended by Regulation (EU) 2024/886, Article 5d(1) and (2), and Article 11(1b)", "rests_on": "law" } ], "exceptions": [ "Nothing in the rulebook makes a CSM liable to anyone. The rulebook binds Participants and the EPC, and what a CSM owes is a matter for its own contract (EPC004-16 2025 v1.1, sections 3.3 and 5.2).", "The liability provisions outlive participation. Sections 5.9 and 5.10 stay enforceable against a Participant after it leaves the scheme (EPC004-16 2025 v1.1, section 5.11).", "Outside the EEA neither the Directive nor the amended Regulation bites directly. Participants there take on equivalent obligations through the rulebook, as far as their own law allows, which can leave a real gap (EPC004-16 2025 v1.1, section 5.14).", "A payment initiation service provider carries its own share, both in proving what happened within its sphere and in compensating the account servicing PSP where it was at fault (Directive (EU) 2015/2366, Articles 72(1) and 73(2)).", "The rulebook's cap is between Participants only. It does not limit what a PSP owes its own customer under payment services law. [Inference: the rulebook says a non-party gets no rights under it, which is not the same as saying it caps nothing outside it.]", "Fraud by a customer, or gross negligence in keeping its credentials, removes the customer's protection for an unauthorised payment entirely, and the PSP has to bring supporting evidence to prove it (Directive (EU) 2015/2366, Articles 72(2) and 74(1))." ], "applies_to": "losses on a SEPA Instant Credit Transfer, between two Participants under the rulebook and between a Participant and its own payment service user under payment services law", "caveat": "The gap worth naming is authorised push payment fraud, and speed makes it worse. A customer tricked into sending an instant transfer has authorised it, and the IBAN was correct, so neither legal route reaches it, while the money is spendable within seconds. What is left is a Request for Recall the beneficiary can refuse. Verification of payee narrows the gap but does not close it.", "related": [ "sepa-sct-inst:finality", "sepa-sct-inst:refund", "sepa-sct-inst:consumer-law", "sepa-sct-inst:recall", "sepa-sct-inst:participants", "sepa-sct-inst:decision-points" ], "basis": { "sources": "EPC004-16 SEPA Instant Credit Transfer Scheme Rulebook 2025 version 1.1 (effective 2025-10-05, marked Public), read for this record: sections 3.3, 4.2.3 D, 5.2, 5.7 points 7 and 9, 5.9.1, 5.9.2, 5.9.3, 5.10, 5.11, 5.14, and the Annex IV entry for section 5.9.2. Directive (EU) 2015/2366 consolidated 2024-04-08, Articles 72, 73, 74(1), 88 and 89, and Regulation (EU) No 260/2012 as amended by Regulation (EU) 2024/886, Articles 5c(8), 5d and 11(1b), both read on EUR-Lex for this record.", "confidence": "high" }, "currency": { "effective_since": "2025-10-05", "effective_note": "The 2025 SCT Inst rulebook was issued and took effect on 2025-10-05. Annex IV records that point 1 of section 5.9.2 gained the wording about a positive confirmation arriving more than ten seconds after the Time Stamp in this edition; the rest of the liability chapter is older, and the date it first took effect is [Unverified] because earlier editions were not read. The sanctions screening regime in Article 5d binds PSPs from 2025-01-09, and the verification of payee liability shift binds euro area PSPs from 2025-10-09.", "source_edition": "EPC004-16 SCT Inst Scheme Rulebook 2025 version 1.1 (2025-10-05); Directive (EU) 2015/2366 consolidated 2024-04-08; Regulation (EU) No 260/2012 as amended by Regulation (EU) 2024/886", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-10/EPC004-16%202025%20SCT%20Instant%20Rulebook%20v1.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC004-16 SCT Inst Scheme Rulebook 2025 version 1.1", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the three inter-PSP liability triggers (5.9.1), the transaction-amount cap and its explicit 2025-edition extension to a claim for restoring the originator's account after a positive confirmation arrives more than 10 seconds late whether the delay is the beneficiary PSP's or an inter-PSP space actor's fault, confirmed word for word against 5.9.2 point 1 and the Annex IV change entry for section 5.9.2, the gross-negligence-survives/wilful-intent-breaks and contributory-negligence and unforeseeability carve-outs (5.9.2 points 2-6), force majeure (5.9.3), EPC's own bad-faith-only liability (5.10), that the rulebook binds only the EPC and Participants (5.2), and the settlement-certainty duty running through the silent period after ten seconds (5.7 points 7, 9; 4.2.3 D). Does not independently confirm Directive 2015/2366 Articles 72, 73(1), 88 or 89, or Regulation 260/2012 Articles 5c(8), 5d or 11(1b) as amended by 2024/886; EUR-Lex remains unreachable." } ] }, "rail_name": "SEPA Instant Credit Transfer", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sct-inst:limits", "id": "limits", "rail": "sepa-sct-inst", "kind": "rail-fact", "facet": "limits", "name": "What limits apply to a SEPA Instant Credit Transfer, and who sets them?", "statement": "There is no maximum amount at scheme level any more. The 2025 rulebook took it out, and took out the reject reason that went with it, because the amended SEPA Regulation removed the scheme's freedom to set one. What is left is the same field width as ordinary SEPA Credit Transfers, 999,999,999.99 euro, the cover a sending PSP holds at its CSM, and one limit that belongs to the customer rather than the bank: on request a payer can set its own daily or per payment maximum, and its PSP has to respect it.", "details": [ { "label": "The scheme maximum is gone", "value": "This edition rewrote the amount limits on the payment attribute and on the amount returned with a positive Recall answer, and the rulebook's own change record states the position plainly: no maximum is stipulated at scheme level any more.", "citation": "EPC004-16 SCT Inst Rulebook 2025 v1.1 (effective 2025-10-05), Annex IV, entry for section 4.6 on AT-T002 and AT-R054", "rests_on": "rule" }, { "label": "The reject reason went with it", "value": "AT-R004 no longer offers a reason for breaching a scheme maximum, in either the CSM list or the beneficiary PSP list. The change record ties the deletion to the same article of the amended SEPA Regulation.", "citation": "EPC004-16 SCT Inst Rulebook 2025 v1.1, Annex IV, entry for section 4.6 on AT-R004", "rests_on": "rule" }, { "label": "What the field still allows", "value": "AT-T002 stops at 999,999,999 euro plus 99 cents at the top and cannot be zero at the bottom. The legal annex behind that frees a scheme from carrying anything above EUR 999 999 999,99 and bars it from setting a floor.", "citation": "EPC004-16 SCT Inst Rulebook 2025 v1.1, section 4.6.1 attribute AT-T002; Regulation (EU) No 260/2012, Annex points (1)(f) and (1)(g)", "rests_on": "law" }, { "label": "The limit the customer sets", "value": "Ask, and the PSP has to offer a ceiling on instant sending, daily or per payment as the customer prefers, changeable at any time before an order goes in. An order that would break it must not be executed: the PSP has to say so and explain how to raise the ceiling.", "citation": "Regulation (EU) No 260/2012 as amended by Regulation (EU) 2024/886, Article 5a(6)", "rests_on": "law" }, { "label": "What a PSP may still limit", "value": "A sending PSP can still cap what it offers its own customers on its own risk judgement, but this edition added four words to that permission, subject to applicable law, and rewrote the whole section to follow Article 5a(6).", "citation": "EPC004-16 SCT Inst Rulebook 2025 v1.1, section 2.5, with the Annex IV entry for section 2.5", "rests_on": "rule" }, { "label": "Limits between the banks", "value": "Participants and communities of them may also cap each other through their CSMs. Run past the cover held at the sending PSP's CSM and the transaction comes back as AM23, which the guidance describes as a shortfall in prefunded inter-PSP settlement guarantees.", "citation": "EPC004-16 SCT Inst Rulebook 2025 v1.1, section 2.5; EPC059-18 v7.0 (2025-10-05), section 3, code AM23", "rests_on": "rule" }, { "label": "The data limits", "value": "Remittance information runs to 140 characters, structured or not, and every hop, sending PSP, intermediary and CSM alike, has to pass it on whole and unaltered. The law fixes the same 140.", "citation": "EPC004-16 SCT Inst Rulebook 2025 v1.1, section 2.7; Regulation (EU) No 260/2012, Annex point (1)(c)", "rests_on": "law" }, { "label": "A count limit on the way out", "value": "Each procedure runs once per transaction: one Recall, one Request for Recall, and neither may be raised again after the beneficiary PSP has answered. This edition tightened that.", "citation": "EPC004-16 SCT Inst Rulebook 2025 v1.1, sections 4.3.2.2 and 4.3.2.3, with the Annex IV entries for those sections", "rests_on": "rule" }, { "label": "No limit on packages either", "value": "A PSP that lets customers send bundles of ordinary transfers has to let them send bundles of instant ones, and it cannot allow fewer orders per instant bundle than it allows per ordinary bundle.", "citation": "Regulation (EU) No 260/2012 as amended by Regulation (EU) 2024/886, Article 5a(7)", "rests_on": "law" } ], "exceptions": [ "Losing the scheme maximum does not mean any account can send any amount. The sending PSP's own cap survives under section 2.5, within the law, and the customer's own ceiling is a control the customer holds, not a limit on the bank (EPC004-16 2025 v1.1, section 2.5).", "A PSP in a non-euro Member State may, with its supervisor's prior permission granted on its euro liquidity, decline to send instant euro transfers above a per transaction limit from national currency accounts during the hours when it handles no ordinary euro transfers either. The supervisor sets that limit and cannot put it below EUR 25 000 (Regulation (EU) No 260/2012 as amended, Article 5a(2)).", "Cover can run out well before any published figure. AM23 depends on prefunding values fixed per CSM and per participant, which the EPC does not publish (EPC059-18 v7.0, section 3).", "Currency is a limit of a different kind: euro at every stage, exception messages included (EPC004-16 2025 v1.1, section 2.4).", "Geography is a limit too: both accounts have to sit in a country or territory on the EPC's list. [Unverified: EPC409-09 was not read for this record.]" ], "applies_to": "the amount, the character count and the count of exception messages on a SEPA Instant Credit Transfer under the EPC SCT Inst scheme", "caveat": "Any figure quoted as the SEPA instant limit is now wrong at scheme level, and the figure most often quoted, EUR 100,000, belonged to an earlier rulebook. Since the 2025 edition the only numbers that matter are the payer's own limit, the sending bank's risk limit, and the cover that bank holds at its CSM. Two of those three are never published.", "related": [ "sepa-sct-inst:settlement", "sepa-sct-inst:participants", "sepa-sct-inst:messages", "sepa-sct-inst:consumer-law", "sepa-sct-inst:decision-points" ], "basis": { "sources": "EPC004-16 SEPA Instant Credit Transfer Scheme Rulebook 2025 version 1.1 (effective 2025-10-05, marked Public), read for this record: sections 2.4, 2.5, 2.7, 4.3.2.2, 4.3.2.3, 4.6.1 (AT-T002, AT-R004, AT-R054), and Annex IV entries for sections 2.5 and 4.6. EPC059-18 v7.0 (2025-10-05), section 3, code AM23. Regulation (EU) No 260/2012, Annex points (1)(c), (1)(f) and (1)(g), and the same Regulation as amended by Regulation (EU) 2024/886, Articles 5a(2), 5a(6) and 5a(7), read on EUR-Lex for this record.", "confidence": "high" }, "currency": { "effective_since": "2025-10-05", "effective_note": "The removal of the scheme maximum took effect with the 2025 SCT Inst rulebook on 2025-10-05. The previous scheme maximum amount and its reject reason were in the 2023 rulebook; the drafter did not read that edition, so the figure it carried is [Unverified] here. The obligation on PSPs in euro area Member States to offer sending instant credit transfers ran from 2025-10-09, four days after this rulebook took effect (Regulation (EU) No 260/2012 as amended, Article 5a(8)).", "source_edition": "EPC004-16 SCT Inst Scheme Rulebook 2025 version 1.1 (2025-10-05); EPC059-18 v7.0 (2025-10-05); Regulation (EU) No 260/2012 as amended by Regulation (EU) 2024/886", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-10/EPC004-16%202025%20SCT%20Instant%20Rulebook%20v1.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC004-16 SCT Inst Scheme Rulebook 2025 version 1.1; EPC059-18 v7.0 Guidance on Reason Codes for SCT Inst R-transactions", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the change history's own words, twice, that there is no longer a maximum amount stipulated at scheme level, tied to Article 5a(6) of the amended SEPA Regulation, covering both the AT-T002/AT-R054 amount limitation change and the AT-R004 removal of the maximum-amount reject reason (Annex IV entries for section 4.6). Confirms section 2.5 was completely reformulated for Article 5a(6) and now reads 'subject to applicable law' for a sending PSP's own value limits. Confirms the AT-T002 999,999,999.99 euro field ceiling (4.6.1), the AM23 CSM prefunding shortfall code against EPC059-18 v7.0 section 3, the 140 character remittance field (2.7), and the one-recall/one-RFRO-per-transaction count limit (4.3.2.2, 4.3.2.3). Does not independently confirm Regulation 260/2012 Annex points (1)(c), (1)(f), (1)(g) or Article 5a(6)/5a(7) text itself; EUR-Lex remains unreachable." } ] }, "rail_name": "SEPA Instant Credit Transfer", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sct-inst:messages", "id": "messages", "rail": "sepa-sct-inst", "kind": "rail-fact", "facet": "messages", "name": "What messages exist on this rail, and what standard are they in?", "statement": "The rulebook names no ISO message. It defines ten datasets and a list of attributes and leaves the ISO 20022 XML mapping to two Implementation Guidelines it makes binding but does not contain. The inter-PSP guideline puts the seven inter-PSP datasets on six ISO 20022 messages: pacs.008, pacs.002, camt.056, camt.029, pacs.004 and pacs.028. The shape is different from SEPA Credit Transfer (SCT) in two ways worth knowing. There is no Reject dataset, because the confirmation message carries both the yes and the no. And there is one extra dataset that SCT has no equivalent for: the notification the beneficiary PSP sends its own customer to say the money is there.", "details": [ { "label": "The ten datasets", "value": "DS-01 the customer's instruction to its PSP, DS-02 the inter-PSP payment, DS-03 the confirmation message, DS-04 what the beneficiary PSP tells its customer, DS-05 a Recall, DS-06 the answer to a Recall, DS-07 the status investigation message, DS-08 a Request for Recall by the Originator, DS-09 the answer to it, DS-10 the positive notification to the beneficiary.", "citation": "EPC004-16 SCT Inst Rulebook 2025 v1.1 (effective 2025-10-05), section 4.5", "rests_on": "rule" }, { "label": "One message does two jobs", "value": "DS-03 is the confirmation, positive or negative, and the negative one is the Reject. That is why this scheme has no separate Reject dataset: saying the transaction failed and saying it was rejected are the same message.", "citation": "EPC004-16 SCT Inst Rulebook 2025 v1.1, sections 4.3.2.1 and 4.5.3", "rests_on": "rule" }, { "label": "The message SCT does not have", "value": "DS-10 sets out the least a beneficiary PSP has to put in the notification telling its own customer that money arrived: who sent it and their reference party, the beneficiary and its reference party, the account, the amount, and optionally the purpose and the remittance information.", "citation": "EPC004-16 SCT Inst Rulebook 2025 v1.1, section 4.5.10", "rests_on": "rule" }, { "label": "Where the ISO mapping lives", "value": "Two documents outside the rulebook carry it, one for the bank to bank space and one for the customer side, and the rulebook makes both binding supplements to itself. The pacs and camt names an implementer needs are in them.", "citation": "EPC004-16 SCT Inst Rulebook 2025 v1.1, section 0.5 and chapter 7 entries for the two Implementation Guidelines", "rests_on": "rule" }, { "label": "The ISO message behind each inter-PSP dataset", "value": "Read from the message side. pacs.008.001.08 carries the payment itself (DS-02). pacs.002.001.10 carries the confirmation (DS-03): status ACCP when it is a yes, RJCT when it is the Reject. camt.056.001.08 carries both kinds of request to get money back, the Recall (DS-05) and the Request for Recall by the Originator (DS-08). The answers to those two (DS-06 and DS-09) split by outcome: a refusal goes on camt.029.001.09, while a yes travels as pacs.004.001.09, so the money comes back in the answer. pacs.028.001.03 carries the originator PSP's status investigation (DS-07) and is reused for the Request for Status Update on a Recall or on a Request for Recall, which has no dataset number of its own.", "citation": "EPC122-16 SCT Inst Inter-PSP Implementation Guidelines 2025 v1.0 (effective 2025-10-05), section 1 (the dataset to message table) and sections 2.1 to 2.12", "rests_on": "rule" }, { "label": "Which ISO release, and when it moves", "value": "The 2025 guidelines are built on the 2019 message version of ISO 20022, and the identifiers above are the variants they pin. A guideline edition belongs to one rulebook edition and takes effect with it, at 03:30 CET on the same day, and there is no overlap period: from the changeover a receiving PSP takes every message, R-messages too, in the new version alone. The move to the 2019 version is the one precedent for a slip: it was due with the 2023 rulebook on 19 November 2023, and the PSMB decided on 24 October 2023 to put it back to 17 March 2024, carrying the rulebook's own entry into force with it.", "citation": "EPC122-16 SCT Inst Inter-PSP Implementation Guidelines 2025 v1.0 (effective 2025-10-05), cover page, section 0.1 reference [2] and section 1.7; EPC004-16 SCT Inst Rulebook 2025 v1.1, section 0.2 entry for 2023 v1.2", "rests_on": "rule" }, { "label": "What the guideline adds that the rulebook does not say", "value": "Four usage rules an implementer meets first. Local Instrument is mandatory and its code may only be INST, which is how a pacs.008 announces itself as SCT Inst. A pacs.008 may hold one transaction and no more, and the positive pacs.002 likewise confirms a single transaction. AT-T056 maps to Acceptance Date Time, mandatory on both the payment and the confirmation, with milliseconds and either UTC or local time with a UTC offset. Settlement Method may only be CLRG, INGA or INDA, so settlement through a clearing system and settlement by the instructing or instructed agent are all admitted.", "citation": "EPC122-16 SCT Inst Inter-PSP Implementation Guidelines 2025 v1.0 (effective 2025-10-05), section 1.5.2, elements 1.4, 1.9, 1.26, 1.27 and 2.13 of section 2.1, element 3.15 of section 2.2, and section 2.3.1 with its element 3.10", "rests_on": "rule" }, { "label": "The customer side is binding only for bulk files", "value": "The EPC treats the customer to PSP guidelines as mandatory, but the duty bites only on a PSP that offers electronic bulk files of instructions: that PSP must accept at least the EPC format, and its customers may keep their existing file set-up. A PSP whose customers key payments one by one in online banking, or on paper, has no customer-side format to meet.", "citation": "EPC131-17 Clarification Paper on the SCT and SCT Inst Rulebooks v4.0 (2025-10-05), section 2.3", "rests_on": "guidance" }, { "label": "Which standard, and why", "value": "ISO 20022 XML, and the choice is the law's rather than the scheme's. Whenever a PSP hands a euro credit transfer on to another PSP, whether directly or across a retail payment system, Article 5(1) makes it use that message standard, and it also makes IBAN the account identifier wherever the PSPs sit; the Annex is where the two standards are actually named. The Regulation's own reach is euro transactions whose PSPs are in the Union. A Participant outside the EEA is bound by it only through the rulebook, which asks such Participants to take on substantially equivalent obligations.", "citation": "Regulation (EU) No 260/2012, Article 1(1), Article 5(1)(a) and (b), and Annex points (1)(a) and (1)(b), read in the consolidated text of 2024-04-08; EPC004-16 SCT Inst Rulebook 2025 v1.1, section 5.14", "rests_on": "law" }, { "label": "The attribute that makes the timing enforceable", "value": "AT-T056 is the time stamp the sending PSP puts on the transaction. It must be unambiguous and carry at least millisecond precision, which is what lets every party check the 5, 7, 9 and 10 second marks against the same clock. The millisecond requirement was added in this edition.", "citation": "EPC004-16 SCT Inst Rulebook 2025 v1.1, section 4.6.1 attribute AT-T056, with the Annex IV entry for section 4.6", "rests_on": "rule" }, { "label": "What every exception message has to carry", "value": "The path the original took, its data unaltered, enough of it for an audit trail, the sending PSP's reference, and a reason code. Rejects carry AT-R004, Recalls carry AT-R051, the refusal of a Recall carries AT-R057, and a Request for Recall carries its own reason attribute. A Recall answer and a Request for Recall answer each carry a complete copy of the original inter-PSP payment dataset.", "citation": "EPC004-16 SCT Inst Rulebook 2025 v1.1, sections 4.3.2.1 to 4.3.2.3, 4.5.6, 4.5.9 and 4.6.1", "rests_on": "rule" }, { "label": "One field for the customer who has to sue", "value": "Where a Request for Recall is refused because the beneficiary account identifier was wrong, the answer may carry an optional attribute holding everything the receiving PSP has that would let the payer bring a legal claim to recover the money. Payment services law has a matching duty on the payer's own PSP: once its efforts to recover funds sent to a wrong unique identifier have failed, it must give the payer, if asked in writing, the information it holds that the payer needs to sue. AT-R078 is how that information can travel back between the banks.", "citation": "EPC004-16 SCT Inst Rulebook 2025 v1.1, section 4.5.9 attribute AT-R078; Directive (EU) 2015/2366, Article 88(3)", "rests_on": "law" }, { "label": "Where the reason code values come from", "value": "The guidance tables each code with two readings side by side: the generic definition ISO gives it, and the reason the SCT Inst rulebook or its guidelines attach to it, which is the meaning that counts on this scheme. It reminds Participants to use the codes the rulebook describes, because some beneficiary PSPs had been using the wrong ones, and it deals with three R-transactions only: Rejects, Recalls and Requests for Recall by the Originator.", "citation": "EPC059-18 v7.0 (2025-10-05), sections 1 and 2, and the column headings of the section 3 table", "rests_on": "guidance" }, { "label": "The message change with a date on it", "value": "From 15 November 2026, at 03:30 CET, an address may only be sent in hybrid or structured form. The EPC moved that date forward from 22 November 2026 in September 2025 to line up with the Swift standards release that month, and version 1.1 of this rulebook exists to carry the new date.", "citation": "EPC004-16 SCT Inst Rulebook 2025 v1.1, IMPORTANT MESSAGE on the cover and the Annex IV entry for section 4.6 on AT-P005 and AT-E004", "rests_on": "rule" }, { "label": "The rulebook calendar", "value": "A change release is opened at least once every two years, and the PSMB may run them closer together. However often changes are asked for, the PSMB approves at most one package of them in a year, outside the two emergency routes below. Each package goes to a public consultation meant to close after 90 calendar days, and once approved it cannot take effect until at least six months after its publication on the EPC website, longer where the EPC judges the change complex. The normal entry into force for new rulebook versions is the third weekend of November.", "citation": "EPC004-16 SCT Inst Rulebook 2025 v1.1, Annex II (EPC207-14 Payment Scheme Management Rules v5.0), sections 4.2.3, 4.2.7 and 4.5", "rests_on": "rule" }, { "label": "The two routes that skip the notice period", "value": "An exceptional change, for a material mistake or flaw that would otherwise disrupt the scheme, and a regulatory change, where new or amended law forces alignment, can both take effect as early as the business day after the PSMB decision is published, on a date the PSMB sets case by case. The rules describe neither as passing through the 90 day consultation.", "citation": "EPC004-16 SCT Inst Rulebook 2025 v1.1, Annex II (EPC207-14 Payment Scheme Management Rules v5.0), sections 4.2.8 and 4.2.9", "rests_on": "rule" }, { "label": "What notice this edition actually gave", "value": "The consultation on the 2024 change requests closed on 9 June 2024, the PSMB approved the package in September 2024, and version 1.0 of the 2025 rulebook is dated 28 November 2024. It took effect on 5 October 2025 at 03:30 CET, a little over ten months after publication and earlier in the year than the usual November date. Version 1.1 changed a single date and carries 5 October 2025 as both issue and effective date. The same history records a 03:30 CET start preceded by a SEPA-wide 30 minute downtime from 03:00 CET, set for the 2023 edition.", "citation": "EPC004-16 SCT Inst Rulebook 2025 v1.1, cover, section 0.2 entries for 2023 v1.1, 2025 v1.0 and 2025 v1.1", "rests_on": "rule" } ], "exceptions": [ "The customer-side datasets, DS-01, DS-04 and DS-10, are mapped in the SCT Inst Customer-to-PSP Implementation Guidelines, which were not read for this record, so no pain or camt name is asserted for them. [Unverified: the Customer-to-PSP guidelines were not read.]", "The guideline's own section 1.7 still names 22 November 2026 for the end of unstructured addresses. Its cover, published on 6 October 2025, says every such reference is to be read as 15 November 2026 (EPC122-16 2025 v1.0, cover and section 1.7).", "Knowing a code's ISO definition is not enough: the meaning the rulebook and its guidelines give the code is the one that governs, and EPC059-18 is a document of its own, separate from the SCT reason code guidance (EPC059-18 v7.0, sections 2 and 3).", "The remittance field is the same 140 characters as on SCT, structured or unstructured, passed on whole and unaltered by every hop. Any instant information a beneficiary PSP gives its customer on top of that is outside the obligation (EPC004-16 2025 v1.1, section 2.7).", "The BIC is not normally needed from the customer. It becomes mandatory on the customer-side dataset only where the sending PSP cannot derive it from the IBAN for an account in a non-EEA SEPA country or territory, and it stays mandatory on the inter-PSP message (EPC004-16 2025 v1.1, section 4.5.1 remarks).", "The 2027 SCT Inst rulebook and its guidelines are due for publication in November 2026 and are expected to take effect in November 2027, on the dates the watch log in docs/rails/sepa.md records. When they take effect this record is superseded, not edited. [Unverified: EPC011-26 and the EPC publication notice were not read for this record.]" ], "applies_to": "the business messages of the SCT Inst scheme and the ISO 20022 standard they are expressed in, in both the customer to PSP space and the inter-PSP space", "caveat": "The confirmation message is the whole control flow on this scheme, so the mapping matters more than on SCT: the same pacs.002 says yes or no, and a returned recall arrives as a pacs.004 rather than as a fresh payment. Field names, cardinalities and message identifiers live in the Implementation Guidelines, which are binding and separate from the rulebook. The identifiers here come from the inter-PSP guideline for the 2025 rulebook; the next rulebook edition brings its own guideline, which may move the ISO version.", "related": [ "sepa-sct-inst:return", "sepa-sct-inst:recall", "sepa-sct-inst:settlement", "sepa-sct-inst:limits", "sepa-sct-inst:participants" ], "basis": { "sources": "EPC004-16 SEPA Instant Credit Transfer Scheme Rulebook 2025 version 1.1 (effective 2025-10-05, marked Public), read for this record: the cover IMPORTANT MESSAGE, sections 0.2, 0.5, 2.7, 4.3.2.1 to 4.3.2.3, 4.5 with 4.5.1, 4.5.3, 4.5.6, 4.5.9 and 4.5.10, 4.6.1 (AT-T056, AT-R004, AT-R051, AT-R057, AT-R078, AT-P005, AT-E004), chapter 7, Annex II (EPC207-14 v5.0, sections 4.2.3, 4.2.7, 4.2.8, 4.2.9 and 4.5) and Annex IV. EPC122-16 SCT Inst Inter-PSP Implementation Guidelines 2025 version 1.0 (issued 2024-11-28, effective 2025-10-05, file published 2025-10-06), read from the copy saved on 2026-09-23: cover, sections 0.1, 1, 1.5.2, 1.7, 2.1 to 2.12 and chapter 3. EPC131-17 Clarification Paper v4.0 (2025-10-05), section 2.3. EPC059-18 v7.0 (2025-10-05), sections 1 and 3. Regulation (EU) No 260/2012, Articles 1(1) and 5(1) and Annex points (1)(a) to (1)(c), read in the consolidated text of 2024-04-08, and Directive (EU) 2015/2366, Article 88(3), read in its Official Journal text; both read from the Publications Office PDFs saved on 2026-09-24, whose public addresses are https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02012R0260-20240408 and https://eur-lex.europa.eu/eli/dir/2015/2366/oj. EPC059-18 v7.0 sections 1 to 3 re-read from the copy saved on 2026-09-23.", "confidence": "high" }, "currency": { "effective_since": "2025-10-05", "effective_note": "The 2025 SCT Inst rulebook and its inter-PSP guideline were both issued for, and took effect at 03:30 CET on, 2025-10-05. Version 1.1 of the rulebook exists solely to move the end of the unstructured address format from 22 November 2026 to 15 November 2026 at 03:30 CET, and the guideline's cover carries the same correction. This edition also required millisecond precision on the time stamp and removed the maximum amount reject reason. The message identifiers here hold until the next rulebook edition and its guideline take effect; when they do, this record is superseded rather than edited. The scheme management rules in Annex II are EPC207-14 v5.0, dated 2023-03-28 and applying to this scheme since 2023-11-28.", "source_edition": "EPC004-16 SCT Inst Scheme Rulebook 2025 version 1.1 (2025-10-05) with Annex II EPC207-14 v5.0; EPC122-16 SCT Inst Inter-PSP Implementation Guidelines 2025 version 1.0 (effective 2025-10-05); EPC131-17 Clarification Paper v4.0 (2025-10-05); EPC059-18 v7.0 (2025-10-05); Regulation (EU) No 260/2012 (consolidated text of 2024-04-08); Directive (EU) 2015/2366 (Official Journal text of 2015-12-23)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-10/EPC004-16%202025%20SCT%20Instant%20Rulebook%20v1.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC004-16 SCT Inst Scheme Rulebook 2025 version 1.1; EPC059-18 v7.0 Guidance on Reason Codes for SCT Inst R-transactions", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the ten datasets DS-01 to DS-10 in section 4.5, that DS-03 serves as both positive and negative confirmation with no separate Reject dataset (4.3.2.1, 4.5.3), DS-10 titled 'Positive Notification Message to the Beneficiary Dataset' as the message SCT has no equivalent for (4.5.10), the ISO mapping pushed to the two Implementation Guidelines (0.5), the AT-T056 millisecond-precision time stamp (4.6.1, Annex IV), the AT-R078 attribute letting a Request for Recall refusal carry information to support a legal claim (4.5.9), and the 15 November 2026 03:30 CET address cutover on the cover notice and Annex IV. Does not independently confirm Regulation 260/2012 Article 5(1) and Annex points (1)(a)-(1)(c), or Directive 2015/2366 Article 88(3); EUR-Lex remains unreachable." }, { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-10/EPC122-16%20SCT%20Inst%20Inter-PSP%20IG%202025%20V1.0.pdf", "source_class": "authoritative_primary", "source_title": "EPC122-16 SCT Inst Inter-PSP Implementation Guidelines 2025 v1.0", "checked_on": "2026-09-24", "checked_by": "Claude validator (Sonnet)", "notes": "Confirms pacs.008.001.08 carrying DS-02 with Local Instrument code INST mandatory in section 2.1, the AT-T056 millisecond timestamp requirement in section 1.5.2, the cover notice correcting every 22 November 2026 reference in the document to 15 November 2026, and section 1.7 on the change-over date and the no-overlap rule for new message versions." }, { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-10/EPC131-17%20v4.0%20Clarification%20Paper%20SCT%20and%20SCT%20Inst%20scheme%20rulebooks.pdf", "source_class": "authoritative_primary", "source_title": "EPC131-17 Clarification Paper on the SCT and SCT Inst Scheme Rulebooks v4.0", "checked_on": "2026-09-24", "checked_by": "Claude validator (Sonnet)", "notes": "Confirms section 2.3: the customer-to-PSP Implementation Guidelines bind a PSP to accept the EPC bulk file format only where that PSP offers its Originators an electronic bulk file service, and that Originators using online banking or paper keep their existing file set-up." }, { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2023-03/EPC207-14%20EPC%20Payment%20Scheme%20Management%20Rules%20v5.0.pdf", "source_class": "authoritative_primary", "source_title": "EPC207-14 EPC Payment Scheme Management Rules v5.0", "checked_on": "2026-09-24", "checked_by": "Claude validator (Sonnet)", "notes": "Confirms section 4.2.7: a change release cycle opens at least every two years, at most one change package is approved in a year, a public consultation targets 90 calendar days, and implementation waits at least six months after publication, longer for complex changes. Confirms sections 4.2.8 and 4.2.9: an exceptional change for a material flaw and a change for regulatory reasons may both take effect from the business day after PSMB publication on a case by case date, skipping the standard notice period." }, { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-10/EPC059-18%20v7.0%20Guidance%20on%20Reason%20Codes%20for%20SCT%20Inst%20R-transactions.pdf", "source_class": "authoritative_primary", "source_title": "EPC059-18 v7.0 Guidance on Reason Codes for SCT Inst R-transactions", "checked_on": "2026-09-24", "checked_by": "Claude validator (Sonnet)", "notes": "Confirms the guidance table lists each code with its ISO definition and the reason the SCT Inst rulebook or its Implementation Guidelines attach to it, and confirms section 2's statement that Beneficiary PSPs had been using incorrect reason codes and are reminded to use the ones the rulebook describes. Confirms the document covers only three R-transaction types: Rejects, Recalls and Requests for Recall by the Originator. Does not name the ISO 20022 Registration Authority anywhere in sections 1 to 3." }, { "source_url": "https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02012R0260-20240408", "source_class": "authoritative_primary", "source_title": "Regulation (EU) No 260/2012 (SEPA Regulation), consolidated text of 2024-04-08", "checked_on": "2026-09-24", "checked_by": "Claude validator (Sonnet)", "notes": "The copy read was the Official Journal PDF from the EU Publications Office, saved 2026-09-24. Confirms Article 1(1): the Regulation covers euro credit transfer and direct debit transactions where both PSPs, or the sole PSP, are located in the Union. Confirms Article 5(1)(a) and (b): PSPs must use the payment account identifier in Annex point (1)(a) and the message format in Annex point (1)(b). Confirms Annex points (1)(a) and (1)(b): the identifier is IBAN and the message format standard is ISO 20022 XML." }, { "source_url": "https://eur-lex.europa.eu/eli/dir/2015/2366/oj", "source_class": "authoritative_primary", "source_title": "Directive (EU) 2015/2366 (PSD2), Official Journal text", "checked_on": "2026-09-24", "checked_by": "Claude validator (Sonnet)", "notes": "The copy read was the Official Journal PDF from the EU Publications Office, saved 2026-09-24. Confirms Article 88(3): once the payer's PSP's reasonable efforts to recover funds sent under an incorrect unique identifier fail, it must give the payer, on written request, all information it holds that is relevant for the payer to bring a legal claim to recover the funds." } ] }, "rail_name": "SEPA Instant Credit Transfer", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sct-inst:participants", "id": "participants", "rail": "sepa-sct-inst", "kind": "rail-fact", "facet": "participants", "name": "Who can be on this rail, in what roles, and who cannot?", "statement": "The eligibility tests are the SEPA Credit Transfer (SCT) tests almost word for word, but the participation duty is not. On SCT a Participant has to do both directions. On SCT Inst it has to do at least the receiving direction, and may stop there, because some Participants are not caught by the EU obligation to send and some never will be. The other differences are operational: every Participant has to run the scheme around the clock on every calendar day, and has to hold a CSM contract good enough to carry settlement certainty on every single transaction. Being a Participant says nothing about which accounts can be paid: each Participant decides which of its accounts take incoming instant payments, within the law, and the public list the rulebook provides for is the EPC register of who has adhered. The payee check that now sits in front of the payment is a duty the amended SEPA Regulation puts on PSPs; the EPC Verification Of Payee scheme is one optional way of meeting it, with an adherence of its own.", "details": [ { "label": "The four roles in a payment", "value": "The originator who instructs, the originator PSP that reserves and sends, the beneficiary PSP that receives, releases the money and confirms, and the beneficiary who is paid. One Participant can be both PSPs on the same transaction.", "citation": "EPC004-16 SCT Inst Rulebook 2025 v1.1 (effective 2025-10-05), section 3.1", "rests_on": "rule" }, { "label": "Receiving is compulsory, sending is not", "value": "A Participant has to offer the scheme either in both roles or at least as beneficiary PSP, subject to the law that applies to it. The rulebook rewrote this in the 2025 edition to follow Article 5a(1) of the amended SEPA Regulation, because some Participants are not yet caught by the dual obligation and some never will be, for instance those based outside the EEA.", "citation": "EPC004-16 SCT Inst Rulebook 2025 v1.1, sections 2.6 and 5.3, with the Annex IV entries for those sections", "rests_on": "rule" }, { "label": "Where the sending duty actually comes from", "value": "Law, not the rulebook. What triggers it is already offering ordinary credit transfers both ways: such a PSP must offer instant ones, in both directions, to every customer, and any account an ordinary transfer can reach must be reachable by an instant one around the clock on every calendar day. When depends on where the PSP sits and what kind it is. Euro area: receiving from 9 January 2025 and sending from 9 October 2025, with payment and e-money institutions taking on both from 9 April 2027. Outside the euro area: sending from 9 July 2027 for all, receiving from 9 January 2027 or, for payment and e-money institutions, 9 April 2027, and until 9 June 2028 no duty to send from national currency accounts during hours when the PSP handles no ordinary euro transfers for them.", "citation": "Regulation (EU) No 260/2012 as amended by Regulation (EU) 2024/886, Article 5a(1) and 5a(8), read in the consolidated text of 2024-04-08", "rests_on": "law" }, { "label": "Always on, as a condition of participation", "value": "Both the sending and the receiving side have to be able to process 24 hours a day on every calendar day, business continuity arrangements included, whether those are run in house or by someone else. The only permitted gaps are planned maintenance or downtime that is foreseeable, short and announced to customers beforehand.", "citation": "EPC004-16 SCT Inst Rulebook 2025 v1.1, section 5.7 point 5, section 5.8 point 4, and section 5.3 last paragraph", "rests_on": "rule" }, { "label": "A CSM contract is not optional", "value": "Both sides have to contract with a CSM, directly or indirectly, on terms that let them deliver their settlement obligations to each other. The sending side also has to provide settlement certainty on every transaction it sends.", "citation": "EPC004-16 SCT Inst Rulebook 2025 v1.1, section 5.7 points 7 and 9, and section 5.8 point 7", "rests_on": "rule" }, { "label": "Who is not in the scheme", "value": "CSMs, intermediary PSPs and payment initiation service providers all take part in the flow without being Participants. The rulebook's account of what CSMs do is marked as information only, and using an intermediary changes none of a Participant's own obligations and must not alter the time stamp.", "citation": "EPC004-16 SCT Inst Rulebook 2025 v1.1, sections 3.1, 3.3 and 3.4", "rests_on": "rule" }, { "label": "The nine eligibility tests", "value": "Continuously, an applicant has to be in the business of providing banking or payment services and of holding and moving customer funds; hold a licence, either from the SEPA country it is incorporated in or from an EEA regulator; be solvent and able to pay its debts; hold enough liquidity and capital for its own regulatory regime; meet any rating criteria the scheme sets; comply with anti money laundering, sanctions and terrorist financing rules; take part directly or indirectly in at least one CSM; and run operational and risk controls suited to its business.", "citation": "EPC004-16 SCT Inst Rulebook 2025 v1.1, section 5.4", "rests_on": "rule" }, { "label": "Who passes automatically", "value": "Credit institutions authorised under Article 8(1) of Directive 2013/36/EU by an EEA state, the bodies listed in points (2) to (23) of Article 2(5) of that Directive, and institutions licensed by a national competent authority in a non-EEA country the schemes' geography has been extended to. Payment institutions authorised under Article 11 of the Payment Services Directive are treated as meeting a subset of the tests.", "citation": "EPC004-16 SCT Inst Rulebook 2025 v1.1, section 5.4", "rests_on": "rule" }, { "label": "How you get in, and how you get out", "value": "An eligible undertaking applies to the EPC with a signed Adherence Agreement and supporting documentation, and becomes a Participant on a date the EPC sets. A rejection comes with reasons and can be appealed. Leaving needs six months' written notice, and the Participant stays bound for everything it did before it left.", "citation": "EPC004-16 SCT Inst Rulebook 2025 v1.1, sections 5.5 and 5.11", "rests_on": "rule" }, { "label": "What a sender can look up before it sends", "value": "The EPC keeps a Register of Participants for this scheme and publishes it on its website, open for download. What goes public from each application is the name, the registered office address, the reference BIC and the readiness date. Nothing in that list of published fields says whether a Participant sends as well as receives, through which CSM it can be reached, or which of its accounts are open to instant payments.", "citation": "EPC004-16 SCT Inst Rulebook 2025 v1.1, Annex I, Schedule to the Adherence Agreement, points (A), (C) and (D); chapter 7 entry for List of SCT Inst Participants", "rests_on": "rule" }, { "label": "Which accounts are reachable is the Participant's call", "value": "Subject to the law that binds it, a Participant keeps the commercial freedom to decide which accounts count as payment accounts and on which of them it offers the scheme. The EPC strongly encourages every Participant, at least as beneficiary PSP, to open to incoming instant payments any euro or national currency account already open to ordinary SCT, and names the cost of not doing so as needless rejects. The rulebook's own definition of reachability is that every payment account in SEPA can receive under the scheme. What the law adds is narrower and binding: inside the Union, an account an ordinary credit transfer can reach has to be reachable by an instant one too.", "citation": "EPC131-17 Clarification Paper v4.0 (2025-10-05), section 4.1 with its footnote 1; EPC004-16 SCT Inst Rulebook 2025 v1.1, chapter 7 entry for Reachability; Regulation (EU) No 260/2012 as amended by Regulation (EU) 2024/886, Article 5a(1) second subparagraph", "rests_on": "guidance" }, { "label": "How a Participant is reached", "value": "The scheme prescribes no route. A Participant may use a CSM, an intermediary PSP, or several arrangements together, at its own risk, provided it stays reachable and compliant, and it may be unreachable only for planned, short maintenance its customers were told about. The inter-PSP guideline mirrors that openness at message level: settlement may run through a clearing system or directly between the instructing and instructed agents.", "citation": "EPC004-16 SCT Inst Rulebook 2025 v1.1, section 5.3; EPC122-16 SCT Inst Inter-PSP Implementation Guidelines 2025 v1.0, section 2.1 element 1.9", "rests_on": "rule" }, { "label": "The payee check: the duty is law, the scheme is optional", "value": "Two layers with different sources. From the IPR: every payer's PSP has to offer the check, and the payee's PSP has to answer a payer's PSP that asks; the law names no scheme, and its recitals only hope for a Union-wide set of rules that bodies of PSPs could write. Euro area PSPs owe this from 9 October 2025, the rest of the Union from 9 July 2027. From the EPC VOP rulebook: joining the EPC's Verification Of Payee scheme is optional and takes an Adherence Agreement separate from the SCT Inst one, and once in, a member that services payment accounts must act both as requesting and as responding PSP, while one that services none must act at least as requesting PSP. The scheme runs across the countries on the EPC list of SEPA scheme countries, which reaches further than the law does.", "citation": "Regulation (EU) No 260/2012 as amended by Regulation (EU) 2024/886, Article 5c(1)(a) and 5c(9); Regulation (EU) 2024/886, recital 23; EPC218-23 Verification Of Payee Scheme Rulebook 2026 v1.1 (effective 2026-09-20), sections 1.4, 1.6, 1.7 and 4.1", "rests_on": "law" }, { "label": "One class of PSP the 2024 law let in", "value": "Payment institutions and electronic money institutions fell outside the settlement finality Directive's definition of an institution, which in practice kept them out of designated payment systems and so out of competitive access to instant payments. Regulation (EU) 2024/886 rewrote that definition to include them, but only for deciding who participates in a system, and not where a payment institution relies on an exemption under Article 32 or 33 of the Payment Services Directive or an e-money institution on a waiver under Article 9 of the E-Money Directive. Member States had until 9 April 2025 to transpose the change. The same Regulation added Article 35a to the Payment Services Directive, which lists what such an institution must have in place to ask for and keep participation: a description of how it safeguards customer funds and of its governance and controls, and a winding-up plan.", "citation": "Regulation (EU) 2024/886, recitals 15 and 16, Article 3(3) (inserting Article 35a into Directive (EU) 2015/2366), Article 4(1) (replacing Article 2(b) of Directive 98/26/EC) and Article 5", "rests_on": "law" } ], "exceptions": [ "Adherence is per scheme. A Participant in SCT Inst is not thereby in SCT, SDD Core or SDD B2B. [Inference: each scheme's rulebook carries its own Adherence Agreement and its own list of Participants; no single EPC statement to that effect was read.]", "Geography is set by a separate document, the EPC list of countries and territories in the schemes' scope. [Unverified: EPC409-09 was not read for this record.]", "A Participant outside the EEA is bound by neither the Directive nor the amended Regulation directly, and takes on substantially equivalent obligations through the rulebook instead. That is why receive-only participation exists (EPC004-16 2025 v1.1, sections 5.3 and 5.14).", "A PSP in a Member State outside the euro area may, with its supervisor's prior permission, granted a year at a time on the strength of its access to euro liquidity, cap instant sending from national currency accounts at a per transaction limit the supervisor sets at EUR 25 000 or more, during hours when it handles no ordinary euro transfers for those accounts. A central bank acting commercially may confine its instant sending to the hours it offers ordinary transfers (Regulation (EU) No 260/2012 as amended, Article 5a(2)).", "How many Participants there are, and who they are, is not stated in the rulebook. The register is a separate EPC publication. [Unverified: the SCT Inst list of Participants was not read for this record.]", "The EPC writes the rules and manages the scheme. It operates no network and settles nothing, so it is never a party to a payment (EPC004-16 2025 v1.1, sections 3.3 and 5.10).", "Article 5c of the amended SEPA Regulation puts the payee check duties on PSPs and names no scheme, and recital 23 of Regulation (EU) 2024/886 asks only that the check follow, as far as possible, Union-wide rules that bodies of PSPs could develop. The rulebook calls participation optional and presents the scheme as support for PSPs meeting that duty (EPC218-23 2026 v1.1, sections 1.10 and 4.1). [Inference: that the duty can be met outside the EPC scheme; no regulator or Commission statement was read.]", "The law's payee check reaches euro credit transfers whose PSPs are in the Union (Regulation (EU) No 260/2012, Article 1(1)). A scheme member in a SEPA country outside the EEA is held to equivalent duties only through the VOP rulebook, which asks such members to take on substantially equivalent obligations as far as their own law allows (EPC218-23 2026 v1.1, section 4.14).", "Which CSMs carry SCT Inst, how they reach each other, and whether a Participant reachable in one is reachable from the others are not in any EPC document read for this record; the rulebook and the guideline name no CSM." ], "applies_to": "adherence to the EPC SEPA Instant Credit Transfer scheme and the roles of the parties to a transaction made under it, and, where it sits in front of an SCT Inst payment, adherence to the EPC Verification Of Payee scheme", "caveat": "Receive-only participation is the fact most easily missed. A Participant listed on this scheme may be unable to send at all, and whether it can depends on where it is authorised and which deadline in the amended SEPA Regulation reaches it. Checking that a counterparty is a Participant does not establish that it can originate.", "related": [ "sepa-sct-inst:settlement", "sepa-sct-inst:hours", "sepa-sct-inst:messages", "sepa-sct-inst:liability", "sepa-sct-inst:consumer-law", "sepa-sct-inst:limits", "sepa-sct-inst:return", "sepa-sct-inst:CNOR" ], "basis": { "sources": "EPC004-16 SEPA Instant Credit Transfer Scheme Rulebook 2025 version 1.1 (effective 2025-10-05, marked Public), read for this record: sections 2.1, 2.6, 3.1, 3.3, 3.4, 5.2, 5.3, 5.4, 5.5, 5.6, 5.7 points 5, 7 and 9, 5.8 points 4 and 7, 5.10, 5.11, 5.14, and Annex IV entries for sections 2.6, 5.3 and 5.7. Regulation (EU) No 260/2012 as amended by Regulation (EU) 2024/886, Articles 1(1), 5a(1), 5a(2), 5a(8), 5c(1) and 5c(9), read in the consolidated text of 2024-04-08, and Regulation (EU) 2024/886, recitals 15, 16 and 23 and Articles 3(3), 4(1) and 5, read in its Official Journal text; both read from the Publications Office PDFs saved on 2026-09-24, whose public addresses are https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02012R0260-20240408 and https://eur-lex.europa.eu/eli/reg/2024/886/oj. Also read for this record from the copies saved on 2026-09-23: EPC004-16 2025 v1.1 Annex I schedule and chapter 7; EPC131-17 Clarification Paper v4.0 (2025-10-05), section 4.1; EPC122-16 SCT Inst Inter-PSP Implementation Guidelines 2025 v1.0, section 2.1; EPC218-23 Verification Of Payee Scheme Rulebook 2026 v1.1 (issued 2026-03-16, effective 2026-09-20), sections 1.4, 1.6, 1.7, 1.10, 4.1 and 4.14.", "confidence": "high" }, "currency": { "effective_since": "2026-09-20", "effective_note": "The SCT Inst lines rest on the 2025 SCT Inst rulebook, issued and effective 2025-10-05, and on the 2025 inter-PSP guideline effective the same day. The payee check line rests partly on the 2026 Verification Of Payee rulebook v1.1, effective 2026-09-20 at 03:30 CET, which is why the record as a whole is dated from then. Annex IV records that sections 2.6 and 5.3 were rewritten in this edition to follow Article 5a(1) of the amended SEPA Regulation, and that the planned downtime wording follows Article 11(1c). The staged obligations in Article 5a(8) run from 2025-01-09 for euro area receiving through to 2027-07-09 for non-euro area sending, with a derogation for some non-euro area sending until 2028-06-09. The 2027 SCT Inst rulebook is due for publication in November 2026 and would supersede this record when it takes effect.", "source_edition": "EPC004-16 SCT Inst Scheme Rulebook 2025 version 1.1 (2025-10-05); EPC122-16 SCT Inst Inter-PSP Implementation Guidelines 2025 version 1.0 (2025-10-05); EPC131-17 Clarification Paper v4.0 (2025-10-05); EPC218-23 Verification Of Payee Scheme Rulebook 2026 version 1.1 (2026-09-20); Regulation (EU) No 260/2012 as amended by Regulation (EU) 2024/886 (consolidated text of 2024-04-08); Regulation (EU) 2024/886 (Official Journal text of 2024-03-19)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-10/EPC004-16%202025%20SCT%20Instant%20Rulebook%20v1.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC004-16 SCT Inst Scheme Rulebook 2025 version 1.1", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the four-corner model (3.1), the receive-only participation option worded 'subject to the laws applicable to them ... both Originator PSP and Beneficiary PSP, or in the role of at least Beneficiary PSP' (2.6), the always-on and CSM-contract participation duties already confirmed for the settlement and hours facts (5.7 points 5, 7, 9; 5.8 points 4, 7; 5.3), CSMs/intermediaries/PISPs as non-Participants (3.1, 3.3, 3.4), and the nine eligibility tests and automatic-pass categories that mirror SCT section 5.4 word for word. Does not independently confirm Regulation 260/2012 Article 5a(1), 5a(2), 5a(8) as amended, or Regulation 2024/886 recitals 15-16; EUR-Lex remains unreachable." }, { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-10/EPC131-17%20v4.0%20Clarification%20Paper%20SCT%20and%20SCT%20Inst%20scheme%20rulebooks.pdf", "source_class": "authoritative_primary", "source_title": "EPC131-17 Clarification Paper on the SCT and SCT Inst Scheme Rulebooks v4.0", "checked_on": "2026-09-24", "checked_by": "Claude validator (Sonnet)", "notes": "Confirms section 4.1: subject to the laws applicable to it, an SCT Inst scheme participant keeps the commercial freedom to decide which accounts are payment accounts and which of those take SCT Inst, and participants are strongly encouraged, at least as Beneficiary PSP, to open euro or national-currency accounts already open to SCT to incoming SCT Inst as well, since not doing so causes unnecessary rejects. The footnote ties this to Article 5a(8) of Regulation (EU) 2024/886." }, { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-10/EPC122-16%20SCT%20Inst%20Inter-PSP%20IG%202025%20V1.0.pdf", "source_class": "authoritative_primary", "source_title": "EPC122-16 SCT Inst Inter-PSP Implementation Guidelines 2025 v1.0", "checked_on": "2026-09-24", "checked_by": "Claude validator (Sonnet)", "notes": "Confirms section 2.1 element 1.9 on Settlement Method, supporting that a Participant may be reached through a CSM or a direct relationship between the instructing and instructed agents." }, { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2026-03/EPC218-23%20v1.1%202026%20Verification%20Of%20Payee%20Scheme%20Rulebook_0.pdf", "source_class": "authoritative_primary", "source_title": "EPC218-23 Verification Of Payee Scheme Rulebook 2026 v1.1", "checked_on": "2026-09-24", "checked_by": "Claude validator (Sonnet)", "notes": "Confirms that VOP scheme membership is by its own Adherence Agreement, separate from the SCT Inst one, and that a Participant servicing payment accounts acts as both Requesting and Responding PSP while one that services none acts at least as Requesting PSP. Confirms the obligations of a Requesting PSP list in section 4.7 and a Responding PSP list in section 4.8, and that participation obligations run subject to the laws applicable to the Participant." }, { "source_url": "https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02012R0260-20240408", "source_class": "authoritative_primary", "source_title": "Regulation (EU) No 260/2012 (SEPA Regulation), consolidated text of 2024-04-08", "checked_on": "2026-09-24", "checked_by": "Claude validator (Sonnet)", "notes": "The copy read was the Official Journal PDF from the EU Publications Office, saved 2026-09-24. Confirms Article 5a(1): a PSP offering both-way ordinary credit transfers must offer both-way instant ones, and every account reachable for ordinary transfers must be reachable for instant ones 24 hours a day on every calendar day. Confirms Article 5a(8): the staged euro area and non-euro area deadlines for receiving and sending, including the 2027-04-09 date for payment and e-money institutions and the 2028-06-09 outer date for a non-euro area sending derogation. Confirms Article 5c(1)(a) and 5c(9): the payer's PSP must offer the payee-verification service and the euro area and non-euro area compliance dates." }, { "source_url": "https://eur-lex.europa.eu/eli/reg/2024/886/oj", "source_class": "authoritative_primary", "source_title": "Regulation (EU) 2024/886 (Instant Payments Regulation), Official Journal text", "checked_on": "2026-09-24", "checked_by": "Claude validator (Sonnet)", "notes": "The copy read was the Official Journal PDF from the EU Publications Office, saved 2026-09-24. Confirms recital 23: the payee-verification service should as far as possible follow a Union-wide set of rules and standards that could be developed by organisations composed of, or representing, PSPs, naming no particular scheme. Confirms Article 4(1), inserting a new Article 2(b) into Directive 98/26/EC, and Article 3(3), inserting Article 35a into Directive (EU) 2015/2366, which sets out what a payment or e-money institution must have in place, including a description of how it safeguards customer funds and a winding-up plan, to participate in a designated system." } ] }, "rail_name": "SEPA Instant Credit Transfer", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sct-inst:recall", "id": "recall", "rail": "sepa-sct-inst", "kind": "rail-fact", "facet": "recall", "name": "Can a sent payment be recalled, and who decides?", "statement": "A completed SEPA Instant Credit Transfer can be asked back two ways, and both are requests. An SCT Inst Recall comes from the originator PSP and is confined to three grounds: a duplicate, a technical fault that produced a wrong transaction, and fraud behind the instruction. Everything else, a payment to the wrong IBAN or for the wrong amount included, goes as a Request for Recall by the Originator. The windows are ten Banking Business Days for the duplicate and technical grounds and thirteen months for fraud and for any Request for Recall. The beneficiary PSP owes an answer in fifteen Banking Business Days and may refuse. Because this scheme has no Return, these are the only paths back, and neither compels anyone to pay.", "details": [ { "label": "Who may start a Recall, and on what grounds", "value": "The sending PSP alone, on its own account or for its customer. Before raising one it has to satisfy itself that the case is a duplicate, a technical fault that produced a wrong transaction, or fraud behind the instruction. Nothing else qualifies.", "citation": "EPC004-16 SCT Inst Rulebook 2025 v1.1 (effective 2025-10-05), section 4.3.2.2 and process steps CT-02.00 and CT-02.01", "rests_on": "rule" }, { "label": "The two windows", "value": "Ten Banking Business Days for a duplicate or a technical fault, thirteen months for fraud, both counted from the execution date of the original transaction. A sending PSP may turn its own customer down where the grounds do not fit or the window has closed.", "citation": "EPC004-16 SCT Inst Rulebook 2025 v1.1, section 4.3.2.2 and process step CT-02.01R", "rests_on": "rule" }, { "label": "Days in a scheme that otherwise has none", "value": "These windows are the only part of SCT Inst measured in days. Banking Business Days, pinned to T2 days, govern the Recall and the Request for Recall and nothing else; the payment itself runs on seconds and calendar days.", "citation": "EPC004-16 SCT Inst Rulebook 2025 v1.1, chapter 7 Defined Terms entry Banking Business Day", "rests_on": "rule" }, { "label": "One request only", "value": "One Recall per transaction inside those windows, and none at all once the receiving PSP has answered. Silence past fifteen Banking Business Days buys the sending PSP a Request for Status Update, but never a second Recall.", "citation": "EPC004-16 SCT Inst Rulebook 2025 v1.1, section 4.3.2.2 and process step CT-02.07, with the Annex IV entry for section 4.3.2.2", "rests_on": "rule" }, { "label": "The answer is compulsory, the return is not", "value": "The receiving PSP has to work every Recall and give a yes or a no inside fifteen Banking Business Days. Failing to answer puts it in breach of the rulebook. Where its own customer has gone quiet, it has to send a no that says exactly that.", "citation": "EPC004-16 SCT Inst Rulebook 2025 v1.1, section 4.3.2.2 and process step CT-02.03", "rests_on": "rule" }, { "label": "Who actually decides", "value": "It depends on the country and the account contract. With the money still on the account, the receiving PSP may be free to debit it and answer yes straight away, may judge that it should ask the customer first, or may have no choice but to get the customer's authorisation. So in some SEPA countries the bank decides and in others the customer does.", "citation": "EPC004-16 SCT Inst Rulebook 2025 v1.1, process steps CT-02.03 and CT-02.03A", "rests_on": "rule" }, { "label": "The grounds for saying no", "value": "Seven of them: not enough money on the account, the account is closed, a legal obstacle set out in plain text, the customer refused, the customer never answered inside the fifteen days, the original transaction never arrived, and the money has already gone back.", "citation": "EPC004-16 SCT Inst Rulebook 2025 v1.1, process step CT-02.03R and section 4.6.1 attribute AT-R057", "rests_on": "rule" }, { "label": "Which codes carry all this", "value": "The guidance turns the three grounds into DUPL, TECH and FRAD, a yes into FOCR, and the seven refusals into CUST for the customer's refusal, LEGL for a legal obstacle, AC04 closed, AM04 not enough money, NOAS no answer, NOOR original never received and ARDT already sent back. On a Request for Recall it names AC03 for the wrong account identifier, AM09 for the wrong amount and CUST where no reason is given.", "citation": "EPC059-18 v7.0 (2025-10-05), section 3", "rests_on": "guidance" }, { "label": "The other route, for every other reason", "value": "Where the customer wants its money back for a reason outside those three grounds, the sending PSP raises a Request for Recall by the Originator. It has to warn the customer first that this may not work, because the beneficiary has to consent, and it has to check that the original debit falls inside the thirteen months before the customer's request reached it.", "citation": "EPC004-16 SCT Inst Rulebook 2025 v1.1, section 4.3.2.3 and step 1", "rests_on": "rule" }, { "label": "Instant on the way there, not on the way back", "value": "Everyone in the inter-PSP space has to pass a Recall and its answer along without delay, and the sending PSP may choose whether to send a Request for Recall instantly or not. The transport is fast; the decision can still take fifteen Banking Business Days.", "citation": "EPC004-16 SCT Inst Rulebook 2025 v1.1, sections 4.3.2.2 and 4.3.2.3, with process steps CT-02.02 and CT-02.05", "rests_on": "rule" }, { "label": "How the money comes back, and at what cost", "value": "On a yes, the receiving PSP debits its customer, having taken authorisation first where it needs it, and must answer on the response message rather than pushing a separate SCT Inst. What arrives can be less than what left, because the receiving PSP may bill a fee, and only where the answer is yes. The two CSMs then square the position between the PSPs.", "citation": "EPC004-16 SCT Inst Rulebook 2025 v1.1, sections 4.3.2.2 and 4.3.2.3 step 4A, with process steps CT-02.04 to CT-02.06", "rests_on": "rule" } ], "exceptions": [ "There is no pre-settlement Recall here in any practical sense. On SEPA Credit Transfer (SCT) a Recall raised before settlement becomes a CSM cancellation; on SCT Inst the payment is over in seconds, so a Recall always arrives after the money reached the beneficiary or after the transaction was rejected (EPC004-16 2025 v1.1, sections 4.2.3 and 4.3.2.2). [Inference: the rulebook describes no pre-settlement Recall path, rather than forbidding one.]", "A refusal on a Request for Recall ends it. The rulebook treats the beneficiary's answer as settling what becomes of the original transaction for both PSPs (EPC004-16 2025 v1.1, section 4.3.2.3 step 4B).", "Thirteen months is also the outer limit law gives a customer for raising an unauthorised or badly executed transaction, counted from the debit (Directive (EU) 2015/2366, Article 71(1)).", "A Request for Status Update is not a second Recall. It can cover one earlier request or several (EPC004-16 2025 v1.1, sections 4.3.2.2 and 4.3.2.3).", "The status investigation in section 4.4 is a different thing. It asks what became of a transaction whose confirmation never turned up; it does not ask for money back (EPC004-16 2025 v1.1, section 4.4).", "Whether a receiving PSP may debit its customer without asking comes from national law and the account contract, not the scheme, so one Recall can behave two different ways in two SEPA countries (EPC004-16 2025 v1.1, CT-02.03)." ], "applies_to": "a SEPA Instant Credit Transfer whose funds have been made available and that the sending side wants back, through either the SCT Inst Recall or the Request for Recall by the Originator procedure", "caveat": "This is the whole of the reversal story on this rail. With no Return, a wrong-account or fraud case has exactly one path: a request the beneficiary side can refuse, answered in up to 15 Banking Business Days, on a payment that took 5 seconds. Any design that assumes money can be pulled back from an SCT Inst is wrong.", "related": [ "sepa-sct-inst:finality", "sepa-sct-inst:return", "sepa-sct-inst:refund", "sepa-sct-inst:liability", "sepa-sct-inst:messages", "sepa-sct-inst:hours", "sepa-sct-inst:decision-points" ], "basis": { "sources": "EPC004-16 SEPA Instant Credit Transfer Scheme Rulebook 2025 version 1.1 (effective 2025-10-05, marked Public), read for this record: section 4.3.2.2 (SCT Inst Recall) with process steps CT-02.00 to CT-02.07, section 4.3.2.3 (Request for Recall by the Originator) with steps 1 to 5, section 4.3.2.4, section 4.4, sections 4.5.5 to 4.5.9 (DS-05 to DS-09), section 4.6.1 (AT-R051 to AT-R057, AT-R071 onwards), chapter 7 (Banking Business Day), and Annex IV entries for sections 4.3.2.2 and 4.3.2.3. EPC059-18 v7.0 (2025-10-05), sections 1 and 3, for the ISO codes DUPL, TECH, FRAD, FOCR, CUST, LEGL, AC04, AM04, NOAS, NOOR, ARDT, AC03 and AM09. Directive (EU) 2015/2366 consolidated 2024-04-08, Article 71(1), read on EUR-Lex.", "confidence": "high" }, "currency": { "effective_since": "2025-10-05", "effective_note": "The 2025 SCT Inst rulebook was issued and took effect on 2025-10-05. Annex IV records that this edition added the single-Recall and single-Request rules, the bar on re-sending after a response, and the Request for Status Update wording. The 10 Banking Business Day and 13 month windows and the 15 Banking Business Day answer are older; the date each first took effect is [Unverified] because earlier editions were not read. The 2026 change request consultation EPC009-26 proposes a longer recall timeline for the duplicate and technical reasons for the 2027 rulebook; nothing is adopted.", "source_edition": "EPC004-16 SCT Inst Scheme Rulebook 2025 version 1.1 (2025-10-05); EPC059-18 v7.0 (2025-10-05); Directive (EU) 2015/2366 consolidated 2024-04-08", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-10/EPC004-16%202025%20SCT%20Instant%20Rulebook%20v1.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC004-16 SCT Inst Scheme Rulebook 2025 version 1.1; EPC059-18 v7.0 Guidance on Reason Codes for SCT Inst R-transactions", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the SCT Inst Recall grounds limited to duplicate, technical fault and fraud, the 10 banking business day and 13 month windows counted from execution date, one recall per transaction, the 15 banking business day compulsory response with a no-response default of 'No response from the Beneficiary,' and that only Request for Status Update (not a second Recall) follows silence (4.3.2.2). Confirms the parallel Request for Recall by the Originator route with its own warning and 13 month check (4.3.2.3). Does not independently confirm Directive 2015/2366 Article 71(1) cited in the exceptions; EUR-Lex remains unreachable." } ] }, "rail_name": "SEPA Instant Credit Transfer", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sct-inst:refund", "id": "refund", "rail": "sepa-sct-inst", "kind": "rail-fact", "facet": "refund", "name": "Does anyone have a right to be refunded, and on what grounds?", "statement": "The SCT Inst rulebook gives nobody a refund right, and this scheme does not even have the Return that SEPA Credit Transfer (SCT) has. The rights that exist come from law and turn on whether the payment was authorised. An unauthorised one has to be put back almost at once. An authorised one the customer regrets has no refund, only a Request for Recall the beneficiary may turn down. One duty in the scheme looks like a refund but is not: where nothing comes back within ten seconds, the sending PSP has to release what it was holding on its customer's account, which restores money that never left.", "details": [ { "label": "No refund in the scheme", "value": "Exception processing runs to Rejects, Recalls and Requests for Recall by the Originator, plus an optional status investigation. None of them is a refund, and no section describes one.", "citation": "EPC004-16 SCT Inst Rulebook 2025 v1.1 (effective 2025-10-05), sections 4.3.2 and 4.4", "rests_on": "rule" }, { "label": "Why there is none", "value": "An instant credit transfer is pushed by the payer, who authorised it before it moved. The refund rights in payment services law attach to transactions the payee started, which is the direct debit shape, not this one, and the eight week no-questions-asked right is written for direct debits under the SEPA Regulation.", "citation": "Directive (EU) 2015/2366, Article 76(1) and Article 77(1)", "rests_on": "law" }, { "label": "The restoration that is not a refund", "value": "Ten seconds of silence and the sending PSP has to put its customer's account back as it would have been, by releasing the amount it was holding. That is the reservation coming off, not money coming back, and the cover towards the receiving PSP stays in place all the while.", "citation": "EPC004-16 SCT Inst Rulebook 2025 v1.1, section 4.2.3 D and CT-01.11R; Regulation (EU) No 260/2012 as amended by Regulation (EU) 2024/886, Article 5a(5)", "rests_on": "law" }, { "label": "The one real refund right: an unauthorised payment", "value": "Where the customer did not authorise the transaction, its own PSP has to give the money back at once, and by the end of the next business day at the latest after it learns of the claim, with a value date no later than the debit. The one way out is a reasonable suspicion of fraud, which the PSP has to report to its national authority in writing.", "citation": "Directive (EU) 2015/2366, Article 73(1)", "rests_on": "law" }, { "label": "What the customer has to do to keep that right", "value": "Speak up promptly once it knows, and in any case inside thirteen months of the debit. Up to EUR 50 of the loss can fall on the customer where a lost, stolen or misappropriated instrument was used, and fraud or gross negligence on the customer's part removes the protection altogether.", "citation": "Directive (EU) 2015/2366, Articles 71(1) and 74(1)", "rests_on": "law" }, { "label": "The second refund right, from the 2024 amendment", "value": "Verification of payee changed the balance, and it matters more here because the money is gone in seconds. A PSP that ran the check properly is not on the hook when a wrong IBAN sends money to the wrong person. A payer's PSP that did not run it, and thereby caused a defective payment, has to refund the payer without delay and restore the account.", "citation": "Regulation (EU) No 260/2012 as amended by Regulation (EU) 2024/886, Article 5c(8)", "rests_on": "law" }, { "label": "Who pays whom when the fault was elsewhere", "value": "Where the failure to run the check was the payee's PSP's, or a payment initiation service provider's, that party has to make the payer's PSP whole for what the failure cost it. Anything more the payer lost is left to the contract between the payer and its own PSP.", "citation": "Regulation (EU) No 260/2012 as amended by Regulation (EU) 2024/886, Article 5c(8) third and fourth subparagraphs", "rests_on": "law" }, { "label": "The refund that is really a liability claim", "value": "Where a payment the customer did authorise was not executed, executed badly or executed late, the payer's PSP owes it the money back without undue delay unless it can show the receiving PSP got the funds on time, in which case the duty shifts across. Either way the customer can demand an immediate trace, free of charge.", "citation": "Directive (EU) 2015/2366, Article 89(1)", "rests_on": "law" }, { "label": "What the scheme offers instead of a refund", "value": "Two things, neither a right for the customer. A Recall, for the sending bank's own duplicates, technical faults and fraud. A Request for Recall by the Originator for everything else, which is the customer's regret route and depends entirely on the beneficiary agreeing. With no Return in this scheme there is no third option.", "citation": "EPC004-16 SCT Inst Rulebook 2025 v1.1, sections 4.3.2.2, 4.3.2.3 and 4.3.2.4", "rests_on": "rule" }, { "label": "Nothing may be charged for the safeguards", "value": "The verification of payee service is free to every customer, and the notification a sending PSP owes its customer about whether the money arrived is free too.", "citation": "Regulation (EU) No 260/2012 as amended by Regulation (EU) 2024/886, Articles 5b(2) and 5a(4)(e)", "rests_on": "law" } ], "exceptions": [ "A payment to the wrong account because the customer gave the wrong IBAN is not a refund case. Law treats it as correctly executed towards whoever owns that account, and the customer's PSP owes only a real attempt at recovery (Directive (EU) 2015/2366, Article 88(1) to (3)).", "A customer that ignored a verification of payee warning may find its position weaker. PSPs have to explain beforehand what ignoring such a notification does to PSP liability and to the customer's own refund rights (Regulation (EU) No 260/2012 as amended, Article 5c(7)).", "Business customers may opt out of verification of payee when sending payments in bulk, and may opt back in at any time. A PSP has to spell out the liability consequences when they opt out (Regulation (EU) No 260/2012 as amended, Article 5c(6) and (7)).", "A payment initiation service provider in the chain does not change the customer's position for an unauthorised payment. The account servicing PSP still refunds immediately and recovers from that provider where it was at fault (Directive (EU) 2015/2366, Article 73(2)).", "Outside the EEA neither the Directive nor the amended Regulation applies directly; Participants there take on equivalent obligations through the rulebook (EPC004-16 2025 v1.1, section 5.14).", "Non-consumer customers can be treated differently. Several of these provisions may be varied by agreement where the customer is not a consumer. [Unverified: Article 61 of Directive (EU) 2015/2366, which sets that out, was not read for this record.]" ], "applies_to": "a payer whose SEPA Instant Credit Transfer was unauthorised, badly executed or sent to the wrong payee, and a payer who simply wants a completed instant transfer back", "caveat": "Speed makes the refund question harder, not easier. On a rail where money is spendable in five seconds, an unauthorised payment refunded by the end of the next business day is still a real loss of use, and an authorised payment the customer regrets has no refund at all. Verification of payee is the main protection the law added, and it works before the payment, not after it.", "related": [ "sepa-sct-inst:finality", "sepa-sct-inst:recall", "sepa-sct-inst:return", "sepa-sct-inst:liability", "sepa-sct-inst:consumer-law", "sepa-sct-inst:decision-points" ], "basis": { "sources": "EPC004-16 SEPA Instant Credit Transfer Scheme Rulebook 2025 version 1.1 (effective 2025-10-05, marked Public), read for this record: sections 4.2.3 D with CT-01.11R, 4.3.2 (exception processing as a whole), 4.3.2.2, 4.3.2.3, 4.3.2.4, 4.4 and 5.14. Directive (EU) 2015/2366 consolidated 2024-04-08, Articles 71(1), 73, 74(1), 76(1), 77(1), 88 and 89(1), and Regulation (EU) No 260/2012 as amended by Regulation (EU) 2024/886, Articles 5a(4)(e), 5a(5), 5b(2), 5c(6), 5c(7) and 5c(8), both read on EUR-Lex for this record.", "confidence": "high" }, "currency": { "effective_since": "2025-10-05", "effective_note": "The 2025 SCT Inst rulebook was issued and took effect on 2025-10-05 and has never contained a refund process. The verification of payee duties and the charges rule came from Regulation (EU) 2024/886: the charges rule binds euro area PSPs from 2025-01-09 and PSPs elsewhere from 2027-01-09, and verification of payee binds euro area PSPs from 2025-10-09 and PSPs elsewhere from 2027-07-09. The Directive's refund provisions date from the 2015 Directive as transposed nationally; national transposition was not checked for this record.", "source_edition": "EPC004-16 SCT Inst Scheme Rulebook 2025 version 1.1 (2025-10-05); Directive (EU) 2015/2366 consolidated 2024-04-08; Regulation (EU) No 260/2012 as amended by Regulation (EU) 2024/886", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "rail_name": "SEPA Instant Credit Transfer", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": null, "effective_status": "draft", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sct-inst:return", "id": "return", "rail": "sepa-sct-inst", "kind": "rail-fact", "facet": "return", "name": "Is there a return, and what can stop a payment before it settles?", "statement": "There is no Return in this scheme. A Reject is the only thing that stops a payment, and it lands in the same seconds as the payment itself. A transaction the receiving PSP cannot post is rejected outright rather than credited and unwound later, and a transaction nobody answers for is rejected on a time-out by the receiving PSP's own CSM. Once the money is with the beneficiary, no message exists for the receiving PSP to send it back on its own, and a beneficiary who wants to return money has to make a fresh payment.", "details": [ { "label": "The exception set", "value": "Three exception types and no more: Reject, Recall, Request for Recall by the Originator. The reason code guidance lists the same three. No Return message exists and no Return window exists.", "citation": "EPC004-16 SCT Inst Rulebook 2025 v1.1 (effective 2025-10-05), sections 4.3.2, 4.3.2.1, 4.3.2.2 and 4.3.2.3; EPC059-18 v7.0 (2025-10-05), section 1", "rests_on": "rule" }, { "label": "What a Reject is here", "value": "Anything that makes the transaction unprocessable under the scheme. It has to be instant, goes back on the DS-03 confirmation message along the path the payment took, carries the original data untouched plus enough of it for an audit trail, quotes the sending PSP's own reference, names a reason in AT-R004, and lands inside the maximum execution time.", "citation": "EPC004-16 SCT Inst Rulebook 2025 v1.1, section 4.3.2.1", "rests_on": "rule" }, { "label": "A reject is a negative confirmation, not a separate message", "value": "Reject and confirmation are one message type here. The receiving PSP owes an answer inside the maximum execution time either way: the money is with the customer, or the transaction is rejected.", "citation": "EPC004-16 SCT Inst Rulebook 2025 v1.1, section 4.5.3 (DS-03) and section 5.8 point 14", "rests_on": "rule" }, { "label": "Who may reject, and when", "value": "Four places. The sending PSP turns the instruction away at CT-01.02R and tells its customer at once. A party in the inter-PSP space turns the transaction away at CT-01.05R. The receiving PSP turns it away at CT-01.06R after its checks. The receiving PSP's CSM turns it away at CT-01.08R when the time-out passed with no answer. In all four the sending PSP releases the amount it was holding and tells its customer.", "citation": "EPC004-16 SCT Inst Rulebook 2025 v1.1, section 4.3.2.1, process steps CT-01.02R, CT-01.05R, CT-01.06R and CT-01.08R", "rests_on": "rule" }, { "label": "The time-out reject", "value": "Whoever gets the transaction too late, or cannot hand it on in time, rejects it there and then with the time-out reason. A receiving PSP that knows its answer will not reach its CSM inside 7 seconds must hold the money back and send a negative confirmation instead. Where nothing reached that CSM by 7 seconds, the CSM itself rejects and tells both sides.", "citation": "EPC004-16 SCT Inst Rulebook 2025 v1.1, section 4.2.3 C", "rests_on": "rule" }, { "label": "Who may not reject", "value": "The sending PSP and its own CSM. Past the time-out they still have to wait for an answer from the receiving side, and the cover towards the receiving PSP stays up until one arrives.", "citation": "EPC004-16 SCT Inst Rulebook 2025 v1.1, section 4.2.3 C", "rests_on": "rule" }, { "label": "Which ISO code goes with which reject", "value": "The guidance turns each reason into an ISO 20022 code. It names AC01 for a bad or non-existent account identifier, AC04 closed, AC06 blocked, AG01 an account type that cannot take the payment, AG09 where the transaction never arrived, AG10 and AG11 where an agent in the chain or the receiving PSP itself is suspended, AM05 duplicate, AM23 beyond the settlement limit, RC01 a bad PSP identifier, and MS03 where national law blocks a precise answer.", "citation": "EPC059-18 v7.0 (2025-10-05), section 3", "rests_on": "guidance" }, { "label": "One reject reason was deleted", "value": "The reason for breaching a scheme maximum came out of AT-R004 in this edition, from both the CSM list and the receiving PSP list, because no scheme maximum survives to breach.", "citation": "EPC004-16 SCT Inst Rulebook 2025 v1.1, Annex IV entry for section 4.6 on AT-R004", "rests_on": "rule" }, { "label": "What a beneficiary does instead of a Return", "value": "The rulebook says outright that it provides nothing for a beneficiary who wants to hand the money back, and points that customer at its own PSP: another EPC SEPA scheme, or a new SCT Inst, as the two of them arrange.", "citation": "EPC004-16 SCT Inst Rulebook 2025 v1.1, section 4.3.2.4", "rests_on": "rule" }, { "label": "What to do when nothing came back at all", "value": "Past the time-out the sending PSP may open an optional status investigation. Everyone downstream owes an instant response, anyone already holding a confirmation has to send it again, and a party that never saw the original transaction says so, at which point the sending PSP rejects and tells its customer.", "citation": "EPC004-16 SCT Inst Rulebook 2025 v1.1, section 4.4, process steps CT-03.01 to CT-03.06", "rests_on": "rule" } ], "exceptions": [ "A negative confirmation arriving past the tenth second still rejects the transaction, but by then the sending PSP has already released the amount it was holding, so all that is left to do is tell the customer (EPC004-16 2025 v1.1, CT-01.12R).", "A positive confirmation arriving past the tenth second means the payment worked, late. The sending PSP informs its customer, and whatever it does about the situation beyond that is outside the scheme (EPC004-16 2025 v1.1, CT-01.13R and section 4.2.3 D).", "The investigation procedure has no completion deadline and no cap on repetitions (EPC004-16 2025 v1.1, section 4.4).", "MS03 is for the case where national law blocks a precise answer. Participants are told not to fall back on general codes where a specific one is available and lawful (EPC059-18 v7.0, sections 2 and 3).", "With no Return, an SCT Inst paid to the wrong person cannot be pulled back by the receiving bank acting alone. Every path from there is a Recall or a Request for Recall, and both can be refused (EPC004-16 2025 v1.1, sections 4.3.2.2 and 4.3.2.3)." ], "applies_to": "SEPA Instant Credit Transfers stopped by a Reject or a negative confirmation at any point in the chain, and the absence of any post-payment Return in the scheme", "caveat": "Do not translate ACH or SEPA Credit Transfer (SCT) habits here. There is no window in which a receiving bank can decide, later, to send the money back. The scheme resolves everything in the same seconds: either the beneficiary PSP confirms and the beneficiary has the money, or it rejects and nobody does. What looks like a return on this rail is either a Recall, which the other side may refuse, or a brand new payment.", "related": [ "sepa-sct-inst:finality", "sepa-sct-inst:recall", "sepa-sct-inst:refund", "sepa-sct-inst:messages", "sepa-sct-inst:liability", "sepa-sct-inst:decision-points" ], "basis": { "sources": "EPC004-16 SEPA Instant Credit Transfer Scheme Rulebook 2025 version 1.1 (effective 2025-10-05, marked Public), read for this record: sections 4.2.3 C and D, 4.3.2 and 4.3.2.1 (Reject, with CT-01.02R, CT-01.05R, CT-01.06R, CT-01.08R, CT-01.11R to CT-01.13R), 4.3.2.2 and 4.3.2.3 (Recall and RFRO, for the contrast), 4.3.2.4 (beneficiary wishing to transfer back the funds), 4.4 (status investigation, CT-03.01 to CT-03.06), 4.5.3 (DS-03), 4.6.1 (AT-R004), 5.8 point 14, and Annex IV entry for AT-R004. EPC059-18 v7.0 (2025-10-05), Guidance on reason codes for SCT Inst R-transactions, sections 1, 2 and 3.", "confidence": "high" }, "currency": { "effective_since": "2025-10-05", "effective_note": "The 2025 SCT Inst rulebook was issued and took effect on 2025-10-05, and EPC059-18 v7.0 carries the same date. This edition added the process steps CT-01.11R to CT-01.13R for what happens after 10 seconds, and removed the maximum amount reject reason, both following the amended SEPA Regulation (Annex IV). The absence of a Return predates this edition; the date it was first the case is [Unverified] because earlier editions were not read.", "source_edition": "EPC004-16 SCT Inst Scheme Rulebook 2025 version 1.1 (2025-10-05); EPC059-18 v7.0 (2025-10-05)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-10/EPC004-16%202025%20SCT%20Instant%20Rulebook%20v1.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC004-16 SCT Inst Scheme Rulebook 2025 version 1.1; EPC059-18 v7.0 Guidance on Reason Codes for SCT Inst R-transactions", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the exception set is limited to Reject, Recall and Request for Recall by the Originator with no Return message and no Return window (4.3.2, 4.3.2.1-4.3.2.3), the Reject-as-negative-confirmation mechanics and the four reject points CT-01.02R/CT-01.05R/CT-01.06R/CT-01.08R (4.3.2.1), the time-out and belated-confirmation handling at CT-01.11R to CT-01.13R (4.2.3, 4.3.2.1), and section 4.3.2.4 titled 'Beneficiary wishing to transfer back the Funds,' which states verbatim that the rulebook foresees no exception processing for that case and points the beneficiary at its own PSP for another EPC scheme or a fresh SCT Inst. Confirms the optional status investigation procedure with no completion deadline (4.4, CT-03.01 onward). This directly supports the special-attention question of whether SCT Inst has any post-settlement return: it does not; Recall and RFRO are the only paths back, and neither is a return." } ] }, "rail_name": "SEPA Instant Credit Transfer", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sct-inst:settlement", "id": "settlement", "rail": "sepa-sct-inst", "kind": "rail-fact", "facet": "settlement", "name": "How does settlement work, when does it happen, and in what money?", "statement": "SCT Inst turns the usual order around. No beneficiary PSP will hand a customer money it might not get, so the cover is arranged first: passing the transaction to its CSM is the originator PSP's authority for that CSM to hold funds against it. From then on the receiving side is covered whatever happens next. The settling itself is still the CSM's job, and the scheme neither names the CSM nor times it. Everything is denominated in euro.", "details": [ { "label": "Cover first, payment second", "value": "Three principles carry the model. By the time the beneficiary PSP sees the transaction it is already covered, arranged through the sending side's CSM. Handing the transaction over is itself the authority to hold that cover, and the CSM does it at once. That is what the rulebook means by upfront settlement certainty.", "citation": "EPC004-16 SCT Inst Rulebook 2025 v1.1 (effective 2025-10-05), section 4.3, principles 1 and 2", "rests_on": "rule" }, { "label": "When the originator PSP actually owes the money", "value": "Not on sending, but on hearing a positive confirmation. Until some confirmation arrives the cover towards the beneficiary PSP has to stay up, and the transaction may not be written off as failed.", "citation": "EPC004-16 SCT Inst Rulebook 2025 v1.1, section 4.3 principle 3 and section 4.2.3 D", "rests_on": "rule" }, { "label": "Settlement certainty is an obligation of participation", "value": "A PSP cannot join on the sending side without a CSM contract, direct or indirect, good enough to carry its settlement duties, and it owes that certainty on every single transaction. The receiving side carries the same contracting duty.", "citation": "EPC004-16 SCT Inst Rulebook 2025 v1.1, section 5.7 points 7 and 9, and section 5.8 point 7", "rests_on": "rule" }, { "label": "What settlement means, and the date on the message", "value": "The glossary treats settlement as the point where the debt between the two PSPs is cleared. AT-T051 carries the date on the message: what the sender asked for on the way out, what was actually applied on the way in.", "citation": "EPC004-16 SCT Inst Rulebook 2025 v1.1, chapter 7 Defined Terms entry Settlement, and section 4.6.1 attribute AT-T051", "rests_on": "rule" }, { "label": "The clock on the message is not a settlement clock", "value": "AT-T056 is stamped by the originator PSP, equals the Time of Receipt, and starts the execution time. Its precision runs to milliseconds or finer. It measures how fast the payment ran, not when the two PSPs squared up.", "citation": "EPC004-16 SCT Inst Rulebook 2025 v1.1, sections 4.2.3 A and 4.6.1 attribute AT-T056", "rests_on": "rule" }, { "label": "The scheme names no CSM and no settlement model", "value": "The rulebook's account of what CSMs do is marked as information only. A CSM need not be one company, since clearing and settling can sit with different actors, and what a Participant agrees with it falls outside the scheme.", "citation": "EPC004-16 SCT Inst Rulebook 2025 v1.1, sections 3.1 and 3.3, and section 3.2 relationship 5", "rests_on": "rule" }, { "label": "Which days count, and where", "value": "In the payment flow, none: no cut-off and no business day, because the service runs every hour of every calendar day. Banking Business Days, pinned to T2 days, show up only once the Recall and Request for Recall procedures start.", "citation": "EPC004-16 SCT Inst Rulebook 2025 v1.1, section 4.2.2 and chapter 7 Defined Terms entry Banking Business Day", "rests_on": "rule" }, { "label": "The money", "value": "Euro throughout, payments and exception messages alike. The two accounts can be denominated in anything; if a conversion is needed, one of the two PSPs does it outside the scheme's rules. Where the payer's account is not in euro, law puts the time of receipt at the moment the conversion is done.", "citation": "EPC004-16 SCT Inst Rulebook 2025 v1.1, sections 2.4 and 4.2.1; Regulation (EU) No 260/2012 as amended by Regulation (EU) 2024/886, Article 5a(3)(c)", "rests_on": "law" }, { "label": "The full amount travels, and charges are shared", "value": "Each side pays its own bank, and nobody takes a slice out of the transfer on the way. On top of that, since the 2024 amendment a PSP may not price an instant credit transfer above what it charges the same customer for the comparable non-instant one.", "citation": "EPC004-16 SCT Inst Rulebook 2025 v1.1, section 4.2.4; Directive (EU) 2015/2366, Article 81(1); Regulation (EU) No 260/2012 as amended by Regulation (EU) 2024/886, Article 5b(1)", "rests_on": "law" }, { "label": "Value dating at the receiving end", "value": "Same day, not the next one: the value date on the payee's account has to be the day the money is posted to it. That is tighter than the general credit transfer rule and came in with the 2024 amendment.", "citation": "Regulation (EU) No 260/2012 as amended by Regulation (EU) 2024/886, Article 5a(4)(d)", "rests_on": "law" } ], "exceptions": [ "Cover can run out. Code AM23 comes back when the sending side does not have enough prefunded guarantee at its CSM to carry the transaction. That is a CSM condition, and the EPC publishes none of the numbers behind it (EPC059-18 v7.0, section 3).", "Participants, and groups of them, may hold settlement and value limits against each other through their CSMs, so long as the law allows it (EPC004-16 2025 v1.1, section 2.5).", "An agent temporarily suspended from the system produces a rejection: AG10 for any agent in the chain, AG11 where it is the beneficiary PSP itself (EPC059-18 v7.0, section 3).", "A positive confirmation arriving past the tenth second still means the payment worked, by which time the originator PSP has already released the amount it was holding. The rulebook treats that as a financial risk to the sending side and caps any claim at the transaction amount (EPC004-16 2025 v1.1, sections 4.2.3 D and 5.9.2 point 1).", "Where one Participant is on both ends there is no inter-PSP settlement to do (EPC004-16 2025 v1.1, section 3.1).", "Which CSMs reach each other, and whether the final leg lands in central bank money, is outside the rulebook. [Unverified: no CSM or Eurosystem documentation was read for this record.]" ], "applies_to": "the inter-PSP leg of a SEPA Instant Credit Transfer, between the originator PSP and the beneficiary PSP, through whichever CSMs those Participants use", "caveat": "Settlement certainty and settlement are not the same event. The beneficiary PSP pays its customer against certainty, arranged in advance by reservation at the originator PSP's CSM, not against money that has already moved. An agent reasoning about counterparty risk on this rail should look at the CSM's prefunding arrangement, which the EPC does not publish.", "related": [ "sepa-sct-inst:finality", "sepa-sct-inst:hours", "sepa-sct-inst:limits", "sepa-sct-inst:return", "sepa-sct-inst:messages", "sepa-sct-inst:participants" ], "basis": { "sources": "EPC004-16 SEPA Instant Credit Transfer Scheme Rulebook 2025 version 1.1 (effective 2025-10-05, marked Public), read for this record: sections 2.4, 2.5, 3.1, 3.2, 3.3, 4.2.1, 4.2.2, 4.2.3 A and D, 4.2.4, 4.3 principles 1 to 3, 4.6.1 (AT-T051, AT-T056), 5.7 points 7 and 9, 5.8 point 7, 5.9.2 point 1, chapter 7 (Settlement, Banking Business Day, Reservation of the Amount). EPC059-18 v7.0 (2025-10-05), section 3, for AM23, AG10 and AG11. Regulation (EU) No 260/2012 as amended by Regulation (EU) 2024/886, Articles 5a(3), 5a(4)(d) and 5b(1), and Directive (EU) 2015/2366 consolidated 2024-04-08, Article 81, read on EUR-Lex.", "confidence": "high" }, "currency": { "effective_since": "2025-10-05", "effective_note": "The 2025 SCT Inst rulebook was issued and took effect on 2025-10-05. Annex IV to that edition records that the Time Stamp must now include milliseconds, and that the Banking Business Day definition changed TARGET2 into T2. The upfront settlement certainty model is older than this edition; the date it first took effect is [Unverified] because earlier editions were not read.", "source_edition": "EPC004-16 SCT Inst Scheme Rulebook 2025 version 1.1 (2025-10-05); EPC059-18 v7.0 (2025-10-05); Regulation (EU) No 260/2012 as amended by Regulation (EU) 2024/886; Directive (EU) 2015/2366 consolidated 2024-04-08", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-10/EPC004-16%202025%20SCT%20Instant%20Rulebook%20v1.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC004-16 SCT Inst Scheme Rulebook 2025 version 1.1; EPC059-18 v7.0 Guidance on Reason Codes for SCT Inst R-transactions", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the three settlement-certainty principles and cover-before-payment model (4.3), that the originator PSP's payment duty bites only on positive confirmation (4.3 principle 3, 4.2.3 D), the originator PSP's settlement-certainty contracting duty in obligation 7 and 9 (5.7) and the parallel beneficiary PSP duty (5.8 point 7), the Settlement glossary entry and AT-T051/AT-T056 attributes including that AT-T056 is a time-of-receipt stamp and not a settlement date (chapter 7, 4.6.1), the scheme naming no CSM or settlement model (3.1, 3.3), no business day or cut-off in the payment flow versus banking business days on Recall/RFRO (4.2.2, chapter 7), and the AM23, AG10 and AG11 reason codes against EPC059-18 v7.0 section 3. Does not independently confirm Regulation 260/2012 Article 5a(3)(c), 5a(4)(d) or 5b(1) as amended by 2024/886, or Directive 2015/2366 Article 81(1); EUR-Lex remains unreachable." } ] }, "rail_name": "SEPA Instant Credit Transfer", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sdd-b2b:consumer-law", "id": "consumer-law", "rail": "sepa-sdd-b2b", "kind": "rail-fact", "facet": "consumer-law", "name": "What consumer protection attaches to a B2B direct debit, and where does it come from?", "statement": "None, by construction, and consumer law is still the reason the scheme looks the way it does. A consumer cannot be a B2B debtor at all, and a business can only be one where its national law lets it give up the statutory refund right. That single permission is what the whole scheme is built on: no refund, therefore mandate verification before every debit, therefore a three day return window instead of eight weeks. Consumer law then reappears at the edges. Some Member States treat microenterprises as consumers, which puts those businesses outside the scheme. A consumer account debited by mistake keeps its statutory rights while the scheme gives the Debtor PSP nothing. And the reachability duty that makes SEPA Direct Debit Core work across borders is written for consumer-available direct debits, so it does not reach this scheme.", "details": [ { "label": "Consumers are excluded", "value": "A Debtor PSP may not sell this scheme to anyone who counts as a consumer where it provides the service. The customer also has to be a business that national law lets give up its statutory refund right for authorised transactions.", "citation": "SDD B2B Scheme Rulebook EPC222-07, 2025 version 1.1, section 2.2", "rests_on": "rule" }, { "label": "The permission the scheme depends on", "value": "Union law lets a non-consumer user and its PSP agree that several articles do not apply, in whole or in part, Article 76 among them, and lets them set time limits other than Article 71's. Article 76 is the refund right and Article 77 its eight week window.", "citation": "Directive (EU) 2015/2366, Article 61(1), with Article 76(1) and 77(1)", "rests_on": "law" }, { "label": "Checking that permission is the Debtor PSP's job", "value": "Before contracting, the Debtor PSP has to establish two things: that this customer is not a consumer, and that its national law permits the opt-out. The rulebook warns that some national laws group microenterprises with consumers.", "citation": "SDD B2B Scheme Rulebook EPC222-07, 2025 version 1.1, section 5.8 item 4", "rests_on": "rule" }, { "label": "Member States decide the microenterprise question", "value": "Union law lets Member States extend the payment services protections to microenterprises on the same footing as consumers, so whether a small business can be a B2B debtor turns on where it is.", "citation": "Directive (EU) 2015/2366, Article 61(3)", "rests_on": "law" }, { "label": "A consumer account debited in error", "value": "Establishing that the customer is a business, before the debit, falls on the Debtor PSP. If it gets that wrong it has no refund right under the scheme, while its customer keeps whatever the Payment Services Directive gives it. The dedicated code for the situation is AC13.", "citation": "SDD B2B Scheme Rulebook EPC222-07, 2025 version 1.1, section 2.7, with EPC Guidance on Reason Codes for SDD R-transactions EPC173-14 version 8.0, section 3", "rests_on": "rule" }, { "label": "No statutory reachability for this scheme", "value": "The reachability obligation on a payer's PSP covers only direct debits that a scheme makes available to consumers as payers. Excluding consumers puts this scheme outside it, and the rulebook says the same thing in its own way by declining to treat universal reach as a premise.", "citation": "Regulation (EU) No 260/2012 Article 3(2) and 3(3), with SDD B2B Scheme Rulebook EPC222-07, 2025 version 1.1, section 2.6", "rests_on": "law" }, { "label": "The account controls need not be offered", "value": "The statutory menu of amount and periodicity caps, blocks and creditor whitelists does not have to be provided where neither payer nor payee is a consumer, which on this scheme is always. The rulebook still requires the Debtor PSP to let a debtor bar B2B direct debits from its account.", "citation": "Regulation (EU) No 260/2012 Article 5(3)(d) and the closing subparagraph of Article 5(3), with SDD B2B Scheme Rulebook EPC222-07, 2025 version 1.1, section 4.2", "rests_on": "law" }, { "label": "But giving up the refund buys a verification duty", "value": "Union law turns the missing refund into a duty. Where the framework agreement leaves the payer no refund right, the payer's PSP has to test each direct debit against the mandate-related information, on amount and on periodicity, before it debits. That duty sits behind the scheme's own checking rules.", "citation": "Regulation (EU) No 260/2012 Article 5(6), with Article 5(3)(d)(ii)", "rests_on": "law" }, { "label": "What the debtor is still told", "value": "Before the first collection the Debtor PSP has to put the respective rights and obligations of debtor, creditor and Debtor PSP in front of the debtor, and cover the secure use of direct debits, with the detail in the risk management annex. The creditor still owes a pre-notification fourteen calendar days ahead unless the two of them agreed otherwise.", "citation": "SDD B2B Scheme Rulebook EPC222-07, 2025 version 1.1, section 5.8 item 12 and section 4.3.4", "rests_on": "rule" }, { "label": "Mandate information on request", "value": "The Debtor PSP has to pass on, without undue delay, the mandate information it gets from the Creditor PSP, and to provide the debtor with a copy of the mandate.", "citation": "SDD B2B Scheme Rulebook EPC222-07, 2025 version 1.1, section 5.8 item 9", "rests_on": "rule" }, { "label": "Charges", "value": "Each side pays its own PSP, as a scheme principle and under Union law, and a payee may not surcharge for payment services covered by Regulation (EU) No 260/2012.", "citation": "SDD B2B Scheme Rulebook EPC222-07, 2025 version 1.1, section 4.3.5, with Directive (EU) 2015/2366 Article 62(2) and 62(4)", "rests_on": "law" } ], "exceptions": [ "Everything here binds as nationally transposed. Whether a business may opt out of the refund right, and whether microenterprises count as consumers, differ by Member State; none was read for this record.", "Countries in the scheme's geography that are outside the EEA are not bound by the Directive or the SEPA Regulation at all; section 5.15 substitutes a contractual promise of substantially equivalent performance.", "A disapplication under Article 61(1) is an agreement, so what a given B2B debtor retains depends on its contract with its PSP as well as on national law.", "Annex III of the rulebook, which carries the detail of the information duties on secure use, was referenced but not read for this record.", "Regulation (EU) 2024/886 added instant payment obligations including verification of payee; those attach to credit transfers and give a direct debit debtor nothing.", "The debtor's rights against the creditor under their own contract are untouched by any of this and sit outside the scheme (section 4.2)." ], "applies_to": "business debtors debited under the SEPA Direct Debit B2B scheme, and the PSPs that must establish they are not consumers", "caveat": "Do not read \"no consumer protection\" as \"no protection\". A B2B debtor keeps its claim against its own PSP for an unauthorised collection, and its PSP keeps the exposure. What the scheme removes is the easy, no-questions route back, not the law.", "related": [ "sepa-sdd-b2b:refund", "sepa-sdd-b2b:limits", "sepa-sdd-b2b:liability", "sepa-sdd-b2b:participants", "sepa-sdd-b2b:finality" ], "basis": { "sources": "SEPA Direct Debit B2B Scheme Rulebook EPC222-07, 2025 version 1.1, date issued 05 October 2025 (marked Public), read for this record: sections 2.2 (access and the opt-out condition), 2.6 (reachability is not assumed), 2.7 (consumer accounts debited in error), 4.2 (blocking and disputes), 4.3.4 (pre-notification), 4.3.5 (charging principles), 5.8 items 4, 9 and 12, 5.15 (application of EU legislation). Directive (EU) 2015/2366, consolidated text of 08 April 2024 on EUR-Lex: Articles 61(1) and (3), 62(2) and (4), 76(1), 77(1). Regulation (EU) No 260/2012, consolidated text of 08 April 2024: Articles 3(2) and (3), 5(3) and 5(6). EPC Guidance on Reason Codes for SDD R-transactions EPC173-14 version 8.0, section 3. Annex III of the rulebook and all national transpositions were not read.", "confidence": "high" }, "currency": { "effective_since": "Long-standing", "effective_note": "Directive (EU) 2015/2366 applied from 13 January 2018 and the SEPA Regulation from 2012, as amended in 2014 and by Regulation (EU) 2024/886. The rulebook provisions cited are in the 2025 version 1.1 edition, effective 05 October 2025. National transpositions carry their own dates and were not checked [Unverified]. The status of the successor payment services package as of September 2026 is [Unverified].", "source_edition": "SDD B2B Scheme Rulebook EPC222-07, 2025 version 1.1, date issued 05 October 2025; Directive (EU) 2015/2366 consolidated to 08 April 2024; Regulation (EU) No 260/2012 consolidated to 08 April 2024", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "rail_name": "SEPA Direct Debit B2B", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": null, "effective_status": "draft", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sdd-b2b:decision-points", "id": "decision-points", "rail": "sepa-sdd-b2b", "kind": "rail-fact", "facet": "decision-points", "name": "Where do the B2B rules stop deciding and hand the outcome to a bank or a person?", "statement": "In two places that SEPA Direct Debit Core does not have, and in most of the places Core does. The first is at the door: before it takes on a B2B debtor at all, the Debtor PSP has to judge that the customer is not a consumer and that national law lets it give up its refund right, which is a legal call with no scheme test behind it. The second is the mandate check, where the scheme sets the attributes to compare but leaves the response to a mismatch to whatever standing instructions the debtor gave. After settlement the discretion moves to the creditor's side: the Creditor PSP must answer an inquiry and decides for itself whether to pay. This is Orca's reading of where the text leaves judgment open, so it caps at medium confidence.", "details": [ { "label": "Whether this customer may be a B2B debtor at all", "value": "The Debtor PSP has to satisfy itself that the customer is not a consumer under local law and is permitted by national law to opt out of the statutory refund right, knowing that some national laws treat microenterprises as consumers. The scheme sets the requirement and gives no test for meeting it.", "citation": "SDD B2B Scheme Rulebook EPC222-07, 2025 version 1.1, sections 2.2 and 5.8 item 4", "rests_on": "rule" }, { "label": "Which checks get agreed, and therefore which collections stop", "value": "The rulebook requires the checks on each collection to be settled explicitly between the Debtor PSP and its debtor. The scheme fixes a minimum list of mandate attributes and lets the two of them add more, so the effective control on an account comes out of a private agreement.", "citation": "SDD B2B Scheme Rulebook EPC222-07, 2025 version 1.1, section 4.6.4 PT-04.09, with section 5.8 item 1", "rests_on": "rule" }, { "label": "What happens on a mismatch", "value": "Where the mandate data and the collection do not correspond, the Debtor PSP acts on the instructions its debtor left. The scheme does not say the collection must be rejected; it says the debtor decides in advance and the PSP follows.", "citation": "SDD B2B Scheme Rulebook EPC222-07, 2025 version 1.1, sections 4.2 and 4.6.4 PT-04.09", "rests_on": "rule" }, { "label": "A reject on suspicion", "value": "This rulebook lets the Debtor PSP Reject where it reasonably believes the collection is erroneous, a ground the Core rulebook does not phrase in those terms. What counts as reasonable belief is left open.", "citation": "SDD B2B Scheme Rulebook EPC222-07, 2025 version 1.1, section 4.4", "rests_on": "rule" }, { "label": "Whether to debit late instead of returning", "value": "Where it cannot debit on the Due Date, for want of funds or because agreed checks are still running, the Debtor PSP may debit later while keeping the D+3 return deadline in view. Waiting or giving up is its call, and the window is short.", "citation": "SDD B2B Scheme Rulebook EPC222-07, 2025 version 1.1, section 4.3.2", "rests_on": "rule" }, { "label": "Whether to open an inquiry", "value": "Faced with a debtor's claim after the return window has closed, the Debtor PSP is free to start the inquiry procedure or not. Nothing compels it, and it has no other route.", "citation": "SDD B2B Scheme Rulebook EPC222-07, 2025 version 1.1, Annex VI, section 1", "rests_on": "rule" }, { "label": "Whether to pay it", "value": "The Creditor PSP must reply, and chooses between accepting that reimbursement is justified and supplying proof that the collection was executed correctly. It may consult its creditor first. The annex states that no settlement is guaranteed.", "citation": "SDD B2B Scheme Rulebook EPC222-07, 2025 version 1.1, Annex VI, introduction and step 3", "rests_on": "rule" }, { "label": "How a conceded inquiry is settled", "value": "There is no prescribed mechanism. The two PSPs agree bilaterally, and the annex offers a Reversal, a Return, a funds transfer or anything else that works.", "citation": "SDD B2B Scheme Rulebook EPC222-07, 2025 version 1.1, Annex VI, step 3", "rests_on": "rule" }, { "label": "Whether to escalate", "value": "The Debtor PSP may take the matter to the scheme's dispute body where no reply arrives within 20 Banking Business Days of the request, or where the reply does not satisfy it and bilateral discussion has not worked. Whether to escalate, and when, is its judgment.", "citation": "SDD B2B Scheme Rulebook EPC222-07, 2025 version 1.1, Annex VI, step 5", "rests_on": "rule" }, { "label": "Whether a collection is a duplicate", "value": "The annex acknowledges that no exhaustive definition is possible and offers presumptions rather than a test: same amount and same Due Date is strongly presumed to be a duplicate, and same amount with close dates may be. The Debtor PSP decides.", "citation": "SDD B2B Scheme Rulebook EPC222-07, 2025 version 1.1, Annex VI, section 2.1", "rests_on": "rule" }, { "label": "How hard to police a creditor", "value": "Creditor PSPs are told to take care to avoid an excessive share of Rejects and Returns against a given creditor, and to investigate a suspected fraudulent creditor immediately once alerted. No threshold and no consequence are stated.", "citation": "SDD B2B Scheme Rulebook EPC222-07, 2025 version 1.1, Annex VI, section 2.2", "rests_on": "rule" }, { "label": "Whether reversals are available to a creditor at all", "value": "A Creditor PSP is not obliged to offer the reversal facility, and on this scheme that decision is sharper than on Core: between D+3 and D+5 a Reversal is the only way money returns to a debtor.", "citation": "SDD B2B Scheme Rulebook EPC222-07, 2025 version 1.1, sections 4.4 and 4.3.4", "rests_on": "rule" }, { "label": "Which reason code to send", "value": "The guidance accepts that one R-transaction can have several reasons, that the depth of checking follows each Debtor PSP's risk and know-your-customer policy, and that where national law blocks the precise code a generic one may be used instead. So the code a creditor sees reflects policy as well as fact.", "citation": "EPC Guidance on Reason Codes for SDD R-transactions EPC173-14 version 8.0, 28 November 2024, sections 2 and 3", "rests_on": "guidance" }, { "label": "Which infrastructure, and what time of day", "value": "Participants pick their CSM commercially, and cut-off times are agreed with it and with their customers, so two participants on the same scheme can have materially different operating deadlines.", "citation": "SDD B2B Scheme Rulebook EPC222-07, 2025 version 1.1, sections 1.4 and 4.3.3", "rests_on": "rule" } ], "exceptions": [ "Handling an incoming Reversal is not a decision point for the Debtor PSP: it is mandatory and no checks are required (section 4.4 and section 4.6.5 PT-05.04).", "Whether to refund the debtor is not a scheme decision at all here, because the scheme has no refund; what the Debtor PSP owes its own customer comes from payment services law and the contract between them.", "Replying to an inquiry is not optional for the Creditor PSP; only the answer is (Annex VI section 1).", "Annex II, the EPC Payment Scheme Management Rules, and Annex III on risk management were not read, so decisions those annexes allocate are missing here. Annex VI still names the Compliance and Adherence Committee as the escalation route, which appears to have been superseded by the Dispute Resolution Committee [Inference from the Core rulebook change history].", "This record is Orca's reading of where the text leaves judgment open, not a list the EPC publishes, and it caps at medium confidence for that reason." ], "applies_to": "points in the SEPA Direct Debit B2B rules where the outcome depends on a participant's judgment rather than on the rule", "caveat": "The costliest judgment on this scheme is made before any payment exists: whether a customer may lawfully be a B2B debtor. Get that wrong and the Debtor PSP has debited an account that keeps its statutory refund rights while holding a scheme that gives it no way to recover.", "related": [ "sepa-sdd-b2b:return", "sepa-sdd-b2b:refund", "sepa-sdd-b2b:recall", "sepa-sdd-b2b:liability", "sepa-sdd-b2b:limits", "sepa-sdd-b2b:hours" ], "basis": { "sources": "SEPA Direct Debit B2B Scheme Rulebook EPC222-07, 2025 version 1.1, date issued 05 October 2025 (marked Public), read for this record: sections 1.4, 2.2, 4.2, 4.3.2, 4.3.3, 4.3.4, 4.4, 4.6.4 PT-04.09 and PT-04.10, 4.6.5 PT-05.04, 5.8 items 1 and 4, Annex VI (introduction, section 1, sections 2.1 and 2.2, steps 2, 3 and 5). EPC Guidance on Reason Codes for SDD R-transactions EPC173-14 version 8.0, 28 November 2024, sections 2 and 3. SDD Core Scheme Rulebook EPC016-06, 2025 version 1.1, section 0.2 change history, for the Dispute Resolution Committee. Annexes II and III of the B2B rulebook were not read. Which provisions count as decision points is Orca's reading, and each line cites the provision that leaves the judgment open.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_note": "The provisions cited are in the 2025 version 1.1 rulebook, effective 05 October 2025, and in EPC173-14 version 8.0 of 28 November 2024. Earlier editions were not read, so first effective dates are [Unverified]. This facet caps at medium confidence by design, because it is a reading of the rules rather than a statement of them.", "source_edition": "SDD B2B Scheme Rulebook EPC222-07, 2025 version 1.1, date issued 05 October 2025; EPC173-14 version 8.0", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-10/EPC222-07%202025%20SDD%20B2B%20Rulebook%20version%201.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC222-07 SDD B2B Scheme Rulebook 2025 version 1.1; EPC173-14 v8.0 Guidance on Reason Codes for SDD R-transactions", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the non-consumer/opt-out gatekeeping duty (2.2, 5.8 item 4), the bilaterally-agreed check list and mismatch-follows-instructions rule already confirmed for the return and limits facts (PT-04.09), the reasonable-belief reject ground (4.4), the debit-late-or-return choice within D+3 (4.3.2), the discretionary inquiry with mandatory Creditor PSP reply but no guaranteed settlement (Annex VI introduction, section 1, step 3), the duplicate-collection presumptions (Annex VI section 2.1), the excessive-share policing instruction (Annex VI section 2.2, confirmed word for word for the limits fact), and the 20 banking business day escalation trigger to the CAC, confirmed by direct inspection at Annex VI step 5. Confirms EPC173-14 v8.0 sections 2 and 3 on multi-reason codes and risk-based checking discretion. No law-rested details in this record." } ] }, "rail_name": "SEPA Direct Debit B2B", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sdd-b2b:finality", "id": "finality", "rail": "sepa-sdd-b2b", "kind": "rail-fact", "facet": "finality", "name": "When does a SEPA Direct Debit B2B collection become final, and can it be reversed?", "statement": "Far sooner than on SEPA Direct Debit Core, and that is the point of the scheme. Settlement happens on the Due Date, the debtor can refuse up to and including that day, and the Debtor PSP can send the collection back with a Return that has to settle within three Inter-PSP Business Days. Past that, nothing in the scheme brings the money back to the debtor except a Reversal, which only the creditor's own side can start. There is no refund of an authorised collection here at all. What does survive is a legal exposure that the scheme deliberately leaves unresolved: for thirteen months the debtor can still go after its own PSP under payment services law for an unauthorised or defectively executed payment, and the scheme gives that PSP no way to pass the loss on.", "details": [ { "label": "What the settlement event is", "value": "As on Core, the money is due, the PSPs settle and the debtor is debited on one day, provided the Due Date is valid, both PSPs can settle, the CSM is open and the Debtor PSP is willing to debit.", "citation": "SDD B2B Scheme Rulebook EPC222-07, 2025 version 1.1, section 4.3.1", "rests_on": "rule" }, { "label": "Refusal reaches further into the day than the law allows", "value": "A debtor can refuse a collection before settlement for any reason, and the B2B scheme expressly stretches that window to cover day D itself, departing from Article 80 of the Payment Services Directive. The Debtor PSP should deal with it before settlement, which makes it a Reject; afterwards it becomes a Return.", "citation": "SDD B2B Scheme Rulebook EPC222-07, 2025 version 1.1, section 4.4 (Refusals), with Directive (EU) 2015/2366 Article 80(3)", "rests_on": "rule" }, { "label": "The short unwind window", "value": "After settlement the Debtor PSP has three Inter-PSP Business Days, counted from the Settlement Date, to get a Return settled. Two days fewer than Core, and the rulebook tells the Debtor PSP to deal with a post-settlement refusal as soon as it can, ideally on day D.", "citation": "SDD B2B Scheme Rulebook EPC222-07, 2025 version 1.1, sections 4.2 and 4.3.4, with section 4.6.4 PT-04.09 and PT-04.10", "rests_on": "rule" }, { "label": "No refund of an authorised collection, full stop", "value": "The scheme states plainly that refunds are not provided for, and that the debtor has no right to obtain one from its PSP for an authorised transaction. That absence is the whole reason the scheme exists and is why the Debtor PSP has to verify mandates up front instead.", "citation": "SDD B2B Scheme Rulebook EPC222-07, 2025 version 1.1, sections 4.2, 4.3.4 and 4.4", "rests_on": "rule" }, { "label": "Only the creditor's side can still put money back", "value": "The Reversal survives, on the same terms as Core: available from the Settlement Date and for five Inter-PSP Business Days after the Due Date, initiated by the creditor or its PSP when they conclude the collection should never have gone out.", "citation": "SDD B2B Scheme Rulebook EPC222-07, 2025 version 1.1, sections 4.3.4 and 4.4", "rests_on": "rule" }, { "label": "The exposure that outlives settlement", "value": "Finality between the banks does not end the Debtor PSP's exposure to its own customer. The rulebook's own inquiry annex says the Debtor PSP can be at risk for thirteen months after the debit date where a debtor disputes a collection and demands reimbursement under Articles 71, 72, 73 and 89 of the Payment Services Directive.", "citation": "SDD B2B Scheme Rulebook EPC222-07, 2025 version 1.1, Annex VI, section 1", "rests_on": "rule" }, { "label": "What the Core rulebook says about the same point", "value": "The comparison annex in the Core rulebook records that a B2B debtor may obtain a refund of an unauthorised collection from its Debtor PSP within thirteen months where its own view is that no B2B mandate covered the collection, and that the Debtor PSP is not allowed to recover that from the Creditor PSP.", "citation": "SDD Core Scheme Rulebook EPC016-06, 2025 version 1.1, Annex V, items 1.2 and 1.3 (marked as included for information and not part of the rulebook)", "rests_on": "rule" }, { "label": "Why unauthorised collections are supposed to be rare", "value": "Because the Debtor PSP has to check mandate data against what the debtor confirmed before every debit, the rulebook expects an unauthorised B2B collection not to happen and the inquiry procedure to be used only in exceptional cases.", "citation": "SDD B2B Scheme Rulebook EPC222-07, 2025 version 1.1, Annex VI, introduction, with section 4.1", "rests_on": "rule" }, { "label": "Finality does not settle the underlying dispute", "value": "Whatever happens to the payment, the argument between debtor and creditor is theirs. The scheme does not reach it.", "citation": "SDD B2B Scheme Rulebook EPC222-07, 2025 version 1.1, section 4.2", "rests_on": "rule" } ], "exceptions": [ "A Due Date on a non-Inter-PSP Business Day moves settlement to the next one, and a Settlement Date that is not a Banking Business Day at the Debtor PSP moves the debit to its next open day (section 4.3.2).", "A Debtor PSP that debits late still has to get any Return settled by D+3 Inter-PSP Business Days (section 4.3.2).", "A Return presented for settlement after the deadline has to be stopped by the Creditor PSP or the CSM, with the Debtor PSP told (section 4.3.4).", "The thirteen month exposure is the debtor's claim against its own PSP under payment services law, not a scheme right to unwind the interbank leg; the scheme offers only a non-binding inquiry procedure to chase the Creditor PSP (Annex VI).", "Errors by the creditor on amount or on Due Date do not make a collection incorrectly executed, because neither is part of the mandate, so such a collection stays authorised and unrefundable under this scheme (Annex VI, section 2.1).", "A Debtor PSP that debits a consumer account in error has no refund right under the scheme, while the debtor keeps its rights against the Debtor PSP under the Payment Services Directive (section 2.7).", "Participants outside the EEA are not bound by the Payment Services Directive; section 5.15 covers that with a contractual promise of substantially equivalent performance." ], "applies_to": "SEPA Direct Debit B2B collections in euro, between a Creditor PSP and a Debtor PSP that each adhere to the B2B scheme, where the debtor is not a consumer", "caveat": "B2B is the scheme where settlement almost means what a creditor wants it to mean: after three Inter-PSP Business Days the money is the creditor's. The risk did not vanish, it moved. It now sits on the Debtor PSP, which has thirteen months of legal exposure to its own customer and no scheme route to pass it back.", "related": [ "sepa-sdd-b2b:settlement", "sepa-sdd-b2b:hours", "sepa-sdd-b2b:return", "sepa-sdd-b2b:recall", "sepa-sdd-b2b:refund", "sepa-sdd-b2b:liability", "sepa-sdd-b2b:consumer-law", "sepa-sdd-b2b:decision-points" ], "basis": { "sources": "SEPA Direct Debit B2B Scheme Rulebook EPC222-07, 2025 version 1.1, date issued 05 October 2025 (marked Public), read for this record: sections 2.7 (erroneous use and consumer accounts), 4.1 (mandate checking obligations), 4.2 (collections, returns, no refund right), 4.3.1 to 4.3.4 (key dates and the time cycle), 4.4 (exception handling definitions), 4.6.4 PT-04.09 to PT-04.11 (checking, debiting and returning), 5.15 (application of EU legislation), Annex VI (inquiry procedure, introduction and sections 1 and 2). SDD Core Scheme Rulebook EPC016-06, 2025 version 1.1, Annex V, items 1.1 to 1.4, 2.1 and 2.3, which the EPC marks as informational. Directive (EU) 2015/2366, consolidated text of 08 April 2024 on EUR-Lex, Articles 71, 73, 80 and 89.", "confidence": "high" }, "currency": { "effective_since": "Long-standing", "effective_note": "The provisions cited are in the 2025 version 1.1 rulebook, effective 05 October 2025. The D+3 return window, the absence of a refund right and the mandate checking duty predate this edition [Inference: EPC173-14 v8.0, published November 2024, covers the 2023 rulebooks and describes the same structure]. Earlier editions were not read, so first effective dates are [Unverified]. The next rulebook version is due for publication in November 2026 and expected to take effect in November 2027.", "source_edition": "SDD B2B Scheme Rulebook EPC222-07, 2025 version 1.1, date issued 05 October 2025; SDD Core Scheme Rulebook EPC016-06, 2025 version 1.1, Annex V; Directive (EU) 2015/2366 consolidated to 08 April 2024", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-10/EPC222-07%202025%20SDD%20B2B%20Rulebook%20version%201.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC222-07 SDD B2B Scheme Rulebook 2025 version 1.1; EPC016-06 SDD Core Scheme Rulebook 2025 version 1.1, Annex V", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms word for word that refusal 'by way of derogation from Article 80 of the Payment Services Directive... also includes day D' (4.4), the D+3 return window already confirmed for the return fact (4.3.4), no refund of an authorised collection (4.2, 4.3.4, 4.4), the Reversal surviving on Core's terms, D+5 from the Due Date (4.3.4), and the Annex VI 13 month inquiry exposure under PSD2 Articles 71-73 and 89 and Core Annex V items 1.2-1.3's no-recovery rule already confirmed precisely for the refund fact. Does not independently confirm the exact scope of Article 80(3); EUR-Lex remains unreachable." } ] }, "rail_name": "SEPA Direct Debit B2B", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sdd-b2b:hours", "id": "hours", "rail": "sepa-sdd-b2b", "kind": "rail-fact", "facet": "hours", "name": "When is the B2B scheme open, and which calendar do its deadlines run on?", "statement": "Day-grained, like SEPA Direct Debit Core, on the same three calendars: TARGET days for anything between the two PSPs, each institution's own opening days for work inside one of them, and plain calendar days for the customer-facing windows. The B2B timetable is shorter at the back end and unchanged at the front. Presentation still has to reach the Debtor PSP one Inter-PSP Business Day before the Due Date and pre-notification still runs fourteen calendar days ahead, but a Return has to settle within three Inter-PSP Business Days rather than five, and the rulebook pushes for it on the Due Date itself. The eight week and thirteen month customer windows that dominate the Core calendar do not exist here.", "details": [ { "label": "The scheme has no intraday clock", "value": "Deadlines are whole days. What time a file has to arrive is agreed between each CSM and its participants, and between each PSP and its business customers.", "citation": "SDD B2B Scheme Rulebook EPC222-07, 2025 version 1.1, section 4.3.3", "rests_on": "rule" }, { "label": "Inter-PSP Business Day", "value": "A day PSPs are generally open to each other, identified from the TARGET Days Calendar, a long-term calendar of closing days running since 2002 and published by the European Central Bank.", "citation": "SDD B2B Scheme Rulebook EPC222-07, 2025 version 1.1, section 4.3", "rests_on": "rule" }, { "label": "Banking Business Day", "value": "A day one named participant is open for the business a SEPA B2B direct debit needs. Institution by institution, so two participants can be on different ones at the same moment.", "citation": "SDD B2B Scheme Rulebook EPC222-07, 2025 version 1.1, section 4.3", "rests_on": "rule" }, { "label": "Calendar Day", "value": "Every day of the year. On this scheme the only customer-facing window that uses it is pre-notification, since there is no refund window to count.", "citation": "SDD B2B Scheme Rulebook EPC222-07, 2025 version 1.1, sections 4.3 and 4.3.4", "rests_on": "rule" }, { "label": "Which deadline uses which calendar, inter-PSP", "value": "Counted in Inter-PSP Business Days: presentation to the Debtor PSP at D-1; settlement of a Return at D+3 from the collection's Settlement Date; a Reversal from the Settlement Date through five days after the Due Date.", "citation": "SDD B2B Scheme Rulebook EPC222-07, 2025 version 1.1, section 4.3.4", "rests_on": "rule" }, { "label": "Which deadline uses which calendar, customer facing", "value": "Counted in calendar days: pre-notification 14 days before the Due Date unless debtor and creditor agreed another timeline, and the collection not handed to the Creditor PSP more than 14 days ahead.", "citation": "SDD B2B Scheme Rulebook EPC222-07, 2025 version 1.1, section 4.3.4", "rests_on": "rule" }, { "label": "Returns are wanted sooner than the deadline", "value": "The rulebook does not treat D+3 as a target. It tells the Debtor PSP to execute a Return as soon as possible and ideally on day D, with three Inter-PSP Business Days as the outer limit for settling it.", "citation": "SDD B2B Scheme Rulebook EPC222-07, 2025 version 1.1, section 4.3.4, with section 4.6.4 PT-04.09 and PT-04.10", "rests_on": "rule" }, { "label": "Refusal covers day D", "value": "By an express derogation from Article 80 of the Payment Services Directive, the period in which a debtor may refuse a collection takes in the Due Date itself.", "citation": "SDD B2B Scheme Rulebook EPC222-07, 2025 version 1.1, section 4.4 (Refusals)", "rests_on": "rule" }, { "label": "The inquiry procedure runs on banking days", "value": "Where a Debtor PSP starts the inquiry procedure it has 4 Banking Business Days to put the request to the Creditor PSP, which has 3 Banking Business Days to answer alone or 10 if it has to go to its creditor, and the creditor 7 Banking Business Days to respond. The Debtor PSP may escalate if nothing comes back within 20 Banking Business Days of the request.", "citation": "SDD B2B Scheme Rulebook EPC222-07, 2025 version 1.1, Annex VI, steps 2 to 5", "rests_on": "rule" }, { "label": "What happens when the calendars disagree", "value": "A Due Date on a non-TARGET day moves settlement to the next Inter-PSP Business Day, and a Settlement Date that is not a Banking Business Day at the Debtor PSP moves the debit to its next open day.", "citation": "SDD B2B Scheme Rulebook EPC222-07, 2025 version 1.1, section 4.3.2", "rests_on": "rule" }, { "label": "There is no 24 by 7 obligation on this rail", "value": "Nothing here makes a participant process collections outside business days, and the round-the-clock duty Regulation (EU) 2024/886 added to Union law applies to instant credit transfers, not direct debits.", "citation": "Regulation (EU) No 260/2012 Article 5a(1), as inserted by Regulation (EU) 2024/886, read against SDD B2B Scheme Rulebook EPC222-07, 2025 version 1.1, section 4.3", "rests_on": "law" } ], "exceptions": [ "The TARGET closing days are not listed in the rulebook; it points at the ECB calendar, which the drafter did not read, so the current list is [Unverified].", "A national holiday can close one participant while TARGET stays open, moving that PSP's debit date without moving any inter-PSP deadline (section 4.3.2) [Inference from the two calendar definitions].", "Debiting late buys no time: the D+3 limit on settling a Return does not move (section 4.3.2).", "The thirteen month exposure described in Annex VI runs on calendar months from the debit date and comes from payment services law, not from the scheme timetable.", "When the creditor is credited is outside the scheme, so its value date is a matter between it and its Creditor PSP (section 4.3.4)." ], "applies_to": "the timing of SEPA Direct Debit B2B collections and their R-transactions between participants, and the customer-facing windows the rulebook sets", "caveat": "The D+3 return window is the operational heart of this scheme and it is tighter than it looks, because the Debtor PSP has to complete its mandate check before it debits at all. A bank that runs mandate verification as an overnight batch has already spent much of the window.", "related": [ "sepa-sdd-b2b:finality", "sepa-sdd-b2b:settlement", "sepa-sdd-b2b:return", "sepa-sdd-b2b:recall", "sepa-sdd-b2b:refund", "sepa-sdd-b2b:limits" ], "basis": { "sources": "SEPA Direct Debit B2B Scheme Rulebook EPC222-07, 2025 version 1.1, date issued 05 October 2025 (marked Public), read for this record: section 4.3 (calendar definitions), 4.3.1 and 4.3.2 (key dates and displacement), 4.3.3 (cut-off times), 4.3.4 (time cycle rules), 4.4 (refusal covering day D), 4.6.4 PT-04.09 and PT-04.10, Annex VI steps 2 to 5. Regulation (EU) No 260/2012, consolidated text of 08 April 2024 on EUR-Lex, Article 5a(1). The TARGET Days Calendar was not read.", "confidence": "high" }, "currency": { "effective_since": "Long-standing", "effective_note": "The calendar definitions, the D+3 return window and the day D refusal derogation are in the 2025 version 1.1 rulebook, effective 05 October 2025, and predate it [Inference]. Earlier editions were not read, so first effective dates are [Unverified]. TARGET closing days change only through ECB decisions on the long-term calendar.", "source_edition": "SDD B2B Scheme Rulebook EPC222-07, 2025 version 1.1, date issued 05 October 2025; Regulation (EU) No 260/2012 consolidated to 08 April 2024", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-10/EPC222-07%202025%20SDD%20B2B%20Rulebook%20version%201.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC222-07 SDD B2B Scheme Rulebook 2025 version 1.1", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the three-calendar structure (4.3), whole-day-only deadlines (4.3.3), the D-1 presentation, D+3 return and D+5 reversal windows already confirmed for the return, finality and recall facts (4.3.4), the day-D refusal derogation from PSD2 Article 80 confirmed word for word for the finality fact (4.4), the 4/3-or-10/7 banking business day inquiry timetable in Annex VI, and the date-displacement rule (4.3.2). Does not independently confirm Regulation 260/2012 Article 5a(1) as inserted by 2024/886; EUR-Lex remains unreachable." } ] }, "rail_name": "SEPA Direct Debit B2B", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sdd-b2b:liability", "id": "liability", "rail": "sepa-sdd-b2b", "kind": "rail-fact", "facet": "liability", "name": "Who bears the loss when a B2B collection goes wrong?", "statement": "The Debtor PSP, far more than on SEPA Direct Debit Core. The scheme's automatic indemnity runs only on Returns, and a Return has to settle within three Inter-PSP Business Days. Nothing comes back automatically after that, because there is no Refund to indemnify. Meanwhile the scheme loads the Debtor PSP with a duty Core does not impose, checking every collection against the mandate data its debtor confirmed, and leaves it exposed for thirteen months to a claim under payment services law that it cannot pass upstream. Beyond that the ordinary damages rule between participants applies, capped at the amount of the collection, a cap that survives gross negligence.", "details": [ { "label": "The automatic indemnity is narrower here", "value": "The Creditor PSP has to make the Debtor PSP whole for the amount of any collection that is Returned, with no fault to show. On Core there is a second limb covering Refunds and refund compensation; this rulebook has no such limb because it has no Refunds.", "citation": "SDD B2B Scheme Rulebook EPC222-07, 2025 version 1.1, section 5.9.1, compared with SDD Core Scheme Rulebook EPC016-06, 2025 version 1.1, section 5.9.1", "rests_on": "rule" }, { "label": "Where a returned collection finally lands", "value": "On the creditor, if the Creditor PSP can reach it. It debits the creditor only where it already credited the account, and if it cannot, it carries the exposure or writes it off; charging it back to the Debtor PSP is not open to it.", "citation": "SDD B2B Scheme Rulebook EPC222-07, 2025 version 1.1, section 4.6.4 PT-04.12", "rests_on": "rule" }, { "label": "The exposure the Debtor PSP cannot pass on", "value": "For thirteen months after the debit date a debtor can claim against its own PSP for an unauthorised or defectively executed collection under payment services law. The Core rulebook's comparison annex states directly that the Debtor PSP may not recover such a payment from the Creditor PSP.", "citation": "SDD B2B Scheme Rulebook EPC222-07, 2025 version 1.1, Annex VI section 1, with SDD Core Scheme Rulebook EPC016-06, 2025 version 1.1, Annex V item 1.3 (marked informational)", "rests_on": "rule" }, { "label": "What it gets instead of recovery", "value": "An inquiry the Creditor PSP must answer. It may conclude that reimbursement is justified and settle bilaterally, or it may simply supply proof that the collection was executed correctly. The annex is explicit that no settlement is guaranteed.", "citation": "SDD B2B Scheme Rulebook EPC222-07, 2025 version 1.1, Annex VI, introduction and step 3", "rests_on": "rule" }, { "label": "The duty that generates the exposure", "value": "Because there is no refund right and the amounts can be large, the Debtor PSP is obliged to confirm the mandate data with the debtor before the first debit, to check every collection against what it stored, and to bind its debtors to tell it about amendments and cancellations. A Debtor PSP that skips those checks has failed a scheme obligation, not just an internal control.", "citation": "SDD B2B Scheme Rulebook EPC222-07, 2025 version 1.1, sections 4.1 and 5.8 items 10 and 11", "rests_on": "rule" }, { "label": "It also has to police who its debtor is", "value": "Ensuring the debtor is not a consumer before debiting is the Debtor PSP's responsibility, and where a consumer account is debited in error it gets no refund right under the scheme while the debtor keeps its rights under the Payment Services Directive.", "citation": "SDD B2B Scheme Rulebook EPC222-07, 2025 version 1.1, sections 2.7 and 4.6.4 PT-04.09", "rests_on": "rule" }, { "label": "Damages between participants", "value": "One participant owes the other its foreseeable losses, costs, damages, expenses, taxes and claim liabilities arising from a breach of the rulebook on that collection, from negligent acts or omissions touching it, or from operational failures touching it.", "citation": "SDD B2B Scheme Rulebook EPC222-07, 2025 version 1.1, section 5.9.2", "rests_on": "rule" }, { "label": "The cap, and how hard it is", "value": "Claims stop at the amount of the collection, with no refund compensation to add. The ceiling holds against gross negligence, lifts only for wilful intent, and shrinks proportionately where the claimant contributed. Losses from risk management decisions, and unforeseeable losses, cannot be claimed at all.", "citation": "SDD B2B Scheme Rulebook EPC222-07, 2025 version 1.1, section 5.9.3", "rests_on": "rule" }, { "label": "Force majeure and the EPC's own position", "value": "A participant is not liable for failure, obstruction or delay from circumstances beyond its control. The EPC and its agents answer for nothing done under a discretion in the rulebook short of bad faith, and never for unforeseeable losses.", "citation": "SDD B2B Scheme Rulebook EPC222-07, 2025 version 1.1, sections 5.9.4 and 5.10", "rests_on": "rule" }, { "label": "What the law does with an unauthorised debit", "value": "The payer's PSP refunds an unauthorised transaction immediately and by the end of the next business day at the latest, unless it suspects fraud on reasonable grounds and puts those grounds in writing to the national authority. If the payer denies authorising it, the burden of proving authentication and correct recording is on the PSP.", "citation": "Directive (EU) 2015/2366, Articles 72 and 73(1)", "rests_on": "law" }, { "label": "How much of that law a B2B debtor still has", "value": "Less than a consumer. A non-consumer user and its PSP may agree that several liability articles do not apply, including the ones on refunds and on defective execution, and may set different time limits than Article 71. What survives depends on the contract and on national law.", "citation": "Directive (EU) 2015/2366, Article 61(1)", "rests_on": "law" }, { "label": "Which law reads the rulebook", "value": "Belgian law governs the rulebook and the Adherence Agreements. The mandate has to be governed by the law of a SEPA country, which need not be the same one.", "citation": "SDD B2B Scheme Rulebook EPC222-07, 2025 version 1.1, section 3.5", "rests_on": "rule" } ], "exceptions": [ "Where the rulebook contradicts itself, Chapter 5 prevails and then Chapter 4, which matters because the liability rules sit in Chapter 5 (section 5.14).", "Participants outside the EEA are not bound by the Payment Services Directive; section 5.15 covers that with a contractual promise of substantially equivalent performance.", "An interchange fee on an R-transaction is cost allocation permitted by Article 8(2) of Regulation (EU) No 260/2012, not compensation, and does not affect the cap (section 5.13).", "Annex II, the EPC Payment Scheme Management Rules, and Annex III on risk management were not read, so the dispute machinery and any risk obligations they impose are [Unverified].", "Annex VI names the Compliance and Adherence Committee as the escalation route, which the Core rulebook's change history indicates became the Dispute Resolution Committee in the 2019 version 1.1 rulebook dated 05 March 2020 [Inference that the annex reference is stale].", "Liability of a CSM to the participants that use it is outside the rulebook (section 1.4) and no CSM document was read." ], "applies_to": "allocation of loss between a Creditor PSP and a Debtor PSP on SEPA Direct Debit B2B collections, and the legal backstop between a PSP and its business customer", "caveat": "B2B moves risk from the creditor to the debtor's bank, not out of the system. The Debtor PSP takes on a mandate verification duty, a three day window to fix anything, thirteen months of legal exposure and no way to recover. That is the price of the certainty the creditor is buying.", "related": [ "sepa-sdd-b2b:finality", "sepa-sdd-b2b:return", "sepa-sdd-b2b:refund", "sepa-sdd-b2b:settlement", "sepa-sdd-b2b:consumer-law", "sepa-sdd-b2b:participants", "sepa-sdd-b2b:decision-points" ], "basis": { "sources": "SEPA Direct Debit B2B Scheme Rulebook EPC222-07, 2025 version 1.1, date issued 05 October 2025 (marked Public), read for this record: sections 2.7 (consumer accounts), 3.5 (governing laws), 4.1 (mandate checking duties), 4.6.4 PT-04.09 and PT-04.12, 5.8 (Debtor PSP obligations, items 4, 10 and 11), 5.9.1 to 5.9.4 (indemnity for returns, compensation, caps, force majeure), 5.10 (EPC liability), 5.13 (interchange fees), 5.14 (order of precedence), 5.15 (application of EU legislation), Annex VI (introduction, section 1, step 3). SDD Core Scheme Rulebook EPC016-06, 2025 version 1.1, section 5.9.1 and Annex V item 1.3, for the comparison, and section 0.2 change history. Directive (EU) 2015/2366, consolidated text of 08 April 2024 on EUR-Lex, Articles 61(1), 72 and 73(1). Regulation (EU) No 260/2012, Article 8. Annexes II and III of the rulebook were not read.", "confidence": "high" }, "currency": { "effective_since": "Long-standing", "effective_note": "The liability provisions cited are in the 2025 version 1.1 rulebook, effective 05 October 2025, and predate it [Inference]. Earlier editions were not read, so first effective dates are [Unverified]. The Dispute Resolution Committee replaced the Compliance and Adherence Committee in the 2019 version 1.1 rulebook dated 05 March 2020 according to the Core rulebook's change history, which is why the Annex VI reference looks stale.", "source_edition": "SDD B2B Scheme Rulebook EPC222-07, 2025 version 1.1, date issued 05 October 2025; Directive (EU) 2015/2366 consolidated to 08 April 2024", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-10/EPC222-07%202025%20SDD%20B2B%20Rulebook%20version%201.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC222-07 SDD B2B Scheme Rulebook 2025 version 1.1; EPC016-06 SDD Core Scheme Rulebook 2025 version 1.1, Annex V", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the return-only automatic indemnity with no refund limb, matching the AT-R005-to-AT-R007 gap already confirmed for the settlement fact (5.9.1), the credit-risk allocation already confirmed for the return fact (PT-04.12), the 13 month unrecoverable exposure precisely confirmed for the refund fact against Annex VI section 1 and Core Annex V item 1.3, the discretionary non-guaranteed inquiry route (Annex VI introduction, step 3), the mandate-confirmation and checking duties (4.1, 5.8 items 10-11), the consumer-screening duty and no-refund-on-error-debit rule (2.7, PT-04.09), the damages trigger and collection-amount cap surviving gross negligence but not wilful intent (5.9.2, 5.9.3), force majeure and EPC's own bad-faith-only liability (5.9.4, 5.10), and Belgian law governing the rulebook (3.5). Does not independently confirm Directive 2015/2366 Articles 72, 73(1) or 61(1); EUR-Lex remains unreachable." } ] }, "rail_name": "SEPA Direct Debit B2B", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sdd-b2b:limits", "id": "limits", "rail": "sepa-sdd-b2b", "kind": "rail-fact", "facet": "limits", "name": "What limits apply to a B2B collection, and who sets them?", "statement": "The amount ceiling is identical to SEPA Direct Debit Core, 999,999,999.99 euro with a one cent floor, which is a little ironic given that the large amounts B2B was built for are the stated reason its rules are stricter. The real limit on this scheme is not a number, it is the mandate: every collection is checked against the mandate data the debtor confirmed, and one that does not match is stopped. The debtor can still bar direct debits from its account outright. What it may not get is the statutory menu of amount and periodicity caps and creditor whitelists, because Union law excuses PSPs from offering those where neither side is a consumer, which on this scheme is always.", "details": [ { "label": "Amount ceiling and floor per collection", "value": "At least 0.01 euro, at most 999,999,999.99 euro, and never nothing. The Implementation Guidelines carry the same range on the interbank settlement amount and allow only EUR.", "citation": "SDD B2B Scheme Rulebook EPC222-07, 2025 version 1.1, section 4.8.28 AT-T002, with SDD B2B Inter-PSP Implementation Guidelines EPC301-07 2025 version 1.0, element 2.20", "rests_on": "rule" }, { "label": "The mandate is the real limit", "value": "Before debiting, the Debtor PSP has to match the collection against the mandate data the debtor confirmed, on the scheme code, the unique mandate reference, the creditor identifier, the debtor's IBAN, the debtor PSP's BIC and the transaction type, plus anything else the debtor and its PSP agreed to check. Where nothing matches, it follows the instructions the debtor left.", "citation": "SDD B2B Scheme Rulebook EPC222-07, 2025 version 1.1, section 4.6.4 PT-04.09, with section 4.1", "rests_on": "rule" }, { "label": "One-off means once", "value": "The checking rules call out the case where recurrent collections arrive against a one-off mandate: everything after the first is simply not covered by the mandate.", "citation": "SDD B2B Scheme Rulebook EPC222-07, 2025 version 1.1, section 4.6.4 PT-04.09", "rests_on": "rule" }, { "label": "The debtor can still close the door", "value": "A debtor may tell its PSP to bar its account from B2B direct debits altogether, and the Debtor PSP has to offer that. A refusal of an individual collection is separate and needs no reason.", "citation": "SDD B2B Scheme Rulebook EPC222-07, 2025 version 1.1, section 4.2", "rests_on": "rule" }, { "label": "The statutory control menu does not have to be offered", "value": "Union law entitles a payer to amount and periodicity caps, blocks and creditor whitelists, but the same article releases PSPs from providing any of them where neither payer nor payee is a consumer. On a scheme that excludes consumers by definition, that release always applies.", "citation": "Regulation (EU) No 260/2012 Article 5(3)(d) and the closing subparagraph of Article 5(3)", "rests_on": "law" }, { "label": "But verification is required where there is no refund right", "value": "Union law turns the absence of a refund right into a duty: where the framework agreement between payer and PSP gives no right to a refund, the payer's PSP has to check each direct debit against the mandate-related information, for amount and periodicity, before debiting.", "citation": "Regulation (EU) No 260/2012 Article 5(6), with Article 5(3)(d)(ii)", "rests_on": "law" }, { "label": "Time limits that act like limits", "value": "Fourteen calendar days of pre-notification before the Due Date unless otherwise agreed, the collection not passed to the Creditor PSP earlier than that, and arrival at the Debtor PSP by one Inter-PSP Business Day before the Due Date.", "citation": "SDD B2B Scheme Rulebook EPC222-07, 2025 version 1.1, sections 4.2 and 4.3.4", "rests_on": "rule" }, { "label": "A mandate expires from disuse", "value": "Thirty six months with no collection presented under a mandate, counted from the last one whatever became of it, and the creditor must cancel it and stop collecting. Neither PSP has to police that; it is the creditor's duty.", "citation": "SDD B2B Scheme Rulebook EPC222-07, 2025 version 1.1, section 4.2", "rests_on": "rule" }, { "label": "No partial amounts coming back", "value": "Returns, Reversals and Revocations all have to be for the exact euro amount of the original collection.", "citation": "SDD B2B Scheme Rulebook EPC222-07, 2025 version 1.1, section 2.5", "rests_on": "rule" }, { "label": "No return rate thresholds, but a soft one", "value": "No percentage threshold triggers anything in this scheme. The nearest thing to one is the inquiry annex telling Creditor PSPs to avoid an excessive share of Rejects and Returns against any single creditor, with no figure attached.", "citation": "SDD B2B Scheme Rulebook EPC222-07, 2025 version 1.1, Annex VI, section 2.2", "rests_on": "rule" }, { "label": "A ceiling on what one PSP can claim from another", "value": "Claims between participants stop at the amount of the collection, with no refund compensation to add because none exists here, and the ceiling holds even against gross negligence.", "citation": "SDD B2B Scheme Rulebook EPC222-07, 2025 version 1.1, section 5.9.3", "rests_on": "rule" } ], "exceptions": [ "The mandate check list in PT-04.09 does not include amount or periodicity, while Article 5(6) of Regulation (EU) No 260/2012 requires the payer's PSP to check amount and periodicity against the mandate-related information where there is no refund right. How participants reconcile the two was not established from the texts read [Unverified].", "The debtor and its PSP may agree to check further attributes, so the effective limit on a given account can be tighter than the scheme's list (section 4.6.4 PT-04.09).", "Annex III on risk management was referenced by the participant obligations and not read, so any quantitative control it imposes is [Unverified].", "Creditor PSPs commonly cap their creditors through their own terms; the rulebook does not govern that relationship (section 3.2).", "A CSM may impose its own file, batch or value limits; CSM rules sit outside the rulebook (section 1.4) and none was read.", "There is no refund window to limit, so nothing here corresponds to the Core eight week and thirteen month claim limits." ], "applies_to": "SEPA Direct Debit B2B collections and the controls a business debtor may place on its own account", "caveat": "Do not read the identical amount ceiling as identical risk. On Core a wrong collection can be clawed back for eight weeks; on B2B the same wrong collection is final in three Inter-PSP Business Days, which is why the mandate check before the debit is the control that actually matters.", "related": [ "sepa-sdd-b2b:settlement", "sepa-sdd-b2b:messages", "sepa-sdd-b2b:consumer-law", "sepa-sdd-b2b:return", "sepa-sdd-b2b:participants", "sepa-sdd-b2b:decision-points" ], "basis": { "sources": "SEPA Direct Debit B2B Scheme Rulebook EPC222-07, 2025 version 1.1, date issued 05 October 2025 (marked Public), read for this record: sections 1.4, 2.5, 3.2, 4.1 (mandate checking), 4.2 (collections, blocking, 36 month inactivity), 4.3.4 (time cycle), 4.6.4 PT-04.09 (the check list), 4.8.28 AT-T002, 5.9.3 (liability cap), Annex VI section 2.2. SDD B2B Inter-PSP Implementation Guidelines EPC301-07 2025 version 1.0 (file dated 2025-10, abstract states it implements rulebook 2025 version 1.1), element 2.20. Regulation (EU) No 260/2012, consolidated text of 08 April 2024 on EUR-Lex, Article 5(3) and 5(6). Annex III of the rulebook was not read.", "confidence": "high" }, "currency": { "effective_since": "2025-10-05", "effective_note": "The amount range and the mandate check list are in the 2025 version 1.1 rulebook and the matching Implementation Guidelines, both effective 05 October 2025, and predate this edition [Inference]. Earlier editions were not read, so first effective dates are [Unverified]. Among the SDD B2B items in the 2026 change request consultation read for Orca's SEPA rail brief (docs/rails/sepa.md), none proposes a change to the amount ceiling (EPC011-26 version 1.0, 13 March 2026).", "source_edition": "SDD B2B Scheme Rulebook EPC222-07, 2025 version 1.1, date issued 05 October 2025; SDD B2B Inter-PSP Implementation Guidelines EPC301-07 2025 version 1.0; Regulation (EU) No 260/2012 consolidated to 08 April 2024", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-10/EPC222-07%202025%20SDD%20B2B%20Rulebook%20version%201.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC222-07 SDD B2B Scheme Rulebook 2025 version 1.1", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the AT-T002 999,999,999.99 euro ceiling at 4.8.28, the mandate-check list already confirmed word for word for the return fact (PT-04.09), the one-off-mandate rule, the 36 month inactivity rule mirroring Core, the account-blocking duty (4.2), the collection-amount liability ceiling (5.9.3), and, confirmed by direct inspection, the 'excessive proportion of Rejects and Returns' language in Annex VI section 2.2. Does not independently confirm Regulation 260/2012 Article 5(3)(d), the Article 5(3) closing subparagraph, or Article 5(6); EUR-Lex remains unreachable. Did not verify the EPC301-07 Implementation Guidelines element 2.20 citation, which was not read for this check." } ] }, "rail_name": "SEPA Direct Debit B2B", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sdd-b2b:messages", "id": "messages", "rail": "sepa-sdd-b2b", "kind": "rail-fact", "facet": "messages", "name": "Which messages carry a B2B direct debit, and who pins their versions?", "statement": "The same message set as SEPA Direct Debit Core, with one fewer use for it. The rulebook names no message at all; it describes datasets and attributes and leaves the wire format to Implementation Guidelines that pin ISO 20022 at the 2019 message version. Between PSPs the collection, the reject, the return and the reversal use the same four pacs messages Core uses, and between a creditor and its own PSP the same three pain messages. What is missing is the refund: the payment return message carries only Returns on this scheme. The inquiry procedure, which is B2B's substitute for a refund claim, has no ISO message at all and travels by a SWIFT message the rulebook never names, or by email or fax templates.", "details": [ { "label": "The rulebook speaks in datasets, not messages", "value": "Business content is defined as datasets and attributes, and the standards that carry them are dealt with in the Implementation Guidelines listed in the front matter.", "citation": "SDD B2B Scheme Rulebook EPC222-07, 2025 version 1.1, sections 4.5, 4.7 and 4.8", "rests_on": "rule" }, { "label": "Which ISO 20022 version is pinned", "value": "The 2025 guidelines sit on the 2019 message version of ISO 20022. They were issued on 28 November 2024 and took effect on 05 October 2025 alongside rulebook version 1.1.", "citation": "SDD B2B Inter-PSP Implementation Guidelines EPC301-07 2025 version 1.0, abstract and section 0.1", "rests_on": "rule" }, { "label": "The four inter-PSP messages", "value": "The collection is the FI to FI Customer Direct Debit, pacs.003.001.08. The pre-settlement Reject is the FI to FI Payment Status Report, pacs.002.001.10. The Return is the Payment Return, pacs.004.001.09. The Reversal is the Payment Reversal, pacs.007.001.09.", "citation": "SDD B2B Inter-PSP Implementation Guidelines EPC301-07 2025 version 1.0, sections 2.1 to 2.4", "rests_on": "rule" }, { "label": "The payment return message does less work here", "value": "On Core the Payment Return carries both Returns and Refunds. On B2B there are no Refunds, so it carries Returns only, and the reason attribute in this rulebook has no refund branch either.", "citation": "SDD B2B Scheme Rulebook EPC222-07, 2025 version 1.1, section 4.8.39 AT-R004, with SDD B2B Inter-PSP Implementation Guidelines EPC301-07 2025 version 1.0, section 2.2", "rests_on": "rule" }, { "label": "Creditor to its own PSP", "value": "The customer-facing side uses the same pain family at the 2019 message version: pain.008.001.08 to send collections, pain.002.001.10 for status back, pain.007.001.09 for a reversal.", "citation": "SDD B2B Customer-to-PSP Implementation Guidelines EPC131-08 2025 version 1.0", "rests_on": "rule" }, { "label": "The inquiry has no ISO message", "value": "An inquiry request and its answer travel as DS-08 over a SWIFT message, or as DS-09 over an email or fax template, with any other channel the two PSPs agree also permitted. The rulebook calls the default the suitable SWIFT message and never identifies it.", "citation": "SDD B2B Scheme Rulebook EPC222-07, 2025 version 1.1, Annex VI, steps 2 and 3", "rests_on": "rule" }, { "label": "Mandate data rides on every collection, and is checked", "value": "The creditor sends mandate data to its PSP with each collection and the Creditor PSP passes it to the Debtor PSP inside the collection, in one flow through the CSM. The difference from Core is what happens next: the Debtor PSP matches that data against what its debtor confirmed before it debits.", "citation": "SDD B2B Scheme Rulebook EPC222-07, 2025 version 1.1, sections 4.1 and 4.2, with section 4.6.4 PT-04.09", "rests_on": "rule" }, { "label": "The scheme identification code separates the two schemes", "value": "Attribute AT-T001 carries the scheme identification code, and the Debtor PSP's mandate check requires it to read B2B. That one field is what stops a Core mandate being used for a B2B collection and the reverse.", "citation": "SDD B2B Scheme Rulebook EPC222-07, 2025 version 1.1, section 4.6.4 PT-04.09", "rests_on": "rule" }, { "label": "Account identification", "value": "IBAN identifies the accounts, and a PSP may not require a payment service user to supply the other side's BIC. The creditor also carries the scheme creditor identifier, attribute AT-E005.", "citation": "Regulation (EU) No 260/2012 Article 5(1)(a) and 5(7), with SDD B2B Scheme Rulebook EPC222-07, 2025 version 1.1, section 4.8 attribute list", "rests_on": "law" }, { "label": "A dated change already in the guidelines", "value": "From 22 November 2026 only structured and hybrid addresses may be used in EPC payment messages; unstructured addresses stop being allowed. The note appears in the Inter-PSP and Customer-to-PSP guidelines for this scheme and points at the EPC guidance document on addresses.", "citation": "SDD B2B Inter-PSP Implementation Guidelines EPC301-07 2025 version 1.0, section 1.7, and SDD B2B Customer-to-PSP Implementation Guidelines EPC131-08 2025 version 1.0, section 1.7", "rests_on": "rule" }, { "label": "Where the reason code values come from", "value": "The rulebook states the permitted reasons in words and points at the EPC reason code guidance for which ISO code carries each. The values themselves are ISO 20022 External Code Set values, and which ones a scheme may use is the EPC's decision.", "citation": "SDD B2B Scheme Rulebook EPC222-07, 2025 version 1.1, section 4.8.39 AT-R004, with EPC Guidance on Reason Codes for SDD R-transactions EPC173-14 version 8.0, section 3", "rests_on": "rule" } ], "exceptions": [ "The SWIFT message used for the inquiry procedure is never identified, in the rulebook or the guidelines, so its identifier is [Unverified].", "The e-mandate rules for this scheme sit in Annex VII and in separate implementation guidelines that were not read, so e-mandate messages are not stated here.", "Additional Optional Services may add data elements, and community usage rules sit outside the rulebook, so a real message can carry more than the guidelines describe (section 2.4).", "The guidelines' cover pages read 2025 version 1.0 while their abstracts state that they implement rulebook 2025 version 1.1; this record cites the files published in October 2025, and whether separately numbered version 1.1 guidelines exist is [Unverified].", "Only the front matter, section headings and message identifiers of EPC131-08 were read, so its element-level rules are not recorded here.", "The EPC guidance document on the provision of addresses, referenced for the 2026 change-over, was not read." ], "applies_to": "the messages that carry SEPA Direct Debit B2B collections and their R-transactions, between PSPs and between a creditor and its own PSP", "caveat": "The message set alone will not tell an integrator that these are different schemes. The same four pacs messages carry both, and the difference lives in one attribute, the scheme identification code, and in what the Debtor PSP is obliged to do before it debits.", "related": [ "sepa-sdd-b2b:return", "sepa-sdd-b2b:recall", "sepa-sdd-b2b:refund", "sepa-sdd-b2b:limits", "sepa-sdd-b2b:settlement" ], "basis": { "sources": "SDD B2B Inter-PSP Implementation Guidelines EPC301-07 2025 version 1.0 (file dated 2025-10, abstract states it implements rulebook 2025 version 1.1), read for this record: abstract, section 0.1, section 1.7 (change-over date and the address note), the section headings and message identifiers at 2.1 to 2.4, and element 2.20. SDD B2B Customer-to-PSP Implementation Guidelines EPC131-08 2025 version 1.0 (file dated 2025-10), front matter, section 1.7 and message identifiers. SEPA Direct Debit B2B Scheme Rulebook EPC222-07, 2025 version 1.1, date issued 05 October 2025: sections 2.4, 4.1, 4.2, 4.5, 4.6.4 PT-04.09, 4.7, 4.8 attribute list and 4.8.39 AT-R004, Annex VI steps 2 and 3. Regulation (EU) No 260/2012, consolidated to 08 April 2024, Article 5. EPC Guidance on Reason Codes for SDD R-transactions EPC173-14 version 8.0, section 3. The e-mandate annex and guidelines, and the EPC address guidance document, were not read.", "confidence": "high" }, "currency": { "effective_since": "2025-10-05", "effective_note": "The guidelines cited were issued on 28 November 2024 and took effect on 05 October 2025 with rulebook version 1.1, pinning the 2019 message version of ISO 20022. A dated change is already published: from 22 November 2026 unstructured addresses may no longer be provided in EPC payment messages, structured and hybrid only. Message versions otherwise move only when a new edition of the guidelines says so, so the next opportunity is the November 2026 publication for the 2027 rulebooks.", "source_edition": "SDD B2B Inter-PSP Implementation Guidelines EPC301-07 2025 version 1.0; SDD B2B Customer-to-PSP Implementation Guidelines EPC131-08 2025 version 1.0; SDD B2B Scheme Rulebook EPC222-07, 2025 version 1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-10/EPC222-07%202025%20SDD%20B2B%20Rulebook%20version%201.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC222-07 SDD B2B Scheme Rulebook 2025 version 1.1; SDD B2B Inter-PSP and Customer-to-PSP Implementation Guidelines EPC301-07 and EPC131-08, both 2025 version 1.0", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms all four inter-PSP message identifiers directly from EPC301-07: pacs.003.001.08 at 2.1.1, pacs.004.001.09 at 2.2.1, pacs.002.001.10 at 2.3.1, pacs.007.001.09 at 2.4.1, and the abstract's 'implementing Version 1.1 of the 2025 SDD B2B Scheme Rulebook' wording, which unlike the Core Inter-PSP Implementation Guidelines does name rulebook version 1.1. Confirms the three pain messages from EPC131-08: pain.008.001.08, pain.007.001.09, pain.002.001.10. Confirms the AT-T001 scheme identification code and AT-R004 no-refund-branch reason attribute already checked for the limits and return facts. Does not independently confirm Regulation 260/2012 Article 5(1)(a) or 5(7); EUR-Lex remains unreachable. Did not verify the Annex VII e-mandate implementation guidelines or the address guidance document, which were not read." } ] }, "rail_name": "SEPA Direct Debit B2B", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sdd-b2b:participants", "id": "participants", "rail": "sepa-sdd-b2b", "kind": "rail-fact", "facet": "participants", "name": "Who can take part in the B2B scheme, and what does joining commit them to?", "statement": "Participants are PSPs, joining is a separate decision from joining SEPA Direct Debit Core, and the biggest difference is that the rulebook drops universal reach as a premise. Being collectible is optional here, so a PSP is free to stay out, and Union law does not push it in, because the statutory reachability duty is written for direct debits available to consumers. A PSP that does join must at least serve as Debtor PSP, and that role carries obligations Core does not impose: establish that the debtor is not a consumer and may lawfully give up its refund right, get the debtor to confirm the mandate data before the first debit, store it, check every later collection against it, and make the debtor tell it about amendments and cancellations.", "details": [ { "label": "Participation is optional, and that is explicit", "value": "Joining is a choice, and so is the role: Debtor PSP alone, or Debtor PSP and Creditor PSP together. The rulebook does not treat universal reach as a premise of this scheme. A PSP that does join has to process collections under its rules.", "citation": "SDD B2B Scheme Rulebook EPC222-07, 2025 version 1.1, section 2.6", "rests_on": "rule" }, { "label": "What a participant must at least offer", "value": "Having joined, a participant offers the scheme as Debtor PSP, or as both Debtor PSP and Creditor PSP. Creditor PSP alone is not one of the options.", "citation": "SDD B2B Scheme Rulebook EPC222-07, 2025 version 1.1, section 5.3", "rests_on": "rule" }, { "label": "Why the law does not force reachability here", "value": "The reachability obligation on a payer's PSP covers only direct debits that a scheme makes available to consumers as payers. Excluding consumers puts this scheme outside it.", "citation": "Regulation (EU) No 260/2012 Article 3(2) and 3(3)", "rests_on": "law" }, { "label": "A participant can be electronic-only", "value": "The e-mandate service is optional in either role, and a PSP may choose to participate as Creditor PSP or as Debtor PSP accepting e-mandates and no paper ones. On Core, offering e-mandates never reduces the duty to accept paper-mandate collections.", "citation": "SDD B2B Scheme Rulebook EPC222-07, 2025 version 1.1, section 2.6, compared with SDD Core Scheme Rulebook EPC016-06, 2025 version 1.1, section 2.6", "rests_on": "rule" }, { "label": "The four actors, and which two are participants", "value": "Creditor, Creditor PSP, Debtor PSP and debtor. Only the two PSPs are participants. CSMs and intermediary PSPs are in the flow without being members, and using them changes nothing about what the participant owes.", "citation": "SDD B2B Scheme Rulebook EPC222-07, 2025 version 1.1, sections 3.1 and 3.4", "rests_on": "rule" }, { "label": "What adhering creates", "value": "A multilateral agreement: a contract with the EPC and a contract with every other participant, governed by Belgian law along with the Adherence Agreements. Non-parties get neither rights nor obligations.", "citation": "SDD B2B Scheme Rulebook EPC222-07, 2025 version 1.1, sections 5.2 and 3.5", "rests_on": "rule" }, { "label": "Who is eligible", "value": "The same nine criteria as Core: providing banking or payment services and payment accounts, licensed in a SEPA country or by an EEA regulator, solvent, adequately capitalised, meeting any rating criteria, compliant on money laundering, sanctions and terrorist financing, participating in a CSM directly or indirectly, and running appropriate operational and risk controls.", "citation": "SDD B2B Scheme Rulebook EPC222-07, 2025 version 1.1, section 5.4", "rests_on": "rule" }, { "label": "The Debtor PSP duties that only exist here", "value": "Know your customer, including the checking instructions agreed with the debtor; establish that the debtor is not a consumer and may opt out of the refund right under national law; obtain the debtor's confirmation of the B2B mandate data before the first debit; check every later collection against the stored data; and carry out Rejects and Returns even after the account closes.", "citation": "SDD B2B Scheme Rulebook EPC222-07, 2025 version 1.1, section 5.8 items 1, 4, 8, 10 and 11", "rests_on": "rule" }, { "label": "What the Debtor PSP must make its debtors do", "value": "Keep to the mandates they signed, resolve disputed collections directly with the creditor, tell the Debtor PSP when their position on opting out of the refund right changes, and report any amendment or cancellation of a mandate no later than the day it takes effect and before the next collection is due, so the checks stay accurate.", "citation": "SDD B2B Scheme Rulebook EPC222-07, 2025 version 1.1, section 5.8 items 19 to 21", "rests_on": "rule" }, { "label": "Joining and leaving", "value": "An applicant sends a signed Adherence Agreement with supporting documentation and becomes a participant on a date the EPC sets under the Internal Rules, with reasons and an appeal if rejected. Leaving takes at least six months' written notice, and work already in flight has to be finished.", "citation": "SDD B2B Scheme Rulebook EPC222-07, 2025 version 1.1, sections 5.5 and 5.11", "rests_on": "rule" }, { "label": "Outsourcing does not move the obligation", "value": "A participant may run the processes itself, use intermediaries or outsource, and answers under the rulebook either way; leaning on a CSM or intermediary is at its own risk.", "citation": "SDD B2B Scheme Rulebook EPC222-07, 2025 version 1.1, sections 1.3 and 5.3", "rests_on": "rule" } ], "exceptions": [ "Adherence is per scheme. A Core participant is not thereby a B2B participant, which is exactly why a creditor cannot assume any given debtor account is reachable for B2B.", "A participant that adheres to B2B as Debtor PSP may apply B2B rules to Reject or Return a collection presented as a Core collection, and is obliged to check the mandate status in that case (section 2.7).", "Participants outside the EEA are not subject to the Payment Services Directive; section 5.15 substitutes a contractual promise of substantially equivalent performance.", "Eligibility includes meeting whatever rating or financial criteria the scheme sets at the time, and those criteria are not written down in the rulebook and were not read [Unverified].", "Annex I, the Adherence Agreement, Annex II, the EPC Payment Scheme Management Rules, and Annex III on risk management were not read for this record.", "Whether the list of participants for this scheme is published openly or only to participants was not checked [Unverified]." ], "applies_to": "PSPs adhering to the SEPA Direct Debit B2B scheme, in the Debtor PSP role or in both roles", "caveat": "The first question on a B2B collection is not whether the mandate is valid, it is whether the debtor's bank is in the scheme at all. Nothing obliges it to be, and a creditor that assumes SEPA-wide reach because Core has it will find collections rejected before anyone looks at a mandate.", "related": [ "sepa-sdd-b2b:settlement", "sepa-sdd-b2b:liability", "sepa-sdd-b2b:consumer-law", "sepa-sdd-b2b:limits", "sepa-sdd-b2b:messages", "sepa-sdd-b2b:refund" ], "basis": { "sources": "SEPA Direct Debit B2B Scheme Rulebook EPC222-07, 2025 version 1.1, date issued 05 October 2025 (marked Public), read for this record: sections 1.3 (binding nature and outsourcing), 2.6 (participation and reachability), 2.7 (erroneous use), 3.1 (actors), 3.4 (intermediary PSPs), 3.5 (governing laws), 5.2 to 5.5 (compliance, reachability, eligibility, joining), 5.8 (Debtor PSP obligations, items 1, 4, 8, 10, 11, 19 to 21), 5.11 (termination), 5.15 (application of EU legislation). SDD Core Scheme Rulebook EPC016-06, 2025 version 1.1, section 2.6, for the comparison. Regulation (EU) No 260/2012, consolidated text of 08 April 2024 on EUR-Lex, Article 3. Annexes I, II and III of the rulebook were not read.", "confidence": "high" }, "currency": { "effective_since": "Long-standing", "effective_note": "The participation rules cited are in the 2025 version 1.1 rulebook, effective 05 October 2025, and predate it [Inference]. The scheme's geographical scope changes when the EPC admits a country, through EPC409-09, which was not read for this record. Earlier rulebook editions were not read, so first effective dates are [Unverified].", "source_edition": "SDD B2B Scheme Rulebook EPC222-07, 2025 version 1.1, date issued 05 October 2025; Regulation (EU) No 260/2012 consolidated to 08 April 2024", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-10/EPC222-07%202025%20SDD%20B2B%20Rulebook%20version%201.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC222-07 SDD B2B Scheme Rulebook 2025 version 1.1", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms word for word that 'PSPs are free to participate...as Debtor PSP, or...both Debtor PSP and Creditor PSP' and that 'Reachability of all PSPs is not an assumption for this Scheme' (2.6), the e-mandate-only participation option contrasted with Core (2.6), the Core/B2B cross-scheme reject-or-return rule (2.7), the four-actor model with only PSPs as participants (3.1, 3.4), the multilateral-agreement framing and Belgian law (5.2, 3.5), and joining/leaving/outsourcing provisions mirroring Core (5.5, 5.11, 1.3, 5.3). Did not re-verify each of the nine eligibility criteria word for word against 5.4 for this check, relying on the identical structure already confirmed for Core; did not verify the specific Debtor PSP duty items 1, 4, 8, 10, 11, 19-21 line by line against 5.8. Does not independently confirm Regulation 260/2012 Article 3(2)-(3); EUR-Lex remains unreachable." } ] }, "rail_name": "SEPA Direct Debit B2B", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sdd-b2b:recall", "id": "recall", "rail": "sepa-sdd-b2b", "kind": "rail-fact", "facet": "recall", "name": "Can the creditor's side pull a B2B collection back, and what is it called?", "statement": "No recall exists here either. The creditor's side has the same three exits as on SEPA Direct Debit Core and they behave the same way: a Revocation, which the creditor agrees bilaterally with its own PSP and the scheme does not govern; a request for cancellation, which the Creditor PSP agrees with its CSM before settlement and the scheme does not govern; and the Reversal, which is the scheme's own process for a creditor that concludes it should never have collected. The Reversal runs on the same five Inter-PSP Business Day window as on Core, which means it outlives the D+3 return window by two days and is, for a stretch, the only way anything comes back to a B2B debtor.", "details": [ { "label": "The scheme's own list of exception paths", "value": "Rejects, Refusals, Returns, Reversals, Revocations and requests for cancellation. Refunds are named only to say they are not part of this scheme, and recall does not appear at all.", "citation": "SDD B2B Scheme Rulebook EPC222-07, 2025 version 1.1, section 4.4", "rests_on": "rule" }, { "label": "Revocation", "value": "The creditor withdrawing its own instruction up to a date agreed with its Creditor PSP. Expressly left to their bilateral agreement and not covered by the scheme.", "citation": "SDD B2B Scheme Rulebook EPC222-07, 2025 version 1.1, section 4.4", "rests_on": "rule" }, { "label": "Request for cancellation", "value": "The Creditor PSP asking its CSM to withdraw a collection before settlement, under their own contract, again outside the scheme.", "citation": "SDD B2B Scheme Rulebook EPC222-07, 2025 version 1.1, section 4.4", "rests_on": "rule" }, { "label": "Reversal, the one scheme process", "value": "After clearing and settlement, a creditor that decides the collection should not have gone out puts the whole amount back to the debtor. The Creditor PSP may start one for the same reasons.", "citation": "SDD B2B Scheme Rulebook EPC222-07, 2025 version 1.1, section 4.4, with section 4.5.5 PR-05", "rests_on": "rule" }, { "label": "Who must offer it and who must handle it", "value": "Optional on the creditor's side, compulsory on the debtor's. A Creditor PSP need not offer Reversals and a creditor need not use them, but a Debtor PSP must process one that arrives.", "citation": "SDD B2B Scheme Rulebook EPC222-07, 2025 version 1.1, section 4.4", "rests_on": "rule" }, { "label": "The window, and why it matters here", "value": "From the Settlement Date through five Inter-PSP Business Days after the Due Date, the same as Core. Since a Return has to settle by D+3 on this scheme, there are two days in which the creditor's side can still put money back and the debtor's side cannot.", "citation": "SDD B2B Scheme Rulebook EPC222-07, 2025 version 1.1, section 4.3.4", "rests_on": "rule" }, { "label": "The Debtor PSP checks nothing", "value": "It credits the debtor without confirming that the original collection was debited or that it has not already been Rejected or Returned. On Core the same step also mentions Refunds; here there are none to mention.", "citation": "SDD B2B Scheme Rulebook EPC222-07, 2025 version 1.1, section 4.6.5 PT-05.04", "rests_on": "rule" }, { "label": "Only two reasons exist", "value": "Whoever starts it can say duplicate entry or give no reason. The Debtor PSP may pass that on to explain the credit.", "citation": "SDD B2B Scheme Rulebook EPC222-07, 2025 version 1.1, section 4.8.53 AT-R041", "rests_on": "rule" }, { "label": "All or nothing", "value": "A Reversal has to match the amount of the collection; the rulebook allows no partial one.", "citation": "SDD B2B Scheme Rulebook EPC222-07, 2025 version 1.1, sections 2.5 and 4.8.54 AT-R042", "rests_on": "rule" }, { "label": "A reversal can also settle an inquiry", "value": "Where the inquiry procedure ends with the Creditor PSP accepting that reimbursement is due, a Reversal is one of the routes the two PSPs may agree to move the money, alongside a Return, a transfer of funds or anything else.", "citation": "SDD B2B Scheme Rulebook EPC222-07, 2025 version 1.1, Annex VI, step 3", "rests_on": "rule" }, { "label": "The message that carries it", "value": "Dataset DS-07 goes on the wire as the ISO 20022 Payment Reversal, pacs.007.001.09, at the 2019 message version.", "citation": "SDD B2B Inter-PSP Implementation Guidelines EPC301-07 2025 version 1.0, section 2.4", "rests_on": "rule" } ], "exceptions": [ "A Reversal presented after its window has to be stopped by the Creditor PSP or the CSM, with the Debtor PSP told (section 4.3.4).", "Once the Debtor PSP has the Reversal there is no scheme deadline for crediting the debtor; the process step leaves the closing time open (section 4.6.5 PT-05.04).", "Because the Debtor PSP checks nothing, a Reversal after a Return of the same collection can credit the debtor twice, and untangling that is outside the scheme [Inference from PT-05.04 read with section 4.4].", "Revocation and cancellation deadlines are bilateral, so they vary between PSPs and between CSMs and cannot be stated scheme-wide (section 4.4).", "A Reversal used to settle an inquiry is an agreed workaround, not an entitlement: the annex is explicit that the inquiry procedure does not guarantee any settlement (Annex VI, introduction).", "Recall exists in the SEPA Credit Transfer and SEPA Instant Credit Transfer schemes under their own rulebooks; those rules do not carry across to a direct debit." ], "applies_to": "creditor-initiated withdrawal of a SEPA Direct Debit B2B collection, before and after settlement", "caveat": "On B2B the Reversal is not a minor tidy-up mechanism. Between D+3 and D+5 it is the only thing that can put money back into a debtor's account, and whether a creditor has it at all depends on a product decision its bank was never obliged to make.", "related": [ "sepa-sdd-b2b:finality", "sepa-sdd-b2b:return", "sepa-sdd-b2b:refund", "sepa-sdd-b2b:messages", "sepa-sdd-b2b:decision-points" ], "basis": { "sources": "SEPA Direct Debit B2B Scheme Rulebook EPC222-07, 2025 version 1.1, date issued 05 October 2025 (marked Public), read for this record: sections 2.5 (exact amounts), 4.2 (disputes out of scope), 4.3.4 (reversal window and late presentation), 4.4 (definitions of reversal, revocation and request for cancellation), 4.5.5 and 4.6.5 PT-05.01 to PT-05.04, 4.8.53 AT-R041 and 4.8.54 AT-R042, Annex VI introduction and step 3. SDD B2B Inter-PSP Implementation Guidelines EPC301-07 2025 version 1.0, section 2.4. The absence of a recall process is an absence claim from the rulebook's own list of R-transactions at section 4.4.", "confidence": "high" }, "currency": { "effective_since": "Long-standing", "effective_note": "The reversal process and its five Inter-PSP Business Day window are in the 2025 version 1.1 rulebook, effective 05 October 2025, and predate it [Inference]. Earlier editions were not read, so first effective dates are [Unverified]. The 2026 change request consultation proposes a longer recall timeline for SCT and SCT Inst, which does not touch this scheme (EPC011-26 version 1.0, 13 March 2026, item 35).", "source_edition": "SDD B2B Scheme Rulebook EPC222-07, 2025 version 1.1, date issued 05 October 2025; SDD B2B Inter-PSP Implementation Guidelines EPC301-07 2025 version 1.0", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-10/EPC222-07%202025%20SDD%20B2B%20Rulebook%20version%201.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC222-07 SDD B2B Scheme Rulebook 2025 version 1.1", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms no Recall among the B2B exception paths, Revocation and cancellation requests as bilateral matters outside the scheme, and the Reversal as the one scheme process, optional to offer and compulsory to process (4.4), the same D+5-from-Due-Date reversal window as Core already confirmed for the finality fact (4.3.4), that the Debtor PSP checks nothing before crediting (PT-05.04), sections 4.8.53 AT-R041 and 4.8.54 AT-R042 existing at those numbers, and the Annex VI step 3 option to use a Reversal to settle an accepted inquiry. Did not verify the EPC301-07 Implementation Guidelines citation for the pacs.007.001.09 message identifier, which was not read for this check." } ] }, "rail_name": "SEPA Direct Debit B2B", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sdd-b2b:refund", "id": "refund", "rail": "sepa-sdd-b2b", "kind": "rail-fact", "facet": "refund", "name": "Does the debtor have a right to be refunded, and on what grounds?", "statement": "Not under this scheme. There is no refund of an authorised collection, and the rulebook puts refunds of unauthorised collections outside its scope as well. That is the bargain: a business debtor may only use B2B if national law lets it give up the statutory refund right, and in exchange its PSP must verify the mandate before every debit. What the rulebook cannot switch off is the debtor's separate claim against its own PSP under payment services law, which the scheme's own inquiry annex acknowledges can run for thirteen months from the debit date. When that claim lands, the Debtor PSP has no scheme route to push the loss back: only an inquiry the Creditor PSP must answer and need not pay.", "details": [ { "label": "No refund of an authorised collection", "value": "A B2B debtor cannot ask its PSP to refund an authorised transaction. The time cycle rules say the same thing in one line: refunds are not provided for under this scheme.", "citation": "SDD B2B Scheme Rulebook EPC222-07, 2025 version 1.1, sections 4.2 and 4.3.4", "rests_on": "rule" }, { "label": "Refunds of unauthorised collections are outside the scope too", "value": "The rulebook defines a refund only in order to say it is not part of this scheme, and the inquiry annex puts unauthorised transaction refunds outside its scope as well. Neither kind settles between the PSPs on this rail.", "citation": "SDD B2B Scheme Rulebook EPC222-07, 2025 version 1.1, section 4.4, with Annex VI section 1, item (ii)", "rests_on": "rule" }, { "label": "Who is allowed to use the scheme at all", "value": "Only a debtor that is not a consumer and that national law permits to give up the refund right for authorised transactions, the right in Articles 61(1) and 76(1) of the Payment Services Directive. The Debtor PSP has to establish both before contracting, and national law in some countries treats microenterprises as consumers.", "citation": "SDD B2B Scheme Rulebook EPC222-07, 2025 version 1.1, sections 2.2 and 4.4, with section 5.8 item 4", "rests_on": "rule" }, { "label": "What the law permits to be given up", "value": "Union law lets a non-consumer user and its PSP agree that Articles 76 and 77, among others, do not apply at all or only in part, and lets them set time limits other than Article 71's. That agreement is the foundation the B2B scheme is built on.", "citation": "Directive (EU) 2015/2366, Article 61(1)", "rests_on": "law" }, { "label": "What cannot be given up, and how long it lasts", "value": "The rulebook's own annex says a Debtor PSP can be at risk for thirteen months after the debit date, where a debtor disputes a collection and demands reimbursement under Articles 71, 72, 73 and 89 of the Payment Services Directive. So the claim survives, it just lands on the Debtor PSP rather than travelling back through the scheme.", "citation": "SDD B2B Scheme Rulebook EPC222-07, 2025 version 1.1, Annex VI, section 1", "rests_on": "rule" }, { "label": "How the EPC describes the same position from the SEPA Direct Debit Core side", "value": "The comparison annex in the Core rulebook records that a B2B debtor may obtain a refund of an unauthorised collection from its Debtor PSP within thirteen months where its own view is that no B2B mandate covered the collection, and, in the next line, that the Debtor PSP is not allowed to recover that from the Creditor PSP.", "citation": "SDD Core Scheme Rulebook EPC016-06, 2025 version 1.1, Annex V, items 1.2 and 1.3 (marked as included for information and not part of the rulebook)", "rests_on": "rule" }, { "label": "The inquiry procedure, and what it is not", "value": "A Debtor PSP facing such a claim may open an inquiry with the Creditor PSP. The Creditor PSP is obliged to reply. It is not obliged to reimburse, the annex says outright that it is not an automatic refund procedure and does not guarantee any settlement, and it is expected to be used only in exceptional cases.", "citation": "SDD B2B Scheme Rulebook EPC222-07, 2025 version 1.1, Annex VI, introduction and section 1", "rests_on": "rule" }, { "label": "The inquiry timetable", "value": "The debtor claims within thirteen months of the debit date. The Debtor PSP has 4 Banking Business Days to put the request to the Creditor PSP, which has 3 Banking Business Days to answer on its own or 10 if it has to go to the creditor, and the creditor 7 Banking Business Days to investigate and reply. If nothing satisfactory arrives within 20 Banking Business Days of the request, the Debtor PSP may escalate.", "citation": "SDD B2B Scheme Rulebook EPC222-07, 2025 version 1.1, Annex VI, steps 1 to 5", "rests_on": "rule" }, { "label": "What an inquiry can actually be about", "value": "Two situations. A defectively executed payment, with duplicate collections as the worked example and a presumption of duplication where amount and Due Date match, or where the amount matches and the dates are close. Or a transaction the debtor says was fraudulent, which neither PSP could have spotted in advance against a valid mandate.", "citation": "SDD B2B Scheme Rulebook EPC222-07, 2025 version 1.1, Annex VI, sections 2.1 and 2.2", "rests_on": "rule" }, { "label": "The line the annex draws", "value": "A creditor that gets the amount or the Due Date wrong has not caused a defectively executed transaction, because neither is part of the mandate. Those collections are authorised, and the annex states they cannot be refunded in this scheme.", "citation": "SDD B2B Scheme Rulebook EPC222-07, 2025 version 1.1, Annex VI, section 2.1", "rests_on": "rule" }, { "label": "If the Creditor PSP does accept", "value": "There is no defined settlement path. The two PSPs agree bilaterally how to move the money, and the annex offers a Reversal, a Return, a funds transfer or any other solution.", "citation": "SDD B2B Scheme Rulebook EPC222-07, 2025 version 1.1, Annex VI, step 3", "rests_on": "rule" }, { "label": "No refund reason codes exist here", "value": "The reason attribute in this rulebook covers Rejects and Returns only, with no refund branch. In the EPC guidance MD06, the unconditional refund reason, is marked for Core collections only, and on B2B collections MD01 means a missing mandate or one the debtor never confirmed, used on a Reject or Return.", "citation": "SDD B2B Scheme Rulebook EPC222-07, 2025 version 1.1, section 4.8.39 AT-R004, with EPC Guidance on Reason Codes for SDD R-transactions EPC173-14 version 8.0, section 3", "rests_on": "guidance" } ], "exceptions": [ "Where a B2B collection debits a consumer account in error, the Debtor PSP gets no refund right under the scheme, and the debtor keeps whatever the Payment Services Directive gives it against that PSP (section 2.7).", "Where national law does not permit a given business to opt out of the refund right, that business cannot be a B2B debtor at all, and the Debtor PSP has to establish this before contracting (section 5.8 item 4).", "Annex VI still directs escalation to the Compliance and Adherence Committee, which the Core rulebook's change history records as having become the Dispute Resolution Committee in the 2019 version 1.1 rulebook dated 05 March 2020; the annex reference appears stale [Inference].", "The statements about the thirteen month exposure come from Annex VI of this rulebook and Annex V of the Core rulebook, and the EPC marks Annex V as informational rather than part of the rulebook.", "Article 61(1) of the Directive permits disapplication by agreement; what a Debtor PSP's national law actually allows, and on what terms, was not read for this record.", "Nothing here affects the debtor's contractual remedies against the creditor, which sit outside the scheme entirely (section 4.2)." ], "applies_to": "claims by a business debtor for reimbursement of a settled SEPA Direct Debit B2B collection", "caveat": "The common shorthand that B2B has no refund right is right about the scheme and wrong about the risk. The debtor's thirteen month claim under payment services law survives; what the scheme removes is the Debtor PSP's ability to pass that claim upstream. Anyone pricing B2B as the low-risk direct debit should be clear about which side of the transaction they are on.", "related": [ "sepa-sdd-b2b:finality", "sepa-sdd-b2b:return", "sepa-sdd-b2b:recall", "sepa-sdd-b2b:consumer-law", "sepa-sdd-b2b:liability", "sepa-sdd-b2b:decision-points", "sepa-sdd-b2b:participants" ], "basis": { "sources": "SEPA Direct Debit B2B Scheme Rulebook EPC222-07, 2025 version 1.1, date issued 05 October 2025 (marked Public), read for this record: sections 2.2 (nature of the scheme and access), 2.7 (consumer accounts debited in error), 4.2 (no refund right), 4.3.4 (refunds not provided for), 4.4 (refund defined only to exclude it), 4.8.39 AT-R004, 5.8 item 4 (Debtor PSP must establish non-consumer status and opt-out), Annex VI in full (introduction, sections 1, 2.1, 2.2 and steps 1 to 6). SDD Core Scheme Rulebook EPC016-06, 2025 version 1.1, Annex V items 1.1 to 1.4, which the EPC marks as informational, and section 0.2 change history for the Dispute Resolution Committee. Directive (EU) 2015/2366, consolidated text of 08 April 2024 on EUR-Lex, Articles 61(1), 71, 72, 73 and 89. EPC Guidance on Reason Codes for SDD R-transactions EPC173-14 version 8.0, 28 November 2024, section 3.", "confidence": "high" }, "currency": { "effective_since": "Long-standing", "effective_note": "The absence of a refund right and the inquiry procedure are in the 2025 version 1.1 rulebook, effective 05 October 2025, and predate it [Inference: EPC173-14 v8.0 of November 2024 already marks MD06 as Core only and covers the 2023 rulebooks]. Earlier editions were not read, so first effective dates are [Unverified]. Among the SDD B2B items in the 2026 change request consultation read for Orca's SEPA rail brief (docs/rails/sepa.md), none proposes introducing a refund (EPC011-26 version 1.0, 13 March 2026).", "source_edition": "SDD B2B Scheme Rulebook EPC222-07, 2025 version 1.1, date issued 05 October 2025; SDD Core Scheme Rulebook EPC016-06, 2025 version 1.1, Annex V; Directive (EU) 2015/2366 consolidated to 08 April 2024; EPC173-14 version 8.0", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-10/EPC222-07%202025%20SDD%20B2B%20Rulebook%20version%201.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC222-07 SDD B2B Scheme Rulebook 2025 version 1.1, Annex VI; EPC016-06 SDD Core Scheme Rulebook 2025 version 1.1, Annex V (marked not part of the rulebook, informational only)", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms precisely, word for word, the special-attention claim: B2B Annex VI section 1 states the Debtor PSP could be at risk during 13 months after the debit date when a debtor disputes a collection and asks for reimbursement under Articles 71, 72, 73 and 89 of the Payment Services Directive, and Core's Annex V items 1.2 and 1.3 (marked in capitals as not part of the rulebook, included for information only) state that the B2B debtor is entitled to a refund of an unauthorised collection from the Debtor PSP within 13 months, while the Debtor PSP is not allowed to recover that refund from the Creditor PSP, in contrast to Core where it is. Confirms the Inquiry Procedure is not an automatic refund procedure and does not guarantee settlement (Annex VI introduction), the exclusion of authorised-collection refunds and unauthorised refunds from scheme scope (Annex VI section 1 item ii, main rulebook 4.2/4.3.4/4.4), the B2B-specific D-1 presentation and D+3 return processing obligations (Annex VI section 1 items v-vi), the duplicate-collection presumption test and the amount/due-date-not-in-mandate reasoning for why creditor amount or date errors are authorised and cannot be refunded (Annex VI section 2.1), and the CAC (not yet renamed) escalation route the record already flags as possibly stale. Does not independently confirm Directive 2015/2366 Article 61(1); EUR-Lex remains unreachable. This directly and precisely confirms the special-attention question on the B2B 13 month unauthorised claim." } ] }, "rail_name": "SEPA Direct Debit B2B", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sdd-b2b:return", "id": "return", "rail": "sepa-sdd-b2b", "kind": "rail-fact", "facet": "return", "name": "Can a settled B2B collection be sent back, by whom, and by when?", "statement": "Yes, by the Debtor PSP, and quickly: the Return has to settle within three Inter-PSP Business Days of the Settlement Date, two days sooner than on SEPA Direct Debit Core. This is the only route by which money goes back to a B2B debtor after settlement, because the scheme has no refund, so the D+3 deadline is doing far more work here than its Core equivalent. The grounds are also wider in one specific way: the Debtor PSP is obliged to check every collection against the stored mandate data, so a mismatch is a Return reason, and two reasons exist here that Core does not have, one for a consumer account and one for a mandate the debtor never confirmed.", "details": [ { "label": "What a return is", "value": "The Debtor PSP pulling a collection out of the normal flow after the PSPs have settled. Before settlement the same act is a Reject. A debtor refusal dealt with after settlement becomes a Return.", "citation": "SDD B2B Scheme Rulebook EPC222-07, 2025 version 1.1, section 4.4", "rests_on": "rule" }, { "label": "The window", "value": "Three Inter-PSP Business Days from the Settlement Date, and it is the settlement of the Return that has to land inside them. The rulebook also asks for the Return as soon as possible and ideally on day D.", "citation": "SDD B2B Scheme Rulebook EPC222-07, 2025 version 1.1, sections 4.2 and 4.3.4, with section 4.6.4 PT-04.09 and PT-04.10", "rests_on": "rule" }, { "label": "Why the window matters more here", "value": "There is no refund on this scheme, so once the three days are gone the scheme offers the debtor nothing. On Core a missed Return still leaves eight weeks of refund.", "citation": "SDD B2B Scheme Rulebook EPC222-07, 2025 version 1.1, sections 4.2 and 4.3.4", "rests_on": "rule" }, { "label": "The grounds", "value": "Technical failures, an inability to take the collection such as a closed account, a dead debtor or an account that does not accept direct debits, or the debtor refusing the debit. The full set is the value range of attribute AT-R004, which for this scheme also covers a missing or unconfirmed mandate and a debtor account that turns out to be a consumer account.", "citation": "SDD B2B Scheme Rulebook EPC222-07, 2025 version 1.1, section 4.2, with section 4.8.39 AT-R004", "rests_on": "rule" }, { "label": "The Debtor PSP has to check, and that produces returns", "value": "Unlike Core, this scheme obliges the Debtor PSP to test every collection against the mandate data its debtor confirmed. Where nothing corresponds it acts on the debtor's standing instructions, which is how mandate mismatches become Rejects or Returns rather than debits.", "citation": "SDD B2B Scheme Rulebook EPC222-07, 2025 version 1.1, sections 4.2 and 4.6.4 PT-04.09, with section 4.6.4 PT-04.10", "rests_on": "rule" }, { "label": "Two reasons Core does not have", "value": "AC13 says the debtor account is a consumer account and exists only for B2B collections. MD01 covers a mandate that does not exist and, on this scheme, a B2B mandate the debtor has not yet confirmed or that the Debtor PSP could not obtain.", "citation": "EPC Guidance on Reason Codes for SDD R-transactions EPC173-14 version 8.0, 28 November 2024, section 3", "rests_on": "guidance" }, { "label": "How the money travels back", "value": "Debtor PSP to CSM to Creditor PSP, and the settlement runs the opposite way to the collection: the creditor's side is charged and the debtor's side credited. Rejects and Returns have to travel over the CSM that carried the collection unless the participants agreed on another route.", "citation": "SDD B2B Scheme Rulebook EPC222-07, 2025 version 1.1, section 4.6.4 PT-04.11, with section 4.4", "rests_on": "rule" }, { "label": "Who ends up out of pocket", "value": "The Creditor PSP owes the Debtor PSP the amount of any returned collection, with no fault to show. It recovers from its creditor under their terms, and where it cannot, the loss or the credit exposure is its own.", "citation": "SDD B2B Scheme Rulebook EPC222-07, 2025 version 1.1, sections 5.9.1 and 4.6.4 PT-04.12", "rests_on": "rule" }, { "label": "Late returns must not be processed", "value": "A Return that misses its settlement deadline has to be stopped on the creditor's side, whether by the Creditor PSP itself or by the CSM acting for it, and the Debtor PSP has to be told it was stopped.", "citation": "SDD B2B Scheme Rulebook EPC222-07, 2025 version 1.1, section 4.3.4", "rests_on": "rule" }, { "label": "The message that carries it", "value": "Dataset DS-05 goes out as the ISO 20022 Payment Return, pacs.004.001.09, at the 2019 message version, and the pre-settlement Reject as the payment status report pacs.002.001.10.", "citation": "SDD B2B Inter-PSP Implementation Guidelines EPC301-07 2025 version 1.0, sections 2.2 and 2.3", "rests_on": "rule" } ], "exceptions": [ "Debiting the debtor late gains no time; the Return still has to settle by D+3 Inter-PSP Business Days (section 4.3.2).", "A Creditor PSP may Reject a collection from its own creditor on grounds the two of them agreed rather than a scheme list (section 4.8.39 AT-R004).", "A CSM may Reject before the Debtor PSP sees the collection, for instance where a PSP is not registered under the BIC used or settlement failed (section 4.8.39 AT-R004).", "A Debtor PSP may also Reject where it reasonably believes the collection is erroneous, a ground the Core rulebook does not give in the same terms (section 4.4).", "Where national law such as data protection law forbids the precise code, the guidance allows the generic agent-generated code instead (EPC173-14 v8.0, section 3).", "AG01 must not be used where a B2B collection hits a consumer account; AC13 is the code for that (EPC173-14 v8.0, section 3).", "A participant adhering to B2B as Debtor PSP may apply B2B rules to Reject or Return a collection presented as a Core collection, and B2B Debtor PSPs are obliged to check the mandate status in that situation (section 2.7)." ], "applies_to": "post-settlement returns of SEPA Direct Debit B2B collections, initiated by the Debtor PSP", "caveat": "D+3 is not a softer version of D+5. On B2B it is the last exit. A Debtor PSP that discovers a mandate problem on day four has no scheme mechanism left, only the inquiry procedure, which the Creditor PSP must answer but need not pay.", "related": [ "sepa-sdd-b2b:finality", "sepa-sdd-b2b:refund", "sepa-sdd-b2b:recall", "sepa-sdd-b2b:messages", "sepa-sdd-b2b:liability", "sepa-sdd-b2b:decision-points", "sepa-sdd-b2b:hours" ], "basis": { "sources": "SEPA Direct Debit B2B Scheme Rulebook EPC222-07, 2025 version 1.1, date issued 05 October 2025 (marked Public), read for this record: sections 2.7 (erroneous use), 4.2 (returns, refusals, no refund right), 4.3.2 and 4.3.4 (windows and late presentation), 4.4 (definitions of reject, refusal and return), 4.6.4 PT-04.09 to PT-04.12 (checking, returning and credit risk), 4.8.39 AT-R004 (permitted reasons), 5.9.1 (no-fault reimbursement of returns). EPC Guidance on Reason Codes for SDD R-transactions EPC173-14 version 8.0, 28 November 2024, section 3. SDD B2B Inter-PSP Implementation Guidelines EPC301-07 2025 version 1.0, sections 2.2 and 2.3.", "confidence": "high" }, "currency": { "effective_since": "Long-standing", "effective_note": "The D+3 return window and the return process are in the 2025 version 1.1 rulebook, effective 05 October 2025, and predate it [Inference: EPC173-14 v8.0 of November 2024 covers the 2023 rulebooks and describes the same structure]. Earlier editions were not read, so first effective dates are [Unverified]. The 2026 change request consultation proposes a new SDD reject and return reason code for fraud for both schemes; it is a proposal and not adopted (EPC011-26 version 1.0, 13 March 2026, item 24).", "source_edition": "SDD B2B Scheme Rulebook EPC222-07, 2025 version 1.1, date issued 05 October 2025; EPC173-14 version 8.0; SDD B2B Inter-PSP Implementation Guidelines EPC301-07 2025 version 1.0", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-10/EPC222-07%202025%20SDD%20B2B%20Rulebook%20version%201.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC222-07 SDD B2B Scheme Rulebook 2025 version 1.1; EPC173-14 v8.0 Guidance on Reason Codes for SDD R-transactions", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms word for word that a Return settles by D+3 inter-PSP business days from the Settlement Date, two days shorter than Core's D+5 (4.3.4), and that unlike Core the Debtor PSP must check every collection against mandate data on defined attributes (AT-T001, AT-M001, AT-E005, AT-D001, AT-D002, AT-M006) and act on the debtor's standing instructions on a mismatch (PT-04.09). Confirms AC13 and MD01 as B2B-scoped codes against EPC173-14 v8.0 section 3, and the same no-fault reimbursement and credit-risk allocation pattern already confirmed for SDD Core (5.9.1, PT-04.11, PT-04.12). Did not verify the EPC301-07 Implementation Guidelines citation for the pacs.004.001.09/pacs.002.001.10 message identifiers, which were not read for this check. This directly supports the special-attention question comparing D+3 (B2B) against D+5 (Core) return settlement." } ] }, "rail_name": "SEPA Direct Debit B2B", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sdd-b2b:settlement", "id": "settlement", "rail": "sepa-sdd-b2b", "kind": "rail-fact", "facet": "settlement", "name": "Who settles a B2B collection, in what money, and when is settlement complete?", "statement": "The rulebook does not answer this, as on SEPA Direct Debit Core, and for the same reason: the scheme is written to be operated by whichever CSM a participant chooses, so settlement mechanics, cut-off times and the settlement asset are not scheme matters. The B2B differences are what settles afterwards. Only Rejects, Returns and Reversals travel back, because there are no Refunds, and with no Refund there is no refund compensation either. The attribute that carries that interest payment on Core does not exist in this rulebook. Everything comes back for the exact euro amount, through the same CSM that carried the collection out.", "details": [ { "label": "The scheme is deliberately separate from the infrastructure", "value": "One set of rules, operated by participants over whichever infrastructure they buy. The rulebook treats the choice of CSM and platform as a competitive market decision rather than something it settles.", "citation": "SDD B2B Scheme Rulebook EPC222-07, 2025 version 1.1, section 1.4", "rests_on": "rule" }, { "label": "What the CSM is responsible for", "value": "Taking collections from the Creditor PSP, passing them to the Debtor PSP unaltered, carrying exceptions back, arranging settlement between the two PSPs and running the risk procedures the service needs.", "citation": "SDD B2B Scheme Rulebook EPC222-07, 2025 version 1.1, section 3.3", "rests_on": "rule" }, { "label": "The expected settlement date", "value": "The Due Date, which is normally also the debit date, provided the conditions in section 4.3.1 hold. Where they do not, section 4.3.2 shifts the dates rather than waiving them.", "citation": "SDD B2B Scheme Rulebook EPC222-07, 2025 version 1.1, sections 4.3.1 and 4.3.2", "rests_on": "rule" }, { "label": "Settlement currency", "value": "Euro at every inter-PSP stage, exceptions included. Customer accounts may be in other currencies, and whoever converts does it inside its own books outside the scheme.", "citation": "SDD B2B Scheme Rulebook EPC222-07, 2025 version 1.1, section 2.5", "rests_on": "rule" }, { "label": "Only three things settle back, not four", "value": "The currency rule lists Rejects, Returns, Reversals and Revocations, and the routing rule at the end of the exception chapter covers Rejects and Returns. Refunds are missing from both lists because the scheme has none.", "citation": "SDD B2B Scheme Rulebook EPC222-07, 2025 version 1.1, sections 2.5 and 4.4", "rests_on": "rule" }, { "label": "Money coming back goes the same way it came", "value": "A Reject or Return has to clear and settle through the CSM that handled the collection, unless the two participants agreed otherwise, and any CSM serving this scheme has to support both.", "citation": "SDD B2B Scheme Rulebook EPC222-07, 2025 version 1.1, section 4.4, final paragraph", "rests_on": "rule" }, { "label": "How a return settles", "value": "The CSM hands the Return to the Creditor PSP and books it the other way: Creditor PSP debited, Debtor PSP credited.", "citation": "SDD B2B Scheme Rulebook EPC222-07, 2025 version 1.1, section 4.6.4 PT-04.11", "rests_on": "rule" }, { "label": "No refund compensation exists here", "value": "On Core an interest compensation travels with every Refund, in attribute AT-R006. The B2B attribute list skips straight from AT-R005 to AT-R007, so that payment has no carrier and no rule in this scheme.", "citation": "SDD B2B Scheme Rulebook EPC222-07, 2025 version 1.1, sections 4.8.40 AT-R005 and 4.8.41 AT-R007, compared with SDD Core Scheme Rulebook EPC016-06, 2025 version 1.1, section 4.8.41 AT-R006", "rests_on": "rule" }, { "label": "Cut-off times are not scheme rules", "value": "The rulebook counts in whole days only. Times of day are agreed between each CSM and its participants and between PSPs and their business customers.", "citation": "SDD B2B Scheme Rulebook EPC222-07, 2025 version 1.1, section 4.3.3", "rests_on": "rule" }, { "label": "Interchange fees on this rail", "value": "Union law bars a multilateral interchange fee on the direct debit itself and allows one on R-transactions only on the strict cost conditions in Article 8(2). The rulebook leaves such arrangements to participants within that law, and the amount the Debtor PSP takes travels in attribute AT-R007.", "citation": "Regulation (EU) No 260/2012 Article 8(1) and 8(2), with SDD B2B Scheme Rulebook EPC222-07, 2025 version 1.1, sections 5.13 and 4.8.41 AT-R007", "rests_on": "law" } ], "exceptions": [ "Where the inquiry procedure ends with the Creditor PSP agreeing to reimburse, the two PSPs settle it bilaterally, and the annex offers a Reversal, a Return, a transfer of funds or anything else they agree; there is no defined settlement path (Annex VI, step 3).", "The rulebook is silent on settlement finality under Directive 98/26/EC, since that depends on the CSM in use; no CSM document was read [Unverified].", "Where both accounts sit at one institution or inside one group the CSM may be internal and nothing settles externally (section 3.1).", "When the creditor is credited is outside the scheme (section 4.3.4).", "If the creditor's account cannot be debited for a Reject or Return, the Creditor PSP carries it or writes it off and may not charge it back to the Debtor PSP (section 4.6.4 PT-04.12).", "Whether a CSM applies different cut-offs to B2B than to Core is a CSM matter and was not checked." ], "applies_to": "inter-PSP settlement of SEPA Direct Debit B2B collections and of the rejects, returns and reversals that follow them", "caveat": "The absence of refund compensation is the tell. On Core the interest cost of a late unwind is priced into the scheme; on B2B there is nothing to price, because after D+3 the scheme provides no unwind at all.", "related": [ "sepa-sdd-b2b:finality", "sepa-sdd-b2b:hours", "sepa-sdd-b2b:return", "sepa-sdd-b2b:recall", "sepa-sdd-b2b:limits", "sepa-sdd-b2b:participants" ], "basis": { "sources": "SEPA Direct Debit B2B Scheme Rulebook EPC222-07, 2025 version 1.1, date issued 05 October 2025 (marked Public), read for this record: sections 1.4 (separation of scheme from infrastructure), 2.5 (currency), 3.1 (actors and CSMs), 3.3 (CSM responsibilities), 4.3.1 to 4.3.4 (key dates, cut-off times, time cycle), 4.4 (exception handling and the CSM routing rule), 4.6.4 PT-04.11 and PT-04.12, 4.8.40 AT-R005 and 4.8.41 AT-R007, 5.13 (interchange fees), Annex VI step 3. SDD Core Scheme Rulebook EPC016-06, 2025 version 1.1, section 4.8.41 AT-R006, for the comparison. Regulation (EU) No 260/2012, consolidated text of 08 April 2024 on EUR-Lex, Article 8. No CSM document was read.", "confidence": "high" }, "currency": { "effective_since": "Long-standing", "effective_note": "The provisions cited are in the 2025 version 1.1 rulebook, effective 05 October 2025, and predate it [Inference]. Earlier editions were not read, so first effective dates are [Unverified].", "source_edition": "SDD B2B Scheme Rulebook EPC222-07, 2025 version 1.1, date issued 05 October 2025; Regulation (EU) No 260/2012 consolidated to 08 April 2024", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-10/EPC222-07%202025%20SDD%20B2B%20Rulebook%20version%201.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC222-07 SDD B2B Scheme Rulebook 2025 version 1.1", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the scheme/infrastructure separation (1.4), CSM responsibilities (3.3), Due Date as expected settlement with 4.3.2 shifting rather than waiving mismatched dates (4.3.1, 4.3.2), euro-only settlement (2.5), the CSM routing rule for Rejects and Returns only, with no Refund in either list (4.4), return settlement direction (PT-04.11), cut-off times left to CSMs (4.3.3), and, precisely, that the attribute list jumps from AT-R005 (Settlement Date) directly to AT-R007 (Interchange Fee) with no AT-R006 interest-compensation attribute, confirmed by direct inspection of sections 4.8.40 and 4.8.41 (no AT-R006 entry exists in this rulebook, unlike Core's AT-R006). Does not independently confirm Regulation 260/2012 Article 8(1)-(2); EUR-Lex remains unreachable." } ] }, "rail_name": "SEPA Direct Debit B2B", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sdd-core:consumer-law", "id": "consumer-law", "rail": "sepa-sdd-core", "kind": "rail-fact", "facet": "consumer-law", "name": "What consumer protection attaches to a Core direct debit, and where does it come from?", "statement": "Core is the consumer scheme of the two SEPA direct debits, and most of what protects the consumer is Union law rather than the rulebook. The refund rights, the ceiling on a payer's loss from an unauthorised debit, the duty to tell the customer what it is getting into and the right to complain all come from the Payment Services Directive as each Member State transposed it. The SEPA Regulation adds the controls a payer may put on its own account and the reachability duty that makes Core work across borders at all, and that duty is written to cover only direct debits that are available to consumers. The rulebook then carries those obligations into the contract between participants, and adds one protection of its own: fourteen calendar days of notice before the money goes.", "details": [ { "label": "Consumers are in scope of this scheme", "value": "Core is built for private individuals as well as businesses, and the rulebook lists the eight week no-questions-asked refund among the things a debtor gets out of it.", "citation": "SDD Core Scheme Rulebook EPC016-06, 2025 version 1.1, sections 1.6.2 and 2.2", "rests_on": "rule" }, { "label": "Cross-border reachability is a consumer-scheme duty", "value": "A payer's PSP that is reachable for national direct debits has to be reachable for direct debits started from any other Member State under the rules of a Union-wide scheme. That obligation is written to apply only where the scheme makes direct debits available to consumers as payers, which is Core and not B2B.", "citation": "Regulation (EU) No 260/2012 Article 3(2) and 3(3)", "rests_on": "law" }, { "label": "The two refund rights", "value": "Eight weeks with no reason needed, and thirteen months where the debtor says the collection was never authorised. Both sit in the Payment Services Directive and are carried into the rulebook.", "citation": "Directive (EU) 2015/2366 Articles 76(1), 77(1) and 71(1), with SDD Core Scheme Rulebook EPC016-06, 2025 version 1.1, section 4.3.4", "rests_on": "law" }, { "label": "The ceiling on a payer's own loss", "value": "A payer may be left with up to 50 euro of the loss from a lost, stolen or misappropriated payment instrument, and nothing at all where the loss was undetectable before the payment or was caused by the PSP's own side, or where the PSP did not require strong customer authentication. A payer who acted fraudulently, or failed its obligations with intent or gross negligence, carries the lot.", "citation": "Directive (EU) 2015/2366, Article 74(1) to (3)", "rests_on": "law" }, { "label": "Who has to prove what", "value": "If the customer denies authorising a payment, the burden is on the PSP to show it was authenticated, recorded accurately, entered in the accounts and unaffected by any breakdown of its own. Pointing at the use of a payment instrument is not enough on its own; the PSP has to produce evidence of fraud or gross negligence.", "citation": "Directive (EU) 2015/2366, Article 72", "rests_on": "law" }, { "label": "Controls the debtor can put on its own account", "value": "Union law entitles a payer to cap direct debits by amount or frequency, to block them altogether, to block named creditors or to allow only named ones. The rulebook makes the Debtor PSP offer those services.", "citation": "Regulation (EU) No 260/2012 Article 5(3)(d), with SDD Core Scheme Rulebook EPC016-06, 2025 version 1.1, section 4.2", "rests_on": "law" }, { "label": "What the debtor has to be told, and when", "value": "Before the first direct debit hits the account, the Debtor PSP has to put the risks, the respective rights and obligations of all three parties and the safe use of direct debits in front of the debtor, drawing on the risk management annex for the security part. Separately the creditor owes the debtor a pre-notification of the amount and date, at least fourteen calendar days ahead unless the two of them agreed on another timeline.", "citation": "SDD Core Scheme Rulebook EPC016-06, 2025 version 1.1, section 5.8 item 5 and section 4.3.4", "rests_on": "rule" }, { "label": "A mandate copy on request", "value": "Where a debtor asks about a collection that has arrived, its PSP has to go after the relevant information and a copy of the mandate from the Creditor PSP without delay, and pass on what it gets without undue delay.", "citation": "SDD Core Scheme Rulebook EPC016-06, 2025 version 1.1, section 5.8 item 11", "rests_on": "rule" }, { "label": "Charges", "value": "Each side pays its own PSP and neither pays the other's, both as a scheme principle and under Union law. A payee may not surcharge for payment services that Regulation (EU) No 260/2012 covers, which includes this scheme.", "citation": "SDD Core Scheme Rulebook EPC016-06, 2025 version 1.1, section 4.3.5, with Directive (EU) 2015/2366 Article 62(2) and 62(4)", "rests_on": "law" }, { "label": "Where a refused refund goes", "value": "A PSP that turns down a refund request has to give its reasons within ten business days and point the payer at the complaint and out-of-court redress bodies Member States set up under Articles 99 to 102 of the Directive.", "citation": "Directive (EU) 2015/2366, Article 77(2)", "rests_on": "law" }, { "label": "Small firms may count as consumers", "value": "Member States are free to extend the protections of Title IV to microenterprises on the same terms as to consumers, so whether a given small business debtor has consumer-grade rights depends on where it is.", "citation": "Directive (EU) 2015/2366, Article 61(3)", "rests_on": "law" } ], "exceptions": [ "The scheme's geography is wider than Union law's. Countries and territories in EPC409-09 that are outside the EEA are not bound by the Payment Services Directive or the SEPA Regulation, and the rulebook covers that gap with a contractual promise of substantially equivalent performance rather than with the law itself (section 5.15).", "The Directive binds as transposed, so the national text and not the Directive is what a debtor actually holds; no national transposition was read for this record.", "A payment service user that is not a consumer may agree with its PSP that several of these articles do not apply, and may agree different time limits than Article 71 (Directive (EU) 2015/2366 Article 61(1)).", "Consumers cannot use the B2B scheme at all: a Debtor PSP may not offer it to one, and the debtor has to be a business whose national law lets it give up the statutory refund right. That is why consumer protection differs so sharply between the two schemes.", "Member States may require more favourable refund rights for direct debits in currencies other than euro; this scheme is euro only, so that option does not reach it (Directive (EU) 2015/2366 Article 76(4)).", "Annex III of the rulebook, which carries the detail of the information duties on secure use, was referenced but not read for this record.", "Regulation (EU) 2024/886 added instant payment obligations including verification of payee; those attach to credit transfers and do not give a direct debit debtor a name-check right." ], "applies_to": "consumers and other payment service users debited under the SEPA Direct Debit Core scheme, and the PSPs that serve them", "caveat": "The consumer's strongest protection on this rail is not a fraud rule, it is the eight week refund, which needs no allegation and no evidence. Anything that models Core consumer risk on card chargeback grounds or on a fraud test has picked the wrong mechanism.", "related": [ "sepa-sdd-core:refund", "sepa-sdd-core:limits", "sepa-sdd-core:liability", "sepa-sdd-core:participants", "sepa-sdd-core:finality" ], "basis": { "sources": "SEPA Direct Debit Core Scheme Rulebook EPC016-06, 2025 version 1.1, date issued 05 October 2025 (marked Public), read for this record: sections 1.6.2 (debtor advantages), 2.2 (nature of the scheme), 4.2 (debtor controls), 4.3.4 (pre-notification and refund windows), 4.3.5 (charging principles), 5.8 (Debtor PSP obligations, items 5, 9, 10 and 11), 5.15 (application of EU legislation between participants). Directive (EU) 2015/2366, consolidated text of 08 April 2024 on EUR-Lex: Articles 61(1) and (3), 62(2) and (4), 71(1), 72, 74, 76(1) and (4), 77(1) and (2). Regulation (EU) No 260/2012, consolidated text of 08 April 2024: Articles 3(2) and (3), 5(3)(d). Annex III of the rulebook and all national transpositions were not read.", "confidence": "high" }, "currency": { "effective_since": "Long-standing", "effective_note": "Directive (EU) 2015/2366 applied from 13 January 2018 and the SEPA Regulation from 2012, as amended in 2014 and again by Regulation (EU) 2024/886. The rulebook provisions cited are in the 2025 version 1.1 edition, effective 05 October 2025. National transpositions of the Directive carry their own dates, which were not checked [Unverified]. The successor payment services package was not read and its status as of September 2026 is [Unverified].", "source_edition": "SDD Core Scheme Rulebook EPC016-06, 2025 version 1.1, date issued 05 October 2025; Directive (EU) 2015/2366 consolidated to 08 April 2024; Regulation (EU) No 260/2012 consolidated to 08 April 2024", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "rail_name": "SEPA Direct Debit Core", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": null, "effective_status": "draft", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sdd-core:decision-points", "id": "decision-points", "rail": "sepa-sdd-core", "kind": "rail-fact", "facet": "decision-points", "name": "Where do the Core rules stop deciding and hand the outcome to a bank or a person?", "statement": "More often than the rulebook's precision suggests. The Debtor PSP holds nearly all of it: whether to bounce a collection at all, whether a refusal gets dealt with before or after settlement, whether to debit late instead of returning, and, for an unauthorised claim, whether the debtor gets its money back. That last decision is explicitly final for every participant in the scheme, and the rulebook offers only recommended guidance on how to reach it. On the other side the Creditor PSP decides whether to offer reversals at all, how closely to police a creditor that uses them too often, and whether to chase a creditor for an unpaid return or absorb it. This is Orca's reading of where the text leaves judgment open, so it caps at medium confidence.", "details": [ { "label": "Whether to bounce a collection at all", "value": "The rulebook says the Debtor PSP may Reject before settlement and may Return after it. Nothing compels either, and the scheme asks it to check nothing about an incoming collection, so both the trigger and the threshold are the PSP's own.", "citation": "SDD Core Scheme Rulebook EPC016-06, 2025 version 1.1, section 4.2, with section 4.6.4 PT-04.10", "rests_on": "rule" }, { "label": "Whether a refusal lands as a reject or a return", "value": "A debtor's refusal is handled on the terms agreed between debtor and PSP. The rulebook expresses a preference for dealing with it before settlement, which produces a Reject, but leaves the choice with the Debtor PSP, and handling it later makes it a Return instead.", "citation": "SDD Core Scheme Rulebook EPC016-06, 2025 version 1.1, section 4.4", "rests_on": "rule" }, { "label": "Whether to debit late instead of returning", "value": "Where the account cannot be debited on the Due Date, for want of funds or because agreed checks are still running, the Debtor PSP may debit later. It has to keep the D+5 return deadline in view, but whether to wait or to give up and Return is its call.", "citation": "SDD Core Scheme Rulebook EPC016-06, 2025 version 1.1, section 4.3.2", "rests_on": "rule" }, { "label": "Whether an unauthorised refund claim succeeds", "value": "The Debtor PSP examines the claim and decides. Once it has, no participant in the scheme can reopen the outcome, and the help the rulebook gives on reaching it is expressly recommended guidance rather than a test: compare the signed mandate with the mandate data on the collection, check the mandate was alive and had not lapsed.", "citation": "SDD Core Scheme Rulebook EPC016-06, 2025 version 1.1, section 4.6.4 PT-04.21 and PT-04.24", "rests_on": "rule" }, { "label": "What to do when nobody answers", "value": "Thirty calendar days after the debtor claimed, with no reply from the Creditor PSP, the Debtor PSP is free to settle the matter on the debtor's evidence alone and in whatever way it thinks right. That is discretion written into the text.", "citation": "SDD Core Scheme Rulebook EPC016-06, 2025 version 1.1, section 4.6.4 PT-04.24", "rests_on": "rule" }, { "label": "Whether the creditor concedes or fights", "value": "On receiving a forwarded claim the creditor chooses: accept it, or dispute it and produce the mandate copy, or, for the two request types that skip the copy, dispute it with whatever supporting information it has. Nothing in the scheme grades that evidence.", "citation": "SDD Core Scheme Rulebook EPC016-06, 2025 version 1.1, section 4.6.4 PT-04.23", "rests_on": "rule" }, { "label": "Whether reversals are available to a creditor at all", "value": "A Creditor PSP is not obliged to offer the reversal facility, so whether a creditor can undo its own erroneous collection depends on its bank's product decision rather than on the scheme.", "citation": "SDD Core Scheme Rulebook EPC016-06, 2025 version 1.1, section 4.4", "rests_on": "rule" }, { "label": "How hard to police a creditor using reversals", "value": "Creditor PSPs are told to watch reversal use carefully so the exception process is not abused for other purposes. What counts as too much, and what follows, the rulebook does not say.", "citation": "SDD Core Scheme Rulebook EPC016-06, 2025 version 1.1, section 4.6.5 PT-05.02", "rests_on": "rule" }, { "label": "Whether to chase the creditor or eat the loss", "value": "Where the creditor's account cannot be debited for a Reject or Return, the rulebook states the outcome as either a credit risk to be recovered from the creditor or a loss the Creditor PSP takes. Which of the two it becomes is a commercial judgment, since charging it back to the Debtor PSP is barred.", "citation": "SDD Core Scheme Rulebook EPC016-06, 2025 version 1.1, section 4.6.4 PT-04.12", "rests_on": "rule" }, { "label": "Which reason code to send", "value": "The guidance acknowledges that a single R-transaction can have more than one reason, that the level of checking depends on the Debtor PSP's own risk and know-your-customer policies, and that whether to test the sequence type or the creditor identifier at all is the Debtor PSP's decision. So the code a creditor receives partly reflects a policy choice, not only a fact.", "citation": "EPC Guidance on Reason Codes for SDD R-transactions EPC173-14 version 8.0, 28 November 2024, section 2", "rests_on": "guidance" }, { "label": "Whether the creditor gets told the real reason", "value": "Where national law such as data protection law blocks the precise code, the guidance allows a generic agent-generated code instead. Judging whether local law blocks it, and reaching for the generic code, sits with the Debtor PSP.", "citation": "EPC Guidance on Reason Codes for SDD R-transactions EPC173-14 version 8.0, 28 November 2024, section 3", "rests_on": "guidance" }, { "label": "How much notice the debtor really gets", "value": "Fourteen calendar days of pre-notification is the default, and the debtor and creditor may agree another timeline. That agreement is between customers, invisible to both PSPs, and it can shorten the only warning a debtor gets.", "citation": "SDD Core Scheme Rulebook EPC016-06, 2025 version 1.1, section 4.3.4", "rests_on": "rule" }, { "label": "Which infrastructure, and what time of day", "value": "Participants choose their CSM commercially, and cut-off times are agreed between the CSM and its participants and between PSPs and their customers. Two participants on the same scheme can therefore have materially different operating deadlines.", "citation": "SDD Core Scheme Rulebook EPC016-06, 2025 version 1.1, sections 1.4 and 4.3.3", "rests_on": "rule" } ], "exceptions": [ "The eight week refund is not a decision point. Inside that window the Debtor PSP has no discretion and must pay without asking why (section 4.6.4 PT-04.15).", "Handling an incoming Reversal is not a decision point for the Debtor PSP either; it is mandatory, and it performs no checks (section 4.4 and section 4.6.5 PT-05.04).", "Judgment a Debtor PSP exercises towards its own debtor is constrained by payment services law even where the scheme is silent, in particular the duty to refund an unauthorised transaction by the end of the next business day (Directive (EU) 2015/2366 Article 73(1)).", "Decisions taken inside Annex III risk management, and the EPC scheme management and dispute processes in Annex II, are not described here because neither annex was read.", "This record is Orca's reading of where the text leaves judgment open, not a list the EPC publishes, and it caps at medium confidence for that reason." ], "applies_to": "points in the SEPA Direct Debit Core rules where the outcome depends on a participant's judgment rather than on the rule", "caveat": "The decision that costs the most money is the one with the least guidance: whether an unauthorised claim succeeds. The rulebook gives a Debtor PSP recommended guidance, thirty days and the last word, and no appeal exists inside the scheme.", "related": [ "sepa-sdd-core:return", "sepa-sdd-core:refund", "sepa-sdd-core:recall", "sepa-sdd-core:liability", "sepa-sdd-core:limits", "sepa-sdd-core:hours" ], "basis": { "sources": "SEPA Direct Debit Core Scheme Rulebook EPC016-06, 2025 version 1.1, date issued 05 October 2025 (marked Public), read for this record: sections 1.4, 4.2, 4.3.2, 4.3.3, 4.3.4, 4.4, 4.6.4 PT-04.10, PT-04.12, PT-04.15, PT-04.21, PT-04.23 and PT-04.24, 4.6.5 PT-05.02 and PT-05.04. EPC Guidance on Reason Codes for SDD R-transactions EPC173-14 version 8.0, 28 November 2024, sections 2 and 3. Directive (EU) 2015/2366, consolidated text of 08 April 2024 on EUR-Lex, Article 73(1). Annexes II and III of the rulebook were not read. Which provisions count as decision points is Orca's reading, and each line cites the provision that leaves the judgment open.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_note": "The provisions cited are in the 2025 version 1.1 rulebook, effective 05 October 2025, and in EPC173-14 version 8.0 of 28 November 2024. Earlier editions were not read, so first effective dates are [Unverified]. This facet caps at medium confidence by design, because it is a reading of the rules rather than a statement of them.", "source_edition": "SDD Core Scheme Rulebook EPC016-06, 2025 version 1.1, date issued 05 October 2025; EPC173-14 version 8.0", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-10/EPC016-06%202025%20SDD%20Core%20Rulebook%20version%201.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC016-06 SDD Core Scheme Rulebook 2025 version 1.1; EPC173-14 v8.0 Guidance on Reason Codes for SDD R-transactions", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the Debtor PSP's Reject/Return discretion and no duty to check incoming collections (4.2, PT-04.10), the reject-or-return timing choice on a refusal (4.4), the debit-late-or-return choice within the D+5 deadline (4.3.2), the final and unappealable unauthorised-claim decision with only recommended guidance (PT-04.21, PT-04.24), the 30 calendar day default-if-no-answer rule (PT-04.24), the creditor's accept-or-dispute choice (PT-04.23), reversal being optional to offer and the watch-for-abuse instruction (4.4, PT-05.02), the credit-risk-or-loss commercial choice on an unpaid return (PT-04.12), the 14 day pre-notification default (4.3.4), and CSM/cut-off choices (1.4, 4.3.3). Confirms EPC173-14 v8.0 sections 2 and 3 on multi-reason codes, risk-based checking discretion, and the generic-code substitution for data protection. Does not independently confirm Directive 2015/2366 Article 73(1); EUR-Lex remains unreachable." } ] }, "rail_name": "SEPA Direct Debit Core", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sdd-core:finality", "id": "finality", "rail": "sepa-sdd-core", "kind": "rail-fact", "facet": "finality", "name": "When does a SEPA Direct Debit Core collection become final, and can it be reversed?", "statement": "Inter-PSP settlement happens on the Due Date, and on this rail that buys the creditor very little. Five separate people can still undo the payment afterwards. The debtor can head it off before Settlement. The Debtor PSP can push it back for five Inter-PSP Business Days after the Settlement Date. The creditor can reverse it inside the same five days. The debtor can demand the money back with no reason at all for eight weeks, and can still claim for thirteen months by saying the collection was never authorised. So a Core collection is not final against the debtor for thirteen months, and even that clock can be stopped where the Debtor PSP never gave the debtor the transaction information payment services law requires.", "details": [ { "label": "What the settlement event is", "value": "Three dates normally land on the same day: the day the money is owed, the day the two PSPs settle and the day the debtor is debited. That only holds if the Due Date on the collection is scheme-compliant, both PSPs can settle that day, the CSM is open that day and the Debtor PSP is willing to debit.", "citation": "SDD Core Scheme Rulebook EPC016-06, 2025 version 1.1, section 4.3.1", "rests_on": "rule" }, { "label": "Who settles, and where", "value": "Nothing settles inside the scheme. A CSM sits between the two PSPs, moves the collection across and arranges for them to settle. Which CSM that is, and how it settles, the rulebook does not decide.", "citation": "SDD Core Scheme Rulebook EPC016-06, 2025 version 1.1, section 3.3", "rests_on": "rule" }, { "label": "The legal moment of receipt", "value": "For the purposes of payment services law, the collection counts as received on the Due Date. The rulebook attributes that treatment to Article 78 of the Payment Services Directive.", "citation": "SDD Core Scheme Rulebook EPC016-06, 2025 version 1.1, section 4.2, with Directive (EU) 2015/2366 Article 78", "rests_on": "law" }, { "label": "Stopped before settlement", "value": "A debtor who does not want a particular collection paid can tell its own PSP so, needs no reason, and the PSP should deal with it before the PSPs settle, which turns the collection into a Reject. A debtor can also shut its account to direct debits altogether.", "citation": "SDD Core Scheme Rulebook EPC016-06, 2025 version 1.1, section 4.4 (Refusals) and section 4.2", "rests_on": "rule" }, { "label": "The payer's revocation right in law", "value": "Payment services law lets a payer withdraw a direct debit order up to the close of the business day before the agreed debit day. Refund rights are unaffected by whether the payer used that window.", "citation": "Directive (EU) 2015/2366, Article 80(3)", "rests_on": "law" }, { "label": "Undone after settlement by the debtor's side", "value": "Once settled, the Debtor PSP can still send the collection back. The deadline bites on the settlement of that Return: five Inter-PSP Business Days counted from the Settlement Date of the collection. A refusal the Debtor PSP deals with too late to Reject becomes a Return instead.", "citation": "SDD Core Scheme Rulebook EPC016-06, 2025 version 1.1, sections 4.2, 4.3.4 and 4.4", "rests_on": "rule" }, { "label": "Undone after settlement by the creditor's side", "value": "The creditor's own unwind, the Reversal, opens on the Settlement Date and closes five Inter-PSP Business Days after the Due Date asked for in the collection. Anything later the Creditor PSP and the CSM must refuse to process, and they have to tell the Debtor PSP they did.", "citation": "SDD Core Scheme Rulebook EPC016-06, 2025 version 1.1, section 4.3.4, with section 4.6.5 PT-05.01 to PT-05.03", "rests_on": "rule" }, { "label": "Undone on the debtor's demand, without a reason, for eight weeks", "value": "For eight weeks counted from the debit date, any Core collection can be clawed back by the debtor simply by asking. The Debtor PSP does not get to ask why.", "citation": "SDD Core Scheme Rulebook EPC016-06, 2025 version 1.1, section 4.3.4, with section 4.6.4 PT-04.15", "rests_on": "rule" }, { "label": "Undone for thirteen months if the collection was not authorised", "value": "Past eight weeks the debtor needs a ground, and the ground is that no valid mandate covered the collection. That claim has to reach the Debtor PSP inside thirteen months of the debit date. The rulebook ties the limit to Article 71 of the Payment Services Directive.", "citation": "SDD Core Scheme Rulebook EPC016-06, 2025 version 1.1, section 4.3.4, with Directive (EU) 2015/2366 Article 71(1)", "rests_on": "law" }, { "label": "Finality does not settle the underlying dispute", "value": "Getting the money back does not decide who was right. The debtor still has to sort the bill out with the creditor, and the refund is not evidence either way. Those arguments sit outside the scheme entirely.", "citation": "SDD Core Scheme Rulebook EPC016-06, 2025 version 1.1, section 4.2", "rests_on": "rule" } ], "exceptions": [ "A Due Date that is not an Inter-PSP Business Day pushes settlement to the next one, and a Settlement Date that is not a Banking Business Day at the Debtor PSP pushes the debit to the next one (section 4.3.2).", "A Debtor PSP that cannot debit on the Due Date may debit later, but it gets no extra time: the Return still has to settle by D+5 Inter-PSP Business Days (section 4.3.2).", "A Return or Refund that arrives for settlement after its deadline has to be blocked by the Creditor PSP or the CSM, with the Debtor PSP told (section 4.3.4).", "The thirteen month cut-off in Article 71(1) of the Payment Services Directive falls away entirely if the PSP never supplied the transaction information Title III of that Directive requires.", "The Payment Services Directive binds as each Member State transposed it, and the scheme reaches countries outside the EEA where it does not bind at all; section 5.15 makes those participants promise to perform substantially equivalent obligations, which is a contract term rather than the law.", "Conversion between euro and another currency happens inside one of the PSPs and is outside the scheme, so a debtor on a non-euro account can be repaid the full euro amount and still lose money on the round trip (section 2.5)." ], "applies_to": "SEPA Direct Debit Core collections in euro, between a Creditor PSP and a Debtor PSP that each adhere to the Core scheme, anywhere in the SEPA geographical scope set by EPC409-09", "caveat": "Do not tell a creditor that a settled Core collection is money in hand. It is money on loan for eight weeks. Treasury and credit models that treat a Core direct debit as final on the Due Date are wrong by at least fifty six days, and by thirteen months where the mandate can be questioned.", "related": [ "sepa-sdd-core:settlement", "sepa-sdd-core:hours", "sepa-sdd-core:return", "sepa-sdd-core:recall", "sepa-sdd-core:refund", "sepa-sdd-core:liability", "sepa-sdd-core:consumer-law", "sepa-sdd-core:decision-points" ], "basis": { "sources": "SEPA Direct Debit Core Scheme Rulebook EPC016-06, 2025 version 1.1, date issued 05 October 2025 (marked Public), read for this record: sections 2.5 (currency), 3.3 (CSMs), 4.2 (collections, receipt, returns, refunds), 4.3.1 to 4.3.4 (key dates and the time cycle), 4.4 (exception handling definitions), 4.6.4 PT-04.15 and PT-04.20 (refund requests), 4.6.5 PT-05.01 to PT-05.03 (reversals), 5.15 (application of EU legislation between participants). Directive (EU) 2015/2366 (PSD2), consolidated text of 08 April 2024 on EUR-Lex, read for this record: Articles 71(1), 78 and 80(3).", "confidence": "high" }, "currency": { "effective_since": "Long-standing", "effective_note": "The provisions cited are in the 2025 version 1.1 rulebook, effective 05 October 2025. The eight week and thirteen month windows and the D+5 return window are long-standing features of the scheme and predate this edition [Inference: EPC173-14 v8.0, published November 2024, describes the same windows]. Earlier rulebook editions were not read for this record, so the date each provision first took effect is [Unverified]. The next rulebook version is due for publication in November 2026 and expected to take effect in November 2027.", "source_edition": "SDD Core Scheme Rulebook EPC016-06, 2025 version 1.1, date issued 05 October 2025; Directive (EU) 2015/2366 consolidated to 08 April 2024", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-10/EPC016-06%202025%20SDD%20Core%20Rulebook%20version%201.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC016-06 SDD Core Scheme Rulebook 2025 version 1.1", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the standard relation between key dates aligning debit/settlement/due date (4.3.1), the scheme naming no CSM or settlement model (3.3), pre-settlement refusal turning a late-handled case into a Return (4.2, 4.4), the D+5 inter-PSP business day Return deadline already confirmed for the return fact (4.3.4), the Reversal window opening on settlement and closing D+5 end to end from PT-05.01 to PT-05.03 (4.6.5), the eight week no-questions-asked and thirteen month unauthorised-claim windows already confirmed for the refund fact (4.3.4), and that a refund does not resolve the underlying debtor-creditor dispute (4.2). Does not independently confirm Directive 2015/2366 Article 78, Article 80(3) or Article 71(1); EUR-Lex remains unreachable." } ] }, "rail_name": "SEPA Direct Debit Core", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sdd-core:hours", "id": "hours", "rail": "sepa-sdd-core", "kind": "rail-fact", "facet": "hours", "name": "When is the Core scheme open, and which calendar do its deadlines run on?", "statement": "This rail is measured in days, never in hours. The rulebook says as much and hands the intraday question to each CSM and its participants. Three calendars then run side by side. Deadlines between the two PSPs count Inter-PSP Business Days, which are TARGET days off the calendar the European Central Bank publishes. Deadlines on work inside one PSP count Banking Business Days, meaning the days that particular institution is open. Windows that face the customer, such as pre-notification and the eight week refund, count plain calendar days. Pick the wrong calendar and the deadline moves by days.", "details": [ { "label": "The scheme has no intraday clock", "value": "Every deadline in the rulebook is a whole number of days. What time of day a file has to arrive is agreed between each CSM and its participants, and between each PSP and its creditors or debtors.", "citation": "SDD Core Scheme Rulebook EPC016-06, 2025 version 1.1, section 4.3.3", "rests_on": "rule" }, { "label": "Inter-PSP Business Day", "value": "A day PSPs are generally open to deal with each other. The scheme identifies them from the TARGET Days Calendar, a long-term calendar of closing days in use since 2002 and published by the European Central Bank.", "citation": "SDD Core Scheme Rulebook EPC016-06, 2025 version 1.1, section 4.3", "rests_on": "rule" }, { "label": "Banking Business Day", "value": "A day one named participant is open for the business a SEPA Direct Debit needs. It is institution by institution, so two participants can be on different Banking Business Days at the same moment.", "citation": "SDD Core Scheme Rulebook EPC016-06, 2025 version 1.1, section 4.3", "rests_on": "rule" }, { "label": "Calendar Day", "value": "Every day of the year, weekends and holidays included. Pre-notification, the eight week refund window and the thirteen month unauthorised transaction window all run on this calendar.", "citation": "SDD Core Scheme Rulebook EPC016-06, 2025 version 1.1, sections 4.3 and 4.3.4", "rests_on": "rule" }, { "label": "Which deadline uses which calendar, inter-PSP", "value": "Counted in Inter-PSP Business Days: presentation to the Debtor PSP at D-1; settlement of a Return at D+5 from the collection's Settlement Date; a Reversal from the Settlement Date through five days after the Due Date; settlement of an eight week Refund two days after that window closes.", "citation": "SDD Core Scheme Rulebook EPC016-06, 2025 version 1.1, section 4.3.4", "rests_on": "rule" }, { "label": "Which deadline uses which calendar, customer facing", "value": "Counted in calendar days: pre-notification 14 days ahead of the Due Date unless debtor and creditor agreed otherwise; the collection not passed to the Creditor PSP more than 14 days ahead either; the no-questions-asked Refund within eight weeks of the debit date; an unauthorised transaction claim within thirteen months of it.", "citation": "SDD Core Scheme Rulebook EPC016-06, 2025 version 1.1, section 4.3.4", "rests_on": "rule" }, { "label": "Which deadline uses which calendar, inside the unauthorised refund investigation", "value": "Mixed, which is where teams trip. The Debtor PSP gets 4 Banking Business Days to pass the claim along, the Creditor PSP 3 to hand it to the creditor, the creditor 7 to answer. The Debtor PSP must decide once the answer arrives or, failing that, 30 calendar days after the debtor claimed, and settlement follows within 4 Inter-PSP Business Days of the answer.", "citation": "SDD Core Scheme Rulebook EPC016-06, 2025 version 1.1, section 4.6.4 PT-04.21 to PT-04.24, with section 4.3.4", "rests_on": "rule" }, { "label": "What happens when the calendars disagree", "value": "A Due Date on a non-TARGET day moves settlement to the next Inter-PSP Business Day. A Settlement Date that is not a Banking Business Day at the Debtor PSP moves the debit to that PSP's next open day.", "citation": "SDD Core Scheme Rulebook EPC016-06, 2025 version 1.1, section 4.3.2", "rests_on": "rule" }, { "label": "There is no 24 by 7 obligation on this rail", "value": "Nothing in the rulebook makes a participant process collections outside business days. The round-the-clock reachability duty that Regulation (EU) 2024/886 added to Union law lands on instant credit transfers, and direct debits are outside it.", "citation": "Regulation (EU) No 260/2012 Article 5a(1), as inserted by Regulation (EU) 2024/886, read against SDD Core Scheme Rulebook EPC016-06, 2025 version 1.1, section 4.3", "rests_on": "law" } ], "exceptions": [ "The rulebook does not list the TARGET closing days; it points at the ECB calendar, which the drafter did not read, so the current list is [Unverified].", "A national holiday can close one participant while TARGET stays open, moving that PSP's debit date without moving any inter-PSP deadline (section 4.3.2) [Inference: the rulebook defines the two calendars separately and does not spell this out].", "A Debtor PSP that debits late gains no time: the D+5 Inter-PSP Business Day limit on settling a Return stays where it was (section 4.3.2).", "When the creditor is credited is outside the scheme, so its own value date is a matter between it and its Creditor PSP (section 4.3.4).", "The deadlines in the unauthorised refund investigation govern only the settlement between the two PSPs. What the Debtor PSP owes its own debtor, and how fast, comes from the Payment Services Directive (section 4.6.4, note before PT-04.21)." ], "applies_to": "the timing of SEPA Direct Debit Core collections and their R-transactions between participants, and the customer-facing windows the rulebook sets", "caveat": "Two teams reading the same deadline can both be right and still disagree by a week, because one counted TARGET days and the other counted its own opening days. Every deadline on this rail has to be read with its calendar attached.", "related": [ "sepa-sdd-core:finality", "sepa-sdd-core:settlement", "sepa-sdd-core:return", "sepa-sdd-core:recall", "sepa-sdd-core:refund", "sepa-sdd-core:limits" ], "basis": { "sources": "SEPA Direct Debit Core Scheme Rulebook EPC016-06, 2025 version 1.1, date issued 05 October 2025 (marked Public), read for this record: section 4.3 (definitions of Inter-PSP Business Day, Banking Business Day and Calendar Day), 4.3.1 and 4.3.2 (key dates and their displacement), 4.3.3 (cut-off times), 4.3.4 (the time cycle rules), 4.6.4 PT-04.21 to PT-04.24 (investigation deadlines). Regulation (EU) No 260/2012, consolidated text of 08 April 2024 on EUR-Lex, Article 5a(1). The TARGET Days Calendar itself was not read.", "confidence": "high" }, "currency": { "effective_since": "Long-standing", "effective_note": "The calendar definitions and the day-grained design are in the 2025 version 1.1 rulebook, effective 05 October 2025, and predate it [Inference]. Earlier editions were not read, so first effective dates are [Unverified]. TARGET closing days change only through ECB decisions on the long-term calendar.", "source_edition": "SDD Core Scheme Rulebook EPC016-06, 2025 version 1.1, date issued 05 October 2025; Regulation (EU) No 260/2012 consolidated to 08 April 2024", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-10/EPC016-06%202025%20SDD%20Core%20Rulebook%20version%201.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC016-06 SDD Core Scheme Rulebook 2025 version 1.1", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms Inter-PSP Business Day defined against the TARGET Days Calendar and Banking Business Day defined per participating institution (4.3), whole-day-only deadlines with intraday cut-offs left to CSMs (4.3.3), the D-1 presentation, D+5 return and reversal windows, and the two/thirty-day refund settlement extensions already confirmed for the finality, return and refund facts (4.3.4), the date-displacement rule when a Due Date or Settlement Date falls outside the relevant calendar (4.3.2), and the mixed banking-business-day and calendar-day timeline inside the unauthorised refund investigation already confirmed for the refund fact (4.6.4 PT-04.21-PT-04.24). Does not independently confirm Regulation 260/2012 Article 5a(1) as inserted by 2024/886; EUR-Lex remains unreachable." } ] }, "rail_name": "SEPA Direct Debit Core", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sdd-core:liability", "id": "liability", "rail": "sepa-sdd-core", "kind": "rail-fact", "facet": "liability", "name": "Who bears the loss when a Core collection goes wrong?", "statement": "The scheme pushes the loss back towards the creditor, and stops there. A Returned collection and a Refunded one both come off the Creditor PSP automatically, with no fault to prove, and the Creditor PSP then has to get it off its creditor or absorb it. Beyond that there is an ordinary damages rule between participants for breach, negligence and operational failure, capped hard at the amount of the collection plus refund compensation, a cap that survives even gross negligence. What the rulebook does not do is decide who carries a fraud loss or an unauthorised debit as between the two PSPs. That comes from payment services law, where the debtor's own PSP pays the debtor first and argues afterwards.", "details": [ { "label": "Returns and refunds move without fault", "value": "Two automatic indemnities run from the Creditor PSP to the Debtor PSP: one for anything paid out to the debtor as a Refund, together with the refund compensation, and one for the amount of any collection that is Returned. Neither requires anyone to be shown at fault.", "citation": "SDD Core Scheme Rulebook EPC016-06, 2025 version 1.1, section 5.9.1", "rests_on": "rule" }, { "label": "Where that loss finally lands", "value": "On the creditor, if the Creditor PSP can reach it. It may debit the creditor for a Reject or Return only where it had already credited the account, and if it cannot get the money it either carries the exposure or writes it off, because charging it back to the Debtor PSP is not permitted. Refund compensation it has to recover on its own terms.", "citation": "SDD Core Scheme Rulebook EPC016-06, 2025 version 1.1, section 4.6.4 PT-04.12 and PT-04.18", "rests_on": "rule" }, { "label": "The Debtor PSP can step into the Creditor PSP's shoes", "value": "If a Debtor PSP is out of pocket on a Refund and the Creditor PSP does not indemnify it, it may take the benefit of the Creditor PSP's own rights against the creditor, and the Creditor PSP has to take reasonable steps to make that possible.", "citation": "SDD Core Scheme Rulebook EPC016-06, 2025 version 1.1, section 5.7, closing paragraphs", "rests_on": "rule" }, { "label": "Damages between participants", "value": "One participant owes the other its foreseeable losses, costs, damages, expenses, taxes and claim liabilities where they flow from a breach of the rulebook on that collection, from negligent acts or omissions touching it, or from operational failures touching it.", "citation": "SDD Core Scheme Rulebook EPC016-06, 2025 version 1.1, section 5.9.2", "rests_on": "rule" }, { "label": "The cap, and how hard it is", "value": "Claims stop at the amount of the collection plus refund compensation where owed. Once a Creditor PSP has paid that, the Debtor PSP gets nothing more however much worse its actual loss was. The ceiling holds against gross negligence, falls away only for wilful intent, and shrinks proportionately where the claimant contributed to the loss.", "citation": "SDD Core Scheme Rulebook EPC016-06, 2025 version 1.1, section 5.9.3", "rests_on": "rule" }, { "label": "Two losses you cannot claim at all", "value": "Anything that came out of a decision taken to limit or manage risk is off the table, and so is anything unforeseeable, where foreseeability is judged by what participants making cross border payments into SEPA countries regularly meet.", "citation": "SDD Core Scheme Rulebook EPC016-06, 2025 version 1.1, section 5.9.3", "rests_on": "rule" }, { "label": "Force majeure", "value": "A participant is off the hook for failure, obstruction or delay caused by circumstances outside its control, with acts of God, fire, flood and loss of energy supply given as examples rather than as the whole list.", "citation": "SDD Core Scheme Rulebook EPC016-06, 2025 version 1.1, section 5.9.4", "rests_on": "rule" }, { "label": "The EPC is not on the hook", "value": "The EPC, its agents and their staff answer for nothing done or left undone in exercising a discretion under the rulebook short of bad faith, and never for unforeseeable losses.", "citation": "SDD Core Scheme Rulebook EPC016-06, 2025 version 1.1, section 5.10", "rests_on": "rule" }, { "label": "Why unauthorised debits do not land on the Debtor PSP under the scheme", "value": "The scheme asks a Debtor PSP to check nothing about an incoming collection, mandate included. That is why an unauthorised collection is dealt with by putting the money back through the Refund route rather than by allocating fault between the PSPs.", "citation": "SDD Core Scheme Rulebook EPC016-06, 2025 version 1.1, section 4.6.4 PT-04.10, read with section 4.6.4 PT-04.20 to PT-04.24", "rests_on": "rule" }, { "label": "What the law does with an unauthorised debit", "value": "The debtor's own PSP pays first: it refunds an unauthorised transaction immediately and by the end of the next business day at the latest, unless it suspects fraud on reasonable grounds and says so in writing to the national authority. The payer can be left carrying up to 50 euro of a loss from a lost, stolen or misappropriated instrument, nothing at all where the PSP did not require strong customer authentication, and everything where it acted fraudulently or failed its obligations with intent or gross negligence.", "citation": "Directive (EU) 2015/2366, Articles 73(1) and 74(1) to (3)", "rests_on": "law" }, { "label": "What the law does with a botched execution", "value": "On a payee-initiated payment, which is what a direct debit is, the payee's PSP answers to the payee for getting the order to the payer's PSP properly and for handling the transaction. Where it is not liable on those grounds, the payer's PSP answers to the payer and has to put the account back as it was. Either PSP must also trace the payment on request, free of charge.", "citation": "Directive (EU) 2015/2366, Article 89(2)", "rests_on": "law" }, { "label": "Recourse between PSPs in law", "value": "Where one PSP's liability under the unauthorised or defective execution articles is really another PSP's or an intermediary's doing, that party has to compensate it, including where the failure was to use strong customer authentication.", "citation": "Directive (EU) 2015/2366, Article 92(1)", "rests_on": "law" }, { "label": "Which law reads the rulebook", "value": "Belgian law governs the rulebook itself and the Adherence Agreements. The mandate has to be governed by the law of a SEPA country, which need not be the same one.", "citation": "SDD Core Scheme Rulebook EPC016-06, 2025 version 1.1, section 3.5", "rests_on": "rule" } ], "exceptions": [ "Where the rulebook contradicts itself, Chapter 5 wins, and after that Chapter 4 wins over anything else, which matters because the liability rules sit in Chapter 5 (section 5.14).", "Participants outside the EEA are not bound by the Payment Services Directive; section 5.15 makes them promise substantially equivalent performance and to refrain from exercising conflicting national law rights, which is a contractual undertaking, not the Directive itself.", "An interchange fee on an R-transaction is a cost allocation permitted by Article 8(2) of Regulation (EU) No 260/2012, not compensation for loss, and it does not affect the cap (section 5.13).", "Annex II, the EPC Payment Scheme Management Rules, carries the compliance and dispute machinery, including the Dispute Resolution Committee that replaced the Compliance and Adherence Committee in the 2019 version 1.1 rulebook; Annex II was not read for this record.", "Annex III on risk management is referenced by the participant obligations and was not read, so obligations it imposes and their liability consequences are [Unverified].", "Article 61(1) of Directive (EU) 2015/2366 lets a non-consumer payer and its PSP disapply several of the liability articles, so the legal backstop described here may be weaker for a business debtor even on the Core scheme.", "Liability of a CSM to the participants that use it is outside the rulebook (section 1.4) and no CSM document was read." ], "applies_to": "allocation of loss between a Creditor PSP and a Debtor PSP on SEPA Direct Debit Core collections, and the legal backstop between a PSP and its own customer", "caveat": "The cap is the part people miss. A Creditor PSP that breaches the rulebook and costs a Debtor PSP far more than the collection was worth still owes only the collection amount plus refund compensation, and gross negligence does not lift that. Only wilful intent does.", "related": [ "sepa-sdd-core:finality", "sepa-sdd-core:return", "sepa-sdd-core:refund", "sepa-sdd-core:settlement", "sepa-sdd-core:consumer-law", "sepa-sdd-core:participants", "sepa-sdd-core:decision-points" ], "basis": { "sources": "SEPA Direct Debit Core Scheme Rulebook EPC016-06, 2025 version 1.1, date issued 05 October 2025 (marked Public), read for this record: section 0.2 (change history, on the Dispute Resolution Committee), 3.5 (governing laws), 4.6.4 PT-04.10, PT-04.12, PT-04.18 and PT-04.20 to PT-04.24, 5.7 (Creditor PSP obligations and subrogation), 5.8 (Debtor PSP obligations), 5.9.1 to 5.9.4 (indemnity, compensation, caps, force majeure), 5.10 (EPC liability), 5.13 (interchange fees), 5.14 (order of precedence), 5.15 (application of EU legislation between participants). Directive (EU) 2015/2366, consolidated text of 08 April 2024 on EUR-Lex: Articles 61(1), 73(1), 74, 89(2), 92(1), 93. Regulation (EU) No 260/2012, consolidated text of 08 April 2024, Article 8. Annexes II and III of the rulebook were not read.", "confidence": "high" }, "currency": { "effective_since": "Long-standing", "effective_note": "The liability provisions cited are in the 2025 version 1.1 rulebook, effective 05 October 2025, and predate it [Inference]. The change history records that the Compliance and Adherence Committee and the Appeals Committee became the Dispute Resolution Committee in the 2019 version 1.1 rulebook, dated 05 March 2020, so any older description of the dispute path is stale. Earlier editions were not read, so other first effective dates are [Unverified].", "source_edition": "SDD Core Scheme Rulebook EPC016-06, 2025 version 1.1, date issued 05 October 2025; Directive (EU) 2015/2366 consolidated to 08 April 2024", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-10/EPC016-06%202025%20SDD%20Core%20Rulebook%20version%201.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC016-06 SDD Core Scheme Rulebook 2025 version 1.1", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms section 5.9.1, titled 'No-fault Reimbursement of Refunds and Returns,' as the automatic Creditor-to-Debtor-PSP indemnity already consistent with the return and refund facts, the credit-risk allocation and no-recourse-against-the-Debtor-PSP rule (PT-04.12, PT-04.18), the Debtor PSP subrogation into the Creditor PSP's rights (5.7 closing paragraphs), the breach/negligence/operational-failure damages trigger and its collection-amount-plus-compensation cap surviving gross negligence but not wilful intent (5.9.2, 5.9.3), the risk-management and unforeseeability carve-outs (5.9.3), force majeure (5.9.4), EPC's own bad-faith-only liability (5.10), Belgian law governing the rulebook (3.5), and the Chapter 5 over Chapter 4 order of precedence (5.14). Does not independently confirm Directive 2015/2366 Articles 73(1), 74, 89(2) or 92(1); EUR-Lex remains unreachable." } ] }, "rail_name": "SEPA Direct Debit Core", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sdd-core:limits", "id": "limits", "rail": "sepa-sdd-core", "kind": "rail-fact", "facet": "limits", "name": "What limits apply to a Core collection, and who sets them?", "statement": "One ceiling comes from the scheme: 999,999,999.99 euro on a single collection, with a floor of one cent. Everything else that behaves like a limit here is either a clock or a control the debtor chose. Union law gives the debtor the right to cap direct debits by amount or by frequency, to shut the account to them entirely, and to name creditors that may or may not collect, and the Debtor PSP has to offer those controls. There is no return rate threshold anywhere in this scheme, so nothing here corresponds to the Nacha return rate caps.", "details": [ { "label": "Amount ceiling and floor per collection", "value": "A collection must be worth at least 0.01 euro and no more than 999,999,999.99 euro, and it cannot be for nothing. The Implementation Guidelines repeat that range on the interbank settlement amount and permit only EUR.", "citation": "SDD Core Scheme Rulebook EPC016-06, 2025 version 1.1, section 4.8.28 AT-T002, with SDD Core Inter-PSP Implementation Guidelines EPC114-06 2025 version 1.0, element 2.20", "rests_on": "rule" }, { "label": "Ceiling on a whole message", "value": "A single inter-PSP message tops out at 999,999,999,999,999.99 euro across all its transactions, with the same one cent floor and the same euro-only rule.", "citation": "SDD Core Inter-PSP Implementation Guidelines EPC114-06 2025 version 1.0, element 1.7", "rests_on": "rule" }, { "label": "The debtor's right to set limits, in law", "value": "Union law entitles a payer to instruct its PSP four ways: cap the amount, cap the frequency, or both; block direct debits on the account; block named payees; or allow only named payees.", "citation": "Regulation (EU) No 260/2012 Article 5(3)(d)(i) and (iii)", "rests_on": "law" }, { "label": "The scheme makes the Debtor PSP offer those controls", "value": "The rulebook carries the same entitlement through: a debtor may bar its account from direct debits outright or ask for the limitations Article 5 of the SEPA Regulation describes, and its PSP has to make those services available.", "citation": "SDD Core Scheme Rulebook EPC016-06, 2025 version 1.1, section 4.2", "rests_on": "rule" }, { "label": "Limits the debtor sets show up as R-transactions", "value": "A collection that breaches a debtor-set control comes back as an ordinary Reject or Return. The permitted reasons include an account blocked for direct debit by the debtor, a refusal by the debtor, and a specific service the Debtor PSP offers, and the reason code guidance gives an amount and periodicity cap as an example of that last category.", "citation": "SDD Core Scheme Rulebook EPC016-06, 2025 version 1.1, section 4.8.39 AT-R004, with EPC Guidance on Reason Codes for SDD R-transactions EPC173-14 version 8.0, section 2", "rests_on": "guidance" }, { "label": "Time limits that act like limits", "value": "The creditor has a fourteen calendar day runway: pre-notification no later than that before the Due Date unless agreed otherwise, and the collection not handed to the Creditor PSP earlier than that either. At the other end it must reach the Debtor PSP by one Inter-PSP Business Day before the Due Date.", "citation": "SDD Core Scheme Rulebook EPC016-06, 2025 version 1.1, sections 4.2 and 4.3.4", "rests_on": "rule" }, { "label": "A mandate expires from disuse", "value": "Thirty six months with no collection presented, counted from the last one whatever became of it, and the creditor has to cancel the mandate and stop using it. Collecting again needs a fresh mandate. Neither PSP is obliged to police this; it is the creditor's duty alone.", "citation": "SDD Core Scheme Rulebook EPC016-06, 2025 version 1.1, section 4.2", "rests_on": "rule" }, { "label": "No partial amounts coming back", "value": "Anything sent back has to match the original euro amount exactly, and a Reversal cannot be for part of a collection.", "citation": "SDD Core Scheme Rulebook EPC016-06, 2025 version 1.1, section 2.5, with section 4.8.57 AT-R042", "rests_on": "rule" }, { "label": "No return rate thresholds", "value": "Nowhere does this scheme set a percentage of Rejects, Returns or Refunds that triggers anything. Risk control lives in Annex III and in each participant's own policies, not in a published rate cap.", "citation": "SDD Core Scheme Rulebook EPC016-06, 2025 version 1.1, sections 4.4 and 5.8 item 7, read with Annex III as referenced there", "rests_on": "rule" }, { "label": "A ceiling on what one PSP can claim from another", "value": "Claims between participants under the rulebook stop at the amount of the collection, plus refund compensation where it is owed, and that ceiling holds even against gross negligence.", "citation": "SDD Core Scheme Rulebook EPC016-06, 2025 version 1.1, section 5.9.3", "rests_on": "rule" } ], "exceptions": [ "Where neither payer nor payee is a consumer, PSPs do not have to provide the Article 5(3)(d) controls at all, so a business debtor on the Core scheme may not get them as of right (Regulation (EU) No 260/2012 Article 5(3), closing subparagraph).", "Annex III on risk management was referenced but not read for this record, so any quantitative control it places on participants is [Unverified].", "Creditor PSPs routinely cap what a creditor may collect through their own terms and conditions; the rulebook leaves that relationship alone and says nothing about it (section 3.2, relationship 4).", "A CSM may impose its own file, batch or value limits; CSM rules are outside the rulebook (section 1.4) and none was read.", "The eight week and thirteen month windows are not limits on collecting. They are limits on the debtor's refund claim." ], "applies_to": "SEPA Direct Debit Core collections and the controls a debtor may place on its own account", "caveat": "The interesting limit on this rail is not the amount ceiling, which almost nobody reaches. It is the limit the debtor sets on its own account, because the collection that fails it comes back as an ordinary Reject or Return with a reason code that does not always say a customer control caused it.", "related": [ "sepa-sdd-core:settlement", "sepa-sdd-core:messages", "sepa-sdd-core:consumer-law", "sepa-sdd-core:refund", "sepa-sdd-core:participants", "sepa-sdd-core:decision-points" ], "basis": { "sources": "SEPA Direct Debit Core Scheme Rulebook EPC016-06, 2025 version 1.1, date issued 05 October 2025 (marked Public), read for this record: sections 2.5 (currency and exact amounts), 4.2 (debtor limits, pre-notification, 36 month inactivity), 4.3.4 (time cycle), 4.8.28 AT-T002 (amount), 4.8.39 AT-R004 (reason ranges), 4.8.57 AT-R042 (no partial reversals), 5.8 (Debtor PSP obligations), 5.9.3 (liability cap). SDD Core Inter-PSP Implementation Guidelines EPC114-06 2025 version 1.0 (file dated 2025-10, abstract states it implements rulebook 2025 version 1.1), elements 1.7 and 2.20. EPC Guidance on Reason Codes for SDD R-transactions EPC173-14 version 8.0, 28 November 2024, section 2. Regulation (EU) No 260/2012, consolidated text of 08 April 2024 on EUR-Lex, Article 5(3). Annex III of the rulebook was not read.", "confidence": "high" }, "currency": { "effective_since": "2025-10-05", "effective_note": "The amount range and the other limits cited are in the 2025 version 1.1 rulebook and the matching Implementation Guidelines, both effective 05 October 2025. The 999,999,999.99 euro ceiling and the 36 month mandate inactivity rule predate this edition [Inference]. Earlier editions were not read, so first effective dates are [Unverified]. Among the SDD Core items in the 2026 change request consultation read for Orca's SEPA rail brief (docs/rails/sepa.md), none proposes a change to the amount ceiling (EPC010-26 version 1.0, 13 March 2026).", "source_edition": "SDD Core Scheme Rulebook EPC016-06, 2025 version 1.1, date issued 05 October 2025; SDD Core Inter-PSP Implementation Guidelines EPC114-06 2025 version 1.0; Regulation (EU) No 260/2012 consolidated to 08 April 2024", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-10/EPC016-06%202025%20SDD%20Core%20Rulebook%20version%201.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC016-06 SDD Core Scheme Rulebook 2025 version 1.1", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the AT-T002 999,999,999.99 euro ceiling with a non-zero floor (4.8.28), the 36 month mandate-inactivity cancellation duty resting on the creditor alone with neither PSP obliged to check it, confirmed word for word (4.2), the debtor account-blocking and Article-5-style limitation services the Debtor PSP must offer (4.2), the 14 calendar day pre-notification runway and D-1 presentation deadline already confirmed for the hours fact (4.2, 4.3.4), the AT-R042 no-partial-reversal rule (4.8.57), and the collection-amount liability ceiling (5.9.3). Does not independently confirm Regulation 260/2012 Article 5(3)(d); EUR-Lex remains unreachable. Did not verify the EPC114-06 Implementation Guidelines element 1.7 and 2.20 citations for the message-level ceilings, which were not read for this check." } ] }, "rail_name": "SEPA Direct Debit Core", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sdd-core:messages", "id": "messages", "rail": "sepa-sdd-core", "kind": "rail-fact", "facet": "messages", "name": "Which messages carry a Core direct debit, and who pins their versions?", "statement": "The rulebook itself names no message. It describes datasets, DS-01 through DS-11, and the attributes inside them, and leaves the wire format to the Implementation Guidelines published alongside it. Those pin ISO 20022 at the 2019 message version. Between PSPs there are four: the collection, the pre-settlement reject, the return or refund, and the reversal. Between a creditor and its own PSP there are three more in the pain family. The odd ones out are the claim for an unauthorised refund and the request for a mandate copy, which the rulebook routes over a SWIFT message it does not identify, or over formatted email or fax templates. Those two have no ISO 20022 message and no XML schema.", "details": [ { "label": "The rulebook speaks in datasets, not messages", "value": "Business content is defined as datasets identified DS-01 to DS-11 and attributes identified AT-plus-a-code, and the standards that carry them are handled in the Implementation Guidelines listed at section 0.5.", "citation": "SDD Core Scheme Rulebook EPC016-06, 2025 version 1.1, sections 4.5, 4.7 and 4.8", "rests_on": "rule" }, { "label": "Which ISO 20022 version is pinned", "value": "The 2025 Implementation Guidelines are built on the 2019 message version of ISO 20022. The guidelines move with the rulebook: this edition was issued on 28 November 2024 and took effect on 05 October 2025 alongside rulebook version 1.1.", "citation": "SDD Core Inter-PSP Implementation Guidelines EPC114-06 2025 version 1.0, abstract and section 0.1", "rests_on": "rule" }, { "label": "The collection, PSP to PSP", "value": "DS-04, the inter-PSP collection, travels as the ISO 20022 FI to FI Customer Direct Debit, pacs.003.001.08.", "citation": "SDD Core Inter-PSP Implementation Guidelines EPC114-06 2025 version 1.0, section 2.1", "rests_on": "rule" }, { "label": "The return or refund", "value": "DS-05 used for a Return or a Refund travels as the ISO 20022 Payment Return, pacs.004.001.09.", "citation": "SDD Core Inter-PSP Implementation Guidelines EPC114-06 2025 version 1.0, section 2.2", "rests_on": "rule" }, { "label": "The reject", "value": "DS-05 used for a Reject, which by definition happens before settlement, travels as the ISO 20022 FI to FI Payment Status Report, pacs.002.001.10. Same dataset, different message, because the money never moved.", "citation": "SDD Core Inter-PSP Implementation Guidelines EPC114-06 2025 version 1.0, section 2.3", "rests_on": "rule" }, { "label": "The reversal", "value": "DS-07, the inter-PSP reversal instruction, travels as the ISO 20022 Payment Reversal, pacs.007.001.09.", "citation": "SDD Core Inter-PSP Implementation Guidelines EPC114-06 2025 version 1.0, section 2.4", "rests_on": "rule" }, { "label": "Creditor to its own PSP", "value": "The customer-facing side uses the pain family at the same 2019 message version: pain.008.001.08 to send collections, pain.002.001.10 for status back, and pain.007.001.09 for a reversal. A Creditor PSP has to support these where it offers its creditors bundled electronic submission.", "citation": "SDD Core Customer-to-PSP Implementation Guidelines EPC130-08 2025 version 1.0, with SDD Core Scheme Rulebook EPC016-06, 2025 version 1.1, section 5.2", "rests_on": "rule" }, { "label": "The two flows with no ISO message", "value": "A claim for the refund of an unauthorised transaction is DS-08 when it goes by SWIFT and DS-09 when it goes by email or fax template; a request for a mandate copy is DS-10 and DS-11 the same way. The rulebook calls the default channel the suitable SWIFT message without naming it, and allows any other channel the two PSPs agree.", "citation": "SDD Core Scheme Rulebook EPC016-06, 2025 version 1.1, sections 4.7.9 to 4.7.12, with section 4.6.4 PT-04.21", "rests_on": "rule" }, { "label": "Mandate data rides on every collection", "value": "The creditor holds the mandate and sends its data to the Creditor PSP with each collection, one-off or recurrent, and the Creditor PSP passes that data to the Debtor PSP inside the collection, in a single flow through the CSM. The Debtor PSP never receives the mandate itself.", "citation": "SDD Core Scheme Rulebook EPC016-06, 2025 version 1.1, section 4.1", "rests_on": "rule" }, { "label": "Account identification", "value": "The IBAN identifies the accounts, and since 2016 for cross-border payments a PSP may not require a payment service user to supply the other side's BIC. The creditor also carries a scheme creditor identifier, attribute AT-E005, which has no equivalent in US ACH.", "citation": "Regulation (EU) No 260/2012 Article 5(1)(a) and 5(7), with SDD Core Scheme Rulebook EPC016-06, 2025 version 1.1, section 4.8.15 AT-E005", "rests_on": "law" }, { "label": "Where the reason code values come from", "value": "The rulebook states the permitted reasons in words as the value range of attribute AT-R004, and points at the EPC reason code guidance to say which ISO code carries each one. The code values themselves are ISO 20022 External Code Set values, not EPC inventions.", "citation": "SDD Core Scheme Rulebook EPC016-06, 2025 version 1.1, section 4.8.39 AT-R004, with EPC Guidance on Reason Codes for SDD R-transactions EPC173-14 version 8.0, section 3", "rests_on": "rule" }, { "label": "A dated change already in the guidelines", "value": "From 22 November 2026 only structured and hybrid addresses may be used in EPC payment messages; unstructured addresses stop being allowed. The note sits with the change-over date in the guidelines and points at the EPC guidance document on addresses.", "citation": "SDD Core Inter-PSP Implementation Guidelines EPC114-06 2025 version 1.0, section 1.7", "rests_on": "rule" } ], "exceptions": [ "The rulebook does not name the SWIFT message used for refund claims and mandate copy requests, and the Implementation Guidelines cover only the four pacs messages, so the identifier of that message is [Unverified].", "The e-mandate service has its own implementation guidelines, EPC002-09 and EPC114-08, which were not read for this record, so the messages an e-mandate uses are not stated here.", "Additional Optional Services may add data elements inside the ISO 20022 standards, and community usage rules sit outside the rulebook, so a real message may carry more than the guidelines describe (section 2.4).", "The Implementation Guidelines carry an extended character set specification, EPC217-08, and clarification papers on slashes and on addresses, which were referenced in the guidelines and not read.", "The guidelines' cover page reads 2025 version 1.0 while the abstract states that they implement rulebook 2025 version 1.1; this record cites the file published in October 2025, and whether a separately numbered version 1.1 of the guidelines exists is [Unverified].", "Whether the SDD Core Customer-to-PSP guidelines also define a mandate-related message beyond the three pain messages named here was not checked; only that document's front matter was read." ], "applies_to": "the messages that carry SEPA Direct Debit Core collections and their R-transactions, between PSPs and between a creditor and its own PSP", "caveat": "Two of the flows a payments team will actually have to build, the unauthorised refund claim and the mandate copy request, are the ones with no XML schema and no named message. Teams that plan SDD Core as an all-ISO 20022 build discover the SWIFT, email and fax leg late.", "related": [ "sepa-sdd-core:return", "sepa-sdd-core:recall", "sepa-sdd-core:refund", "sepa-sdd-core:limits", "sepa-sdd-core:settlement" ], "basis": { "sources": "SDD Core Inter-PSP Implementation Guidelines EPC114-06 2025 version 1.0 (file dated 2025-10, abstract states it implements rulebook 2025 version 1.1), read for this record: abstract, section 0.1, section 1.7 (change-over date and the address note) and the section headings and message identifiers at 2.1 to 2.4, and element specifications 1.7 and 2.20. SDD Core Customer-to-PSP Implementation Guidelines EPC130-08 2025 version 1.0 (file dated 2025-10), front matter and message identifiers. SEPA Direct Debit Core Scheme Rulebook EPC016-06, 2025 version 1.1, date issued 05 October 2025: sections 0.5, 4.1, 4.5, 4.7.9 to 4.7.12, 4.6.4 PT-04.21, 4.8.15 AT-E005, 4.8.39 AT-R004, 5.2. Regulation (EU) No 260/2012, consolidated to 08 April 2024, Article 5. EPC Guidance on Reason Codes for SDD R-transactions EPC173-14 version 8.0, section 3. The e-mandate guidelines and the ISO 20022 message definitions themselves were not read.", "confidence": "high" }, "currency": { "effective_since": "2025-10-05", "effective_note": "The Implementation Guidelines cited were issued on 28 November 2024 and took effect on 05 October 2025 with rulebook version 1.1. They pin the 2019 message version of ISO 20022, which the previous editions did as well [Unverified: the change history was not compared]. A dated change is already published: from 22 November 2026 unstructured addresses may no longer be provided in EPC payment messages, structured and hybrid only. Message versions otherwise move only when a new edition of the guidelines says so, so the next opportunity is the November 2026 publication for the 2027 rulebooks.", "source_edition": "SDD Core Inter-PSP Implementation Guidelines EPC114-06 2025 version 1.0; SDD Core Customer-to-PSP Implementation Guidelines EPC130-08 2025 version 1.0; SDD Core Scheme Rulebook EPC016-06, 2025 version 1.1", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-10/EPC016-06%202025%20SDD%20Core%20Rulebook%20version%201.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC016-06 SDD Core Scheme Rulebook 2025 version 1.1; SDD Core Inter-PSP and Customer-to-PSP Implementation Guidelines EPC114-06 and EPC130-08, both 2025 version 1.0", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the rulebook speaks in datasets not messages and pushes the ISO mapping to the Implementation Guidelines (4.5, 4.7, 4.8, section 0.5), and confirms all four inter-PSP message identifiers directly from EPC114-06's table of contents and body: pacs.003.001.08 for the collection at 2.1.1, pacs.004.001.09 for the return/refund at 2.2.1, pacs.002.001.10 for the pre-settlement reject at 2.3.1, and pacs.007.001.09 for the reversal at 2.4.1. Confirms the three customer-to-PSP pain messages from EPC130-08's table of contents: pain.008.001.08 at 2.1.1, pain.007.001.09 at 2.2.1, and pain.002.001.10 at 2.3.1. Confirms the 2019 message version and the abstract's 'implementing Version 1.0 of the 2025 SDD Core Scheme Rulebook' wording, which does not itself say rulebook version 1.1 as the record's exception already flags. Confirms the 36 month mandate rule and reason code attribute AT-R004 already checked for the limits fact. Does not independently confirm Regulation 260/2012 Article 5(1)(a) or 5(7); EUR-Lex remains unreachable. Did not verify EPC002-09, EPC114-08, EPC217-08 or the address clarification papers, which were not read." } ] }, "rail_name": "SEPA Direct Debit Core", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sdd-core:participants", "id": "participants", "rail": "sepa-sdd-core", "kind": "rail-fact", "facet": "participants", "name": "Who can take part in the Core scheme, and what does joining commit them to?", "statement": "Participants are PSPs, and only PSPs. Creditors and debtors are customers of participants, not members of the scheme. Joining means signing an Adherence Agreement that puts the signatory in a contract with the EPC and with every other participant at once, under Belgian law. The obligation that matters most on Core is asymmetric: every participant has to serve as a Debtor PSP, so it can be collected from, while acting as a Creditor PSP is optional. Reachability is the whole point of the scheme, and Union law reinforces it for direct debits that consumers can use. Outsourcing the work changes nothing about who answers for it.", "details": [ { "label": "The four actors, and which two are participants", "value": "A direct debit involves a creditor, its PSP, the debtor's PSP and the debtor. Only the two PSPs are participants in the scheme. The creditor holds the mandate and initiates; the debtor gives the mandate and gets debited.", "citation": "SDD Core Scheme Rulebook EPC016-06, 2025 version 1.1, section 3.1", "rests_on": "rule" }, { "label": "Parties that are involved but not members", "value": "CSMs and intermediary PSPs take part in the flow without being participants. Using either has to be invisible to the scheme and must not alter what the participant owes, and any such arrangement is a separate bilateral contract.", "citation": "SDD Core Scheme Rulebook EPC016-06, 2025 version 1.1, sections 3.1 and 3.4", "rests_on": "rule" }, { "label": "What adhering actually creates", "value": "The rulebook is a multilateral agreement: a contract between the EPC and each participant, and a contract between each participant and every other one. Anyone who is not a party to it has neither rights nor obligations under it.", "citation": "SDD Core Scheme Rulebook EPC016-06, 2025 version 1.1, section 5.2", "rests_on": "rule" }, { "label": "The asymmetric duty that makes Core work", "value": "Every participant has to offer the scheme as a Debtor PSP. Offering it as a Creditor PSP is a choice. That is what makes accounts across SEPA collectible, and it is the sharpest structural difference from the B2B scheme.", "citation": "SDD Core Scheme Rulebook EPC016-06, 2025 version 1.1, sections 5.3 and 2.6", "rests_on": "rule" }, { "label": "The same duty in Union law", "value": "A payer's PSP reachable for domestic direct debits must also be reachable for direct debits started through a PSP in any other Member State under a Union-wide scheme, and that obligation covers only schemes whose direct debits are available to consumers as payers.", "citation": "Regulation (EU) No 260/2012 Article 3(2) and 3(3)", "rests_on": "law" }, { "label": "Who is eligible", "value": "An applicant has to be in the business of providing banking or payment services and of holding accounts used for payments, be incorporated and licensed in a SEPA country or licensed by an EEA regulator, be solvent and able to pay its debts, hold enough liquidity and capital, meet any rating criteria the scheme sets, comply with anti-money-laundering, sanctions and terrorist financing rules, participate directly or indirectly in a CSM, and run appropriate operational and risk controls.", "citation": "SDD Core Scheme Rulebook EPC016-06, 2025 version 1.1, section 5.4", "rests_on": "rule" }, { "label": "Who is waved through", "value": "EEA-authorised credit institutions and the bodies listed in the banking directive's own exemption list count as eligible automatically, as do licensed institutions in the non-EEA countries the scheme's geography has been extended to and that appear in EPC409-09. An authorised payment institution is treated as meeting five of the nine criteria. A sovereign treasury does not have to show solvency or meet rating criteria, subject to exceptions.", "citation": "SDD Core Scheme Rulebook EPC016-06, 2025 version 1.1, section 5.4", "rests_on": "rule" }, { "label": "Joining and leaving", "value": "An applicant sends the EPC a signed Adherence Agreement with supporting documentation, may use an agent to sign, and becomes a participant on a date the EPC sets under the Internal Rules. A rejection comes with reasons and can be appealed. Leaving takes at least six months' written notice, and everything already in flight has to be completed afterwards.", "citation": "SDD Core Scheme Rulebook EPC016-06, 2025 version 1.1, sections 5.5 and 5.11", "rests_on": "rule" }, { "label": "The list of participants", "value": "A list is kept current, showing contact details, the date each participant joined and details of those removed with their removal dates, and it is made available to participants when it is issued or updated. Applying to join includes consenting to that publication.", "citation": "SDD Core Scheme Rulebook EPC016-06, 2025 version 1.1, section 5.6", "rests_on": "rule" }, { "label": "What a Debtor PSP signs up to", "value": "Know your customer before contracting; enforceable terms consistent with the rulebook; tell debtors about the risks and their rights before the first collection lands; let a debtor bar direct debits; run the risk management the rulebook and Annex III require; carry out Rejects, Returns and Refunds even where the account has since closed; chase the Creditor PSP for mandate information when a debtor asks; and report risks and major incidents of scheme-wide importance to the EPC without delay.", "citation": "SDD Core Scheme Rulebook EPC016-06, 2025 version 1.1, section 5.8", "rests_on": "rule" }, { "label": "What a Creditor PSP signs up to", "value": "Alongside its own obligations it has to bind its creditors: use a compliant mandate, keep to its terms, store mandate data properly, pre-notify debtors, present collections on time, effect the Rejects, Returns and Refunds on its collections, hand over mandate copies on request, follow risk management guidance, and settle underlying contract disputes directly with the debtor.", "citation": "SDD Core Scheme Rulebook EPC016-06, 2025 version 1.1, section 5.7", "rests_on": "rule" }, { "label": "Outsourcing does not move the obligation", "value": "A participant may run the processes itself, use intermediaries or outsource wholly or partly, and remains answerable under the rulebook either way. Where it leans on a CSM or an intermediary it does so at its own risk.", "citation": "SDD Core Scheme Rulebook EPC016-06, 2025 version 1.1, sections 1.3 and 5.3", "rests_on": "rule" } ], "exceptions": [ "Offering the e-mandate service is optional in either role, and taking it up does not narrow the duty to accept collections made under paper mandates (section 2.6).", "Participants in the non-EEA parts of the scheme's geography are not subject to the Payment Services Directive; section 5.15 obliges them to perform substantially equivalent obligations and to comply with named articles of the SEPA Regulation as a matter of contract.", "Eligibility includes meeting whatever rating or financial criteria the scheme sets at the time, and those criteria are not written down in the rulebook and were not read [Unverified].", "Annex I, the Adherence Agreement, and Annex II, the EPC Payment Scheme Management Rules that govern the admission, compliance and appeal process, were not read for this record.", "The rulebook says the list of participants is made available to participants; whether the EPC also publishes it openly was not checked [Unverified].", "Adherence is per scheme. A participant in Core is not thereby a participant in SDD B2B, SCT or SCT Inst, each of which has its own rulebook and adherence.", "Where a Debtor PSP is itself the debtor on a collection, its obligations under section 5.8 apply subject to applicable law (section 5.8 item 17)." ], "applies_to": "PSPs adhering to the SEPA Direct Debit Core scheme, in either or both of the Creditor PSP and Debtor PSP roles", "caveat": "The reachability duty is what a creditor is actually buying when it picks Core: any euro account at any Core participant can be collected from. Treat a list of participants as a list of reachable debtor accounts, not as a list of banks that will act as Creditor PSP for you, because that side is optional.", "related": [ "sepa-sdd-core:settlement", "sepa-sdd-core:liability", "sepa-sdd-core:consumer-law", "sepa-sdd-core:limits", "sepa-sdd-core:messages" ], "basis": { "sources": "SEPA Direct Debit Core Scheme Rulebook EPC016-06, 2025 version 1.1, date issued 05 October 2025 (marked Public), read for this record: sections 1.3 (binding nature and outsourcing), 2.6 (reachability and e-mandates), 3.1 (actors), 3.2 (four corner model), 3.4 (intermediary PSPs), 3.5 (governing laws), 5.1 to 5.8 (scheme, compliance, reachability, eligibility, joining, list of participants, PSP obligations), 5.11 (termination), 5.15 (application of EU legislation between participants). Regulation (EU) No 260/2012, consolidated text of 08 April 2024 on EUR-Lex, Article 3. Annexes I, II and III of the rulebook, and EPC409-09, were not read.", "confidence": "high" }, "currency": { "effective_since": "Long-standing", "effective_note": "The participation rules cited are in the 2025 version 1.1 rulebook, effective 05 October 2025, and predate it [Inference]. The geographical scope changes when the EPC admits a country, through EPC409-09, whose current version was not read for this record. Earlier rulebook editions were not read, so first effective dates are [Unverified].", "source_edition": "SDD Core Scheme Rulebook EPC016-06, 2025 version 1.1, date issued 05 October 2025; Regulation (EU) No 260/2012 consolidated to 08 April 2024", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-10/EPC016-06%202025%20SDD%20Core%20Rulebook%20version%201.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC016-06 SDD Core Scheme Rulebook 2025 version 1.1", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the asymmetric reachability duty word for word: 'Each Participant shall offer services...in the capacity of Debtor PSP. A Participant may also offer services...in the capacity of Creditor PSP' (5.3), the multilateral-agreement/non-party-gets-no-rights framing (5.2), CSMs and intermediaries as non-participants acting at the participant's own risk (3.1, 3.4, 5.3), the Core/B2B cross-scheme reject-or-return rule (2.7), the e-mandate optionality not narrowing the paper-mandate reachability duty (2.6), and joining/leaving/eligibility/register provisions (5.4, 5.5, 5.6, 5.11) that mirror the SCT and SCT Inst sections already confirmed. Does not independently confirm Regulation 260/2012 Article 3(2)-(3); EUR-Lex remains unreachable." } ] }, "rail_name": "SEPA Direct Debit Core", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sdd-core:recall", "id": "recall", "rail": "sepa-sdd-core", "kind": "rail-fact", "facet": "recall", "name": "Can the creditor's side pull a collection back, and what is it called?", "statement": "There is no recall here. Recall is a credit transfer idea, and dropping it onto a direct debit reverses the direction of the money. The creditor's side has three exits and only one of them belongs to the scheme. A Revocation is the creditor telling its own PSP to drop a collection before a cut-off the two of them agreed, and the rulebook leaves that to their contract. A request for cancellation is the Creditor PSP asking its CSM to drop it before settlement, again a bilateral matter outside the scheme. The Reversal is the scheme's own process: after settlement, a creditor that concludes it should never have collected pays the debtor back in full. Note which way that money moves. Nothing in this scheme lets the creditor's side take money off a debtor after the fact.", "details": [ { "label": "The scheme's own list of exception paths", "value": "The rulebook enumerates what can go wrong and what each situation is called: Rejects, Refusals, Returns, Reversals, Revocations, requests for cancellation and Refunds. No recall appears on that list.", "citation": "SDD Core Scheme Rulebook EPC016-06, 2025 version 1.1, section 4.4", "rests_on": "rule" }, { "label": "Revocation", "value": "The creditor withdrawing its own instruction, up to a date it agreed with its Creditor PSP. The rulebook explicitly leaves this to that bilateral agreement and does not cover it.", "citation": "SDD Core Scheme Rulebook EPC016-06, 2025 version 1.1, section 4.4", "rests_on": "rule" }, { "label": "Request for cancellation", "value": "One step further out: the Creditor PSP asking the CSM to withdraw a collection before settlement. That sits in the contract between the Creditor PSP and its CSM, which the scheme does not govern either.", "citation": "SDD Core Scheme Rulebook EPC016-06, 2025 version 1.1, section 4.4", "rests_on": "rule" }, { "label": "Reversal, the one scheme process", "value": "After clearing and settlement, a creditor that decides the collection should not have gone out can put the full amount back to the debtor. The Creditor PSP may start one for the same reasons.", "citation": "SDD Core Scheme Rulebook EPC016-06, 2025 version 1.1, section 4.4, with section 4.5.5 PR-05", "rests_on": "rule" }, { "label": "Who must offer it and who must handle it", "value": "Optional on the sending side, compulsory on the receiving side. A Creditor PSP need not offer Reversals at all and a creditor need not use them, but a Debtor PSP has no choice about processing one that arrives.", "citation": "SDD Core Scheme Rulebook EPC016-06, 2025 version 1.1, section 4.4", "rests_on": "rule" }, { "label": "The window", "value": "It opens on the Settlement Date and shuts five Inter-PSP Business Days after the Due Date the collection asked for. Those five days are measured end to end, from the creditor starting it to the CSM delivering it to the Debtor PSP.", "citation": "SDD Core Scheme Rulebook EPC016-06, 2025 version 1.1, section 4.3.4, with section 4.6.5 PT-05.01 to PT-05.03", "rests_on": "rule" }, { "label": "The Debtor PSP checks nothing", "value": "It simply credits the debtor. It does not have to confirm that the original collection was ever debited, nor that it has not already been Rejected, Returned or Refunded.", "citation": "SDD Core Scheme Rulebook EPC016-06, 2025 version 1.1, section 4.5.5 PT-05.04 and section 4.6.5 PT-05.04", "rests_on": "rule" }, { "label": "Only two reasons exist", "value": "Whoever starts the Reversal, creditor or Creditor PSP, can give one of exactly two reasons: duplicate entry, or none specified. The Debtor PSP may pass that on to explain the credit.", "citation": "SDD Core Scheme Rulebook EPC016-06, 2025 version 1.1, section 4.8.56 AT-R041", "rests_on": "rule" }, { "label": "All or nothing", "value": "A Reversal has to be for the same amount as the collection. Part of one is not allowed.", "citation": "SDD Core Scheme Rulebook EPC016-06, 2025 version 1.1, section 4.8.57 AT-R042", "rests_on": "rule" }, { "label": "It is meant to stay rare", "value": "This is exception handling, and the rulebook tells Creditor PSPs to watch how often their creditors reach for it so it does not become a routine tool for purposes the rules do not allow.", "citation": "SDD Core Scheme Rulebook EPC016-06, 2025 version 1.1, section 4.6.5 PT-05.02", "rests_on": "rule" }, { "label": "The message that carries it", "value": "Dataset DS-07 goes on the wire as the ISO 20022 Payment Reversal, pacs.007.001.09, at the 2019 message version.", "citation": "SDD Core Inter-PSP Implementation Guidelines EPC114-06 2025 version 1.0, section 2.4", "rests_on": "rule" } ], "exceptions": [ "A Reversal presented after its window has to be stopped by the Creditor PSP or by CSMs acting for it, with the Debtor PSP told (section 4.3.4).", "Once the Debtor PSP has the Reversal, the scheme sets no deadline at all for crediting the debtor; the process step leaves the closing time open (section 4.6.5 PT-05.04).", "Since the Debtor PSP checks nothing, a Reversal that follows a Return or a Refund of the same collection can leave the debtor paid twice, and untangling that is outside the scheme [Inference from PT-05.04 read with section 4.4].", "Revocation and cancellation deadlines are agreed case by case, so they vary between PSPs and between CSMs and cannot be stated for the scheme as a whole (section 4.4).", "A Reversal does not settle the argument between debtor and creditor, which the scheme leaves to them (section 4.2).", "Recall does exist in the SEPA Credit Transfer and SEPA Instant Credit Transfer schemes, under their own rulebooks and reason code guidance. Those rules do not carry across to a direct debit." ], "applies_to": "creditor-initiated withdrawal of a SEPA Direct Debit Core collection, before and after settlement", "caveat": "An agent asked to \"recall a SEPA direct debit\" is almost always being asked one of two different questions: the creditor wants to undo its own collection, which is a Reversal, or the debtor wants its money back, which is a Refund or a Return. Answering with the credit transfer recall rules would be wrong on the initiator, the direction of funds and the window.", "related": [ "sepa-sdd-core:finality", "sepa-sdd-core:return", "sepa-sdd-core:refund", "sepa-sdd-core:messages", "sepa-sdd-core:decision-points" ], "basis": { "sources": "SEPA Direct Debit Core Scheme Rulebook EPC016-06, 2025 version 1.1, date issued 05 October 2025 (marked Public), read for this record: section 4.2 (disputes out of scope), 4.3.4 (reversal window and late presentation), 4.4 (definitions of reversal, revocation and request for cancellation), 4.5.5 and 4.6.5 PT-05.01 to PT-05.04 (the reversal process), 4.8.56 AT-R041 and 4.8.57 AT-R042 (reversal reasons and amount). SDD Core Inter-PSP Implementation Guidelines EPC114-06 2025 version 1.0, section 2.4. The absence of a recall process is an absence claim from the rulebook's own list of R-transactions at section 4.4.", "confidence": "high" }, "currency": { "effective_since": "Long-standing", "effective_note": "The reversal process and its five Inter-PSP Business Day window are in the 2025 version 1.1 rulebook, effective 05 October 2025, and predate it [Inference]. Earlier editions were not read, so first effective dates are [Unverified]. The 2026 change request consultation proposes a longer recall timeline for SCT and SCT Inst, which does not touch this scheme (EPC011-26 version 1.0, 13 March 2026, item 35).", "source_edition": "SDD Core Scheme Rulebook EPC016-06, 2025 version 1.1, date issued 05 October 2025; SDD Core Inter-PSP Implementation Guidelines EPC114-06 2025 version 1.0", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-10/EPC016-06%202025%20SDD%20Core%20Rulebook%20version%201.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC016-06 SDD Core Scheme Rulebook 2025 version 1.1", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms no Recall appears among the scheme's exception paths (Rejects, Refusals, Returns, Reversals, Revocations, cancellation requests, Refunds), Revocation and requests for cancellation as bilateral matters outside the scheme (4.4), the Reversal as the one scheme process, optional to offer but compulsory to process (4.4), the D+5 end-to-end reversal window already confirmed for the finality fact (4.3.4, 4.6.5 PT-05.01-05.03), that the Debtor PSP checks nothing before crediting (PT-05.04), and the AT-R041 two-value reason range (Duplicate entry, Reason not specified) and AT-R042 no-partial-reversal rule confirmed word for word (4.8.56, 4.8.57). Did not verify the EPC114-06 Implementation Guidelines citation for the pacs.007.001.09 message identifier, which was not read for this check." } ] }, "rail_name": "SEPA Direct Debit Core", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sdd-core:refund", "id": "refund", "rail": "sepa-sdd-core", "kind": "rail-fact", "facet": "refund", "name": "Does the debtor have a right to be refunded, and on what grounds?", "statement": "Two rights, two clocks, two processes. For the first eight weeks after the debit the debtor can demand its money back for any reason or none at all, and the Debtor PSP pays without asking why, then takes the amount plus interest off the Creditor PSP. From eight weeks out to thirteen months the debtor can still claim, but now it has to assert that no valid mandate covered the collection, and a defined investigation starts: the claim goes down the chain to the creditor, a mandate copy is usually demanded, and the Debtor PSP decides. Inside the scheme that decision is the end of it for every participant. Neither refund settles the argument between debtor and creditor, which the scheme leaves to them.", "details": [ { "label": "The eight week right", "value": "Eight weeks from the debit date, any Core collection, no reason needed. The Debtor PSP has to pay.", "citation": "SDD Core Scheme Rulebook EPC016-06, 2025 version 1.1, section 4.3.4", "rests_on": "rule" }, { "label": "What no-questions-asked means operationally", "value": "The debtor tells its PSP to put the money back and does not have to say why. The PSP credits the account for the amount collected, and the scheme itself gives it the authority to take that amount from the Creditor PSP.", "citation": "SDD Core Scheme Rulebook EPC016-06, 2025 version 1.1, section 4.6.4 PT-04.15 and PT-04.16", "rests_on": "rule" }, { "label": "Where the eight week right comes from in law", "value": "Union law gives payers an unconditional refund right on direct debits covered by Regulation (EU) No 260/2012, running for eight weeks from the debit. A PSP has ten business days to pay or to justify refusing, and on the unconditional right refusing is not open to it.", "citation": "Directive (EU) 2015/2366, Article 76(1) fourth subparagraph and Article 77(1) and (2)", "rests_on": "law" }, { "label": "When the eight week refund settles between the PSPs", "value": "The inter-PSP leg gets two Inter-PSP Business Days beyond the end of the eight weeks, so debit date plus eight weeks plus two.", "citation": "SDD Core Scheme Rulebook EPC016-06, 2025 version 1.1, section 4.3.4, with section 4.6.4 PT-04.16 and PT-04.17", "rests_on": "rule" }, { "label": "The interest that travels with a refund", "value": "The debtor is put back with value date equal to the original Due Date, so the Debtor PSP is out of pocket on interest and bills that to the Creditor PSP as refund compensation. The sum is driven by the ECB's euro short-term rate over the days between the two settlement dates and rides in attribute AT-R006.", "citation": "SDD Core Scheme Rulebook EPC016-06, 2025 version 1.1, section 4.6.4 PT-04.16", "rests_on": "rule" }, { "label": "The thirteen month right", "value": "Past eight weeks the debtor needs a ground, and the ground is that the collection was never authorised. The claim, with whatever evidence the debtor has, has to reach the Debtor PSP inside thirteen months of the debit date. The rulebook ties that limit to Article 71 of the Payment Services Directive.", "citation": "SDD Core Scheme Rulebook EPC016-06, 2025 version 1.1, section 4.3.4 and section 4.6.4 PT-04.20, with Directive (EU) 2015/2366 Article 71(1)", "rests_on": "law" }, { "label": "How the unauthorised claim is investigated", "value": "The Debtor PSP looks at the claim and decides whether to take it forward. If it does, it sends the claim on, stripped of the debtor's evidence, within 4 Banking Business Days. The Creditor PSP then has 3 Banking Business Days to hand it to the creditor, and the creditor 7 Banking Business Days to investigate and reply. A SWIFT message is the default channel, with formatted email or fax templates as alternatives.", "citation": "SDD Core Scheme Rulebook EPC016-06, 2025 version 1.1, section 4.6.4 PT-04.21 to PT-04.23", "rests_on": "rule" }, { "label": "The four kinds of request", "value": "A type code on the request says what the Debtor PSP wants. Two of the four demand a mandate copy, differing over whether the creditor can avoid sending one by conceding. The other two skip the copy: either the debtor says it cancelled the mandate, or the mandate should have lapsed after 36 months without a collection.", "citation": "SDD Core Scheme Rulebook EPC016-06, 2025 version 1.1, section 4.6.4 PT-04.21, with section 4.8.44 AT-R022", "rests_on": "rule" }, { "label": "What the Debtor PSP is told to weigh", "value": "The rulebook recommends a comparison: the mandate the debtor actually signed, with any amendments, against the mandate data the creditor sent with the collection, across a named list of attributes. It also says to check the mandate was still alive on the debit date and had not lapsed under the 36 month rule.", "citation": "SDD Core Scheme Rulebook EPC016-06, 2025 version 1.1, section 4.6.4 PT-04.21, recommended guidance", "rests_on": "rule" }, { "label": "Who decides, and how final it is", "value": "The Debtor PSP decides once the creditor's answer comes back, or at the outside 30 calendar days after the debtor claimed. It can accept because the creditor conceded, accept on the evidence, refuse, or, where nothing came back inside those 30 days, do whatever it thinks right on what the debtor gave it. For scheme purposes that decision is the end of the matter. Settlement then follows within 4 Inter-PSP Business Days of the answer.", "citation": "SDD Core Scheme Rulebook EPC016-06, 2025 version 1.1, section 4.6.4 PT-04.24, with section 4.3.4", "rests_on": "rule" }, { "label": "A mandate copy is the price of claiming", "value": "Before it can bill the Creditor PSP, the Debtor PSP must have asked for the mandate copy, unless the debtor had cancelled the mandate or it had lapsed through 36 months of disuse. A Debtor PSP that turns the debtor down has to say so promptly and pass on the creditor's evidence.", "citation": "SDD Core Scheme Rulebook EPC016-06, 2025 version 1.1, section 4.6.4 PT-04.24", "rests_on": "rule" }, { "label": "Who ultimately pays", "value": "The Creditor PSP has to make the Debtor PSP whole for the refund and the compensation, with no fault to prove, and then chase its own creditor, on terms of its own making for the compensation part. If the Creditor PSP does not pay up, the Debtor PSP may step into its shoes against the creditor, and the Creditor PSP has to help it do so.", "citation": "SDD Core Scheme Rulebook EPC016-06, 2025 version 1.1, sections 5.9.1(a), 4.6.4 PT-04.18 and 5.7 closing paragraphs", "rests_on": "rule" }, { "label": "Which code says which refund", "value": "In the EPC guidance the unconditional eight week claim is MD06, a disputed authorised transaction, marked for Core collections only, and the unauthorised claim is MD01. Orca holds the per-code detail as reason code records in corpus/sepa-sdd-core/reason-codes.", "citation": "EPC Guidance on Reason Codes for SDD R-transactions EPC173-14 version 8.0, 28 November 2024, section 3", "rests_on": "guidance" }, { "label": "A refund is not a resolution", "value": "Money back does not mean the debtor was right. It still has to settle the bill with the creditor, and the refund proves nothing either way. Those disputes are outside the scheme.", "citation": "SDD Core Scheme Rulebook EPC016-06, 2025 version 1.1, section 4.2", "rests_on": "rule" } ], "exceptions": [ "The investigation steps govern only the settlement between the two PSPs. What the Debtor PSP owes its own debtor runs on the Directive's clock, where an unauthorised transaction must be refunded straight away and by the end of the next business day after notification at the latest, unless the PSP has reasonable grounds to suspect fraud and puts those grounds to the national authority in writing (rulebook note before PT-04.21, with Directive (EU) 2015/2366 Article 73(1)).", "A framework contract can switch off the payer's refund right where consent went straight to the PSP and the payer was told about the transaction at least four weeks ahead, and the unconditional direct debit right is expressed as being without prejudice to that (Directive (EU) 2015/2366 Article 76(3) and Article 76(1) fourth subparagraph). The scheme grants the eight week refund with no such carve-out, so a Core debtor may hold a scheme right wider than the legal floor [Inference from reading the two texts together].", "A payment service user that is not a consumer may agree with its PSP to disapply Articles 76 and 77 in whole or in part, and to different time limits than Article 71. A business debtor on the Core scheme can therefore have bargained the legal right away while the scheme right stands (Directive (EU) 2015/2366 Article 61(1)).", "The thirteen month cut-off falls away where the PSP never supplied the transaction information Title III of the Directive requires (Article 71(1), second subparagraph).", "An unauthorised claim raised inside the first eight weeks still lets the Debtor PSP ask for a mandate copy through the PR-06 procedure (section 4.6.4 PT-04.20).", "Finality for scheme participants is not finality for the customers: creditor and debtor may reopen the dispute between themselves by any means, outside the scheme (section 4.6.4 PT-04.24).", "Closing the account does not close the right: the Debtor PSP must still handle refunds the debtor asks for afterwards (section 5.8 items 9 and 10).", "Annex VI of the rulebook, Instructions for the Refund Procedure for Unauthorised Transactions, is referenced at PT-04.24 and was not read for this record." ], "applies_to": "refund claims made by a debtor to its own Debtor PSP on a settled SEPA Direct Debit Core collection", "caveat": "The eight week right and the thirteen month right are not one right with two lengths. The first needs no reason and no evidence and cannot be refused; the second needs an assertion that the collection was unauthorised, runs an investigation with named deadlines, and can be refused by the Debtor PSP with no appeal inside the scheme. Anything that describes SEPA Core as \"thirteen months to get your money back\" has merged them.", "related": [ "sepa-sdd-core:finality", "sepa-sdd-core:return", "sepa-sdd-core:recall", "sepa-sdd-core:consumer-law", "sepa-sdd-core:liability", "sepa-sdd-core:decision-points", "sepa-sdd-core:hours", "sepa-sdd-core:messages" ], "basis": { "sources": "SEPA Direct Debit Core Scheme Rulebook EPC016-06, 2025 version 1.1, date issued 05 October 2025 (marked Public), read for this record: sections 4.2 (refund entitlement and disputes), 4.3.4 (the eight week, thirteen month and settlement windows), 4.4 (definition of refunds and refund compensation), 4.6.4 PT-04.15 to PT-04.27 (both refund processes end to end), 4.8.39 AT-R004 (refund reasons), 4.8.41 AT-R006 and 4.8.44 AT-R022, 5.7 (Creditor PSP obligations and subrogation), 5.8 (Debtor PSP obligations), 5.9.1 (no-fault reimbursement). Directive (EU) 2015/2366, consolidated text of 08 April 2024 on EUR-Lex: Articles 61(1), 71(1), 73(1), 76(1) and (3), 77(1) and (2). EPC Guidance on Reason Codes for SDD R-transactions EPC173-14 version 8.0, 28 November 2024, section 3. Annex VI of the rulebook was not read.", "confidence": "high" }, "currency": { "effective_since": "Long-standing", "effective_note": "Both refund rights are in the 2025 version 1.1 rulebook, effective 05 October 2025, and predate it: the eight week and thirteen month windows follow Articles 77 and 71 of Directive (EU) 2015/2366, which applied from 13 January 2018, and equivalent provisions existed under the earlier Payment Services Directive [Unverified as to that earlier text, which was not read]. The 2026 change request consultation proposes adding FRAD as an SDD Core refund reason; it is a proposal and not adopted (EPC010-26 version 1.0, 13 March 2026, item 36).", "source_edition": "SDD Core Scheme Rulebook EPC016-06, 2025 version 1.1, date issued 05 October 2025; Directive (EU) 2015/2366 consolidated to 08 April 2024; EPC173-14 version 8.0", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-10/EPC016-06%202025%20SDD%20Core%20Rulebook%20version%201.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC016-06 SDD Core Scheme Rulebook 2025 version 1.1; EPC173-14 v8.0 Guidance on Reason Codes for SDD R-transactions", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms word for word the eight week no-questions-asked refund right and the thirteen month unauthorised-transaction claim window tied to PSD2 Article 71 (4.3.4 time-cycle rules), the two inter-PSP business day settlement extension for the eight week refund and the 30 calendar day plus four inter-PSP business day extension for the unauthorised refund (4.3.4), the PT-04.15/PT-04.16 no-questions-asked process and interest compensation, and the PT-04.20 to PT-04.24 investigation timeline exactly as described: 4 banking business days for the Debtor PSP to forward the claim, 3 for the Creditor PSP to reach the Creditor, 7 for the Creditor to answer, and a 30 calendar day outside limit for the Debtor PSP's decision, including the four refund-type codes and the recommended mandate-comparison attribute list verbatim (4.6.4). Confirms the Creditor PSP's subrogation-based recovery against the creditor (5.9 area) and MD01/MD06 as EPC173-14 v8.0 section 3 codes. Does not independently confirm Directive 2015/2366 Article 76(1) fourth subparagraph or Article 77(1)-(2); EUR-Lex remains unreachable. This directly supports the special-attention question on the Core 8 week and 13 month refund rights with interest compensation." } ] }, "rail_name": "SEPA Direct Debit Core", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sdd-core:return", "id": "return", "rail": "sepa-sdd-core", "kind": "rail-fact", "facet": "return", "name": "Can a settled Core collection be sent back, by whom, and by when?", "statement": "Yes, and the call belongs to the Debtor PSP alone. Once the PSPs have settled, the Debtor PSP can push the collection back, and the binding deadline is on settling that Return: five Inter-PSP Business Days from the Settlement Date of the collection. It needs nobody's permission and owes no explanation past a reason code. The money retraces its route through the same CSM, the Creditor PSP has to make the Debtor PSP whole without any fault being shown, and if it cannot get the money off its own creditor it carries the loss. The same event before settlement is a Reject, which is a different thing: a Reject never settles, a Return unwinds a settlement that already happened.", "details": [ { "label": "What a return is", "value": "A Return is the Debtor PSP pulling a collection out of the normal flow after the PSPs have settled. Do the same thing before settlement and it is a Reject. A debtor refusal that the Debtor PSP gets to too late to Reject turns into a Return.", "citation": "SDD Core Scheme Rulebook EPC016-06, 2025 version 1.1, section 4.4", "rests_on": "rule" }, { "label": "The window", "value": "Five Inter-PSP Business Days from the Settlement Date, and it is the settlement of the Return that has to happen inside them, not merely the decision to send one.", "citation": "SDD Core Scheme Rulebook EPC016-06, 2025 version 1.1, sections 4.2 and 4.3.4, with section 4.6.4 PT-04.10", "rests_on": "rule" }, { "label": "The grounds", "value": "Something technical went wrong, or the Debtor PSP cannot take the collection at all, for instance a closed account, a dead debtor, or an account that does not accept direct debits; or Article 93 of the Payment Services Directive applies; or the debtor simply does not want it paid. The exhaustive set is the value range of attribute AT-R004.", "citation": "SDD Core Scheme Rulebook EPC016-06, 2025 version 1.1, section 4.2, with section 4.8.39 AT-R004", "rests_on": "rule" }, { "label": "What Article 93 of the Payment Services Directive covers", "value": "It lifts liability where events outside a party's control were both abnormal and unforeseeable and could not have been avoided, or where another Union or national law obliged the PSP to act as it did. In practice that is the sanctions and force majeure door, not a general discretion to decline.", "citation": "Directive (EU) 2015/2366, Article 93", "rests_on": "law" }, { "label": "The Debtor PSP is not obliged to check anything", "value": "Nothing in the scheme makes a Debtor PSP test an incoming collection against anything, and in particular it need not hold or check a mandate for the creditor presenting it. A Debtor PSP may promise its debtor such checks privately, but that is a contract between them, not a scheme rule.", "citation": "SDD Core Scheme Rulebook EPC016-06, 2025 version 1.1, section 4.6.4 PT-04.10", "rests_on": "rule" }, { "label": "How the money travels back", "value": "Debtor PSP to CSM to Creditor PSP, and the settlement runs the opposite way to the collection: the creditor's side is charged and the debtor's side credited. Rejects and Returns have to travel over the CSM that carried the collection unless the participants agreed on another route.", "citation": "SDD Core Scheme Rulebook EPC016-06, 2025 version 1.1, section 4.6.4 PT-04.11, with section 4.4", "rests_on": "rule" }, { "label": "Who ends up out of pocket", "value": "The Creditor PSP owes the Debtor PSP the amount of any returned collection, no fault required. It may pass that on to the creditor only if it already credited the creditor's account. If it cannot collect from the creditor, it holds the exposure or takes the loss, because debiting the Debtor PSP again is not open to it.", "citation": "SDD Core Scheme Rulebook EPC016-06, 2025 version 1.1, sections 5.9.1(b) and 4.6.4 PT-04.12", "rests_on": "rule" }, { "label": "Late returns must not be processed", "value": "A Return that misses its settlement deadline has to be stopped on the creditor's side, whether by the Creditor PSP itself or by the CSM acting for it, and the Debtor PSP has to be told it was stopped.", "citation": "SDD Core Scheme Rulebook EPC016-06, 2025 version 1.1, section 4.3.4", "rests_on": "rule" }, { "label": "Which codes carry a return", "value": "The EPC guidance works code by code and states which R-transaction types each one may appear on. Codes available on a Core Return cover the account, mandate, funds and refusal families. MD06 is a Refund reason only, and AC13 belongs to B2B collections. Orca holds the per-code detail as reason code records in corpus/sepa-sdd-core/reason-codes.", "citation": "EPC Guidance on Reason Codes for SDD R-transactions EPC173-14 version 8.0, 28 November 2024, section 3", "rests_on": "guidance" }, { "label": "The message that carries it", "value": "Dataset DS-05 on the wire is the ISO 20022 Payment Return, pacs.004.001.09, at the 2019 message version. The pre-settlement Reject rides in the payment status report instead, pacs.002.001.10.", "citation": "SDD Core Inter-PSP Implementation Guidelines EPC114-06 2025 version 1.0, sections 2.2 and 2.3", "rests_on": "rule" } ], "exceptions": [ "Debiting the debtor late does not buy time: the Return still has to settle by D+5 Inter-PSP Business Days (section 4.3.2).", "A Creditor PSP can also Reject a collection its own creditor gave it, and the reasons for that are whatever the two of them agreed rather than a scheme list (section 4.8.39 AT-R004).", "A CSM can Reject before the Debtor PSP ever sees the collection, for example where a PSP is not registered under the BIC used or settlement of the collection failed (section 4.8.39 AT-R004).", "Where national law, typically data protection law, forbids the precise code, the guidance permits the generic agent-generated code instead, which leaves the creditor unable to see the real reason (EPC173-14 v8.0, section 3).", "AC13, debtor account is a consumer account, exists for SDD B2B collections and is not available on a Core Return (EPC173-14 v8.0, section 3).", "A participant that adheres to Core as Debtor PSP may apply Core rules to Reject or Return a collection that arrived flagged as a B2B collection (section 2.7)." ], "applies_to": "post-settlement returns of SEPA Direct Debit Core collections, initiated by the Debtor PSP", "caveat": "Five Inter-PSP Business Days is the settlement deadline for the Return, not a grace period the Debtor PSP may spend deciding. A Debtor PSP that debits late still owes the Return inside the original window, which is why late debits and D+5 returns collide in practice.", "related": [ "sepa-sdd-core:finality", "sepa-sdd-core:refund", "sepa-sdd-core:recall", "sepa-sdd-core:messages", "sepa-sdd-core:liability", "sepa-sdd-core:decision-points", "sepa-sdd-core:hours" ], "basis": { "sources": "SEPA Direct Debit Core Scheme Rulebook EPC016-06, 2025 version 1.1, date issued 05 October 2025 (marked Public), read for this record: sections 2.7 (erroneous use of the schemes), 4.2 (returns and their grounds), 4.3.2 and 4.3.4 (windows and late presentation), 4.4 (definitions of reject, refusal and return), 4.6.4 PT-04.10 to PT-04.12 (return process and credit risk), 4.8.39 AT-R004 (permitted reasons), 5.9.1 (no-fault reimbursement). EPC Guidance on Reason Codes for SDD R-transactions EPC173-14 version 8.0, 28 November 2024, sections 1 to 3. SDD Core Inter-PSP Implementation Guidelines EPC114-06 2025 version 1.0, sections 2.2 and 2.3. Directive (EU) 2015/2366, consolidated text of 08 April 2024 on EUR-Lex, Article 93.", "confidence": "high" }, "currency": { "effective_since": "Long-standing", "effective_note": "The D+5 return window and the return process are in the 2025 version 1.1 rulebook, effective 05 October 2025, and predate it [Inference: EPC173-14 v8.0 of November 2024 describes the same window and covers the 2023 rulebooks as well]. Earlier editions were not read, so first effective dates are [Unverified]. The 2026 change request consultation proposes a new SDD reject and return reason code for fraud for both schemes; it is a proposal and not adopted (EPC010-26 version 1.0, 13 March 2026, item 24).", "source_edition": "SDD Core Scheme Rulebook EPC016-06, 2025 version 1.1, date issued 05 October 2025; EPC173-14 version 8.0; SDD Core Inter-PSP Implementation Guidelines EPC114-06 2025 version 1.0", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-10/EPC016-06%202025%20SDD%20Core%20Rulebook%20version%201.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC016-06 SDD Core Scheme Rulebook 2025 version 1.1; EPC173-14 v8.0 Guidance on Reason Codes for SDD R-transactions", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms word for word that a Return settles by D+5 inter-PSP business days from the Settlement Date (4.3.4, PT-04.10), that the scheme imposes no duty on the Debtor PSP to check or hold a mandate for an incoming collection (PT-04.10), the debtor-to-creditor settlement flow through the CSM (PT-04.11), the no-fault reimbursement and credit-risk allocation to the Creditor PSP with no recourse against the Debtor PSP (PT-04.12), and the late-return stop rule (4.3.4). Confirms MD06 as a refund-only code and AC13 as B2B-only against EPC173-14 v8.0 section 3. Does not independently confirm Directive 2015/2366 Article 93, and did not verify the EPC114-06 Inter-PSP Implementation Guidelines citation for the pacs.004.001.09/pacs.002.001.10 message identifiers, which were not read for this check. This directly supports the special-attention question on D+5 return settlement." } ] }, "rail_name": "SEPA Direct Debit Core", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "sepa-sdd-core:settlement", "id": "settlement", "rail": "sepa-sdd-core", "kind": "rail-fact", "facet": "settlement", "name": "Who settles a Core collection, in what money, and when is settlement complete?", "statement": "The scheme settles nothing and says almost nothing about how settlement works, on purpose. The EPC writes one rulebook; each participant buys clearing and settlement from whichever CSM it prefers. So the settlement model, the settlement asset, the cycle and the intraday cut-offs on any given Core collection come from that CSM, not from the EPC. What the rulebook does pin down is which day settlement is expected, that the inter-PSP leg is always in euro, that money going back has to retrace the route it came by, and that a Refund carries interest compensation with it.", "details": [ { "label": "The scheme is deliberately separate from the infrastructure", "value": "One rulebook, many operators, is a stated design choice. The EPC supplies the rules; CSMs, platforms and networks compete to carry them, and participants choose between them commercially.", "citation": "SDD Core Scheme Rulebook EPC016-06, 2025 version 1.1, section 1.4", "rests_on": "rule" }, { "label": "What the CSM is responsible for", "value": "In the ordinary course a CSM takes collections from the Creditor PSP, passes them intact to the Debtor PSP, carries the Rejects, Returns and Refunds back, arranges the settlement between the two PSPs and runs whatever risk controls the service needs.", "citation": "SDD Core Scheme Rulebook EPC016-06, 2025 version 1.1, section 3.3", "rests_on": "rule" }, { "label": "A CSM is not necessarily one entity, and need not be external", "value": "The word covers more than clearing houses: intra-PSP books, intra-group arrangements and bilateral or multilateral deals between participants all count, and clearing and settlement can be done by different parties.", "citation": "SDD Core Scheme Rulebook EPC016-06, 2025 version 1.1, section 3.1", "rests_on": "rule" }, { "label": "The expected settlement date", "value": "Settlement is expected on the Due Date, which is also normally the debit date, provided the conditions in section 4.3.1 hold. Where they do not, section 4.3.2 moves the dates rather than excusing them.", "citation": "SDD Core Scheme Rulebook EPC016-06, 2025 version 1.1, sections 4.3.1 and 4.3.2", "rests_on": "rule" }, { "label": "Settlement currency", "value": "Euro, at every stage between PSPs, including every R-transaction. The customers' own accounts can be in any currency; whoever converts does so inside its own books and the scheme takes no view on the rate or the risk.", "citation": "SDD Core Scheme Rulebook EPC016-06, 2025 version 1.1, section 2.5", "rests_on": "rule" }, { "label": "Money coming back goes the same way it came", "value": "A Reject, Return or Refund has to clear and settle through the CSM that handled the original collection, unless the two participants agree on another route. Any CSM that serves this scheme has to support all three.", "citation": "SDD Core Scheme Rulebook EPC016-06, 2025 version 1.1, section 4.4, final paragraph", "rests_on": "rule" }, { "label": "How a return settles", "value": "The CSM hands the Return to the Creditor PSP and books the money the other way: the Creditor PSP is debited and the Debtor PSP credited.", "citation": "SDD Core Scheme Rulebook EPC016-06, 2025 version 1.1, section 4.6.4 PT-04.11", "rests_on": "rule" }, { "label": "How a refund settles, and what rides with it", "value": "Same direction as a Return, plus an extra: the Creditor PSP is debited for the original amount and for the refund compensation the Debtor PSP worked out. The unauthorised transaction Refund settles the same way.", "citation": "SDD Core Scheme Rulebook EPC016-06, 2025 version 1.1, section 4.6.4 PT-04.17 and PT-04.25", "rests_on": "rule" }, { "label": "How refund compensation is calculated", "value": "Because the debtor is put back with value date equal to the original Due Date, the Debtor PSP loses interest, and the Creditor PSP owes it. The figure is interest over the calendar days from the collection's Settlement Date, counted, to the Refund's settlement date, not counted, using the ECB's euro short-term rate as it stood on the first Banking Business Day of each month, on a 360 day basis. It travels in attribute AT-R006.", "citation": "SDD Core Scheme Rulebook EPC016-06, 2025 version 1.1, section 4.6.4 PT-04.16, with section 4.8.41 AT-R006", "rests_on": "rule" }, { "label": "Cut-off times are not scheme rules", "value": "Deadlines in the rulebook are counted in whole days and stop there. What time of day a file has to be in is settled between each CSM and its participants, and between each PSP and its customers.", "citation": "SDD Core Scheme Rulebook EPC016-06, 2025 version 1.1, section 4.3.3", "rests_on": "rule" }, { "label": "Interchange fees on this rail", "value": "Union law forbids a multilateral interchange fee on the direct debit itself, and permits one on R-transactions only where it is strictly cost based and meets the rest of the conditions in Article 8(2). The rulebook leaves such arrangements to participants within that law, and the amount the Debtor PSP takes travels in attribute AT-R007.", "citation": "Regulation (EU) No 260/2012 Article 8(1) and 8(2), with SDD Core Scheme Rulebook EPC016-06, 2025 version 1.1, sections 5.13 and 4.8.42 AT-R007", "rests_on": "law" } ], "exceptions": [ "The rulebook is silent on when settlement becomes final in the sense of Directive 98/26/EC, because that turns on whether the CSM in use is a designated system; no CSM document was read for this record [Unverified].", "Where both accounts sit at the same institution or inside one group, the CSM can be an internal arrangement and nothing settles externally at all (section 3.1).", "When the creditor is credited for a collection is outside the scheme (section 4.3.4), and so is when the Creditor PSP debits the creditor for a Refund (section 4.6.4 PT-04.18).", "If the creditor's account cannot be debited for a Reject or Return, the Creditor PSP carries it as credit risk or eats it; it is barred from debiting the Debtor PSP (section 4.6.4 PT-04.12).", "Getting refund compensation back from the creditor is the Creditor PSP's own commercial problem, not a scheme process (section 4.6.4 PT-04.18).", "The euro short-term rate can go negative and the rulebook gives the formula without addressing that case [Unverified]." ], "applies_to": "inter-PSP settlement of SEPA Direct Debit Core collections and of the rejects, returns, refunds and reversals that follow them", "caveat": "Two questions get confused here. \"When does a Core collection settle?\" has a scheme answer: the Due Date, as a rule. \"How does it settle, and when is that irrevocable between the banks?\" has no scheme answer at all. Anyone modelling settlement risk on this rail has to read their CSM's rules, not the rulebook.", "related": [ "sepa-sdd-core:finality", "sepa-sdd-core:hours", "sepa-sdd-core:return", "sepa-sdd-core:refund", "sepa-sdd-core:limits", "sepa-sdd-core:participants" ], "basis": { "sources": "SEPA Direct Debit Core Scheme Rulebook EPC016-06, 2025 version 1.1, date issued 05 October 2025 (marked Public), read for this record: sections 1.4 (separation of scheme from infrastructure), 2.5 (currency), 3.1 (actors and CSMs), 3.3 (CSM responsibilities), 4.3.1 to 4.3.4 (key dates, cut-off times, time cycle), 4.4 (exception handling and the CSM routing rule), 4.6.4 PT-04.11, PT-04.12, PT-04.16, PT-04.17, PT-04.18 and PT-04.25 (settlement of returns and refunds, refund compensation), 4.8.41 AT-R006 and 4.8.42 AT-R007, 5.13 (interchange fees). Regulation (EU) No 260/2012, consolidated text of 08 April 2024 on EUR-Lex, Article 8. No CSM document was read.", "confidence": "high" }, "currency": { "effective_since": "Long-standing", "effective_note": "The provisions cited are in the 2025 version 1.1 rulebook, effective 05 October 2025. The separation of scheme from infrastructure and the refund compensation formula predate this edition [Inference]. The euro short-term rate replaced EONIA as the reference rate for refund compensation in an earlier edition that was not read, so the date of that change is [Unverified].", "source_edition": "SDD Core Scheme Rulebook EPC016-06, 2025 version 1.1, date issued 05 October 2025; Regulation (EU) No 260/2012 consolidated to 08 April 2024", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-10/EPC016-06%202025%20SDD%20Core%20Rulebook%20version%201.1.pdf", "source_class": "authoritative_primary", "source_title": "EPC016-06 SDD Core Scheme Rulebook 2025 version 1.1", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the scheme/infrastructure separation (1.4), CSM responsibilities and that a CSM need not be one external entity (3.1, 3.3), the Due Date as expected settlement day with 4.3.2 moving rather than excusing mismatched dates (4.3.1, 4.3.2), euro-only inter-PSP settlement (2.5), the CSM routing rule for Rejects/Returns/Refunds (4.4), the return and refund settlement directions and compensation calculation on the euro short-term rate already confirmed for the return and refund facts (4.6.4), cut-off times counted only in whole days (4.3.3), and the interchange fee section's existence (5.13, 4.8.42). Does not independently confirm Regulation 260/2012 Article 8(1)-(2); EUR-Lex remains unreachable." } ] }, "rail_name": "SEPA Direct Debit Core", "governing_authority": "European Payments Council", "snapshot": "2026-09-17", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "uk-fps:consumer-law", "id": "consumer-law", "rail": "uk-fps", "kind": "rail-fact", "facet": "consumer-law", "name": "What does the law give a consumer that the scheme does not?", "statement": "Part 7 of the Payment Services Regulations 2017 binds every United Kingdom provider whatever Faster Payments says, and it does three things the scheme rules do not. It sets an outer limit on execution: the payer's provider must get the amount to the payee's provider by the end of the business day following receipt of the payment order. Since 30 October 2024 it also lets a provider hold a payment back where it has reasonable grounds, established by the end of the next business day, to suspect the order was placed as a result of fraud or dishonesty by someone other than the payer; that delay is for making enquiries, must be no longer than necessary, must end by the close of the fourth business day, and the payer must be told of the delay, its reasons and anything required of them by the end of the business day after receipt. And, since August 2023, it stops a provider hiding behind the rule that a payer who gave the wrong account number bears the loss: where the payment was executed as a result of fraud or dishonesty, regulation 90 yields to the reimbursement direction. Alongside that, the regulator made providers tell their consumers about the reimbursement right and write it into their contract terms, and Schedule 4 preserves the Financial Ombudsman and the Contingent Reimbursement Model Code rather than displacing them.", "details": [ { "label": "The money must reach the payee's provider by the end of the next business day", "value": "Whatever a scheme's own speed, the statutory duty is that the payer's provider gets the amount to the payee's provider's account by the end of the business day following the time it received the payment order. For a payment order on paper the duty is the end of the second business day. Faster Payments normally does this in seconds, so the statutory limit bites only when something has gone wrong, and it is what a payer can point at when a payment sits unexplained.", "citation": "The Payment Services Regulations 2017 (SI 2017/752), Part 7, regulation 86(1) and 86(2)", "rests_on": "law" }, { "label": "A provider may hold a payment to the fourth business day on suspicion of third party fraud", "value": "Since 30 October 2024 a payer's provider may delay crediting the payee's provider where it has established reasonable grounds to suspect that the payment order was placed as a result of fraud or dishonesty by someone other than the payer, and has established those grounds by the end of the business day after it received the order. The delay is for contacting the payer or another relevant party to work out whether to execute at all, must be no longer than necessary, and in any event must end by the close of the fourth business day after receipt. The provider must tell the payer of the delay, the reasons for it, and anything the payer must do or provide, in an agreed manner, as soon as possible and by no later than the end of the business day after it received the order. The trigger is fraud by a third party, which is exactly the scam case, and this is the statutory basis for the pause a bank puts on a suspicious transfer.", "citation": "The Payment Services Regulations 2017 (SI 2017/752), Part 7, regulation 86(2A) to 86(2D)", "rests_on": "law" }, { "label": "The reimbursement duty overrides the wrong account number defence", "value": "Regulation 90 ordinarily leaves a payer who gave the wrong unique identifier bearing the loss, with the provider owing only a duty to try to recover. Two paragraphs inserted on 29 August 2023 by section 72(11) of the Financial Services and Markets Act 2023 cut that off where the payment was executed as a result of fraud or dishonesty: nothing in regulation 90 affects a provider's liability under a relevant requirement in such a case, and regulation 90 is itself subject to any such requirement. A relevant requirement includes a direction under section 54 of the Financial Services (Banking Reform) Act 2013, which is what the reimbursement direction is. So a provider cannot answer a scam claim by saying the consumer gave the account number.", "citation": "The Payment Services Regulations 2017 (SI 2017/752), Part 7, regulation 90(6) and 90(7), with textual amendment note F34", "rests_on": "law" }, { "label": "Providers had to tell consumers about the right and write it into their terms", "value": "Two obligations the regulator put on providers directly rather than through the scheme. Every directed provider capable of sending had to inform its existing consumers of their rights under the reimbursement requirement and rules by 7 October 2024, including the changes coming to their contract terms, and from that date must have arrangements to tell new consumers by the time it starts serving them, using the same manner in which it would notify them of any other change to its services. Each such provider also had to amend the terms of its framework contracts with consumers holding relevant accounts to say that it will reimburse as the requirement and rules oblige, at the earliest practicable opportunity and in any event by 9 April 2025.", "citation": "PSR Specific Direction 20 (July 2024), FPS APP scam reimbursement requirement, paragraphs 5.1 to 5.5 and 6.1 to 6.3", "rests_on": "rule" }, { "label": "The Ombudsman and the industry code sit alongside, not under, the scheme rule", "value": "Schedule 4 says that handling a scam claim does not alter any other legal obligation about how a consumer is treated under another regime, and names the Financial Ombudsman and the Contingent Reimbursement Model Code as examples. A consumer who is refused under the reimbursement rules has not run out of routes, and a provider that has closed a claim correctly may still face a decision elsewhere, though anything it then pays is voluntary and the receiving provider owes nothing toward it.", "citation": "FPS Reimbursement Rules, Schedule 4, v3.0, clauses 2.6 and 5.2(b)", "rests_on": "rule" } ], "exceptions": [ "The statutory execution limit rarely bites on this rail, because Faster Payments normally moves money in seconds. It matters when something has gone wrong or a payment has been held.", "The fraud delay power is what a bank relies on when it pauses a suspicious transfer. Its trigger is fraud by someone other than the payer, which is the scam case exactly.", "HM Treasury has a review of assimilated payment services law under way, so these regulation numbers may eventually move into regulator rules [Unverified: no document read here states a date]." ], "applies_to": "every payment service provider in the United Kingdom, for payments in Part 7's scope, alongside the Faster Payments rules rather than under them", "caveat": "Do not read the reimbursement requirement as the whole of a consumer's protection, and do not read the statutory rights as covering a scam. Regulation 76 reaches only payments the payer did not authorise; a scam victim authorised theirs, which is why the reimbursement requirement had to be created and why section 72 of the Financial Services and Markets Act 2023 had to cut off the wrong-account-number defence.", "related": [ "uk-fps:refund", "uk-fps:liability", "uk-fps:decision-points" ], "basis": { "sources": "The Payment Services Regulations 2017 (SI 2017/752), regulations 86(1), 86(2), 86(2A) to (2D), 90(6) and (7), with the textual amendment notes recording the 30 October 2024 and 29 August 2023 insertions, read on legislation.gov.uk 2026-09-20; PSR Specific Direction 20 (July 2024), paragraphs 5.1 to 5.5 and 6.1 to 6.3; FPS Reimbursement Rules Schedule 4 v3.0, clauses 2.6 and 5.2. All read 2026-09-20 and cited by regulation, paragraph and clause. Neither the Financial Ombudsman scheme rules nor the Contingent Reimbursement Model Code was read [Unverified].", "confidence": "high" }, "currency": { "effective_since": "2024-10-30", "effective_to": null, "effective_note": "The newest provision in this fact, the fraud delay in regulation 86(2A) to (2D), was inserted on 30 October 2024 by the Payment Services (Amendment) Regulations 2024, SI 2024/1013. Regulation 90(6) and (7) were inserted on 29 August 2023 by the Financial Services and Markets Act 2023, section 72(11). The consolidated text carries no commencement note on regulation 86(1) and (2) themselves, so when they first applied is [Unverified].", "source_edition": "Faster Payments System Principles v11 (2 January 2026); Pay.UK's 2025 PFMI self-assessment (published November 2025); Pay.UK's Certainty of Fate proposed rule clarification v1.0 (January 2026); Pay.UK's Faster Payment System, transaction limits, participant list and Confirmation of Payee FAQ pages; FPS Reimbursement Rules Schedule 4 v3.0 (26 September 2024); PSR Specific Direction 20 (July 2024) and the two PSR notices of value; PSR Specific Direction 17 as consolidated July 2026; the Payment Services Regulations 2017, Part 7. All read 2026-09-20.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.legislation.gov.uk/uksi/2017/752/part/7", "source_class": "authoritative_primary", "source_title": "The Payment Services Regulations 2017 (SI 2017/752), Part 7", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms the statutory execution deadline in regulation 86, the fraud delay power in regulation 86(2A) to (2D) with its dates and timings, and the override of the wrong identifier defence in regulation 90(6) and (7)." }, { "source_url": "https://www.psr.org.uk/media/rqrpnb0w/amended-specific-direction-20-july-2024.pdf", "source_class": "authoritative_primary", "source_title": "PSR Specific Direction 20 (July 2024), FPS APP scam reimbursement requirement", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms the duty on providers to tell consumers about the reimbursement right and to amend their contract terms." } ] }, "rail_name": "Faster Payments (UK)", "governing_authority": "Pay.UK Limited", "snapshot": "2026-09-20", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "uk-fps:decision-points", "id": "decision-points", "rail": "uk-fps", "kind": "rail-fact", "facet": "decision-points", "name": "Where does a person or a bank actually decide something?", "statement": "Six places, and one of them is a machine. The receiving institution decides in seconds whether to accept a payment without qualification, accept it with a qualifier code or reject it, on checking Pay.UK guides rather than mandates. Either provider may hold a payment for fraud or money laundering investigation before it reaches the infrastructure, on its own policies, and the sending provider decides how much error checking to do at all. The payer decides whether to go ahead after a Confirmation of Payee result, which comes in four outcomes and where unavailable is not a no match. On a scam claim the sending provider decides alone whether the standard of caution exception applies, whether the consumer was grossly negligent, whether they were vulnerable, whether the matter is really a private civil dispute, and whether to stop the clock. The receiving provider decides whether to volunteer information in its three business day window, and decides when its internal investigations are concluded, which is what starts the clock on returning recovered money. The machine is the central infrastructure, which refers every payment to the Current Account Switch Service table and silently redirects a switched account, telling the sending participant afterwards.", "details": [ { "label": "The receiving institution decides in seconds, and may accept with a qualification", "value": "The first decision on every payment belongs to the receiving institution, and it has seconds to make it: accept without qualification, accept with a qualifier code, or reject with a rejection code. Pay.UK sets guidelines rather than mandatory rules for the checking behind it. A participant giving an unqualified acceptance is expected as a minimum to have checked that the payee account number in tag 35 exists at the quoted sort code and can take credits, or that a building society roll number or other identifier in the reference information identifies an account that can, or that an account reference such as a credit card number in tag 120 exists and is open, and it is expected to make those checks even where the account is not held with it. Pay.UK's proposed clarification would tighten this: a receiving institution must accept without qualification where the payee account details can be checked in near real time and it can be certain of making funds available for the vast majority in near real time, extending only in exceptional circumstances, and otherwise must either reject or accept with the right qualifier code.", "citation": "Faster Payments System Principles, FPS information guide, v11, Required Elements, Error Checking (Receiving Participant), Availability of Funds to the Beneficiary; Pay.UK's work on Certainty of Fate to support A2A retail transactions: proposed rule clarification, v1.0, annex, rules 6.2 and 10.1", "rests_on": "rule" }, { "label": "Fraud and money laundering holds are the provider's own judgement", "value": "Faster Payments does not mandate fraud checking. Both the sending and the receiving provider are to make suitable checks in line with their own policies, and to follow the prevailing money laundering and know your customer law at all times. Pay.UK notes that a small percentage of attended payments may be held pending investigation by either side before submission to the infrastructure, or rejected back to the customer, and that a sending participant must still tell its customer that the payment has not yet been made. The level of error checking a sending participant applies before submission is likewise its own commercial choice, and the whole proposition relies on the payer checking the sort code and account number.", "citation": "Faster Payments System Principles, FPS information guide, v11, section 5.1; Required Elements, Fraud, Error Checking (Sending Participant)", "rests_on": "rule" }, { "label": "Confirmation of Payee hands the decision to the payer, in four outcomes", "value": "Confirmation of Payee is an overlay Pay.UK owns and writes the rules for, checking a payee's name, sort code, account number, any secondary reference data and account type against what the payee's provider holds. It is payments agnostic and can be offered on Faster Payments, CHAPS and Bacs. The payer is shown one of four outcomes: a match, a close match with the actual account name to check, no match, or unavailable, which happens where the check could not run at all, for instance on a timeout, a customer opt out or an account that does not exist. Unavailable is not a no match. Pay.UK states plainly that a name check does not guarantee that a fraudulent payment will be caught or that a victim will be reimbursed. The check is on new payees and on amended details; existing payees and standing orders may not be checked. More than 140 organisations offer it. A separate regulator direction obliges named providers to offer it, and the underlying four character reason codes are not public.", "citation": "Pay.UK, Confirmation of Payee FAQs, the whole page; Faster Payments System Principles, FPS information guide, v11, section 10.3; Required Elements, Error Checking (Sending Participant); PSR Specific Direction 17, consolidated text as it would be varied, July 2026, paragraphs 1.7, 3 and 7.2", "rests_on": "rule" }, { "label": "The sending provider judges gross negligence and vulnerability, alone", "value": "The decision that matters most to a scam victim is one bank's. The sending provider assesses every payment in the claim, decides whether the consumer standard of caution exception applies and whether the consumer's behaviour amounted to gross negligence, decides whether the victim was a vulnerable consumer at the time and whether that had a material effect, decides whether the matter is really a private civil dispute, and decides whether to stop the clock. It may not complete that assessment until the receiving providers have had their chance to respond. No source read gives a route of appeal within the rules: a consumer who disagrees is left to the Ombudsman and the other regimes Schedule 4 preserves.", "citation": "FPS Reimbursement Rules, Schedule 4, v3.0, clauses 3.6, 3.11, 4.2, 4.3, 4.5 and 2.6", "rests_on": "rule" }, { "label": "Two choices belong to the receiving provider", "value": "The receiving provider decides whether to volunteer information in the three business day window, which is an opportunity and not a duty, and it decides when its internal investigations and approvals are concluded, which is what starts the three business day clock on returning recovered money. Both choices shape the outcome and neither is constrained by an outer deadline in the text read: the only backstop is that the claim goes from dormant to closed without repatriation 13 months after the contribution was paid.", "citation": "FPS Reimbursement Rules, Schedule 4, v3.0, clauses 4.2, 6.4 and 6.5", "rests_on": "rule" }, { "label": "The infrastructure silently redirects a switched account, and nobody decides", "value": "Where a customer has switched provider under the Current Account Switch Service, their old and new account details sit on a redirection table for a period the service defines. The central infrastructure refers every Faster Payment to that table and automatically redirects any payment naming an old account. Each redirection is reported to the sending participant afterwards, which must then update the payer's standing order or bill payment instruction within the permitted timescale, or tell a corporate or agency customer so it can update its own records. Pay.UK monitors compliance with that. A payment can therefore reach an account the payer never named, and reach it correctly; no person decides it, and the payer is not asked.", "citation": "Faster Payments System Principles, FPS information guide, v11, Required Elements, Redirections", "rests_on": "rule" } ], "exceptions": [ "No source read gives a route of appeal inside the reimbursement rules against a sending provider's assessment. Schedule 4 preserves the Financial Ombudsman and other regimes instead [Inference: this is an absence in the text].", "Nothing read puts an outer limit on how long a receiving provider's internal investigations may take before the three business day repatriation clock starts. The only backstop is that the claim closes without repatriation 13 months after the contribution was paid.", "Pay.UK's proposed clarification to the receiving institution's obligations was open for feedback to 20 February 2026 and no outcome had been published when this record was written." ], "applies_to": "the Faster Payment System, its participants and the directed providers the reimbursement rules bind", "caveat": "Orca cannot tell you how any of these judgements will go. Whether a consumer was grossly negligent, whether they were vulnerable, whether a dispute is really civil, and when a receiving bank's investigations conclude are all one firm's assessment on facts Orca does not hold. This record says who decides and by when, not what they will decide.", "related": [ "uk-fps:liability", "uk-fps:messages", "uk-fps:hours", "uk-fps:consumer-law" ], "basis": { "sources": "Faster Payments System Principles v11, sections 5.1 and 10.3 and the Error Checking, Availability of Funds, Fraud and Redirections rows of the Required Elements table; Pay.UK's Certainty of Fate proposed rule clarification, annex rules 6.2 and 10.1; Pay.UK's Confirmation of Payee FAQs; FPS Reimbursement Rules Schedule 4 v3.0, clauses 2.6, 3.6, 3.11, 4.2, 4.3, 4.5, 6.4 and 6.5; PSR Specific Direction 17 as consolidated July 2026. All read 2026-09-20. Confidence is held at medium for this facet whatever the strength of the sources, because the content is judgement.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: Pay.UK does not publish the FPS Rules, so the public documents read do not date these provisions", "effective_to": null, "effective_note": "Drafted 2026-09-20 in Orca Core form from Pay.UK's public documents. Pay.UK does not publish the FPS Rules or the FPS Procedures, so when each scheme provision first applied is [Unverified]; the dates given are the editions of the public documents that describe them.", "source_edition": "Faster Payments System Principles v11 (2 January 2026); Pay.UK's 2025 PFMI self-assessment (published November 2025); Pay.UK's Certainty of Fate proposed rule clarification v1.0 (January 2026); Pay.UK's Faster Payment System, transaction limits, participant list and Confirmation of Payee FAQ pages; FPS Reimbursement Rules Schedule 4 v3.0 (26 September 2024); PSR Specific Direction 20 (July 2024) and the two PSR notices of value; PSR Specific Direction 17 as consolidated July 2026; the Payment Services Regulations 2017, Part 7. All read 2026-09-20.", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "rail_name": "Faster Payments (UK)", "governing_authority": "Pay.UK Limited", "snapshot": "2026-09-20", "source_class": null, "effective_status": "draft", "effective_status_reason": null, "boundaries": [] }, { "uid": "uk-fps:finality", "id": "finality", "rail": "uk-fps", "kind": "rail-fact", "facet": "finality", "name": "When is a Faster Payment final, and can it be undone?", "statement": "A Faster Payment is irrevocable the moment the sending institution submits it to the central infrastructure, and the system carries no message for taking one back. Everything after that point, the receiving bank's answer in seconds and the money appearing in the payee's account, happens to a payment that is already fixed. Settlement finality is a second, later moment that concerns the banks and not the payment: the net position becomes irrevocable when the single settlement amount is recorded with the Bank of England's real time gross settlement timestamp, three times on each working day. Faster Payments is designated for settlement finality under the Financial Markets and Insolvency (Settlement Finality) Regulations 1999. The reimbursement rules for scam victims do not disturb any of this: a reimbursement is fresh money from the bank, not an undone payment.", "details": [ { "label": "A payment is irrevocable the moment it reaches the central infrastructure", "value": "The point at which an individual Faster Payment can no longer be taken back is the moment the sending institution submits it to the central infrastructure. Pay.UK states this as the defined point of irrevocability for the system. Nothing later in the payment's life moves that point: acceptance, qualified acceptance and settlement all come after it.", "citation": "2025 PFMI self-assessment of Pay.UK, key consideration 8.1; Faster Payments System Principles, FPS information guide, v11, Required Elements, Revocability", "rests_on": "rule" }, { "label": "The system has no message for taking a payment back", "value": "Faster Payments carries no revocation, recall or cancellation message of any kind. Pay.UK states that after submission no payment can be reversed and that the system has no revocation messaging capability. That is a statement about the system's own design, not about what a bank may do commercially, and it is why money can only come back on this rail as a fresh payment going the other way.", "citation": "2025 PFMI self-assessment of Pay.UK, key consideration 8.1; Faster Payments System Principles, FPS information guide, v11, Required Elements, Revocability", "rests_on": "rule" }, { "label": "Net settlement is final when the single amount carries the real time gross settlement timestamp", "value": "Irrevocability of an individual payment and finality of settlement are two different moments on this rail. A participant's net position becomes irrevocable at the point the single settlement amount is recorded with the timestamp of the Bank of England's real time gross settlement infrastructure. Individual payments have been irrevocable, and the money in customers' accounts, for hours before that.", "citation": "2025 PFMI self-assessment of Pay.UK, key consideration 8.1", "rests_on": "rule" }, { "label": "Faster Payments is designated for settlement finality", "value": "Faster Payments is designated for settlement finality purposes under the Financial Markets and Insolvency (Settlement Finality) Regulations 1999, alongside the other two systems Pay.UK operates. HM Treasury also recognises it under section 184 of the Banking Act 2009, which puts Pay.UK's operation of it under the Bank of England's supervision.", "citation": "2025 PFMI self-assessment of Pay.UK, 2.1", "rests_on": "law" }, { "label": "The reimbursement requirement does not touch settlement finality", "value": "Schedule 4 says in terms that the FPS reimbursement requirement does not affect the settlement finality of payments executed through Faster Payments, and that handling a scam claim does not alter a provider's other legal obligations to its customer. A reimbursement is a fresh payment from the provider's own money to its customer. The original scam payment stands, the receiving customer keeps whatever the fraudster left them, and the money the providers move between themselves afterwards is a contribution and a repatriation, not a reversal.", "citation": "FPS Reimbursement Rules, Schedule 4, v3.0, clause 2.6", "rests_on": "rule" } ], "exceptions": [ "A standing order or a forward dated payment sits with the sending participant until its due date and reaches the infrastructure only then, so a payer may still ask for it to be cancelled up to that point. Whether the participant agrees is its own commercial matter and not a scheme right.", "Money can still come back, as a Return Payment, a recovery attempt or a scam reimbursement. None of those reverses the original payment." ], "applies_to": "Faster Payments in the United Kingdom, in sterling: single immediate payments, standing orders, forward dated payments and Direct Corporate Access payments, among Pay.UK's directly connected settling and non-settling participants and the indirect agencies they carry", "caveat": "Do not read irrevocable as settled. A Faster Payment sent on a Saturday afternoon is irrevocable at once and in the payee's account in seconds, but the banks do not settle it until the first cycle of the next working day. The two moments are hours or days apart, which is the opposite of a rail that settles each payment on its own.", "related": [ "rtp:finality", "fednow:finality", "ch-sic-ip:finality", "uk-fps:settlement", "uk-fps:recall", "uk-fps:liability" ], "basis": { "sources": "Pay.UK 2025 PFMI self-assessment, key consideration 8.1 and section 2.1; Faster Payments System Principles v11, the Revocability row of the Required Elements table; FPS Reimbursement Rules Schedule 4 v3.0, clause 2.6. All read 2026-09-20. Pay.UK's own FPS Rules, which define the point of irrevocability, were not read: they are available to participants only.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: Pay.UK does not publish the FPS Rules, so the public documents read do not date these provisions", "effective_to": null, "effective_note": "Drafted 2026-09-20 in Orca Core form from Pay.UK's public documents. Pay.UK does not publish the FPS Rules or the FPS Procedures, so when each scheme provision first applied is [Unverified]; the dates given are the editions of the public documents that describe them.", "source_edition": "Faster Payments System Principles v11 (2 January 2026); Pay.UK's 2025 PFMI self-assessment (published November 2025); Pay.UK's Certainty of Fate proposed rule clarification v1.0 (January 2026); Pay.UK's Faster Payment System, transaction limits, participant list and Confirmation of Payee FAQ pages; FPS Reimbursement Rules Schedule 4 v3.0 (26 September 2024); PSR Specific Direction 20 (July 2024) and the two PSR notices of value; PSR Specific Direction 17 as consolidated July 2026; the Payment Services Regulations 2017, Part 7. All read 2026-09-20.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.wearepay.uk/wp-content/uploads/2025/11/2025-PFMI-self-assessment-of-Pay.UK_.pdf", "source_class": "public_primary", "source_title": "2025 PFMI self-assessment of Pay.UK", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms irrevocability on submission to the central infrastructure, the later settlement finality moment at the RTGS timestamp, and designation under the Settlement Finality Regulations 1999." }, { "source_url": "https://www.wearepay.uk/wp-content/uploads/2024/09/FPS-Reimbursement-Rules-Schedule-4-v3.0.pdf", "source_class": "authoritative_primary", "source_title": "FPS Reimbursement Rules, Schedule 4, v3.0", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms that the reimbursement requirement does not affect settlement finality." } ] }, "rail_name": "Faster Payments (UK)", "governing_authority": "Pay.UK Limited", "snapshot": "2026-09-20", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "uk-fps:hours", "id": "hours", "rail": "uk-fps", "kind": "rail-fact", "facet": "hours", "name": "When does the rail run, and how fast must a bank answer?", "statement": "Clearing never stops: Faster Payments runs at every hour of every day of the year, including weekends and bank holidays, and a participant must be able to receive and answer every kind of payment without exception. Settlement is the only part tied to the calendar, running three times on each working day. Speed is measured on the sending side: where the payer is present the sending participant must tell them the fate of the payment within 15 seconds, and Pay.UK's own definition of near real time is 10 seconds for 95 in 100 payments and 15 seconds for the rest. Standing orders are the exception to the always-on picture: they run on weekdays only, excluding public holidays in England and Wales, and a participant must submit at least nine in ten of them between midnight and 06:00.", "details": [ { "label": "Clearing runs at every hour of every day", "value": "Faster Payments clears at all hours, every day of the year, including weekends and bank holidays, and has since it launched in 2008. A sending participant may submit a single immediate payment at any time. Participants must be available to receive and answer every type of payment at all hours without exception, and where an incident or planned maintenance gets in the way a participant is expected to stand in so others can keep sending to it, answering with a qualified acceptance. Maintenance is to be scheduled when volumes are lowest.", "citation": "Faster Payments System Principles, FPS information guide, v11, sections 3 and 5.1; Required Elements, Availability to Receive Payments; Pay.UK, Faster Payment System, opening description", "rests_on": "rule" }, { "label": "An attending payer must be told the fate of the payment within 15 seconds", "value": "Where the payer is present, for example paying through internet or mobile banking, the sending participant has to tell them what happened to the payment within 15 seconds. The receiving participant answers through the central infrastructure within seconds, and the 15 second obligation does not stretch when one or two non-settling participants sit in the chain. The obligation holds whichever answer comes back: a sending participant must inform its customer after a qualified acceptance, an unqualified acceptance or a rejection.", "citation": "Faster Payments System Principles, FPS information guide, v11, section 5.1; Required Elements, Fate of Payment", "rests_on": "rule" }, { "label": "Near real time means 10 seconds for 95 in 100 payments and 15 for the rest", "value": "Pay.UK's own definition of near real time for a single immediate payment, as set out in the text of its rule on the fate of a payment, is 10 seconds for 95 percent of payments and 15 seconds for the remaining 5 percent. Pay.UK adds that meeting the timescale must not come at the cost of the accuracy or availability of the information the sending institution gives its customers.", "citation": "Pay.UK's work on Certainty of Fate to support A2A retail transactions: proposed rule clarification, v1.0, annex, rule 9.3.1", "rests_on": "rule" }, { "label": "Standing orders run on weekdays only", "value": "A standing order may only be executed on a weekday that is not a public holiday in England and Wales. Where the due date falls on a weekend or such a holiday, the sending participant holds the payment back to the next working day. This is the one place on the rail where the calendar limits a payment, and it is narrower than the definition of a business day the reimbursement rules use, which excludes a bank holiday in any part of the United Kingdom.", "citation": "Faster Payments System Principles, FPS information guide, v11, section 5.2", "rests_on": "rule" }, { "label": "At least nine in ten standing orders go out between midnight and 06:00", "value": "A sending participant has to process at least 90 percent of its standing orders between midnight and 06:00, and customers should expect the funds by the start of the working day. The exception is a payer who did not have the money: there the retry process takes over and the payment goes later in the day.", "citation": "Faster Payments System Principles, FPS information guide, v11, section 5.2", "rests_on": "rule" }, { "label": "A participant retries a standing order or forward dated payment later the same day", "value": "Where the payer did not have the money when the sending participant first ran its standing orders or forward dated payments, the participant retries later in the day to give the payer a chance to pay funds in. Pay.UK states that this is required by the Financial Conduct Authority. For an attended single immediate payment there is no such obligation: the payer has to ensure the funds are there or have made another arrangement, and whether the participant retries at all is its own commercial choice.", "citation": "Faster Payments System Principles, FPS information guide, v11, sections 5.1, 5.2 and 5.3; Required Elements, Paying Customer Funds", "rests_on": "guidance" } ], "exceptions": [ "Where an incident or planned maintenance stops normal processing, a participant is expected to stand in so others can keep sending to it, answering with a qualified acceptance.", "A small share of attended payments may be held for fraud or money laundering investigation before submission, and the sending participant must tell its customer that the payment has not yet been made.", "The payment types use two different calendars. Standing orders exclude public holidays in England and Wales; the reimbursement rules use a business day that excludes a bank holiday in any part of the United Kingdom." ], "applies_to": "Faster Payments in the United Kingdom, in sterling: single immediate payments, standing orders, forward dated payments and Direct Corporate Access payments, among Pay.UK's directly connected settling and non-settling participants and the indirect agencies they carry", "caveat": "The 15 second and 10 second figures are obligations on the sending participant to tell its customer what happened, not promises about when the payee's account is credited. A qualified acceptance means the payment succeeded and the money may arrive later.", "related": [ "uk-fps:settlement", "uk-fps:messages", "uk-fps:decision-points" ], "basis": { "sources": "Faster Payments System Principles v11, sections 3, 5.1, 5.2 and 5.3 and the Availability to Receive Payments, Fate of Payment and Paying Customer Funds rows of the Required Elements table; Pay.UK's Certainty of Fate proposed rule clarification, annex rule 9.3.1; Pay.UK's Faster Payment System page. All read 2026-09-20. The FPS Procedures timetable, which the rules point at, was not read.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: Pay.UK does not publish the FPS Rules, so the public documents read do not date these provisions", "effective_to": null, "effective_note": "Drafted 2026-09-20 in Orca Core form from Pay.UK's public documents. Pay.UK does not publish the FPS Rules or the FPS Procedures, so when each scheme provision first applied is [Unverified]; the dates given are the editions of the public documents that describe them.", "source_edition": "Faster Payments System Principles v11 (2 January 2026); Pay.UK's 2025 PFMI self-assessment (published November 2025); Pay.UK's Certainty of Fate proposed rule clarification v1.0 (January 2026); Pay.UK's Faster Payment System, transaction limits, participant list and Confirmation of Payee FAQ pages; FPS Reimbursement Rules Schedule 4 v3.0 (26 September 2024); PSR Specific Direction 20 (July 2024) and the two PSR notices of value; PSR Specific Direction 17 as consolidated July 2026; the Payment Services Regulations 2017, Part 7. All read 2026-09-20.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.wearepay.uk/wp-content/uploads/2026/02/Pay.UK-Faster-Payments-System-Principles-v-11-Jan-2026.pdf", "source_class": "public_primary", "source_title": "Faster Payments System Principles, FPS information guide, v11", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms 24 hour every day clearing, the 15 second fate window, the standing order weekday and 90 percent before 06:00 rules, and the same day retry on insufficient funds." }, { "source_url": "https://www.wearepay.uk/wp-content/uploads/2026/01/Pay.UK-CoF-Proposed-Rule-Clarification-January-2026.pdf", "source_class": "public_primary", "source_title": "Pay.UK's work on Certainty of Fate to support A2A retail transactions: proposed rule clarification, v1.0", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms the near real time definition of 10 seconds for 95 percent of payments and 15 seconds for the rest." } ] }, "rail_name": "Faster Payments (UK)", "governing_authority": "Pay.UK Limited", "snapshot": "2026-09-20", "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "uk-fps:liability", "id": "liability", "rail": "uk-fps", "kind": "rail-fact", "facet": "liability", "name": "Who bears the loss when a Faster Payment goes wrong?", "statement": "For an authorised push payment scam, both banks do, and by rule. Since 7 October 2024 the provider that holds the account the money was paid from must reimburse the victim in full when the claim is reimbursable, and the provider that received the money must pay back half, apportioned where the scam reached several. The ceiling is GBP 85,000 for each claim and across linked claims, and the sending provider may deduct a single excess of up to GBP 100, but not from a vulnerable consumer whose vulnerability affected their ability to protect themselves. Both figures are set by the regulator's notices, not by the scheme rule, and the regulator may change either at any time. The clock is five business days, but it can be stopped as often as needed on six listed grounds, and the real longstop is the 35th business day, by which the claim must be decided and closed. The receiving provider gets three business days to volunteer information, should answer an information request by the end of the 25th business day, and pays the contribution within five business days of being told it is due. Money recovered from the fraudster later is shared so that nobody gets back more than they paid out, and the claim stays dormant up to 13 months waiting for that. A claim reported more than 13 months after the last payment is out of the regime, and anything paid outside the regime is voluntary: the receiving provider owes nothing toward it.", "details": [ { "label": "The sending provider must reimburse a scam victim in full", "value": "When a victim reports a reimbursable authorised push payment scam payment to the provider that holds the account it was paid from, that provider must reimburse them in full. This is the FPS reimbursement requirement, and it is a duty on the provider whether or not that provider is a member of the Faster Payments scheme. It covers payments executed from 7 October 2024 onward. A scam payment here is one the consumer authorised and the fraudster procured: it is executed to the account the consumer named, but either the recipient is not who the consumer meant to pay, or the payment is for a purpose the consumer did not intend. A consumer who is party to the fraud is not a victim.", "citation": "FPS Reimbursement Rules, Schedule 4, v3.0, clauses 3.1, 3.2, 3.10, 3.11 and 10.4 (APP scam); PSR Specific Direction 20 (July 2024), FPS APP scam reimbursement requirement, paragraphs 3.1, 3.2 and 4.1", "rests_on": "rule" }, { "label": "The requirement covers a UK consumer account paying a UK account", "value": "For a payment to be in scope it must have all of five features: the victim is a customer of the sending provider, holds a relevant account with it and holds that account as a consumer; the payment is executed from a relevant account located in the United Kingdom; the transfer settles through Faster Payments; it is received into a relevant account under the control of a receiving provider in the United Kingdom that the consumer does not control; and it goes to the account the consumer named but not to the intended recipient or not for the intended purpose. A relevant account is one provided to a service user, held in the United Kingdom and reachable by Faster Payments, but accounts at credit unions, municipal banks and national savings banks are excluded. A consumer means an individual, a microenterprise under ten people whose turnover or balance sheet total is no more than two million euro, or a charity with annual income under one million pounds.", "citation": "FPS Reimbursement Rules, Schedule 4, v3.0, clauses 3.10 and 10.4 (Relevant account, Consumer, Account controlled by the consumer)", "rests_on": "rule" }, { "label": "Gross negligence against four standards can cost the consumer the right", "value": "A provider need not reimburse where the consumer standard of caution exception applies, which is where the sending provider can show that the consumer, through gross negligence, fell short of one or more of four standards: heeding an intervention by their provider or a competent national authority; reporting the scam promptly once they learn or suspect it; answering reasonable and proportionate requests for information made for the purposes the stop the clock provision lists; and consenting to the provider reporting to the police on their behalf, or reporting to a competent national authority themselves. The bar is gross negligence, not ordinary carelessness. The exception does not apply at all where the victim was a vulnerable consumer when they made at least one of the payments and that had a material effect on their ability to protect themselves. A competent national authority means a police force, Police Scotland, the Police Service of Northern Ireland, the National Crime Agency, or another body the regulator identifies by guidance.", "citation": "FPS Reimbursement Rules, Schedule 4, v3.0, clauses 3.6, 3.11(1) and 10.4 (Competent National Authority, Consumer Standard of Caution Exception)", "rests_on": "rule" }, { "label": "Five further tests a claim has to pass", "value": "Besides the standard of caution, a sending provider assessing a claim must satisfy itself that the victim is not party to the fraud, is not claiming fraudulently or dishonestly, is not claiming for an amount that is the subject of a private civil dispute, and did not pay the money for an unlawful purpose. A private civil dispute means a disagreement between a consumer and a payee that belongs in the civil courts rather than involving criminal fraud or dishonesty, which is the line between a scam and a bad bargain. The claim must also have been reported no more than 13 months after the last payment in it and not before 7 October 2024.", "citation": "FPS Reimbursement Rules, Schedule 4, v3.0, clauses 3.11(2) to 3.11(6) and 10.4 (Private civil dispute)", "rests_on": "rule" }, { "label": "A claim reported more than 13 months after the last payment is out of the regime", "value": "A provider need not reimburse payments reported more than 13 months after the date of the final scam payment in the claim, nor payments made before 7 October 2024, and that is so whether or not the consumer was assessed as vulnerable. The 13 months run from the last payment of the claim, not the first, so a scam that ran for months is measured from its end. The consumer is expected to report as quickly as they can. If a provider pays outside the limit anyway, that is a voluntary reimbursement.", "citation": "FPS Reimbursement Rules, Schedule 4, v3.0, clauses 3.4, 3.8 and 3.11(6)", "rests_on": "rule" }, { "label": "The receiving provider must be told within two business hours", "value": "As soon as a consumer reports a scam claim, the sending provider has two business hours to tell the receiving provider, through the claims management system where it can. A business hour here means an hour between 9 in the morning and 5 in the evening on a business day, so a claim reported at the weekend or overnight starts its two hours when the next business day opens. What has to be sent is the sort code and account number the money left, the sort codes and account numbers and any secondary reference data of the accounts it went to whether or not the sending provider has confirmed they are in the United Kingdom, the amounts of every payment in the claim, the date and time the consumer reported it, and any reasonable evidence the sending provider holds that the payment did not reach the intended recipient or was received for another purpose. This is the shortest deadline on the rail.", "citation": "FPS Reimbursement Rules, Schedule 4, v3.0, clauses 4.1 and 10.4 (Business hours)", "rests_on": "rule" }, { "label": "The receiving provider has three business days to volunteer what it knows", "value": "Once a claim has been reported, the receiving provider may send the sending provider anything it thinks relevant, up to the end of the third business day after the report. This is an opportunity, not a duty. Its bite is on the other side: the sending provider cannot complete its assessment until either that period has run out or every receiving provider has answered, and it cannot close the claim or send the contribution request before then. A sending provider may still choose to pay the victim early, but it must go on to complete the assessment taking account of whatever the receiving providers said, and it may not ask for a contribution toward payments that turn out not to be reimbursable.", "citation": "FPS Reimbursement Rules, Schedule 4, v3.0, clauses 4.2, 4.3(1), 4.11 and 4.13", "rests_on": "rule" }, { "label": "Five business days to pay the victim, unless the clock is stopped", "value": "The sending provider has to assess the claim and pay whatever is reimbursable to the victim within five business days of the victim reporting it, unless it stops the clock. A business day for this purpose is any day that is not a Saturday, a Sunday or a bank holiday in any part of the United Kingdom. Reading the five days as a hard deadline is a mistake: it can be paused, repeatedly, and the real longstop is the 35th business day.", "citation": "FPS Reimbursement Rules, Schedule 4, v3.0, clauses 3.3, 4.3(2), 4.14 and 10.4 (Business day)", "rests_on": "rule" }, { "label": "Six grounds let the sending provider stop the clock, as often as needed", "value": "The five business day clock may be paused only where the sending provider has asked for more information, and only for as long as that takes. The six permitted reasons are: getting information from the consumer or their agent to decide whether the claim is reimbursable; getting it from the receiving provider for the same purpose; checking that an agent is bringing a legitimate claim, for instance that the consumer authorised the company to act; getting more from the consumer on whether they were vulnerable when they made the payments; where the provider has evidence of fraud by the person claiming, getting more from the receiving provider, law enforcement or others; and, where several providers are involved, getting more from all of them. The clock restarts when the sending provider has everything it asked for and is not asking anyone else for anything. Where several requests are open at once the clock stays stopped until the last answer arrives. The provider may stop the clock as many times as it needs. The sending provider must keep a record of each assessment.", "citation": "FPS Reimbursement Rules, Schedule 4, v3.0, clauses 4.5, 4.6, 4.8, 4.9 and 4.10", "rests_on": "rule" }, { "label": "An information request should be answered by the end of the 25th business day", "value": "A receiving provider asked for information about a claim must answer accurately and as soon as it can. Schedule 4 recommends that this be no later than the end of the 25th business day after the consumer or their agent reported the claim, and requires the sending provider to tell the receiving provider what the final business day to answer is. The word the rule uses is recommended, so this reads as a strong expectation rather than a hard deadline, while the duty to answer accurately and promptly is not qualified.", "citation": "FPS Reimbursement Rules, Schedule 4, v3.0, clause 4.7", "rests_on": "rule" }, { "label": "Whatever happens, the claim is decided and closed by the 35th business day", "value": "However many times the clock is stopped, the sending provider must complete its assessment, decide whether to reimburse, and close the claim before the end of the 35th business day after the consumer or their agent reported it. This is the real outer limit of the regime and the figure a consumer waiting on a stalled claim needs. A claim may not be closed until the assessment is done and the opportunity to respond has ended, and then only when either the victim has been paid for the reimbursable payments or the claim has been rejected because there were none.", "citation": "FPS Reimbursement Rules, Schedule 4, v3.0, clauses 4.9, 4.13 and 10.4 (Claim closed)", "rests_on": "rule" }, { "label": "The consumer is told the outcome in writing either way", "value": "Where the sending provider decides the payments are reimbursable it must tell the victim in writing, credit the account the victim holds with it, and where the amount is less than the total of the reimbursable payments explain why. Where it decides they are not, it must tell the consumer in writing that they do not meet the test and, so far as the law lets it, give a summary of its reasons. In both cases it must notify the receiving provider within one business day of telling the consumer: on a positive decision that notification is the request for the contribution, and on a negative one it confirms the reason for rejecting the payment. Any further payments found to belong to the same scam after the first report have to be raised as a new claim referencing the first, and no new excess may be applied to a linked claim.", "citation": "FPS Reimbursement Rules, Schedule 4, v3.0, clauses 4.4, 4.11 and 4.12", "rests_on": "rule" }, { "label": "Nothing above GBP 85,000 per claim has to be reimbursed", "value": "A provider is not required to reimburse above the maximum level of reimbursement, and that is so whether or not the consumer was assessed as vulnerable. The figure is GBP 85,000 and the ceiling applies to each claim, and across all claims linked to the same scam. It is set by the regulator rather than by the scheme: the notice of value says the figure does not move with inflation or any other measure, that the regulator keeps it under review, and that it stays in force until varied or revoked, so the number must be read from the notice and not from Schedule 4. Anything paid above it is a voluntary reimbursement and the receiving provider owes nothing toward it.", "citation": "PSR Specific Requirement 1, notice of maximum reimbursement level value, September 2024, paragraphs 1.1 to 1.3; FPS Reimbursement Rules, Schedule 4, v3.0, clauses 3.7, 4.4 and 4.15ii", "rests_on": "rule" }, { "label": "A provider may deduct an excess of up to GBP 100, once per claim", "value": "A sending provider may apply a single excess to each claim, up to the maximum the regulator sets by notice, which is GBP 100. It may apply that figure, a smaller one, or none at all. Only one excess may be applied across claims linked to the same scam. Like the ceiling, the figure comes from the regulator's notice, which says it does not move with inflation or any other measure and stays in force until varied or revoked. The amount the victim gets is the full value of the reimbursable payments, up to the ceiling, less any excess.", "citation": "PSR Specific Requirement 1, notice of maximum excess value, December 2023, paragraphs 1.1 to 1.3; FPS Reimbursement Rules, Schedule 4, v3.0, clauses 4.15 and 4.15i and clause 4.4", "rests_on": "rule" }, { "label": "No excess may be taken from a vulnerable consumer, though the ceiling still applies", "value": "A sending provider may not apply an excess where the victim was a vulnerable consumer when they made at least one of the payments in the claim and that vulnerability affected their ability to protect themselves from the scam. The ceiling is the opposite: it applies whether or not the consumer was assessed as vulnerable. Two rules about vulnerability that read alike and point in different directions. Vulnerable consumer takes the meaning the Financial Conduct Authority gives it in its guidance on the fair treatment of vulnerable customers, someone who because of their circumstances is especially open to harm, particularly where a firm is not taking appropriate care.", "citation": "FPS Reimbursement Rules, Schedule 4, v3.0, clauses 3.7, 4.15iii and 10.4 (Vulnerable Consumer)", "rests_on": "rule" }, { "label": "The receiving provider pays back half, split by where the money went", "value": "The receiving provider owes the sending provider a contribution worked out as a share of half the reimbursable amount. Where the scam sent money to more than one receiving provider, each one's share is the value of reimbursable payments it received divided by the value of all reimbursable payments in the claim. The sending provider calculates it and must substantiate the calculation with the claim data. Where the sending provider chooses not to apply the maximum excess and the victim is not vulnerable, the contribution is instead a share of half the lower of two figures: the maximum reimbursable amount reduced by the maximum excess value, or the total of all reimbursable payments in the claim reduced by the maximum excess value. The 50 percent split is not a general principle of the rail: it attaches only to reimbursable amounts.", "citation": "FPS Reimbursement Rules, Schedule 4, v3.0, clauses 5.1, 5.3, 5.4, 5.5, 5.6 and 5.9", "rests_on": "rule" }, { "label": "The contribution is paid within five business days of being asked", "value": "The receiving provider has five business days from the sending provider's notification to pay the contribution, and it pays it over Faster Payments. It then has to update the claim record to confirm payment, at which point the claim is closed but pending repatriation. A sending provider may not ask for the contribution before it has submitted the outcome of its assessment and confirmation that the victim has been paid, or where the claim is not substantiated by the required data.", "citation": "FPS Reimbursement Rules, Schedule 4, v3.0, clauses 3.5, 5.7, 5.8 and 5.9", "rests_on": "rule" }, { "label": "Anything paid outside the rules is voluntary, and the receiving side owes nothing toward it", "value": "A voluntary reimbursement is anything a sending provider pays beyond what the rules require: above the ceiling, on a claim reported more than 13 months after the final payment, on a payment made before 7 October 2024, or after the claim was closed, whether closed by reimbursement or by rejection. That includes a payment made because a court or an alternative dispute resolution body decided the matter after the claim was closed. A voluntary reimbursement falls outside the reimbursement requirement and outside the rules, and the receiving provider is not liable to pay any part of it. A provider paying generously is paying alone.", "citation": "FPS Reimbursement Rules, Schedule 4, v3.0, clauses 3.7, 3.8, 3.9, 5.2 and 10.4 (Voluntary reimbursement)", "rests_on": "rule" }, { "label": "Money recovered is shared so nobody profits", "value": "Where a receiving provider freezes and returns money that was paid away in a scam, who gets it depends on what has already been paid. If the sending provider has not yet reimbursed the victim, everything recovered goes back to the sending provider to credit the victim's account. If the victim has been reimbursed and the contribution has been paid, the recovered money goes first to the sending provider up to the reimbursable amount less the contribution, then to the receiving provider up to the contribution, and any remainder to the victim. Schedule 4 states the governing principle plainly: no party should receive back more than they paid out. All of this yields to any different instruction from a court, a regulator, law enforcement or a disputes body.", "citation": "FPS Reimbursement Rules, Schedule 4, v3.0, clauses 6.1, 6.2 and 6.3", "rests_on": "rule" }, { "label": "Recovered money moves within three business days of the receiving provider finishing its investigations", "value": "The clock on repatriation does not start when the claim is made. It starts when the receiving provider has concluded all its internal investigations and approvals and worked out what is payable; only then must it execute the payment over Faster Payments within three business days and tell the sending provider the value and the calculation. When those investigations conclude is the receiving provider's own matter, and no source read puts a limit on it. The claim stays dormant for up to 13 months after the contribution was paid to allow for recovery, and after that it moves from dormant to closed without repatriation. If money comes back later than that the receiving provider must tell the operator.", "citation": "FPS Reimbursement Rules, Schedule 4, v3.0, clauses 6.4 and 6.5 and 10.4 (Claim closed, pending repatriation)", "rests_on": "rule" }, { "label": "The reimbursement rules bind providers that are not scheme members", "value": "Schedule 4 applies to every directed provider whether or not it is a member of Faster Payments and party to the FPS Rules, and the regulator's direction says in terms that it did this so that members and non-members, and their consumers, are as far as possible on an equal footing. Every directed provider had to register with the operator by 20 August 2024 so it could be identified in the reimbursement directory, and to be onboarded to the claims management system by 20 September 2024, with a further stage proposed for 1 May 2025. A provider joining later must register before it sends or receives live traffic. A sponsoring settling participant is not answerable for a provider it sponsors, unless it controls that provider's access to the claim funds; otherwise every directed provider answers to Pay.UK for its own compliance.", "citation": "FPS Reimbursement Rules, Schedule 4, v3.0, section 3 Application; clauses 2.2, 2.3, 2.4 and 2.5; PSR Specific Direction 20 (July 2024), FPS APP scam reimbursement requirement, paragraphs 1.5, 8.1, 8.3 and 10.1", "rests_on": "rule" }, { "label": "Schedule 4 is part of the FPS Rules but the regulator, not Pay.UK, enforces it", "value": "Schedule 4 is incorporated into and forms part of the FPS Rules, Rules for the Faster Payments Service, which makes it a clause of the rulebook, and the rest of the rulebook's terms apply to it. Four things change. Where Schedule 4 conflicts with the rest of the rulebook, Schedule 4 governs. Enforcement passes from Pay.UK to the Payment Systems Regulator under its powers in the Financial Services (Banking Reform) Act 2013. Reporting and notification obligations are additional to the rulebook's, and notifications follow Schedule 4's own procedures. And Pay.UK may amend Schedule 4 only on a direction or requirement of the regulator, unless the change is purely administrative or technical. Nothing in Schedule 4 prejudices a conflicting obligation a provider has under other United Kingdom law. Anyone citing this material should name both bodies: the rule is Pay.UK's and the instrument behind it is the regulator's.", "citation": "FPS Reimbursement Rules, Schedule 4, v3.0, clauses 9.1, 9.2 and 9.3 and clause 2.1", "rests_on": "rule" }, { "label": "Pay.UK monitors compliance and reports it to the regulator", "value": "Under a separate direction the regulator gives Pay.UK the job of monitoring how well directed providers keep to the reimbursement rules: building and running the arrangements, watching the nature, extent and effectiveness of compliance, improving it where it has the power to, gathering data from providers, and reporting to the regulator on what it finds. The information providers must collate, retain and hand over is specified by the regulator in its compliance data reporting standards, and sending providers report through the claims management system. Every directed provider must keep the information for at least five years, take reasonable steps to assure its accuracy, answer reasonable and proportionate requests from the operator, and hold it securely. Reports cover the claims closed in each month and are due by close of business on the last business day of the following month, including a nil return where a provider had no claims. Each sending provider can watch its own performance on a compliance dashboard. Pay.UK may use what it collects only for this monitoring, and may disclose confidential information only to the regulator or where a statutory obligation, another regulator or a court order requires it.", "citation": "FPS Reimbursement Rules, Schedule 4, v3.0, section 7 and clauses 11.1 to 11.4; PSR Specific Direction 20 (July 2024), FPS APP scam reimbursement requirement, paragraphs 8.4 to 8.7 and 9.1 to 9.9", "rests_on": "rule" } ], "exceptions": [ "The regime covers only a consumer payment from a relevant account in the United Kingdom to a relevant account in the United Kingdom that the consumer does not control, settled through Faster Payments. Accounts at credit unions, municipal banks and national savings banks are outside it.", "A consumer here can be an individual, a microenterprise under ten people, or a small charity, so this is not a consumers-only regime in the ordinary sense.", "Where the consumer standard of caution exception applies through gross negligence, or the victim is party to the fraud, is claiming dishonestly, is in a private civil dispute, or paid for an unlawful purpose, there is no duty to reimburse. The standard of caution exception falls away entirely for a vulnerable consumer whose vulnerability had a material effect.", "A sponsoring settling participant is not answerable for a provider it sponsors, unless it controls that provider's access to the claim funds.", "Outside the scam regime, liability for a payment that failed or went to the wrong place is statutory rather than scheme based, and sits in the refund and consumer-law facts." ], "applies_to": "every payment service provider that participates in Faster Payments and provides relevant accounts in the United Kingdom, whether or not it is a member of the scheme, for consumer payments made from 7 October 2024 out of a UK account into a UK account", "caveat": "Two traps. First, five business days is not a deadline you can rely on: the clock stops on any of six grounds, as often as needed, and the number that binds is the 35th business day. Second, the ceiling and the excess are not in the scheme rule. Schedule 4 points at the regulator's notices for both and says the regulator may change them at any time, so cite the notice for the figures and check it before quoting GBP 85,000 or GBP 100.", "related": [ "us-ach:liability", "sepa-sct-inst:liability", "rtp:liability", "uk-fps:consumer-law", "uk-fps:refund", "uk-fps:finality", "uk-fps:decision-points" ], "basis": { "sources": "FPS Reimbursement Rules Schedule 4 v3.0, sections 2 to 7 and the definitions in clause 10.4, which clause 9.1 states is incorporated into and forms part of the FPS Rules; PSR Specific Direction 20 (July 2024); the PSR notices of maximum reimbursement level value (September 2024) and maximum excess value (December 2023). All read 2026-09-20 and cited by clause and paragraph. This is the operative scheme rule itself, which is why this fact reaches high confidence where the rest of the rail cannot.", "confidence": "high" }, "currency": { "effective_since": "2024-10-07", "effective_to": null, "effective_note": "The FPS reimbursement requirement took effect on 7 October 2024 (Schedule 4 clauses 2.1, 3.2 and section 8, and Specific Direction 20 paragraphs 3.2 and 4.1). Schedule 4 may be amended by Pay.UK only on a direction or requirement of the Payment Systems Regulator, except for administrative or technical changes (clause 9.2.5). The regulator may change the reimbursement ceiling and the excess by notice at any time.", "source_edition": "Faster Payments System Principles v11 (2 January 2026); Pay.UK's 2025 PFMI self-assessment (published November 2025); Pay.UK's Certainty of Fate proposed rule clarification v1.0 (January 2026); Pay.UK's Faster Payment System, transaction limits, participant list and Confirmation of Payee FAQ pages; FPS Reimbursement Rules Schedule 4 v3.0 (26 September 2024); PSR Specific Direction 20 (July 2024) and the two PSR notices of value; PSR Specific Direction 17 as consolidated July 2026; the Payment Services Regulations 2017, Part 7. All read 2026-09-20.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.wearepay.uk/wp-content/uploads/2024/09/FPS-Reimbursement-Rules-Schedule-4-v3.0.pdf", "source_class": "authoritative_primary", "source_title": "FPS Reimbursement Rules, Schedule 4, v3.0", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms the reimbursement mechanics stated: full reimbursement by the sending provider, the half contribution from the receiving provider, the 85,000 pound ceiling and 100 pound excess figures as set by the regulator's notices rather than the scheme rule, the five and 35 business day clocks, the three and 25 business day receiving provider windows, the repatriation apportionment, and the 13 month reporting limit." } ] }, "rail_name": "Faster Payments (UK)", "governing_authority": "Pay.UK Limited", "snapshot": "2026-09-20", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "uk-fps:limits", "id": "limits", "rail": "uk-fps", "kind": "rail-fact", "facet": "limits", "name": "How much can one Faster Payment carry?", "statement": "There is one ceiling for the whole system and the central infrastructure enforces it: GBP 1,000,000 for a single payment, up from GBP 250,000 in February 2022. A payment above it is rejected by the infrastructure, not by the receiving bank. That is the most a payment may be, not the most a customer may send. Every organisation offering the service sets its own limits, which differ by channel and by the kind of account the money comes from, and some also cap how much may go in a day. Pay.UK publishes each directly connected organisation's personal and business limits by channel. An indirect agency may be held to whatever its sponsor allows. Where a transaction limit stops the whole of a received payment being sent back as one Return Payment, the two institutions have to agree another way; the limit is not a reason to keep the money.", "details": [ { "label": "The central infrastructure rejects a payment above GBP 1,000,000", "value": "There is one value ceiling for the whole system and the central infrastructure enforces it: a payment above it is rejected by the infrastructure itself, not by the receiving bank. The current figure is GBP 1,000,000, raised from GBP 250,000 in February 2022.", "citation": "2025 PFMI self-assessment of Pay.UK, 2.2.2 and its footnote 7; Pay.UK, Faster Payment System transaction limits, opening paragraph; Faster Payments System Principles, FPS information guide, v11, Required Elements, Limits (Individual Payment Amount)", "rests_on": "rule" }, { "label": "A participant may set a lower limit, and most do", "value": "The system ceiling is the most a payment may be, not the most a customer may send. Every organisation offering the service sets its own limits, and they differ by how the payment is sent and by the kind of account it is sent from. Pay.UK publishes each directly connected organisation's personal and business limits by channel, and notes that some also cap how much may be sent in a day. An indirect agency may be held to whatever its sponsor allows. Nothing in the documents read says a receiving participant may not set a lower limit of its own.", "citation": "Pay.UK, Faster Payment System transaction limits, opening paragraphs and the per organisation tables; Faster Payments System Principles, FPS information guide, v11, Required Elements, Limits (Individual Payment Amount)", "rests_on": "rule" }, { "label": "A limit that blocks a full return has to be worked around by agreement", "value": "Where transaction limits stop the whole of a received payment being returned as one Return Payment, the institution sending the money back must contact the originating institution and agree how the funds are to be returned. The limit does not excuse keeping the money, and it does not permit a partial Return Payment.", "citation": "Pay.UK's work on Certainty of Fate to support A2A retail transactions: proposed rule clarification, v1.0, annex, rule 10.1", "rests_on": "rule" } ], "exceptions": [ "Nothing in the documents read bars a receiving participant from setting a lower limit of its own, which is the opposite of what some other instant rails say [Inference: this is an absence in the sources, not a statement].", "The per participant figures Pay.UK publishes are commercial settings that move without notice and carry no date on the page." ], "applies_to": "Faster Payments in the United Kingdom, in sterling: single immediate payments, standing orders, forward dated payments and Direct Corporate Access payments, among Pay.UK's directly connected settling and non-settling participants and the indirect agencies they carry", "caveat": "Never quote a per participant limit from this record as current. The system ceiling is a scheme figure; every number below it belongs to a bank and can change the day after it is read.", "related": [ "rtp:limits", "fednow:limits", "nct-inst:limits", "uk-fps:return", "uk-fps:liability" ], "basis": { "sources": "Pay.UK 2025 PFMI self-assessment, section 2.2.2 and its footnote 7; Pay.UK's Faster Payment System transaction limits page; Faster Payments System Principles v11, the Limits row of the Required Elements table; Pay.UK's Certainty of Fate proposed rule clarification, annex rule 10.1. All read 2026-09-20.", "confidence": "medium" }, "currency": { "effective_since": "2022-02-01", "effective_to": null, "effective_note": "Pay.UK's 2025 PFMI self-assessment, footnote 7, gives February 2022 as the month the system ceiling rose from GBP 250,000 to GBP 1,000,000 and gives no day. The first of that month is Orca's placeholder so the field can hold a date, and is not a date any source states [Inference]. The per participant limits Pay.UK publishes carry no date at all and were read on 2026-09-20.", "source_edition": "Faster Payments System Principles v11 (2 January 2026); Pay.UK's 2025 PFMI self-assessment (published November 2025); Pay.UK's Certainty of Fate proposed rule clarification v1.0 (January 2026); Pay.UK's Faster Payment System, transaction limits, participant list and Confirmation of Payee FAQ pages; FPS Reimbursement Rules Schedule 4 v3.0 (26 September 2024); PSR Specific Direction 20 (July 2024) and the two PSR notices of value; PSR Specific Direction 17 as consolidated July 2026; the Payment Services Regulations 2017, Part 7. All read 2026-09-20.", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "rail_name": "Faster Payments (UK)", "governing_authority": "Pay.UK Limited", "snapshot": "2026-09-20", "source_class": null, "effective_status": "draft", "effective_status_reason": null, "boundaries": [] }, { "uid": "uk-fps:messages", "id": "messages", "rail": "uk-fps", "kind": "rail-fact", "facet": "messages", "name": "What does a Faster Payment look like on the wire, and what codes come back?", "statement": "Faster Payments runs on ISO 8583, not ISO 20022. Pay.UK has scoped moving the single immediate payment standard to ISO 20022 under the National Payments Vision and no document read gives a date. There is no pacs.008, no pacs.002 and no camt message on this rail; fields are numbered tags, with 35 the payee account number, 42 the originating credit institution, 62 an end to end reference of up to 31 characters, 120 reference information of up to 18 characters and 121 remittance information of up to 140 characters. Every payment gets one of three answers within a few seconds: unqualified acceptance, qualified acceptance with a qualifier code, or rejection with a rejection code. Where an unqualified acceptance is possible the infrastructure indicates code 0000, accepted without qualification. The code lists themselves are not published: they live in the FPS Procedures, Appendix B, FPS Codes, with qualifier codes at section 7 and institution rejection codes at section 8.2, and Pay.UK makes the Procedures available to participants' legal departments only.", "details": [ { "label": "Faster Payments runs on ISO 8583, not ISO 20022", "value": "This is the single most important thing to know about the rail's messages. Pay.UK states that Faster Payments uses ISO 8583, which it describes as an internationally accepted standard open and accessible under ISO governance, while Bacs uses its own format and the Image Clearing System a proprietary standard based on ISO 20022. Pay.UK has defined the scope and requirements to move the single immediate payment standard to ISO 20022 under the National Payments Vision, and no document read gives a date for that. There is no pacs.008, no pacs.002, no pacs.004, no camt.056 and no camt.029 on this rail; the fields are numbered tags. Pay.UK sets the standard as part of the rules and mandates its use.", "citation": "2025 PFMI self-assessment of Pay.UK, key consideration 22.1; Faster Payments System Principles, FPS information guide, v11, Required Elements, Account Statement, Payment Information, Error Checking (Receiving Participant); section 10.2", "rests_on": "rule" }, { "label": "Every payment gets one of three answers, and one of them is neither yes nor no", "value": "For each Faster Payment it receives, a directly connected participant must respond within a few seconds with an unqualified acceptance, a qualified acceptance carrying a qualifier code, or a rejection carrying a rejection code. An unqualified acceptance means the funds will reach the payee in near real time, though they could take longer within the availability window. A qualified acceptance means the payment passed initial error checking but the money may not be there in near real time or within that window: the payment succeeded and the money is late. It is not a soft rejection, and the sending participant must still tell its customer. Pay.UK restricts the proportion of payments a participant may qualify, and its stated objective is to maintain 95 percent unqualified acceptance.", "citation": "Faster Payments System Principles, FPS information guide, v11, Required Elements, Availability of Funds to the Beneficiary, Fate of Payment, Customer Messaging; Pay.UK's work on Certainty of Fate to support A2A retail transactions: proposed rule clarification, v1.0, section 3 and annex, rules 6.2 and 9.3.1", "rests_on": "rule" }, { "label": "A qualified acceptance signals one of five timescales, and the code values are not public", "value": "Where a receiving participant accepts with a qualification, the qualifier code tells the sending side when the funds will be available. Pay.UK publishes the five timescales a qualifier code can signal: the same day, the next calendar day, the next working day, an unspecified time and date within Payment Services Directive guidelines, and after the next working day within those guidelines. It does not publish the code values. They sit in the FPS Procedures, Appendix B, FPS Codes, at section 7.", "citation": "Faster Payments System Principles, FPS information guide, v11, Required Elements, Availability of Funds to the Beneficiary; Pay.UK's work on Certainty of Fate to support A2A retail transactions: proposed rule clarification, v1.0, annex, rules 6.2a, 6.2b and 9.3.1", "rests_on": "rule" }, { "label": "The code lists live in a document Pay.UK does not publish", "value": "A receiving institution must specify the rejection code in its response if it rejects a payment, and must specify the return reason on a Return Payment. Pay.UK names where those lists live: FPS Procedures, Appendix B, FPS Codes, with qualifier codes at section 7 and FPS institution rejection codes at section 8.2. It does not publish the Procedures. Pay.UK's own assessment says the FPS rules and procedures are available for review by participants' legal departments and that the website carries only the list of system documentation. Where an unqualified acceptance is possible the infrastructure indicates code 0000, accepted without qualification, which is the one code value in any public document read here. Orca holds the codes two independent public source families agree on, in separate directories, and nothing else.", "citation": "Pay.UK's work on Certainty of Fate to support A2A retail transactions: proposed rule clarification, v1.0, annex, rules 6.2a, 6.2b, 9.3.1 and 10.1; 2025 PFMI self-assessment of Pay.UK, key consideration 23.1", "rests_on": "rule" }, { "label": "What a payment can carry, and what the payee must be shown", "value": "A payment may carry up to 18 characters of reference information in tag 120. Two further fields are competitive, meaning each participant chooses whether to offer them: a 31 character end to end reference for the payer in tag 62 and 140 characters of remittance information in tag 121. Where they are present the receiving provider must be able to give the information to its customer, either without being asked or on request. As a minimum the credit on the payee's statement must show the date of posting, the amount, the remitter's name and any reference information in tag 120. The sender must quote the payee's sort code, account number and name on every payment.", "citation": "Faster Payments System Principles, FPS information guide, v11, Required Elements, Account Statement, Payment Information, Beneficiary Account Details", "rests_on": "rule" }, { "label": "A payment drawn on an overseas account is marked only by a BIC in one field", "value": "A Faster Payment can carry money originally drawn on an account held outside the United Kingdom. The only way the receiving provider can tell is that the originating credit institution field, tag 42, holds a bank identifier code instead of a sort code. Pay.UK warns that failing to populate that field correctly could put the receiving participant in breach of money laundering and know your customer law. Both the sending and the receiving provider should screen for sanctions under their own policies. Note the contrast with the reimbursement rules, which cover only a payment from a relevant account located in the United Kingdom to a relevant account in the United Kingdom.", "citation": "Faster Payments System Principles, FPS information guide, v11, Required Elements, Payments Originating Overseas; FPS Reimbursement Rules, Schedule 4, v3.0, clause 3.10", "rests_on": "rule" }, { "label": "Participants must refresh sort code data every week", "value": "It is mandatory for participants to update the sort code reference data in their payment databases and applications weekly from the most recent Extended Industry Sort Code Directory. Settling participants are responsible for maintaining the directory entries of the indirect agencies they carry, including those sponsored by a non-settling participant.", "citation": "Faster Payments System Principles, FPS information guide, v11, section 8; section 4.3", "rests_on": "rule" } ], "exceptions": [ "A qualified acceptance is neither an acceptance nor a rejection in the ordinary sense: the payment succeeded and the money may arrive later, within one of five timescales the qualifier code signals. Orca has no class for a status that is neither, so it is carried here in words.", "A payment drawn on an account outside the United Kingdom is identified only by a bank identifier code in tag 42 instead of a sort code.", "Orca holds 16 of the roughly 64 code values a participant's developer documentation lists, in uk-fps-reject and uk-fps-return, because those are the ones two independent public source families agree on." ], "applies_to": "Faster Payments in the United Kingdom, in sterling: single immediate payments, standing orders, forward dated payments and Direct Corporate Access payments, among Pay.UK's directly connected settling and non-settling participants and the indirect agencies they carry", "caveat": "Not one Faster Payments rejection or return code is an ISO 20022 ExternalStatusReason value. Never carry an AC04, AM04 or MD07 meaning onto this rail, and never link a Faster Payments code to an ISO code on another rail. The numerics here are Pay.UK's own.", "related": [ "uk-fps:decision-points", "uk-fps:return", "uk-fps:hours" ], "basis": { "sources": "Pay.UK 2025 PFMI self-assessment, key considerations 22.1 and 23.1; Faster Payments System Principles v11, the Availability of Funds to the Beneficiary, Account Statement, Payment Information, Error Checking, Payments Originating Overseas and Beneficiary Account Details rows of the Required Elements table and section 8; Pay.UK's Certainty of Fate proposed rule clarification, annex rules 6.2, 9.3.1 and 10.1. All read 2026-09-20. The FPS Procedures, Functional Specification and External Interface Specification and the standards library were not read.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: Pay.UK does not publish the FPS Rules, so the public documents read do not date these provisions", "effective_to": null, "effective_note": "Drafted 2026-09-20 in Orca Core form from Pay.UK's public documents. Pay.UK does not publish the FPS Rules or the FPS Procedures, so when each scheme provision first applied is [Unverified]; the dates given are the editions of the public documents that describe them.", "source_edition": "Faster Payments System Principles v11 (2 January 2026); Pay.UK's 2025 PFMI self-assessment (published November 2025); Pay.UK's Certainty of Fate proposed rule clarification v1.0 (January 2026); Pay.UK's Faster Payment System, transaction limits, participant list and Confirmation of Payee FAQ pages; FPS Reimbursement Rules Schedule 4 v3.0 (26 September 2024); PSR Specific Direction 20 (July 2024) and the two PSR notices of value; PSR Specific Direction 17 as consolidated July 2026; the Payment Services Regulations 2017, Part 7. All read 2026-09-20.", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "rail_name": "Faster Payments (UK)", "governing_authority": "Pay.UK Limited", "snapshot": "2026-09-20", "source_class": null, "effective_status": "draft", "effective_status_reason": null, "boundaries": [] }, { "uid": "uk-fps:participants", "id": "participants", "rail": "uk-fps", "kind": "rail-fact", "facet": "participants", "name": "Who can be on the rail, and on what terms?", "statement": "Three access classes and a fourth population that is not an access class at all. A directly connected settling participant connects to the infrastructure and settles for itself, which needs authorisation as a payment service provider under the Payment Services Regulations 2017, sterling settlement facilities at the Bank of England, a sort code or eligibility for one, and compliance with the FPS Rules. A directly connected non-settling participant connects but is sponsored for settlement, with its debits and credits authorised in real time by its sponsor. An indirect agency does not connect at all and reaches the rail through one of the others. Onboarding a direct participant runs nine to twelve months through seven phases. Pay.UK lists 47 organisations as participants today, counted 46 direct participants at the end of August 2025, and says some 300 more institutions reach the system through agency arrangements. The fourth population is the directed provider: the reimbursement rules bind every provider that participates in Faster Payments and offers relevant accounts, member or not.", "details": [ { "label": "What it takes to connect directly and settle", "value": "To become a directly connected settling participant an organisation must be an authorised payment service provider under the Payment Services Regulations 2017, have access to sterling settlement facilities at the Bank of England, be able to meet the technical and operational requirements either by building its own gateway or through a technical aggregator, hold or be eligible to hold at least one unique sort code, and comply with the FPS Rules and the assurance and attestation requirements. It must also commit to Pay.UK's legal costs, execute and remain party to Pay.UK's legal agreements, and where it is an overseas entity provide a legal opinion that the scheme agreements bind it. There is no fee to join the scheme itself, but a direct participant commits to the infrastructure provider's connectivity, testing and onboarding charges and to per payment fees. A non-bank provider may need to engage with the Financial Conduct Authority before the Bank of England will consider settlement facilities.", "citation": "Faster Payments System Principles, FPS information guide, v11, sections 4, 4.1 and 12", "rests_on": "rule" }, { "label": "Two ways in that do not need a Bank of England account", "value": "A directly connected non-settling participant connects to the infrastructure itself but is sponsored by a settling participant, which authorises its debits and credits in near real time and manages its settlement. It carries the same sending and receiving obligations as a settling participant, including being an authorised provider under the Payment Services Regulations 2017, but does not need settlement facilities at the Bank of England. An indirect agency does not connect at all and sends and receives through a settling or non-settling participant. What channel, interface and limits an indirect agency gets are its sponsor's commercial choice, and the sponsor answers payments on its behalf and maintains its sort code directory entries.", "citation": "Faster Payments System Principles, FPS information guide, v11, sections 4.2 and 4.3; Required Elements, Availability to Receive Payments, Delivery Channel, Limits", "rests_on": "rule" }, { "label": "Direct onboarding runs nine to twelve months", "value": "Pay.UK expects the end to end onboarding of a new direct participant to take between nine and twelve months, through seven phases: discovery, definition and planning, documentation and approvals, procedure design build and certification, Bank of England setup for those that settle, pre go live, and go live. Some phases may run in parallel. The steps include signing a non-disclosure agreement before the discovery workshops, a formal accept or reject decision by Pay.UK on the letter of intent, certification testing with the infrastructure provider, funding and defunding the Bank of England accounts in test and live, and a joint go or no go call.", "citation": "Faster Payments System Principles, FPS information guide, v11, sections 2 and 11", "rests_on": "rule" }, { "label": "Who is on the rail", "value": "Pay.UK lists 47 organisations as Faster Payment System participants, from the largest clearing banks to challenger banks, card and payment companies and money transfer firms. The list does not say which access class each holds. Pay.UK's 2025 assessment counted 46 direct participants, settling and non-settling together, as at the end of August 2025, and said some 300 further institutions reach the system through agency arrangements. Direct participation has more than tripled since an access programme launched in 2014, and the first non-bank direct participant joined in 2018 after rules allowed non-banks to hold a Bank of England settlement account. The system carried 5.55 billion payments worth GBP 4.84 trillion in 2025.", "citation": "Pay.UK, Faster Payment participants, the Faster Payment System list; 2025 PFMI self-assessment of Pay.UK, 2.2.2; Pay.UK, Faster Payment System, opening description", "rests_on": "rule" }, { "label": "Being bound is not the same as being a member", "value": "There are two populations on this rail and they do not coincide. Membership of Faster Payments means a directly connected settling or non-settling participant, which is how Schedule 4 defines a member. A directed provider is any provider that participates in Faster Payments and offers relevant accounts, which reaches well beyond that: the reimbursement rules apply whether or not the provider is a member and party to the FPS Rules. An indirect access provider also has its own reporting duty, having to give the regulator a complete annual list of its indirect provider customers and monthly updates of any changes. Reading the reimbursement regime as a members-only obligation understates it badly.", "citation": "FPS Reimbursement Rules, Schedule 4, v3.0, section 3 Application; clause 10.4 (Member of Faster Payments, Directed PSP, Indirect Access Provider); PSR Specific Direction 20 (July 2024), FPS APP scam reimbursement requirement, paragraphs 1.5, 7.1, 7.3 and 10.1", "rests_on": "rule" } ], "exceptions": [ "Non-banks have been able to hold a Bank of England settlement account since 2018 and the first non-bank direct participant joined that year. A non-bank may need to engage with the Financial Conduct Authority before the Bank will consider settlement facilities.", "There is no fee to join the scheme itself, but a direct participant commits to the infrastructure provider's connectivity, onboarding and per payment charges and to Pay.UK's service management fee.", "Pay.UK's participant list does not say which access class each organisation holds." ], "applies_to": "participation in the Faster Payment System, and, for the directed provider population, every payment service provider that participates in Faster Payments and offers relevant accounts in the United Kingdom", "caveat": "Membership and being bound are two different things on this rail. A provider can be subject to the reimbursement rules, and answerable to Pay.UK for keeping them, without being a member of the scheme or a party to the FPS Rules.", "related": [ "uk-fps:settlement", "uk-fps:liability", "uk-fps:decision-points" ], "basis": { "sources": "Faster Payments System Principles v11, sections 2, 4, 4.1, 4.2, 4.3, 11 and 12; Pay.UK's Faster Payment participants page, counted by Orca on 2026-09-20; Pay.UK 2025 PFMI self-assessment, section 2.2.2; Pay.UK's Faster Payment System page; FPS Reimbursement Rules Schedule 4 v3.0, the Application heading in section 3 and the definitions in clause 10.4; PSR Specific Direction 20 (July 2024), paragraphs 1.5, 7.1 and 10.1. All read 2026-09-20.", "confidence": "medium" }, "currency": { "effective_since": "2026-09-20", "effective_to": null, "effective_note": "Pay.UK's participant list and Faster Payment System pages carry no date; the 47 figure is a count of the list as read on 2026-09-20 and is not an effective date. The 46 direct participants and the roughly 300 agency institutions are the position at the end of August 2025 as Pay.UK's self-assessment states it. The directed provider obligations took effect on 7 October 2024.", "source_edition": "Faster Payments System Principles v11 (2 January 2026); Pay.UK's 2025 PFMI self-assessment (published November 2025); Pay.UK's Certainty of Fate proposed rule clarification v1.0 (January 2026); Pay.UK's Faster Payment System, transaction limits, participant list and Confirmation of Payee FAQ pages; FPS Reimbursement Rules Schedule 4 v3.0 (26 September 2024); PSR Specific Direction 20 (July 2024) and the two PSR notices of value; PSR Specific Direction 17 as consolidated July 2026; the Payment Services Regulations 2017, Part 7. All read 2026-09-20.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.wearepay.uk/wp-content/uploads/2026/02/Pay.UK-Faster-Payments-System-Principles-v-11-Jan-2026.pdf", "source_class": "public_primary", "source_title": "Faster Payments System Principles, FPS information guide, v11", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms the three access classes, their eligibility requirements, and the nine to twelve month onboarding process." }, { "source_url": "https://www.wearepay.uk/wp-content/uploads/2024/09/FPS-Reimbursement-Rules-Schedule-4-v3.0.pdf", "source_class": "authoritative_primary", "source_title": "FPS Reimbursement Rules, Schedule 4, v3.0", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms the fourth population, the directed provider, which the reimbursement rules bind whether or not the provider is a scheme member." }, { "source_url": "https://www.wearepay.uk/what-we-do/payment-systems/faster-payment-system/payment-system-participant-list/", "source_class": "public_primary", "source_title": "Pay.UK, Faster Payment participants", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms 47 organisations listed as participants today, counted on 2026-09-20." } ] }, "rail_name": "Faster Payments (UK)", "governing_authority": "Pay.UK Limited", "snapshot": "2026-09-20", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "uk-fps:recall", "id": "recall", "rail": "uk-fps", "kind": "rail-fact", "facet": "recall", "name": "Can a payer get a Faster Payment recalled?", "statement": "No. A payment cannot be revoked or recalled once it has been sent to the central infrastructure, and the system has no revocation messaging capability at all. There is no request for return of funds, no recall message and no cancellation path in the scheme. This is the clearest case in the corpus of a rail where the absence of a path is the fact. What exists instead are two recovery processes that sit outside the message flow. Credit Payment Recovery is used to attempt to get back a payment that reached the wrong account through customer or bank error. Bank Error Recovery covers a participant that has sent a large number of payments in error and wants them back. Both are attempts. Nothing in any public document read obliges a receiving institution to return the money, and Pay.UK does not publish either procedure, so Orca cannot state their deadlines, grounds or outcomes.", "details": [ { "label": "There is no recall on Faster Payments", "value": "A payment cannot be revoked or recalled once it has been sent to the central infrastructure. There is no recall message, no request for return of funds and no cancellation path in the scheme at all. This is the plainest difference between Faster Payments and the other instant rails: the absence of the path is the fact. What a payer's bank may do before submission is different, and for a standing order or a forward dated payment, which the sending participant holds until the due date, it may cancel on the payer's request, but that is each participant's own commercial matter, not a scheme right.", "citation": "Faster Payments System Principles, FPS information guide, v11, Required Elements, Revocability; sections 5.2 and 5.3; 2025 PFMI self-assessment of Pay.UK, key consideration 8.1", "rests_on": "rule" }, { "label": "Credit Payment Recovery is an attempt, not a right", "value": "Credit Payment Recovery is the industry process for trying to get back a payment that went to the wrong account through customer error or bank error. An indirect agency may join it directly or reach it through a recovery sponsoring participant. Pay.UK's public guide says only that the process may be used to attempt a recovery. Nothing read obliges the receiving institution to return the money, and the process itself sits in the FPS Procedures, which Pay.UK does not publish, so Orca cannot say what its deadlines or grounds are.", "citation": "Faster Payments System Principles, FPS information guide, v11, Required Elements, Credit Payment Recovery", "rests_on": "guidance" }, { "label": "Bank Error Recovery covers a participant's own bulk mistake", "value": "Where a directly connected participant has sent a large number of payments in error it may use the scheme's procedures to send a recovery file to the participants that received them, and it may do so for an indirect agency it sponsors. Like Credit Payment Recovery this is a recovery process outside the payment message flow, and the procedure that governs it is not public.", "citation": "Faster Payments System Principles, FPS information guide, v11, Required Elements, Bank Error Recover", "rests_on": "guidance" } ], "exceptions": [ "A standing order or forward dated payment is held by the sending participant until its due date, so a payer may ask for it to be cancelled before submission. Pay.UK calls that competitive, meaning each participant's own choice.", "A scam victim's route is the reimbursement claim, which is not a recall: the bank pays its own money and then recovers half from the receiving bank." ], "applies_to": "Faster Payments in the United Kingdom, in sterling: single immediate payments, standing orders, forward dated payments and Direct Corporate Access payments, among Pay.UK's directly connected settling and non-settling participants and the indirect agencies they carry", "caveat": "Do not reach for a recall on this rail because another instant rail has one. Real time payments in the United States has a request for return of funds and SEPA credit transfer has a recall; Faster Payments has neither, and the two recovery processes it does have are unpublished and impose no duty on the other side that Orca can point to.", "related": [ "rtp:recall", "sepa-sct:recall", "uk-fps:return", "uk-fps:refund", "uk-fps:liability", "uk-fps:finality" ], "basis": { "sources": "Faster Payments System Principles v11, the Revocability, Credit Payment Recovery and Bank Error Recover rows of the Required Elements table and sections 5.2 and 5.3; Pay.UK 2025 PFMI self-assessment, key consideration 8.1. Both read 2026-09-20. That the receiving side is under no duty to return funds under either recovery process is an absence in the documents read, not a statement in them [Inference]; the procedures themselves are in the FPS Procedures, which Pay.UK does not publish.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: Pay.UK does not publish the FPS Rules, so the public documents read do not date these provisions", "effective_to": null, "effective_note": "Drafted 2026-09-20 in Orca Core form from Pay.UK's public documents. Pay.UK does not publish the FPS Rules or the FPS Procedures, so when each scheme provision first applied is [Unverified]; the dates given are the editions of the public documents that describe them.", "source_edition": "Faster Payments System Principles v11 (2 January 2026); Pay.UK's 2025 PFMI self-assessment (published November 2025); Pay.UK's Certainty of Fate proposed rule clarification v1.0 (January 2026); Pay.UK's Faster Payment System, transaction limits, participant list and Confirmation of Payee FAQ pages; FPS Reimbursement Rules Schedule 4 v3.0 (26 September 2024); PSR Specific Direction 20 (July 2024) and the two PSR notices of value; PSR Specific Direction 17 as consolidated July 2026; the Payment Services Regulations 2017, Part 7. All read 2026-09-20.", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "rail_name": "Faster Payments (UK)", "governing_authority": "Pay.UK Limited", "snapshot": "2026-09-20", "source_class": null, "effective_status": "draft", "effective_status_reason": null, "boundaries": [] }, { "uid": "uk-fps:refund", "id": "refund", "rail": "uk-fps", "kind": "rail-fact", "facet": "refund", "name": "When does a payer get their money back as of right?", "statement": "The scheme gives no refund right at all. Every refund-shaped right on this rail is statutory, from Part 7 of the Payment Services Regulations 2017, and it binds every provider whatever the scheme rules say. Three provisions matter. Where a payment was executed without the payer's consent, the provider must refund it and restore the account, as soon as practicable and in any event by the end of the business day after it becomes aware, value dated to the day the money left; the payer may be held to GBP 35 of losses from a lost or stolen instrument, and to everything where they acted fraudulently or with intent or gross negligence. Where a payment the payer initiated did not arrive, the payer's provider is liable unless it can prove the payee's provider received the money in time, and must refund without undue delay; if it proves the money arrived, the payee's provider becomes liable to the payee. Where the payer gave the wrong account details, nobody is liable for defective execution, but the provider must make reasonable efforts to recover, the receiving provider must co-operate, and if the money cannot be recovered the payer must be given the information to pursue it themselves.", "details": [ { "label": "An unauthorised payment must be refunded by the end of the next business day", "value": "Where a payment was executed without the payer's consent, the provider must refund the amount and, where needed, put the account back into the state it would have been in, with a credit value date no later than the date the money left. The refund has to be made as soon as practicable and in any event by the end of the business day after the provider becomes aware of the unauthorised transaction. The one exception is where the provider has reasonable grounds to suspect fraudulent behaviour by the user and reports those grounds in writing under the money laundering reporting route. The payer may be held liable for up to GBP 35 of losses from a lost, stolen or misappropriated payment instrument, and for everything where the payer acted fraudulently or failed with intent or gross negligence to protect their credentials. This is a statutory right and has nothing to do with a scam the payer authorised.", "citation": "The Payment Services Regulations 2017 (SI 2017/752), Part 7, regulations 76(1) to 76(4) and 77(1) to 77(4)", "rests_on": "law" }, { "label": "The payer's provider answers for a payment that did not arrive", "value": "Where the payer started the payment, the payer's provider is liable to the payer for executing it correctly unless it can prove to the payer, and where relevant to the payee's provider, that the payee's provider received the money in time. If it is liable it must refund the amount without undue delay and restore the account, with a credit value date no later than the date of the debit. If it proves the money did arrive, the payee's provider becomes liable to the payee and must make the amount available immediately. For a late payment, the payee's provider must on request value date the credit as if the payment had run correctly. Whoever is liable, the payer's provider must on request trace the payment immediately and without charge and tell the payer what it found.", "citation": "The Payment Services Regulations 2017 (SI 2017/752), Part 7, regulation 91(1) to 91(8)", "rests_on": "law" }, { "label": "A payment sent to the wrong account number is the payer's risk, with a duty to try to get it back", "value": "Where a payment is executed in accordance with the unique identifier the payer gave, it counts as correctly executed by every provider involved, whoever the money actually reached. If that identifier was wrong the provider is not liable for non-execution or defective execution, but it must make reasonable efforts to recover the funds and may charge for doing so if the framework contract says it may. The payee's provider must co-operate, in particular by handing over everything relevant to collecting the money. If the money cannot be recovered, the payer's provider must on written request give the payer all the relevant information it has so the payer can pursue the claim themselves.", "citation": "The Payment Services Regulations 2017 (SI 2017/752), Part 7, regulation 90(1) to 90(5)", "rests_on": "law" } ], "exceptions": [ "An authorised push payment scam is not an unauthorised transaction: the payer consented, so regulation 76 does not reach it. That gap is what the reimbursement requirement fills.", "The wrong unique identifier defence does not apply where the payment was executed as a result of fraud or dishonesty, because of paragraphs inserted into regulation 90 in August 2023.", "The refund duty for an unauthorised payment does not apply where the provider has reasonable grounds to suspect fraudulent behaviour by the user and reports those grounds in writing under the money laundering route." ], "applies_to": "every payment service provider in the United Kingdom, for payments in Part 7's scope, whatever the Faster Payments rules say", "caveat": "Nothing here comes from the scheme. Do not look for a Faster Payments refund rule: there is none, and a consumer's rights on a payment that went wrong are found in the Payment Services Regulations 2017 and, for a scam the consumer authorised, in the reimbursement requirement.", "related": [ "pix:refund", "sepa-sdd-core:refund", "uk-fps:consumer-law", "uk-fps:liability", "uk-fps:recall" ], "basis": { "sources": "The Payment Services Regulations 2017 (SI 2017/752), regulations 76, 77, 90 and 91, read on legislation.gov.uk 2026-09-20. This is the governing text itself, cited by regulation.", "confidence": "high" }, "currency": { "effective_since": "Unknown: the consolidated text read does not state when regulations 76, 77, 90(1) to (5) and 91 commenced", "effective_to": null, "effective_note": "Drafted 2026-09-20 from the current consolidated text of the Payment Services Regulations 2017, Part 7, on legislation.gov.uk. The page carries no commencement note on regulations 76, 77, 90(1) to (5) or 91, so the date they first applied is [Unverified]. Regulation 90(6) and (7) were inserted on 29 August 2023. HM Treasury has a review of assimilated payment services law under way, so these regulation numbers may eventually move; whether that has happened at read time is [Unverified] here.", "source_edition": "Faster Payments System Principles v11 (2 January 2026); Pay.UK's 2025 PFMI self-assessment (published November 2025); Pay.UK's Certainty of Fate proposed rule clarification v1.0 (January 2026); Pay.UK's Faster Payment System, transaction limits, participant list and Confirmation of Payee FAQ pages; FPS Reimbursement Rules Schedule 4 v3.0 (26 September 2024); PSR Specific Direction 20 (July 2024) and the two PSR notices of value; PSR Specific Direction 17 as consolidated July 2026; the Payment Services Regulations 2017, Part 7. All read 2026-09-20.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.legislation.gov.uk/uksi/2017/752/part/7", "source_class": "authoritative_primary", "source_title": "The Payment Services Regulations 2017 (SI 2017/752), Part 7", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms that no refund right sits in the scheme rule, and that regulations 76, 77, 90 and 91 give the statutory refund, liability and recovery duties the fact describes." } ] }, "rail_name": "Faster Payments (UK)", "governing_authority": "Pay.UK Limited", "snapshot": "2026-09-20", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "uk-fps:return", "id": "return", "rail": "uk-fps", "kind": "rail-fact", "facet": "return", "name": "How does money come back on this rail?", "statement": "As a new payment, never as a reversal. Where a payment was accepted and then could not be made available to the payee, for instance because it turned out to be fraudulent or failed a money laundering check, the receiving institution raises a fresh credit push that references the original payment and carries a return reason, and sends it over Faster Payments where it can. Nothing is debited from the payee and the original payment stands. It must go within one to three working days of the original payment, depending on the answer the receiving participant gave. Where only part of the money can go back, or a Return Payment cannot be built, the institution makes a New Payment instead, but only with the agreement of the original initiator and quoting the first 18 characters of the original payment identifier. A Scheme Return Payment is a different thing: only the central infrastructure can send one, and only for an asynchronous payment a participant received and rejected.", "details": [ { "label": "A return is a new payment, never a reversal", "value": "When funds cannot be made available to the payee after the payment was accepted, the way back is a fresh credit push that references the original payment and carries a return reason. The original payment is not reversed, nothing is debited from the payee, and the return should where possible go over Faster Payments itself. Anyone reading return codes on this rail with an automated clearing house or SEPA return in mind will get the mechanics wrong.", "citation": "Faster Payments System Principles, FPS information guide, v11, section 5.4; Required Elements, Returns; Pay.UK's work on Certainty of Fate to support A2A retail transactions: proposed rule clarification, v1.0, annex, rule 10.1", "rests_on": "rule" }, { "label": "A Return Payment goes within one to three working days", "value": "A Return Payment must be sent within one to three working days of the original payment. Which of those it is depends on the answer the receiving directly connected participant gave to the original payment. Pay.UK's public guide states the range and does not say which answer maps to which deadline; that sits in the FPS Procedures, which Pay.UK does not publish.", "citation": "Faster Payments System Principles, FPS information guide, v11, section 5.4", "rests_on": "rule" }, { "label": "A Return Payment must specify the return reason", "value": "A receiving institution sending a Return Payment over Faster Payments has to specify the return reason on it. The reason is what tells the sending institution, and through it the payer, why the money came back.", "citation": "Pay.UK's work on Certainty of Fate to support A2A retail transactions: proposed rule clarification, v1.0, annex, rule 10.1", "rests_on": "rule" }, { "label": "A partial return is a new payment and needs the originator's agreement", "value": "Where a participant cannot use a Return Payment, for instance because it is returning only part of the money or cannot build one, it may make a New Payment instead. That is allowed only with the agreement of the initiator of the original payment, and the first 18 characters of the original payment identifier have to go in the payment reference field so the two can be matched.", "citation": "Pay.UK's work on Certainty of Fate to support A2A retail transactions: proposed rule clarification, v1.0, annex, rule 10.1", "rests_on": "rule" }, { "label": "Only the central infrastructure sends a Scheme Return Payment", "value": "A Scheme Return Payment is a different thing from a Return Payment and no participant can send one. The central infrastructure sends it, and only to return the funds of an asynchronous payment, meaning a forward dated payment, a standing order or a Direct Corporate Access payment, that a directly connected participant received and rejected.", "citation": "Faster Payments System Principles, FPS information guide, v11, section 5.5", "rests_on": "rule" } ], "exceptions": [ "A rejection is not a return. A rejected payment never reached the payee and no money moves; a return sends money back after it did.", "Pay.UK does not publish the return reason list. Orca holds only the values two independent public source families agree on, in uk-fps-return, and holds the rest back." ], "applies_to": "Faster Payments in the United Kingdom, in sterling: single immediate payments, standing orders, forward dated payments and Direct Corporate Access payments, among Pay.UK's directly connected settling and non-settling participants and the indirect agencies they carry", "caveat": "Automated clearing house and SEPA intuition is wrong here. There is no debit pull, no reversal of the original entry and no camt message. The return is a payment in the opposite direction with a reason code attached, and the original payment is untouched.", "related": [ "rtp:return", "uk-fps:recall", "uk-fps:refund", "uk-fps:messages" ], "basis": { "sources": "Faster Payments System Principles v11, sections 5.4 and 5.5 and the Returns row of the Required Elements table; Pay.UK's Certainty of Fate proposed rule clarification, annex rule 10.1. Both read 2026-09-20. Which response maps to which of the one to three working days sits in the FPS Procedures, which are not public.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: Pay.UK does not publish the FPS Rules, so the public documents read do not date these provisions", "effective_to": null, "effective_note": "Drafted 2026-09-20 in Orca Core form from Pay.UK's public documents. Pay.UK does not publish the FPS Rules or the FPS Procedures, so when each scheme provision first applied is [Unverified]; the dates given are the editions of the public documents that describe them.", "source_edition": "Faster Payments System Principles v11 (2 January 2026); Pay.UK's 2025 PFMI self-assessment (published November 2025); Pay.UK's Certainty of Fate proposed rule clarification v1.0 (January 2026); Pay.UK's Faster Payment System, transaction limits, participant list and Confirmation of Payee FAQ pages; FPS Reimbursement Rules Schedule 4 v3.0 (26 September 2024); PSR Specific Direction 20 (July 2024) and the two PSR notices of value; PSR Specific Direction 17 as consolidated July 2026; the Payment Services Regulations 2017, Part 7. All read 2026-09-20.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.wearepay.uk/wp-content/uploads/2026/02/Pay.UK-Faster-Payments-System-Principles-v-11-Jan-2026.pdf", "source_class": "public_primary", "source_title": "Faster Payments System Principles, FPS information guide, v11", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms the Return Payment mechanics as a new credit push referencing the original, the one to three working day window, and the Scheme Return Payment restricted to the central infrastructure for a rejected asynchronous payment." }, { "source_url": "https://www.wearepay.uk/wp-content/uploads/2026/01/Pay.UK-CoF-Proposed-Rule-Clarification-January-2026.pdf", "source_class": "public_primary", "source_title": "Pay.UK's work on Certainty of Fate to support A2A retail transactions: proposed rule clarification, v1.0", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms the New Payment route when a Return Payment cannot be built or only part of the money can go back, requiring the original initiator's agreement and the first 18 characters of the original payment identifier." } ] }, "rail_name": "Faster Payments (UK)", "governing_authority": "Pay.UK Limited", "snapshot": "2026-09-20", "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "uk-fps:settlement", "id": "settlement", "rail": "uk-fps", "kind": "rail-fact", "facet": "settlement", "name": "How and when does money actually move between the banks?", "statement": "Faster Payments clears in real time and settles in batches. Vocalink nets what each participant owes and is owed, and the Bank of England settles the single amount over its real time gross settlement infrastructure three times on each working day, at 07:00, 13:00 and 17:00, in central bank money. Every settling participant holds reserve or settlement accounts at the Bank, sets its own net sender cap to limit the exposure it can build up between cycles, and must hold cash equal to that cap in a separate pre-funded account. In normal running the pre-funding is never touched; it exists so Pay.UK can instruct the Bank to draw on it if a participant cannot settle, without reaching any other participant. That is what removes credit risk between participants. A directly connected participant that does not settle for itself uses a sponsor's account and gets its debits and credits authorised in real time.", "details": [ { "label": "Settlement runs three times each working day", "value": "Payments clear in real time all day and all night, but the money between participants moves in deferred net settlement over the Bank of England's real time gross settlement infrastructure three times on each working day, at 07:00, 13:00 and 17:00. Vocalink nets what each participant owes and is owed; the Bank of England settles the single amount. Clearing and settlement are therefore separate on this rail, and a payment credited to a customer on a Saturday is not settled between the banks until the next working day's first run.", "citation": "2025 PFMI self-assessment of Pay.UK, 2.2 and 2.2.2; Faster Payments System Principles, FPS information guide, v11, section 6", "rests_on": "rule" }, { "label": "Settlement is in central bank money at the Bank of England", "value": "Every settling participant must hold reserve or settlement accounts at the Bank of England, and the net positions settle across those accounts in central bank money over the Bank's real time gross settlement infrastructure. A participant that does not settle for itself uses its sponsor's account. Pay.UK holds a contract with the Bank as the settlement service provider, and Pay.UK's contingency for a run that cannot complete is to seek an extension or delay the cycle rather than to unwind the payments.", "citation": "2025 PFMI self-assessment of Pay.UK, 2.2, 2.2.2 and key consideration 8.2; Faster Payments System Principles, FPS information guide, v11, sections 4.1 and 6", "rests_on": "rule" }, { "label": "Each settling participant sets its own net sender cap", "value": "A settling participant sets the ceiling on the credit exposure it may bring into the system between settlement cycles, and Pay.UK expects that ceiling to more than cover the largest debit position the participant anticipates within a cycle. A participant's own cap, not a scheme figure, is what limits how much it can send before settling. Where Pay.UK has to draw on a participant's pre-funding, it reduces that participant's cap first and raises it again only when the participant puts more cash in.", "citation": "Faster Payments System Principles, FPS information guide, v11, section 6; 2025 PFMI self-assessment of Pay.UK, 2.2.2", "rests_on": "rule" }, { "label": "Pre-funding must equal the net sender cap", "value": "A settling participant has to hold cash equal to its net sender cap in a separate pre-funded account, on top of the funds in its settlement account. In normal running that cash is never touched; it exists so that if a participant cannot meet its obligations Pay.UK can instruct the Bank of England to draw on it and complete the cycle without reaching any other participant. Banks and building societies hold prefunding accounts; a non-bank provider holds a settlement collateralisation account or a client fund account depending on its model, with a deed of charge or, on the own funds model, a single settlement trust deed behind it. Pre-funding is what removes credit risk between participants from the settlement process.", "citation": "Faster Payments System Principles, FPS information guide, v11, section 6; 2025 PFMI self-assessment of Pay.UK, 2.2, 2.2.2 and key consideration 8.2", "rests_on": "rule" }, { "label": "A non-settling participant settles through its sponsor's account", "value": "A directly connected participant that does not settle for itself is sponsored by one that does. The sponsor authorises each of its debits and credits in near real time, giving a real time answer on the availability of funds before a payment goes out and before a credit is accepted, and manages its settlement using the sponsor's own account at the Bank of England.", "citation": "Faster Payments System Principles, FPS information guide, v11, section 4.2; 2025 PFMI self-assessment of Pay.UK, 2.2.2", "rests_on": "rule" } ], "exceptions": [ "Banks and building societies hold prefunding accounts; a non-bank provider holds a settlement collateralisation account or a client fund account depending on its model, with a deed of charge or, on the own funds model, a single settlement trust deed.", "Where a cycle cannot complete, Pay.UK's contingency is to seek an extension or delay the cycle in the real time gross settlement system, not to unwind the payments." ], "applies_to": "Faster Payments in the United Kingdom, in sterling: single immediate payments, standing orders, forward dated payments and Direct Corporate Access payments, among Pay.UK's directly connected settling and non-settling participants and the indirect agencies they carry", "caveat": "A payment credited to a customer in the evening, at a weekend or on a bank holiday is not settled between the banks until the next working day. The customer experience is instant; the interbank position is deferred and net.", "related": [ "ca-acss:settlement", "ph-pesonet:settlement", "rtp:settlement", "uk-fps:finality", "uk-fps:participants" ], "basis": { "sources": "Pay.UK 2025 PFMI self-assessment, sections 2.2 and 2.2.2 and key considerations 8.1 and 8.2; Faster Payments System Principles v11, sections 4.1, 4.2 and 6. Both read 2026-09-20. The settlement times are read as United Kingdom local time, which neither document states in terms [Inference].", "confidence": "medium" }, "currency": { "effective_since": "Unknown: Pay.UK does not publish the FPS Rules, so the public documents read do not date these provisions", "effective_to": null, "effective_note": "Drafted 2026-09-20 in Orca Core form from Pay.UK's public documents. Pay.UK does not publish the FPS Rules or the FPS Procedures, so when each scheme provision first applied is [Unverified]; the dates given are the editions of the public documents that describe them.", "source_edition": "Faster Payments System Principles v11 (2 January 2026); Pay.UK's 2025 PFMI self-assessment (published November 2025); Pay.UK's Certainty of Fate proposed rule clarification v1.0 (January 2026); Pay.UK's Faster Payment System, transaction limits, participant list and Confirmation of Payee FAQ pages; FPS Reimbursement Rules Schedule 4 v3.0 (26 September 2024); PSR Specific Direction 20 (July 2024) and the two PSR notices of value; PSR Specific Direction 17 as consolidated July 2026; the Payment Services Regulations 2017, Part 7. All read 2026-09-20.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.wearepay.uk/wp-content/uploads/2025/11/2025-PFMI-self-assessment-of-Pay.UK_.pdf", "source_class": "public_primary", "source_title": "2025 PFMI self-assessment of Pay.UK", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms deferred net settlement three times each working day at 07:00, 13:00 and 17:00 in central bank money at the Bank of England, and the prefunding account types by participant model." }, { "source_url": "https://www.wearepay.uk/wp-content/uploads/2026/02/Pay.UK-Faster-Payments-System-Principles-v-11-Jan-2026.pdf", "source_class": "public_primary", "source_title": "Faster Payments System Principles, FPS information guide, v11", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms the net sender cap each settling participant sets, the matching pre funded account, and that a non-settling participant settles through its sponsor's account with real time authorisation." } ] }, "rail_name": "Faster Payments (UK)", "governing_authority": "Pay.UK Limited", "snapshot": "2026-09-20", "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "us-ach:consumer-law", "id": "consumer-law", "rail": "us-ach", "kind": "rail-fact", "facet": "consumer-law", "name": "What consumer protection law applies, and what does it require?", "statement": "The Electronic Fund Transfer Act and Regulation E apply to an ACH entry that debits or credits a consumer account, which means an account held mainly for personal, family or household purposes. The law attaches to the account, not to the rail, so the same ACH debit is covered when it hits a household account and uncovered when it hits a company account. Regulation E sets the authorisation requirement, the stop payment right, the error resolution timetable and the cap on what a consumer can lose.", "details": [ { "label": "What is covered", "value": "Regulation E reaches any electronic fund transfer that authorises a bank to debit or credit a consumer's account, where an account is a demand deposit, savings or other consumer asset account held mainly for personal, family or household purposes, and now includes a prepaid account.", "citation": "12 CFR Part 1005 (Regulation E), eCFR current text, 1005.3(a) and 1005.2(b)(1) and (3), read 2026-09-17", "rests_on": "law" }, { "label": "Authorisation for a recurring debit must be written", "value": "A preauthorised debit from a consumer account may only be authorised by a writing that the consumer signs or similarly authenticates, and whoever takes the authorisation has to give the consumer a copy.", "citation": "12 CFR Part 1005 (Regulation E), eCFR current text, 1005.10(b), read 2026-09-17", "rests_on": "law" }, { "label": "The stop payment right", "value": "A consumer can call or write to the bank to stop a preauthorised debit, and the notice counts if it arrives by the third business day before the debit is due. The bank may ask for the oral order to be put in writing inside 14 days, and the order dies if that never comes.", "citation": "12 CFR Part 1005 (Regulation E), eCFR current text, 1005.10(c), read 2026-09-17", "rests_on": "law" }, { "label": "Warning when the amount changes", "value": "Where a preauthorised debit will differ from the last one or from the authorised amount, the payee or the bank must send written notice of the amount and date at least 10 days ahead. The consumer may be offered notice only outside an agreed range or beyond an agreed variation instead.", "citation": "12 CFR Part 1005 (Regulation E), eCFR current text, 1005.10(d), read 2026-09-17", "rests_on": "law" }, { "label": "Notice that an incoming credit arrived", "value": "Where someone sends preauthorised credits to a consumer account at least every 60 days, the bank must either tell the consumer within 2 business days that the transfer happened, or tell them within 2 business days that it did not, or run a phone line the consumer can call, disclosed on statements. The payor giving positive notice relieves the bank of this.", "citation": "12 CFR Part 1005 (Regulation E), eCFR current text, 1005.10(a)(1) and (a)(2), read 2026-09-17", "rests_on": "law" }, { "label": "Credit as of the day funds arrive", "value": "A bank receiving such a preauthorised credit must credit the amount as of the date the funds for it are received, which stops a bank taking value date between settlement and posting.", "citation": "12 CFR Part 1005 (Regulation E), eCFR current text, 1005.10(a)(3), read 2026-09-17", "rests_on": "law" }, { "label": "The error clock", "value": "The consumer has 60 days from the statement that first showed the item. The bank then has 10 business days to decide, or 45 days if it provisionally credits inside those 10 business days, stretching to 20 business days and 90 days for a new account or certain transfers.", "citation": "12 CFR Part 1005 (Regulation E), eCFR current text, 1005.11(b)(1)(i), 1005.11(c)(1) to (c)(3), read 2026-09-17", "rests_on": "law" }, { "label": "The consumer's exposure is capped", "value": "A consumer's liability for an unauthorised transfer is limited to $50 where they tell the bank within 2 business days of learning of a loss or theft of an access device, and to $500 where they do not. Both caps depend on the bank having given the required disclosures.", "citation": "12 CFR Part 1005 (Regulation E), eCFR current text, 1005.6(a) and 1005.6(b)(1) and (2), read 2026-09-17", "rests_on": "law" }, { "label": "No forcing a consumer onto the rail", "value": "A lender may not require repayment by preauthorised electronic transfer, except for overdraft credit or to keep a minimum balance, and nobody may require a consumer to open an account at a particular bank as a condition of a job or a government benefit.", "citation": "12 CFR Part 1005 (Regulation E), eCFR current text, 1005.10(e), read 2026-09-17", "rests_on": "law" }, { "label": "Government benefit accounts are inside the regime", "value": "Electronic delivery of government benefits is covered by its own section of Regulation E, and needs tested state or local benefit accounts are treated as a defined account type rather than left outside.", "citation": "12 CFR Part 1005 (Regulation E), eCFR current text, 1005.15, with the account definitions at 1005.2(b), read 2026-09-17", "rests_on": "law" }, { "label": "Why 95 days and not 60", "value": "Nacha explains the 95 day floor as covering the Regulation E arithmetic: up to a statement cycle before the consumer sees the entry, plus the 60 days the consumer then has to report it. The rulebook window is built around the statute, not the other way round.", "citation": "Nacha, Limitation on Warranty Claims, rule effective 2021-06-30; 12 CFR Part 1005 (Regulation E), eCFR current text, 1005.11(b)(1)(i), read 2026-09-17", "rests_on": "rule" } ], "exceptions": [ "Preauthorised transfers to or from an account at an institution with $100 million or less in assets are exempt, with the exemption ending a year after it crosses the threshold (12 CFR 1005.3(c)(7)).", "Automatic transfers a bank makes under an arrangement between itself and the consumer, including between the consumer's own accounts or to a family member's account at the same bank, are outside the regulation, though transfers between the consumer's account and the bank's own account remain subject to the compulsory use rule (12 CFR 1005.3(c)(5)).", "Article 4A of the Uniform Commercial Code does not apply to a funds transfer any part of which is governed by the Electronic Fund Transfer Act, so the commercial law regime and this one do not overlap (12 CFR 210.25 appendix commentary, eCFR text read 2026-09-17).", "An international ACH entry to or from a consumer may also be a remittance transfer under subpart B of Regulation E, which carries its own disclosure and cancellation rules; this record does not state them [Unverified: subpart B was not read section by section].", "A payment the consumer was tricked into authorising does not fit the definition of error, so the error resolution machinery does not obviously reach it [Inference from 12 CFR 1005.11(a)(1); no CFPB interpretation read]." ], "applies_to": "ACH debits and credits to accounts held by a natural person in the United States primarily for personal, family or household purposes, including prepaid accounts and government benefit accounts", "caveat": "Reading the rail alone will mislead anyone here. Regulation E duties sit on the account holding bank whatever the ACH rules say, and they can require a recredit after every ACH window has closed. An originator's exposure on consumer debits is therefore set by this regulation and by its bank's agreement, not by the return windows.", "related": [ "us-ach:refund", "us-ach:liability", "us-ach:return", "us-ach:finality", "us-ach:decision-points" ], "basis": { "sources": "Regulation E, 12 CFR part 1005, read on eCFR 2026-09-17 by fetching the part with compressed responses: sections 1005.2(b), 1005.3(a), 1005.3(b), 1005.3(c)(5) and (c)(7), 1005.6, 1005.10(a) to (e), 1005.11(a) to (e), 1005.12 and 1005.15. Regulation J, 12 CFR 210.25 appendix commentary, read on eCFR 2026-09-17, for the Article 4A and EFTA boundary. Nacha public rule page Limitation on Warranty Claims, rule effective 2021-06-30, read 2026-09-17, for how the rulebook windows were built around the statute. The statute itself, 15 U.S.C. 1693, and the CFPB official interpretations were not read.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "The Regulation E text read is the current eCFR version as at 2026-09-17. Section 1005.10 carries amendments through 89 FR 106836 dated 2024-12-30; the watch log in Orca's US ACH rail brief (docs/rails/us-ach.md) records a substantive amendment to 1005.10 dated 2025-10-01 whose content the drafter did not determine [Unverified]. The dollar caps of $50 and $500 are not indexed and have not moved.", "source_edition": "12 CFR 1005 and 12 CFR 210 as on eCFR 2026-09-17; Nacha public rule page read 2026-09-17", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.ecfr.gov/current/title-12/part-1005", "source_class": "authoritative_primary", "source_title": "12 CFR Part 1005 (Regulation E), eCFR current text", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms account/coverage definition (1005.2(b), 1005.3(a)), written authorization and copy requirement (1005.10(b)), stop payment right and 14 day confirmation (1005.10(c)), variable amount notice (1005.10(d)), preauthorized credit notice and value dating (1005.10(a)), error window running from transmittal of the periodic statement not from settlement (1005.11(b)(1)(i), (c)), loss caps (1005.6), no compulsory use (1005.10(e)), and government benefit account coverage (1005.15). Does not confirm the CFPB official interpretations or the 15 USC 1693 statute text, which were not read." } ] }, "rail_name": "US ACH", "governing_authority": "Nacha", "snapshot": "2026-09-16", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "us-ach:decision-points", "id": "decision-points", "rail": "us-ach", "kind": "rail-fact", "facet": "decision-points", "name": "Where do the rules hand the outcome to a human or a bank?", "statement": "ACH looks automatic and is not. At a dozen points the text says a bank may, or judges, or must take a risk based approach, and the payment's outcome then depends on a person or a policy rather than on the rail. The receiving bank decides whether money goes back. The Reserve Bank decides whether settlement happens at all. The account holding bank decides whether a consumer's claim is an error. This record names each point and the provision that leaves it open.", "details": [ { "label": "Whether to honour a request to return", "value": "Where the originating side asks for an entry back, the receiving bank chooses. Nothing compels a return; the rules only give the originating bank an indemnity to offer.", "citation": "Popular Bank, ACH Rules Awareness Guide for Businesses, revised 2025-04-02, R06 entry naming Article Two, Subsection 2.12.3", "rests_on": "rule" }, { "label": "The receiving side is not obliged to fund it", "value": "The receiving bank need not post a reversing debit that would overdraw the account or that hits a closed account. The receiver must be told a reversing debit hit the account but is not asked to authorise it.", "citation": "Popular Bank, ACH Rules Awareness Guide for Businesses, revised 2025-04-02, reversals section", "rests_on": "rule" }, { "label": "Whether a reversal was proper", "value": "Since 2021 a receiving bank may return a reversal it considers improper, using R17 on a non consumer account even when it spotted the problem itself with no customer contact. That judgement is the bank's.", "citation": "Nacha, ACH Network Rules: Reversals and Enforcement, rule effective 2021-06-30 and enforcement rule effective 2021-01-01, reversals rule effective 2021-06-30, read 2026-09-17", "rests_on": "rule" }, { "label": "Settlement can also be refused before it happens", "value": "Where the Reserve Bank holding the settlement account expects the account to be short at settlement time, or hears that a bank has suspended payment or closed, it may stop processing the item, batch or file and decline to settle for it.", "citation": "Federal Reserve Banks Operating Circular No. 4, Automated Clearing House Items, effective January 5, 2026, paragraph 10.4", "rests_on": "rule" }, { "label": "Credit given for a debit is not the same as funds collected", "value": "Credit for a debit entry is available on the settlement date but the Reserve Bank can withhold its use if it doubts the sending bank's account will cover a chargeback or return, and can reverse a whole settlement window's debit entries the following morning if funds did not arrive.", "citation": "Federal Reserve Banks Operating Circular No. 4, Automated Clearing House Items, effective January 5, 2026, paragraphs 11.1(a) and 11.1(b)", "rests_on": "rule" }, { "label": "Prefunding, where a Reserve Bank requires it", "value": "A sending bank's Administrative Reserve Bank may require credit originations to be prefunded where it has decided to monitor that account in real time. Originations that should have been prefunded and were not can be rejected, and where prefunding applies the Reserve Bank steps into the sending bank's settlement obligation.", "citation": "Federal Reserve Banks Operating Circular No. 4, Automated Clearing House Items, effective January 5, 2026, paragraph 5.3 with Appendix C", "rests_on": "rule" }, { "label": "Where to set the fraud thresholds", "value": "The 2026 rules require risk based processes to spot entries initiated by fraud, at originating banks, larger originators and service providers, and at larger receiving banks for inbound credits. Risk based means each institution sets its own baselines and triggers, and no rule states them.", "citation": "Nacha, Risk Management Topics, Fraud Monitoring Phase 1, effective 2026-03-20; Nacha, Risk Management Topics, Fraud Monitoring Phase 2, effective 2026-06-19", "rests_on": "rule" }, { "label": "Whether a consumer's claim is an error", "value": "The account holding bank investigates and determines whether an error occurred, may require written confirmation of an oral notice within 10 business days, and may hold back $50 of a provisional credit where it has a reasonable basis to believe the transfer was unauthorised.", "citation": "12 CFR Part 1005 (Regulation E), eCFR current text, 1005.11(b)(2), 1005.11(c)(1) and 1005.11(c)(2)(i), read 2026-09-17", "rests_on": "law" }, { "label": "The stop payment right", "value": "A consumer can call or write to the bank to stop a preauthorised debit, and the notice counts if it arrives by the third business day before the debit is due. The bank may ask for the oral order to be put in writing inside 14 days, and the order dies if that never comes.", "citation": "12 CFR Part 1005 (Regulation E), eCFR current text, 1005.10(c), read 2026-09-17", "rests_on": "law" }, { "label": "Whether an entry breaches sanctions obligations", "value": "From 2028-03-17 the R90 return code exists, in Nacha's own words, to support a receiving bank's decision to return an entry to meet its sanctions obligations. The decision is the bank's, and Nacha notes that OFAC rarely instructs directly.", "citation": "New Return Reason Code for Sanctions Compliance Obligations, effective 2028-03-17", "rests_on": "rule" }, { "label": "Whether to dispute a return", "value": "A sending bank may dispute the propriety of a return once, which starts a provisional settlement that the receiving bank can then contest. Neither step happens unless a person decides to take it.", "citation": "Federal Reserve Banks Operating Circular No. 4, Automated Clearing House Items, effective January 5, 2026, paragraph 15.1", "rests_on": "rule" }, { "label": "Whether a description is true", "value": "The 2026 rule introducing PURCHASE as a standard company entry description states that the originating bank has no obligation to verify that the word is present or accurate, so accuracy rests on the originator alone.", "citation": "Nacha, Risk Management Topics, Company Entry Descriptions, effective 2026-03-20; Popular Bank, ACH Rules Awareness Guide for Businesses, revised 2025-04-02, upcoming revisions section", "rests_on": "rule" }, { "label": "Whether the originator keeps its access", "value": "A bank can pass on fines it receives for its customer's non compliance and can cancel ACH services where the customer does not fix the problem, so continued access to the rail is a commercial decision.", "citation": "Popular Bank, ACH Rules Awareness Guide for Businesses, revised 2025-04-02, compliance section", "rests_on": "practice" }, { "label": "Whether funds appear before settlement", "value": "Some receiving banks advance their own money so a payroll credit shows before settlement. Nacha describes this as a practice of some institutions, not a requirement, which is why early availability varies by bank.", "citation": "Nacha, The ABCs of ACH, standard industry practices section, read 2026-09-17", "rests_on": "practice" } ], "exceptions": [ "This record is Orca's reading of where the texts leave judgement open, not a list any authority publishes. It caps at medium confidence for that reason.", "Decisions taken inside the paid Nacha Operating Rules that no public source describes are not listed; the rulebook was not opened.", "Thresholds a bank sets under the fraud monitoring rules are neither public nor uniform, so no figure is given (Nacha Fraud Monitoring rule pages, effective 2026-03-20 and 2026-06-19).", "A Reserve Bank's discretionary powers bind it only to the banks it serves; they give a corporate originator no right to ask for a decision (Operating Circular 4, paragraph 21.1).", "Where a decision point involves a consumer account, Regulation E constrains the outcome even though the decision is the bank's (12 CFR 1005.11)." ], "applies_to": "points in the ACH flow where a published provision leaves the outcome to a bank's judgement, a Reserve Bank's discretion or a person's choice", "caveat": "An agent should read this facet as the list of places where automation stops. None of these decisions has a published timetable or a right of appeal for the originator, and several belong to a bank with no relationship to the originator at all. Building a flow that assumes any of them resolves in your favour is a design error.", "related": [ "us-ach:finality", "us-ach:settlement", "us-ach:return", "us-ach:recall", "us-ach:refund", "us-ach:liability", "us-ach:consumer-law", "us-ach:participants" ], "basis": { "sources": "Each line names the provision that leaves the decision open. Federal Reserve Banks Operating Circular 4, effective 2026-01-05, read in full for this record: paragraphs 5.3, 10.4, 11.1, 15.1 and 21.1. Regulation E, 12 CFR 1005.10(c)(2) and 1005.11(b)(2) and (c), read on eCFR 2026-09-17. Nacha public rule pages (nacha.org), read 2026-09-17: Reversals and Enforcement, rule effective 2021-06-30; the two Fraud Monitoring pages, effective 2026-03-20 and 2026-06-19; Company Entry Descriptions, effective 2026-03-20; New Return Reason Code for Sanctions Compliance Obligations, effective 2028-03-17; The ABCs of ACH. Popular Bank ACH Rules Awareness Guide for Businesses, revised 2025-04-02 (secondary), for the receiving bank's freedom over returns and reversals and for the originator's access. The rulebook itself was not opened, so decision points visible only there are missing.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Most of these provisions are long-standing in the sources read. Dated ones: the improper reversal return from 2021-06-30, fraud monitoring from 2026-03-20 and 2026-06-19, company entry descriptions from 2026-03-20, and the sanctions return decision from 2028-03-17.", "source_edition": "Federal Reserve Banks Operating Circular 4, effective 2026-01-05; 12 CFR 1005 as on eCFR 2026-09-17; Nacha public rule pages read 2026-09-17; Popular Bank guide revised 2025-04-02", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "primary_not_public": true, "corroboration": [ { "source_url": "https://www.frbservices.org/binaries/content/assets/crsocms/resources/rules-regulations/010526-operating-circular-4.pdf", "source_class": "authoritative_primary", "source_title": "Federal Reserve Banks Operating Circular No. 4, Automated Clearing House Items, effective January 5, 2026", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the Reserve Bank's discretion to refuse settlement (10.4), to withhold use of credit given for a debit and to unwind a settlement window (11.1), to require prefunding after deciding to monitor an account (5.3), a sending bank's one-time dispute of a return (15.1), and the Reserve Bank's own discretionary recovery and security-interest powers (10.3). Does not itself confirm the Nacha-side decision points (reversal impropriety, fraud thresholds, sanctions returns, description accuracy)." }, { "source_url": "https://www.nacha.org/rules/reversals-and-enforcement", "source_class": "public_primary", "source_title": "Nacha, ACH Network Rules: Reversals and Enforcement, rule effective 2021-06-30 and enforcement rule effective 2021-01-01", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms an RDFI may return an improper reversal using R11 (consumer, 60 day claim window) or R17 (non-consumer, 2 day window identified by the bank itself), which is the source for the 'whether a reversal was proper' decision point, and confirms the egregious-violation enforcement framework behind the 'whether the originator keeps its access' point. Independent of Operating Circular 4: different organisation (Nacha, not the Federal Reserve), different host, own wording, dated to its own rule effective dates." } ] }, "rail_name": "US ACH", "governing_authority": "Nacha", "snapshot": "2026-09-16", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "not_public", "label": "the operator's own text", "needs": "what the operator's own text says, which Orca has not read", "detail": "Nacha's own text is not the source for this rail fact: it is not public, or not under terms Orca can use. It rests on 2 named public sources, so a term set by agreement rather than by a published rule is not Orca's to state.", "from": "currency.primary_not_public" } ] }, { "uid": "us-ach:finality", "id": "finality", "rail": "us-ach", "kind": "rail-fact", "facet": "finality", "name": "When does an ACH payment become final, and can it be reversed?", "statement": "Settlement between the two banks is final on the settlement date, at the settlement time the Reserve Banks publish. That is the only sense in which an ACH payment is final. Money keeps moving after it: a receiving bank may send the entry back inside a return window measured in banking days, a consumer may dispute an unauthorized debit for 60 days, an originator may send a reversal for an error, and a return can itself be dishonored. Read ACH finality as the end of the interbank settlement question, not the end of the payment.", "details": [ { "label": "The moment settlement is final for a credit", "value": "For a credit entry cleared through a Reserve Bank, the credit the receiving bank gets is final, usable and countable as reserves from the settlement time published in the FedACH Processing Schedule for the settlement date.", "citation": "Federal Reserve Banks Operating Circular No. 4, Automated Clearing House Items, effective January 5, 2026, paragraph 11.2", "rests_on": "rule" }, { "label": "Credit given for a debit is not the same as funds collected", "value": "Credit for a debit entry is available on the settlement date but the Reserve Bank can withhold its use if it doubts the sending bank's account will cover a chargeback or return, and can reverse a whole settlement window's debit entries the following morning if funds did not arrive.", "citation": "Federal Reserve Banks Operating Circular No. 4, Automated Clearing House Items, effective January 5, 2026, paragraphs 11.1(a) and 11.1(b)", "rests_on": "rule" }, { "label": "Settlement can be unwound the next morning", "value": "If a Reserve Bank has not collected funds for all debit entries that settled on the previous banking day by noon Eastern, it may undo the debits and credits for every debit entry in that settlement window, until 5:30 pm Eastern, and must tell the banks by 4:00 pm Eastern that day.", "citation": "Federal Reserve Banks Operating Circular No. 4, Automated Clearing House Items, effective January 5, 2026, paragraph 11.1(b)", "rests_on": "rule" }, { "label": "Settlement can also be refused before it happens", "value": "Where the Reserve Bank holding the settlement account expects the account to be short at settlement time, or hears that a bank has suspended payment or closed, it may stop processing the item, batch or file and decline to settle for it.", "citation": "Federal Reserve Banks Operating Circular No. 4, Automated Clearing House Items, effective January 5, 2026, paragraph 10.4", "rests_on": "rule" }, { "label": "No recall by the sender once the file has gone", "value": "A sending bank or an earlier party cannot amend or revoke an entry after sending it to a Reserve Bank, other than by whatever the Nacha rules themselves allow, which is the reversal path and not a cancellation.", "citation": "Federal Reserve Banks Operating Circular No. 4, Automated Clearing House Items, effective January 5, 2026, paragraph 13.1; Nacha, ACH Network Rules: Reversals and Enforcement, rule effective 2021-06-30 and enforcement rule effective 2021-01-01, reversals rule effective 2021-06-30", "rests_on": "rule" }, { "label": "Second layer: Article 4A, and only for some entries", "value": "Article 4A of the Uniform Commercial Code governs an ACH credit entry that is a payment order, but not an entry any part of which falls under the Electronic Fund Transfer Act, and not zero dollar traffic such as prenotifications, notifications of change, automated enrollment or zero dollar returns. So the commercial law layer is switched off for most consumer credits.", "citation": "Federal Reserve Banks Operating Circular No. 4, Automated Clearing House Items, effective January 5, 2026, paragraphs 2.1(e) and 2.1(j); 12 CFR Part 210 (Regulation J), eCFR current text, 210.25 appendix commentary, describing 15 U.S.C. 1693 through section 4A-108", "rests_on": "law" }, { "label": "ACH is not a Fedwire funds transfer, and Regulation J subpart B does not reach it", "value": "Regulation J's funds transfer subpart defines a payment order to exclude automated clearing house transfers, and says the Fedwire Funds Service is not the ACH system. The Federal Reserve rules that do govern FedACH entries are Operating Circular 4, which incorporates Article 4A for the entries Article 4A covers.", "citation": "12 CFR Part 210 (Regulation J), eCFR current text, 210.26, definitions of payment order and Fedwire Funds Service, read 2026-09-17; Federal Reserve Banks Operating Circular No. 4, Automated Clearing House Items, effective January 5, 2026, paragraph 2.1(e)", "rests_on": "law" }, { "label": "Third layer: the consumer's claim runs on its own clock", "value": "A consumer who reports an unauthorized or incorrect electronic transfer within 60 days of the statement that showed it triggers the bank's error resolution duties under Regulation E, whatever happened at settlement. That right does not depend on the return window, and a bank may owe a recredit after the return window has closed.", "citation": "12 CFR Part 1005 (Regulation E), eCFR current text, 1005.11(b)(1)(i) and 1005.11(c), read 2026-09-17", "rests_on": "law" }, { "label": "The practical window: returns run in days, not seconds", "value": "Most returns are due back within 2 banking days of settlement; unauthorized debits to a consumer account run to 60 calendar days, on a written statement from the account holder. Both windows open after settlement is final, so final settlement and safe funds are not the same thing.", "citation": "Nacha, ACH Network Rules: Reversals and Enforcement, rule effective 2021-06-30 and enforcement rule effective 2021-01-01, reversals rule effective 2021-06-30, which states the R11 60 day and R17 2 day return time frames; Popular Bank, ACH Rules Awareness Guide for Businesses, revised 2025-04-02, return time frame table and 24 hour exception note", "rests_on": "rule" }, { "label": "Reversals exist, and they are new entries", "value": "An error can be reversed by originating a reversing entry, not by cancelling the original. The receiving bank is not obliged to post the reversing debit, so a reversal is an attempt to recover money, not a right to it.", "citation": "Nacha, ACH Network Rules: Reversals and Enforcement, rule effective 2021-06-30 and enforcement rule effective 2021-01-01, reversals rule effective 2021-06-30; Popular Bank, ACH Rules Awareness Guide for Businesses, revised 2025-04-02, reversals section", "rests_on": "rule" } ], "exceptions": [ "The finality in Operating Circular 4 is finality between banks that settle through a Reserve Bank. The Clearing House operates the other ACH operator, EPN, and this record does not state EPN settlement finality [Unverified: no EPN rule text was read].", "A same day entry received after the last same day deadline settles on the next banking day, so the finality moment moves with the window the file actually made (Operating Circular 4, Appendix B, paragraph 3.1).", "An entry the Reserve Bank refuses to settle for never reaches finality at all (Operating Circular 4, paragraph 10.4).", "Government entries carry their own overlay: Treasury's reclamation process can pull back federal benefit payments after settlement, and a badly formatted return of a federal payment can be dishonored (Green Book, A Guide to Federal Government ACH Payments, Returns chapter, edition published 2025-03).", "Finality between banks decides nothing about who bears a loss. That is a question of liability, and for a consumer account Regulation E answers it, not the settlement rule." ], "applies_to": "ACH credit and debit entries cleared through the Federal Reserve Banks as ACH operator (FedACH), between US depository institutions, in USD", "caveat": "Do not translate ACH finality into instant payment finality. An instant rail is final and irrevocable per payment; ACH is final per settlement window while the entry itself stays reversible, returnable and disputable for days or weeks. Anyone building a release of goods or funds on ACH should treat the 2 banking day return window as the floor and the 60 day consumer window as the real exposure.", "related": [ "us-ach:settlement", "us-ach:hours", "us-ach:return", "us-ach:recall", "us-ach:refund", "us-ach:liability", "us-ach:consumer-law", "us-ach:decision-points" ], "basis": { "sources": "Federal Reserve Banks Operating Circular 4 (ACH Items), effective 2026-01-05, read in full for this record at frbservices.org: paragraphs 2.1(e), 2.1(h), 2.1(j), 10.4, 11.1, 11.2, 13.1, and Appendix B paragraph 3.1. Regulation J, 12 CFR 210.26 and the appendix commentary to 210.25, read on eCFR 2026-09-17, for the exclusion of ACH from the Fedwire subpart and for the Article 4A and EFTA boundary. Regulation E, 12 CFR 1005.11, read on eCFR 2026-09-17. Nacha public rule page Reversals and Enforcement (nacha.org), read 2026-09-17, for the return time frames attached to improper reversals. Popular Bank ACH Rules Awareness Guide for Businesses (secondary), revised 2025-04-02, for the 2 banking day and 60 calendar day windows as a bank states them to its own originators. The Nacha Operating Rules themselves are paid and were not opened.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "The Operating Circular 4 provisions cited are those of the edition effective 2026-01-05; the drafter did not read earlier editions, so the date each paragraph first took this form is [Unverified]. The 60 day and 2 banking day return windows are long-standing in practice but their governing text is the paid Nacha Operating Rules, which no session may open.", "source_edition": "Federal Reserve Banks Operating Circular 4, effective 2026-01-05; 12 CFR 210 and 12 CFR 1005 as on eCFR 2026-09-17; Nacha public rule pages read 2026-09-17", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.frbservices.org/binaries/content/assets/crsocms/resources/rules-regulations/010526-operating-circular-4.pdf", "source_class": "authoritative_primary", "source_title": "Federal Reserve Banks Operating Circular No. 4, Automated Clearing House Items, effective January 5, 2026", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms credit finality at settlement time (11.2), conditional availability and next-morning unwind of debit credit (11.1), refusal to settle (10.4), no amend or revoke after sending except as ACH rules allow (13.1), the Article 4A definition excluding EFTA-governed and nonvalue traffic (2.1(e), 2.1(j)), and that Article 4A is stated by this circular to sit in Appendix B of Regulation J. Does not confirm the practical 2 banking day and 60 day return windows, which rest on Nacha and bank guide pages only." }, { "source_url": "https://www.ecfr.gov/current/title-12/part-210", "source_class": "authoritative_primary", "source_title": "12 CFR Part 210 (Regulation J), eCFR current text", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms 210.26 excludes automated clearing house transfers from the definitions of payment order and Fedwire Funds Service, so Regulation J subpart B does not reach ACH. Confirms 210.25(b)(1) and 210.26 both place Article 4A in Appendix A of Part 210, not Appendix B, which conflicts with Operating Circular 4 paragraph 2.1(e) naming Appendix B of Regulation J; that conflict is a genuine unresolved discrepancy between the two primary texts, not a drafting error in this record." } ] }, "rail_name": "US ACH", "governing_authority": "Nacha", "snapshot": "2026-09-16", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "us-ach:hours", "id": "hours", "rail": "us-ach", "kind": "rail-fact", "facet": "hours", "name": "When is the rail open, and what are the cutoffs?", "statement": "ACH runs on banking days, not around the clock. Files can be transmitted to the Federal Reserve in six windows spread across the day and night, but the three same day windows close at 10:30, 14:45 and 16:45 Eastern, and anything after that is next day work. Weekends and federal holidays are not banking days, so a Friday afternoon payment commonly reaches the receiver on Monday. A bank's own cutoff for its customers sits earlier than every time here.", "details": [ { "label": "What a banking day is", "value": "A banking day is whatever stretch of a day a Reserve Bank, an account holder or a bank on either side is actually open to take in, work on or send out entries. Where the entry is a credit that counts as an Article 4A payment order, the term shifts to mean a funds transfer business day instead.", "citation": "Federal Reserve Banks Operating Circular No. 4, Automated Clearing House Items, effective January 5, 2026, paragraph 2.1(h), which points to Appendix B for the Reserve Banks' own ACH banking day", "rests_on": "rule" }, { "label": "Same day transmission deadlines", "value": "Three deadlines a day carry an entry to same day settlement: 10:30, 14:45 and 16:45 Eastern. The file has to be fully received by the deadline, so a transmission that begins in the window but finishes after it has missed.", "citation": "FedACH Processing Schedule, effective September 12, 2022, Same Day Eligible Forward Items table with footnote 1, read 2026-09-17", "rests_on": "guidance" }, { "label": "Overnight windows for future dated work", "value": "Future dated files have three further windows after the same day deadlines: 20:00 Eastern Sunday through Thursday, 22:45 Eastern, and 02:15 Eastern. All of them settle at the same 08:30 Eastern morning event on the applicable banking day.", "citation": "FedACH Processing Schedule, effective September 12, 2022, Future Dated Forward Items table with footnotes 4 and 5, read 2026-09-17", "rests_on": "guidance" }, { "label": "Return deadlines follow the same clock", "value": "Electronic returns use the same six transmission deadlines as forward items, with the three earliest settling same day. Returns keyed through the web channel have their own two afternoon deadlines, and paper returns an 08:00 Eastern deadline with an intraday exception at 14:00 Eastern for larger items.", "citation": "FedACH Processing Schedule, effective September 12, 2022, Electronic Return Items, FedLine Web Returns and Paper Returns tables with footnote 6, read 2026-09-17", "rests_on": "guidance" }, { "label": "Release, not transmission, is what counts", "value": "Where a bank uses a service that needs a separate release step, the file counts as sent only once every release step is done. A file not released before the end of day deadline is rejected or deleted, and same day items not released before the final same day deadline are simply processed as next day items.", "citation": "Federal Reserve Banks Operating Circular No. 4, Automated Clearing House Items, effective January 5, 2026, paragraph 3.4", "rests_on": "rule" }, { "label": "How long the network is open", "value": "Nacha describes the network as available for processing 23 and a quarter hours on every business day, settling four times a day while the Federal Reserve's settlement system is open, which it is not on weekends, on federal holidays, or between 18:30 and 07:30 Eastern.", "citation": "Nacha, The ABCs of ACH, read 2026-09-17", "rests_on": "guidance" }, { "label": "When the receiver can use the money", "value": "From 2026-09-18 a receiving bank must make a non same day credit available for withdrawal by 09:00 in its own local time on the settlement date, whenever the file arrived. The earlier condition, which tied that duty to files delivered by 17:00 local the day before, is removed.", "citation": "Nacha, Funds Availability Requirements for Non-Same Day Credit Entries, effective September 18, 2026, quoting Article Three, Subsection 3.3.1.1", "rests_on": "rule" }, { "label": "One geographic exception to that availability rule", "value": "A receiving bank east of the Atlantic time zone and west of the International Date Line, such as one in Guam or the Northern Mariana Islands, which gets the entry from its operator after 08:00 local on the settlement date, has until the end of the settlement date instead, and longer still if the file lands after it has finished processing that day.", "citation": "Nacha, Minor Topics Rule Change, Funds Availability Exceptions for non-Same Day Credit Entries, effective 2026-09-18, quoting Article Three, Subsection 3.3.1.1", "rests_on": "rule" }, { "label": "Industry practice around weekends", "value": "Because settlement cannot happen on a non banking day, pay dates that would fall on a weekend or holiday are commonly funded on the preceding Friday while collections move to the following business day, in each case leaving the consumer better off. This is practice described by Nacha, not a rule of the circular.", "citation": "Nacha, The ABCs of ACH, standard industry practices section, read 2026-09-17", "rests_on": "practice" } ], "exceptions": [ "Paper returns are outside the FedACH Processing Schedule entirely and run on terms the Reserve Bank agrees case by case (Operating Circular 4, paragraph 14.5).", "The 20:00 Eastern window does not run on Friday nights (FedACH Processing Schedule, footnote 5).", "Distribution times are targets, not commitments, and the Reserve Banks accept no liability for a later distribution, so the hour a receiving bank sees a file can slip (FedACH Processing Schedule, footnote 2).", "The Reserve Banks may amend the FedACH Processing Schedule at any time, so every clock time here is current rather than fixed (Operating Circular 4, paragraph 2.1(n)).", "Funds availability for same day credits runs on its own deadline in the Nacha rules, which the drafter did not find stated on a public page and does not assert here." ], "applies_to": "ACH files sent to and received from the Federal Reserve Banks as ACH operator (FedACH); a bank's own customer cutoffs and the hours of the other operator, EPN, are outside this record", "caveat": "Every time in this record is a Reserve Bank deadline, and no customer ever sees them. Banks and processors set their own cutoffs hours earlier so they can assemble, screen and release a file. An agent planning around same day ACH should ask its bank for that bank's cutoff, not read the 16:45 Eastern deadline as the last moment to pay.", "related": [ "us-ach:settlement", "us-ach:finality", "us-ach:limits", "us-ach:return", "us-ach:messages" ], "basis": { "sources": "FedACH Processing Schedule, effective 2022-09-12, read at frbservices.org 2026-09-17: the four item class tables and footnotes 1 through 6. Federal Reserve Banks Operating Circular 4 (ACH Items), effective 2026-01-05, read in full for this record: paragraphs 2.1(h), 2.1(n), 3.4, 14.5 and Appendix B. Nacha public pages read 2026-09-17: The ABCs of ACH, for network hours, settlements per day and weekend practice; Funds Availability Requirements for Non-Same Day Credit Entries and the related Minor Topics rule page, both effective 2026-09-18, which quote Article Three, Subsection 3.3.1.1 of the Nacha Operating Rules. The Nacha Operating Rules themselves are paid and were not opened.", "confidence": "medium" }, "currency": { "effective_since": "2022-09-12", "effective_to": null, "effective_note": "The clock times are those of the FedACH Processing Schedule effective 2022-09-12. The funds availability lines take effect 2026-09-18, one day after this record was drafted; until then the earlier rule, which conditioned the 09:00 duty on delivery by 17:00 local the previous banking day, still applies. A Nacha Minor Topics rule in force 2026-01-01 is recorded in the watch log in Orca's US ACH rail brief (docs/rails/us-ach.md) as narrowing the Banking Day definition to ACH Operator processing days [Unverified: no public Nacha page read for this record states it].", "source_edition": "FedACH Processing Schedule, effective 2022-09-12; Federal Reserve Banks Operating Circular 4, effective 2026-01-05; Nacha public rule pages read 2026-09-17", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.frbservices.org/binaries/content/assets/crsocms/resources/rules-regulations/010526-operating-circular-4.pdf", "source_class": "authoritative_primary", "source_title": "Federal Reserve Banks Operating Circular No. 4, Automated Clearing House Items, effective January 5, 2026", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the banking day definition and its Article 4A funds transfer business day variant (2.1(h)), release not transmission governing when a file counts as sent (3.4), and Appendix B's banking day, effective date window and settlement date mechanics (Appendix B 1.1, 2.1, 2.2, 3.1)." }, { "source_url": "https://www.frbservices.org/resources/resource-centers/same-day-ach/fedach-processing-schedule.html", "source_class": "authoritative_primary", "source_title": "FedACH Processing Schedule, effective September 12, 2022", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the three same day transmission deadlines 10:30, 14:45 and 16:45 ET, the future dated windows including 20:00 ET (Sunday-Thursday only, not Friday), 22:45 and 02:15 ET all settling 08:30 ET, the six electronic return deadlines mirroring forward items, the FedLine Web Returns deadlines including two in the afternoon (14:45 and 16:45 ET) plus an overnight one, the paper returns 08:00 ET deadline with a 14:00 ET intraday exception for items over 10,000 dollars, and the footnote that distribution times are targets with no Reserve Bank liability for a later distribution." }, { "source_url": "https://www.nacha.org/rules/funds-availability-requirements-non-same-day-credit-entries", "source_class": "public_primary", "source_title": "Nacha, Funds Availability Requirements for Non-Same Day Credit Entries, effective September 18, 2026", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the 09:00 local time funds availability duty for non-same-day credits effective 2026-09-18, that it removes the prior condition tying the duty to delivery by 17:00 local the previous day, and the related time zone exception for RDFIs east of Atlantic time and west of the date line (Guam, Northern Mariana Islands)." } ] }, "rail_name": "US ACH", "governing_authority": "Nacha", "snapshot": "2026-09-16", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "us-ach:liability", "id": "liability", "rail": "us-ach", "kind": "rail-fact", "facet": "liability", "name": "Who bears the loss when something goes wrong?", "statement": "Loss on ACH lands in three different places depending on who the account belongs to. A consumer is protected by statute and pays at most a capped amount for an unauthorised transfer. Between banks, the originating bank warrants that the entry was authorised, and the receiving bank can claim against that warranty for up to a year, or two years on a consumer account. The Federal Reserve, as operator, warrants nothing at all and limits its own liability to its failure to use ordinary care.", "details": [ { "label": "The consumer's exposure is capped", "value": "A consumer's liability for an unauthorised transfer is limited to $50 where they tell the bank within 2 business days of learning of a loss or theft of an access device, and to $500 where they do not. Both caps depend on the bank having given the required disclosures.", "citation": "12 CFR Part 1005 (Regulation E), eCFR current text, 1005.6(a) and 1005.6(b)(1) and (2), read 2026-09-17", "rests_on": "law" }, { "label": "The 60 day line on a statement", "value": "A consumer who does not report an unauthorised transfer shown on a statement within 60 days of the bank sending it can be liable for the later transfers the bank shows would have been prevented by earlier notice. Delay caused by extenuating circumstances extends the period.", "citation": "12 CFR Part 1005 (Regulation E), eCFR current text, 1005.6(b)(3) and (b)(4), read 2026-09-17", "rests_on": "law" }, { "label": "The warranty that carries loss back to the originating side", "value": "The originating bank warrants that an entry was authorised, and the receiving bank can make a claim on that warranty when it has recredited its customer. Nacha limits the claim to one year from settlement for a non consumer account, and for a consumer account to the first 95 days from settlement of the first unauthorised entry or otherwise two years.", "citation": "Nacha, Limitation on Warranty Claims, rule effective 2021-06-30, read 2026-09-17", "rests_on": "rule" }, { "label": "ODFI indemnity for a request for return", "value": "An ODFI that asks an RDFI to return an entry indemnifies the RDFI for honoring the request.", "citation": "Popular Bank, ACH Rules Awareness Guide for Businesses, revised 2025-04-02, return reason code table for R06, naming Article Two, Subsection 2.12.3", "rests_on": "rule" }, { "label": "The operator's liability, and what it is not", "value": "For items other than Article 4A credits, a Reserve Bank answers only to a sending bank, a receiving bank or another Reserve Bank, and only for its own failure to use ordinary care or for wilful misconduct. It is not an agent of another bank, and it makes no warranty about an item it processes or settles.", "citation": "Federal Reserve Banks Operating Circular No. 4, Automated Clearing House Items, effective January 5, 2026, paragraph 21.1", "rests_on": "rule" }, { "label": "How damages against the operator are measured", "value": "For a credit item, damages are limited to what follows directly and immediately from the failure, with consequential loss excluded even where it was foreseeable. For a debit item, liability for lack of ordinary care is capped at the amount of the item less what ordinary care could not have recovered.", "citation": "Federal Reserve Banks Operating Circular No. 4, Automated Clearing House Items, effective January 5, 2026, paragraph 21.2", "rests_on": "rule" }, { "label": "Article 4A credits are a separate regime", "value": "Where the entry is a credit item that is a payment order under Article 4A, the Reserve Bank's liability runs under Article 4A and nothing else, and it will not agree to consequential damages under section 4A-305(d).", "citation": "Federal Reserve Banks Operating Circular No. 4, Automated Clearing House Items, effective January 5, 2026, paragraph 22.1", "rests_on": "law" }, { "label": "Two deadlines that quietly destroy claims", "value": "A bank has 30 calendar days from an advice of debit to raise an unauthorised or wrongly executed item; later notice can count as a failure of ordinary care and cost it interest and other damages. No claim survives one year from the settlement date, and a suit against a Reserve Bank must start within one year.", "citation": "Federal Reserve Banks Operating Circular No. 4, Automated Clearing House Items, effective January 5, 2026, paragraphs 16.2, 21.1(d) and 23.2", "rests_on": "rule" }, { "label": "Banks indemnify the operator, not the other way round", "value": "Both the sending bank and the receiving bank agree to indemnify the Reserve Banks for loss from a breach of their agreements or from action the Reserve Bank took under the circular, except where the loss comes solely from the Reserve Bank's own lack of ordinary care or bad faith.", "citation": "Federal Reserve Banks Operating Circular No. 4, Automated Clearing House Items, effective January 5, 2026, paragraphs 5.1 and 12.1(d)", "rests_on": "rule" }, { "label": "Fraud duties are monitoring duties, not a loss rule", "value": "From 2026 the rules require originating banks, larger originators and service providers to run risk based fraud detection, and larger receiving banks to monitor inbound credits, with the rest following on 2026-06-19. Nacha defines False Pretenses for this purpose, covering impersonation of a person, of authority or of account ownership. None of this says who pays when a scam succeeds.", "citation": "Nacha, Risk Management Topics, Fraud Monitoring Phase 1, effective 2026-03-20, read 2026-09-17; Nacha, Risk Management Topics, Fraud Monitoring Phase 2, effective 2026-06-19, read 2026-09-17", "rests_on": "rule" }, { "label": "Settlement risk sits with the Reserve Bank's discretion", "value": "A Reserve Bank may refuse to settle where it doubts the account will cover the item, take a security interest in the bank's property held at any Reserve Bank, and set off without notice to recover what it is owed.", "citation": "Federal Reserve Banks Operating Circular No. 4, Automated Clearing House Items, effective January 5, 2026, paragraphs 10.3 and 10.4", "rests_on": "rule" } ], "exceptions": [ "Article 4A does not apply at all to an entry any part of which is governed by the Electronic Fund Transfer Act, so most consumer traffic is outside the commercial law regime described here (Operating Circular 4, paragraph 2.1(j); 12 CFR 210.25 appendix commentary).", "State law or a bank's own agreement may impose less consumer liability than Regulation E, and then the lower figure governs (12 CFR 1005.6(b)(6)).", "A payment a consumer was tricked into authorising is not an unauthorised transfer on the face of the error definition, so these caps do not reach it [Inference from 12 CFR 1005.11(a)(1); no CFPB interpretation read].", "The circular's limits bind the Reserve Banks as operator. They say nothing about liability between an originator and its own bank, which is contractual.", "Government entries add Treasury's reclamation liability, under which a financial institution that does not return or properly handle a payment after a death can be left owing the money (Green Book, Reclamations chapter, edition published 2025-03)." ], "applies_to": "losses on ACH entries cleared through the Federal Reserve Banks, allocated between consumers, originators, originating and receiving banks, and the Reserve Banks as operator", "caveat": "Three regimes answer this question and they do not have the same deadlines: 60 days for the consumer to report, 2 banking days or 60 calendar days to return, one year or two for a warranty claim, 30 calendar days to object to an operator's advice. A payments team should map its own exposure against all four rather than assuming one window closes the matter.", "related": [ "us-ach:refund", "us-ach:return", "us-ach:finality", "us-ach:settlement", "us-ach:consumer-law", "us-ach:participants", "us-ach:decision-points" ], "basis": { "sources": "Two independent organisations for each interbank line, because the warranties live in the paid Nacha Operating Rules. Federal Reserve Banks Operating Circular 4, effective 2026-01-05, read in full for this record at frbservices.org: paragraphs 2.1(j), 5.1, 10.3, 10.4, 12.1, 16.2, 16.3, 21.1, 21.2, 22.1, 22.2 and 23.2. Regulation E, 12 CFR 1005.6, read on eCFR 2026-09-17. Nacha public rule pages (nacha.org), read 2026-09-17: Limitation on Warranty Claims, rule effective 2021-06-30, for the authorisation warranty and its time limits; the two Fraud Monitoring rule pages for the 2026 monitoring duties and the False Pretenses definition. Popular Bank ACH Rules Awareness Guide for Businesses, revised 2025-04-02 (secondary), for the R06 indemnity in that bank's own wording. Regulation J, 12 CFR 210.25 appendix commentary, for the Article 4A and EFTA boundary. The rulebook itself was not opened.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "The warranty claim limits took effect 2021-06-30 and the fraud monitoring duties on 2026-03-20 and 2026-06-19. The Operating Circular 4 paragraphs are those of the edition effective 2026-01-05; earlier editions were not read, so when each took this form is [Unverified]. The Regulation E liability figures of $50 and $500 are the current eCFR text and are not indexed.", "source_edition": "Federal Reserve Banks Operating Circular 4, effective 2026-01-05; 12 CFR 1005 and 12 CFR 210 as on eCFR 2026-09-17; Nacha public rule pages read 2026-09-17; Popular Bank guide revised 2025-04-02", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "primary_not_public": true, "corroboration": [ { "source_url": "https://www.frbservices.org/binaries/content/assets/crsocms/resources/rules-regulations/010526-operating-circular-4.pdf", "source_class": "authoritative_primary", "source_title": "Federal Reserve Banks Operating Circular No. 4, Automated Clearing House Items, effective January 5, 2026", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the Reserve Bank's own liability limits and disclaimers: liability only to a sending/receiving bank for its own failure of ordinary care or willful misconduct and no warranty on items processed (21.1), the credit/debit damages measures (21.2), the separate Article 4A liability regime for credit items subject to it (22.1), the 30 calendar day notice window and one year claim/suit limits (16.2, 21.1(d), 23.2), and the sending/receiving bank indemnities to the Reserve Banks (5.1(e), 12.1(d)). Does not confirm the Nacha authorization warranty or its claim-period figures." }, { "source_url": "https://www.nacha.org/rules/limitation-warranty-claims", "source_class": "public_primary", "source_title": "Nacha, Limitation on Warranty Claims, rule effective 2021-06-30", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the ODFI authorization warranty claim limits: one year from settlement for a non-consumer account, and for a consumer account the first 95 calendar days from settlement of the first unauthorized entry or otherwise two years from settlement, with the 95 days explained as covering the Regulation E statement-cycle-plus-60-day arithmetic. Independent of Operating Circular 4: different organisation, different host, own wording." } ] }, "rail_name": "US ACH", "governing_authority": "Nacha", "snapshot": "2026-09-16", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "not_public", "label": "the operator's own text", "needs": "what the operator's own text says, which Orca has not read", "detail": "Nacha's own text is not the source for this rail fact: it is not public, or not under terms Orca can use. It rests on 2 named public sources, so a term set by agreement rather than by a published rule is not Orca's to state.", "from": "currency.primary_not_public" } ] }, { "uid": "us-ach:limits", "id": "limits", "rail": "us-ach", "kind": "rail-fact", "facet": "limits", "name": "What amount limits apply, and who sets them?", "statement": "One network limit is published: a Same Day ACH entry may not exceed $1,000,000, and that ceiling becomes $10,000,000 on 2027-09-17. No public source read here states any per entry ceiling for ordinary next day or two day ACH. The limits that actually stop a payment are set lower down: the originating bank's exposure limit for its customer, and the processor's own caps. Those are commercial, private, and the ones worth asking about.", "details": [ { "label": "The Same Day ACH ceiling today", "value": "$1,000,000 per payment, in force since 2022-03-18. It applies to a single entry, whichever of the three same day windows is used, for credits and debits and for consumer and business payments alike.", "citation": "Nacha, Same Day ACH Expansion to $1 Million Begins Today, press release dated 2022-03-18, read 2026-09-17", "rests_on": "rule" }, { "label": "The ceiling that is coming", "value": "The per payment ceiling rises tenfold to $10,000,000 on 2027-09-17, again across all eligible SEC codes, both directions and all three windows.", "citation": "Nacha, Increasing the Same Day ACH Dollar Limit to $10 Million, effective September 17, 2027, read 2026-09-17; Nacha, The ABCs of ACH, read 2026-09-17", "rests_on": "rule" }, { "label": "How the operator sees the limit", "value": "The Federal Reserve's own circular does not restate the figure. It requires a same day item to stay within whatever dollar limit the Nacha rules set, which is how a private rulebook number becomes an operator edit.", "citation": "Federal Reserve Banks Operating Circular No. 4, Automated Clearing House Items, effective January 5, 2026, paragraph 3.3(b)", "rests_on": "rule" }, { "label": "Eligibility limits, not just dollar limits", "value": "Same day settlement is open to every Standard Entry Class code apart from two, the international code IAT and the enrollment code ENR, and the entry's effective entry date cannot be after the banking day the Reserve Bank takes it in. An international entry is therefore out of same day whatever its amount.", "citation": "Federal Reserve Banks Operating Circular No. 4, Automated Clearing House Items, effective January 5, 2026, paragraph 3.3(b); Nacha, Increasing the Same Day ACH Dollar Limit to $10 Million, effective September 17, 2027, which states IAT stays ineligible", "rests_on": "rule" }, { "label": "Other dollar limits exist and are not published", "value": "Nacha states that separate dollar limits for ARC, BOC, POP, RCK and XCK entries survive the increase, without giving their values. Those figures sit in the paid rulebook and no public source read here states them.", "citation": "Nacha, Increasing the Same Day ACH Dollar Limit to $10 Million, effective September 17, 2027, details section, read 2026-09-17", "rests_on": "rule" }, { "label": "No published ceiling on non same day entries", "value": "Nothing in the Federal Reserve circular, the FedACH Processing Schedule or the Nacha public pages read here sets a maximum amount for an ordinary next day or two day ACH entry. Treat the absence as unproven rather than as a confirmed absence of any rule.", "citation": "Federal Reserve Banks Operating Circular No. 4, Automated Clearing House Items, effective January 5, 2026, read in full; FedACH Processing Schedule, effective September 12, 2022; Nacha, Increasing the Same Day ACH Dollar Limit to $10 Million, effective September 17, 2027, and the other Nacha public rule pages read 2026-09-17", "rests_on": "rule" }, { "label": "The limit a sender actually hits", "value": "In practice the binding constraint is the originating bank's exposure limit for its own customer, or a processor's cap and risk hold. A processor may also block a bank account outright after certain returns, so a payment can fail on risk grounds with no amount involved.", "citation": "Stripe documentation, ACH Direct Debit payments, read 2026-09-17, on blocked bank accounts and automatic retry caps; Popular Bank, ACH Rules Awareness Guide for Businesses, revised 2025-04-02, on the bank's right to cancel ACH services for non compliance", "rests_on": "practice" }, { "label": "Funding capacity can act as a limit", "value": "Where a sending bank's Administrative Reserve Bank requires prefunding, credit originations that are not prefunded may simply be rejected. The effective ceiling is then the balance in the settlement account, not any rule figure.", "citation": "Federal Reserve Banks Operating Circular No. 4, Automated Clearing House Items, effective January 5, 2026, paragraph 5.3 with Appendix C", "rests_on": "rule" } ], "exceptions": [ "Structuring a payment to fit the same day ceiling is not allowed: Nacha's guidance on the $1 million limit states a payment may not be broken up to evade it, though several genuinely separate invoices may each be paid same day [Unverified: read in a search summary of Nacha's guidance PDF, which the drafter could not extract, not in the PDF itself].", "What an operator does with a same day entry above the limit is not stated in any source read here; Operating Circular 4 paragraph 3.3(b) only forbids it.", "The Clearing House's EPN may apply its own limits; no EPN rule text was read [Unverified].", "Government ACH payments carry Treasury's own rules and limits, which this record does not state (Green Book, A Guide to Federal Government ACH Payments, edition published 2025-03).", "Amount limits say nothing about risk thresholds. Nacha's return rate thresholds (0.5 percent for unauthorized entries, 3 percent administrative, 15 percent overall) constrain an originator independently of any dollar figure." ], "applies_to": "ACH entries originated in the United States in USD, with the same day figures applying to entries flagged for Same Day ACH settlement", "caveat": "Both published figures are per entry, not per batch or per file, so a large obligation can be split across entries only where the underlying payments are genuinely separate. The number an agent should plan against is the one its own bank or processor has set, which is never published and is usually well below $1,000,000.", "related": [ "us-ach:settlement", "us-ach:hours", "us-ach:finality", "us-ach:messages", "us-ach:participants" ], "basis": { "sources": "Two independent organisations, because the governing text is the paid Nacha Operating Rules. Nacha public pages (nacha.org), read 2026-09-17: the press release dated 2022-03-18 that records the $1 million limit starting that day; the rule page Increasing the Same Day ACH Dollar Limit to $10 Million, effective 2027-09-17, which also states that ARC, BOC, POP, RCK and XCK limits continue and that IAT stays ineligible; The ABCs of ACH. Federal Reserve Banks (frbservices.org), read 2026-09-17: Operating Circular 4, effective 2026-01-05, paragraphs 3.3(b) and 5.3, which bind a same day item to the Nacha dollar limit and to the SEC code exclusions, and the FedACH Processing Schedule effective 2022-09-12. Stripe documentation and the Popular Bank originator guide, both secondary, for the commercial limits that bite first. The rulebook itself was not opened.", "confidence": "medium" }, "currency": { "effective_since": "2022-03-18", "effective_to": null, "effective_note": "The $1,000,000 per payment limit has applied since 2022-03-18. A change is already dated: on 2027-09-17 the limit becomes $10,000,000, at which point this record should be superseded rather than edited. The values of the ARC, BOC, POP, RCK and XCK limits are not public.", "source_edition": "Nacha public rule and news pages read 2026-09-17; Federal Reserve Banks Operating Circular 4, effective 2026-01-05; FedACH Processing Schedule, effective 2022-09-12", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "primary_not_public": true, "corroboration": [ { "source_url": "https://www.nacha.org/rules/increasing-same-day-ach-dollar-limit-10-million-0", "source_class": "public_primary", "source_title": "Nacha, Increasing the Same Day ACH Dollar Limit to $10 Million, effective September 17, 2027", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the current $1,000,000 per payment Same Day ACH ceiling in force since 2022-03-18 (third increase after $25,000 at launch and $100,000 in 2020), the future rise to $10,000,000 on 2027-09-17, and that IAT stays ineligible for same day settlement." }, { "source_url": "https://www.frbservices.org/binaries/content/assets/crsocms/resources/rules-regulations/010526-operating-circular-4.pdf", "source_class": "authoritative_primary", "source_title": "Federal Reserve Banks Operating Circular No. 4, Automated Clearing House Items, effective January 5, 2026", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms paragraph 3.3(b): a same day item must not exceed the dollar amount limit in the Nacha Operating Rules and may use any SEC code except IAT or ENR, which is how the operator's circular defers to the private rulebook figure. Independent of the Nacha source: different organisation (Federal Reserve, not Nacha), different host, own wording." } ] }, "rail_name": "US ACH", "governing_authority": "Nacha", "snapshot": "2026-09-16", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "eligibility", "label": "the transaction type", "needs": "which transaction type the entry used", "detail": "The rule this rests on, Eligibility limits, not just dollar limits, applies to every SEC code except IAT and ENR.", "from": "us-ach:rule.limits-eligibility-limits-not-just-dollar-limits" }, { "kind": "not_public", "label": "the operator's own text", "needs": "what the operator's own text says, which Orca has not read", "detail": "Nacha's own text is not the source for this rail fact: it is not public, or not under terms Orca can use. It rests on 2 named public sources, so a term set by agreement rather than by a published rule is not Orca's to state.", "from": "currency.primary_not_public" } ] }, { "uid": "us-ach:messages", "id": "messages", "rail": "us-ach", "kind": "rail-fact", "facet": "messages", "name": "What message format does the rail use, and what travels with a payment?", "statement": "ACH does not send messages, it sends files of fixed width records, 94 bytes to a line, grouped into batches. Each batch carries a three letter Standard Entry Class code saying how the payment was authorised, and each entry may carry addenda records for remittance detail. The format is defined in the Nacha rules, which are paid; the Federal Reserve's circular simply requires that format and whatever media it prescribes. There is no ISO 20022 message on this rail.", "details": [ { "label": "The record line", "value": "An ACH record line is 94 bytes. Nacha's 2027 rule on accepted characters is explicit that multi byte characters are discouraged precisely because a line must not exceed 94 bytes.", "citation": "Nacha, Currently Accepted Characters in the ACH Network, effective January 1, 2027, read 2026-09-17", "rests_on": "rule" }, { "label": "The record types a payment uses", "value": "A batch carries a company or batch header record, then entry detail records, optionally entry detail addenda records, then a company or batch control record. Treasury's guidance names the same three around a return, because a return copies them from the original.", "citation": "Green Book, A Guide to Federal Government ACH Payments, edition published 2025-03, Returns chapter; Nacha, Currently Accepted Characters in the ACH Network, effective January 1, 2027, which speaks of the ACH Record", "rests_on": "rule" }, { "label": "Who defines the format", "value": "The operator does not define it. The Federal Reserve's circular requires only that an entry arrive on whatever media the Reserve Banks specify and in whatever layout the applicable ACH rules set, which points straight at the Nacha rules.", "citation": "Federal Reserve Banks Operating Circular No. 4, Automated Clearing House Items, effective January 5, 2026, paragraph 3.3(a)", "rests_on": "rule" }, { "label": "The Standard Entry Class code", "value": "Every batch carries a three letter SEC code describing how the customer authorised the debit or credit, and it decides which authorisation and dispute rules apply. Nacha defines and maintains the codes; an originator choosing the wrong one is outside the rules for that entry.", "citation": "Stripe documentation, Overview of ACH SEC codes, read 2026-09-17; Federal Reserve Banks Operating Circular No. 4, Automated Clearing House Items, effective January 5, 2026, paragraph 3.3(b), which excludes IAT and ENR from same day settlement by code", "rests_on": "rule" }, { "label": "Traffic that moves no money", "value": "The same file format carries non value entries: prenotifications, notifications of change, zero dollar returns and automated enrollment entries. The circular separates them out, both in its Article 4A definition and in the paragraph capping a Reserve Bank's liability for handling them at the fee paid.", "citation": "Federal Reserve Banks Operating Circular No. 4, Automated Clearing House Items, effective January 5, 2026, paragraphs 2.1(j) and 19.1", "rests_on": "rule" }, { "label": "Correcting the data rather than the payment", "value": "A notification of change tells the originator the account data was wrong without returning the entry. Popular Bank's ACH Rules Awareness Guide for Businesses states the originator must apply the correction within 6 banking days of receiving it or before sending another entry.", "citation": "Popular Bank, ACH Rules Awareness Guide for Businesses, revised 2025-04-02, originator responsibilities; Green Book, A Guide to Federal Government ACH Payments, edition published 2025-03, Notification of Change chapter", "rests_on": "rule" }, { "label": "The description field is becoming meaningful", "value": "From 2026-03-20 the company entry description field carries standard values: PAYROLL for a PPD credit paying wages, and PURCHASE for a consumer e-commerce debit, which normally uses the WEB code. The originating bank is expressly not obliged to check that PURCHASE is used correctly.", "citation": "Nacha, Risk Management Topics, Company Entry Descriptions, effective 2026-03-20, which names Appendix Three, Subpart 3.2.2; Popular Bank, ACH Rules Awareness Guide for Businesses, revised 2025-04-02, upcoming revisions section", "rests_on": "rule" }, { "label": "REVERSAL is a field value, not a message type", "value": "A reversal is an ordinary entry whose company entry description says REVERSAL and whose company identification, SEC code and amount match the original. There is no separate cancellation message on this rail.", "citation": "Nacha, ACH Network Rules: Reversals and Enforcement, rule effective 2021-06-30 and enforcement rule effective 2021-01-01, reversals rule effective 2021-06-30; Popular Bank, ACH Rules Awareness Guide for Businesses, revised 2025-04-02", "rests_on": "rule" }, { "label": "What identifies an entry afterwards", "value": "The trace number carries the originating bank's routing number and a unique item number, and it appears in the entry detail, corporate entry detail and addenda records. It is the field any later return, dishonour or trace is matched on.", "citation": "Green Book, A Guide to Federal Government ACH Payments, edition published 2025-03, trace number description and the four fields a return must match", "rests_on": "rule" }, { "label": "Character handling is not uniform between operators", "value": "Some characters are accepted by one operator and not the other. Where such a character is sent to an operator that accepts it but the entry must pass through the other, the value may be wild carded, and a file with a character an operator does not accept may be pended or rejected.", "citation": "Nacha, Currently Accepted Characters in the ACH Network, effective January 1, 2027", "rests_on": "rule" } ], "exceptions": [ "The full record layouts, field positions and the complete SEC code list sit in the Nacha rules and its appendices, which are paid; this record names the structure without reproducing any layout.", "Addenda capacity differs by code, with corporate formats carrying far more remittance data than consumer ones; this record does not state the per code limits [Unverified: no public source read gives them].", "Nacha runs programmes mapping between ACH and ISO 20022 for participants that need it, but the entries themselves remain fixed width records [Unverified: taken from Nacha's site navigation, not from a page read for this record].", "Federal payments carry Treasury specific conventions on top of the format, including claim number structures in the individual identification field (Green Book, Returns chapter, edition published 2025-03).", "The 94 byte line and the record types are stable, but the character table rule takes effect 2027-01-01 and should be re-read then." ], "applies_to": "ACH files exchanged between US depository institutions and the ACH operators, in the Nacha file format", "caveat": "An agent used to ISO 20022 will find no structured party data, no purpose code vocabulary and no response message here. What it gets is a batch header, fixed fields and a three letter class code. Anything richer has to go in addenda records, and whether the receiving side ever sees them depends on that bank.", "related": [ "us-ach:return", "us-ach:recall", "us-ach:limits", "us-ach:settlement", "us-ach:participants" ], "basis": { "sources": "Two independent organisations for each structural line, because the format specification is in the paid Nacha Operating Rules. Nacha public rule pages (nacha.org), read 2026-09-17: Currently Accepted Characters in the ACH Network, effective 2027-01-01, for the 94 byte record and operator character differences; Risk Management Topics, Company Entry Descriptions, effective 2026-03-20, naming Appendix Three, Subpart 3.2.2; Reversals and Enforcement, rule effective 2021-06-30. US Treasury Bureau of the Fiscal Service Green Book, edition published 2025-03 (tfx.treasury.gov), for the record types around a return, the trace number and the matching fields. Federal Reserve Banks Operating Circular 4, effective 2026-01-05, paragraphs 3.3(a), 3.3(b), 2.1(j) and 19.1. Stripe documentation (secondary) for the SEC code's role. Popular Bank guide revised 2025-04-02 (secondary) for notification of change handling. No rulebook appendix was opened and no layout is reproduced here.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "The file format is long-standing and no source read here dates it. Two dated changes touch this facet: standard company entry descriptions from 2026-03-20, and the documented character table from 2027-01-01.", "source_edition": "Nacha public rule pages read 2026-09-17; Green Book edition published 2025-03; Federal Reserve Banks Operating Circular 4, effective 2026-01-05; Stripe documentation read 2026-09-17", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "primary_not_public": true, "corroboration": [ { "source_url": "https://www.nacha.org/rules/currently-accepted-characters-ach-network", "source_class": "public_primary", "source_title": "Nacha, Currently Accepted Characters in the ACH Network, effective January 1, 2027", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the 94 byte ACH record line, that multi-byte characters are not recommended because they would break the 94 byte limit, that some characters are accepted by only one ACH Operator (risking wild-carding on pass-through), and that a file with a character an Operator does not accept may be pended or rejected." }, { "source_url": "https://www.frbservices.org/binaries/content/assets/crsocms/resources/rules-regulations/010526-operating-circular-4.pdf", "source_class": "authoritative_primary", "source_title": "Federal Reserve Banks Operating Circular No. 4, Automated Clearing House Items, effective January 5, 2026", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the operator requires only the media and format the applicable ACH rules set (3.3(a)), the SEC-code-based same day exclusions for IAT and ENR (3.3(b)), and the Article 4A credit item definition separating out nonvalue traffic such as prenotifications, NOCs, zero dollar returns and automated enrollment (2.1(j), 19.1). Independent of the Nacha source: different organisation, different host, own wording." } ] }, "rail_name": "US ACH", "governing_authority": "Nacha", "snapshot": "2026-09-16", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "not_public", "label": "the operator's own text", "needs": "what the operator's own text says, which Orca has not read", "detail": "Nacha's own text is not the source for this rail fact: it is not public, or not under terms Orca can use. It rests on 2 named public sources, so a term set by agreement rather than by a published rule is not Orca's to state.", "from": "currency.primary_not_public" } ] }, { "uid": "us-ach:participants", "id": "participants", "rail": "us-ach", "kind": "rail-fact", "facet": "participants", "name": "Who can take part, and in what role?", "statement": "Five named roles carry every ACH payment: the Originator who instructs it, its bank the ODFI, an ACH Operator, the receiving bank or RDFI, and the Receiver. Only a depository institution can be an ODFI or RDFI, and only one with a settlement account at a Reserve Bank can send to FedACH. Businesses reach the rail through their bank, or through a Third-Party Sender that has its own registration and risk duties. There are exactly two operators: the Federal Reserve and The Clearing House.", "details": [ { "label": "The five roles", "value": "The Originator instructs the payment; its bank, the ODFI, puts it into a file; the ACH Operator sorts and routes it; the RDFI posts it; the Receiver is the account holder on the other side. The same five roles carry both credits and debits, with the direction of money reversed.", "citation": "Nacha, How ACH Payments Work, read 2026-09-17", "rests_on": "guidance" }, { "label": "There are two operators, not one", "value": "The Federal Reserve and The Clearing House both operate ACH. A change to the network is implemented with both so that an entry reaches any account whichever operator carried it.", "citation": "Nacha, How ACH Payments Work, read 2026-09-17; Nacha, Same Day ACH Expansion to $1 Million Begins Today, press release dated 2022-03-18, which quotes both Federal Reserve Financial Services and The Clearing House on the same rule change", "rests_on": "guidance" }, { "label": "Who counts as a bank for FedACH", "value": "Four kinds of entity qualify as a bank for this purpose: a depository institution as the Federal Reserve Act defines one at section 19(b)(1)(A); a US branch or agency of a foreign bank that holds reserves under the International Banking Act; a federal government body or a government owned corporation; and anyone else a Reserve Bank serves with FedACH directly.", "citation": "Federal Reserve Banks Operating Circular No. 4, Automated Clearing House Items, effective January 5, 2026, paragraph 2.1(g)", "rests_on": "rule" }, { "label": "The entry condition is a settlement account", "value": "A sending bank may send to any Reserve Bank only if it maintains or uses a settlement account at a Reserve Bank and the receiving bank does too. Both sides must designate that account to their Administrative Reserve Bank before anything moves.", "citation": "Federal Reserve Banks Operating Circular No. 4, Automated Clearing House Items, effective January 5, 2026, paragraphs 3.1 and 9.1", "rests_on": "rule" }, { "label": "A correspondent's account can be used, and it changes nothing", "value": "A bank may settle through a correspondent's account with that correspondent's agreement, but the correspondent does not thereby become a party to the entry or a sender under Article 4A, and the bank stays responsible for everything.", "citation": "Federal Reserve Banks Operating Circular No. 4, Automated Clearing House Items, effective January 5, 2026, paragraph 9.1", "rests_on": "rule" }, { "label": "Agents are allowed and the bank still owns the outcome", "value": "A sending bank may name an agent, including another ACH operator or the operator of its sending point, to send entries for it. It must make sure the agent complies with its own obligations, is bound by the agent's acts and omissions, and indemnifies the Reserve Banks for losses arising from them.", "citation": "Federal Reserve Banks Operating Circular No. 4, Automated Clearing House Items, effective January 5, 2026, paragraph 3.5", "rests_on": "rule" }, { "label": "Third-Party Senders, including nested ones", "value": "A business may reach the rail through a Third-Party Sender rather than directly. Since 2022-09-30 the rules define a Nested Third-Party Sender, set out the chain of agreements, and require every Third-Party Sender to complete its own risk assessment rather than rely on another's.", "citation": "Nacha, Third-Party Sender Roles and Responsibilities, rule effective 2022-09-30, read 2026-09-17", "rests_on": "rule" }, { "label": "New duties reach originators and service providers directly", "value": "From 2026-03-20 fraud monitoring duties fall on every ODFI and on non consumer Originators, Third-Party Service Providers and Third-Party Senders that originated 6 million or more entries in 2023, with receiving banks above 10 million receipts monitoring inbound credits. Everyone else follows on 2026-06-19.", "citation": "Nacha, Risk Management Topics, Fraud Monitoring Phase 1, effective 2026-03-20; Nacha, Risk Management Topics, Fraud Monitoring Phase 2, effective 2026-06-19", "rests_on": "rule" }, { "label": "Receiving is an agreement too", "value": "A receiving bank that keeps a settlement account or accepts an entry from a Reserve Bank thereby agrees to follow the ACH rules, to process under the circular, to accept that the Reserve Banks act as ACH operator rather than as collecting or returning banks, and to indemnify them.", "citation": "Federal Reserve Banks Operating Circular No. 4, Automated Clearing House Items, effective January 5, 2026, paragraph 12.1", "rests_on": "rule" }, { "label": "The sanction for breaking the rules", "value": "Nacha enforces against participants through a rules enforcement panel. An egregious violation, meaning a wilful or reckless act involving at least 500 entries or entries totalling at least $500,000, can be classed as a Class 3 violation carrying up to $500,000 per occurrence and a directive to suspend the originator or third party sender.", "citation": "Nacha, ACH Network Rules: Reversals and Enforcement, rule effective 2021-06-30 and enforcement rule effective 2021-01-01, enforcement rule effective 2021-01-01, read 2026-09-17", "rests_on": "rule" }, { "label": "Scale, for context", "value": "Nacha reports 35.2 billion ACH payments in 2025, worth $93 trillion, averaging 141 million a day, of which 1.4 billion were Same Day ACH worth $3.9 trillion.", "citation": "Nacha, ACH Network Volume and Value Statistics, figures for full year 2025, read 2026-09-17", "rests_on": "guidance" } ], "exceptions": [ "The criteria for being a Participating Depository Financial Institution under the Nacha rules, and the membership arrangements behind them, are in the paid rulebook and are not stated here.", "Government entities take part on different terms: Treasury payment instructions are excluded from the definition of item in the circular and run under Treasury's own regulations (Operating Circular 4, paragraph 2.1(o); 31 CFR parts 210 and 370).", "A consumer or business is never a participant in the rail itself; it is a customer of a participant, which is why every obligation in this record runs through a bank.", "This record describes participation in FedACH. Access criteria for The Clearing House's EPN were not read [Unverified].", "The count of participating institutions is not stated in any source read here; the volume figures are Nacha's own reporting." ], "applies_to": "participation in the US ACH Network, with the access conditions stated for the Federal Reserve Banks as ACH operator", "caveat": "A non bank cannot join this rail. Fintechs and processors appear inside it as Originators, Third-Party Senders or agents of a bank, which is why their obligations show up through a bank's agreements and why a sponsor bank can cut off access. Any plan that assumes direct access should be re-checked against the sponsor arrangement.", "related": [ "us-ach:settlement", "us-ach:liability", "us-ach:messages", "us-ach:finality", "us-ach:limits", "us-ach:decision-points" ], "basis": { "sources": "Two independent organisations across the roles and access lines. Nacha public pages (nacha.org), read 2026-09-17: How ACH Payments Work for the five roles and the two operators; Third-Party Sender Roles and Responsibilities, rule effective 2022-09-30; the two Fraud Monitoring rule pages effective 2026-03-20 and 2026-06-19; Reversals and Enforcement for the enforcement rule effective 2021-01-01; ACH Network Volume and Value Statistics for the 2025 figures; the press release dated 2022-03-18 quoting both operators. Federal Reserve Banks Operating Circular 4, effective 2026-01-05, read in full for this record: paragraphs 2.1(g), 2.1(o), 3.1, 3.5, 9.1 and 12.1. The Nacha Operating Rules, which set participation criteria, are paid and were not opened.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "The role structure is long-standing. Dated changes in this facet: Third-Party Sender roles from 2022-09-30, fraud monitoring duties from 2026-03-20 and 2026-06-19. The volume figures are for full year 2025 and will age; Nacha publishes quarterly.", "source_edition": "Nacha public pages read 2026-09-17; Federal Reserve Banks Operating Circular 4, effective 2026-01-05", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "primary_not_public": true, "corroboration": [ { "source_url": "https://www.nacha.org/content/how-ach-payments-work", "source_class": "public_primary", "source_title": "Nacha, How ACH Payments Work", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the five roles (Originator, ODFI, ACH Operator, RDFI, Receiver) carrying both credits and debits, and that there are two ACH Operators, the Federal Reserve and The Clearing House." }, { "source_url": "https://www.frbservices.org/binaries/content/assets/crsocms/resources/rules-regulations/010526-operating-circular-4.pdf", "source_class": "authoritative_primary", "source_title": "Federal Reserve Banks Operating Circular No. 4, Automated Clearing House Items, effective January 5, 2026", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the four categories qualifying as a bank for FedACH (2.1(g)), the settlement account entry condition on both sides (3.1), that a correspondent's account can be used without becoming a party (9.1), agent designation with the sending bank retaining responsibility (3.5), and the receiving bank's agreement to follow the ACH rules by maintaining a settlement account (12.1). Independent of the Nacha source: different organisation, different host, own wording." } ] }, "rail_name": "US ACH", "governing_authority": "Nacha", "snapshot": "2026-09-16", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "not_public", "label": "the operator's own text", "needs": "what the operator's own text says, which Orca has not read", "detail": "Nacha's own text is not the source for this rail fact: it is not public, or not under terms Orca can use. It rests on 2 named public sources, so a term set by agreement rather than by a published rule is not Orca's to state.", "from": "currency.primary_not_public" } ] }, { "uid": "us-ach:recall", "id": "recall", "rail": "us-ach", "kind": "rail-fact", "facet": "recall", "name": "Can a sent payment be recalled, and who decides?", "statement": "There is no cancel button once a file has gone to the operator. Two paths exist instead. A reversal is a new entry in the opposite direction that the originator may send for a narrow list of errors, within 5 banking days of the original and within 24 hours of spotting the mistake. A request for return asks the receiving bank to send the money back, and it may decline. In both paths the receiving bank, not the sender, decides whether money actually moves.", "details": [ { "label": "No recall by the sender once the file has gone", "value": "A sending bank or an earlier party cannot amend or revoke an entry after sending it to a Reserve Bank, other than by whatever the Nacha rules themselves allow, which is the reversal path and not a cancellation.", "citation": "Federal Reserve Banks Operating Circular No. 4, Automated Clearing House Items, effective January 5, 2026, paragraph 13.1; Nacha, ACH Network Rules: Reversals and Enforcement, rule effective 2021-06-30 and enforcement rule effective 2021-01-01, reversals rule effective 2021-06-30", "rests_on": "rule" }, { "label": "What a reversal may be used for", "value": "The permitted errors are narrow: a duplicate, the wrong amount, the wrong account, and since the 2021 rule also the wrong date, meaning a debit dated earlier or a credit dated later than the originator intended. Dissatisfaction, a cancelled order or a failure to fund a credit file are not reasons.", "citation": "Nacha, ACH Network Rules: Reversals and Enforcement, rule effective 2021-06-30 and enforcement rule effective 2021-01-01, reversals rule effective 2021-06-30, read 2026-09-17; Popular Bank, ACH Rules Awareness Guide for Businesses, revised 2025-04-02, reversals section", "rests_on": "rule" }, { "label": "The two clocks on a reversal", "value": "The reversing entry must go within 5 banking days of the original entry and within 24 hours of the originator discovering the error, and it must be for the full amount.", "citation": "Popular Bank, ACH Rules Awareness Guide for Businesses, revised 2025-04-02, reversals section", "rests_on": "rule" }, { "label": "How a reversal must be formatted", "value": "The company identification, SEC code and amount have to match the original entry exactly, other fields may only change as far as processing requires, and the company entry description field carries the word REVERSAL.", "citation": "Nacha, ACH Network Rules: Reversals and Enforcement, rule effective 2021-06-30 and enforcement rule effective 2021-01-01, reversals rule effective 2021-06-30; Popular Bank, ACH Rules Awareness Guide for Businesses, revised 2025-04-02", "rests_on": "rule" }, { "label": "The receiving side is not obliged to fund it", "value": "The receiving bank need not post a reversing debit that would overdraw the account or that hits a closed account. The receiver must be told a reversing debit hit the account but is not asked to authorise it.", "citation": "Popular Bank, ACH Rules Awareness Guide for Businesses, revised 2025-04-02, reversals section", "rests_on": "rule" }, { "label": "A wrongly used reversal can be sent back", "value": "Since 2021 a receiving bank may return an improper reversal: R11 on a consumer account within the 60 day window when the consumer claims it, and R17 on a non consumer account within 2 days, including where the bank spots it without any customer contact.", "citation": "Nacha, ACH Network Rules: Reversals and Enforcement, rule effective 2021-06-30 and enforcement rule effective 2021-01-01, reversals rule effective 2021-06-30", "rests_on": "rule" }, { "label": "Reversing a whole file", "value": "A duplicate file, or one in which substantially every entry was wrong, may be reversed as a file. It must reach the receiving bank within 5 banking days of the settlement date of the entries and within 24 hours of discovery, the batch header carries REVERSAL, and an erroneous file must be accompanied by a correcting file.", "citation": "Popular Bank, ACH Rules Awareness Guide for Businesses, revised 2025-04-02, file reversal section", "rests_on": "rule" }, { "label": "Asking rather than reversing", "value": "Where no reversal reason fits, the originating bank can ask the receiving bank to return the entry, which is what R06 records. The receiving bank may refuse; if it agrees, the originating bank indemnifies it under the rules.", "citation": "Popular Bank, ACH Rules Awareness Guide for Businesses, revised 2025-04-02, return reason code table for R06, which names Article Two, Subsection 2.12.3", "rests_on": "rule" }, { "label": "The operator has its own cancellation power", "value": "A Reserve Bank that finds it sent a duplicate or erroneous batch may cancel by originating a reversing batch under the ACH rules and tells the sending bank it did. Nothing in the circular waives a Reserve Bank's right to recover under the law of mistake and restitution.", "citation": "Federal Reserve Banks Operating Circular No. 4, Automated Clearing House Items, effective January 5, 2026, paragraph 13.2", "rests_on": "rule" }, { "label": "Before the file leaves, it is a different question", "value": "A payment still inside a bank's or processor's queue can usually be stopped, because nothing has been sent. Stripe, for example, treats a pending ACH debit as cancellable and treats a refund as a separate credit rather than a reversal.", "citation": "Stripe documentation, ACH Direct Debit payments, read 2026-09-17, cancel and refund sections", "rests_on": "practice" } ], "exceptions": [ "A reversal is not available for a credit the originator simply cannot fund. Nacha's 2021 rule page names failure to fund an ACH credit file as an improper use the rule was written to stop.", "One further reversal reason exists for payroll: a PPD credit for wages where the employee was already given a cheque for the same amount before the credit went out [Unverified: read in a search summary of bank originator guides, not in a source read in full for this record].", "The reversal clocks are stated by Popular Bank's ACH Rules Awareness Guide for Businesses rather than by Nacha's public pages; the governing text is the paid rulebook (Nacha Operating Rules, not opened).", "A Reserve Bank's own reversing batch under paragraph 13.2 is a correction of the operator's mistake, not a route available to a sending bank.", "Recall says nothing about who ends up bearing the loss where the money is gone; that is a question of liability, and for a consumer account Regulation E runs separately." ], "applies_to": "ACH entries already sent to an ACH operator by a US originating bank, on consumer and non consumer accounts", "caveat": "Treat a reversal as a request with a deadline, not as a recall. It can be refused for lack of funds, returned as improper, or simply arrive after the money has left the account. An agent that has sent a wrong ACH credit should assume recovery depends on the receiver's goodwill and act inside 24 hours.", "related": [ "us-ach:finality", "us-ach:return", "us-ach:settlement", "us-ach:refund", "us-ach:messages", "us-ach:decision-points" ], "basis": { "sources": "Two independent organisations for each detail, because the reversal rules are in the paid Nacha Operating Rules. Nacha public rule page Reversals and Enforcement (nacha.org), rule effective 2021-06-30, read 2026-09-17, for the permitted reasons including the wrong date addition, the formatting requirements and the R11 and R17 return routes for an improper reversal. Popular Bank ACH Rules Awareness Guide for Businesses, revised 2025-04-02 (secondary), in that bank's own wording, for the 5 banking day and 24 hour clocks, the full amount requirement, the receiving bank's freedom not to post, file reversals, and the R06 request path naming Article Two, Subsection 2.12.3. Federal Reserve Banks Operating Circular 4, effective 2026-01-05, paragraphs 13.1 and 13.2. Stripe documentation (secondary) for pre submission cancellation and refund practice. The rulebook itself was not opened.", "confidence": "medium" }, "currency": { "effective_since": "2021-06-30", "effective_to": null, "effective_note": "The reversal rule in its current shape, including the wrong date reason and the right to return an improper reversal, took effect 2021-06-30. The 5 banking day and 24 hour clocks predate that change [Unverified: no source read here dates them].", "source_edition": "Nacha public rule pages read 2026-09-17; Federal Reserve Banks Operating Circular 4, effective 2026-01-05; Popular Bank guide revised 2025-04-02", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "primary_not_public": true, "corroboration": [ { "source_url": "https://www.nacha.org/rules/reversals-and-enforcement", "source_class": "public_primary", "source_title": "Nacha, ACH Network Rules: Reversals and Enforcement, rule effective 2021-06-30 and enforcement rule effective 2021-01-01", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the narrow permitted reversal reasons (duplicate, wrong amount, wrong account, wrong date since 2021), that failure to fund a credit file is an improper use, and the R11 (consumer, 60 day)/R17 (non-consumer, 2 day, self-identified) return routes for an improper reversal." }, { "source_url": "https://documents.popular.com/pdfs/PCB/ACH_Rules_Awareness_Guide.pdf", "source_class": "secondary", "source_title": "Popular Bank, ACH Rules Awareness Guide for Businesses, revised 2025-04-02", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms, in the bank's own wording, the two reversal clocks (within 5 banking days of the original entry and within 24 hours of discovering the error, full amount only) and the file reversal mechanics. Independent of the Nacha source: different organisation (a bank, not the rule writer), different host, own wording, dated to its own 2025-04-02 revision." } ] }, "rail_name": "US ACH", "governing_authority": "Nacha", "snapshot": "2026-09-16", "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "not_public", "label": "the operator's own text", "needs": "what the operator's own text says, which Orca has not read", "detail": "Nacha's own text is not the source for this rail fact: it is not public, or not under terms Orca can use. It rests on 2 named public sources, so a term set by agreement rather than by a published rule is not Orca's to state.", "from": "currency.primary_not_public" } ] }, { "uid": "us-ach:refund", "id": "refund", "rail": "us-ach", "kind": "rail-fact", "facet": "refund", "name": "Can the payer get the money back, and on what grounds?", "statement": "A consumer whose account was debited without authorisation has a real right to be made whole, and it comes from law rather than from the ACH rules: report the error within 60 days of the statement and the bank must investigate, provisionally credit inside 10 business days in most cases, and correct. The ACH rules give the receiving bank the matching tool, a return inside 60 days on a signed statement, and a warranty claim against the originating bank afterwards. A business gets none of this. For a company the money comes back only by agreement or by contract.", "details": [ { "label": "The consumer's statutory route", "value": "Notice of an unauthorised or incorrect electronic transfer, given within 60 days of the statement that first showed it, starts the bank's duty to investigate. The bank has 10 business days to decide, must report within 3 business days of finishing, and must fix an error within 1 business day of finding it.", "citation": "12 CFR Part 1005 (Regulation E), eCFR current text, 1005.11(b)(1)(i) and 1005.11(c)(1), read 2026-09-17", "rests_on": "law" }, { "label": "Provisional credit while the bank investigates", "value": "A bank that cannot finish in 10 business days may take up to 45 days, but only if it provisionally credits the disputed amount within those 10 business days, tells the consumer within 2 business days of doing so and leaves the funds usable. It may hold back $50 where it has a reasonable basis to believe the transfer was unauthorised and it gave the required disclosures.", "citation": "12 CFR Part 1005 (Regulation E), eCFR current text, 1005.11(c)(2), read 2026-09-17", "rests_on": "law" }, { "label": "Longer clocks for new accounts and some transfers", "value": "The 10 business days becomes 20 where the transfer happened within 30 days of the first deposit, and the 45 days becomes 90 for a transfer not initiated within a state, a point of sale debit card transaction, or one in that first 30 day period.", "citation": "12 CFR Part 1005 (Regulation E), eCFR current text, 1005.11(c)(3), read 2026-09-17", "rests_on": "law" }, { "label": "The stop payment right", "value": "A consumer can call or write to the bank to stop a preauthorised debit, and the notice counts if it arrives by the third business day before the debit is due. The bank may ask for the oral order to be put in writing inside 14 days, and the order dies if that never comes.", "citation": "12 CFR Part 1005 (Regulation E), eCFR current text, 1005.10(c), read 2026-09-17", "rests_on": "law" }, { "label": "The ACH tool that carries the money back", "value": "Inside 60 calendar days the receiving bank recovers by returning the entry, after taking a signed written statement of unauthorised debit from the account holder. That is the mechanism behind most consumer recredits on this rail.", "citation": "Popular Bank, ACH Rules Awareness Guide for Businesses, revised 2025-04-02, unauthorised debit section; Nacha, ACH Network Rules: Reversals and Enforcement, rule effective 2021-06-30 and enforcement rule effective 2021-01-01, reversals rule effective 2021-06-30, which states the 60 day consumer claim route", "rests_on": "rule" }, { "label": "The warranty that carries loss back to the originating side", "value": "The originating bank warrants that an entry was authorised, and the receiving bank can make a claim on that warranty when it has recredited its customer. Nacha limits the claim to one year from settlement for a non consumer account, and for a consumer account to the first 95 days from settlement of the first unauthorised entry or otherwise two years.", "citation": "Nacha, Limitation on Warranty Claims, rule effective 2021-06-30, read 2026-09-17", "rests_on": "rule" }, { "label": "Why 95 days and not 60", "value": "Nacha explains the 95 day floor as covering the Regulation E arithmetic: up to a statement cycle before the consumer sees the entry, plus the 60 days the consumer then has to report it. The rulebook window is built around the statute, not the other way round.", "citation": "Nacha, Limitation on Warranty Claims, rule effective 2021-06-30; 12 CFR Part 1005 (Regulation E), eCFR current text, 1005.11(b)(1)(i), read 2026-09-17", "rests_on": "rule" }, { "label": "A business has no equivalent right", "value": "Nothing in Regulation E reaches an account held for business purposes, and the corporate return reasons run on the ordinary 2 banking day window. A company that paid the wrong party relies on the reversal path, a request for return, or its contract.", "citation": "12 CFR Part 1005 (Regulation E), eCFR current text, 1005.2(b)(1), which limits account to one established primarily for personal, family or household purposes, read 2026-09-17; Popular Bank, ACH Rules Awareness Guide for Businesses, revised 2025-04-02, which states that the consumer or corporate entry code determines which return rules apply", "rests_on": "law" }, { "label": "A merchant refund is a new payment", "value": "Where a business refunds a customer it originates a fresh credit rather than reversing the original debit. Stripe's documentation describes an ACH refund as a separate credit that shows on the statement as a credit referencing the original descriptor, available for up to 180 days.", "citation": "Stripe documentation, ACH Direct Debit payments, refunds section, read 2026-09-17", "rests_on": "practice" }, { "label": "Federal payments have their own recovery route", "value": "Money that a federal agency should not have paid is pursued through Treasury's reclamation process rather than an ordinary return, and Treasury publishes a separate route for obtaining a refund where a payment was returned in error.", "citation": "Green Book, A Guide to Federal Government ACH Payments, edition published 2025-03, Returns and Reclamations chapters", "rests_on": "guidance" } ], "exceptions": [ "Regulation E error resolution is about errors, not regret. A transfer the consumer authorised and now dislikes is not an error, and a scam in which the consumer was tricked into authorising the payment sits outside the definition (12 CFR 1005.11(a)).", "A bank that has fully met the error resolution requirements owes nothing further if the consumer reasserts the same error (12 CFR 1005.11(e)).", "A provisional credit can be taken back. The bank must then tell the consumer and honour items for 5 business days afterwards (12 CFR 1005.11(d)(2)).", "The 60 day return and the 60 day Regulation E notice are different clocks with different starting points: settlement of the entry for the return, transmittal of the statement for the notice.", "Small institutions below the asset threshold are exempt from parts of the preauthorized transfer rules, so the stop payment path is not uniform (12 CFR 1005.3(c)(7))." ], "applies_to": "ACH debits to US accounts, with the Regulation E lines applying only to accounts held by a natural person primarily for personal, family or household purposes", "caveat": "Two systems run in parallel and they do not line up. The consumer's right is against their own bank under Regulation E; the bank's recovery is against the originating bank under the Nacha rules. A consumer can therefore be made whole after the ACH return window has closed, with the loss settled later between the banks, which is exactly why the originating side should not treat day 61 as safe.", "related": [ "us-ach:return", "us-ach:recall", "us-ach:finality", "us-ach:consumer-law", "us-ach:liability", "us-ach:decision-points" ], "basis": { "sources": "Regulation E, 12 CFR 1005.2(b), 1005.3(c)(7), 1005.10(c), 1005.11(a) to (e), read on eCFR 2026-09-17, for every law line. Nacha public rule pages (nacha.org), read 2026-09-17: Limitation on Warranty Claims, rule effective 2021-06-30, for the one year, 95 day and two year limits and for the reason behind the 95 days; Reversals and Enforcement, rule effective 2021-06-30, for the 60 day consumer claim route. Popular Bank ACH Rules Awareness Guide for Businesses, revised 2025-04-02 (secondary), in that bank's own wording, for the written statement practice and the consumer versus corporate split. Stripe documentation (secondary) for refund practice. US Treasury Green Book, edition published 2025-03, for federal payment recovery. The Nacha Operating Rules are paid and were not opened.", "confidence": "medium" }, "currency": { "effective_since": "2021-06-30", "effective_to": null, "effective_note": "The warranty claim limits took effect 2021-06-30. The Regulation E provisions cited are the current eCFR text as at 2026-09-17; section 1005.10 carries amendments through 89 FR 106836 dated 2024-12-30, and the watch log in Orca's US ACH rail brief (docs/rails/us-ach.md) records a substantive amendment to 1005.10 dated 2025-10-01 whose content the drafter did not determine [Unverified].", "source_edition": "12 CFR 1005 as on eCFR 2026-09-17; Nacha public rule pages read 2026-09-17; Popular Bank guide revised 2025-04-02; Green Book edition published 2025-03", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "primary_not_public": true, "corroboration": [ { "source_url": "https://www.ecfr.gov/current/title-12/part-1005", "source_class": "authoritative_primary", "source_title": "12 CFR Part 1005 (Regulation E), eCFR current text", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the statutory error resolution route: 60 day notice from statement transmittal, 10 business day investigation with 3/1 business day reporting and correction duties (1005.11(b),(c)(1)), provisional credit within 10 business days extending to 45 days with the $50 holdback (1005.11(c)(2)), the 20/90 day extensions for new accounts and certain transfers (1005.11(c)(3)), the stop payment right (1005.10(c)), and that Regulation E reaches only accounts held primarily for personal, family or household purposes (1005.2(b)(1))." }, { "source_url": "https://www.nacha.org/rules/limitation-warranty-claims", "source_class": "public_primary", "source_title": "Nacha, Limitation on Warranty Claims, rule effective 2021-06-30", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the post-return-window warranty claim path and its limits (one year non-consumer; 95 days or two years consumer), and the 95 day figure's stated basis in the Regulation E statement-cycle-plus-60-day arithmetic. Independent of the eCFR source: different organisation (Nacha, not the CFPB), different host, own wording." } ] }, "rail_name": "US ACH", "governing_authority": "Nacha", "snapshot": "2026-09-16", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "not_public", "label": "the operator's own text", "needs": "what the operator's own text says, which Orca has not read", "detail": "Nacha's own text is not the source for this rail fact: it is not public, or not under terms Orca can use. It rests on 2 named public sources, so a term set by agreement rather than by a published rule is not Orca's to state.", "from": "currency.primary_not_public" } ] }, { "uid": "us-ach:return", "id": "return", "rail": "us-ach", "kind": "rail-fact", "facet": "return", "name": "How does an entry come back, and by when?", "statement": "The receiving bank sends the entry back as a return entry carrying a reason code, and it settles in the opposite direction like any other ACH traffic. Two windows matter: about 2 banking days for the ordinary case, and 60 calendar days for an unauthorised debit to a consumer account, which needs a signed written statement from the account holder. A return can itself be dishonoured, and a dishonour contested, so the return path is not one step but up to three.", "details": [ { "label": "The mechanism", "value": "A receiving bank returns a debit or credit to any Reserve Bank under the applicable ACH rules and by the schedule's deadline. Miss the deadline on a debit and the receiving bank is accountable for the amount.", "citation": "Federal Reserve Banks Operating Circular No. 4, Automated Clearing House Items, effective January 5, 2026, paragraph 14.1", "rests_on": "rule" }, { "label": "How a return settles", "value": "The Reserve Banks process the return like a forward item and settle it on its settlement date, debiting or crediting each side at the schedule's time. A same day item may be returned on the day it was received.", "citation": "Federal Reserve Banks Operating Circular No. 4, Automated Clearing House Items, effective January 5, 2026, paragraph 14.2; FedACH Processing Schedule, effective September 12, 2022, Electronic Return Items table", "rests_on": "rule" }, { "label": "Return window: 2 banking days", "value": "For the return reasons linked to it, the RDFI has 2 banking days after the settlement date of the original entry to return it.", "citation": "ACH Return Reason Codes (First Hawaiian Bank); CBS Bank, Quick Reference Guide: ACH Return Reason Codes and Time Frames, March 2025; ACH Return Codes (R01-R85), Modern Treasury; ACH Return Reason Codes (BMO Treasury and Payment Solutions, May 2025); Nacha, ACH Network Rules: Reversals and Enforcement, rule effective 2021-06-30 and enforcement rule effective 2021-01-01, reversals rule effective 2021-06-30, read 2026-09-17, the R17 2 day window for returning an improper reversal to a non consumer account; Popular Bank, ACH Rules Awareness Guide for Businesses, revised 2025-04-02, return reason code table, which gives the 2 banking day window as the general rule", "rests_on": "rule" }, { "label": "Extended return window: 60 calendar days", "value": "For the return reasons linked to it, the RDFI may return the entry up to 60 calendar days after the settlement date of the original entry. The written statement some of those reasons need is a separate Rule.", "citation": "ACH Return Reason Codes (First Hawaiian Bank); CBS Bank, Quick Reference Guide: ACH Return Reason Codes and Time Frames, March 2025; Differentiating Unauthorized Return Reasons (Nacha); ACH Return Reason Codes (BMO Treasury and Payment Solutions, May 2025); Nacha, ACH Network Rules: Reversals and Enforcement, rule effective 2021-06-30 and enforcement rule effective 2021-01-01, reversals rule effective 2021-06-30, the R11 60 day window as the consumer claim route; Popular Bank, ACH Rules Awareness Guide for Businesses, revised 2025-04-02, return reason code table entries for R05 and R07 and their neighbours", "rests_on": "rule" }, { "label": "What the consumer has to sign", "value": "Where the account holder disputes a debit as unauthorised, the receiving bank takes a signed written statement of unauthorised debit before returning, and the originator can ask its own bank for a copy.", "citation": "Popular Bank, ACH Rules Awareness Guide for Businesses, revised 2025-04-02, section on unauthorised debits", "rests_on": "rule" }, { "label": "Returns can be sent back again", "value": "A return is not the end. A return that arrives late, or that carries data not matching the original entry, can be dishonoured by the originating side. Treasury dishonours a return of a federal payment where any of four fields, the original trace number, effective entry date, amount and individual identification number, differ from the original.", "citation": "Green Book, A Guide to Federal Government ACH Payments, edition published 2025-03, Returns chapter section D; Popular Bank, ACH Rules Awareness Guide for Businesses, revised 2025-04-02, note that an untimely return may be dishonoured without permission", "rests_on": "rule" }, { "label": "Disputing a return through the operator", "value": "A sending bank may dispute the propriety of a return once. The Reserve Banks then settle the disputed return provisionally, subject to getting funds from the receiving bank, and reverse that provisional settlement if the receiving bank disputes the claim in turn.", "citation": "Federal Reserve Banks Operating Circular No. 4, Automated Clearing House Items, effective January 5, 2026, paragraph 15.1", "rests_on": "rule" }, { "label": "Re-presenting a failed debit", "value": "A debit returned for insufficient or uncollected funds may be sent again up to twice, giving three attempts in all. A stop payment return may only be re-presented with the payee's agreement, and re-presenting after any other return reason breaks the rules.", "citation": "Popular Bank, ACH Rules Awareness Guide for Businesses, revised 2025-04-02, re-initiation section; Stripe documentation, ACH Direct Debit payments, read 2026-09-17, which caps its own automatic retries at 2 within 40 days", "rests_on": "rule" }, { "label": "An adjustment path exists alongside the return path", "value": "Where a receiving bank sends an adjustment entry for an unauthorised debit rather than an ordinary return, it indemnifies the Reserve Banks against the sending bank failing to pay the amount, whether or not the original debit came through a Reserve Bank.", "citation": "Federal Reserve Banks Operating Circular No. 4, Automated Clearing House Items, effective January 5, 2026, paragraph 14.4", "rests_on": "rule" }, { "label": "A new return code with its own window is dated", "value": "From 2028-03-17 a receiving bank returning an entry to meet its sanctions obligations uses R90, and Nacha is adding a distinct time frame for that case to the section of the rules that governs an RDFI's right to return. R16 loses its OFAC meaning on the same date and goes back to account frozen.", "citation": "New Return Reason Code for Sanctions Compliance Obligations, effective 2028-03-17, which names Article Three, Section 3.8 and Appendix Four, Part 4.2", "rests_on": "rule" } ], "exceptions": [ "The second and third steps each have their own record and window. The ODFI may dishonour a return with a code from R61 to R70 within 5 banking days of the return's settlement date (us-ach:exc.dishonored-return, us-ach:rule.dishonor-window-5-banking-days), and the RDFI may then contest or correct the dishonour with a code from R71 to R77 within 2 banking days of the dishonour's settlement date (us-ach:exc.contested-dishonored-return, us-ach:rule.contest-window-2-banking-days). Both windows rest on public bank guides, not on the Nacha Operating Rules.", "Paper returns fall outside the FedACH Processing Schedule and run on terms agreed with the Reserve Bank case by case (Operating Circular 4, paragraph 14.5).", "Returns of federal payments carry Treasury's own requirements on top of the ACH rules, including the four matching fields and the reclamation process that follows a death or ineligibility (Green Book, Returns chapter, edition published 2025-03).", "A consumer's right to a recredit under Regulation E is not a return and does not end when the 60 day return window closes.", "The precise list of reason codes and their individual windows lives in this rail's reason code records, not here; the codes counted toward the 0.5 percent unauthorised entry return rate threshold are R05, R07, R10, R11, R29 and R51." ], "applies_to": "return entries sent by a receiving bank on ACH debits and credits cleared through the Federal Reserve Banks, for US consumer and non consumer accounts", "caveat": "The 2 banking day figure is the shape of the rule, not a guarantee: it is stated by Popular Bank's ACH Rules Awareness Guide for Businesses and implied by Nacha's public pages, and the governing text is the paid rulebook. Anyone relying on a specific window for a specific reason code should read that code's record rather than this one, and should treat the 60 day consumer window as the real exposure on any debit from a consumer account.", "related": [ "us-ach:finality", "us-ach:settlement", "us-ach:hours", "us-ach:recall", "us-ach:refund", "us-ach:liability", "us-ach:messages", "us-ach:decision-points", "us-ach:consumer-law" ], "basis": { "sources": "Two independent organisations for each detail, because the return windows live in the paid Nacha Operating Rules. Nacha public pages (nacha.org), read 2026-09-17: Reversals and Enforcement, rule effective 2021-06-30, which states the R11 60 day consumer and R17 2 day non consumer time frames; New Return Reason Code for Sanctions Compliance Obligations, effective 2028-03-17, naming Article Three, Section 3.8 and Appendix Four, Part 4.2. Federal Reserve Banks (frbservices.org): Operating Circular 4, effective 2026-01-05, paragraphs 14.1 to 14.5 and 15.1, and the FedACH Processing Schedule effective 2022-09-12. US Treasury Bureau of the Fiscal Service (tfx.treasury.gov): Green Book, Returns chapter, edition published 2025-03, for dishonoured returns and the four matching fields. Popular Bank ACH Rules Awareness Guide for Businesses, revised 2025-04-02 (secondary), for the windows, the written statement and the re-initiation limit, in that bank's own wording. Stripe documentation (secondary) for retry practice. CBS Bank ACH Return Reason Codes quick reference, March 2025 (cbsbank.com, secondary), read 2026-09-23, for the dishonour and contest windows and code ranges named in the exceptions. The rulebook itself was not opened.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "The 2 banking day and 60 calendar day windows are long-standing; no source read here dates their introduction, so that is [Unverified]. Two dated changes are ahead: R90 and the sanctions return time frame on 2028-03-17, with R16 narrowing to account frozen on the same date.", "source_edition": "Nacha public rule pages read 2026-09-17; Federal Reserve Banks Operating Circular 4, effective 2026-01-05; Green Book edition published 2025-03; Popular Bank guide revised 2025-04-02", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "primary_not_public": true, "corroboration": [ { "source_url": "https://www.nacha.org/rules/reversals-and-enforcement", "source_class": "public_primary", "source_title": "Nacha, ACH Network Rules: Reversals and Enforcement, rule effective 2021-06-30 and enforcement rule effective 2021-01-01", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the R11 60 calendar day consumer claim window and R17 2 banking day non-consumer window for returning an improper reversal, both measured from the settlement date of the improper reversal, not from posting or a statement." }, { "source_url": "https://www.frbservices.org/binaries/content/assets/crsocms/resources/rules-regulations/010526-operating-circular-4.pdf", "source_class": "authoritative_primary", "source_title": "Federal Reserve Banks Operating Circular No. 4, Automated Clearing House Items, effective January 5, 2026", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms the return mechanism and accountability for a missed deadline (14.1), that a return settles like a forward item including same day returns (14.2), the disputed-return provisional settlement process (15.1), and the unauthorized-debit adjustment entry path with its indemnity (14.4). Independent of the Nacha source: different organisation, different host, own wording." }, { "source_url": "https://www.cbsbank.com/wp-content/uploads/2025/03/ACH-Return-Reason-Codes.pdf", "source_class": "secondary", "source_title": "CBS Bank, Quick Reference Guide: ACH Return Reason Codes and Time Frames, March 2025", "checked_on": "2026-09-23", "checked_by": "validator-opus-2026-09-23", "notes": "Confirms the ordinary 2 banking day return deadline measured from the settlement date of the original entry, and that a return can itself be dishonoured and the dishonour contested: the ODFI sends a dishonoured return with a code from R61 to R70 within five banking days after the returned entry settles, and the RDFI sends a contested or corrected dishonoured return with a code from R71 to R77 within two banking days after the dishonoured return settles." } ] }, "rail_name": "US ACH", "governing_authority": "Nacha", "snapshot": "2026-09-16", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "not_public", "label": "the operator's own text", "needs": "what the operator's own text says, which Orca has not read", "detail": "Nacha's own text is not the source for this rail fact: it is not public, or not under terms Orca can use. It rests on 3 named public sources, so a term set by agreement rather than by a published rule is not Orca's to state.", "from": "currency.primary_not_public" } ] }, { "uid": "us-ach:settlement", "id": "settlement", "rail": "us-ach", "kind": "rail-fact", "facet": "settlement", "name": "How and when does money actually settle between the banks?", "statement": "ACH is deferred net settlement across accounts at the Federal Reserve. Entries are collected into files, an operator sorts them, and at fixed clock times on the settlement date the Reserve Bank debits one bank's settlement account and credits the other's. Nothing settles per payment and nothing settles on receipt. Which clock time applies depends on the window the file made and on whether the entry is same day, next day or two day.", "details": [ { "label": "What settlement is", "value": "At the settlement time and date in the FedACH Processing Schedule, the Reserve Bank holding the sending bank's settlement account debits or credits it for the amount of the entry, and the Reserve Bank holding the receiving bank's account does the matching entry on the other side.", "citation": "Federal Reserve Banks Operating Circular No. 4, Automated Clearing House Items, effective January 5, 2026, paragraph 10.2", "rests_on": "rule" }, { "label": "Whose obligation it is", "value": "A bank's settlement obligation runs to its own Administrative Reserve Bank even where the designated account sits on another Reserve Bank's books, and settling with the account holding Reserve Bank counts as settling with the Administrative Reserve Bank.", "citation": "Federal Reserve Banks Operating Circular No. 4, Automated Clearing House Items, effective January 5, 2026, paragraph 10.1", "rests_on": "rule" }, { "label": "Same day settlement clock times", "value": "Same day eligible forward items settle at 13:00, 17:00 or 18:00 Eastern on the day of receipt, according to which of the three transmission deadlines the file met (10:30, 14:45 or 16:45 Eastern).", "citation": "FedACH Processing Schedule, effective September 12, 2022, Same Day Eligible Forward Items table, read 2026-09-17", "rests_on": "guidance" }, { "label": "Future dated settlement clock time", "value": "Everything not eligible for same day settles in a single morning event, at 08:30 Eastern on the applicable future banking day, whichever of the six transmission windows the file arrived in.", "citation": "FedACH Processing Schedule, effective September 12, 2022, Future Dated Forward Items table and footnote 4, read 2026-09-17", "rests_on": "guidance" }, { "label": "Which day is the settlement day", "value": "An entry carrying an effective date one banking day out settles the next banking day after receipt, and one carrying two banking days settles on the second banking day after receipt. An entry whose effective date is the day of receipt or earlier settles the same day if it reached the Reserve Bank before the last same day cutoff, and otherwise moves to the next banking day.", "citation": "Federal Reserve Banks Operating Circular No. 4, Automated Clearing House Items, effective January 5, 2026, Appendix B, paragraphs 2.1 and 3.1", "rests_on": "rule" }, { "label": "Effective date windows are bounded", "value": "Credit entries may carry an effective date one or two banking days ahead; debit entries only one. An entry with an effective date beyond the window is sent back to the sender rather than settled late.", "citation": "Federal Reserve Banks Operating Circular No. 4, Automated Clearing House Items, effective January 5, 2026, Appendix B, paragraph 2.1 table", "rests_on": "rule" }, { "label": "The settlement asset and its hours", "value": "Settlement happens in central bank money, so it can only happen while the Federal Reserve's settlement service is open. Nacha describes the network as settling four times each business day, with the Federal Reserve settlement system closed on weekends and federal holidays and between 18:30 and 07:30 Eastern.", "citation": "Nacha, The ABCs of ACH, read 2026-09-17; FedACH Processing Schedule, effective September 12, 2022, footnote 3 pointing settlement to the Federal Reserve Policy on Payment System Risk", "rests_on": "guidance" }, { "label": "Credit given for a debit is not the same as funds collected", "value": "Credit for a debit entry is available on the settlement date but the Reserve Bank can withhold its use if it doubts the sending bank's account will cover a chargeback or return, and can reverse a whole settlement window's debit entries the following morning if funds did not arrive.", "citation": "Federal Reserve Banks Operating Circular No. 4, Automated Clearing House Items, effective January 5, 2026, paragraphs 11.1(a) and 11.1(b)", "rests_on": "rule" }, { "label": "Prefunding, where a Reserve Bank requires it", "value": "A sending bank's Administrative Reserve Bank may require credit originations to be prefunded where it has decided to monitor that account in real time. Originations that should have been prefunded and were not can be rejected, and where prefunding applies the Reserve Bank steps into the sending bank's settlement obligation.", "citation": "Federal Reserve Banks Operating Circular No. 4, Automated Clearing House Items, effective January 5, 2026, paragraph 5.3 with Appendix C", "rests_on": "rule" }, { "label": "How a return settles", "value": "The Reserve Banks process the return like a forward item and settle it on its settlement date, debiting or crediting each side at the schedule's time. A same day item may be returned on the day it was received.", "citation": "Federal Reserve Banks Operating Circular No. 4, Automated Clearing House Items, effective January 5, 2026, paragraph 14.2; FedACH Processing Schedule, effective September 12, 2022, Electronic Return Items table", "rests_on": "rule" } ], "exceptions": [ "This record describes settlement through the Federal Reserve Banks. The Clearing House operates EPN, the other ACH operator; its settlement arrangements were not read and are not stated here [Unverified].", "The 08:00 pm Eastern transmission window runs Sunday through Thursday only, not Friday, so the file that would settle the next morning is not available every night (FedACH Processing Schedule, footnote 5).", "Distribution times in the schedule are targets and the Reserve Banks disclaim liability for a later distribution, so the time a receiving bank actually sees a file is not a guaranteed time (FedACH Processing Schedule, footnote 2).", "Where prefunding applies, Appendix C of Operating Circular 4 overrides inconsistent provisions of the circular, including parts of the ordinary settlement mechanics (Operating Circular 4, paragraph 5.3).", "Settlement between banks is not funds availability to the customer. Availability is set separately by the Nacha rules and by Regulation CC." ], "applies_to": "ACH credit and debit entries cleared and settled through the Federal Reserve Banks as ACH operator (FedACH), between US depository institutions holding or using a settlement account at a Reserve Bank", "caveat": "The three same day settlement times and the single 08:30 morning event are the whole settlement timetable, so an ACH payment's speed is decided by which deadline the originating bank makes, not by how fast any party acts afterwards. A bank's own file cutoffs sit hours ahead of the Reserve Bank deadlines and are not published here.", "related": [ "us-ach:finality", "us-ach:hours", "us-ach:limits", "us-ach:return", "us-ach:participants", "us-ach:decision-points" ], "basis": { "sources": "Federal Reserve Banks Operating Circular 4 (ACH Items), effective 2026-01-05, read in full for this record at frbservices.org: paragraphs 5.3, 8.1, 8.2, 9.3, 10.1, 10.2, 10.4, 11.1, 11.2, 14.2, and Appendix B paragraphs 2.1, 2.2 and 3.1. FedACH Processing Schedule, effective 2022-09-12, read at frbservices.org 2026-09-17, for the transmission deadlines, target distribution times and settlement times, and its footnotes 2, 3, 4 and 5. Nacha public page The ABCs of ACH, read 2026-09-17, for the count of settlements per business day and the Federal Reserve settlement system hours. The Nacha Operating Rules themselves are paid and were not opened.", "confidence": "medium" }, "currency": { "effective_since": "2022-09-12", "effective_to": null, "effective_note": "The clock times are those of the FedACH Processing Schedule effective 2022-09-12, which the Reserve Banks may amend at any time (Operating Circular 4, paragraph 2.1(n)). The Operating Circular 4 paragraphs cited are those of the edition effective 2026-01-05; earlier editions were not read, so the date each paragraph first took this form is [Unverified].", "source_edition": "Federal Reserve Banks Operating Circular 4, effective 2026-01-05; FedACH Processing Schedule, effective 2022-09-12; Nacha public pages read 2026-09-17", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://www.frbservices.org/binaries/content/assets/crsocms/resources/rules-regulations/010526-operating-circular-4.pdf", "source_class": "authoritative_primary", "source_title": "Federal Reserve Banks Operating Circular No. 4, Automated Clearing House Items, effective January 5, 2026", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms settlement obligation runs to the Administrative Reserve Bank (10.1), the settlement mechanics debiting/crediting each side at the scheduled time (10.2), conditional availability of credit given for a debit and next morning unwind (11.1), final credit item availability (11.2), prefunding (5.3 with Appendix C), returns settling the same way (14.2), and Appendix B's effective date windows and settlement date rules (2.1-3.1)." }, { "source_url": "https://www.frbservices.org/resources/resource-centers/same-day-ach/fedach-processing-schedule.html", "source_class": "authoritative_primary", "source_title": "FedACH Processing Schedule, effective September 12, 2022", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Confirms same day settlement times 13:00, 17:00 and 18:00 ET matching the three transmission deadlines, and the single 08:30 ET future dated settlement event." } ] }, "rail_name": "US ACH", "governing_authority": "Nacha", "snapshot": "2026-09-16", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "visa:consumer-law", "id": "consumer-law", "rail": "visa", "kind": "rail-fact", "facet": "consumer-law", "name": "How do Visa's rules relate to consumer protection law?", "statement": "Visa's rules sit under the law, not over it. Where the rules and applicable law conflict, the law governs, and every transaction must be legal where the cardholder is and where the merchant outlet is. In disputes an issuer must give cardholders every protection the law provides for any Visa card, and in Europe Visa requires strong customer authentication for e-commerce in line with PSD2. The laws themselves were not read for this record.", "details": [ { "label": "Law prevails", "value": "Where the rules and applicable law clash, the law governs. Legality is tested twice, where the cardholder is and where the merchant outlet is. Obeying local law, consumer protection included, is each Member's duty, and the duty extends to the merchants and agents it brings into the system.", "citation": "VR 1.1.1.3 (ID# 0000385)", "rests_on": "rule" }, { "label": "Protections in disputes", "value": "An issuer resolving a cardholder dispute must extend all protections the law gives on any Visa card, using its usual practices, so that similar cases come out the same whatever the card type.", "citation": "VR 11.1.2 (ID# 0030208)", "rests_on": "rule" }, { "label": "No third-party rights", "value": "The rules govern Visa and its Members and their agents; they give no rights to anyone else, so a cardholder's enforceable rights come from law and the card agreement, not from the rules [Inference as to the card agreement].", "citation": "VR 1.1.1.5 (ID# 0007428)", "rests_on": "rule" }, { "label": "Illegal transactions", "value": "An issuer that finds a transaction illegal must decline it with code 93.", "citation": "VR 1.7.4.1 (ID# 0029326)", "rests_on": "rule" } ], "exceptions": [ "Europe Region: e-commerce transactions on cards issued in the EEA and the United Kingdom must be subject to strong customer authentication in line with Directive (EU) 2015/2366 (VR 7.9.1.1, ID# 0030622). The directive was not read.", "Canada Region, US Region and US Territories: a Member may file for compliance over an improperly assessed credit card surcharge without showing a loss, and the issuer must credit the surcharge to the cardholder if it was billed (VR 11.12.4, ID# 0030229)." ], "applies_to": "Visa transactions in all Visa Regions; law lines apply only where the named law applies", "caveat": "US Regulations E and Z, the EU payment services rules and national consumer law were not read, so this record says only how the Visa rules defer to law, not what the law requires [Unverified]. Zero liability (visa:liability) is a Visa rule and is separate from these laws.", "related": [ "visa:liability", "visa:return", "visa:refund" ], "basis": { "sources": "Visa Core Rules and Visa Product and Service Rules, edition 18 April 2026 (marked Visa Public), fetched 2026-09-19 with a plain GET from https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf (7,591,762 bytes, 923 pages, PDF created 2026-04-21) and read with python3. Sections read for this record: 1.1.1.3, 1.1.1.5, 1.7.4.1, 7.9.1.1, 11.1.2, 11.12.4. Rules are cited by section and ID#; nothing is quoted, and the wording and order here are Orca's own.", "confidence": "medium" }, "currency": { "effective_since": "Not dated in the edition read", "effective_note": "Stated as the rules read in the 18 April 2026 edition; the rules cited carry their own last-updated months in their ID# footers. Visa publishes a new edition each April and October, and the next is expected in October 2026 [Inference from the edition pattern].", "source_edition": "Visa Core Rules and Visa Product and Service Rules, edition 18 April 2026", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf", "source_class": "authoritative_primary", "source_title": "Visa Core Rules and Visa Product and Service Rules, 18 April 2026", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms every detail's citation: VR 1.1.1.3 on law prevailing over the rules and the double legality test, VR 11.1.2 on extending legal protections in dispute handling, VR 1.1.1.5 on the rules giving no third-party rights, and VR 1.7.4.1 on the mandatory decline code 93 for an illegal transaction. Confirms the Canada and US surcharge compliance exception in VR 11.12.4, including that no financial loss need be shown and that a billed surcharge must be credited to the cardholder." } ] }, "rail_name": "Visa", "governing_authority": "Visa (Visa Core Rules and Visa Product and Service Rules)", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "visa:decision-points", "id": "decision-points", "rail": "visa", "kind": "rail-fact", "facet": "decision-points", "name": "Where do Visa's rules leave a decision to an issuer, an acquirer or Visa?", "statement": "Visa's rules leave several choices to people and institutions rather than to fixed outcomes. The issuer decides each authorization on its merits and decides whether to dispute; the acquirer decides whether to contest; the issuer decides whether to accept a pre-arbitration attempt; the filing Member chooses whether to go to its Group Member or to Visa; and Visa's Arbitration and Compliance Committee decides the case, weighing fairness and able to split the loss.", "details": [ { "label": "Issuer: each authorization", "value": "Blanket declines, for example by BIN, country or channel, are barred; each properly submitted transaction must be judged on its own. The bar lifts for commercial card issuers blocking gambling or non-fiat currency purchases, for approved special-purpose programs, and where an immediate fraud threat or a legal or rule-based exception exists. A transaction the issuer finds illegal gets code 93.", "citation": "VR 1.7.4.1 (ID# 0029326)", "rests_on": "rule" }, { "label": "Issuer: whether to dispute", "value": "Before disputing, the issuer must try to honor the transaction, must review the case with due diligence, and must not raise an invalid dispute.", "citation": "VR 1.10.1.1 (ID# 0003287); 11.1.2 (ID# 0030208)", "rests_on": "rule" }, { "label": "Acquirer: whether to contest", "value": "The acquirer may contest with a dispute response or a pre-arbitration attempt, as the category allows, and must check that a pre-arbitration attempt is valid before sending it. For 10.1, 10.3 and 10.4 it may attach compelling evidence of listed kinds.", "citation": "VR 11.2.2 (ID# 0030212); 11.2.3 (ID# 0030213); 11.5.1, Table 11-6 (ID# 0030221)", "rests_on": "rule" }, { "label": "Issuer: accept or decline pre-arbitration", "value": "In fraud and authorization cases the issuer may accept liability or decline; if the acquirer sent compelling evidence, a decline needs the issuer's certification that the contact details do not match or that it asked the cardholder and has an explanation.", "citation": "VR 11.2.2, Table 11-1 (ID# 0030212)", "rests_on": "rule" }, { "label": "Where to file", "value": "A Member files an arbitration or compliance case with its Group Member or with Visa. A Group Member that finds the request invalid returns it, and the Member may not then go to Visa.", "citation": "VR 11.13.1 (ID# 0030366)", "rests_on": "rule" }, { "label": "Visa decides", "value": "Visa decides on all the information it has, including the rules in force on the transaction date, and may weigh other factors such as fairness. It may split the loss where one side offered a fair compromise or the committee finds a split warranted.", "citation": "VR 1.10.2.2 (ID# 0027133); 1.10.2.3 (ID# 0003623)", "rests_on": "rule" }, { "label": "Visa may excuse a missed deadline", "value": "If a Visa back-office platform failure made a Member miss a deadline or a document requirement, Visa may grant an exception; the Member must ask within 15 calendar days of the failure.", "citation": "VR 11.1.3 (ID# 0030209)", "rests_on": "rule" } ], "exceptions": [ "LAC Region (Chile): the rule against systematic or wholesale declines does not apply (VR 1.7.4.1 note 3).", "Europe Region: Members processing through Visa also follow the Visa Europe Operating Regulations - Processing, which were not read (VR 1.1.1.2); a Europe Member whose Visa Scheme Processor is not Visa may still use Visa for arbitration and compliance (VR 11.3.1 note 1)." ], "applies_to": "Visa transactions and disputes in all Visa Regions", "caveat": "This record is Orca's reading of where the rules leave judgment open; each line cites the rule that leaves the choice. The cardholder's own choice, whether to complain to the issuer at all, sits outside the rules.", "related": [ "visa:return", "visa:liability", "visa:participants", "visa:finality", "visa-decline:93", "visa-decline:CATEGORY_4" ], "basis": { "sources": "Visa Core Rules and Visa Product and Service Rules, edition 18 April 2026 (marked Visa Public), fetched 2026-09-19 with a plain GET from https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf (7,591,762 bytes, 923 pages, PDF created 2026-04-21) and read with python3. Sections read for this record: 1.1.1.2, 1.7.4.1, 1.10.1.1, 1.10.2.2, 1.10.2.3, 11.1.2, 11.1.3, 11.2.2 with Table 11-1, 11.2.3, 11.3.1, 11.5.1 with Table 11-6, 11.13.1. Rules are cited by section and ID#; nothing is quoted, and the wording and order here are Orca's own.", "confidence": "medium" }, "currency": { "effective_since": "Not dated in the edition read", "effective_note": "Stated as the rules read in the 18 April 2026 edition; the rules cited carry their own last-updated months in their ID# footers. Visa publishes a new edition each April and October, and the next is expected in October 2026 [Inference from the edition pattern].", "source_edition": "Visa Core Rules and Visa Product and Service Rules, edition 18 April 2026", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf", "source_class": "authoritative_primary", "source_title": "Visa Core Rules and Visa Product and Service Rules, 18 April 2026", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms every detail's citation: VR 1.7.4.1 on the bar on systematic declines and the mandatory code 93, VR 1.10.1.1 and 11.1.2 on the issuer's duties before and during a dispute, VR 11.2.2 and 11.2.3 with Tables 11-1 and 11-6 on the acquirer's contest options, VR 11.13.1 on filing with a Group Member or Visa, VR 1.10.2.2 and 1.10.2.3 on Visa's decision basis and power to split liability, and VR 11.1.3 on the 15 calendar day window to ask Visa to excuse a platform-failure deadline miss." } ] }, "rail_name": "Visa", "governing_authority": "Visa (Visa Core Rules and Visa Product and Service Rules)", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "judgement", "label": "your bank's own terms", "needs": "whose terms decide it: the bank's, the participant's or the scheme's", "detail": "The cardholder's own choice, whether to complain to the issuer at all, sits outside the rules.", "from": "caveat" } ] }, { "uid": "visa:finality", "id": "finality", "rail": "visa", "kind": "rail-fact", "facet": "finality", "name": "When does a Visa card payment become final, and can it be reversed?", "statement": "No single moment makes a Visa card payment final. An approval is a promise by the issuer, not a transfer of money; funds move later, through clearing and Visa's net settlement between Members. Even after settlement the cardholder's issuer can take the amount back through a dispute, for 75 or 120 days in most cases and up to 540 days for some consumer disputes. The only step the rules call final is the outcome of Visa's own case process: an arbitration or compliance ruling, open only to an appeal the rules permit.", "details": [ { "label": "An approval moves no money", "value": "Authorization tells the merchant whether the issuer will stand behind the sale. It can be cancelled with an authorization reversal, and a merchant that receives an approval after it has already timed the sale out must send one.", "citation": "VR 7.3.4.2 (ID# 0030580); Glossary, Authorization Response (ID# 0024321) and Authorization Reversal", "rests_on": "rule" }, { "label": "The issuer owes payment for valid cards", "value": "An issuer must pay the acquirer what is due on a transaction made with a valid card, and this now expressly covers an agentic transaction carried out on the cardholder's instructions.", "citation": "VR 1.7.6.1 (ID# 0006558)", "rests_on": "rule" }, { "label": "Disputes reopen settled payments", "value": "After presentment the issuer may send a transaction back under one of 23 dispute conditions. The time to do so is 75 or 120 calendar days in most conditions, counted mainly from the processing date; several consumer-dispute conditions start the clock at a later event but cap it at 540 days after processing.", "citation": "VR 11.2.2 (ID# 0030212); 11.2.3 (ID# 0030213); time limit tables, for example 11.7.5.4 (ID# 0030255), 11.10.2.4 (ID# 0030316), 11.10.7.4 (ID# 0030346)", "rests_on": "rule" }, { "label": "Case rulings bind both Members", "value": "When a dispute reaches arbitration or compliance, Visa decides who bears the loss, in writing to both sides. The ruling can be challenged only through an appeal the rules allow, and the appeal decision itself cannot be challenged.", "citation": "VR 1.10.2.2 (ID# 0027133); 1.10.2.4 (ID# 0001440)", "rests_on": "rule" }, { "label": "When an appeal is possible", "value": "An appeal needs evidence that was not available when the case was filed and at least USD 5,000 in dispute (or local equivalent), and must be filed within 60 calendar days of notice of the committee's decision.", "citation": "VR 11.13.4 (ID# 0030373); 11.13.5 (ID# 0030374)", "rests_on": "rule" } ], "exceptions": [ "US Region: the issuer answers for every transaction receipt bearing its BIN where a valid card was properly honored, and an acquirer may not pass its guarantee of payment to a non-Member (VR 7.7.4.4, ID# 0005710; 7.7.4.5, ID# 0005146).", "Europe Region: Members processing through Visa are also bound by the Visa Europe Operating Regulations - Processing, which were not read (VR 1.1.1.2, ID# 0029986).", "Domestic transactions processed under a Private Agreement need not use VisaNet or Visa Resolve Online for dispute financial messages (VR 11.3.1, ID# 0030214), so the path back may differ.", "Compliance cases, used where a Member has no dispute right, have their own time limits: generally 90 calendar days, and in some cases up to 2 years from the transaction date when the loss was found later (VR 11.12.2, ID# 0030227)." ], "applies_to": "Visa card transactions between Members in all Visa Regions, under the Visa rules; cardholder rights under law sit outside this record", "caveat": "Do not read an approval, or a completed settlement, as final payment. On Visa the issuer can reverse the flow through a dispute long after settlement, and consumer law may give the cardholder further rights outside the rules.", "related": [ "visa:settlement", "visa:return", "visa:recall", "visa:liability", "visa:decision-points", "visa-dispute:13.1", "paypal:finality" ], "basis": { "sources": "Visa Core Rules and Visa Product and Service Rules, edition 18 April 2026 (marked Visa Public), fetched 2026-09-19 with a plain GET from https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf (7,591,762 bytes, 923 pages, PDF created 2026-04-21) and read with python3. Sections read for this record: 1.7.6.1, 1.10.2.2, 1.10.2.4, 7.3.4.2, 7.7.4.4, 7.7.4.5, 11.2.2, 11.2.3, 11.3.1, 11.12.2, 11.13.4, 11.13.5, the dispute time limit tables named, and the glossary entries named. Rules are cited by section and ID#; nothing is quoted, and the wording and order here are Orca's own.", "confidence": "high" }, "currency": { "effective_since": "Not dated in the edition read", "effective_note": "Stated as the rules read in the 18 April 2026 edition; the rules cited carry their own last-updated months in their ID# footers. Visa publishes a new edition each April and October, and the next is expected in October 2026 [Inference from the edition pattern].", "source_edition": "Visa Core Rules and Visa Product and Service Rules, edition 18 April 2026", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf", "source_class": "authoritative_primary", "source_title": "Visa Core Rules and Visa Product and Service Rules, 18 April 2026", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms every detail's citation: VR 7.3.4.2 on the authorization reversal duty, VR 1.7.6.1 on the issuer's payment duty for a valid card including agentic transactions, VR 11.2.2 and 11.2.3 on the dispute time limits, VR 1.10.2.2 and 1.10.2.4 on the finality of an arbitration or compliance decision subject only to a permitted appeal, and VR 11.13.4 and 11.13.5 on the new-evidence, USD 5,000 and 60 day appeal conditions. Confirms the US BIN-responsibility exception in VR 7.7.4.4 and 7.7.4.5 and the compliance time limits in VR 11.12.2, including the 90 day general limit and the 2 year limit from later discovery." } ] }, "rail_name": "Visa", "governing_authority": "Visa (Visa Core Rules and Visa Product and Service Rules)", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "visa:hours", "id": "hours", "rail": "visa", "kind": "rail-fact", "facet": "hours", "name": "When is Visa authorization available, and how fast must an issuer answer?", "statement": "Authorization never closes: every Member must provide authorization services around the clock, every day, either itself or through a processor. Issuers have seconds to answer, and when they do not, Visa answers for them through Stand-In Processing. Clearing and settlement processing days and cut-offs are not in the public rules.", "details": [ { "label": "Always on", "value": "A Member must take part in the Card Verification Service and give authorization for all its cardholders and merchants 24 hours a day, 7 days a week. It may do this as a VisaNet Processor itself, rely on another processor (Visa included), use other means Visa approves, or in Europe use a Visa Scheme Processor.", "citation": "VR 7.3.3.1 (ID# 0004381)", "rests_on": "rule" }, { "label": "Issuer response limits", "value": "Outside Europe an issuer has 10 seconds to answer a point-of-sale or Visa Direct request and 25 seconds for ATM cash under MCC 6011. In Europe the limit is 5 seconds for all three.", "citation": "VR 7.3.4.1, Table 7-1 (ID# 0004385)", "rests_on": "rule" }, { "label": "Visa answers on timeout", "value": "If no answer reaches Visa within the limit, Visa responds on the issuer's behalf through Stand-In Processing (in Europe, the Visa Scheme Processor does). Stand-In also acts when the issuer or its processor is unavailable or has asked Visa to act, and a stand-in approval carries an authorization code the acquirer must pass to the merchant.", "citation": "VR 7.3.4.1 (ID# 0004385); 7.3.2.1 (ID# 0005498); Glossary, Stand-In Processing (ID# 0025121)", "rests_on": "rule" }, { "label": "Merchant timeout floor", "value": "An acquirer or merchant may not time out a point-of-sale transaction in under 15 seconds, and an approval that arrives after a timeout must be reversed.", "citation": "VR 7.3.4.2 (ID# 0030580)", "rests_on": "rule" } ], "exceptions": [ "US Region: an issuer or its authorizing processor, stand-in included, must keep its average response time at or under 5 seconds in each calendar month (VR 7.3.3.1).", "Europe Region: the 15-second merchant timeout floor does not apply (VR 7.3.4.2 note 1), and the Card Verification Service duty does not apply there; a Member using Visa for processing refers to the Visa Europe Operating Regulations - Processing (VR 7.3.3.1 note 1).", "Clearing and settlement processing days, windows and cut-offs are in VisaNet manuals, which were not read [Unverified]." ], "applies_to": "Authorization services in all Visa Regions", "caveat": "Always-on authorization does not mean always-on settlement. Funds move on Visa's settlement schedule, which the public rules do not publish.", "related": [ "visa:settlement", "visa:messages", "visa:decision-points", "visa-decline:91", "visa-decline:83" ], "basis": { "sources": "Visa Core Rules and Visa Product and Service Rules, edition 18 April 2026 (marked Visa Public), fetched 2026-09-19 with a plain GET from https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf (7,591,762 bytes, 923 pages, PDF created 2026-04-21) and read with python3. Sections read for this record: 7.3.2.1, 7.3.3.1, 7.3.4.1, 7.3.4.2, and the glossary entry named. Rules are cited by section and ID#; nothing is quoted, and the wording and order here are Orca's own.", "confidence": "high" }, "currency": { "effective_since": "Not dated in the edition read", "effective_note": "Stated as the rules read in the 18 April 2026 edition; the rules cited carry their own last-updated months in their ID# footers. Visa publishes a new edition each April and October, and the next is expected in October 2026 [Inference from the edition pattern].", "source_edition": "Visa Core Rules and Visa Product and Service Rules, edition 18 April 2026", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf", "source_class": "authoritative_primary", "source_title": "Visa Core Rules and Visa Product and Service Rules, 18 April 2026", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms every detail's citation: VR 7.3.3.1 on the 24 hour, 7 day authorization duty and its Card Verification Service link, VR 7.3.4.1 with Table 7-1 on the 10, 25 and 5 second response limits by region and transaction type, VR 7.3.4.1 and 7.3.2.1 on Stand-In Processing answering on timeout, and VR 7.3.4.2 on the 15 second merchant timeout floor and the reversal duty. Confirms the US average-response exception, the Europe carve-outs from the merchant timeout floor and the Card Verification Service duty, and that clearing and settlement cut-offs are not in the sections read." } ] }, "rail_name": "Visa", "governing_authority": "Visa (Visa Core Rules and Visa Product and Service Rules)", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "visa:liability", "id": "liability", "rail": "visa", "kind": "rail-fact", "facet": "liability", "name": "Who bears the loss for fraud or error on a Visa card payment?", "statement": "Visa's rules spread fraud and error losses in layers. Toward the cardholder, the issuer must hold liability for unauthorized use at zero, with product exclusions, and outside Europe must give provisional credit on set timelines. Between issuer and acquirer, fraud losses move through the fraud dispute conditions: the chip liability shift decides who bears counterfeit and some lost or stolen card fraud, and 3-D Secure authentication makes a card-absent fraud dispute invalid. Visa also runs a monitoring program for acquirers and merchants with high fraud or dispute levels.", "details": [ { "label": "Zero liability", "value": "Outside Visa Corporate, Visa Purchasing and anonymous prepaid transactions, a cardholder who reports an unauthorized transaction owes nothing for it. The issuer can set a higher share only on substantial evidence of the cardholder's own fraud or negligence, and must tell cardholders of any such limits.", "citation": "VR 1.4.5.1 (ID# 0029460)", "rests_on": "rule" }, { "label": "Provisional credit", "value": "Outside Europe the issuer must credit the cardholder provisionally for a dispute or an unauthorized transaction while it is worked, on timelines that range from immediately to 5 business days by region and card product; for some Canada Region cards the credit is due once the dispute is confirmed as valid and legitimate.", "citation": "VR 4.1.11.1, Table 4-4", "rests_on": "rule" }, { "label": "Chip liability shift", "value": "The shift covers counterfeit fraud at POS and ATM in the AP and US Regions (Mainland China domestic excluded), and counterfeit, lost, stolen and not-received fraud at POS and ATM in the Canada, CEMEA, Europe and LAC Regions, with a carve-out for some Visa Easy Payment Service transactions.", "citation": "VR 1.10.1.2, Table 1-12 (ID# 0008190)", "rests_on": "rule" }, { "label": "3-D Secure moves card-absent fraud liability", "value": "A 10.4 card-absent fraud dispute is invalid for a transaction the issuer authenticated through Visa Secure with EMV 3DS (ECI 5 with a CAVV in the authorization request), and for an attempted authentication the issuer or Visa answered (ECI 6 with a CAVV), other than on a non-reloadable prepaid card.", "citation": "VR 11.7.5.3, Table 11-28 (ID# 0030254)", "rests_on": "rule" }, { "label": "Case outcomes", "value": "In arbitration or compliance, Visa may put the full loss on one Member or split it, and the Member held responsible pays the amount and the review fee.", "citation": "VR 1.10.2.2 (ID# 0027133); 1.10.2.3 (ID# 0003623)", "rests_on": "rule" }, { "label": "Monitoring", "value": "Visa identifies acquirers under the Visa Acquirer Monitoring Program and may require them or their merchants to deploy remediation tools. Entry and exit thresholds are in the program guide, which was not read.", "citation": "VR 10.4.3.1 (ID# 0029286)", "rests_on": "rule" } ], "exceptions": [ "Europe Region: the issuer may also raise the cardholder's liability where substantial evidence proves the cardholder took part in the transaction (VR 1.4.5.1).", "Europe Region: VR 4.1.11.1 names every region except Europe, so the provisional credit timetable there does not reach Europe.", "AP Region (Malaysia): the liability shift also covers some domestic lost, stolen and not-received fraud (Table 1-12 note 1).", "US Region: Visa Infinite and Visa Infinite Business cardholders get provisional credit immediately; Canada Region debit category cards within 2 business days, with listed grounds for delay (Table 4-4)." ], "applies_to": "Fraud and error liability under the Visa rules in all Visa Regions, with the regional variants listed", "caveat": "Zero liability is a Visa rule the issuer applies, not a statute. Regulation E and Z limits, PSD2 rights and national law exist independently and were not read (see visa:consumer-law). Do not merge the two.", "related": [ "visa:consumer-law", "visa:return", "visa:finality", "visa:decision-points", "visa-dispute:10.1", "visa-dispute:10.2", "visa-dispute:10.3", "visa-dispute:10.4", "visa-dispute:10.5" ], "basis": { "sources": "Visa Core Rules and Visa Product and Service Rules, edition 18 April 2026 (marked Visa Public), fetched 2026-09-19 with a plain GET from https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf (7,591,762 bytes, 923 pages, PDF created 2026-04-21) and read with python3. Sections read for this record: 1.4.5.1, 1.10.1.2 with Table 1-12, 1.10.2.2, 1.10.2.3, 4.1.11.1 with Table 4-4, 10.4.3.1, 11.7.5.3 with Table 11-28. Rules are cited by section and ID#; nothing is quoted, and the wording and order here are Orca's own.", "confidence": "high" }, "currency": { "effective_since": "Not dated in the edition read", "effective_note": "Stated as the rules read in the 18 April 2026 edition; the rules cited carry their own last-updated months in their ID# footers. Visa publishes a new edition each April and October, and the next is expected in October 2026 [Inference from the edition pattern]. Known dated change: for disputes processed on or after 2026-10-24 the 10.4 compelling-evidence and AVS rules change (VR 11.7.5.3).", "source_edition": "Visa Core Rules and Visa Product and Service Rules, edition 18 April 2026", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf", "source_class": "authoritative_primary", "source_title": "Visa Core Rules and Visa Product and Service Rules, 18 April 2026", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms every detail's citation: VR 1.4.5.1 on zero liability, its product exclusions and the negligence carve-out including the Europe participation ground, VR 4.1.11.1 with Table 4-4 on provisional credit timelines outside Europe (confirmed for the US Visa Infinite immediate credit and the Canada debit 2 business day rule), VR 1.10.1.2 with Table 1-12 on the EMV liability shift, VR 11.7.5.3 on 3-D Secure making a 10.4 dispute invalid, VR 1.10.2.2 and 1.10.2.3 on splitting the loss, and VR 10.4.3.1 on the Visa Acquirer Monitoring Program." } ] }, "rail_name": "Visa", "governing_authority": "Visa (Visa Core Rules and Visa Product and Service Rules)", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "visa:limits", "id": "limits", "rail": "visa", "kind": "rail-fact", "facet": "limits", "name": "What amount, count and time limits apply on Visa?", "statement": "The public Visa rules set no network-wide maximum amount for a card payment [Unverified: not every section of the edition was searched]; spending limits a cardholder meets are set by the issuer. The rules do set other limits that shape what can happen to a payment: how far a cleared amount may differ from the authorized one, how often a merchant may retry after a decline, a minimum amount for many travel and entertainment disputes, a cap on fraud disputes per account, and a daily check on card-absent spending.", "details": [ { "label": "Retrying after a decline", "value": "After a category 1 decline the merchant must never retry for the same credential; after any other decline it may make at most 20 attempts in 30 days.", "citation": "VR 7.3.6.3, Table 7-2 (ID# 0030640)", "rests_on": "rule" }, { "label": "Authorized versus cleared amount", "value": "Above the floor limit the cleared amount must equal the authorized amount unless the table allows a gap. Examples: the greater of 15% or USD 75 for vehicle rental; 15% for lodging, cruise lines and other cardholder-initiated card-absent sales; 20% for taxis, bars, beauty and spa merchants. No gap is allowed after a partial authorization or for Visa Purchasing Card commercial payables.", "citation": "VR 7.5.6, Table 7-10 (ID# 0030940)", "rests_on": "rule" }, { "label": "Minimum dispute amount", "value": "For travel and entertainment transactions, most dispute conditions need at least USD 25 (or local equivalent); since 18 April 2026 either the transaction amount or the partial disputed amount may meet it. The fraud conditions and a few others are exempt.", "citation": "VR 11.4.3, Table 11-5 (ID# 0030219)", "rests_on": "rule" }, { "label": "Fraud disputes per account", "value": "A 10.4 card-absent fraud dispute is invalid once the issuer has raised more than 35 disputes on that account number in the previous 120 calendar days.", "citation": "VR 11.7.5.3, Table 11-28 (ID# 0030254)", "rests_on": "rule" }, { "label": "Daily card-absent check", "value": "A card-absent merchant must set a daily number of transactions after which it confirms that the cardholder approves further spending, and that number may not exceed 25 in one day.", "citation": "VR 10.4.4.2 (ID# 0030641)", "rests_on": "rule" }, { "label": "Case and appeal thresholds", "value": "One arbitration or compliance case may hold at most 10 disputed transactions, all with the same credential, acquirer, merchant and condition. An appeal needs at least USD 5,000 in dispute.", "citation": "VR 11.3.1 note 2 (ID# 0030214); 11.13.4 (ID# 0030373)", "rests_on": "rule" } ], "exceptions": [ "US Region: from 21 February 2026 restaurants, caterers and fast food (MCC 5811, 5812, 5814) may clear up to 30% above the authorized amount; in the other regions MCC 5812 and 5814 are allowed 20% (VR 7.5.6, Table 7-10).", "Europe Region: an EEA transaction must clear at the authorized amount (VR 7.5.6).", "LAC Region (Brazil): the USD 25 minimum does not apply to domestic installment transactions (Table 11-5 note 3).", "Mobility and transport merchants have their own limits on authorization requests after a decline (VR 7.3.6.2, ID# 0030046)." ], "applies_to": "All Visa Regions unless an exception names a region", "caveat": "The floor limit that triggers the matching rule appears in the public edition only as a reference to Section X, so it is not published there. Credit lines, daily spend and cash limits are issuer settings, not Visa rules, and are not in this record.", "related": [ "visa:return", "visa:liability", "visa:decision-points", "visa-decline:61", "visa-dispute:10.4" ], "basis": { "sources": "Visa Core Rules and Visa Product and Service Rules, edition 18 April 2026 (marked Visa Public), fetched 2026-09-19 with a plain GET from https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf (7,591,762 bytes, 923 pages, PDF created 2026-04-21) and read with python3. Sections read for this record: 7.3.6.2, 7.3.6.3 with Table 7-2, 7.5.6 with Table 7-10, 10.4.4.2, 11.3.1, 11.4.3 with Table 11-5, 11.7.5.3, 11.13.4. Rules are cited by section and ID#; nothing is quoted, and the wording and order here are Orca's own.", "confidence": "medium" }, "currency": { "effective_since": "2026-04-18", "effective_note": "Dated from the edition read, 18 April 2026, the day the partial-amount reading of the USD 25 minimum took effect (Table 11-5 note 4). The US restaurant tolerance took effect on 2026-02-21. Other limits here carry no start date in the edition read. The next edition is expected in October 2026 [Inference].", "source_edition": "Visa Core Rules and Visa Product and Service Rules, edition 18 April 2026", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf", "source_class": "authoritative_primary", "source_title": "Visa Core Rules and Visa Product and Service Rules, 18 April 2026", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms every detail's citation: VR 7.3.6.3 with Table 7-2 on the reattempt cap, VR 7.5.6 with Table 7-10 on the authorized-to-cleared amount gaps (the vehicle rental, lodging, cruise line, taxi, bar and spa percentages, and the no-gap rule for a partial authorization or a Purchasing Card commercial payable), VR 11.4.3 with Table 11-5 on the USD 25 T&E minimum, VR 11.7.5.3 on the 35-disputes-in-120-days cap for condition 10.4, VR 10.4.4.2 on the 25 transaction daily card-absent check, and VR 11.3.1 and 11.13.4 on the 10 dispute and USD 5,000 case thresholds. Confirms the US restaurant tolerance dated 21 February 2026, the Europe no-gap rule for EEA transactions, and that the floor limit itself is published only as a Section X placeholder." } ] }, "rail_name": "Visa", "governing_authority": "Visa (Visa Core Rules and Visa Product and Service Rules)", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "visa:messages", "id": "messages", "rail": "visa", "kind": "rail-fact", "facet": "messages", "name": "Which Visa systems carry authorization, clearing and dispute messages?", "statement": "Visa's messages run on VisaNet. Authorizations and online financial messages go through the V.I.P. System, clearing and settlement files through BASE II, and dispute actions and documents through Visa Resolve Online (VROL), with dispute financial messages sent through VROL or VisaNet. The public rules name these systems but not the message standard or field layouts, which are in VisaNet manuals.", "details": [ { "label": "VisaNet", "value": "VisaNet is the platform through which Visa provides online authorization, clearing, settlement and reporting to Members.", "citation": "Glossary, VisaNet (ID# 0025218)", "rests_on": "rule" }, { "label": "Authorization: V.I.P. System", "value": "The V.I.P. System is VisaNet's online part, routing and processing authorizations and financial transactions. When the issuer's and acquirer's authorization records differ, the V.I.P. record prevails in arbitration and compliance.", "citation": "Glossary, V.I.P. System (ID# 0025201); VR 11.13.2 (ID# 0030368)", "rests_on": "rule" }, { "label": "Clearing: BASE II", "value": "BASE II is the file-based VisaNet service that collects, clears, settles and delivers financial and non-financial files between Visa and Members.", "citation": "Glossary, BASE II (ID# 0024341)", "rests_on": "rule" }, { "label": "Disputes: VROL", "value": "Case filings, withdrawals and appeals, pre-arbitration and pre-compliance steps, disputes and their responses, and the documents behind them all go through VROL, in English or with a translation. The money side of a dispute action is sent either by VROL itself or by the Member through VisaNet on the same day as the VROL action.", "citation": "VR 11.3.1 (ID# 0030214); 11.2.1 (ID# 0030211); Glossary, Visa Resolve Online (ID# 0025388)", "rests_on": "rule" }, { "label": "Decline codes", "value": "An issuer that declines must send VisaNet the decline response code that fits best, from Table 7-2.", "citation": "VR 7.3.6.3 (ID# 0030640)", "rests_on": "rule" }, { "label": "Specifications not public", "value": "The VisaNet manuals, including the BASE II and V.I.P. System specifications, are listed as Visa Supplemental Requirements. The rules refer to message fields by number (for example field 63.3 in 10.4), but the rules read do not name ISO 8583 or ISO 20022 [Unverified].", "citation": "Visa Supplemental Requirements list, Appendix A (pp. 823 to 824); VR 11.7.5.3 (ID# 0030254)", "rests_on": "guidance" } ], "exceptions": [ "Europe Region: the VROL rule does not apply to a Member whose Visa Scheme Processor is not Visa; such a Member sends information electronically if it wants Visa to handle arbitration and compliance (VR 11.3.1 note 1). The glossary points Europe to the Electronic Documentation Transfer Method.", "Europe Region: a processing Member must send Visa a daily file of its transactions, approvals and declines included, and an issuer must report a dispute within 15 calendar days of its processing date (VR 7.3.11.1).", "Domestic interchange under a Private Agreement need not use VisaNet or VROL for dispute financial messages (VR 11.3.1)." ], "applies_to": "Visa messaging for authorization, clearing and disputes in all Visa Regions", "caveat": "Message formats, field definitions and the full list of response values are in client-only VisaNet manuals, which were not consulted. Do not assume a Visa field or value from another network's ISO 8583 implementation.", "related": [ "visa:settlement", "visa:return", "visa:hours", "visa:participants", "visa-decline:CATEGORY_4" ], "basis": { "sources": "Visa Core Rules and Visa Product and Service Rules, edition 18 April 2026 (marked Visa Public), fetched 2026-09-19 with a plain GET from https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf (7,591,762 bytes, 923 pages, PDF created 2026-04-21) and read with python3. Sections read for this record: 7.3.6.3, 7.3.11.1, 11.2.1, 11.3.1, 11.7.5.3, 11.13.2, Appendix A (Supplemental Requirements list), and the glossary entries named. Rules are cited by section and ID#; nothing is quoted, and the wording and order here are Orca's own.", "confidence": "medium" }, "currency": { "effective_since": "Not dated in the edition read", "effective_note": "Stated as the rules read in the 18 April 2026 edition; the rules cited carry their own last-updated months in their ID# footers. Visa publishes a new edition each April and October, and the next is expected in October 2026 [Inference from the edition pattern].", "source_edition": "Visa Core Rules and Visa Product and Service Rules, edition 18 April 2026", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf", "source_class": "authoritative_primary", "source_title": "Visa Core Rules and Visa Product and Service Rules, 18 April 2026", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms every detail's citation: the VisaNet, V.I.P. System, BASE II and Visa Resolve Online glossary entries, VR 11.13.2 on the V.I.P. authorization record prevailing at arbitration and compliance, VR 11.3.1 on dispute actions running through VROL and the English-language requirement, VR 7.3.6.3 on the decline code duty, and VR 11.7.5.3 naming field 63.3. Confirms the Europe daily transmission file and 15 day dispute reporting duty in VR 7.3.11.1, and that the rules read do not name ISO 8583 or ISO 20022." } ] }, "rail_name": "Visa", "governing_authority": "Visa (Visa Core Rules and Visa Product and Service Rules)", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "visa:participants", "id": "participants", "rail": "visa", "kind": "rail-fact", "facet": "participants", "name": "Who takes part in the Visa system, and in what role?", "statement": "The Visa rules bind Members, Visa's licensed clients, and through them everyone else in the system. Issuers hold the cardholder relationship and acquirers sign merchants and put their transactions into interchange. Around them sit processors, payment facilitators, digital wallet operators, marketplaces and, from 18 April 2026, agentic payment enablers and providers, each with its own rules. A duty written for a merchant is a duty on the merchant's acquirer to make it happen.", "details": [ { "label": "Members and binding force", "value": "A Member is a client of one of the named Visa entities, or a party to a Services Agreement with Visa Canada. The rules form a binding contract between Visa and each Member, and every participant is bound by the charter documents and rules according to its role and geography.", "citation": "Glossary, Member (ID# 0024822); Introduction (ID# 0020308); VR 1.1.1.1 (ID# 0007750)", "rests_on": "rule" }, { "label": "Issuers and acquirers", "value": "The issuer is the Member holding the card contract with the cardholder. The acquirer is the Member that puts transactions into interchange; it is the party that signs merchants and payment facilitators, and the definition also reaches Members that load prepaid cards or pay cash to cardholders.", "citation": "Glossary, Issuer (ID# 0024768) and Acquirer (ID# 0024219)", "rests_on": "rule" }, { "label": "Merchant duties fall on acquirers", "value": "Under Visa's writing conventions, a rule telling a merchant what to do means the acquirer must ensure its merchant does it.", "citation": "Introduction, Writing Conventions (ID# 0020313)", "rests_on": "rule" }, { "label": "Processors", "value": "A VisaNet Processor is a Member or approved non-Member directly connected to VisaNet that provides authorization, clearing or settlement services.", "citation": "Glossary, VisaNet Processor (ID# 0025230)", "rests_on": "rule" }, { "label": "Facilitators and wallets", "value": "A payment facilitator contracts with an acquirer to deposit transactions and receive settlement for sponsored merchants. A digital wallet operator runs a staged or stored value wallet; a staged wallet funds a purchase from the cardholder's card, while a pass-through wallet only hands the credential to the merchant and stays out of authorization, clearing and settlement. Both wallet types may carry agentic transactions from 18 April 2026.", "citation": "Glossary: Payment Facilitator (ID# 0028921), Digital Wallet Operator (ID# 0029530), Staged Digital Wallet (ID# 0029532), Pass-Through Digital Wallet (ID# 0029533)", "rests_on": "rule" }, { "label": "Agentic payments", "value": "An agentic payment provider runs an application that searches and buys for the cardholder on instructions and verification, passing a token to the merchant; it is not treated as a merchant and stays out of authorization, clearing and settlement. An agentic payment enabler connects such providers to Visa without dealing with cardholders. Both must enroll in Visa Intelligent Commerce and register with Visa.", "citation": "Glossary, Agentic Payment Enabler (ID# 0031163) and Agentic Payment Provider; VR 4.1.24.1 (ID# 0031167); 4.1.24.2 (ID# 0031168)", "rests_on": "rule" } ], "exceptions": [ "Europe Region: issuer and acquirer are defined differently (the issuer keeps contractual privity with the cardholder; the acquirer signs merchants for acceptance or pays out currency), and a Visa Scheme Processor may provide authorization, clearing and settlement services (Glossary, ID# 0024768, 0024219, 0029764).", "LAC Region (Chile): the April 2026 wallet and agentic changes take effect on 17 June 2026 (Glossary notes to ID# 0029532 and 0029533).", "AP, Canada, CEMEA, LAC and US Regions: a Group Member, as defined in Visa's by-laws, may receive arbitration and compliance filings (Glossary, ID# 0024685; VR 11.13.1)." ], "applies_to": "Participants in the Visa system in all Visa Regions", "caveat": "Only Members are bound by the rules as a matter of contract; merchants, wallets and agents are reached through the Member that sponsors or contracts with them. The Visa charter documents and by-laws that define membership were not read.", "related": [ "visa:decision-points", "visa:messages", "visa:settlement" ], "basis": { "sources": "Visa Core Rules and Visa Product and Service Rules, edition 18 April 2026 (marked Visa Public), fetched 2026-09-19 with a plain GET from https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf (7,591,762 bytes, 923 pages, PDF created 2026-04-21) and read with python3. Sections read for this record: Introduction (ID# 0020308, 0020313), 1.1.1.1, 4.1.24.1, 4.1.24.2, 11.13.1, and the glossary entries named. Rules are cited by section and ID#; nothing is quoted, and the wording and order here are Orca's own.", "confidence": "high" }, "currency": { "effective_since": "Not dated in the edition read", "effective_note": "Stated as the rules read in the 18 April 2026 edition; the rules cited carry their own last-updated months in their ID# footers. Visa publishes a new edition each April and October, and the next is expected in October 2026 [Inference from the edition pattern]. The wallet and agentic provisions took effect on 2026-04-18 (2026-06-17 in Chile).", "source_edition": "Visa Core Rules and Visa Product and Service Rules, edition 18 April 2026", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf", "source_class": "authoritative_primary", "source_title": "Visa Core Rules and Visa Product and Service Rules, 18 April 2026", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms every detail's citation: the Member, Issuer, Acquirer, VisaNet Processor, Payment Facilitator, Digital Wallet Operator, Staged Digital Wallet and Pass-Through Digital Wallet glossary entries, the Introduction's writing convention that a merchant duty falls on its acquirer, VR 1.1.1.1 on the charter documents binding participants, and VR 4.1.24.1 and 4.1.24.2 on the Agentic Payment Enabler and Provider duties including Visa Intelligent Commerce enrollment. Confirms VR 11.13.1 on Group Member filing and the Chile 17 June 2026 date for the wallet and agentic definitions." } ] }, "rail_name": "Visa", "governing_authority": "Visa (Visa Core Rules and Visa Product and Service Rules)", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "visa:recall", "id": "recall", "rail": "visa", "kind": "rail-fact", "facet": "recall", "name": "Can a Visa card payment be recalled or reversed by the sending side?", "statement": "Once a Visa card payment has been cleared, no one on the paying side can call it back; the cardholder's route is a dispute through the issuer. The rules give narrower correction paths instead: an approval can be reversed before clearing, a merchant must reverse or adjust a transaction it processed in error, a Member must reverse duplicate or wrong data, and a Member may undo its own step in a dispute within a few days.", "details": [ { "label": "Before clearing", "value": "An acquirer must reverse an online financial transaction when no authorization response arrived or the sale was voided, and must forward a merchant's authorization reversal to Visa at once. A transaction reversed in full must not then be deposited.", "citation": "VR 1.7.7.1 (ID# 0005477); 7.3.7.1 (ID# 0005476); 1.7.7.2 (ID# 0025598)", "rests_on": "rule" }, { "label": "Merchant error", "value": "A merchant that processed a transaction in error must reverse or adjust it within 30 calendar days.", "citation": "VR 1.7.7.3 (ID# 0008614)", "rests_on": "rule" }, { "label": "Duplicate or wrong data", "value": "A Member that detects duplicate or erroneous data, or is told of it by Visa, must send reversals within one business day, and the issuer must take the duplicate off the cardholder's account. Visa charges any exchange-rate loss to the Member responsible.", "citation": "VR 1.7.7.4 (ID# 0008878); 1.7.7.5 (ID# 0008879)", "rests_on": "rule" }, { "label": "Credit reversals", "value": "An acquirer may reverse a credit only to correct an inadvertent processing error, within 30 calendar days of the credit's processing date.", "citation": "VR 1.7.7.6 (ID# 0008880)", "rests_on": "rule" }, { "label": "Undoing a dispute step", "value": "A Member may reverse its own dispute, dispute response, pre-arbitration attempt or reply within 3 calendar days of processing (1 day where an Original Credit Transaction is disputed), as long as the other side has not moved to the next stage and no one has accepted liability. The 3-day limit does not apply when the cardholder has told the issuer the dispute is dropped.", "citation": "VR 11.3.3 (ID# 0030216)", "rests_on": "rule" } ], "exceptions": [ "US Region: the merchant correction and credit reversal windows are 45 calendar days for PIN-authenticated Visa Debit transactions (VR 1.7.7.3 note 1; 1.7.7.6 note 2).", "Stop Payment Service: an issuer that takes part may, at the cardholder's request, place a stop instruction on card-absent transactions; this stops future authorizations rather than recalling a paid one [Inference] (VR 7.8.2.1, ID# 0030698; Glossary, Stop Payment Service, ID# 0030697). From 2026-10-24 the service rule does not apply in the LAC Region (Brazil).", "Europe Region: Members processing through Visa also follow the Visa Europe Operating Regulations - Processing, which were not read (VR 1.1.1.2)." ], "applies_to": "Visa transactions in all Visa Regions", "caveat": "A merchant refund is not a recall; it is a new credit transaction (see visa:refund). A cardholder who wants a card payment back after clearing has to go through the issuer, whose tool is the dispute (see visa:return).", "related": [ "visa:return", "visa:refund", "visa:finality", "visa:decision-points", "visa-decline:R0", "visa-decline:R1" ], "basis": { "sources": "Visa Core Rules and Visa Product and Service Rules, edition 18 April 2026 (marked Visa Public), fetched 2026-09-19 with a plain GET from https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf (7,591,762 bytes, 923 pages, PDF created 2026-04-21) and read with python3. Sections read for this record: 1.1.1.2, 1.7.7.1 to 1.7.7.6, 7.3.7.1, 7.8.2.1, 11.3.3, and the glossary entry named. Rules are cited by section and ID#; nothing is quoted, and the wording and order here are Orca's own.", "confidence": "high" }, "currency": { "effective_since": "Not dated in the edition read", "effective_note": "Stated as the rules read in the 18 April 2026 edition; the rules cited carry their own last-updated months in their ID# footers. Visa publishes a new edition each April and October, and the next is expected in October 2026 [Inference from the edition pattern].", "source_edition": "Visa Core Rules and Visa Product and Service Rules, edition 18 April 2026", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf", "source_class": "authoritative_primary", "source_title": "Visa Core Rules and Visa Product and Service Rules, 18 April 2026", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms every detail's citation: VR 1.7.7.1 and 1.7.7.2 on authorization reversal before clearing, VR 7.3.7.1 on forwarding a reversal to Visa, VR 1.7.7.3 on the 30 calendar day merchant error window and its US 45 day PIN-debit variant, VR 1.7.7.4 and 1.7.7.5 on the one business day duplicate-data reversal, VR 1.7.7.6 on the 30 day credit reversal window, and VR 11.3.3 confirming the reversal-of-a-dispute-step window is 3 calendar days (1 day for an Original Credit Transaction dispute), which the extracted text renders as 31 because a footnote marker attaches to the digit. Confirms the Stop Payment Service glossary entry and VR 7.8.2.1, including the Brazil carve-out from 24 October 2026." } ] }, "rail_name": "Visa", "governing_authority": "Visa (Visa Core Rules and Visa Product and Service Rules)", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "visa:refund", "id": "refund", "rail": "visa", "kind": "rail-fact", "facet": "refund", "name": "How does a merchant refund a Visa card payment?", "statement": "A merchant sets its own refund policy but must disclose it. A refund is a new credit transaction, sent where possible to the credential used for the purchase, with fallbacks to another credential or to other means in listed situations. If a promised credit never arrives, the issuer can dispute under condition 13.6.", "details": [ { "label": "Policy is the merchant's", "value": "The merchant may choose its own credit refund policy, subject to the disclosure rule in VR 5.4.2.5.", "citation": "VR 1.5.4.14 (ID# 0003076)", "rests_on": "rule" }, { "label": "Where the refund goes", "value": "The first choice is the original payment credential. With proof of purchase, a second credential may be used if the original is closed, transferred or reported lost or stolen, or declines the credit. Cash, cheque, store credit or a prepaid card may be used in stated cases, for example when credits to the card keep being declined, when a gift is returned by someone other than the cardholder, or when there is no proof of purchase.", "citation": "VR 1.5.4.14 (ID# 0003076)", "rests_on": "rule" }, { "label": "No credit without a sale", "value": "A merchant may not issue a credit unless it earlier completed a sale with the same cardholder, and may not take card payments to put money into the cardholder's account, except for loads to prepaid cards in the Visa Prepaid Load Service.", "citation": "VR 1.5.4.14 (ID# 0003076)", "rests_on": "rule" }, { "label": "Faster Refund", "value": "A merchant that uses a Faster Refund to deliver the credit follows the Visa Direct for Card Processing Guide from 18 April 2026.", "citation": "VR 1.5.4.14 (ID# 0003076)", "rests_on": "rule" }, { "label": "Timeshares", "value": "A timeshare merchant must refund in full when the cardholder cancels within 14 calendar days of the contract date or of receiving the contract documents.", "citation": "VR 5.10.1.1 (ID# 0003082)", "rests_on": "rule" }, { "label": "Credit never arrived", "value": "Under condition 13.6 the issuer waits 15 calendar days from the date on the credit receipt, then has 120 days from that date, never more than 540 days after the original processing date.", "citation": "VR 11.10.7.4, Table 11-125 (ID# 0030346)", "rests_on": "rule" }, { "label": "No double recovery", "value": "A cardholder must not be credited twice through both a dispute and a merchant credit; such a case is settled through the dispute process.", "citation": "VR 1.10.1.1 (ID# 0003287)", "rests_on": "rule" } ], "exceptions": [ "AP Region (Australia, New Zealand), Canada Region, Europe Region, US Region and US Territories: the merchant must refund any surcharge with the purchase, pro-rated on a partial refund (VR 1.5.4.14).", "For ATM transactions, a 13.6 dispute is counted from the processing date of the adjustment (VR 11.10.7.4).", "Consumer law may give refund or cancellation rights that the Visa rules do not; none was read for this record." ], "applies_to": "Refunds by merchants accepting Visa, in all Visa Regions unless an exception names a region", "caveat": "A refund depends on the merchant's policy and moves as a separate credit; it is not a recall of the original payment and it is not a dispute. The disclosure rule, VR 5.4.2.5, was not read.", "related": [ "visa:return", "visa:recall", "visa:consumer-law", "visa-dispute:13.6", "visa-dispute:13.7" ], "basis": { "sources": "Visa Core Rules and Visa Product and Service Rules, edition 18 April 2026 (marked Visa Public), fetched 2026-09-19 with a plain GET from https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf (7,591,762 bytes, 923 pages, PDF created 2026-04-21) and read with python3. Sections read for this record: 1.5.4.14, 1.10.1.1, 5.10.1.1, 11.10.7.4. Rules are cited by section and ID#; nothing is quoted, and the wording and order here are Orca's own.", "confidence": "high" }, "currency": { "effective_since": "Not dated in the edition read", "effective_note": "Stated as the rules read in the 18 April 2026 edition; the rules cited carry their own last-updated months in their ID# footers. Visa publishes a new edition each April and October, and the next is expected in October 2026 [Inference from the edition pattern].", "source_edition": "Visa Core Rules and Visa Product and Service Rules, edition 18 April 2026", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf", "source_class": "authoritative_primary", "source_title": "Visa Core Rules and Visa Product and Service Rules, 18 April 2026", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms every detail's citation: VR 1.5.4.14 on the merchant's own refund policy and disclosure duty, the credential-fallback order (secondary credential, then cash, cheque, in-store credit or a prepaid card in the listed situations), the bar on taking deposits or crediting without a prior sale (Prepaid Load Service excepted), and the Faster Refund guide reference dated 18 April 2026. Confirms VR 5.10.1.1 on the 14 day timeshare refund, VR 11.10.7.4 on the 13.6 credit-never-arrived timeline, and VR 1.10.1.1 on the no-double-recovery rule. Confirms the AP (Australia, New Zealand), Canada, Europe and US surcharge refund exception." } ] }, "rail_name": "Visa", "governing_authority": "Visa (Visa Core Rules and Visa Product and Service Rules)", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [ { "kind": "judgement", "label": "your bank's own terms", "needs": "whose terms decide it: the bank's, the participant's or the scheme's", "detail": "A refund depends on the merchant's policy and moves as a separate credit; it is not a recall of the original payment and it is not a dispute.", "from": "caveat" } ] }, { "uid": "visa:return", "id": "return", "rail": "visa", "kind": "rail-fact", "facet": "return", "name": "How does a Visa card payment come back after settlement?", "statement": "On Visa, money comes back after settlement through a dispute, often called a chargeback. The cardholder's issuer starts it under one of 23 dispute conditions in four categories: fraud, authorization, processing errors and consumer disputes. Each condition sets its own time limit. The acquirer may contest, and the case moves through fixed stages toward arbitration by Visa, but the stages differ by category.", "details": [ { "label": "Only the issuer starts it", "value": "The issuer may dispute only after presentment and only when every requirement of a condition is met. Before disputing it must try to honor the transaction, and it may dispute only where the cardholder lost money, except under the authorization category and conditions 12.4 and 13.8. Each transaction is disputed on its own.", "citation": "VR 1.10.1.1 (ID# 0003287); 11.2.1 (ID# 0030211); 11.2.2 (ID# 0030212); 11.2.3 (ID# 0030213)", "rests_on": "rule" }, { "label": "The conditions", "value": "Category 10, fraud: 10.1 to 10.5. Category 11, authorization: 11.1 to 11.3. Category 12, processing errors: 12.2 to 12.7 (there is no 12.1). Category 13, consumer disputes: 13.1 to 13.9. That is 23 conditions.", "citation": "VR 11.7 to 11.10, section headings", "rests_on": "rule" }, { "label": "Time to dispute", "value": "Most conditions give 120 calendar days from the processing date; 11.1, 11.2, 11.3 and 12.7 give 75. Some consumer conditions start the clock at a later event, such as the expected delivery date or the date on a credit receipt, but never beyond 540 days after processing.", "citation": "Time limit tables, for example VR 11.7.5.4 (ID# 0030255), 11.8.2.4, 11.9.6.4, 11.10.2.4 (ID# 0030316), 11.10.7.4 (ID# 0030346)", "rests_on": "rule" }, { "label": "Fraud and authorization path", "value": "Categories 10 and 11 have no dispute response. The acquirer may make a pre-arbitration attempt within 30 calendar days of the dispute, the issuer answers within 30, and the acquirer may then file for arbitration within 10.", "citation": "VR 11.2.2, Table 11-1 (ID# 0030212)", "rests_on": "rule" }, { "label": "Processing error and consumer path", "value": "In categories 12 and 13 the acquirer first sends a dispute response within 30 calendar days. The issuer may then make a pre-arbitration attempt within 30, the acquirer has 30 to answer, and it is the issuer that may file for arbitration, within 10.", "citation": "VR 11.2.3, Table 11-2 (ID# 0030213)", "rests_on": "rule" }, { "label": "Counting and one-shot rules", "value": "The processing date of the step before is not counted as a day. The issuer may not dispute the same transaction twice (10.5 excepted), the acquirer may answer a dispute only once, and a Member that lets a deadline pass is treated as closing the cycle and owes the last amount the other side received.", "citation": "VR 11.2.1 (ID# 0030211)", "rests_on": "rule" }, { "label": "No resubmission by the merchant", "value": "A merchant may not put a disputed and returned transaction through again; it may seek payment from the customer outside the Visa system.", "citation": "VR 5.10.1.2 (ID# 0003022)", "rests_on": "rule" } ], "exceptions": [ "CEMEA Region (Nigeria): for domestic transactions the acquirer's first response stage is 2 business days (Tables 11-1 and 11-2 notes).", "CEMEA Region (Tanzania): domestic response stages are shortened to 20 and 10 calendar days (Tables 11-1 and 11-2 notes).", "Europe Region (Poland): the first acquirer stage for domestic ATM transactions is 20 calendar days in category 10 and 11 disputes and in 12.6 and 13.9 (Tables 11-1 and 11-2 notes).", "CEMEA Region (Egypt) and AP Region (India): domestic ATM disputes under 12.6 and 13.9 give the acquirer 10 and 6 calendar days to respond (Table 11-2 notes).", "Condition 11.1 (Card Recovery Bulletin) is limited to disputes processed through 2026-10-23 (VR 11.8.1).", "Domestic transactions under a Private Agreement need not use VROL or VisaNet for dispute financial messages (VR 11.3.1, ID# 0030214)." ], "applies_to": "Disputes on Visa transactions between Members in all Visa Regions, with the country variants listed", "caveat": "A decline is not a return: it happens at authorization, before any money moves. Do not apply one representment timeline to every condition, because categories 10 and 11 skip the dispute response and the filing party for arbitration differs. Dispute days are calendar days unless a note says otherwise.", "related": [ "visa:finality", "visa:refund", "visa:liability", "visa:decision-points", "visa:messages", "visa:limits", "visa-dispute:12.2", "visa-dispute:13.6", "visa-dispute:10.3", "visa-dispute:10.2", "visa-dispute:13.7", "visa-dispute:12.3", "visa-dispute:12.4", "visa-dispute:10.5", "visa-dispute:11.1", "visa-dispute:10.4", "visa-dispute:13.1", "visa-dispute:12.5", "visa-dispute:11.3", "visa-dispute:13.2", "visa-dispute:12.6", "visa-dispute:12.7", "visa-dispute:13.3", "visa-dispute:11.2", "visa-dispute:13.8", "visa-dispute:10.1", "visa-dispute:13.4", "visa-dispute:13.5", "visa-dispute:13.9", "paypal:return" ], "basis": { "sources": "Visa Core Rules and Visa Product and Service Rules, edition 18 April 2026 (marked Visa Public), fetched 2026-09-19 with a plain GET from https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf (7,591,762 bytes, 923 pages, PDF created 2026-04-21) and read with python3. Sections read for this record: 1.10.1.1, 5.10.1.2, 11.2.1, 11.2.2 with Table 11-1, 11.2.3 with Table 11-2, 11.3.1, the headings of 11.7 to 11.10, 11.8.1, and the dispute time limit tables named. Rules are cited by section and ID#; nothing is quoted, and the wording and order here are Orca's own.", "confidence": "high" }, "currency": { "effective_since": "Not dated in the edition read", "effective_note": "Stated as the rules read in the 18 April 2026 edition; the rules cited carry their own last-updated months in their ID# footers. Visa publishes a new edition each April and October, and the next is expected in October 2026 [Inference from the edition pattern]. Known dated changes: for disputes processed on or after 2026-10-24, the 10.4 compelling-evidence rule widens and condition 11.1 is retired (VR 11.7.5.3, ID# 0030254; 11.8.1). On 2027-04-24 a further 10.4 change starts for Australia, New Zealand and Singapore (VR 11.7.5.3).", "source_edition": "Visa Core Rules and Visa Product and Service Rules, edition 18 April 2026", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf", "source_class": "authoritative_primary", "source_title": "Visa Core Rules and Visa Product and Service Rules, 18 April 2026", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms every detail's citation: VR 1.10.1.1 and 11.2.1 to 11.2.3 on when and how often an issuer may dispute, the 23 dispute conditions across categories 10 to 13, the 120 and 75 day filing windows and the 540 day ceiling read from each condition's own time limit table, VR 11.2.2 with Table 11-1 on the no-dispute-response category 10/11 cycle, VR 11.2.3 with Table 11-2 on the category 12/13 cycle, VR 11.2.1 on day counting and the one-dispute and one-response rules, and VR 5.10.1.2 on the bar on merchant resubmission. Confirms the Nigeria, Tanzania, Poland, Egypt and India country variants and that condition 11.1 applies only through 23 October 2026." } ] }, "rail_name": "Visa", "governing_authority": "Visa (Visa Core Rules and Visa Product and Service Rules)", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] }, { "uid": "visa:settlement", "id": "settlement", "rail": "visa", "kind": "rail-fact", "facet": "settlement", "name": "How and when do Visa transactions settle between Members?", "statement": "Visa settles between Members, not payment by payment. Clearing produces a daily net amount for each Member in its settlement currency, and Visa arranges the transfer of those amounts. Outside Europe, where a country has a National Net Settlement Service, domestic transactions in local currency must settle through it; other traffic goes through the International Settlement Service. In Europe, Visa itself stands behind the settlement of Visa transactions that meet stated conditions. Settlement dates and cut-off times are not in the public rules.", "details": [ { "label": "Net amounts, daily", "value": "In Visa's terms, settlement follows clearing: each Member's obligations, to other Members and to Visa, are totalled into a daily net figure in its settlement currency, covering transactions and fee collections, and that figure is reported and paid.", "citation": "Glossary: Settlement (ID# 0025095), Settlement Amount (ID# 0025096), Settlement Date (ID# 0025099)", "rests_on": "rule" }, { "label": "What must run through VisaNet", "value": "International transactions must be authorized, cleared and settled through VisaNet, and domestic transactions processed elsewhere must be reported to Visa. In the Canada and US Regions and in listed AP countries the VisaNet rule reaches all Visa transactions, unless Visa has approved another route. In Europe, EEA cross-border transactions go through a Visa Scheme Processor.", "citation": "VR 1.7.1.1 (ID# 0007788)", "rests_on": "rule" }, { "label": "National Net Settlement Service", "value": "Outside Europe, a Member must enroll its BINs in the national service where one exists and use it for qualifying domestic transactions processed through VisaNet in local currency, subject to listed exceptions such as programs that settle in a non-local currency. In an emergency Visa may suspend a national service, move domestic transactions to the International Settlement Service and collect in full from the Member's settlement account or bank.", "citation": "VR 7.7.1.1 (ID# 0029856)", "rests_on": "rule" }, { "label": "Ready to settle on submission", "value": "A Member that submits a clearing record must be able to settle within the timeframe Visa sets for that settlement service and currency. The public rules do not state that timeframe.", "citation": "VR 7.7.5.1 (ID# 0029031)", "rests_on": "rule" } ], "exceptions": [ "Europe Region: the national service and readiness rules do not apply; a Member using Visa for processing follows the Visa Europe Operating Regulations - Processing, which were not read (VR 7.7.1.1; 7.7.5.1; 1.1.1.2, ID# 0029986).", "Europe Region: Visa takes on the payment obligation for Visa transactions that meet its conditions, among them processing by a Visa Scheme Processor, reporting to Visa within 24 hours of the transaction date, meeting data quality standards, and reporting any settlement failure within 24 hours; a co-badged card used on another scheme is not a Visa transaction (VR 7.7.3.3, ID# 0029572).", "Europe Region: Visa may require Members to settle on its estimates when clearing is delayed, and may share a loss from a Member's failure among Principal Members, collected within 120 calendar days (VR 7.7.3.15, ID# 0030062; 7.7.3.16, ID# 0030096).", "AP Region: a Member answers for the settlement obligations of entities it owns or controls, and Visa may offset against its accounts worldwide (VR 7.7.2.2, ID# 0005423).", "LAC Region (Aruba, Brazil, Curacao, Sint Maarten, Venezuela): an acquirer in the national service must process domestic transactions in local currency (VR 7.7.1.1).", "Canada Region: a Member with a Private Agreement for settling domestic transactions is outside the national service rule (VR 7.7.1.1)." ], "applies_to": "Settlement of Visa interchange between Members, in all Visa Regions; the national service rules outside Europe only", "caveat": "Settlement timing, cut-offs, and when a settlement transfer is final in the settlement bank are set in the VisaNet Settlement Service guides and national procedures, which are Supplemental Requirements not read here [Unverified]. The public text of VR 7.7.3.3 refers to a Section X, a placeholder, so part of the Europe rule is not published.", "related": [ "visa:finality", "visa:messages", "visa:participants", "visa:hours", "paypal:settlement" ], "basis": { "sources": "Visa Core Rules and Visa Product and Service Rules, edition 18 April 2026 (marked Visa Public), fetched 2026-09-19 with a plain GET from https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf (7,591,762 bytes, 923 pages, PDF created 2026-04-21) and read with python3. Sections read for this record: 1.1.1.2, 1.7.1.1, 7.7.1.1, 7.7.2.2, 7.7.3.3, 7.7.3.15, 7.7.3.16, 7.7.5.1, and the glossary entries named. Rules are cited by section and ID#; nothing is quoted, and the wording and order here are Orca's own.", "confidence": "medium" }, "currency": { "effective_since": "Not dated in the edition read", "effective_note": "Stated as the rules read in the 18 April 2026 edition; the rules cited carry their own last-updated months in their ID# footers. Visa publishes a new edition each April and October, and the next is expected in October 2026 [Inference from the edition pattern].", "source_edition": "Visa Core Rules and Visa Product and Service Rules, edition 18 April 2026", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source_url": "https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf", "source_class": "authoritative_primary", "source_title": "Visa Core Rules and Visa Product and Service Rules, 18 April 2026", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms every detail's citation: the Settlement, Settlement Amount and Settlement Date glossary entries, VR 1.7.1.1 on the VisaNet processing requirement and its regional reach, VR 7.7.1.1 on the National Net Settlement Service enrollment duty, its exceptions, the LAC local-currency countries, the Canada Private Agreement carve-out and Visa's emergency suspension power, and VR 7.7.5.1 on settlement readiness. Confirms the Europe exclusion from the national-service rule and the Section X placeholder in VR 7.7.3.3, and that settlement timing and cut-offs are not stated in the sections read." } ] }, "rail_name": "Visa", "governing_authority": "Visa (Visa Core Rules and Visa Product and Service Rules)", "snapshot": "2026-09-19", "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "boundaries": [] } ] }